Você é o arquiteto, a IA é a construtora

Quando você constrói com IA, você é o arquiteto e a IA é a construtora. Você é dono de toda decisão que sai cara mudar depois — quais dados existem, como se conectam, quem pode ver o quê, que qualidade vai para o ar. A IA executa essas decisões em código. Borre essa linha e, cedo ou tarde, seu produto desaba.

Este é o modelo mental que decide se as ferramentas de programação com IA vão tornar você perigoso ou livre. Não é "a IA é a desenvolvedora e eu sou o gerente de produto". Não é "estamos programando juntos, como parceiros". Você projeta. A IA constrói. Aprendi essa divisão do jeito caro — a história de origem, incluindo o precipício dos três meses em que produtos feitos com IA morrem em silêncio, está em a armadilha do vibe coding. Este post é a metade prática: exatamente quais decisões são suas, quais são da IA e os momentos em que você precisa dizer não.

O que "você é o arquiteto" significa na prática?

Pense na construção de uma casa. O arquiteto toma as decisões que afetam a estrutura inteira: onde a casa fica no terreno, quantos andares, que fundação, onde ficam as paredes estruturais, por onde passam a água e a eletricidade. Essas decisões não mudam fácil depois que a obra começa. A construtora executa essa visão — faz a fundação exatamente como especificado, levanta as paredes conforme a planta. A construtora é extremamente habilidosa. Mas ela executa um plano; não o cria.

Agora diga a uma construtora "me faz uma casa" sem planta nenhuma. Você vai receber alguma coisa. Pode até ficar de pé e parecer bonita no começo. Mas a fundação não vai aguentar o segundo andar que você vai querer depois, e o encanamento vai estar no lugar errado para a sua cozinha. Você ganha uma estrutura que funciona até precisar fazer algo para o qual não foi projetada. Isso, numa frase, é a maior parte do software feito com IA.

A matriz de decisões: o que é seu, o que é da IA

Aqui está a divisão de trabalho, na prática. Tudo à esquerda é seu. Tudo à direita é delegado:

Repare no que falta na coluna da IA: uma única decisão. A IA propõe; você dispõe. E a decisão de arquiteto com maior alavancagem de todas é desenhar seus dados antes das suas telas — esse método tem um post só dele: desenvolvimento database-first.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

Os três chapéus de todo arquiteto solo

Chapéu um: arquiteto de sistemas. Você decide o formato dos dados. Quais entidades existem, como se conectam, se cada registro está marcado com o cliente a quem pertence, que histórico é guardado. São perguntas de negócio vestidas de técnicas — e você conhece o seu negócio melhor do que qualquer IA.

Chapéu dois: gerente de produto. Você decide o que é construído e, mais importante, o que não é. Fundações antes de funcionalidades. Nada de "seria legal ter" na versão um. As prioridades são suas: login antes de analytics, analytics antes de qualquer coisa avançada. A IA vai construir alegremente o que você pedir, em qualquer ordem — e é exatamente por isso que a ordem precisa vir de você.

Chapéu três: garantia de qualidade. Você decide se o trabalho está bom o suficiente. Segue os seus padrões? É seguro? Vai sobreviver a clientes reais? É você quem diz "isso cria dívida técnica, refaz" — e quem diz "isso está pronto para produção, pode lançar".

Cinco momentos em que a IA vai testar você — diga não

A IA vai sugerir coisas que parecem inteligentes e violam a sua arquitetura. Cinco sinais devem provocar uma parada automática:

1. "Para simplificar..." — tradução: "deixa eu criar dívida técnica". Simplicidade agora é complexidade depois. Insista na estrutura correta.
2. "Por questão de desempenho..." — exija evidências. Se não há um problema medido, não há nada para otimizar. Otimização prematura é como sistemas limpos apodrecem.
3. "Uma correção rápida..." — gambiarras viram permanentes. Diga não e peça a causa raiz.
4. Embutir listas de opções no código. Status, categorias, tipos — a IA adora deixar isso fixo no código. Mantenha como dados editáveis, para poder adicionar ou renomear opções sem mexer no código.
5. Enfiar registros relacionados num único campo genérico. Se os dados são relacionados, precisam de um relacionamento de verdade — para poderem ser buscados, conectados e verificados. Um blob não faz nada disso.

Cada um desses apareceu enquanto eu construía o FIKR Space. A IA queria listas de status fixas no código; eu obriguei que virassem dados editáveis. A IA queria valores duplicados "por questão de desempenho"; eu insisti numa fonte única da verdade, com mais de 90% das tabelas totalmente normalizadas e cada exceção documentada. Dizer não não era algo ocasional. Era o trabalho.

Como arquitetos falam com a IA

Compare dois prompts. Quem faz vibe coding escreve: "Crie uma página de perfil de usuário." Agora a IA precisa adivinhar que dados mostrar, de onde eles vêm, o que é editável e que padrão seguir. Ela vai adivinhar diferente a cada vez, e seu produto vira uma colcha de retalhos de palpites.

O arquiteto escreve a planta: quais fontes de dados alimentam a página, quais seções aparecem, exatamente o que o usuário pode editar, que permissão isso exige, quais componentes existentes reaproveitar e como o carregamento e os erros se comportam. A mesma funcionalidade. Mas agora a IA sabe exatamente o que construir e como — e o resultado combina com tudo o que você já construiu. O prompt parece uma planta porque é uma.

Os três níveis de pensamento arquitetural

Nível um — funcionalidade: "Preciso de um dashboard, então vou construir um dashboard." Uma funcionalidade de cada vez, sem pensar em como elas se conectam. Esse é quem faz vibe coding.

Nível dois — produto: "Estou construindo um produto com usuários, equipes e projetos — como eles se relacionam?" Melhor. Os relacionamentos são projetados. Mas escala e segurança ainda ficam para depois.

Nível três — sistema: "Estou construindo algo que precisa isolar os dados de cada cliente, manter trilhas de auditoria, sobreviver ao crescimento e aceitar novas funcionalidades sem retrabalho." Escala, segurança e consistência são decididas no primeiro dia.

O nível três é onde você precisa operar — e ele não exige diploma em ciência da computação. Exige pensar em sistemas, que é exatamente o que profissionais corporativos experientes fazem todo dia. Seus anos vendo sistemas de grandes empresas darem certo e errado são a sua qualificação.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

Perguntas frequentes

Quais decisões eu nunca devo delegar à IA?

Tudo o que sai caro mudar depois: como seus dados são estruturados e relacionados, quem pode acessar o quê, os padrões que tudo segue, o que é construído e em que ordem, e o nível de qualidade para lançar. A IA executa essas decisões de forma brilhante. Ela nunca deveria tomá-las.

Preciso ser técnico para atuar como arquiteto?

Não. Decisões de arquitetura são decisões de negócio disfarçadas: que coisas existem no seu sistema, como se relacionam, que regras valem, quem vê o quê. Você as descreve em linguagem simples; a IA as traduz em código. Conhecimento do domínio importa muito mais do que saber programar.

O que acontece se eu deixar a IA tomar as decisões de arquitetura?

Funciona — no começo. Depois os padrões se desviam, o mesmo fato mora em três lugares e se contradiz, os dados dos clientes não ficam devidamente isolados, e cada nova funcionalidade fica mais difícil de adicionar. No fim, você reconstrói. As decisões do arquiteto são justamente as que a IA elimina para otimizar.

Como dizer não a uma sugestão da IA?

Seja específico, não vago. Diga o que está errado, explique por que está errado, diga exatamente o que você quer no lugar e peça para ver implementado. "Isso está errado, conserta" não ensina nada à IA; uma correção precisa entrega trabalho com qualidade de produção de primeira.