Português
Marcar conversa

Do protótipo feito com IA a um produto em que se pode confiar

Quase todos os fundadores que construíram um produto com ferramentas de IA conhecem este momento. Nas primeiras semanas os ecrãs aparecem depressa, os botões funcionam e há uma demonstração para mostrar aos investidores. Depois o produto cresce. Corrige-se um erro e deixam de funcionar outras duas coisas. Uma alteração pequena demora uma semana.

A sensação tem números por trás. E há uma solução que não obriga a abdicar da rapidez.

O código multiplica-se em vez de se organizar

A GitClear analisou 211 milhões de linhas de código alteradas entre 2020 e 2024. A percentagem de linhas copiadas e coladas subiu de 8,3% em 2021 para 12,3% em 2024. No mesmo período, a percentagem de linhas movidas, o sinal de que alguém está a reorganizar código existente, caiu de 25% para menos de 10%. Em 2024, pela primeira vez, os projetos tinham mais código copiado do que código reorganizado.

Num projeto construído em conversa com um agente de IA, isto acontece ainda mais depressa. O agente resolve o pedido que tem à frente e muitas vezes escreve código novo em vez de alterar o que já existe. Ficam assim dois sítios que fazem quase a mesma coisa. Uma correção num deles não chega ao outro, e é daí que vem o “corrigi aqui e partiu-se ali”.

Código que corre ainda não é código seguro

A empresa de segurança Veracode testa há quatro anos o código escrito por modelos de IA. No relatório que publicou em julho de 2026, sobre mais de 100 modelos, quase todo o código passou na verificação de sintaxe, ou seja, corria. Nos testes de segurança, só 56% passou, em média. Mesmo o melhor modelo do teste ficou nos 68%.

O exemplo mais conhecido vem das ferramentas para criar aplicações sem código. Em maio de 2025, o investigador Matt Palmer revelou que 170 das 1.645 aplicações apresentadas na galeria da Lovable, cerca de 10%, expunham dados de utilizadores: endereços de email, números de telefone, dados de pagamento e chaves de API. A causa era uma regra de permissões em falta ou mal configurada na base de dados. As aplicações funcionavam na perfeição. Simplesmente, qualquer pessoa podia ler os dados delas.

A produção não perdoa

Em julho de 2025, Jason Lemkin, fundador da SaaStr, documentou uma experiência de 12 dias a construir uma aplicação com o agente da Replit. No nono dia, o agente apagou a base de dados de produção, apesar de uma instrução explícita para congelar todas as alterações. Continha registos de 1.206 executivos e de cerca de 1.200 empresas.

As correções que a Replit anunciou a seguir mostram o que faltava: separação automática entre a base de dados de desenvolvimento e a de produção, um modo em que o agente apenas planeia e não executa, e reposição com um clique. Nada disto é complicado. São bases que uma equipa de desenvolvimento experiente monta antes de entrar o primeiro utilizador.

A sensação de rapidez pode enganar

Em julho de 2025, o instituto de investigação METR publicou um ensaio controlado com 16 programadores experientes e 246 tarefas reais. Com ferramentas de IA, as tarefas demoraram mais 19%. Antes do ensaio, os programadores esperavam que a IA os tornasse 24% mais rápidos, e mesmo depois acreditavam que lhes tinha poupado 20%. Em fevereiro de 2026, o METR relatou um novo ensaio com ferramentas mais recentes, em que o quadro já aponta para ganhos de rapidez, mas o próprio instituto considera essas provas muito fracas. A lição prática é simples: medir, em vez de confiar na sensação.

O relatório DORA de 2025 da Google Cloud, baseado em cerca de 5.000 profissionais, acrescenta a parte mais importante para quem funda uma empresa. O uso de IA está associado a entregas mais rápidas, mas também a menor estabilidade daquilo que é entregue. Segundo o relatório, a IA amplifica o que já existe na equipa. Com testes automáticos, controlo de versões e feedback rápido, acelera o trabalho. Sem isso, acelera também a desordem.

Uma especificação que conduz o código

A abordagem que está a ganhar espaço no setor chama-se Spec-Driven Development: desenvolvimento em que uma especificação escrita e aprovada conduz o trabalho, e o código decorre dela. Em setembro de 2025, o GitHub lançou um kit de código aberto chamado Spec Kit, que divide o trabalho em quatro fases: especificação, planeamento, tarefas e implementação. Em maio de 2026 já funcionava com mais de 30 agentes de IA diferentes. Em julho de 2025, a AWS lançou o Kiro, um ambiente de desenvolvimento construído em torno da mesma ideia e apresentado explicitamente como ponte entre o protótipo e a produção.

Vale a pena conhecer também as críticas. Em novembro de 2025, a consultora Thoughtworks colocou o método na categoria “Assess”, a de técnicas a avaliar, e avisou que as especificações podem sair longas e difíceis de rever. Uma especificação que ninguém lê não ajuda ninguém. Por isso, tem de ser curta o suficiente para o fundador a ler e aprovar, e precisa o suficiente para servir de referência aos testes do código.

Antes de chegarem utilizadores reais

Uma lista curta do que tem de estar resolvido antes de um produto entrar em produção:

  • Uma especificação escrita do que o produto faz hoje e do que deve fazer. Sem ela, nem sequer é possível decidir o que conta como erro.
  • Testes automáticos em torno dos fluxos críticos, como registo, pagamento e gravação de dados, que correm a cada alteração.
  • Separação total entre desenvolvimento e produção, e uma cópia de segurança a partir da qual já se fez uma reposição de teste.
  • Uma revisão de permissões na base de dados e nas APIs: quem pode ler o quê, e onde estão guardadas as chaves e as palavras-passe.
  • Um programador experiente que aprova cada alteração que mexe em dados, permissões ou pagamentos. O agente escreve, e uma pessoa responde pelo resultado.

Nem sempre é preciso reescrever

Há sinais claros de que chegou a altura de parar: cada correção estraga outra coisa, ninguém consegue explicar como os dados circulam no sistema, e há receio de publicar uma nova versão. Mesmo assim, recomeçar do zero não é a opção por defeito. Normalmente começa-se por especificar o que existe, envolve-se em testes aquilo que tem de continuar a funcionar, e só depois se arruma o código, parte a parte. Assim, o produto continua a servir os utilizadores enquanto estabiliza.

Perguntas frequentes

O código escrito com IA é pior do que o código escrito por um programador?
Não necessariamente. O problema é o código que ninguém verificou. Segundo a Veracode, quase todo o código que os modelos escrevem corre, mas perto de metade falha nos testes de segurança. Um programador experiente, testes automáticos e uma revisão de segurança fecham a maior parte dessa diferença.
É preciso trocar a ferramenta com que o protótipo foi construído?
Na maioria dos casos, não. A ferramenta importa menos do que ter especificação, testes e ambientes separados. Tudo isso pode ser acrescentado a um projeto existente.
O que é Spec-Driven Development numa frase?
Desenvolvimento em que primeiro se escreve e aprova o que o sistema deve fazer, e só depois se escreve código, mesmo quando são agentes de IA a escrevê-lo. A especificação é a fonte, e o código é testado face a ela.
Quanto tempo demora a estabilizar um protótipo antes do lançamento?
Depende da dimensão do produto e do estado do código, por isso só é possível dar um número fiável depois de especificar o que já existe. Quem dá um número vinculativo antes disso está a adivinhar.

Fontes

Quer falar sobre isto no contexto do seu sistema? Marque uma conversa gratuita de uma hora.