stamatios
← Voltar ao feed
Projeto enrolado jogado no lixo ao lado de guindaste ativo, fim do modo plan
Dev & Engenharia

Modo plan está morto: desenvolvedores preferem loops de ação

resumo de ~3 min

O que era o Nuanced e por que foi criado

Ayman Nadeem, ex-engenheiro sênior do GitHub, lançou no início do ano o Nuanced, um aplicativo desktop de codificação construído em torno de uma tese forte: o planejamento seria a parte mais importante de construir software com IA. A motivação vinha de uma observação concreta - a IA aumentou radicalmente a velocidade e o volume de geração de código, mas as interfaces não acompanharam esse novo ritmo. A pergunta central do produto era como humanos mantêm um modelo mental coerente de um sistema de software enquanto máquinas o modificam mais rápido do que conseguem inspecionar.

O problema que ele queria resolver

A geração fácil de código criava uma carga de manutenção enorme antes mesmo de pensar no que se estava construindo ou por quê. Isso dificultava raciocinar sobre comportamento e depurar premissas incorretas que já tinham sido endurecidas em código. Nadeem relata que, se subespecificava a arquitetura, o agente preenchia as lacunas por conta própria, criando problemas futuros nas fronteiras de abstração, e esses mal-entendidos se propagavam por vários arquivos abaixo da superfície do chat. O resultado era uma sensação de desconexão mental - ele descreve como se sentia "zumbi" ao usar apps como Conductor e Codex com vários agentes em paralelo - e mais dificuldade para verificar se os resultados estavam corretos.

Os plan modes existentes também não bastavam: serviam a dois propósitos históricos, especificar instruções precisas o suficiente para o agente e ajudar humanos a entender o que estavam construindo. Ele sentia falta de um "lar" para os planos, que ficavam presos em blocos de texto efêmeros no backscroll do chat, exigindo cortar e colar mensagens para revisar.

A aposta do produto

O Nuanced transformava cada thread de chat em um plano persistente: o usuário conversava sobre o que queria construir, o sistema destacava ambiguidades e decisões que exigiam input, e juntos chegavam a um plano antes da implementação. O produto implementava o plano verificando aderência aos requisitos, num pipeline de ponta a ponta: intenção → implementação → revisão → verificação. Ele via a ferramenta mais como uma prótese para a mente do que mais um app de codificação.

Por que a tese falhou

Nadeem atribui o fracasso a quatro fatores. Primeiro, ele confundiu planejar com plano: usuários tinham pouco apetite pela especificação estruturada. Segundo, os modelos ficaram muito bons - com contexto e memória, passaram a explorar repositórios grandes, fazer suposições razoáveis e revisar o próprio trabalho, reduzindo a necessidade de instruções explícitas. Ele nota que a capacidade do modelo competia com o design de interfaces para o pensamento humano: cada decisão que o modelo tomava sozinho era uma decisão a menos a ser surfaceizada.

Terceiro, texto gerado por IA é doloroso de ler: as especificações eram longas, com ritmo e estruturação que faziam os olhos "desfocar". A solução paliativa, um "Spec Tour" que guiava pelos pontos importantes, só adicionava complexidade - e se era preciso gerar uma versão menor para tornar o documento utilizável, qual era o sentido do documento completo?

Quarto, o fluxo era linear e sequencial demais (chat → desambiguar → gerar spec → revisar → aprovar → implementar → revisar código). O pensamento real é intercalado: você entende parte do problema, tenta algo, a geração inicial ensina algo novo e você muda de ideia. A interface forçava os usuários a "terminar de pensar" prematuramente, e voltar ao raciocínio anterior parecia retroceder numa cascata. A separação entre plan mode e build mode também era estranha: o usuário precisava decidir se uma tarefa merecia planejamento e lembrar de ativar o modo certo - algo que, segundo ele, a IA deveria decidir pelo contexto.

O novo loop e o problema em aberto

Com agentes melhores, o antigo fluxo "planejar → aprovar → executar" - justificado quando o custo de errar a direção era alto - cede lugar a um loop de: entender → agir → inspecionar → clarificar → ajustar → agir de novo. Há enorme planejamento dentro desse loop, mas ele não precisa se materializar como um documento chamado "o plano". O maior erro, conclui ele, foi transformar o plano em artefato em vez de desenhar um processo que melhorasse o entendimento humano.

Ele reconhece que o problema de manter o entendimento atualizado permanece aberto - e fica mais difícil ao escalar de cinco para centenas de agentes em paralelo. Agentes precisarão identificar os poucos lugares onde a atenção humana tem maior impacto e surfaceizar contexto suficiente. A necessidade de tornar a complexidade compreensível, argumenta, é permanente mesmo enquanto as interfaces mudam.