Luis Aburto is the Founder and CEO of Scio, a custom software development firm serving North American organizations.
Most conversations about AI-assisted software development focus on productivity: “How much faster can developers work?”
That matters, but it misses the bigger shift. AI is lowering the cost of producing code, yet code is only one input into successful software. Someone still has to decide what to build, understand how it fits into the existing environment, verify it, secure it and determine whether it delivers the intended business result.
As implementation gets cheaper, the value of engineering shifts away from raw labor input and toward outcomes: increasing revenue, lowering cost, reducing risk or improving reliability.
Scarcity does not disappear. It moves.
When code gets cheaper, scarcity moves elsewhere.
For most of my career, accelerating a road map usually meant adding people, extending timelines or reducing scope. AI is loosening that relationship. Developers can now produce many implementations much faster, but the difficult work has not disappeared. More of it shifts toward problem definition, architecture, system context and validation.
Consider a routine change to a mature application. Producing the code may take hours instead of days, but the team still has to understand dependencies, test downstream systems and avoid an outage.
For engineering leaders, the practical question is no longer just how quickly developers code. Look at the full path from idea to production value. Where does work wait? Where does rework happen? Where does risk accumulate? If the bottleneck is testing, architecture or unclear product decisions, faster code generation will not solve it.
Faster development can simply move the bottleneck.
Software delivery is a system. Speeding up one part does not necessarily speed up the whole.
DORA has described AI as an amplifier of what’s already there, and this is especially true of the engineering environment around it. Faster implementation can improve throughput, but weak testing, poor architecture or slow reviews still constrain delivery.
I have seen this pattern for years. A team delivers an integration faster than expected, only to lose the time in testing, security review or a legacy dependency. The coding improvement was real; coding just was not the constraint.
If implementation falls from two weeks to three days but validation still takes 10, the next dollar of improvement probably belongs in test automation, observability or system documentation, not more code generation.
Reliability and security become more valuable for the same reason. More services, integrations and automations mean more software to monitor, patch and maintain.
Engineering metrics need to move closer to outcomes.
AI also makes activity metrics less useful. Pull requests, tickets closed and velocity can help teams manage work, but they measure activity more than value. AI can increase all of them without improving the result, so measurement needs to move closer to the outcome: time to validated value, reliability, operating cost and risk reduction.
It also helps to separate developer productivity, delivery performance and business outcomes. They are connected, but not interchangeable. A developer can get faster while the team remains slow. A team can ship faster while the product creates no additional value.
The better management question is simple: “Are we getting more value from our engineering investment?”
Team structures and commercial models will follow.
As implementation requires less human effort, engineering roles will adjust. Developers will still write code, but more of their time is likely to go toward specifying work, reviewing generated output, integrating systems, validating behavior and operating what they build. That puts a premium on judgment, context and accountability.
The same economics apply to companies that buy engineering services. Much of the industry still purchases engineering through FTEs, hourly rates and team capacity. That model assumes a reasonably stable relationship between labor input and useful output, but AI weakens that relationship.
Suppose two providers can deliver the same modernization outcome with comparable quality and risk. One requires eight engineers; the other needs five because it uses AI more effectively. A model based primarily on hours creates an odd incentive: The more efficient provider bills less for producing the same value.
Buyers will increasingly question that logic. This does not mean the industry jumps directly to pure outcome pricing. Business outcomes such as revenue growth or customer retention depend on factors an engineering provider may not control. A more realistic transition is from paying primarily for labor toward paying for accountable delivery.
That can mean managed capacity with performance expectations, fixed prices for defined deliverables, service levels or fees linked partly to measurable outcomes. The more control a provider has over the result, the more economic accountability it can reasonably assume. I believe hybrid models are likely to become common.
Companies ultimately buy faster market entry, lower costs, modernization, more reliable systems or reduced risk. AI makes the distinction between input and value harder to ignore.
Here’s where organizations misread the shift.
Organizations can still get this wrong through the following mistakes:
• Treating More Generated Code As Success: More code can mean more review, testing and maintenance without creating more value.
• Optimizing Developer Productivity In Isolation: If QA, security or deployment becomes the new queue, you improved a local metric, not the system.
• Jumping Straight To Outcome Pricing: Commercial accountability should follow operational control.
The lesson is straightforward: Measure the outcome you care about, not the promise of the tool.
The economic shift is toward outcomes.
AI is lowering the cost of producing software. It is not lowering the cost of every good decision around that software, nor does it guarantee that what gets built will create value. That is why the larger change is economic, not just technical.
As implementation becomes less scarce, value moves toward judgment, integration, verification, security, reliability and operational ownership. Team structures, engineering metrics and commercial models will follow.
The organizations that I believe will benefit most from cheaper code will not simply produce more of it. They will get better at turning engineering investment into measurable business results.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
