Over the past year or so we’ve seen an explosion of AI tooling for software development. GitHub Copilot, Claude Code, OpenCode and a whole range of other harnesses and agents. Alongside the tools themselves, we’ve seen new approaches to the AI software development lifecycle: spec driven development frameworks like BMAD, Superpowers, HyperVelocity Engineering Core and GitHub Spec Kit, and patterns for building agents, skills and workflows that tie all of these things together.
It would be easy to look at all of this and conclude that the story here is the tooling. It isn’t. The story is what the tooling does to the rest of your delivery process, and what happens when organisations bolt AI onto workflows that were never designed for it.
The development loop has collapsed, and the pressure has moved
What’s actually happening is that the software development loop is getting really short. The ability to produce large amounts of high quality code has increased dramatically, and that puts a new kind of demand on developers at both ends of the process.
On the way in, the quality of what you feed into these tools now matters enormously. If you want AI tooling to produce correctly specced code, you need to give it high quality requirements. Average specifications and average business requirements that developers used to transpose into the end state simply don’t cut it anymore. The demand for well formed, implementable requirements has never been higher.
On the way out, developers need to bring their full technical capability and their critique to reviewing what gets produced. It’s not just about checking the code against standard development practices. It’s about making sure it’s free of bugs, well designed and secure. This isn’t about trusting the output. It’s about applying real engineering judgment to it, every time.
So the effort hasn’t disappeared. It’s moved. And that has some interesting consequences for how you plan and run delivery.
What we saw first: the baseline
At Arinco, we worked with a large enterprise client to migrate more than 50 applications into Azure. These were old applications with a lot of tech debt. Old .NET, jQuery, Angular 1, genuine spaghetti code. We migrated all of them to .NET 10 Blazor, brought them up to the client’s new security standards, added authentication with Entra ID, and landed the lot in Azure.
We did that in six months.
That work happened around 18 months ago, with the tooling available at the time. No spec driven development frameworks. No agent harnesses. Just GitHub Copilot and ChatGPT Enterprise to break the work down and get through it. Even that generation of tooling reshaped what was possible. The acceleration since then has been rapid, and it’s the follow on engagement with the same client where things got really interesting.
What we saw next: the inversion
The next piece of work was to take a set of services from an existing legacy code base and migrate them onto the new stack. We scoped it as a quarter of work, and our original assumption was that this would run like a standard project. Just in time requirements gathering, aligned to the development process, with AI accelerating the build.
That’s not what happened.
What actually transpired is that we spent around five weeks doing analysis and writing specifications. Deep analysis of the legacy code base, conversations with business stakeholders, and analysis of the repositories the features would be built into. The output was a set of specifications that talk directly to the code bases they’ll be built against, verified by the business, and ready for AI tooling to pick up and develop from.
And now that development is underway, it’s tracking to take less time than the specification phase did.
The specification took longer than the build. That is completely alien to every other software project I’ve been involved in. The traditional effort curve, where requirements are a slim phase at the front and development is the long middle, has inverted. Specification is now the long pole. Development is the short one.
The interesting part is that the tooling accelerated both sides. We used AI to help produce specifications that were implementable, and then AI tooling implemented them. The upfront investment wasn’t overhead. It was the thing that made the acceleration possible.
The real lesson: the whole lifecycle needs redesigning
Once development stops being the bottleneck, friction starts showing up everywhere else. In requirements. In design handoffs. In testing. In the path to support and operations. And you can’t fix that by adding another tool. You fix it by looking at the full workflow, end to end, and redesigning the interaction points between phases.
The pattern we’re seeing emerge is that the outputs of one phase become defined, machine consumable inputs to the next. Your design system and component libraries stop being reference material and become the direct input for front end implementation, through skills that understand how those design systems work and can implement against them. Your testing strategy stops being a document and becomes a set of defined guardrails: this spread of tests, these frameworks, these end to end scenarios, expressed as skills and components the tooling can execute against.
We’re already working with another organisation that’s taking this seriously. They’re using a project, a website and collection of applications being revitalised, as a test bed for changing the process itself. Not just application development, but the entire delivery lifecycle. Specifications, user experience, development, testing, and through into support and operations, with AI as both the accelerator and the glue between the pieces.
Where this lands
We didn’t design this workflow on a whiteboard. It emerged on real engagements, and it surprised us too. We went in expecting a standard project with faster typing, and we came out with an inverted delivery model and a set of lessons about where the real friction lives.
I don’t think the full delivery lifecycle is automatable today. But the direction is clear. The organisations that redesign their workflow around these capabilities will compound the acceleration. The ones that just add tools will get a fraction of the value and wonder why.
If you’re looking at your own delivery process and wondering where to start, that’s a conversation we’re having with clients right now. Whether it’s rethinking how requirements flow into development, or standing up a test bed project to redesign the lifecycle end to end, we’ve done it on live engagements and we know where the friction points are. Take a look at our Agentic Delivery Accelerator or get in touch with the team at Arinco.
