Tu és o arquiteto, a IA é o construtor

Quando constróis com IA, tu és o arquiteto e a IA é o construtor. Tu és dono de todas as decisões que saem caras de mudar mais tarde — que dados existem, como se ligam, quem pode ver o quê, que qualidade vai para produção. A IA executa essas decisões em código. Esbate essa fronteira e, mais cedo ou mais tarde, o teu produto desaba.

Este é o modelo mental que decide se as ferramentas de programação com IA te tornam perigoso ou te tornam livre. Não é "a IA é o programador e eu sou o gestor de produto". Não é "estamos a programar juntos, como parceiros". Tu desenhas. A IA constrói. Aprendi esta divisão da forma cara — a história de origem, incluindo o precipício dos três meses onde os produtos construídos com IA morrem em silêncio, está em a armadilha do vibe coding. Este artigo é a metade prática: exatamente que decisões são tuas, quais são da IA e os momentos em que tens de dizer não.

O que significa realmente "tu és o arquiteto"?

Pensa na construção de uma casa. O arquiteto toma as decisões que afetam a estrutura inteira: onde fica a casa no terreno, quantos pisos, que fundações, onde ficam as paredes-mestras, por onde passam a água e a eletricidade. Essas decisões não se mudam facilmente depois de a obra começar. O construtor executa essa visão — faz as fundações exatamente como especificado, levanta as paredes de acordo com a planta. O construtor é incrivelmente competente. Mas o construtor executa um plano; não o cria.

Agora diz a um construtor "faz-me uma casa" sem plantas nenhumas. Vais ter alguma coisa. Pode até ficar de pé e parecer bonita ao início. Mas as fundações não vão aguentar o segundo piso que vais querer mais tarde, e a canalização vai estar no sítio errado para a tua cozinha. Ficas com uma estrutura que funciona até precisares que ela faça algo para que não foi desenhada. Isso, numa frase, é a maior parte do software construído com IA.

A matriz de decisão: que decisões são tuas e quais são da IA

Eis a divisão de trabalho, em concreto. Tudo o que está à esquerda é teu. Tudo o que está à direita é delegado:

Repara no que falta na coluna da IA: uma única decisão. A IA propõe; tu dispões. E a decisão de arquiteto com mais alavancagem de todas é desenhar os dados antes dos ecrãs — esse método tem um artigo próprio: desenvolvimento com a base de dados primeiro.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Os três chapéus de qualquer arquiteto a solo

Chapéu um: arquiteto de sistemas. Tu decides a forma dos dados. Que entidades existem, como se ligam, se cada registo está associado ao cliente a quem pertence, que histórico se guarda. São perguntas de negócio com roupa técnica — e tu conheces o teu negócio melhor do que qualquer IA.

Chapéu dois: gestor de produto. Tu decides o que se constrói e, mais importante ainda, o que não se constrói. Fundações antes de funcionalidades. Nada de extras na primeira versão. As prioridades são tuas: o login antes da analítica, a analítica antes de qualquer coisa avançada. A IA constrói de bom grado o que lhe pedires, por qualquer ordem — e é precisamente por isso que a ordem tem de vir de ti.

Chapéu três: controlo de qualidade. Tu decides se o trabalho está suficientemente bom. Segue os teus padrões? É seguro? Vai sobreviver a clientes reais? És tu quem diz "isto cria dívida técnica, refaz" — e quem diz "isto está pronto para produção, lança".

Cinco momentos em que a IA te vai pôr à prova — diz que não

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

1. "Por simplicidade..." — tradução: "deixa-me criar dívida técnica". A simplicidade de agora é a complexidade de depois. Insiste na estrutura correta.
2. "Por questões de desempenho..." — exige provas. Se não há um problema medido, não há nada para otimizar. A otimização prematura é a forma como os sistemas limpos apodrecem.
3. "Uma correção rápida..." — os remendos tornam-se permanentes. Diz que não e pede antes a causa de fundo.
4. Listas de opções gravadas no código. Estados, categorias, tipos — a IA adora fixá-los no código. Mantém-nos como dados editáveis, para poderes acrescentar ou renomear opções sem mexer no código.
5. Enfiar registos relacionados num único campo genérico (blob). Se os dados estão relacionados, precisam de uma relação a sério — para poderem ser pesquisados, ligados e verificados. Um blob não faz nada disso.

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

Como os arquitetos falam com a IA

Compara dois prompts. O vibe coder escreve: "Constrói uma página de perfil do utilizador." A IA tem agora de adivinhar que dados mostrar, de onde vêm, o que é editável e que padrão seguir. Vai adivinhar de maneira diferente de cada vez, e o teu produto torna-se uma manta de retalhos de palpites.

O arquiteto escreve a planta: que fontes de dados alimentam a página, que secções aparecem, exatamente o que o utilizador pode editar, que permissão isso exige, que componentes existentes reutilizar e como se comportam o carregamento e os erros. A mesma funcionalidade. Mas agora a IA sabe precisamente o que construir e como — e o resultado bate certo com tudo o resto que construíste. O prompt parece uma planta porque é uma.

Os três níveis de pensamento arquitetónico

Nível um — ao nível da funcionalidade: "Preciso de um painel, por isso vou construir um painel." Uma funcionalidade de cada vez, sem pensar em como as funcionalidades se ligam. Este é o vibe coder.

Nível dois — ao nível do produto: "Estou a construir um produto com utilizadores, equipas e projetos — como se relacionam?" Melhor. As relações são desenhadas. Mas a escala e a segurança continuam a ficar para depois.

Nível três — ao nível do sistema: "Estou a construir algo que tem de isolar os dados de cada cliente, manter registos de auditoria, sobreviver ao crescimento e aceitar novas funcionalidades sem retrabalho." A escala, a segurança e a consistência são decididas no primeiro dia.

O nível três é onde precisas de operar — e não exige uma licenciatura em informática. Exige pensar em sistemas, que é exatamente o que os profissionais corporativos experientes fazem todos os dias. Os teus anos a ver sistemas de grandes empresas terem sucesso e falharem são a tua qualificação.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

Que decisões nunca devo delegar na IA?

Tudo o que sai caro mudar mais tarde: como os teus dados são estruturados e relacionados, quem pode aceder a quê, os padrões que tudo segue, o que se constrói e por que ordem, e a fasquia de qualidade para lançar. A IA executa estas decisões de forma brilhante. Nunca as deve tomar.

Preciso de ser técnico para fazer de arquiteto?

Não. As decisões de arquitetura são decisões de negócio disfarçadas: que coisas existem no teu sistema, como se relacionam, que regras se aplicam, quem vê o quê. Descreves tudo isto em linguagem simples; a IA traduz para código. O conhecimento do setor conta muito mais do que saber programar.

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

Funciona — ao início. Depois os padrões desviam-se, o mesmo facto vive em três sítios e contradiz-se, os dados dos clientes não ficam devidamente isolados e cada nova funcionalidade fica mais difícil de acrescentar. No fim, reconstróis. As decisões do arquiteto são exatamente aquelas que a IA elimina ao otimizar.

Como digo que não a uma sugestão da IA?

Sê específico, não vago. Diz o que está errado, explica porque está errado, diz exatamente o que queres em vez disso e pede para ver isso implementado. "Isto está errado, corrige" não ensina nada à IA; uma correção precisa dá-te trabalho com qualidade de produção à primeira.