Why AI is raising the stakes of the software engineering craft

In the age of AI, the craft of software development is more important than ever. It’s arguably even at risk of disappearing: as engineers spend less time writing code from scratch and more time reviewing AI outputs, we risk forgetting the 'why' behind the patterns we use. This means it needs to be protected and nurtured; it’s living knowledge we must actively pass from generation to generation. 

The idea of software being a craft might seem parochial or nostalgic in the context of enterprise-scale systems. However, I’m not arguing that we need to hold on to some kind of quaint valorization of ‘handcrafted’ software. It’s about retaining the knowledge, system understanding and ‘mechanical sympathy’ that allows us to ensure software is built and maintained with intention and care.

AI’s impact on the craft of software engineering

AI doesn't undermine craftsmanship; it raises the stakes. We might know we cannot blindly trust the output of an LLM, but outsourcing tasks to generative and agentic systems can lead us, without realizing, towards a passive mindset in which we shore up significant cognitive debt. In other words, we lose the opportunity to actually learn by doing. The knowledge we accrue from writing code or solving different kinds of problems may come to lack substance. 

It’s important to remain mindful of this, but we also need to acknowledge that software engineering is far more than writing code. And, in a world where AI is doing a lot more actual code generation, the emphasis moves to orchestration and auditing. Whether we’re writing prompts or specs, as is becoming more and more critical as spec-driven development grows in adoption, we need to remain the human on the loop.

It’s true that LLMs now have the ability to assess and evaluate outputs, yet humans nevertheless need to orchestrate those feedback loops and harnesses and, of course, to have oversight and accountability for what the code actually does.

The principles of software craftsmanship after AI

The foundational principles of software engineering remain the same: clean code, testability and decoupled architecture. We’ve known for a long time that these things support developers to amend and evolve software, but what’s particularly interesting is that these things also make it easier for agents to work with code. Messy, complicated codebases are much harder for agents to interact with and will likely lead to poorer outputs.

Alongside those principles, though, we also need to become more active system thinkers. Indeed, good software engineers already do this. They know that the work they do is embedded in a wider ecosystem that includes both an existing codebase but also, potentially a wider range of tools and systems that live beyond organizational boundaries.

But it’s now critical that every developer understands that our craft now really requires us to imagine and design complex, interconnected systems with a deep sense of curiosity and intent. This requires us to bridge both creativity and foundational knowledge: first, solving problems an AI may not, without the richness of embodied experience of context, be able to identify and second, using our experience to ensure a system’s integrity, the thing that ultimately makes it valuable in the first place.

How to commit to the software engineering craft in an AI-dominated age

There are a number of things developers today can do to cultivate and retain a sense of craftsmanship in an AI-dominated field. First, returning to the fundamentals: the patterns, practices and ideas that have emerged over a period of decades to shape software engineering as we know it today. In the latest edition of the Technology Radar we noticed that amongst the new tools, there was also discussion about long-standing aspects of the discipline that were being talked about once again.

Second, we need to acknowledge that we’re ultimately responsible for the systems we are working on. Doing this allows us to do exactly that work of bridging that gap between creativity and system integrity, ensuring we’re focusing on architecting systems that are both functional and thoughtful. 

Third, we need to remain curious. AI’s speed and convenience has the potential to rob us of that by giving us what we believe we want with just a few prompts. Yes, AI can help us deliver at a faster pace, but we need to be able to dig deeper and ask the questions that machines don't know how to ask.

The importance of collaboration and sharing knowledge

There has been much discussion over the last year or so about how AI can act as a kind of pairing partner. There are certainly benefits to working with tools like Claude Code to explore problems or unpack ideas, but at the core of the software engineering craft remains human collaboration and sharing. This is why we did the Future of Software Engineering Retreat in Utah, and it’s why we still get together, face to face, to put the Technology Radar together.

Experienced and senior developers need to set an example to less experienced team members. Questions of code hygiene, and good habits, such as avoiding using AI as a mere shortcut, is important, but it goes beyond that: we need to demonstrate that even with perfectly configured and optimized agents, there is still significant value in our deeply human capacity for imagination, systems thinking nd experimentation with new approaches and patterns courage to experiment with new patterns. We need to keep the flame of curiosity alive in the team.

For those less experienced, embrace curiosity. There’s so much that's unknown and unsettled in this current moment, so ask questions, experiment and explore. But also look to the past and people’s experiences to better understand how to approach and tackle problems. Even if the problems of the past don’t look like yours today, there’s still likely to be something important for you to learn.

Making the case for craftsmanship inside organizations

Talking about software engineering as a craft can be a risk. To some it sounds unserious, as if the work we’re doing isn’t robust and substantial enough for demanding enterprise contexts. Some inside organizations might even see the notion of craftsmanship as antithetical to the kind of speed and gains we should be trying to unlock with AI right now.

However, as technologists this makes it crucial that we continue to make the case that speed without discipline is an illusion. We need to also frame craftsmanship not as an aesthetic preference, but instead as a means of mitigating risk. Developing software without that sensibility not only increases the chances that we’ll ship vulnerable software, introducing new attack vectors, it also creates additional complexity. This has a very real cost for organizations.

Ensuring sustainability in a future where change is constant

At the core of my understanding of software craftsmanship is that it allows us to work in a way that’s sustainable. That’s in multiple senses of the term, from our own capacity as individual developers, to the systems we build and how they’re maintained and evolved in the future. 

Velocity is great, but it shouldn’t become a bottleneck; if it’s pursued at all costs, it will. By prioritizing meaningful impact over mindless output, we can protect the organization's most valuable asset: its ability to evolve and innovate without being paralyzed by technical debt.