Design de software AI-first a partir de primeiros princípios: guia para quem constrói

A maioria dos times adotou a IA sem revisar uma única premissa por baixo, e por isso o resultado ficou mais rápido e os sistemas piores.

Esta é a pergunta que a maioria dos times de engenharia ainda não disse em voz alta: se o modelo pode escrever o código, em que exatamente devemos ser bons agora?

As respostas que ouço são majoritariamente defensivas. Engenharia de prompts. Revisar a saída da IA. Saber a qual ferramenta recorrer. Todas habilidades reais, todas consequência da mudança de fundo, e nenhuma explica o que vejo repetidamente na prática: times que adotaram as mesmas ferramentas, no mesmo trimestre, com os mesmos modelos, terminando em lugares completamente diferentes. Um grupo lança mais rápido e o software aguenta. O outro lança mais rápido e passa o trimestre seguinte descobrindo o que quebrou.

As mesmas ferramentas. Resultados opostos. Essa diferença não vem do modelo.

O amplificador que ninguém contabilizou

O relatório State of AI-assisted Software Development da DORA de 2025 colocou números nisso. 90% dos profissionais de tecnologia já usam IA no trabalho, e mais de 80% acreditam que ela aumentou sua produtividade. As duas coisas não surpreendem. O achado que importa é o terceiro: uma maior adoção de IA está associada a um aumento do desempenho de entrega de software e a um aumento da instabilidade dessa entrega, ao mesmo tempo.

Leia de novo, porque é o argumento todo. A ferramenta deixou os times mais rápidos ao lançar e piores ao manter as coisas funcionando. Não uma coisa ou outra. As duas.

O enquadramento da DORA é que a IA é um amplificador: ela magnifica qualquer prática sobre a qual aterrissa. Sistemas fortes ficam mais fortes. Sistemas fracos ficam mais rápidos em ser fracos.

O que significa que a pergunta interessante nunca foi “como adotamos a IA”. Era “o que a IA amplifica em nós”. E responder isso exige recuar mais que qualquer decisão de ferramenta.

Raciocine a partir do problema, não da ferramenta

Pensar a partir de primeiros princípios é uma dessas frases que foi repetida até perder o sentido, então vou ser concreto sobre o que quero dizer com ela e o que não.

Raciocinar por analogia é com o que a maior parte da adoção de IA se pareceu. Tínhamos um fluxo de trabalho de desenvolvimento. Chegou uma capacidade nova. Perguntamos onde a capacidade se encaixa no fluxo, a adicionamos no ponto de menor resistência (normalmente a escrita de código) e deixamos todo o resto igual. Reuniões diárias, tickets, sprints, revisão, tudo preservado. O fluxo foi tratado como um dado e a ferramenta foi ajustada a ele.

Raciocinar a partir de primeiros princípios coloca uma pergunta mais dura. Reduza o processo ao que é realmente, fisicamente verdadeiro sobre construir software. Depois pergunte quais dessas verdades o modelo mudou e quais ele não tocou. Reconstrua a partir do que sobrevive.

Faça isso com honestidade e você descobre que a IA mudou exatamente uma coisa, e não é a que a categoria vem vendendo.

O custo de produzir código foi a quase zero. O custo de decidir qual deveria ser o código não se moveu.

Tudo o que é útil decorre dessa única assimetria. Abaixo estão as quatro consequências que eu gostaria que qualquer pessoa que constrói pudesse enunciar de memória.

Um: o modelo de dados é o produto

A tela é a parte mais volátil de qualquer aplicação e o lugar mais tentador para começar, porque é a parte que se pode ver. É também a parte que deveria ser a mais barata de jogar fora.

O modelo de dados é o oposto. Ele decide o que você pode perguntar, o que pode indexar, o que pode mudar depois sem uma migração que assuste todo mundo. Toda capacidade posterior é limitada por decisões tomadas, ou improvisadas, nessa camada.

Quando o código era caro, essa ordem se impunha sozinha. Ninguém escrevia cem telas à mão contra um esquema que não havia pensado, porque escrever cem telas à mão levava um trimestre. A geração eliminou essa barreira natural. Agora você pode produzir uma interface inteira contra um modelo de dados que nenhuma pessoa revisou, e vai parecer pronta.

Então a ordem precisa se tornar deliberada. Modelo primeiro, depois contrato, depois interface. Não porque seja o tradicional, mas porque é a única ordem em que as decisões caras são tomadas enquanto ainda são baratas de mudar.

Dois: uma decisão adiada é tomada de qualquer forma

Esta é a que mais se subestima.

Toda decisão que você não toma explicitamente é tomada de qualquer forma. É tomada pelo gerador, no momento de gerar, a partir de um contexto que não inclui seu negócio, sua superfície de conformidade, seu histórico de migrações nem seus planos para o próximo trimestre. O modelo não se recusa a decidir. Ele escolhe algo plausível e segue.

O que um usuário com a assinatura cancelada ainda pode ver? O que acontece quando duas pessoas editam o mesmo registro? Um endereço de e-mail é único, e único em relação a quê? Ninguém fez essas perguntas em um prompt, então ninguém as respondeu, e a aplicação agora tem uma resposta para as três, escolhida por inferência, descobrível apenas ao bater nela em produção.

Esse é o mecanismo atrás do que as comunidades de construtores batizaram como o problema dos 70%. O progresso empaca não porque o trabalho restante seja difícil, mas porque está bloqueado por decisões tomadas em silêncio, várias centenas de gerações antes, que já não podem ser mudadas sem desmontar tudo.

A prática que conserta isso já tem nome: desenvolvimento guiado por especificação. Escreva primeiro os requisitos, as restrições e os critérios de sucesso. Trate esse documento como a fonte da verdade. Deixe o agente construir contra ele. O GitHub publicou o Spec Kit, a AWS publicou o Kiro, e a convergência não é coincidência.

Três: quando gerar é grátis, as restrições precisam ser escritas

Por décadas, a correção foi sustentada em parte pelo custo de escrever código. Quem implementava uma regra precisava sustentar a regra na cabeça. O conhecimento tácito em uma cabeça humana era um lugar aceitável para armazenar uma restrição, porque sempre havia uma pessoa no circuito.

Esse lugar de armazenamento já não funciona. Se uma restrição não está expressa em algum lugar legível por máquinas (uma restrição de esquema, um tipo, uma regra de validação, um teste, uma linha explícita em uma especificação) ela não existe no que concerne ao gerador. Existe apenas na memória de quem está a ponto de se surpreender.

Esse é o núcleo prático do design AI-first, e não tem nenhum glamour. Empurre os invariantes para baixo, para a camada que pode aplicá-los. Not-null e unique no banco de dados, não em um manipulador de formulário. Tipos nas fronteiras, não em um comentário de código. Autorização como uma política que o sistema avalia, não como uma condição que alguém lembrou de escrever em um endpoint.

Cada restrição que você externaliza é uma decisão que o modelo já não pode errar.

Quatro: agora você constrói para dois consumidores

A última é a mais nova, e a que a maioria dos times não internalizou de forma alguma.

Sua aplicação agora tem dois tipos de usuário. Um é uma pessoa olhando uma tela. O outro é um agente chamando uma API, que nunca vê sua interface e não pode ser persuadido por bom design. Se uma capacidade existe na sua interface mas não na sua API, então, no que concerne à economia dos agentes, ela não existe.

Isso tem uma consequência de design: a paridade não é um extra desejável. Qualquer coisa que uma pessoa possa fazer através da interface deveria ser alcançável através de uma superfície definida, documentada e descobrível. É também por isso que o GraphQL se encaixou melhor que o REST para o consumo por agentes: um esquema autodescritivo é algo que uma máquina pode explorar sem que uma pessoa escreva antes notas de integração.

Construa para o agente e a interface humana se simplifica como efeito colateral. Construa só para a pessoa e você vai acabar encaixando retroativamente uma API sob pressão de prazo, que é o pior momento possível para projetar uma.

Como pular isso aparece nos dados

A GitClear analisou 623 milhões de mudanças de código entre 2023 e 2026, e o quadro de manutenibilidade é consistente com tudo o que está acima.

Contra a linha de base de 2023, os blocos de código duplicados estão 81% acima. O copiar e colar dentro de um mesmo commit subiu de 9,4% em 2022 para 15,7% no primeiro semestre de 2026. As construções que mascaram erros estão 47% acima. Enquanto isso, as chamadas de função entre arquivos (o sinal mais claro disponível de reutilização de código) estão 35% abaixo, e a atividade de refatoração despencou de 21% das mudanças em 2022 para 3,8% no que vai de 2026.

Quem desenvolve tem agora cerca de cinco vezes mais probabilidade de copiar e colar do que de refatorar. Em 2022 essa proporção ia no sentido contrário.

Nada disso é um problema de qualidade do modelo. Duplicação em vez de reutilização, tratamento de erros que os engole em vez de trazê-los à superfície, refatoração que para de acontecer: é isso que você obtém quando gerar é barato e a estrutura não é o trabalho explícito de ninguém. O resultado é localmente plausível e globalmente incoerente, que é precisamente o modo de falha que um fluxo que começa pela tela não consegue detectar.

Como trabalhar assim, começando esta semana

Nada disso exige uma reorganização. Exige mudar a ordem de quatro ou cinco hábitos.

1. Escreva o modelo de dados antes da primeira tela. Entidades, relações, cardinalidade, o que torna uma linha única, o que se propaga ao excluir. Uma hora aqui é a hora de maior alavancagem do projeto, e é a que as ferramentas ativamente convidam você a pular.
2. Faça da especificação o artefato que você revisa, não o diff. Se a especificação está certa e a geração é fiel a ela, revisar milhares de linhas de código gerado é teatro. Revise o documento que as produziu. Discuta sobre a especificação enquanto discutir ainda é barato.
3. Externalize toda restrição que você conseguir nomear. Antes de gerar, liste as regras que nunca devem ser violadas e coloque cada uma em algum lugar onde o sistema as aplique. Tudo o que ficar em uma conversa vai acabar sendo violado por algo que nunca participou dessa conversa.
4. Projete a API como a superfície do produto. Depois trate a interface humana como um dos seus consumidores. Isso é mais uma decisão de sequência que de engenharia, e sequenciar tarde é o que a torna caro.
5. Instrumente para a instabilidade, não só para o desempenho. O achado da DORA é que velocidade e fragilidade subiram juntas, então medir apenas a velocidade vai te mostrar a metade boa da sua própria tendência. A taxa de falhas por mudança e o tempo de restauração são os números que dizem se o amplificador está trabalhando a seu favor.

Quanto isso custa

Quero ser direto sobre o compromisso em vez de fingir que ele não existe.

Trabalhar assim é mais lento na primeira semana de um projeto e sensivelmente mais rápido em todas as semanas seguintes. Esse é um custo real, pago adiantado, exatamente no momento em que o impulso parece mais valioso e um concorrente está lançando algo visível. Vão existir sprints em que o time que pulou tudo isso parece estar ganhando.

Também não é grátis em disciplina. Escrever restrições é menos divertido que ver uma interface aparecer. Revisar uma especificação é menos satisfatório que revisar código. Esses hábitos se degradam sob pressão de prazo, que é a mesma pressão que os faz importar.

E parte disso genuinamente não se aplica. Se você está validando uma ideia neste fim de semana com intenção de jogar o resultado fora, jogue fora: nada do que está acima vale a pena para software com dois dias de vida. O argumento aqui é sobre as aplicações que sobrevivem à própria demonstração.

A parte que nunca foi automatizável

Alguns papéis construídos em torno da produção de código vão encolher. Alguns vão desaparecer. Fingir o contrário não ajuda ninguém a se preparar, e quem te diz que todo posto de engenharia está seguro não está te fazendo nenhum favor.

Mas olhe o que a assimetria realmente fez. Ela automatizou a expressão das decisões e deixou as decisões em si completamente intactas. O que construir. O que não construir. Quais invariantes se sustentam. O que o sistema nunca deve fazer. Onde ficam as fronteiras e quem pode atravessá-las.

Esse trabalho sempre foi a parte difícil. Só estava escondido embaixo do trabalho de digitar, que era caro o suficiente para parecer o trabalho.

Digitar nunca foi o trabalho.

Leituras relacionadas

A prática em profundidade: desenvolvimento guiado por especificação. Se você está escolhendo uma ferramenta: os melhores construtores de aplicações com IA em 2026.

Perguntas frequentes

O que significa “design de software AI-first”? Projetar uma aplicação partindo da premissa de que a maior parte do código será gerada em vez de escrita à mão, e de que alguns consumidores serão agentes em vez de pessoas. Na prática significa que o modelo de dados, as restrições e o contrato da API são definidos explicitamente de antemão, porque essas são as decisões que a geração não pode tomar por você.

Em que o design AI-first é diferente de simplesmente usar ferramentas de IA para programar? Usar ferramentas de IA adiciona uma capacidade a um fluxo de trabalho inalterado. O design AI-first muda a ordem das operações do fluxo: modelo e contrato antes da interface, especificação como artefato revisado, restrições empurradas para camadas que as apliquem. A pesquisa da DORA de 2025 encontrou que a adoção de IA elevou ao mesmo tempo o desempenho e a instabilidade, que é o que acontece quando a ferramenta muda mas a prática não.

Quais são os primeiros princípios do design de software na era da IA? Quatro se sustentam: o modelo de dados é o produto e a tela é uma visão dele; qualquer decisão que você não tome explicitamente é tomada de forma implícita pelo gerador; as restrições precisam viver em algum lugar que uma máquina possa aplicar e não na cabeça de alguém; e sua aplicação agora serve tanto a uma interface humana quanto a uma API voltada a agentes, que precisam de paridade.

Projetar assim freia os times? Adianta o trabalho em vez de adicioná-lo. As decisões capturadas em um modelo de dados e em uma especificação são decisões que alguém toma de qualquer forma: ou deliberadamente no início ou de forma implícita por um modelo que adivinha depois. O segundo caminho é de onde vem o retrabalho, e retrabalho não é mais rápido.

Desenvolvimento guiado por especificação é o mesmo que design AI-first? Desenvolvimento guiado por especificação é a prática; design AI-first é o conjunto mais amplo de consequências arquitetônicas. A primeira cobre escrever a especificação e gerar contra ela. O design AI-first cobre também a ordem da modelagem de dados, onde as restrições são aplicadas e projetar para consumidores agênticos além dos humanos.

Quando está tudo bem pular tudo isso? Protótipos, demonstrações, coisas internas de uma vez só e qualquer coisa que você planeja descartar. A sobrecarga só vale a pena para software que precisa sobreviver a usuários reais, dados reais e mudanças no tempo.