Two questions for enterprise engineering: does the way we make software need to change, and what should it change into?
For the last 50 years, one profession has sat in plain sight: the programmer. What that profession produces has quietly become the thing everything else runs on.
The scale of the shift is easy to under-read. In 1980, the United States had roughly 300,000 computer-programming jobs, according to Bureau of Labor Statistics data reported by Fortune, 2025, and the machines those people wrote for sat in rooms most of the public never entered. A car of that era carried a single-function chip to time its spark plugs.
Today, about 6 billion people, roughly 74 per cent of humanity, are online, according to ITU, 2025. Worldwide IT spending is heading for $6.37 trillion this year, more than $1.47 trillion of it software alone, per Gartner, 2026. Somewhere around 36.5 million people code for a living, with another 10 million or so doing it as a hobbyist, a student, or a side skill, according to SlashData, 2025. And that car now ships with around 100 million lines of code spread across more than a hundred controllers, a 2021 estimate that’s almost certainly higher today.
Somewhere in there, software stopped being a product category and became the medium through which people reach their money, their medicine and their government. Nobody opts out. And with AI, itself software and an engine for producing more of it, the curve is steepening, not flattening.
Which raises two questions. The first is obvious. The second is the one worth your time.
Does the way we produce software need to change?
Yes. Not because the tools got better, but because the stakes moved, and because of what happens when you bolt a fast tool onto a slow process.
A woman filed her tax return through a new government portal last spring. It crashed twice. The error message blamed ‘high traffic.’ It wasn’t traffic. The agency had shipped code faster than anyone could test or review it. She refiled by mail. Nobody called that a failure. The pull requests still counted as progress.
That failure is structural, not accidental. Requirements are written for humans to read slowly. Review gates are staffed for the volume a human team produces in a sprint. Test plans assume one person wrote the code and another will read it carefully before it ships. Drop an AI coding assistant into that pipeline and you haven’t removed the constraint, you’ve relocated it. Code now arrives faster than review, testing, security sign-off and deployment approval can absorb. The citizen doesn’t see any of those stations. She sees the timeout.
The numbers say the same thing. According to Gartner, 2025, enterprises applying AI only to code generation are capturing roughly 10 per cent productivity gains at the system level, while teams applying AI consistently across the whole lifecycle, requirements through operations, are projected to reach 25 to 30 percent by 2028. Adoption was never the hard part: according to Gartner, 2025, 90 per cent of enterprise engineers are projected to use AI code assistants by 2028, up from under 14 per cent in 2024.
Developer productivity and citizen experience are not the same measurement. One counts output per person. The other counts whether a real person got what they came for. A team can improve the first number for a year straight and watch complaints barely move.
What should it change into?
Not a second coding assistant. The work is governing what the agents are allowed to do once they are already inside the pipeline. Four moves, in order.
- Set the boundary before the agent touches the repository. What it is permitted to change, who reviews what it produces, and how that decision gets logged. Most enterprises have made none of these decisions. They turned the tools on and hoped the process would catch up.
- Sort review by risk, not by habit. Routine, low-stakes changes get automated validation. Anything touching a person’s data, a payment or a compliance boundary keeps a human sign-off with a recorded reason. That is neither reviewing everything by hand nor reviewing nothing, and it is the actual redesign.
- Keep traceability that survives the hard question six months later. What the agent changed, why, and on whose authority. Explainability stops being a research topic at the point where a regulator, an auditor or a customer asks.
- Measure the person on the other end. Map where AI-generated work actually gets stuck, not where it runs fastest. The metric that matters is whether she filed her taxes.
“Requires software engineering leaders to rethink their strategies,” is how Joachim Herschmann, VP Analyst at Gartner, described what LLM-based development now demands of engineering organisations.
This is the layer Calsoft’s practice for engineering intelligent systems at scale is built around: agentic AI development with controlled autonomy, not agents operating on production systems with no defined boundary. Governance isn’t the part enterprises bolt on after the AI-native SDLC works. It’s the part that protects the person on the other end of the transaction.
In 1980, a programmer’s output was a product. Today it is infrastructure that 6 billion people cannot opt out of. A faster test suite doesn’t matter if the citizen still hits a broken form. A faster pipeline doesn’t matter if nobody can explain why her filing failed twice.
The companies that get this right won’t be the ones with the most AI-generated code by December. They’ll be the ones whose citizens and customers stop noticing the software at all, because it simply worked.
FAQs
Why does software production need restructuring now?
Because the dependency changed. Software went from a product category to the medium through which billions of people reach money, healthcare and government. AI now generates code faster than review, testing, security sign-off and deployment approval, all still staffed for pre-AI volume, can absorb. The constraint moved downstream; the process hasn’t.
What is an AI-native SDLC?
A software development lifecycle rebuilt around AI agents working at every stage, requirements through operations, rather than an assistant bolted onto a pre-AI process. It replaces sequential, human-paced workflows with risk-based review and continuous validation, so the person using the software hits fewer failures instead of merely receiving code faster.
How should enterprises restructure the SDLC for AI?
Define agent boundaries before agents touch the repository. Sort review by risk: automated validation for routine changes, human sign-off with an audit trail for anything touching data, payments or compliance. Keep traceability that holds up months later, and measure customer outcomes, not developer output.
