Em novembro de 2025, o Collins Dictionary escolheu «vibe coding» como palavra do ano e definiu-a como usar IA, instruída em linguagem natural, para ajudar a escrever código. A expressão pegou porque a experiência é real. Descreve-se uma aplicação, aceita-se o que o modelo escreve e no domingo à noite há um ecrã a funcionar. Um fundador pode agora mostrar uma demonstração a clientes antes de contratar um engenheiro.
O que não ficou mais barato foi a parte que torna o software fiável. No Stack Overflow Developer Survey de 2025, 66% dos programadores apontaram «soluções de IA que estão quase certas, mas não totalmente» como a sua principal frustração com ferramentas de IA, e 45% disseram que depurar código gerado por IA demora mais tempo. Um protótipo é o sítio onde quase certo chega. A produção é o sítio onde não chega.
Esta nota enumera o que a produção acrescenta a um protótipo, apresenta uma divisão aproximada do esforço e sugere como um responsável pelo orçamento deve tratar a demonstração que acabou de ver.
O ganho de velocidade é real, e continua por medir
A medição mais cuidadosa da velocidade de programação com IA vem do METR, uma organização de investigação sem fins lucrativos. O seu ensaio aleatorizado de 2025 concluiu que programadores open-source experientes demoraram mais 19% nas tarefas quando a IA era permitida, com um intervalo de confiança de +2% a +39%.
A 24 de fevereiro de 2026, o METR publicou um estudo de seguimento: 57 programadores, 143 repositórios, mais de 800 tarefas, realizado a partir de agosto de 2025. Na mesma escala de variação de tempo em que o resultado de 2025 foi +19%, as novas estimativas pontuais são -18% para os programadores que regressaram do primeiro estudo (intervalo de -38% a +9%) e -4% para os programadores recém-recrutados (intervalo de -15% a +9%). As duas estimativas pontuais inclinam-se agora para a IA poupar tempo. Os dois intervalos incluem o zero.
O próprio METR considera os novos dados um sinal pouco fiável. Entre 30% e 50% dos programadores disseram ter optado por não submeter algumas tarefas porque não queriam fazê-las sem IA. As tarefas em que a IA mais ajuda estão, portanto, ausentes da amostra, e o METR acredita que o verdadeiro ganho de velocidade é provavelmente maior do que a sua estimativa.
Para um comprador, a conclusão é restrita. A IA torna alguma programação mais rápida, numa medida que investigadores cuidadosos ainda não conseguiram fixar. Não muda aquilo de que um sistema precisa antes de as pessoas poderem depender dele.
O que um protótipo prova, e o que não prova
Um protótipo de fim de semana prova três coisas úteis: a ideia funciona com as entradas que alguém experimentou, a interface faz sentido para as pessoas que a viram, e alguém a quer.
Não prova que o sistema funciona com entradas que ninguém experimentou, que funciona para duzentas pessoas ao mesmo tempo, que mostra a cada pessoa apenas o que ela pode ver, que custa por mês o que se pensa, nem que alguém o consegue arranjar quando avaria de noite. São estas as perguntas a que a produção responde.
Há uma segunda diferença fácil de ignorar. Um protótipo é avaliado pela pessoa que o construiu, no dia em que foi construído, com entradas escolhidas por ela. Um sistema em produção é avaliado por pessoas que nunca viram a demonstração, meses depois, com dados que não existiam quando o código foi escrito. A maior parte do trabalho da tabela seguinte existe para que essa segunda avaliação corra bem.
O que a produção acrescenta
As frações abaixo são uma divisão ilustrativa para uma ferramenta LLM interna, como um copiloto de pesquisa em documentos, a passar de um protótipo funcional para algumas centenas de utilizadores diários. São opiniões de planeamento, não medições. Ajuste os pesos ao seu caso; o que importa é a forma.
| Item de trabalho | O que significa | Sem ele | Fração ilustrativa |
|---|---|---|---|
| Lógica central | O que o protótipo já mostra | Não há produto | 20% |
| Contratos de dados e pipelines | Verificação de esquema em cada fonte de entrada; cargas agendadas e idempotentes | Uma exportação a montante muda e as respostas degradam-se sem qualquer erro | 15% |
| Conjunto de avaliação e critérios de qualidade | Perguntas reais com respostas esperadas, executadas a cada alteração de prompt ou de modelo | Ninguém consegue dizer se uma alteração melhorou ou piorou as coisas | 12% |
| Autenticação e permissões | Single sign-on; regras de acesso aplicadas no momento da recuperação | Os colaboradores veem documentos que não deviam ver | 8% |
| Validação de entradas e tratamento de erros | Limites de tamanho e formato; tratamento de texto hostil em carregamentos e documentos recuperados | Um ficheiro estranho deita o serviço abaixo ou manipula o modelo | 8% |
| Monitorização e alertas | Latência, taxa de erro, custo por pedido, taxa de recuperações vazias, feedback dos utilizadores | Os problemas são reportados pelos utilizadores, dias depois | 8% |
| Revisão de segurança e correções | Segredos, dependências, dados enviados para APIs de terceiros | Uma chave exposta ou uma violação no tratamento de dados | 8% |
| Piquete e runbooks | Um responsável nomeado e passos escritos para as falhas comuns | A única pessoa que sabe está de férias | 7% |
| Rollback e processo de lançamento | Prompts, modelos e índices versionados; um interruptor para voltar à última versão boa | Um lançamento mau fica ativo enquanto alguém o depura | 5% |
| Documentação e passagem de testemunho | Como funciona, como alterá-lo, como operá-lo | O sistema não sobrevive ao seu autor | 5% |
| Limites de custo | Quotas por utilizador, limites de tokens, um disjuntor de despesa | Um ciclo ou um utilizador intensivo produz uma fatura inesperada | 4% |
A primeira linha é o protótipo. Nesta divisão, é um quinto do trabalho. Os outros quatro quintos são invisíveis numa demonstração, e é por isso que uma demonstração é tão má referência para um orçamento.
Para engenheiros: para onde vai o tempo
Algumas das linhas merecem mais detalhe, porque é aí que as estimativas costumam falhar.
As permissões pertencem à recuperação, não à resposta. Num sistema com geração aumentada por recuperação (RAG), a verificação de acesso tem de filtrar os documentos antes de chegarem ao modelo. Filtrar depois da geração não funciona: o modelo já leu o texto restrito e pode parafraseá-lo. Isso significa que o índice transporta metadados de acesso, se mantém sincronizado com o sistema de origem, e alguém o testa com contas que têm direitos diferentes.
O conjunto de avaliação é a especificação em forma executável. É um ficheiro versionado de entradas reais com saídas esperadas ou regras de classificação, executado em CI a cada alteração de prompts, modelos, chunking ou parâmetros de recuperação. Construí-lo significa sentar-se com as pessoas que vão usar o sistema e escrever o que é uma resposta correta. É lento, e nenhum assistente o pode fazer por si, porque o conhecimento está com os utilizadores.
A validação de entradas inclui agora texto que ataca o modelo. Um documento no índice pode conter instruções. Os carregamentos podem ser enormes, vazios, imagens digitalizadas ou estar na codificação errada. Cada caso precisa de um comportamento definido e de um teste.
O rollback exige que tudo seja versionado em conjunto. Um lançamento é um prompt, uma versão de modelo, uma construção de índice e código. Se só o código estiver no git, reverter o código não reverte o comportamento.
Os limites de custo são uma funcionalidade de produção. Um protótipo tem um utilizador. Um sistema em produção tem algumas centenas, mais scripts e novas tentativas. Quotas por utilizador, números máximos de tokens e um alerta sobre a despesa diária são baratos de construir e evitam a surpresa desagradável mais comum.
Como tratar um protótipo se é responsável pelo orçamento
Trate-o como uma especificação. Um protótipo funcional é a descrição mais clara do que se quer que a maioria dos projetos alguma vez obtém. Entregue-o aos engenheiros juntamente com a lista de entradas com que foi testado e os casos em que falhou.
Não o trate como 80% do produto. Se um orçamento é pequeno porque o protótipo já existe, pergunte quais das linhas acima ele cobre. Se a resposta for só a primeira linha, o orçamento é para um segundo protótipo.
Use-o para testar a procura antes de financiar a produção. Coloque-o à frente dos utilizadores previstos durante duas semanas. Se não voltarem a usá-lo, poupou o orçamento de produção, que é a coisa mais útil que um protótipo pode fazer.
Quando deitar o protótipo fora
Reescreva em vez de estender quando uma ou mais destas condições se verificam:
- há segredos no código ou no histórico do repositório;
- os dados são acedidos através da conta pessoal ou da chave de API pessoal de alguém;
- a interface, a lógica e o acesso aos dados estão misturados, pelo que as permissões não podem ser aplicadas num único sítio;
- ninguém consegue explicar como foi produzida uma determinada resposta;
- corre num construtor alojado que não pode ser implementado dentro do seu ambiente nem cumprir as suas regras de dados;
- a lógica é longa e não tem testes.
Mantenha-o quando a lógica central é curta, legível e separável, já existem alguns testes e o fluxo de dados se assemelha ao de produção.
Deitar código fora custa menos do que parece. O protótipo já fez o seu trabalho: as decisões estão tomadas, os exemplos estão recolhidos, a interface foi experimentada. Os prompts, as entradas de exemplo e as capturas de ecrã costumam sobreviver a uma reescrita, mesmo quando o código não sobrevive.
Como é a diferença em dinheiro
Os nossos próprios intervalos de preço publicados mostram o mesmo rácio. Uma prova de conceito custa 14k–38k € em 4–7 semanas. Uma construção para produção custa 45k–120k € em 10–20 semanas. Nos dois extremos do intervalo, a produção é cerca de três vezes a prova de conceito: 45 / 14 ≈ 3,2 e 120 / 38 ≈ 3,2. Esse múltiplo é o custo das linhas acima que não são a primeira. Entregamos monitorização e rollback antes da passagem de testemunho pela mesma razão: é isso que permite a um cliente operar o sistema sem nós.
Se já tem um protótipo e quer saber que linhas ele cobre, o teardown gratuito é uma primeira verificação em seis perguntas, e uma descoberta paga e curta responde por completo. A mesma lista aplica-se a copilotos de documentos internos, onde as permissões e o conjunto de avaliação costumam levar mais tempo.
Fontes
- CNN, 'Vibe coding' named Collins Dictionary's Word of the Year, novembro de 2025 — https://www.cnn.com/2025/11/06/tech/vibe-coding-collins-word-year-scli-intl
- Stack Overflow, 2025 Developer Survey: AI, julho de 2025 — https://survey.stackoverflow.co/2025/ai
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, julho de 2025 — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR, We are Changing our Developer Productivity Experiment Design, fevereiro de 2026 — https://metr.org/blog/2026-02-24-uplift-update/