A Armadilha do Espectador: Mantendo o Controle no Desenvolvimento Assistido por IA

Meus feeds se encheram de um novo gênero de conteúdo de engenharia: uma gravação de tela de um agente escrevendo código, narrada pela pessoa que assiste. Vinte minutos de tokens escorrendo para dentro do editor, um "uau" ocasional, um accept-all no final. A empolgação é real e eu compartilho dela — entrego trabalho relevante para agentes todos os dias, e esta série inteira existe porque isso mudou meu jeito de fazer engenharia. Mas quero nomear o que essa gravação de fato mostra, da forma mais gentil que consigo: não é um ganho de produtividade. É assistir. Os tokens fluem rápido o bastante para parecer progresso, o que faz disso a maneira mais confortável já inventada de não estar trabalhando.

O desconforto merece ser examinado, porque a postura é nova. Nenhum compilador jamais seduziu ninguém a ficar assistindo. A geração de código hoje é fluente, legível e narrada — ela performa competência em tempo real — e por isso convida uma plateia. Sentar nessa plateia parece supervisão. Está mais para abdicação com as luzes acesas.

Este post fecha uma linha de raciocínio que comecei em Engineering Before Inference — toda chamada de IA é uma decisão arquitetural — e continuei em O Handoff É a Unidade de Design — delegação dimensionada pela revisão que você consegue bancar. Este aqui é sobre a postura por trás dos dois: minha perspectiva sobre como é o desenvolvimento assistido por IA quando funciona, hoje, e não em algum futuro projetado que não para de se afastar.

O plano de controle é o trabalho

O modelo mental ao qual eu sempre volto vem dos sistemas que construo. Toda rede séria e todo sistema distribuído sério separam um plano de controle de um plano de dados: o plano de dados move os pacotes, o plano de controle decide as rotas. Ninguém confunde os dois, e ninguém aloca no plano de controle pessoas que ficam vendo pacotes passarem.

Agentes são um plano de dados para mudança de software. Eles executam: escrevem o diff, rodam os testes, perseguem os erros de compilação. O desenvolvedor é o plano de controle: decide o que deve existir, em que ordem, sob quais restrições, e verifica se o que voltou é o que o sistema precisava. Assistir um agente digitar é abandonar o plano de controle para ir sentar na plateia do plano de dados — o único lugar da arquitetura onde um humano não acrescenta nada.

A indústria até nomeou o modo plateia com honestidade no começo. Quando Andrej Karpathy cunhou o termo vibe coding em fevereiro de 2025, o tweet dizia para "esquecer que o código sequer existe" — e, no mesmo fôlego, que o modo servia para projetos descartáveis de fim de semana. Essa segunda metade se perdeu conforme a expressão viralizou. A primeira metade virou fluxo de trabalho. Em 2026 o próprio Karpathy já traçava a linha profissional em outro lugar, falando de agentic engineering em vez de vibes — a versão em que um humano permanece no loop com intenção. Quem cunhou o termo seguiu em frente; a plateia continuou sentada.

Como é estar no controle neste ano

Minha própria resposta tem duas metades, e nenhuma delas é "digitar mais rápido".

A primeira metade é delegação paralela e delimitada. Parei de entregar funcionalidades para agentes e passei a entregar tarefas — pequenas, com escopo explícito e critérios de conclusão — várias ao mesmo tempo quando são independentes. Enquanto um agente migra a interface de um repositório, outro rascunha os testes de contrato de um endpoint, e eu não estou assistindo nenhum dos dois; estou preparando o próximo briefing ou revisando o último resultado. A mecânica de dimensionar esses handoffs é o assunto inteiro do post anterior, então não vou repeti-la aqui. O ponto sobre postura é outro: paralelismo é o que o plano de controle faz com o próprio tempo. Um roteador não acompanha um pacote pela rede inteira. No instante em que me pego assistindo um único agente trabalhar, caí de operador para espectador, e a fila de decisões que só eu posso tomar está crescendo às minhas costas.

Estar no controle também significa que o diff nunca recebe um accept-all. Toda mudança é lida antes de entrar — não porque o agente escreva código ruim, mas porque a aceitação é o único ato que transfere a propriedade. O agente produziu a mudança; fazer o merge a torna minha.

A segunda metade é onde acho que mora a velocidade de verdade, e ela recebe muito menos atenção do que a geração de código: pesquisa antes da implementação, automatizada. Antes de qualquer handoff de implementação, rodo um tipo separado e mais barato de delegação — agentes que investigam em vez de escrever. O que essa mudança toca? Quais serviços consomem esse contrato? O que quebra downstream se a semântica desse campo mudar? O que os três últimos incidentes nessa área tinham em comum? A saída é um documento de requisitos e efeitos colaterais que reviso em minutos, produzido enquanto eu fazia outra coisa. Erros são pegos no estágio em que custam a edição de um parágrafo, e não uma janela de rollback.

Isso é, na minha leitura, exatamente aquilo para o que a pesquisa do DORA vem convergindo. O relatório State of AI-assisted Software Development de 2025 constatou que a IA age principalmente como amplificadora do sistema organizacional em que aterrissa — fundações fortes amplificam, fracas também amplificam, na direção errada. O follow-up de maio de 2026 sobre ROI é mais direto: o retorno vem do sistema ao redor, não das ferramentas, e a adoção segue uma curva em J cujo vale é impulsionado pela curva de aprendizado, pela adaptação de processos downstream e pelo que o relatório chama de imposto de verificação — a carga de revisão que fluxos pesados em geração empurram para os humanos. O modelo deles chega a precificar o modo de falha: em uma organização de referência com 500 engenheiros, uma taxa de falha de mudanças subindo de 5% para 6% custa uma estimativa de US$ 344 mil em instabilidade. O enquadramento do relatório sobre o que medir é o que eu colocaria na parede: não o código que a IA escreve, mas "os gargalos que ela elimina". A pesquisa antecipada elimina o meu gargalo real — confiança no que uma mudança vai fazer — e é por isso que ela compra mais velocidade do que assistir código aparecer jamais compraria.

A última vez em que ninguém leu o código

Aqui está a parte que mais quero destacar, porque a indústria já rodou esse experimento antes.

Em dezembro de 2021, o Log4Shell chegou. Uma biblioteca de logging, uma vulnerabilidade — e a análise do Google sobre o Maven Central encontrou 35.863 artefatos afetados, mais de 8% de todo o ecossistema. O detalhe que importa para este post não é a contagem; é o formato. Apenas cerca de 7.000 desses artefatos dependiam do log4j diretamente. Para mais de 80% deles, a vulnerabilidade estava a mais de um nível de profundidade na árvore de dependências — para a maioria, cinco níveis abaixo; para alguns, nove. A mesma análise estimou que a remediação em todo o ecossistema levaria "provavelmente anos", e anos foi o que levou.

O Log4Shell não foi uma história sobre um bug. Foi o momento em que a indústria descobriu, de uma vez e sob ataque, quanto código em execução ninguém jamais tinha lido ou sequer sabia que estava entregando. A lição foi institucionalizada: SBOMs, varredura de dependências, proveniência, toda uma prática de segurança de cadeia de suprimentos construída para responder a uma pergunta — o que está de fato rodando em produção, e alguém entende isso?

Agora olhe para o fluxo do espectador com essa pergunta em mente. Código gerado em volume, no máximo passado de olho, aceito porque os testes estão verdes e a demo funciona, por um desenvolvedor que não conseguiria explicar a estratégia de tratamento de erros no diff que acabou de mergear. Isso é a cegueira do log4j sendo reconstruída um accept-all por vez — com uma diferença que a torna pior. Dependências transitivas eram, ao menos, código compreendido por alguém; o mantenedor conhecia aquilo, mesmo quando o consumidor não conhecia. Código gerado e não lido não tem mantenedor algum na cadeia que o entenda. A indústria passou uma década construindo ferramentas para responder "o que está rodando?" sobre código que outras pessoas escreveram. Seria um gol contra notável tornar essa pergunta irrespondível para código entregue sob o nome do próprio desenvolvedor.

Não estou prevendo um incidente específico, e o paralelo é estrutural, não literal. Mas quando vier a próxima correria sistêmica, os times que responderem rápido serão aqueles em que um humano ainda consegue explicar cada mudança relevante — e a diferença entre esses times e os demais está sendo decidida agora, uma revisão por vez.

O que o handoff consciente custa — e o que compra

Permanecer no plano de controle não é de graça, e fingir o contrário enfraqueceria o argumento. Então, a troca nomeada com honestidade.

Ele custa latência por tarefa: um handoff com briefing escrito, revisão de plano e diff lido sempre vai perder uma corrida contra um accept-all numa tarefa isolada. Ele limita o paralelismo: meu teto de concorrência não é quantos agentes consigo iniciar, mas quantos resultados consigo verificar de verdade — capacidade de revisão, não capacidade de geração, é o recurso escasso, o que é precisamente o imposto de verificação que o DORA descreve. E custa uma disciplina que o ferramental não impõe: nada em nenhum agente de código hoje impede um engenheiro cansado de passar os olhos e seguir em frente.

O que ele compra é cumulativo. Velocidade que sobrevive ao contato com a produção, porque os efeitos colaterais foram mapeados antes de a mudança existir. Depurabilidade, porque alguém entende o que foi entregue, e a resposta a incidentes começa a partir de conhecimento em vez de arqueologia. Habilidades que ainda estarão lá daqui a cinco anos, exercitadas a cada revisão em vez de atrofiarem na plateia. E um ritmo de entrega que se sustenta conforme o sistema cresce, em vez da barganha de mais throughput por menos estabilidade que o volume não revisado costuma fechar.

O checklist ao qual de fato me submeto, curto o suficiente para sobreviver a semanas reais:

• Pesquisa primeiro: antes de um handoff de implementação, um agente já mapeou requisitos, impacto e efeitos colaterais — e eu li esse mapa.
• Handoffs pequenos, em paralelo, cada um com escopo explícito e critérios de conclusão; concorrência limitada pelo que consigo revisar, não pelo que consigo iniciar.
• Nada de accept-all, nunca. Todo diff mergeado foi lido pela pessoa cujo nome está no merge.
• Se me pego assistindo tokens fluírem, paro e faço trabalho de plano de controle: o próximo briefing, a última revisão, a nota de arquitetura.
• O teste das 3 da manhã: se essa mudança acionar o pager de alguém hoje à noite, consigo explicar o que ela faz e por quê? Se não, ela não entra.

A IA deixou os desenvolvedores mais rápidos. A postura de espectador gasta essa velocidade em conforto; a postura de operador a investe em controle. Mesmas ferramentas, mesmos modelos, mesmo ano — a diferença está apenas em qual assento você ocupa.

​