O Postmortem da Reescrita: O Que o k10s Diz Sobre IA Codando Sem Supervisão

Em maio de 2026, dois times trabalhando no mesmo domínio de problema publicaram histórias quase opostas na mesma semana. O time do k10s, criadores de um dashboard para Kubernetes, postou I’m Going Back to Writing Code by Hand. A construção assistida por IA no estilo “vibe-coded” tinha desabado sob a própria arquitetura: um monólito god-object com data races severos o bastante para que a única correção sensata fosse uma reescrita completa em Rust. Na mesma semana, o time da WorkOS publicou The Self-Driving Codebase: Building Horizon at WorkOS, um relato funcional de agentes de código rodando autonomia de produção sob um orquestrador desenhado de propósito.

Mesmo domínio. Mesma semana. Resultado oposto. Ler os dois lado a lado é a educação mais honesta em governança de IA que dá para receber agora.

O Que de Fato Falhou no k10s

O postmortem do k10s é incomumente direto. O autor não culpou os modelos. Culpou a ausência de autoridade arquitetural. Funcionalidades eram adicionadas por prompt. O gerenciamento de estado morava onde quer que a geração mais recente tivesse decidido pôr. A base de código se consolidou, organicamente, em um único god object que possuía coisas demais para refatorar com segurança. Quando bugs de concorrência apareceram, o time não conseguiu isolá-los porque a arquitetura não tinha fronteiras contra as quais isolar. Os data races não foram introduzidos por um commit ruim. Eram o comportamento de regime permanente de um sistema sem contrato entre as partes.

A decisão a que chegaram é a parte que vale ler duas vezes. Eles não pararam de usar IA. Concluíram que a forma como vinham usando produzia uma base de código que nenhum humano conseguia raciocinar a respeito, e que reescrever do zero em Rust, com uma arquitetura desenhada a mão e guardrails técnicos no lugar antes de qualquer agente tocar, sairia mais barato do que continuar debugando a base existente. A reescrita não é recuo da assistência de IA. É a reconstrução da superfície de restrição que deveria ter existido antes do primeiro prompt.

O Que Funcionou na WorkOS

Horizon é o mesmo tipo de história contada pelo outro lado. A WorkOS descreve uma stack de agentes de código rodando pela base de produção deles com autonomia real, e a descrição passa a maior parte do tempo não no modelo, mas na estrutura ao redor dele. O orquestrador. O harness de avaliação. As portas de merge. A taxonomia do trabalho que é delegado e a taxonomia do que não é. As decisões arquiteturais humanas que o agente herda como imovíveis.

Os engenheiros da WorkOS não dão crédito a um modelo específico. Dão crédito a um sistema em que o modelo opera dentro de um envelope desenhado. O agente é rápido nas tarefas que o sistema entrega para ele. O sistema, não o agente, decide quais são essas tarefas.

Dois times. Mesma semana. Mesmo domínio. O time do k10s operou sem superfície de restrição e queimou uma base de código. O time da WorkOS desenhou a superfície de restrição antes e rodou o agente dentro dela. O modelo não foi a diferença. O harness foi.

A Frase Que Nomeia a Lição

Lendo relatos suficientes desse tipo, uma frase emerge em todos eles. A alavanca de governança não é “usar menos IA”. É “desenhar a superfície de restrição antes do agente escrever a primeira linha”.

A superfície de restrição é a união de três coisas. Uma arquitetura decidida por humanos, escrita e tratada como imovível pela duração do trabalho. Um conjunto de guardrails técnicos: sistemas de tipos, regras de lint, limiares de cobertura de teste, contratos de concorrência, fronteiras de módulos. Uma disciplina de revisão que converte a saída do agente em código commitado apenas depois que um humano leu. Sem essas três, o agente produz código que se compõe em uma estrutura sem responsável. Com essas três, a velocidade do agente vira alavanca, não passivo.

O time do k10s agora está instalando essas três coisas em torno de uma base nova. O time da WorkOS instalou antes do agente rodar. A diferença de custo entre essas duas sequências é a reescrita.

Por Que “Só Tomar Mais Cuidado” Não Resolve

Uma leitura do postmortem do k10s que termina em “a lição é ser mais disciplinado com a IA” é a leitura que garante o próximo postmortem. Disciplina não é virtude pessoal. É propriedade arquitetural do sistema dentro do qual o time trabalha. Antirez sustentou a disciplina sozinho no tipo Array do Redis porque é um dos engenheiros de sistemas mais respeitados em atividade e o projeto era pequeno o bastante para caber em uma cabeça. A maioria dos times não é o antirez e a maioria dos projetos não cabe em uma cabeça. A disciplina precisa ser codificada, não improvisada.

Já escrevemos sobre a construção de quatro meses do tipo Array do Redis por antirez como a versão prática da colaboração disciplinada com IA e sobre code smells como camada de governança que sobrevive ao contribuidor IA. O caso k10s é o espaço negativo desses posts. Mesmo problema, sem disciplina codificada, desfecho previsível.

O Que Isso Significa para a Prática de Engenharia do Seu Time

Três ações valem a pena ser tomadas neste trimestre se seu time entregou algo substancial com assistência de IA.

Primeiro, audite sua superfície de restrição antes da próxima funcionalidade assistida por IA. Escreva as decisões arquiteturais que são imovíveis. Escreva os módulos que possuem estado e os contratos entre eles. Escreva as garantias de teste, tipo e concorrência que a base impõe hoje. Se esse documento não existe, o agente já está operando sem ele, e o próximo data race é evento de calendário, não surpresa.

Segundo, desenhe a linha entre arquitetura e implementação por escrito. Agentes são excelentes em implementação dentro de uma arquitetura estável. Agentes são catastróficos em arquitetura sem supervisão. A linha é o ativo. A maioria dos times não a desenhou.

Terceiro, trate o orquestrador como sistema de primeira classe, não como script. A lição da WorkOS é que a parte da stack que decide o que o agente faz, no que ele pode tocar, como a saída dele é controlada e como o trabalho é revisado é a parte que determina se autonomia compõe valor ou compõe dívida. Construa essa parte de propósito.

A reescrita do k10s não é o fim do vibe-coding como prática. É o custo de ter tentado em uma base séria sem a governança em volta. A versão mais barata dessa lição é a versão que seu time lê no postmortem de outra pessoa antes de escrever o próprio.

O slogan é fácil. A superfície de restrição é o trabalho.

---

Fontes

• blog.k10s.dev. “I’m Going Back to Writing Code by Hand.” Maio de 2026.
• WorkOS. “The Self-Driving Codebase: Building Horizon at WorkOS.” Maio de 2026.

A Victorino ajuda organizações de engenharia a desenhar a superfície de restrição que transforma autonomia de IA em alavanca de entrega em vez de risco de reescrita: contato@victorino.com.br | www.victorino.com.br