A Forbes publicou em maio deste ano um artigo de Thanh Pham, CEO da Saigon Technology, prevendo uma bifurcação no mercado de software nos próximos 36 meses.

De um lado, empresas presas na guerra de preços vendendo hora de programador. Do outro, empresas AI-native com iniciativas de cobrança por outcome, com times menores e mais eficientes. Para quem está no setor há algum tempo, a previsão soa como constatação tardia.

Tenho mais de 13 anos construindo software para empresas. Vi esse setor mudar em ciclos, mas o ritmo atual tem uma qualidade diferente: as mudanças que antes levavam uma década para afetar o modelo de negócio de uma empresa de software estão acontecendo em meses. Resolvi escrever minha leitura sobre a tese do Pham, o que ela acerta, onde ela para antes do ponto mais difícil, e o que aprendi tentando fazer essa transição na prática.

A equação que quebrou

Durante décadas, o setor de software funcionou em cima de uma lógica simples: mais entrega requer mais gente. Os contratos eram fechados em horas de trabalho. Times cresciam para absorver projetos maiores. Faturamento e headcount andavam juntos, e a métrica mais comum de saúde de uma empresa de software era quantos desenvolvedores ela tinha alocados.

Esse modelo tinha uma virtude clara para as empresas fornecedoras: o risco ficava todo com o cliente. A empresa de software entregava horas. O que acontecia com o subproduto dessas horas depois era responsabilidade de quem contratou. Se o produto atrasou, o cliente pagava mais horas. Se o escopo crescia, o cliente aprovava um aditivo. A empresa de software era um fornecedor de mão de obra especializada, e a responsabilidade pelo resultado gerado pelo software ficava do lado de quem comprava.

O vibe engineering, que é o vibe coding feito do jeito certo por engenheiros de software, rompe com essa equação pelo lado da produção. O conceito, que Pham usa para descrever o modelo onde o desenvolvedor descreve a intenção e a IA executa, comprime dramaticamente o tempo entre especificação e código rodando. Um time pequeno com as ferramentas certas entrega hoje o que antes precisava de dezenas de pessoas. A Uber está reconstruindo seu processo de engenharia em torno disso. Pham cita um relatório da Reuters de fevereiro de 2026 mostrando queda na demanda por papéis de nível médio à medida que a adoção de IA acelera. O código genérico, repetitivo, de baixo risco cognitivo, que preenchia esses papéis, passou a ser trabalho de agentes.

Quando a produção deixa de ser o gargalo, o argumento de venda baseado em headcount cai por terra. O cliente percebe que está pagando por presença, e começa a perguntar por resultado.

O que a Forbes acerta, e o que fica implícito

Pham identifica três movimentos que as empresas sobreviventes precisam fazer: de execução para expertise, de mão de obra para alavancagem, e de entrega técnica para responsabilidade pelo resultado do negócio. A direção está certa. Mas há uma consequência desses três movimentos que o artigo deixa implícita e que merece ser dita com clareza: eles são mutuamente dependentes, e seguir apenas um sem os outros produz resultado pior do que o modelo atual.

Uma empresa que migra para "expertise" sem mudar o modelo de remuneração continua vendendo consultoria cara no lugar de hora barata. O cliente paga mais e ainda carrega o risco. Uma empresa que reduz headcount usando IA para produzir mais volume mantém o mesmo problema de antes: ninguém se responsabiliza pelo resultado. A transição só funciona quando os três movimentos acontecem juntos, porque é a combinação deles que muda a posição da empresa na cadeia de valor.

O argumento mais interessante do artigo, e o menos desenvolvido, gira em torno do que Pham chama de "trust-as-a-service". Qualquer pessoa hoje consegue gerar código em velocidade. O problema é que o código gerado por IA pode ser inconsistente, difícil de manter e pode carregar vulnerabilidades que não aparecem de imediato. Em um mercado onde a barreira de entrada para gerar código caiu perto de zero, confiança virá o ativo escasso.

O que Pham não desdobra é o que operacionalizar essa confiança exige na prática. Validar código gerado por IA em escala requer processos de revisão que são diferentes dos processos de revisão de código humano. Um desenvolvedor humano tem intenção: você consegue perguntar por que ele fez determinada escolha. Um agente de IA tem padrão, mas a intenção precisa ser inferida. O processo de revisão, os critérios de teste e o padrão de documentação precisam cobrir decisões que antes eram explícitas na cabeça de quem escreveu o código. Empresas que souberem construir esse processo com consistência têm um diferencial real, porque a maioria está gerando código rápido e descobrindo os problemas na produção.

Nos projetos que a Softo entregou usando Outcome Pods, o que os clientes mais valorizam é exatamente essa certeza: o que foi construído vai funcionar em produção, vai escalar, e vai ser possível manter sem depender de quem construiu.

Onde o artigo para antes do ponto mais difícil

Pham descreve o movimento para outcome-based pricing como parte do "playbook de reinvenção" e trata a mudança como uma decisão estratégica que as empresas precisam tomar. A descrição está certa, mas omite a parte mais complicada: mudar de horas para outcome redistribui quem carrega o risco, e essa redistribuição exige uma maturidade de ambos os lados que raramente existe no início.

No modelo de horas, o cliente assume o risco de prazo, escopo e resultado. A empresa de software entrega o combinado dentro do tempo contratado. Se o produto não gerou resultado como esperado, o contrato foi cumprido. O problema virou do cliente. Essa assimetria é confortável para a empresa de software e frustrante para o cliente, mas ela persiste porque o cliente historicamente aceitou pagar por ela. A alternativa, confiar que um fornecedor vai se responsabilizar pelo resultado, exige um histórico que leva anos para construir e que a maioria das empresas de software ainda está começando a acumular. No modelo baseado em outcomes, a empresa de software entra como parceira de risco: precifica incerteza, assume responsabilidade pelo resultado final, além da entrega técnica. Isso exige que o cliente saiba definir o que é resultado antes de assinar qualquer coisa, que a empresa saiba precificar algo que ainda não existe, e que os dois lados acumulem confiança suficiente para negociar quando o escopo evolui no meio do caminho. E o escopo sempre evolui.

Quando cheguei para o meu sócio Rafael Ruiz no início desse ano dizendo que precisávamos mudar o modelo, o que percebemos é que as conversas mais difíceis aconteceram com os clientes. Alguns estavam prontos: queriam olhar para o resultado desde sempre e pela primeira vez tinham um fornecedor disposto a se responsabilizar por isso. Esses clientes aderiram rapidamente, porque o modelo novo resolvia uma frustração antiga. Outros precisaram de tempo para entender o que estavam comprando, e alguns não estavam prontos para definir o que seria sucesso antes de começar, o que inviabiliza o modelo inteiro. Aprendemos que a qualificação do cliente é tão importante quanto a qualidade da entrega. Aceitar um cliente que ainda pensa em horas, dentro de um contrato de outcome, cria conflito garantido.

O artigo da Forbes trata essa transição como um switch. Na prática, é uma construção que leva tempo, depende de relação, e pode exigir rejeitar projetos que antes seriam aceitos sem hesitação.

O gargalo que se deslocou

Há uma dimensão do vibe engineering que o artigo não aprofunda, e que está mudando o perfil de quem agrega valor dentro de uma empresa de software.

A velocidade de geração de código aumentou muito. A capacidade de entender o que o negócio realmente precisa, definir o problema com precisão, e garantir que o que foi construído resolve o que devia resolver, avançou num ritmo bem mais lento. O resultado é um descompasso: as equipes produzem mais rápido, mas muitas vezes não possuem o problema certo para resolver.

O trabalho que antes demorava por causa da escrita do código agora demora por causa da definição do problema. O profissional mais valioso dentro de um time passa a ser o que sabe traduzir contexto de negócio em especificação precisa: o que entende a operação o suficiente para dizer o que precisa ser construído antes de acionar qualquer ferramenta. Esse perfil sempre existiu, mas era escasso porque a maior parte da energia dos times ia para execução. Com a execução se tornando mais barata, o custo de ter pessoas que sabem fazer as perguntas certas antes de construir se justifica com mais facilidade.

Isso tem uma consequência direta para o modelo de Outcome Pods: o trabalho mais valioso que fazemos pelos clientes acontece antes da primeira linha de código. É o mapeamento do problema, a definição dos critérios de sucesso, a identificação do que precisa ser construído primeiro para gerar aprendizado antes de comprometer orçamento com desenvolvimento. Nos ciclos mais rápidos que já entregamos, o diferencial foi a qualidade da especificação que entrou na ferramenta. E isso faz toda a diferença.

Conclusão

O artigo da Forbes descreve corretamente a direção do mercado, e a bifurcação que Pham prevê já está em andamento. As empresas que saírem bem serão as que entenderam que a IA mudou o que precisa ser vendido, e que fizeram os três movimentos juntos: expertise, alavancagem e responsabilidade pelo resultado.

O que fica de fora da tese do Pham é onde o gargalo foi parar. A IA resolveu a execução. O problema que ficou, e que vai separar as empresas que crescem das que apenas sobrevivem, é a capacidade de chegar antes do código: entender o problema com profundidade suficiente para construir a coisa certa na primeira tentativa.

Quem dominar essa etapa vai capturar o valor que a velocidade de geração libera. Quem pular ela vai gerar código rápido para o problema errado.

Pham fecha com uma frase que resume a tese: "code is cheap, trust is priceless and outcomes are everything." A frase está certa, mas confiança se constrói entrega por entrega, projeto por projeto, com clientes dispostos a fazer o mesmo movimento do outro lado. Declarar que você entrega outcome resolve o posicionamento. A relação construída ao longo das entregas é o que valida.