Programar descrevendo o que você quer funciona. Essa é a parte que quem discute o assunto pula. Você descreve, o modelo escreve, você roda, e existe uma coisa que há uma hora não existia.
Onde para de funcionar é específico e merece nome, porque a falha não é «o código está ruim». O código geralmente está bem. A falha é que você não sabe mais o que tem lá dentro, e cada mudança nova precisa ser descrita para um modelo que também não sabe, porque a descrição do sistema não mora em lugar nenhum.
O formato do muro
Funciona assim. As dez primeiras mudanças são rápidas. Por volta da décima quinta, quebra algo que você não tocou. Você descreve o problema, o modelo corrige, quebra outra coisa. Você descreve aquela. Na mudança vinte e cinco você gasta mais tempo explicando o estado atual do app do que descrevendo o que quer, e o modelo gasta mais tokens relendo arquivos para deduzir o que as sessões anteriores fizeram.
Nada falhou. Você só cruzou o ponto em que o sistema é maior do que cabe na cabeça de qualquer um dos dois, e nenhum dos dois escreveu nada.
Quatro hábitos empurram esse muro bem para longe. Nenhum exige que você vire engenheiro de software.
1. Faça funcionar, depois faça parar
O hábito de maior valor: depois que algo funcionar, deixe num estado ao qual você consiga voltar.
Um commit. Uma cópia da pasta. Um arquivo duplicado. O que você realmente for fazer. O mecanismo importa menos que ter um, porque a alternativa é cada sessão colocar em risco o que já funcionava.
Com um agente isso pesa mais do que sem: um agente edita vários arquivos de uma vez, então quando uma mudança dá errado ela dá errado espalhada pelo projeto, e «desfazer» não é uma tecla. O Codoro mantém as edições atrás de um diff aprovado e tem desfazer otimista, o que ajuda dentro de uma sessão. Não te leva de volta para terça-feira.
2. Peça o plano antes da edição
Dois terços das sessões caras começam com uma tarefa que o modelo entendeu diferente de você.
Pergunte o que ele vai fazer. Leia. Corrija a parte errada. Aí deixe escrever.
Custa um turno barato e economiza dez caros com regularidade, porque um plano com o qual você não concorda é pego antes de existir código, em vez de depois de você revisar um diff construído em cima dele. E te dá algo para comparar o resultado: dá para ver se a mudança bate com o plano sem ler cada linha.
3. Diga o que não tocar
Modelos são prestativos de um jeito que às vezes destrói coisas. Peça para consertar o formulário de cadastro e o modelo alegremente também arruma o CSS, renomeia uma variável que achou confusa e atualiza três arquivos sem relação que leu no caminho.
Delimite: «mude só o formulário de cadastro; não toque em mais nada». Depois olhe quais arquivos aparecem no diff antes de aprovar. Se tem um que você não esperava, esse é o sinal inteiro — nem precisa ler a mudança para saber que algo saiu do trilho.
4. Tenha um arquivo dizendo o que isso é
Um arquivo de texto. O que o app faz, quais são as peças principais, o que você decidiu não fazer, o que está quebrado agora.
É o que empurra o muro mais longe, porque é o artefato que falta. Toda sessão começa deduzindo contexto a partir do código. Um arquivo que declare isso faz o modelo ler um parágrafo em vez de oito arquivos: mais barato, mais rápido e com mais chance de acertar, porque um parágrafo escrito por você descreve a sua intenção melhor do que o código descreve.
O Codoro lê regras com escopo de .codoro/rules/*.md, que é a versão formalizada da mesma ideia. Um
arquivo de texto na raiz funciona quase tão bem.
Para onde vai o dinheiro
Vale entender, porque a fatura é o que faz as pessoas desistirem.
Cada turno reenvia toda a conversa acumulada como entrada. O turno doze carrega os onze anteriores dentro dele: os arquivos lidos, os diffs propostos, os resultados das ferramentas, tudo. Uma sessão longa não é linear, é uma curva, e uma tarefa que descarrila é o evento caro.
Por isso os hábitos acima também são controles de custo. Um plano combinado num turno barato evita dez caros. Uma tarefa delimitada lê menos arquivos. Um arquivo de contexto substitui uma fase inteira de exploração.
Na prática: coloque um teto por execução. No Codoro são US$ 2,00 por tarefa por padrão, editável, com um respaldo de US$ 25,00 por dia. Coloque num valor que você ficaria irritado de bater — um teto acima do seu pior caso nunca disparou e não está protegendo nada. Quando dispara, a execução pausa e oferece um modelo mais barato em vez de trocar em silêncio, então quem decide é você.
Se você já tem uma chave de algum provedor, use: o markup é 0%, a chave fica no chaveiro do macOS e os tetos continuam valendo. O crédito hospedado tem 40% sobre o custo, que paga uma fatura só e nenhuma chave para administrar, e nada além disso.
O limite honesto
Nada disso te deixa consertar o que você não consegue ler. Existe um ponto em que um app precisa de alguém que o entenda, e os hábitos acima compram tempo e uma passagem de bastão melhor, não imunidade.
O que eles evitam de forma confiável é chegar nesse ponto sem ideia de como você chegou lá — que é a diferença entre «isso agora precisa de um desenvolvedor» e «isso precisa de um desenvolvedor e ninguém sabe explicar o que faz».
Situação
O Codoro está em prévia para macOS. Ainda não há download público: a página é uma lista de espera até existir uma release assinada. Tudo acima vale para qualquer editor com agentes; os tetos, o diff aprovado e as regras com escopo são como o Codoro faz especificamente.