Quando você usa IA pra gerar código, você assume responsabilidade de entendê-lo. Aqui está como honrar essa responsabilidade.

TL;DR

• Disseminação obrigatória — código gerado por IA cria ponto único de falha no desenvolvedor que pediu; distribuir conhecimento é pré-condição, não opcional.
• Mentoria como processo — sênior que usa IA ensina pleno a auditar a geração, não apenas a copiar a saída; transferi-se o método, não o snippet.
• Dívida técnica explícita — aceitar código não refatorado é contrair dívida consciente; manter registro audível é parte do contrato.
• Domínio antes da ferramenta — gerar código em área que o desenvolvedor não compreende é negligência; competência é pré-requisito, não consequência.
• Accountability sem disfarce — “IA sugeriu” não é desculpa; pedir, escolher e aceitar são três atos que permanecem sob custódia humana.
• Prática como defesa — assumir responsabilidade do desenvolvedor com código gerado por IA exige processo público, não promessa verbal.

Conhecimento gerado por IA não é posse: é responsabilidade distribuída

Vibe code com IA cria um ponto único de falha: o desenvolvedor que gerou o código. Em organizações com processo de revisão maduro, esse ponto único é mitigado por code review, pair programming e rotação de responsabilidade. Em organizações que tratam IA como acelerador individual, o nó de conhecimento crítico fica depositado em uma cabeça. Quando esse desenvolvedor sai, fica, muda de stack ou simplesmente esquece o contexto, o sistema se torna órfão.

A contramedida operacional tem cinco frentes complementares:

• Pair programming intra-sprint — outro desenvolvedor acompanha a geração em tempo real e formula objeções no momento em que a sugestão aparece, não semanas depois em PR. Custo medido em duas pessoas numa estação; retorno medido em revisão que disputa a decisão em vez de aprovar.
• Code walk-through registrado — explicação oral ou escrita do raciocínio, gravada em formato pesquisável (vídeo curto, ata estruturada, ADR). Exige 10-15 minutos por entrega relevante; evita reconstrução do contexto meses depois.
• Documentação inline no código — comentários que respondam “por que” e não “o que”, apoiados em referência a issue, RFC ou ADR. Não substitui documentação externa; complementa.
• Testes como documentação executável — cobertura de cenários nomeados de acordo com o comportamento esperado, não com o método. O teste documenta a intenção; o nome do teste cita a propriedade do sistema.
• Rotação planejada de domínios — cada desenvolvedor transita por área diferente do sistema a cada quarter, garantindo que conhecimento crítico tenha mais de uma custódia.

Conhecimento gerado por IA não é propriedade intelectual do desenvolvedor que pediu. É ativo da equipe, e distribuí-lo é parte do contrato assumido ao usar a ferramenta. A responsabilidade do desenvolvedor com código gerado por IA começa no momento em que outro membro do time precisa dar manutenção no sistema sem conseguir.

Mentoria como transferência ativa de processo (não de código)

Desenvolvedor sênior que usa IA tem responsabilidade adicional: ensinar desenvolvedor pleno a usar bem. O erro frequente é tratar mentoria como “mostrar o código gerado” e supor que a revisão preenche a lacuna. Não preenche. O que precisa ser transferido é o processo que levou àquela geração, em quatro camadas:

• O pedido — o que foi solicitado à IA, em que sequência, com que contexto. Por que a forma do prompt foi aquela; o que se deixou de fora e por quê.
• A resposta — o que a IA devolveu, em que variações, em quantas iterações. Quais saídas foram rejeitadas e por quê.
• O critério de aceitação — por que a versão final é considerada boa. Que sinais foram procurados; que sinais foram considerados descartáveis.
• O mecanismo de validação — como o código foi testado, em que ambientes, com que cobertura. Que cenário não foi coberto e por que o risco residual foi aceito.

Quando pleno gera com IA, sênior revisa o processo de geração, não o resultado. Perguntas que viraram úteis na revisão: “o que você pediu primeiro?”, “o que veio de resposta e o que você rejeitou?”, “como você sabe que essa é a versão boa e não a primeira aceitável?”, “como você vai validar amanhã se isso quebrar?”. As quatro perguntas, em sequência, cobrem a cadeia de custódia. Sênior que responde essas quatro perguntas para si mesmo antes de aceitar sugestão de IA captura o método; pleno que responde para sênior aprende a auditar.

A prática oposta — “confia no código, está testado” — transfere snippet sem método. Pleno que recebe snippet sem método replica a forma sem a substância, e a próxima geração dele parte do mesmo atalho. A curva de aprendizado da equipe cai, mesmo com ganho individual de velocidade. Mentoria honesta é transferência ativa do processo decisório, com a granularidade necessária para que o próximo sênior da equipe não dependa mais do sênior original.

Dívida técnica explícita: a alternativa profissional ao “funcionou”

Quando IA gera código, há duas saídas profissionais: aceitar como está ou refatorar antes de merged. Se o time aceita como está, contraiu dívida consciente. A regra profissional é manter essa dívida declarada em formato audível. Cinco elementos sustentam o registro explícito:

• Issue dedicada — não comentário perdido em PR; issue com label `debt` ou `tech-debt`, vinculada ao código por path.
• Descrição do impacto — o que fica ineficiente, em que métrica (latência, cobertura, complexidade ciclomática, churn), em que horizonte.
• Condição de refatoração — gatilho objetivo que decide quando o trabalho volta: cobertura abaixo de X%, nova feature que toque o mesmo módulo, incidente correlacionado, dois membros do time pedindo revisão.
• Estimativa de retorno — não prazo mágico, mas ordem de grandeza: “duas horas por dev”, “um sprint dedicado”, “recurso de Q3”.
• Dono declarado — quem é responsável por revisitar a decisão, em que data. Sem dono, a dívida volta à lista do “ninguém”.

Dívida invisível é pior que dívida visível. Em organizações que tratam IA como acelerador sem processo, a dívida se acumula em comentários `// TODO`, em branches desatualizados, em código que todo mundo sabe que tem problema mas ninguém consegue articular. A única defesa contra esse acúmulo silencioso é registro público, datado, vinculado a caminho concreto no código. Ferramentas como `debt.md`, arquivos `KNOWN_ISSUES.md` no diretório do módulo, ou tickets com label dedicada resolvem.

A relação entre rigor com IA e dívida técnica é direta: código gerado por IA tem taxa de aceitação maior (sugestão parece boa e desenvolvedor entrega mais rápido), taxa de refatoração menor (custo marginal de aceitar é menor), e taxa de compreensão posterior menor (código complexo fora do repertório do autor). Sem registro explícito, a dívida acumula sem que ninguém decida conscientemente. A prática de registrar é intervenção de governança, não higiene opcional.

Domínio antes da ferramenta: competência como pré-requisito

Não há sentido técnico em usar IA para gerar código em área que o desenvolvedor não compreende. O exemplo didático aparece em código de criptografia: pedir para IA implementar primitiva de cifragem sem conhecer o ataque de padding oracle, sem conhecer a diferença entre AES-CBC e AES-GCM, sem conhecer gestão de vetor de inicialização, gera código que parece correto e falha em produção de formas não detectáveis por teste unitário. O custo de um erro nessa classe não é refatoração; é incidente de segurança com notificação a regulador.

A regra profissional nessa frente é simples e em duas camadas:

• Se não entende o domínio, não peça para IA gerar. Pergunte em fórum, leia documentação canônica, faça curso, converse com especialista. Quando chegar ao ponto de entender o problema, use IA como ferramenta de aceleração, não como substituto da compreensão.
• Se precisa do código imediatamente, aprenda o domínio em paralelo. Tempo gasto estudando é custo, mas é custo de mão única; tempo gasto depurando código de criptografia que se revelou errado é custo composto.

A regra oposta — “IA faz mais rápido, e a aceitação sai sem custódia” — produz duas classes de problema. A primeira é o código produzido ser incorreto, o que se manifesta como bug funcional ou como brecha de segurança. A segunda é o desenvolvedor não ter repertório para detectar a incorreção, o que se manifesta como confiança indevida em revisão que não aprova nem rejeita — apenas carimba.

A posição correta da IA nessa frente é: ferramenta de aceleração para quem já tem o domínio, instrumento didático para quem está aprendendo o domínio sob supervisão de quem já tem, e jamais gerador autônomo para quem está fora do domínio. A frase operacional: *”você não pode revisar criticamente código que não compreende; portanto, não pode aceitar código que não compreende sem que essa aceitação seja, em si, ato de negligência.”*

A responsabilidade do desenvolvedor com código gerado por IA exige competência prévia no domínio da mudança. Sem competência, aceitação é formalidade, e formalidade sem custódia é a estrutura da falha. Desenvolvedores em início de transição para nova área precisam de combinação explícita de mentoria sênior mais revisão adicional, mais testes de cobertura mais ampla, mais restrição de blast radius. Sem essa combinação, o ganho de velocidade da IA é inversamente proporcional à segurança do código produzido.

Accountability sem disfarce: “IA sugeriu” não é desculpa

Quando se delega uma decisão técnica a um terceiro — humano ou máquina — não se transfere a responsabilidade; muda-se a forma como ela se manifesta. Antes da IA generativa, a cadeia era: o desenvolvedor escreveu, revisou e assinou o commit. Com IA generativa, a cadeia é: o desenvolvedor pediu, escolheu entre alternativas, validou e aceitou. Cada um dos quatro elos permanece sob custódia humana. “IA sugeriu” é descrição do caminho, não absolvição da decisão.

Três marcadores distinguem accountability profissional de aceitação passiva:

• Pedido verificável — prompt ou instrução que originou a sugestão está em log, PR, comentário de código, ou descrição de commit. Sugestão sem origem conhecida é caso perdido na auditoria.
• Escolha documentada — alternativas oferecidas pela IA foram comparadas em algum momento, mesmo que em rascunho interno. Decisão registrada antes de merged elimina a possibilidade de alegar, em post-mortem, que a escolha aconteceu sem custódia do desenvolvedor.
• Validação rastreável — testes que sustentam a aceitação estão em CI, com nome que cita a propriedade testada. Validação que vive só em commit local não conta como validação no momento em que o incidente ocorre.

A regra que fecha essa frente é a mais dura e mais clara: “IA sugeriu” não é desculpa em post-mortem. Em organizações que adotaram IA generativa em desenvolvimento como prática regular, o desvio frequente é tratar sugestão como atenuante. Não é. Sugestão que passou pelo crivo do desenvolvedor é código do desenvolvedor. Sugestão aceita sem crivo é negligência do desenvolvedor. Os dois casos são falha, em gradações distintas.

Cultura de accountability nessa frente se constrói com três práticas de equipe: (i) post-mortem que cita o prompt quando a causa raiz é rejeitada por validação fraca, (ii) revisão de PR que pergunta “como você validou isso” antes de aprovar, (iii) rito de compartilhamento de falhas induzidas por IA em ambiente controlado (workshop interno, post de lição aprendida, experimentação documentada). O que se combate é a normalização da aceitação sem custódia — o “tudo funcionou em dev” que vira incidente em produção.

Desenvolvedor que assume responsabilidade do desenvolvedor com código gerado por IA integralmente sabe três coisas: o que pediu, o que escolheu, o que validou. Saber essas três coisas é o mínimo profissional a partir de 2024; não saber é a fratura que o próximo incidente vai expor.

A frase operacional final: “não é ‘IA falhou’. É ‘o uso de IA foi inadequado'”. Essa mudança de mentalidade reorganiza toda a cadeia de custódia técnica — do prompt à revisão em produção, da mentoria ao post-mortem. Ferramenta é instrumento; responsabilidade é do operador.

A responsabilidade do desenvolvedor com código gerado por IA tem, portanto, cinco frentes operáveis que se reforçam mutuamente: distribuição de conhecimento, mentoria de processo, dívida técnica explícita, domínio como pré-requisito e accountability sem disfarce. Cada frente isolada é útil; as cinco em conjunto formam o sistema mínimo de governança que separa uso profissional de uso negligente.

Leitura relacionada

• Iteração com IA não é “até parecer certo”. É ciclo estruturado de refinamento — post anterior da série rigor; formaliza o ciclo iterativo pedido-resposta-validação que organiza todo uso responsável de IA em geração.
• Você não pode debugar o que não entende. Por que compreensão é a prática número um com IA — preenche a prática nº 1 mencionada neste post: a leitura crítica do código gerado antes da aceitação é o que sustenta todas as outras quatro frentes de responsabilidade.
• Seu processo de validação de código com IA é inadequado. Aqui está por quê e o que fazer. — detalha a cerimônia de validação que vem imediatamente antes da responsabilidade deste post; sem validação robusta, accountability é formalidade vazia.