The future is agentic. Does that mean discarding the lessons of the past?

The days of hand cranking code are over. Outside a few niche domains, teams at the frontier of agentic engineering are now writing very little code by hand. Agentic delivery is steadily becoming the de facto way of producing software – engineers working in partnership with agents to plan, refine and produce working, tested code.

A solved problem?

Indeed, you could be forgiven for thinking that coding is a solved problem and that software engineering as a discipline is a thing of the past - that we have entered the age of the Ralph Wiggum loop, where humans are merely onlookers to a swarm of agents happily burning through tokens in pursuit of a goal.

Or even that software quality no longer matters, so long as the tests pass, the machine understands the code, and the business goals are met. Who cares if the code is understandable to humans?

The reality is, we're all living through a time of enormous and near constant change, where hype and hyperbole dominate every online discussion; where one person's maximalist position or cynical perspective is amplified above all else. Finding the signal in the noise is a challenge in itself. What is actually working in this new world, and what isn't?

We’re all still figuring this out

For some, life at this bleeding edge will be entirely reasonable. When software is ephemeral, throwaway or carries zero business risk, quality arguably matters less. But what happens when the consequence of failure extends beyond minor inconvenience and starts impacting lives or company bottom lines? Are you comfortable with the idea of business-critical software being generated with minimal human oversight?

The fact is, the new rules and practices are still being written, and we're all in the process of figuring them out¹. It will be several years before any real consensus is reached. But amid all the flux, it is fair to say that some things will likely never change. Strip away the hype and the fundamentals of good software engineering – maintainability, understandability, sufficiency, consistency, etc - are as important today as they have ever been. If anything, they matter even more.

But pull the lens out a little, and what else holds true. What are the truths that underpin high-performing teams with AI? This is not an exhaustive list, nor is any of this new. It's that AI has reminded us of the realities of how the best teams have always operated – small, lean, accountable and focused on business outcomes.

Accountability stays human

You can’t outsource accountability. Our attitude to risk is shaped by how likely something is to go wrong and what happens when it does. The greater the potential fallout, the less tolerant we become of risk - we are more accepting of risk when the stakes are low; we demand near certainty and predictability when they are high. Put it this way: would you fly that plane if its software had been built entirely by a swarm of agents? When something goes wrong, we need to be able to stand by our choices.

Throughput must be constrained by understanding. There’s a temptation to believe that LLMs have become so good that they can be both judge and arbiter of their own work - that code is now so cheap, quality matters less, and the machine will do it all. But if human accountability is to remain a thing, and it must, then we must continue to understand what we’re building. In systems of any importance, work cannot be allowed to flow faster than we can reason about it. Even at this constrained pace, we’re still moving much faster than when every line of code was written by hand.

Quality is the point, not the trade-off 

Quality drives productivity. The AI sales pitch is almost entirely about productivity. However, the smartest teams are using AI to raise the bar first, knowing that faster and better will come as a result. Adoption cannot be at the expense of stability or increased rework, so embed sensible (DORA) metrics into your delivery to help identify and address issues quickly. And beware the unintended consequences of measuring the wrong thing i.e. Goodhart’s Law. Lines of code generated, anyone?

AI does not replace good engineering. Practices like working in small batches, automated testing, fast CI cycles, and rapid feedback remain essential, as do human-centric activities that maintain quality and reduce cognitive debt - pairing, reviewing and continuous refactoring. Modern engineering practices were never optional; now they’re non-negotiable.

Good design makes AI better. Clear structure and clean code have always made software easier to understand, test and change. Our ability to reason about systems enables us to stand over them. This has not changed. If anything, it matters more. LLMs perform best with clearly partitioned, well-organised systems characterised by strong contractual boundaries and clean code. Left to their own devices, they will quickly drift off course, so a human hand must remain at the tiller. 

Testing first clarifies intent. Writing tests before code forces engineers to think in terms of specific outcomes and behaviours before diving into implementation. Tests (and precise specifications of behaviours to be implemented by an agent) provide a shared contract of expectations between human and machine. This is critical when working with systems that can generate large volumes of code quickly. AI is hugely powerful, but it must be guided, constrained and controlled.

It’s the people, not the tool

AI does not fix a broken process. There’s a reason why high-performing teams work better with AI - they work better without it. They are optimised for flow, feedback and learning. You will get far greater gains from fixing your people and process issues than you will get from throwing AI over a dysfunctional team. This includes addressing the latent bottlenecks and inadequate quality gates that have been hiding in plain sight (likely drowned out by the noise of coding) in so many underperforming teams.

Small, capable teams get more done. A lifecycle organised around silos of specifiers (BAs), validators (QA), and implementors (developers) requires more ceremony, more communication channels, more handoffs, and more headcount. As a result, ownership falls between the lines, and things get lost in translation, resulting in longer lead times and more rework. Small teams of capable people have always accomplished more than a meticulous process filled with average individuals.

Capable people think beyond their lane. Individuals can no longer hide behind the 'complexity' of coding.  The old premise of "where there is mystery, there’s job protection" has gone, and with it, developers must become more T-shaped. Folks who have never stepped outside their React or Spring lane are going to struggle in this new world. The best engineers have always kept an eye on the big picture, on the why, and on what success looks like for the business and its users. This is their time.

Ownership drives motivation. When you only own part of the problem (the code), you worry less about building the right thing – someone else has already made that decision – and focus more on just meeting the specification, not on the wider impact of your changes. Do they deliver the desired business outcomes? Can I challenge or suggest a better way? True ownership and accountability come from owning a problem from concept to delivery.

But judge the context

Mileages will vary. Not all software deserves the same level of rigour. Disposable solutions that solve specific, localised problems do not need to be scrutinised to the nth degree - AI with minimal oversight is your ideal partner. Somewhere along the continuum between throwaway and safety-critical, there’s an inflexion point where humans must retain control. It is a lot closer to the disposable end of the spectrum than you may think. 

Final thoughts

AI hasn’t changed the laws of physics. But it has exposed what has always been true - that the best software is built by small, capable teams that deliver continuously, are optimised for learning, and that are accountable for their outputs, from concept to delivery. 

¹ As an agentic product engineering firm, we've come a long way down this road. Stay tuned for future posts where we will cover how we've adopted agentic into our SDLC at scale.