AI-assisted engineering ainda está se consolidando
como prática. As decisões abaixo não têm respostas
definitivas — têm trade-offs que cada time precisa
articular explicitamente.
Agente autônomo ou assistente com aprovação humana em cada passo?
Agentes autônomos (Claude Code com permissão
total, Cursor agent mode) são mais rápidos mas
menos controláveis: podem tomar decisões de
design que o engenheiro discordaria, introduzir
dependências não-planejadas, ou deletar código
"desnecessário" que tinha propósito não-óbvio.
Assistente com aprovação em cada passo (o humano
aceita ou rejeita cada mudança) é mais lento mas
o engenheiro mantém controle do que entra na base.
A regra prática que emerge da experiência: agente
autônomo para tarefas mecânicas e bem-definidas
(gerar testes para código existente, refactoring
de nome, gerar boilerplate de padrão estabelecido);
aprovação humana para qualquer coisa que afete
contratos entre componentes, segurança, ou
arquitetura.
Enviar código da empresa para LLMs externos — como avaliar o risco?
Toda requisição a um LLM externo (OpenAI, Anthropic,
Google) é uma transmissão de dado para servidor
de terceiro. A questão não é "o LLM vai vazar
meu código?" — é "estou transmitindo código
proprietário para uma infraestrutura fora do
meu controle, e quais são as implicações de
confidencialidade, compliance e IP?". Algumas
empresas resolvem isso com modelos on-premise
ou com APIs enterprise que oferecem contrato
de não-retenção de dados. Outras estabelecem
política de "não enviar código de sistemas
críticos". O ponto de partida é o mesmo de
qualquer ferramenta SaaS: verificar os termos
de serviço, envolver legal e segurança na
decisão, e não assumir que "provavelmente é
ok" é política suficiente.
TDD first ou LLM first?
LLM first (descrever o que quer e deixar a IA
gerar código + testes) é mais rápido no curto
prazo mas inverte a ordem: os testes são escritos
para passar no código que já existe, não para
definir o comportamento esperado antes da
implementação. O risco é a suíte de testes que
passa mas não captura os comportamentos que
importam. TDD first (humano escreve o teste que
falha, LLM implementa o código que faz o teste
passar) mantém o valor do TDD — especificação
executável do comportamento — e usa IA na parte
que LLMs fazem bem (implementar um comportamento
já definido). Para código novo em domínio complexo,
TDD first com LLM implementando é a combinação
mais robusta.
Como medir se IA está melhorando ou degradando a qualidade do código da base?
Sem medição, a percepção de "IA está ajudando"
é viés de confirmação — você lembra quando
acelerou, não quando introduziu bug sutil.
Métricas que dão sinal real: taxa de bugs
encontrados em review por PR gerado com IA
vs sem (se PRs com IA têm mais issues, algo
está errado no processo); cobertura de testes
em código gerado vs código manual; DORA metrics
(frequency, lead time, MTTR, change failure rate)
antes e depois da adoção. O que não é métrica
útil: "velocidade de geração de código" — código
gerado rápido que não funciona em produção é
custo, não ganho.
Spec-driven vs prompt-driven: qual o nível certo de formalização?
Prompt-driven: engenheiro descreve informalmente
o que quer no chat e itera até o resultado
parecer certo. Rápido, mas sem artefato persistente
— o raciocínio fica na conversa e não pode
ser revisado, versionado ou reaproveitado.
Spec-driven: antes de interagir com o LLM, o
engenheiro escreve uma spec estruturada (contexto,
comportamento esperado, exemplos, restrições).
A spec é um artefato de design, independente
do LLM — pode ser revisada por pares antes de
implementação. O custo é escrever a spec. O
retorno é que a spec força clareza de pensamento,
serve como documentação, e melhora dramaticamente
a qualidade do output do LLM por dar contexto
estruturado. Para funcionalidades de mais de 1
hora de implementação, spec-driven paga o
investimento.