Agent-Assisted Engineering for the Enterprise

Modern agents can now build and maintain safe, secure, robust enterprise software at scale. This requires a critical set of conditions.

The promise of faster, cheaper, better is often vocal, from your boardroom, your vendors and your engineers, but the complexity, size and legacy embedded across the estate you oversee poses the biggest questions.

Everyone is looking at a future of supercharged engineers using frontier models to build out platforms, products and services that are more bespoke, better managed and easier to change than the current SaaS (software-as-a-service)-centric app stack.

The questions are similar whether you have to scale-up fast to meet investor expectations or steward a complex enterprise through this acceleration. What differs is the environment in which you have to act.

AI-assisted development capability is a must-have (how's your AI software factory coming on?). Do we learn as we go, or buy it in from Tier 1s?
How do we move from PoCs in orchestration and agentic chains to scaled, production-grade AI assistance in our software development lifecycle (SDLC)?
What must be true for us to trust AI-assisted development in a regulated environment?

We believe technology leaders at even the world’s largest, most complex organisations should be implementing AI-assisted delivery in production, safely, securely and at scale.

This is happening across big tech. We think the enterprise has no time to waste in learning from them, adapting it for their world and getting ahead of competition.

Getting there feels like changing everything. Software is moving from being inflexible but with a cheaper unit cost the more people use it, to total flexibility but with a unit cost that scales with the more people that use it.

Everything the enterprise values most: safety, certainty, control, scale - is, for the very first time, truly in their gift. Being able to reliably, safely, and provably implement AI-assisted engineering in the software development lifecycle fundamentally changes the Build-vs-Buy decisions all strategic technology leaders make.

Before the advent of truly capable AI-engineering, buying an off-the-shelf solution that largely met requirements was the prudent move. SaaS vendors banked on it. You get most of what you need out of the box, and configure the last mile. You exchange a subscription fee for capability, plus outsourced maintenance and support.

Now, Build has been supercharged. Creating high-quality custom software that’s truly fit-for-purpose is significantly quicker and cheaper. And owning the solution has become feasible, even trivial, making it easier to evolve and change over time.

Crucially, though, while AI has transformed many things, it hasn’t fundamentally changed the software development process and what meets the quality bar to be production-ready. The decades of discipline about how quality software gets built remain. What has changed is that an amplifier now sits inside that lifecycle, and an amplifier is only as good as the signal it is given.

Create a rock-solid foundation platform, ensure the context you give it is as clean and robust as possible, and only once those guards are in place can you let the model do what it is designed to do best. Write high-quality, correct code. This is where the 10x optimisation lives. Get the set-up wrong, and you get a messy, not-to-be-trusted, noisy outcome. Get the set-up right and AI-code for enterprise is real, is ready, and is orders of magnitude faster and cheaper to produce.

We have tested this on ourselves. Our own internal operations application - feature-rich, 107,000 lines of Rust with an event-sourced domain, a shared core driving two native apps and a web experience, and a full contract test suite - took around 200 hours of applied effort, spread across eight weeks, alongside other work. It contains no human-written code. Every line was agent-written under the conditions on this page, to the bar we hold in every enterprise engagement.

Unaided by agents (the world we lived in last year), greenfield code of this standard gets written at around a sustained 25 to 40 lines an hour. The comparison is stark. If written manually this would have taken between 2,500 and 4,000 hours of work, around two working years. Guided agents approach produces a top-quality product in around 6 weeks. An order of magnitude difference.

And we can show the working: the estimate comes from an audit of the full commit history, with every assumption stated.

Using agentic engineering (multi-step automated agents that act on developer instructions) to accelerate development is a double-edged sword, because a model is an amplifier. It amplifies whatever it is given.

Point it at an established codebase with strong patterns, embedded quality bars, and disciplined tests, and it produces more of the same.

Point it at a poorly structured estate with no enforcement, and it produces more of that too. Faster than any team of humans ever could.

Fail to set the right system conditions and an accelerated development cycle simply accelerates the bad.

For AI coding to move as a capability from POC to a live, scaled production system, enterprises need governed, repeatable, auditable and trusted quality. With the right conditions, agentic assisted engineering is not just possible, it's the capability you’ll need for the phase change that’s upon us all.

To confidently and safely deliver production-grade code using AI, a set of conditions must be true. The following describes our pattern, and while businesses may already tick several — all are now needed for no regrets AI-assisted coding.

Specification, design and plan to be fully thought through and agreed before a line of code is written. The architecture and patterns guided by experienced human judgment, not by the agent.
Technology choices optimised for correctness. This means a language and toolchain strict enough to reject the agent's mistakes before they compile.
Automated, continuous testing. Tests written alongside the code, not after it, with coverage that makes a green build shippable — in production.
Patterns, principles and the quality bar embedded in the repo from the first commit. Everything the agent can see is clean, correct and points in the desired direction.
A narrow, purpose-built context for each project. Avoid generic playbooks or patterns or sample codebases. Context pollution is real and introduces noise and agent drift.
Insist on small batches. Work with agents on lots of small pull requests, incrementally built, exactly as disciplined delivery has always worked. Loop engineering with 100s of sub agents and long chains of work has its place, but it is unlikely to be in the complex, highly dependent enterprise domain.
Decisions get made at the pace of development, in partnership with the agent and aligned to shared objectives with a decision-maker close to the work.
Where estate controls would strangle the work (pretty much any existing legacy environment), build outside the estate under agreed guardrails.
Start with path-to-production front of mind and plan the route to production within the estate. It will be managed, maintained and iterated in a new agentic-assisted way.
Clean up technical debt as you go. There’s no need for it anymore. Do it inline if it won’t distract the agent, or otherwise, at the end of your session while the context is fresh. This includes a docs sweep (so that future humans and agents won’t be misled).

3 questions

Should we buy or build now that AI seems to have changed the economics?+

We believe: if something exists that genuinely fits, buy it. We've spent 16 years telling clients that's the right answer. What's changed is the threshold: when the fit is 80%, living with the missing 20% now costs more than building the whole thing well. It is still a value:effort:risk call and for core transformation you are probably still buying. For everything else, the equation has changed.

Why isn't our AI coding investment showing up in delivery metrics?+

Away from agent orchestration, re-engineering business processes and rapid (vibe) integrations, heavy-lifting production codebases were sacred. In your custom app stack, code generation will never be the bottleneck. If your specification, review and release still move at legacy speed though, faster-typing engineers change nothing. The gains only appear when the whole SDLC moves. This is what the conditions are designed to solve. Throwing AI tools, and even great engineers, won't cut it.

A company we know vibe-coded their own version of a SaaS tool, couldn't maintain it, and went back. Why would this end differently?+

Your unique context is the most important factor. You are not a start-up greenfield and you are not the competitor down the street. All the failures we see share a pattern: no clean context built, no enforcement layer, no tests, no versioning discipline. Vibe POCs run as pet projects by experimentalists. Building without the conditions will give you a new and messier legacy headache - at speed.

5 questions

You advocate for Rust. Why? I can't hire Rust engineers.+

Rust is rapidly becoming the agentic engineering language of choice. The past few years' adoption by Big Tech is accelerating hard in the agentic era. You need far fewer Rust engineers than you'd think, as the agents write such high-quality Rust code and the compiler rejects what's wrong. Your language choice is an enforcement layer strict enough to act as a barrier for a machine's mistakes. You can't have high confidence the agent has done the right thing unless you know it can't have done the wrong thing. With Rust, you get correctness out of the box, alongside all the enterprise advantages of safety, performance, resilience and a mature ecosystem evolving for AI. A byproduct is a modern, progressive engineering org and ways of working that is genuinely compelling for the emerging talent stream.

How can you trust code that no human wrote?+

The same way you should trust code humans wrote: you don't, you verify. Machine-checked types, tests co-located with the code, end-to-end coverage that means green genuinely means shippable and your confidence is in the verification. Trust moves from the author to the verification system. We shift left on everything with humans still owning the spec, the architecture and the QA approach.

What are the conditions for using AI agents in a regulated codebase?+

Everything must be auditable: provenance on every change, compliance checked continuously rather than at an end-stage gate, rollback baked in to ensure it's cheap and instant. We believe regulated environments are where machine-enforced quality and verified automation beats human promises. The machines are generally better at this than we are.

Does any of this apply to our fifteen-year-old codebase, or only greenfield?+

Directly. What we've seen work: set the agents on the existing estate first, cleaning debt, documentation, fixing bugs, tidying non-idiomatic code, to make the existing as pristine as it can be before adding anything new. The cost of this is collapsing, but where a system is beyond lifting, build alongside it and let the existing migrate towards the new.

The tools change monthly. Aren't we betting on whatever's fashionable now?+

We believe the phase we are in will continue to generate rapid evolution of the front of the toolchain for a while. The frontier models and the ecosystems closest to them will undergo a Cambrian explosion and constant consolidation. New, impressive and useful tooling will emerge continuously. That supplies the more robust argument for why a stable, reliable, no-surprises platform underneath it is critical. Tight language, explicit dependencies, everything in version control. The more the agents evolve, the more the foundations matter.

5 questions

Why build outside our estate? Our controls exist for a reason.+

Your estate's controls encode years of risk decisions made for a different pace of change, slow-moving compliance, decades of tool and framework choices. They are rational, appropriate for your territory, and ossified. They will strangle this opportunity and pose a real risk. You must build outside of them in order to understand this new world. If you consider cyber as a standalone case, it would be reckless, bordering on negligent, not to know the new threats and responses. We believe software development is now in the same category. What works: build outside with agreed guardrails, then land the work and approach through your gates or by considered evolution of the gates. You only learn the new way by doing it.

Why does tool choice sit here and not our architecture board?+

This is not ours-versus-yours. It is simply that the choice of tools determines the quality of the code. Any constraint in the toolchain sets a defect rate, a quality bar and the likelihood of success before a line is written. We understand the issues at play and are open to deep technical exploration of the conditions and tooling we believe maximise success.

Does this mean fewer engineers?+

The reality we perceive for enterprises is capable engineers spending their time on judgment: specification, architecture, review, rather than coding. They will be doing more of this work in partnership with the agents and new classes of software development and engineering problems will emerge. The LLMs and systems around them are just another abstraction layer for us to understand and leverage in pursuit of great outcomes. What we've seen is that the organisations getting this right retain their best people because of it. The ability to generate top tier code gets hugely amplified and 'do more with less' is possible, but the work gets more senior, not smaller.

How do you handle dependencies when code is generated at agent speed?+

We have talked a lot about shifting left - on security, on platform design, on pipelines, on requirements, and on specifications. Dependencies must be deliberately managed and as early as possible. Map them before you start building. To accelerate any truly critical ones, place someone from the dependency team inside the new one. The build moving fast doesn't make the legacy teams faster. If these remain unresolved, the gaps grow and all your intent for production gets stalled at stubbed pilots.

Why start small? We need this at programme scale.+

Slow is smooth, smooth is fast. Every condition gets harder as scope grows: dependencies multiply, stakeholders multiply, decisions require more people and slow down. Tooling and compliance get harder to sign-off etc. The smallest useful slice proves the system while being wrong is still cheap. As it scales in feature, importance and size, the requirements that surface get solved from a position of knowledge and experience. Scale is earned and pragmatic.

3 questions

What does 'decisions at the speed of the build' require from us?+

An empowered decision-maker should be close to the work and able to 'see round the corners' that the team might miss. When implementation compresses from months to days, waiting for the steering committee on a fortnightly cadence becomes your critical path. Most of the schedule risk you will see in the new world comes from the latency baked into the existing decision paths. You'll need a remit and a mechanism for decision making to happen at your pace, whatever that takes. All orgs can do this, it's often a question of appetite.

How does governance keep up without becoming a rubber stamp?+

Governance has to be moved into the pipeline. Policy as code, continuous compliance, evidence generated with every change, or even recorded at every event. The end-stage review stops being the place risk is discovered. Those with this model matured find it offers way more control, not less.

What happens when you leave?+

Aim to make the deliverable the capability, not just the software. Your team works inside the new system from day one, and because the agent maintains the code under the same conditions it was built with, you own it without needing to staff it. You get maintainability out of the box, you also get an exemplar codebase and patterns to evolve agents with and to bring staff up to speed on.

Enterprise software development with AI agents*

*conditions apply

Modern agents can now build and maintain safe, secure, robust enterprise software at scale. This requires a critical set of conditions.

The opportunity at large

What must be true to succeed

The system conditions

FAQs - Ask the expert

See the blueprint