Como ler: os degraus sobem porque a IA assume mais execução a cada fase — mas a linha tracejada mostra o que muda de verdade: na fase 1 você decide cada linha; na fase 3 você decide o sistema em que o agente trabalha. É por isso que a engenharia importa mais, não menos.
Mapa da trilha
Conteúdo detalhado
🧭 Onde realmente está a IA na engenharia
As três fases (autocomplete, assistente, agente), o que um agente precisa para funcionar, o novo papel do engenheiro e os limites reais das ferramentas.
Três estágios de uso da IA no desenvolvimento. Fase 1 sugere linhas enquanto você digita. Fase 2 responde, explica e gera arquivos sob pedido. Fase 3 recebe uma tarefa e executa: lê o repositório, edita arquivos, roda comandos e testes, analisa o erro e tenta corrigir a própria implementação.
Cada fase exige um tipo de controle diferente. Aplicar hábitos da fase 1 num agente da fase 3 é a origem da maior parte dos acidentes: você revisa uma linha enquanto ele já alterou dezoito arquivos.
Autocomplete = sugestão · Assistente = resposta sob demanda · Agente = execução com ferramentas · A responsabilidade humana migra da linha para o sistema.
A lista de pré-requisitos operacionais de um agente: acesso controlado ao repositório, contexto, documentação, ferramentas, ambiente de execução, memória, estado, permissões, regras, testes, critérios de conclusão, mecanismo de interrupção e registro das ações.
Quando um agente "não funciona", quase sempre falta um item dessa lista — não é o modelo que é fraco. É o diagnóstico mais rápido que existe.
Agente = componente operacional dentro de um sistema controlado · Sem critério de conclusão não há conclusão · Sem registro não há auditoria.
O deslocamento do trabalho: menos digitar cada linha, mais especificar, montar contexto, definir limites, desenhar verificação e julgar resultado.
Quem continua medindo produtividade em linhas escritas fica invisível; quem estrutura o sistema em que a IA trabalha multiplica o time inteiro.
Especificar > digitar · Julgar resultado é habilidade central · Velocidade sem verificação é risco acelerado.
O conhecimento durável de engenharia — arquitetura, testes, sistemas operacionais, redes, APIs, segurança, bancos e infraestrutura — usado para avaliar o que a IA produziu.
Sem fundamentos você não percebe concorrência quebrada, falha de segurança, erro de modelagem, dependência frágil ou impacto em outro sistema — e o código passa nos testes assim mesmo.
Quanto mais código gerado, mais valiosa a capacidade de avaliar · Ferramenta muda, entendimento de sistemas fica.
O que a IA ainda erra sistematicamente: enxerga só o contexto que você deu, não conhece regras não escritas, presume comportamento de integrações que não pode observar e confunde "teste passou" com "intenção atendida".
Saber onde a ferramenta falha é o que define quais tarefas você delega hoje e quais exige aprovação humana.
Contexto ausente = suposição · Passar no teste ≠ estar correto · Limite conhecido vira regra, não surpresa.
O modo de trabalho em que a única entrada é a frase do momento: sem especificação, sem testes, sem limites e sem revisão independente.
Ele parece produtivo por uma semana e cobra o preço no mês seguinte: duplicação semântica, inconsistência entre módulos e mudanças que ninguém consegue revisar.
A IA acelera produção e também acelera erro · O diferencial não está no prompt, está no sistema em volta.
📐 Spec-Driven Development
Como transformar intenção em especificação estruturada que reduz ambiguidade — e que um agente consegue executar e verificar.
Um fluxo em que a especificação vem antes do código: intenção → especificação estruturada → plano → implementação → testes → verificação.
A especificação é o único artefato que diz o que é "certo". Sem ela, agente e humano negociam a definição de pronto no meio do caminho.
Spec ≠ texto genérico · Reduzir ambiguidade é o objetivo · Toda spec termina em critério verificável.
O esqueleto padrão: problema, objetivo, escopo, fora do escopo, entradas, saídas, contratos, condições de erro, restrições, critérios de aceitação, testes e definição de pronto.
Cada campo ausente vira uma decisão que o agente toma sozinho — normalmente a mais genérica possível.
"Fora do escopo" evita refatoração selvagem · "Contratos" protege quem consome sua API · "Definição de pronto" encerra a discussão.
A fronteira explícita da tarefa mais a lista de condições observáveis que provam a conclusão.
Agente sem fronteira "melhora" o que não foi pedido; critério vago devolve trabalho que parece pronto e não é.
Critério de aceitação é verificável, não opinativo · Escopo negativo vale tanto quanto o positivo.
A parte da spec que fixa formatos, interfaces e comportamentos preservados, além do que deve acontecer em cada falha.
Quase toda regressão grave em produção nasce de um contrato implícito que ninguém escreveu e a IA não tinha como adivinhar.
Condição de erro é requisito · Compatibilidade é contrato · O caminho triste precisa de spec tanto quanto o feliz.
O par canônico: um pedido de uma linha versus a versão que fixa meios de pagamento, idempotência, estados, webhooks, retentativas, logs, compatibilidade, dados sensíveis, testes, rollback e bloqueio de merge.
É o exercício mais rápido para calibrar o time: todo mundo vê na hora quantas decisões estavam escondidas na frase curta.
Ambiguidade não some, ela é decidida por alguém · Quanto melhor a spec, menor a chance de decisão incompatível com o sistema.
A prática de traduzir cada critério de aceitação em um teste automático, fechando o ciclo spec → teste → implementação → verificação.
Uma regra escrita em texto é útil; a mesma regra como teste é confiável — e é o que permite delegar execução ao agente sem perder controle.
Teste é a spec executável · Sem teste, "pronto" é opinião · O verificador é quem autoriza a autonomia.