Blurred lines - better outcomes, not just faster delivery.

AI is revolutionising how software is created. But unlike previous shifts, this one has no steady state. The ground keeps moving - models improve, capabilities expand, assumptions outdate, often week to week. Teams no longer have the luxury of waiting for things to settle; they have to adapt in real time.

With so much change afoot, you can be forgiven for feeling somewhat uncertain about where things are headed. How do teams embrace AI while the rules are still being written? Where should we focus our energies in a world of constant iteration? Which practices should evolve and which should remain intact?

As with any disruption, patterns will eventually stabilise. But even in the midst of near constant churn, several things are already becoming clear:

• Lines are blurring. Roles, responsibilities and skills are all up in the air. The future belongs to smaller, more closely knit teams of experts whose skills are both broader and deeper - less defined by the narrow roles of the recent past, and more by a consultative mindset focused on shaping product, guiding decisions, and delivering meaningful outcomes.
• Focus is shifting. The cost of implementation is dropping dramatically and teams are being forced to address bottlenecks elsewhere in the software delivery lifecycle - coordinating, collaborating, planning and specifying.
• Fundamentals still matter. The hardest part of software development has never been writing code. It’s understanding what to build and why. Sprinkling AI over a dysfunctional team will only amplify that dysfunction. The fundamentals of software engineering have not changed and arguably matter more when non-determinism sits at the heart of your processes.

Blurred lines and why it matters

In a previous post, we looked at how AI is redefining the designer’s role, replacing much of the work once done using tools like Figma with faster, more fluid approaches built around vibe-coding and experimentation.

The equation is simple. More experimentation and faster feedback lead to better outcomes.

This fundamental shift means that designers are now less focused on the mechanics of design and more on the needs of the user and direction of the product. Of course, this was always the job, but until recently, the tooling got in the way. Now, the primary bottleneck is the designer’s imagination.

This shift is happening across the board. Product people now have one foot firmly in the design camp. Engineers are more focused on outcomes, not just code.

The democratisation of prototyping means that everyone can now experiment, including product owners. They may not have the designer’s eye for consistency and detail, but they can use the tools to independently explore solutions and come to the table with a clearer, better-informed sense of product direction, without needing technical help at every turn.

This is a good thing. It focuses everyone on the hardest part of building software, the what and the why. Turning abstract, nebulous thoughts into a coherent product is the work. Anything that brings functions closer together and improves shared understanding between roles will ultimately lead to better product decisions.

To that end, you can expect the product engineering teams of the near future to be smaller and more closely knit. The walls between functions are breaking down for good reason. For too long, slow feedback loops, distance between roles, and unnecessary friction have resulted in the wrong thing being built.

Focus is shifting to the hardest problems

AI isn’t just impacting roles. It is reshaping what we mean by work.

As software delivery evolves to be more AI-native, teams must continuously question what they should be doing less of - what tasks should be handed off to tools (with appropriate oversight) - and what they should be doing more of.

In this new paradigm, much of what we think of as implementation is increasingly becoming unnecessary labour. If you’ve written CRUD or boilerplate code once, you’ve written it a thousand times. It’s not where the value is. (Today, this is meat and potatoes for AI, so hand it off to the tools, provide the necessary oversight, and move on with your life.)

What’s left are the genuinely hard problems:

• Coordinating people
• Managing complexity
• Navigating change
• Deciding what to build
• Determining how to build it
• Agreeing desired outcomes

Far from leading to skills entropy, the opposite is happening. Product, design, and engineering are being pulled out of narrowly defined lanes and into broader, more demanding territory. The skills that matter most now are critical thinking, judgement, empathy, communication, and the ability to collaborate across disciplines.

Rather than reducing the need for expertise, AI raises the bar on how our expertise is applied. Systems of any meaningful complexity will always require deep specialist skills. Those are not going away. But the familiar model of T-shaped skills is starting to feel insufficient. Knowledge workers of the future need to be broader and, arguably, deeper at the same time.

The fundamentals matter more now than ever

If we have learned anything over the past 50 years, it’s that engineering rigour matters. And yet, somehow, in the maelstrom of noise around AI, there’s a prevailing sentiment that we’re now at the point where you can throw some loose requirements at a bunch of agents, and between them, they’ll create the perfect product while you treat yourself to a double espresso.

The reality is there’s a huge difference between building secure, scalable, resilient systems at scale and developing tools and apps for limited internal consumption. Yes, solo developers can knock out simple applications with relative ease, but building essentially complex systems still requires extreme levels of engineering rigour and coordination.

There is a reason why high-performing teams get more from AI - they’re exceptional without it. The best teams mix individual capability with rigorous, collaborative engineering practices. They design systems to iterate quickly, release often and learn rapidly. They work in small batches, integrate continuously, refactor diligently, test deeply and automate relentlessly.

AI pushes at the boundaries of these practices. Turn the code-generating firehose to 10 and teams will quickly find themselves drowning in large code reviews, increasing the risk of regressions and defects.

The safety net of modern engineering practices exists for a reason - to help us keep systems working, make changes with confidence, and protect us from our own failings. But AI is equally fallible, only with the added tendency to introduce flaws at a far greater rate, which only increases the importance of the engineering safety net.

As teams feel the pressure to produce more code, faster, they must hold on to what is tried and tested. Refactoring, testing, automation... none of this stuff has gone away. Ultimately, our AI-enabled processes must be centred on where true accountability lies, and it’s not with the machine.

A computer can never be held accountable, therefore a computer must never make a management decision.

– IBM Training Manual, 1979

Final thoughts

As the cost of implementation (especially coding) approaches zero, AI-enabled engineering is forcing teams to confront the parts of the software delivery cycle that they’ve always struggled with – direction, collaboration, communication, change, decisions-making.

But while the promise of AI has largely been framed around speed, the real gain is freeing up time to address these core challenges – resulting in better quality software and improved outcomes enabled by faster feedback loops, smaller and tighter teams, and the shared responsibility that comes from roles blurring and overlapping.

Teams that embrace this shift while holding firm to stringent engineering practices will find themselves delivering better software. Delivering faster will flow from there.