Construir com IA sem saber arquitetura: o que costuma quebrar lá pelo sexto mês

Construir com IA sem base de arquitetura quebra por volta do sexto mês. Cinco checagens que você faz sem ler código, o que cada resposta revela e o que fazer depois.

A quinta pergunta é a que ninguém consegue responder sem abrir o repositório

Se você está construindo um produto com IA e não sabe avaliar arquitetura, comece pela checagem mais barata que existe. Pegue uma máquina limpa, sem nada instalado, e tente subir o sistema do zero seguindo só o que está escrito no repositório. Cronometre. Se passar de umas duas horas, ou se só uma pessoa no mundo consegue fazer isso, você não tem um sistema de pé. Tem uma sessão de chat que por enquanto continua aberta.

Essa é a primeira de cinco perguntas que ficam no fim do texto, e nenhuma delas exige que você leia uma linha de código. Elas existem porque o problema de construir com IA sem base de arquitetura quase nunca aparece na semana em que o código nasce. Ele aparece perto do quinto ou sexto mês, numa cena bem específica: você precisa decidir alguma coisa, pede opinião para duas pessoas, e as duas respostas soam igualmente razoáveis para você.

Um texto sobre exatamente isso no dev.to juntou 70 reações e 51 comentários em poucos dias. O número de comentários é a parte interessante. Ninguém comenta guia de ferramenta. Gente comenta quando reconhece a própria semana descrita ali.

Eu já estive desse lado da mesa e nem sabia formular a pergunta

Máquina limpa, cronômetro ligado: a checagem mais barata de todas

Antes da Revin eu tive uma startup de locação de equipamentos para construção civil, formato aplicativo, aquele "Uber de escavadeira" que todo mundo tentou em algum momento. Eu vinha da engenharia mecânica e da montagem industrial. Sabia ler projeto, sabia cobrar medição, já tinha respondido tecnicamente pela estrutura metálica de um autódromo. Diante de um dev, eu ficava mudo.

Ele dizia que precisava reorganizar o módulo de reservas antes de fazer a tela nova. Eu tinha duas saídas: acreditar ou brigar sem um único argumento. Acreditava, sempre. E a sprint terminava sem a entrega esperada.

Levei perto de um ano para descobrir onde estava o meu erro. A resposta dele nunca foi o problema. O problema era a minha pergunta, que era sempre "quanto tempo leva". Voltei a programar por causa disso. A startup morreu por outros motivos também, mas essa parte eu poderia ter evitado.

A IA devolve essa mesma sensação para quem está começando agora, e devolve mais rápido. Você descreve o que quer, o código aparece, a tela abre, o botão funciona. Parece controle. É bem parecido com o que eu sentia saindo da reunião de sprint com uma data anotada no caderno.

O que quebra no sexto mês não acende alerta nenhum

O primeiro sintoma é a mudança pequena que atravessa o sistema inteiro. Você pede para trocar o texto de um e-mail de confirmação e a alteração passa por uns doze arquivos, porque a mesma regra foi escrita em cinco lugares diferentes em semanas diferentes. Cada pedaço funcionava quando nasceu. Juntos, eles não têm dono.

Depois vem a máquina. Existe um único jeito de subir aquilo, e esse jeito mora na cabeça de uma pessoa ou na pasta de downloads dela. Nada disso é técnico o suficiente para virar assunto de reunião, e é exatamente por isso que ninguém trata.

O terceiro é o mais caro e o mais silencioso: não existe rastro. Pergunte o que o sistema fez ontem e a resposta honesta será alguém abrindo o banco na mão para conferir. Se tem dado pessoal circulando ali, isso deixa de ser conforto de engenharia e passa a ser exposição, porque LGPD se resolve na arquitetura, não no formulário de consentimento.

O quarto você testa em dez minutos. Peça para alguém quebrar de propósito a regra que calcula o preço e rodar a bateria de testes. Se nada falhar, o que existe ali é teatro de qualidade: a métrica de cobertura existe, a garantia não.

"Mas está funcionando e o cliente está pagando"

Na montagem, a foto mostra o parafuso. Quem segura a estrutura é a planta

Essa objeção é justa, e eu ouço em quase toda conversa. Funcionar é o requisito mais fácil da lista. O que separa um produto de um protótipo caro é o preço da segunda mudança, e da terceira, e da mudança que o cliente pede na sexta à tarde.

O momento em que a conta chega costuma ser o primeiro cliente grande. Ele abre o contrato e pede login integrado ao diretório da empresa, registro de auditoria por usuário e um relatório que varre dois anos de histórico sem travar. Aí a arquitetura deixa de ser bastidor e vira o seu produto, com a diferença de que agora ela está sendo julgada por quem assina o cheque.

Uma digressão rápida, porque ela ajuda: em montagem industrial, a parte que aparece na foto é o parafuso. O que decide se aquilo fica de pé é a planta que ninguém mais abre depois da inauguração. Software funciona igual, com o agravante de que a planta pode simplesmente nunca ter existido.

O que fazer quando as cinco respostas vêm ruins

Reescrever do zero é o pedido que mais chega aqui, e é quase sempre o mais caro. Reescrita congela o produto por meses e devolve, no melhor cenário, o que você já tinha. Antes disso existem dois caminhos mais baratos.

O primeiro é comprar em vez de manter. Boa parte do que trava esses projetos é encanamento genérico: autenticação, cobrança recorrente, envio de e-mail, emissão de nota. Existe um jeito de decidir isso com cinco perguntas em vez de com opinião, e ele costuma apontar para fora de casa.

O segundo é colocar um sênior de verdade para revisar antes de montar time. Não uma contratação, uma revisão. Vale entender a faixa que isso custa antes de conversar com alguém, porque os valores de hora e salário no Brasil em 2026 variam muito mais do que a maioria imagina. Umas trinta horas de gente experiente lendo o que existe custam menos que um mês de reescrita conduzida no escuro.

Onde essa régua não serve

Se você está com três semanas para validar se alguém quer o que você imaginou, ignore quase tudo isso. Protótipo não precisa de rastro, de teste que testa, nem de segunda pessoa capaz de subir o sistema. Precisa provar que existe demanda, e rápido.

Também não sei dizer se a régua vale para ferramenta interna usada por quatro pessoas que se falam todo dia. Nesse tamanho, a documentação é o almoço. A partir do momento em que existe um cliente pagando e um servidor que não pode cair, ela passa a valer inteira.

As cinco perguntas, para levar impressas

1. Alguém que nunca tocou no projeto consegue subir o sistema numa máquina limpa em menos de duas horas, seguindo apenas o que está escrito no repositório?
2. Quando você pede uma mudança de texto ou de regra pequena, quantos arquivos são alterados, e por que mais de um?
3. Dá para responder o que o sistema fez ontem sem alguém abrir o banco de dados na mão?
4. Se alguém quebrar de propósito a regra que calcula preço, desconto ou permissão, algum teste falha antes de ir para produção?
5. Além da IA e de você, quem consegue explicar em voz alta por que aquela decisão de estrutura foi tomada?

A primeira resposta você já sabe

Você leu a lista e já sentiu qual das cinco vai doer. Não precisa de auditoria para descobrir isso, precisa de uma tarde reservada nesta semana e de alguém do lado com permissão para dizer que está ruim.

A pergunta que eu deixo é a que eu não soube fazer na minha startup, e que teria mudado o desfecho: se a pessoa que hoje sabe subir o seu sistema não atender o telefone por duas semanas, o que exatamente para de funcionar no seu negócio?