Criador de apps com IA vs agente de programação com IA: o que as equipas sérias precisam de saber

O mercado fala de "ferramentas de desenvolvimento com IA" como se fossem uma coisa só. São pelo menos duas. Um criador de apps com IA é um produto em que descreve uma aplicação em linguagem simples e recebe uma aplicação em execução, interface, lógica, base de dados, alojamento, tipicamente dentro do ambiente do fornecedor, iterada por chat e edição visual. O utilizador principal não precisa de ser programador, e a unidade de resultado é uma app. O Lovable, o Bolt, o Base44, o v0 e a experiência de geração de apps do Replit situam-se, em termos gerais, nesta categoria, cada um com a sua ênfase.

Um agente de programação com IA é uma ferramenta que um programador aponta a uma base de código. Lê o repositório, planeia alterações, escreve e edita código, corre comandos e testes, e produz diffs. Num editor, num terminal ou anexado a um ticket. O utilizador principal é alguém capaz de avaliar código, e a unidade de resultado é uma alteração. O Cursor, o Claude Code e o OpenAI Codex são os exemplos mais conhecidos. O pressuposto da categoria é que a maquinaria circundante, repositório, CI, revisão, implementação, já existe e é sua.

Nenhuma das categorias é o substituto barato da outra, e os rótulos vão-se esbatendo à medida que os fornecedores se expandem. Por isso, avalie a capacidade, não o substantivo de marketing: quem a opera, o que consome, o que emite e o que acontece a esse resultado a seguir. A última pergunta, o que acontece a seguir, é a que a maioria das avaliações salta, e é onde as equipas de produção se magoam.

As duas categorias vêm também de linhagens diferentes, o que explica os seus instintos diferentes. Os criadores de apps descendem do no-code e dos criadores de sites: o seu ADN é a acessibilidade, o alojamento incluído, a complexidade escondida. Os agentes de programação descendem das ferramentas para programadores: o seu ADN é a transparência, a composição e a confiança no operador com arestas afiadas. Nenhuma das heranças é errada, mas nota-se em todo o lado. No que cada um assume sobre o seu utilizador, no que cada um mostra ou esconde, e no que cada um considera terminado. Conhecer a linhagem prevê o encaixe mais depressa do que qualquer lista de funcionalidades: diz-lhe se uma ferramenta vai servir as mãos em que realmente a planeia pôr.

A falha clássica corre nos dois sentidos. Uma equipa de negócio adota um criador de apps, lança uma ferramenta interna genuinamente útil, e dezoito meses depois a TI herda uma aplicação com utilizadores reais, sem suite de testes que alguém consiga ver, e sem histórico de revisão que satisfaça um auditor. Porque a ferramenta foi comprada pela velocidade, e velocidade foi o que ela entregou. No sentido inverso, uma organização de engenharia compra agentes de programação para todos, celebra o salto nos pull requests, e depois descobre que a revisão, o QA e a gestão de lançamentos se tornaram o estrangulamento, porque os agentes multiplicaram a produção em exatamente uma fase do ciclo de vida.

Ambas as falhas remontam à mesma raiz: a compra foi avaliada pela geração, e a dor chegou na entrega. O que uma ferramenta gera na primeira hora está visível na demonstração. Quem o testa, quem o aprova, onde é implementado, quem repara quando se parte às 2 da manhã. Nada disso está na demonstração, e é tudo aí que o software realmente ganha ou destrói confiança.

Há também um custo mais discreto: as equipas que escolhem uma categoria acabam muitas vezes por precisar das duas, mais cola. A ferramenta feita no criador acaba por precisar de controlo de alterações de nível de engenharia; a base de código acelerada por agentes acaba por precisar do empacotamento ao nível da app que o lado do negócio não pára de pedir. Orçamentar para a categoria que escolheu, em vez da capacidade de que precisa, é como a proliferação de ferramentas acontece.

Um terceiro custo é o teatro de avaliação. Como as categorias se demonstram de formas tão diferentes. Os criadores mostram uma app em minutos, os agentes mostram um diff em segundos. Os concursos que as pontuam numa única grelha produzem disparates confiantes. O criador vence na velocidade até à app, o agente vence na qualidade do código, e ninguém pontuou a dimensão que vai realmente doer: o que acontece a qualquer dos resultados a caminho da produção. Estruture a avaliação primeiro em torno da sua situação e só depois das ferramentas, ou as demonstrações estruturam-na por si. A correção é barata. Escreva o resumo da situação antes de assistir a uma única demonstração.

O Automo recusa deliberadamente o ou/ou. Começa como um criador. Descreva a app em linguagem simples, receba uma aplicação real em React, TypeScript e Supabase que é sua. Mas a geração fica dentro de um ciclo de entrega completo, e não ao lado de um. Cada workspace recebe uma organização de software com IA: CTO, Doctor, analista de QA, engenheiro de Segurança, Coder e operador de SysOps. O Guardrails aplica políticas em linguagem simples e regista a revisão humana com um registo de auditoria por trás de cada merge; o QA executa repetições determinísticas em navegador com smoke gates antes da publicação; o Security confirma vulnerabilidades contra a app ao vivo antes de as sinalizar.

Cobre também o lado dos agentes de programação da questão: as imagens de sandbox personalizadas envolvem a engenharia assistida por IA à volta de Rails, Java, Go, Python, Node e backends multi-processo, para que os sistemas existentes entrem no mesmo ciclo de vida em vez de viverem fora dele. O resultado é React, TypeScript e Tailwind padrão, exportável para o seu próprio repositório a qualquer momento, e os alvos de implementação incluem a nuvem Automo, a sua própria conta AWS, Azure ou GCP, uma VPC privada ou on-premise sob termos separados. Se a sua avaliação continua a concluir "precisamos dos dois, mais governança", essa combinação é a coisa a ver em demonstração. Os programas de desenvolvimento sérios começam em 10.000 USD por ano.

Na prática, o emparelhamento é comum, não excecional: a engenharia mantém os seus agentes de programação para o produto principal, as equipas próximas do negócio constroem na plataforma, e as políticas de governança, não as proibições de ferramentas, definem o que pode chegar à produção a partir de qualquer dos fluxos. A resposta da plataforma à questão das duas categorias é deliberadamente aborrecida. Use o modo de geração que servir o momento. Chat com o Builder, inspect-to-prompt sobre a app ao vivo, ou trabalho de agente dentro de uma sandbox personalizada num backend existente, e deixe o ciclo constante. O QA, o Security e o Guardrails não querem saber que modo produziu o diff; cada alteração encontra os mesmos gates e aterra no mesmo registo de auditoria. Consistência de escrutínio, não consistência de ferramentas, é o que uma organização realmente precisa de padronizar.