In May this year, Forbes published an article by Thanh Pham, CEO of Saigon Technology, predicting a fork in the software market over the next 36 months.

On one side, companies trapped in a price war selling programmer hours. On the other, AI-native companies with outcome-based billing models, smaller teams, and greater efficiency. For anyone who has been in the sector for a while, the prediction reads like a belated observation.

I have spent more than 13 years building software for companies. I have watched this sector change in cycles, but the current pace has a different quality to it: the shifts that once took a decade to affect a software company's business model are now happening in months. I decided to write up my reading of Pham's thesis, what it gets right, where it stops short of the hardest point, and what I learned trying to make this transition in practice.

The equation that broke

For decades, the software sector ran on a simple logic: more output requires more people. Contracts were closed in work hours. Teams grew to absorb larger projects. Revenue and headcount moved together, and the most common measure of a software company's health was how many developers it had allocated.

That model had a clear advantage for the vendors: all the risk sat with the client. The software company delivered hours. Whatever happened to the byproduct of those hours afterward was the responsibility of whoever hired them. If the product slipped, the client paid for more hours. If the scope grew, the client approved a change order. The software company was a supplier of specialized labor, and responsibility for the result the software produced stayed on the buyer's side.

Vibe engineering, which is vibe coding done the right way by software engineers, breaks that equation on the production side. The concept, which Pham uses to describe the model where the developer describes the intent and the AI executes, dramatically compresses the time between specification and running code. A small team with the right tools delivers today what once required dozens of people. Uber is rebuilding its engineering process around this. Pham cites a Reuters report from February 2026 showing a drop in demand for mid-level roles as AI adoption accelerates. The generic, repetitive, low cognitive-risk code that used to fill those roles became work for agents.

When production stops being the bottleneck, the headcount-based sales pitch falls apart. The client realizes they are paying for presence, and starts asking about results.

What Forbes gets right, and what stays implicit

Pham identifies three moves that surviving companies need to make: from execution to expertise, from labor to leverage, and from technical delivery to accountability for the business result. The direction is correct. But there is a consequence of these three moves that the article leaves implicit and that deserves to be stated plainly: they are mutually dependent, and following only one without the others produces a worse result than the current model.

A company that migrates to "expertise" without changing its compensation model just keeps selling expensive consulting in place of cheap hours. The client pays more and still carries the risk. A company that cuts headcount by using AI to produce more volume keeps the same problem as before: no one is accountable for the result. The transition only works when the three moves happen together, because it is the combination of them that changes the company's position in the value chain.

The most interesting argument in the article, and the least developed, revolves around what Pham calls "trust-as-a-service." Anyone today can generate code at speed. The problem is that AI-generated code can be inconsistent, hard to maintain, and may carry vulnerabilities that do not show up right away. In a market where the barrier to entry for generating code has dropped close to zero, trust becomes the scarce asset.

What Pham does not unpack is what operationalizing that trust requires in practice. Validating AI-generated code at scale calls for review processes that are different from the ones used to review human code. A human developer has intent: you can ask why they made a particular choice. An AI agent has patterns, but the intent has to be inferred. The review process, the testing criteria, and the documentation standard need to cover decisions that used to be explicit in the head of whoever wrote the code. Companies that learn to build this process with consistency hold a real edge, because most are generating code fast and discovering the problems in production.

In the projects Softo has delivered using Outcome Pods, what clients value most is exactly that certainty: what was built will work in production, will scale, and can be maintained without depending on whoever built it.

Where the article stops short of the hardest point

Pham describes the move to outcome-based pricing as part of the "reinvention playbook" and treats the change as a strategic decision companies need to make. The description is correct, but it leaves out the trickiest part: shifting from hours to outcomes redistributes who carries the risk, and that redistribution demands a maturity on both sides that rarely exists at the start.

In the hours model, the client takes on the risk of timeline, scope, and result. The software company delivers what was agreed within the contracted time. If the product did not produce the expected result, the contract was still fulfilled. The problem became the client's. That asymmetry is comfortable for the software company and frustrating for the client, but it persists because the client has historically agreed to pay for it. The alternative, trusting that a vendor will be accountable for the result, requires a track record that takes years to build and that most software companies are still only beginning to accumulate.

In the outcome-based model, the software company enters as a risk partner: it prices uncertainty and takes responsibility for the final result, on top of the technical delivery. This requires the client to know how to define what the result is before signing anything, the company to know how to price something that does not yet exist, and both sides to build up enough trust to negotiate when the scope evolves along the way. And the scope always evolves.

When I went to my partner Rafael Ruiz early this year and said we needed to change the model, what we realized is that the hardest conversations happened with the clients. Some were ready: they had always wanted to look at the result, and for the first time they had a vendor willing to be accountable for it. Those clients came on board quickly, because the new model solved an old frustration. Others needed time to understand what they were buying, and some were not ready to define what success would look like before starting, which makes the whole model unworkable. We learned that qualifying the client matters as much as the quality of the delivery. Taking on a client who still thinks in hours, inside an outcome contract, creates guaranteed conflict.

The Forbes article treats this transition as a switch. In practice, it is something you build over time, it depends on the relationship, and it can mean turning down projects you would once have accepted without hesitation.

The bottleneck that moved

There is a dimension of vibe engineering the article does not explore, and it is changing the profile of who adds value inside a software company.

The speed of code generation has risen sharply. The ability to understand what the business actually needs, to define the problem precisely, and to make sure what was built solves what it was supposed to solve, has advanced at a much slower pace. The result is a mismatch: teams produce faster, but often do not have the right problem to solve.

The work that used to be slow because of writing the code is now slow because of defining the problem. The most valuable person on a team becomes the one who can translate business context into a precise specification: the one who understands the operation well enough to say what needs to be built before reaching for any tool. That profile always existed, but it was scarce because most of a team's energy went into execution. With execution becoming cheaper, the cost of having people who know how to ask the right questions before building is far easier to justify.

This has a direct consequence for the Outcome Pods model: the most valuable work we do for clients happens before the first line of code. It is the mapping of the problem, the definition of success criteria, the identification of what needs to be built first to generate learning before committing budget to development. In the fastest cycles we have ever delivered, the difference was the quality of the specification that went into the tool. And that makes all the difference.

Conclusion

The Forbes article correctly describes the direction of the market, and the fork Pham predicts is already underway. The companies that come out well will be the ones that understood that AI changed what needs to be sold, and that made the three moves together: expertise, leverage, and accountability for the result.

What gets left out of Pham's thesis is where the bottleneck ended up. AI solved execution. The problem that remains, and that will separate the companies that grow from the ones that merely survive, is the ability to get there before the code: to understand the problem deeply enough to build the right thing on the first attempt.

Whoever masters that stage will capture the value that generation speed unlocks. Whoever skips it will generate fast code for the wrong problem.

Pham closes with a line that sums up the thesis: "code is cheap, trust is priceless and outcomes are everything." The line is correct, but trust is built delivery by delivery, project by project, with clients willing to make the same move on their side. Declaring that you deliver outcomes settles the positioning. The relationship built across deliveries is what validates it.