If AI writes more code, should we stop designing it for humans?

Valentina Servile argues no. Good software design still matters, not just for people, but for AI agents too. The audience for great code has expanded, not disappeared.

👉 https://t.co/xF8ExkDzW1

Should we still design code for humans?

Source: https://www.thoughtworks.com/insights/blog/programming-languages/should-still-design-code-humans A few weeks ago I attended theFuture of Software Engineering eventin Engelberg, Switzerland. As you might expect from an event that happened in the middle of 2026, many conversations revolved around AI engineering practices and coding agents.

I encountered a range of points of view at the event. Some spoke about preferring to keep agents on a tight leash, reviewing their output line by line to make sure it’s maintainable, well-partitioned and everything else we’ve come to associate with goodsoftware craftsmanship.

Others claimed they’d rather delegate the majority of the software development lifecycle to agents. This group, broadly speaking, weren’t particularly bothered about the code agents actually produce; for them, time is better spent improving the specs and deterministic checks that guide the agent, leaving the agent to take care of the code completely. (As long as the build stays green, of course.)

Will humans never need to look at code again?

The ‘full autonomy’ end of the spectrum is what gives me the most pause. It reminded me of a bigger idea that I frequently see circulating in my social circles and media feeds:

Soon, no humans will ever look at or maintain code again. Will good software design* even matter a few years from now?

This argument goes something like this: as agentic workflows evolve, eventually all humans will have to produce is markdown specs, or context trees, or whatever new interaction pattern will be popular a few months from now. This specification can then be thrown over the fence at a team of AI agents who will generate, test, review, deploy and later evolve the code. Eventually, code might become little more than an implementation detail to most companies; we may even be able to have agents on-call, responding to production incidents at 2am.

Some flavors ofspec-driven developmentalready advocate for treating specs as the new lingua franca of software development, and the code as an ephemeral artifact.

The second line of theAgile Manifestostates*‘working software over comprehensive documentation’.*Should we rephrase it: ‘*Working software as comprehensive documentation’?*This is, undeniably, a challenging question for people like me who take professional pride in crafting clean, readable code. And yes, I admit there’s some conflict of interest: this is, after all, an article by a programmer explaining why programming is still needed.

Nevertheless, what follows is a collection of my personal reflections on this topic, informed by both the conversations I had at the event and my own experience maintaining production systems with the help of agents.

So, throughout the rest of this piece, I’ll explain why I believe good design still matters (even with agents doing most of the changes), why humans must remain in the loop in order to produce well-designed software and why those same humans actually have to keep operating at the code level in order to do so.

But before I get into that, it’s worth first understanding the argument that we’re really just dealing with a further layer of abstraction. In my view, this isn’t the case, and really the belief that itis, is the crux of this issue.

Personally, I’d rather be designing the code with an agent rather than throwing natural language specs at it. Doing so allows the work of resolving ambiguity into a well-organized set of rules to be done incrementally as the code is written. This not only saves time spent going back and forth; it also lets us leverage on code as a shared and non-ambiguous vocabulary for good design while pairing with the agent.