The art of the possible in this new world

A few weeks ago, I called our senior architect late on a Friday. We had a module on our roadmap with no firm start date, but an opportunity had appeared where, if we moved fast, we could land a significant account.

The original estimate was four to six weeks. By Wednesday, the backend was built and we were already 60-70% complete.  This kind of timeline compression is becoming possible more often. But possible is the operative word,  AI doesn’t deliver speed like this on its own. The version of this story that says “AI is just faster now, plan for faster” is lacking some important detail.

There are two completely different planes of experience in AI-assisted application development right now.

On one plane: people who don’t come from a hardcore coding background suddenly have capabilities that would have been unthinkable even six months ago. They’re unconstrained by the baggage of the traditional SDLC. They don’t carry the battle scars of seasoned engineers. They’re bound only by their imagination, and the ones with aptitude are building genuinely exciting things.  But they walk straight into the familiar pitfalls of maintainability, scalability, and the most underrated one of all: the failure to design for what’s down the road, not just what’s in front of you. Good engineers don’t just build for the current requirement; they build something that can flex when the requirement changes. Imagination without architectural judgment is how prototypes fail to become anything more.

On the other plane: seasoned developers, who approach AI with a high degree of scepticism. Rightly so. They’ve spent years learning, often painfully, how easily a complex codebase becomes unwieldy the moment discipline slips. They are control freaks, and they should be. But this means their spin-up time with AI is much slower. They have to learn to trust, or more accurately, to build the supporting mechanisms that let them trust the output.  Until a developer can step out of the loop, the speed benefit is marginal. If you’re reviewing every line your AI agent wrote, you’re not 10x faster. You’re maybe 20% faster, and probably frustrated.  Getting veterans out of the loop isn’t really a problem of trust, it’s a problem of infrastructure. The hooks, plug-ins, guardrails, and processes that surround the AI are what make veteran discipline operational at AI speed.

Some people also inherently get better output from AI agents than others. Prompting well is a real skill, and the gap between people who get it and those still working at it is wider than most realise. We run regular AI working group sessions for exactly this reason. The tools improve fast, but the team’s ability to wield them well is the actual leverage.  The other side of wielding AI well is knowing what not to do with it, and the most obvious example isn’t unique to newcomers and that is the multitasking trap. It is dangerously easy to have multiple projects, prototypes, and ideas in flight at once when the cost of starting something has collapsed. It feels productive but it usually isn’t.  Attention split across five half-built things almost always produces five things that aren’t quite right. The discipline of focus matters more, not less.

What I keep coming back to is that AI adoption is largely being treated as a tool choice. It isn’t. It’s an operating-model choice. The teams seeing roadmap-changing speed aren’t the ones with access to the best models. They’re the ones who have done the work to build the systems, skills, and discipline around AI that let veteran judgment operate at AI velocity.  Then, the compression is real. But it’s earned, not given. Adopt the same tools without the same investment, and your six-week build is still a six-week build.