We brought a demo to AI TechWorld that would have drawn a crowd two years ago. Scan a QR code. Text what you want to build. Ten minutes later you have a working backend, a database, APIs, and a front end, deployed and running.
Cool story? Almost nobody cared.
Not in a rude way. People watched it, said it was neat, and moved on. Over two days on the floor, not one conversation turned on how fast we could build something. Everyone in that hall already knew building was cheap. What they wanted to talk about was what happens after.
A theme that resonated - Understanding
I gave a talk called The Missing Layer in the AI SDLC. The argument is short. Build has become generate. Code review is the bottleneck today, but it will not stay one, because as models improve people will accept what the model ships. When review compresses toward zero, the question left is not whether the code is correct. It is whether the software does what the business needed.
Those are different questions. Code approval is not business rule approval.
Imagine a scenario where a merchant has one rule: refund the customer when an item is returned. The logs look fine. Status 200. The code reads fine. There is a refund function and a return function and both do their jobs. But look at the sequence as a business process and you see the money leaving before the return is confirmed. The code is correct. The business outcome is wrong.
Who got it fastest
There was a pattern in who understood it right away. Business-oriented people got there fast. Purely technical people took longer.
The clearest case was a founder who runs his own company. He met a colleague of mine on day one and told him he did not understand what we were selling. My colleague asked him to come back the next day and explain why he would never use us, since that is useful too. Before he did, he sat in on my talk. He came to the booth afterward and said he had been thinking about the AI development lifecycle purely as a technology problem, and had forgotten that the business stakeholders are the ones accountable for what the software does.
Engineers understand the system. The business answers for it. Review used to be where those two met, and that is the part getting compressed.
AI Engineers at Microsoft, Mozilla and Atlassian described the same problem
The most useful validation came from a panel on AI in production, with engineers from Mozilla, Atlassian, Microsoft, and Thinking Machines Lab.
One theme ran through all of it. Traditional systems fail loudly. Something returns a 500, a service goes down, everyone knows in minutes. Agent-driven systems fail quietly. Every dashboard stays green. Latency is normal, cost is normal, error rates are normal, and the system is doing the wrong thing.
Andy Seng of TechFocus described a customer who automated payment approvals with a few people handling exceptions. Six months later the exception team had gone from four people to one, because the handoffs had stopped happening. Volume grew past what a human could review, so the thresholds were adjusted, and the agents were just processing. Every metric looked healthy. He said he still does not know whether that was a success or a failure.
Priyanshu Jha who leads AI for Loom on the Atlassian side put the demo problem well. Your demo is your best customer on their best day. Your production is your customer having a bad one.
Look at me. Agents are the consumer now
Kathy Baxter, who leads responsible AI at Salesforce and who I worked with years ago at Google, opened the second day with a structural version of the same argument. For thirty years the contract around an API was that a human makes a request and a human reviews the result. Agents broke that contract. They are now first-class consumers of the APIs we build, working at a speed and scale no person can review.
She shared numbers that put scale on it: more than 29,000 Agentforce deployments in production and over seven billion completed units of agentic work, growing 97 percent year over year.
Salesforce reports work completed rather than tokens consumed. Tokens measure what you spent. Completed work measures what you got.
Her closing rule was the one I wrote down. An agent and the mechanism that constrains it must not live in the same trust domain. If an agent can reach the rules that bind it, those rules are a suggestion.
Where this leaves me
Two years ago the story was speed. It is not anymore, and the floor at AI TechWorld made that clear. Nobody needs help writing code faster and soon enough code review will go away entirely.
What people need is a way to know what the software they now own actually does. Something derived from the running system, tied to the rules the business set, showing what happened in production. Process, policy, production, in one place.
I have started calling that the understanding layer, because you cannot govern what you do not understand.
Like this take on the future of software development in the AI era? Get the latest posts straight in your inbox by subscribing to the Futureproof newsletter on LinkedIn.
