AI Engineering Is Easy. Do We Really Have to Change How We Work?

In Part 1, I explored why making AI engineering easier doesn't automatically make software delivery easier. In Part 2, I looked at what changing our workflows could actually involve.

But before we go further, I want to step back and question something.

Do we really have to change how we work?

With every new AI capability comes a growing expectation to rethink our workflows, reinvent our processes, and fundamentally change how we build software. But are all these changes necessary, or have we started treating the ability to do something differently as proof that we should?

We've seen this pattern before. A new technology arrives, early adopters experiment with it, and soon there's pressure for everyone else to catch up.

With AI, that pressure feels particularly strong because the capabilities are improving so quickly. If an agent can complete in minutes what once took hours, continuing to work the old way can seem almost irresponsible.

But there's a difference between having a better tool and needing an entirely different way of working.

A better tool can make an existing process more efficient without making that process fundamentally wrong. A new capability can open up possibilities without making every previous decision obsolete.

Yet we often jump straight from this is possible now to we must work differently now.

Imagine your team adopts an AI coding agent. Engineers start delivering changes faster, routine tasks become easier, and the tool proves genuinely useful.

Does that automatically mean you need to redesign your engineering process?

Perhaps your existing process already handles the important things well. Perhaps the new tool fits naturally into it. Perhaps the biggest benefit comes from letting engineers spend less time on repetitive work while keeping everything else largely unchanged.

Of course, you might discover that your existing process creates unnecessary friction once implementation becomes faster. That would be a good reason to make changes.

The distinction is simple: change because you've found a reason, not because the technology has given you permission.

AI creates new possibilities. It doesn't automatically tell us which ones are worth pursuing.

Much of the conversation around AI engineering is necessarily speculative. We're trying to understand what increasingly capable agents will mean for software development, and experimentation is part of that process.

But speculation can easily turn into premature decisions.

We might redesign a workflow around agents that aren't reliable enough for the task. We might introduce layers of orchestration before we understand which parts of the work actually need them. We might optimise for a future operating model while making today's work more complicated.

The problem isn't experimentation. It's treating an experiment as a conclusion before we've seen the results.

We don't need to predict the final form of AI-assisted engineering before we can benefit from it. We can try things, learn from the experience, and change direction when the evidence supports it.

Not every promising capability needs to become part of the team's permanent workflow.

AI can make implementation dramatically faster, but that doesn't mean every engineering task should be handed to an agent. Nor does it mean that manually solving a problem is somehow outdated.

Sometimes, writing the code yourself is the quickest way to understand an unfamiliar system. Sometimes, working through a problem exposes assumptions that an agent might miss. Sometimes, the task is so small that explaining it to an agent takes longer than doing it yourself.

And sometimes, delegating the work is obviously the better choice.

The point isn't to defend traditional engineering or argue that AI should only be used selectively. It's to recognise that the best way to do a task depends on the task itself, not on whether a tool can do it.

We don't need to turn every engineering activity into an AI workflow to benefit from AI.

Perhaps the most useful question to ask before changing anything is also the simplest: what outcome are we trying to improve?

Is it delivery time? Reliability? Developer experience? The ability to explore ideas that would otherwise be too expensive? The amount of maintenance work a team can handle?

Different goals lead to different decisions.

If AI helps a team explore three architectural approaches instead of committing to the first reasonable one, that may be valuable even if delivery time stays the same.

If it allows engineers to maintain a neglected test suite, the benefit might show up months later rather than in the next sprint.

If it helps a small team take on work that previously required more people, the impact might be capacity rather than individual productivity.

And if a new workflow adds complexity without improving any outcome that matters, it's worth asking why we're keeping it.

We need to be careful not to confuse visible AI activity with meaningful progress. More agents, more generated code, and more automated steps are not outcomes in themselves.

Sometimes the best use of a new capability is to do more. Sometimes it's to do the same work with less effort. And sometimes it's to leave a perfectly good process alone.

Sometimes, I wonder what it would be like to go back to 2019. Before AI became part of almost every conversation about software engineering. Before every new release came with questions about what it meant for our jobs, our workflows, and the future of engineering.

Back then, AI was still something we talked about, experimented with, and imagined. There was excitement about what might be possible, but we weren't constantly being told to rethink how we worked because of it.

There was something nice about that space between an idea and its reality. We could be curious without feeling like we were already falling behind. We could learn a new tool because it interested us, not because we were wondering whether we'd become irrelevant if we didn't.

Of course, I'm not suggesting that we should go back or pretend these advances haven't happened. AI has opened up genuinely exciting possibilities, and I'd rather have these tools than not have them.

But sometimes, I miss when the conversation was still just a conversation. When we could discuss the future of AI without feeling like we had to reorganise the present around it.

Maybe it's not 2019 itself that I miss. Maybe it's the feeling of having room to explore technology without every new development becoming an expectation, a deadline, or another thing we need to optimise ourselves around.

There's always another model to try, another tool to evaluate, another workflow to rethink, and another prediction about how engineering will look in a few years. Keeping up can start to feel like a job in itself, separate from the actual work we're trying to do.

We can be excited about what's coming without feeling obligated to chase every development. We can appreciate what AI makes possible while still enjoying the craft of engineering, the satisfaction of solving a difficult problem ourselves, and the simple pleasure of building something that works.

Perhaps the question isn't just what we can do differently with AI, but what we want to preserve as everything changes.

None of this means engineering teams should ignore how AI is changing their work. It means we should resist the idea that every new capability demands an immediate, sweeping response.

We can experiment without committing to a complete transformation. We can adopt useful tools without rebuilding everything around them. We can question established practices without assuming they're all outdated.

Most importantly, we can let experience shape our decisions instead of letting expectations about AI do it for us.

There's no single operating model that every engineering team needs to adopt. Teams have different products, constraints, responsibilities, and definitions of success. What works for a team building a new product may be unnecessary or even harmful for one maintaining a mature system.

The interesting work is figuring out what makes sense in our own context, rather than trying to keep up with an imagined version of the future.

Maybe some things will change significantly. Others won't need to change at all.

We don't yet know how all of this will settle, and that's okay. The technology will keep evolving, our understanding will improve, and some of today's sensible decisions will eventually need revisiting.

But in the middle of all this excitement, it's worth remembering something fundamental: AI was built to serve us, not the other way around.

We're adopting these tools to make our work easier, solve problems we couldn't tackle before, and create more room for the things that matter. We shouldn't end up spending more time adapting to our tools than benefiting from them. Nor should we feel compelled to redesign perfectly functional workflows simply because a new capability exists.

Technology should fit into our lives and help us achieve our goals. When it genuinely makes sense to change how we work, we should. When it doesn't, we're allowed to keep doing what works.

We don't have to treat every new AI capability as a mandate to reinvent ourselves. We can be curious without being impulsive, ambitious without being dogmatic, and willing to change without assuming that change is always progress.

Perhaps we don't need to choose between embracing AI and holding on to the way we work today. We can do both: explore what's possible, adopt what genuinely helps, and leave behind what no longer serves us.

At the end of the day, AI is a tool we've built to help us do better work and, hopefully, make some parts of that work more enjoyable. We shouldn't become so focused on figuring out how to work for the tool that we forget what we wanted it to help us achieve in the first place.

And if, every now and then, we want to slow down, close the tabs full of AI announcements, and just enjoy being engineers for a while, I think that's perfectly fine too.