Engenharia assistida por IA: evidência acima do output

Um método delimitado para usar IA no trabalho de software sem terceirizar o critério técnico.

A IA pode reduzir o tempo de exploração e implementação. Ela não pode ser responsável pela decisão técnica, pelo risco ou pelo release. A pergunta útil não é quanto código um modelo produziu. É qual evidência permanece quando o código precisa ser compreendido, testado, protegido e mantido.

Este é o método que uso em trabalho de engenharia assistido por IA. Ele se baseia nos projetos públicos Formatloom e Max Bid, mas não afirma que cada linha desses projetos foi gerada por IA. A evidência registrada sustenta uma afirmação mais precisa: a IA ajudou em partes da implementação e da exploração técnica, enquanto os limites do produto, a revisão, os testes e a responsabilidade pela entrega permaneceram sob controle humano.

A especificação e as restrições vêm primeiro

Antes de pedir que a IA altere código, registro o que o produto precisa fazer, o que nunca deve fazer e como o resultado será verificado. A especificação não é uma formalidade para o modelo. É a fronteira que torna uma sugestão gerada passível de revisão.

O Formatloom tem um exemplo claro: o processamento fica no navegador, não existe endpoint de upload nem banco de dados da aplicação, a entrada é limitada a 1 MiB e uma conversão com perda precisa produzir um aviso visível. O Max Bid tem outra fronteira: um contrato de cálculo precisa continuar compreensível em uma aplicação Rails de referência e em uma implementação TypeScript estática, com localização e sem conversão de moeda.

As restrições mudam as perguntas que faço. Em vez de pedir uma implementação genérica, posso perguntar se uma proposta preserva um limite de privacidade, corresponde a um contrato observável, trata trabalho antigo no navegador ou expõe uma limitação do parser para a pessoa usuária.

Exploração assistida por IA

A IA é útil como parceira rápida para explorar um problema delimitado. Uso-a para comparar opções de implementação, enumerar casos de borda, sugerir fixtures de teste, explicar APIs desconhecidas e identificar perguntas que um design ainda não respondeu.

O resultado é um candidato, não uma decisão. Comparo-o com as instruções do repositório, a especificação, as convenções existentes e a menor mudança útil. Uma resposta fluente não é prova de que o design está correto. A evidência vem do contrato, do código, dos testes e do produto em execução.

Não publico uma contagem exata de prompts ou interações. Esses números não foram registrados como uma métrica confiável por projeto, e uma contagem de prompts não provaria qualidade de engenharia. O registro importante é a sequência entre restrição, decisão e verificação.

A implementação permanece incremental

A mudança assistida por IA mais segura é pequena o bastante para ser inspecionada. Prefiro uma sequência de partes estreitas:

declarar o comportamento e as condições de aceitação;
localizar a fronteira responsável no repositório;
pedir uma implementação ou comparação focada;
inspecionar o diff e rejeitar mudanças desnecessárias;
executar as verificações que cobrem a fronteira alterada;
inspecionar o produto antes de avançar para a próxima parte.

Isso mantém o modelo perto da fonte de verdade. Também torna a falha recuperável. Se uma sugestão estiver errada, o diff é pequeno, a razão fica visível e a próxima tentativa não precisa redescobrir o sistema inteiro.

A revisão humana é a fronteira de responsabilidade

Quem submete a mudança é responsável pelo resultado, independentemente de quem digitou o código. Revisão humana é mais do que procurar problemas de estilo. É perguntar se a implementação resolve o problema declarado, se os trade-offs são aceitáveis e se a pessoa consegue explicar os caminhos importantes e os modos de falha.

Para código que vai durar, reviso fluxo de dados, transições de estado, tratamento de erros, complexidade, fronteiras de segurança, acessibilidade e custo de manutenção. Também verifico se a implementação adicionou silenciosamente uma capacidade de que o produto não precisava, como persistência, uma requisição externa ou um novo segredo.

A profundidade da revisão acompanha o risco. Uma experiência descartável pode ter um gate mais leve. Uma regra pública de negócio, uma fronteira de privacidade no navegador ou um fluxo de implantação exigem revisão mais profunda porque alguém dependerá disso depois.

Testes transformam decisões em evidência

Testes não provam que um sistema é perfeito. Eles são registros executáveis das decisões que importam.

No Formatloom, a evidência inclui contratos do parser e do worker, avisos de fidelidade, limites das rotas Rails, fluxos no navegador, acesso por teclado, layouts responsivos e verificações de rede. No Max Bid, inclui o contrato de cálculo, comportamento monetário exato, localização, comportamento do DOM, cenários end-to-end, acessibilidade, inspeção de artefato e paridade com a referência Rails.

O nível do teste deve acompanhar o risco:

testes unitários e de contrato protegem fórmulas, parsers e formatos de mensagem;
testes de integração protegem as fronteiras entre partes da aplicação;
testes de navegador protegem comportamento observável, navegação e acessibilidade;
build, lint e análise estática protegem o artefato de release;
verificações manuais do produto cobrem o que testes automatizados não conseguem enxergar bem.

A IA pode sugerir testes. Ela não pode decidir que um teste aprovado cobre o risco certo sem compreender o sistema.

Verificações de segurança fazem parte da mudança

A revisão de segurança começa na fronteira do produto. No Formatloom, o worker não pode enviar o conteúdo do documento, o analytics é allowlisted e a Content Security Policy restringe destinos. No Max Bid, os valores ficam na memória do navegador, valores controlados pelo usuário são renderizados como texto, idiomas e moedas são allowlisted e o artefato gerado é verificado em busca de segredos e conteúdo inseguro.

A referência Rails acrescenta controles como proteção contra CSRF, HTTPS, strong parameters e filtragem de parâmetros. Brakeman e auditoria de dependências cobrem riscos que testes no navegador não conseguem cobrir. Essas verificações não são enfeites opcionais adicionados depois que a IA produziu o código. São condições de aceitação da implementação.

Inspecionar o produto em execução

Um diff pode parecer correto enquanto o produto está errado. Depois das verificações automatizadas, inspeciono a aplicação em execução: rotas, textos, ordem do foco, layout responsivo, estados de carregamento e erro, saída gerada e requisições de rede do navegador.

Em uma ferramenta local no navegador, o painel Network importa. Em uma calculadora estática, importam a navegação direta, a formatação localizada e o artefato gerado. Nos dois produtos, a pergunta é se o sistema em execução ainda corresponde ao limite escrito na especificação.

Essa etapa também encontra problemas difíceis de expressar em um prompt: um aviso tecnicamente presente mas ilegível, um resultado antigo que permanece na tela, um link para o idioma errado ou um asset de release que contém informação que não deveria conter.

Release e rollback

Release é outro gate de evidência. A mudança precisa passar pelos testes relevantes, gerar o artefato de produção, inspecionar esse artefato e publicar exatamente o commit que passou pelo CI. O workflow de implantação deve deixar claras suas permissões e condições de disparo.

Rollback deve fazer parte do design antes da primeira falha. Um registro de release precisa identificar o artefato anterior aprovado, o gatilho do rollback, o comando ou ação que o restaura e o smoke test que confirma a recuperação.

O registro de release do Max Bid é útil precisamente porque separa os gates automatizados locais aprovados das verificações pendentes de navegadores nativos, acessibilidade manual e rollback em produção. Não transformo um procedimento documentado em alegação de que o rollback foi executado. Se a evidência está pendente, ela continua pendente.

O que o uso de IA prova — e o que não prova

Trabalho assistido por IA pode mostrar que sei delimitar uma ferramenta, comparar opções, inspecionar mudanças e conectar implementação a evidência. Não prova desenvolvimento autônomo, um número específico de interações, uma percentagem de código gerada ou domínio profundo de uma área que o projeto não exercitou.

A responsabilidade continua simples: compreender a mudança, tornar o risco visível, executar as verificações certas e assumir o resultado que chega às pessoas.