Cinco decisões de engenharia que precisam ser tomadas antes de gerar código com IA

O engenheiro toma decisões tanto durante a codificação quanto antes dela. Se a primeira pergunta for feita diretamente à IA, o resultado vai funcionar, mas o seu custo já vai aumentar no segundo release.

Vibe coding vs trabalho de engenharia

Vibe coding é um processo em que a pessoa descreve o resultado desejado, pede ajustes com base na observação e, quando a tela funciona, para. O trabalho de engenharia com IA inclui, além disso, as restrições do sistema existente, as mudanças permitidas, as condições de falha e as formas de verificação. O código pode ser gerado em ambos os casos. A diferença está em quais decisões foram tomadas de forma consciente.

Não se trata de níveis de senioridade — um desenvolvedor iniciante pode trabalhar da segunda forma, e um experiente, da primeira. O que importa é a experiência que se transformou em compreensão das dependências. Quando você já fez rollback de um release ou investigou um registro concorrente no banco de dados, em uma nova tarefa perguntas adicionais surgem naturalmente — antes do código e antes do primeiro defeito.

Para um prototype, a verificação visual pode ser suficiente. Para um serviço com usuários reais, o pedido "adicione mais uma funcionalidade" já altera um sistema em produção, e seu custo não se reduz ao tempo de geração.

Cinco decisões antes da primeira linha de código

1. Integrações: definir o limite do contrato externo

Em um produto em produção, isso costuma ser três serviços separados: A recebe dados do provedor, B implementa a regra de negócio, C exibe o resultado. Se o formato externo penetrou nas três partes, um novo provedor significa alterar A, B e C simultaneamente. Se A converte os dados para um contrato interno, um novo provedor é apenas um novo adaptador, e B e C permanecem inalterados.

Exemplo: um catálogo de jogos com duas fontes. A primeira descreve o jogo como `{id, name}`, a segunda como `{code, title}`. A abordagem errada é fazer os consumidores conhecerem os dois formatos e escolherem o campo com base no tipo de fonte. Cada novo provedor acrescenta um novo ramo em cada função, e em um ano ninguém mais sabe dizer quantos pontos precisam ser alterados. A abordagem correta é os adaptadores converterem para um contrato comum `{key, title}`, sem que os consumidores saibam nada sobre o provedor. Conectar uma nova fonte não exige testes de regressão em todo o sistema.

2. Plataforma multimarca: definir os limites da variabilidade

Cada marca da plataforma era um produto separado, não uma cópia de um template com outro logotipo. Cada uma tinha suas próprias licenças, mercados, equipes de produto e cronogramas de release. Era preciso evoluir tudo em uma única base de código, preservando diferenças reais.

O modelo inicial parecia suficiente: um tema base, sobrescrito em cada marca específica. As sobrescritas foram além das cores. A mesma tarefa era resolvida de formas diferentes em vários lugares, as particularidades locais se acumulavam, e a estilização perdia coerência.

Foi preciso migrar para mixins SCSS, cujos caminhos eram resolvidos no contexto da marca durante o build. Essa migração, em produtos já em produção, acabou saindo mais cara do que escolher o modelo adequado desde o início.

3–5. Operações concorrentes, topologia e garantias de entrega

Uma recarga de saldo com duas repetições simultâneas exige efeito único e limites transacionais bem definidos. Uma mensagem de chat após um restart exige topologia de armazenamento e recuperação. A exclusão de dados antigos com atraso na execução da tarefa exige tempo de vida (TTL) e reexecução segura. Um release pronto exige sinais do cenário de negócio e condições de interrupção.

A experiência não se traduz em pontuação no prompt, mas em perguntas concretas na definição do problema. O tamanho do prompt, por si só, não garante nada. Se a tarefa é local e reversível, a definição pode ser curta. Se envolve um contrato compartilhado, saldo ou permissões, alguns esclarecimentos antes da implementação mudam o modelo de dados, a transação e o cenário de teste.