This article explores SDD through the lens of someone who lived through modelling days past. I acknowledge that “this time it might be different”, so I’ll focus my concerns on the flawed idea that implementation is the mere execution of a known scope. Rather, implementation is an essential part of the discovery process itself. And the further we remove ourselves from it, the harder it becomes.

Quick recap: what is SDD?

The idea with SDD is to capture the intended behavior in a structured specification. We then let a coding agent execute the resulting tasks and generate design docs, etc., in the process.

Yet, as Birgitta Böckeler points out, SDD seems to come in several forms. It can be anything from a relatively lightweight way to drive agents to a strong form where the spec itself is the ground truth. It’s the latter I’m concerned with.

The risk is that SDD becomes the latest iteration of an age-old manager dream: have your skilled seniors specify what to build, then pass it on to the seemingly simpler “implementation” while pretending that step is predictable and somehow less important. In the 1990s, “implementation” meant a team of coders kept in the dark. Today, it’s obviously agents.

The process didn’t work well back then. As both the pace and expectations on a software delivery are orders of magnitude higher now, I’m sceptical about how well SDD will work this time around. Not due to waterfall thinking — many SDD practitioners evolve their systems iteratively — but rather due to the nature of problem solving.

The pull: a need for predictability

Software development is at a crossroads. The best possible outcome of the agentic revolution is that we raise the bar for software engineering. We know what’s good for us: strong automated test suites, continuous delivery, small increments, modular architectures, and top-notch code quality.

We also know that GenAI is stochastic. But so too is a group of humans collaborating on software. And if history taught us anything, the solution isn’t just better input but also faster feedback loops. Let me elaborate by travelling back in time to the model wars.

The Emperor’s new executable clothes

SDD is strongly reminiscent of the Model-Driven Architecture, Executable UML, and the glorious Rational Unified Process (RUP) of decades (fortunately) long gone.

Early in my career, I used these technologies at two different companies. In the first one, we had an effective design review process. As a developer, I’d basically sketch out the software design as a UML class diagram, complement it with some sequence diagrams for the dynamics, and did a walkthrough for my peers.

Yes, the process was slow. But what we designed usually worked as a direction on what to implement. The real advantage, though, was that the resulting UML diagrams served well for onboarding and extensions. It was easy enough to get the high-level view of the solution, which helped when later drilling into the code.

Subscribe now

So far so good. Then came the tool vendors. I mean, if you’ve already sketched out your design, why not take it full circle and generate all code from that sketch? After all, code is just an implementation detail, right? All that was needed was to extend UML with an “action language” to capture those “details”.

How well did it work in practice? Oh, the first victim was the documented design. The executable diagrams turned so bloated and verbose that they became literally incomprehensible. After all, the new audience was a compiler, not humans.

Changes and extensions got painful. You see, all those power tools we’ve gotten used to — build pipelines, command line utilities, IDEs, linters, etc. — didn’t exist in the vendors’ design tools. Imagine coding in a Microsoft Word document. That’s how it felt.

The cognitive perils of a strong spec

Tooling was only part of the model-driven fiasco. A stronger problem was the process mindset at that time. Agile was brand new, and few people were familiar with the movement outside narrow programmer circles. Virtually every company I worked with operated in waterfall mode.

However, back then, the expectations on a software delivery were quite different. Today, with daily deployments being the standard, we just cannot afford to be slow in acting on feedback.

Human problem solving is inherently iterative and driven by reflection in action. We learn by doing. Express an idea in code, test it out, observe, and learn. The cycle expands our understanding of the problem we’re trying to solve. That improved understanding is then translated into modifications to the program, which we in turn observe and learn from. Rinse and repeat. We just cannot short-circuit that.

No, I don’t mean that we shouldn’t think things through early on. We should. And we should write stuff down to make it more concrete and invite a conversation. That helps thinking, too. But we need to treat that document as an imperfect starting point rather than the finished product.

The most underestimated aspect of code: requirements explosion

The main challenge starts if we work from a spec as if the problem was already understood. The reason is the concept of requirements explosion. The term was first coined by Robert Glass. Glass argues that “for every 10-percent increase in problem complexity, there is a 100-percent increase in the software solution’s complexity.”

In other words, each requirement in the spec will lead to tens of implicit design requirements that need to be resolved. We cannot leave that as guesswork for an agent to figure out.

To make SDD work, we would have to provide directives that let agents resolve a large share of all those implicit requirements.

So, couldn’t we complement our spec with a detailed solution model? We could. But it would lead us on a march with three major obstacles:

1. Free text lacks precision. Yes, we can explain constraints, etc., in text, but that becomes verbose and hard to check. Even structured prose and checklists leave room for ambiguity. That’s why we have programming languages. Those are excellent at capturing precise rules intended for machines.

2. We cannot know the solution requirements up-front. Remember: we learn by doing. And if we don’t and rather have agents make those decisions for us, it becomes orders of magnitude harder to derive and capture the solution requirements. Think reverse engineering a legacy codebase. That’s the position we’d be in. Constantly.

3. Extending requirements specs with implementation details and contracts blurs the model: This is what hit hardest back in the MDA/UML days: the model starts to become the implementation and loses its value as an overview, a different level of abstraction. Code just needs another level of precision.

The moment a model becomes the implementation, it ceases to be a good model.

The other road ahead

SDD is something I’ll continue to observe but sit out on for now. However, that doesn’t mean I don’t value structure and a certain predictability. It just means we should look for those qualities elsewhere.

Predictable progress rests on domain expertise, intention-revealing software design, automated safeguards for our code and its behavior, and rapid visual feedback, all amplified by a highly skilled team. Those capabilities are harder to grow than a spec. But they are also far more valuable. With or without SDD.

And now you’re reading this article. So a fair question is: is there a real person with their own experience and views behind it? Assuming the answer is “yes”, why would that matter?

What follows is my list of ingredients for Code for Humans and Machines. It explains how I work with AI as well as the consequences of outsourcing writing to it. Ultimately, it ties into the purpose of writing, which should go deeper than content production.

Does it matter if content is AI-generated?

Yes.

AI-written content has a peculiar flavour. LLMs employ several advanced stylistic devices. These give AI content its tell-tale signs, serving as mental cues to immediately scroll past. It’s not about quality per se. More like: If it was effortless to produce, it simply carries less value.

That reaction is not just me. Research shows that we rate identical works as more valuable when we think a human, rather than an AI, created them: Humans versus AI: whether and why we prefer human-created compared to AI-created artwork.

Feelings aside, my main problem with AI-generated content is that it is so bland. Yes, individual sentences can be expressive, even snappy. But the overall effect is repetition, verbosity, and a lack of sharpness. Impressive in the small, exhausting at length.

Losing the benefits

Consuming LLM content is one thing. It poses an even larger challenge for the writer.

For decades, I’ve used writing to explore and understand various topics. Writing is an active process, and the very act of expressing an idea in text is itself a valuable way to learn.

I often start writing about topics I’d like to think I already master. Still, I frequently discover a gap in my understanding or an edge case I hadn’t considered. Writing is learning. LLMs take away that component.

That, too, is backed by research: writing is not just a way to report thought, but a way to develop it.

Subscribe now

How much AI do I use?

There’s a crucial difference here: I do use AI a lot, but not to generate articles.

Iterating on sample code

Most of my articles contain code samples. Historically, those samples have been time-consuming. Not only do I have to find relevant examples; the code also needs to exhibit a specific design problem. Coming up with artificial code examples is hard enough. Coming up with examples that are “bad” in a specific way is next-level hard.

AI largely automates that process. I can iterate on sample code, instruct the agent to make it more or less complex, and even ask it to amplify some code smell for illustrative purposes. I love that.

Research assistance

I’ve always made it a point to base my recommendations on research. The real, peer-reviewed kind.

In the past, a lot of that work was repetitive searches on Google Scholar and university databases, trying to identify relevant papers. After skimming too many not-quite-what-I-need papers, reviewer fatigue would kick in.

An agent is, of course, a superb support for these types of tasks. I use AI a lot to narrow down my search. I probably spend the same amount of time in total, but now the bulk of that time is spent reading and understanding relevant material.

Review and feedback loop

This is where AI shines. It’s good at identifying inconsistencies, and offers a rapid feedback loop.

90% of my writing is rewriting. The first draft is usually quick, but I do multiple iterations where I tweak, clarify, and try to improve the flow and structure. Continuous feedback is useful.

Unblocking writer’s block

I have a tendency to get stuck on certain parts of a text. I know what my message should be, but I cannot get into the proper writing flow. Here, AI is wonderful: I type down a stream of consciousness and ask the AI to refine it.

Ultimately, I tend to throw most of that generated text away. Occasionally, I keep parts that I tweak. But getting a starting point — even if imperfect — helps more often than not.

Indirect influence

AI impacts my work in other ways, too. I mentioned earlier how LLMs mimic advanced stylistic writing patterns. Think of lines like “It’s not only an X. It’s a Y,” or the classic em dash.

I actively minimize my use of these tricks. The LLM tendency to overuse the em dash in particular is a tragedy — I employed it heavily in my pre-GenAI writing.

Why I write

Writing with AI support is a more enjoyable process. However, writing that is meant to be read is still 95% human effort. Any attempt to short-circuit that process comes with a cost: bland text and a lost learning opportunity. It’s self-defeating.

At the end of the day, the personal question each writer has to ask is:

Why do I write?

But there is a cost we are still underestimating. Agentic coding is mentally expensive.

I can usually sustain the pace for a couple of hours. Then I need a break. The pace is simply too intense. And based on conversations with other engineers, I do not think I am alone in that.

That is the trade I want to unpack here. Agents help us stay with the problem longer, but they also compress too many meaningful decisions into too little time.

The timeline collapse

Software development was always about making decisions. A typical product requirement quickly explodes into hidden design work that end users never see. Architecture, naming, boundaries, behavior, edge cases, test design, failure modes.

In the old days, say pre-2025, work unfolded at human speed, which meant the decisions were naturally spaced out. Today, agents compress the timeline. We have to deal with complexity and decisions that used to be spread over days in a single coding session.

But there’s more. Agentic coding raises the engineering bar, and we just cannot afford to slip. Like skipping e2e tests, ignoring problematic dependencies, or rebuilding library functionality we should have reused.

So we’re now a) facing more complex work, with b) a compressed timeline of decisions. No wonder agentic coding is draining.

Decision density and mental energy

What we are experiencing as modern developers is not new. It just shows up in a new context.

Psychology has studied the mental cost of decision making for decades. One of the most well-known concepts is decision fatigue. Decision fatigue says that the quality of our decisions deteriorates after a long session of continuous choices.

One of the most cited examples comes from judicial decisions. Danziger et al. looked at thousands of rulings and found that favorable decisions dropped as judges moved through a work session. Interestingly, the decision quality then recovered after breaks.

The Danziger study shows what depletion looks like in practice. Other studies suggest the mechanism: making choices is itself mentally expensive. Agents accelerate the arrival rate of those decisions.

Manual coding had a built-in pacing mechanism. That was our implicit recovery break. And it’s now gone.

Why this is hard on the brain

This lines up neatly with cognitive load theory.

Sweller’s classic work on cognitive load focused on problem solving. When too much information has to be held and manipulated at the same time, reasoning suffers. Agents might remove lower-level serial coding work, but they also increase the amount of high-level state you have to evaluate.

Working memory is limited too. You might have heard about the classic “seven plus or minus two” rule. Turns out that was over-optimistic. Modern cognitive scientists paint a more depressing picture: we can, at best, hold 3-4 things in our head at once and still be able to reason effectively.

Now, any non-trivial software task involves plenty of moving parts. Even with agents, we still have to decide which parts matter, how they interact, and whether the design still holds together. It’s a lot more architecture per minute.

Subscribe now

The interruption problem on steroids

We all know that traditional task switching is cognitively expensive. It harms our focus, and hurts performance.

However, what’s less known is that self-interruptions tend to be even more disruptive than external ones.

Coincidentally, agentic coding is like an open invitation for more self-interruption. The agent:

• asks a question,

• produces a diff,

• gets blocked by a missing tool,

• fails a test, or

• suggests a change that looks almost right but touches too much.

Each event pulls you into a new review-verify-steer decision.

The AI productivity paradox

This also helps explain why the productivity story around AI coding tools is more complicated than the marketing slides suggest.

One of my favourite studies gave experienced open-source developers access to AI tools. It was a controlled trial, so half the participants were still coding in the old school way.

At first glance, the study seemed to confirm the usual story: the developers with AI tools felt faster. Indeed, they claimed so themselves, estimating a 20% speedup. Only problem: they were not. They ended up 19% slower than the non-AI group. Adding insult to Big Tech injury, the study also demonstrates that even expert developers overestimate the AI impact on developer productivity.

One plausible contributor is self-interruption. Developers get many natural pause points: waiting, reviewing, correcting, etc. Each of those pulls you into a different task.

How I try to manage it

AI is now an integral part of our work, and we do not want agents to slow down. Speed is kind of their point.

But we do control when and how we actively interact with AI:

• The simplest tip is to keep agent tasks small and iterative enough so that the review fits in your head

• That includes designing for cognitive resourcefulness: automate everything that can be automated. (You don’t want to spend time reviewing coding rules, checking test coverage, etc.)

There are also things that I actively avoid doing:

• Don’t review details, verify them. This was a hard one personally, but we need to accept that we can no longer know every line of code. Again, automation and safeguards are the mechanisms for delivering trust, not manual inspection.

• Avoid parallel work. I typically have one long-running agentic maintenance task that I just babysit, and then one focus task. Never more.

That last point is important given the running-twenty-agents-in-parallel hype. I cannot even think about twenty meaningful things to build, and even less so about the resulting cognitive tax of the likely interruptions. It’s exactly the wrong thing to even consider. At least for humans. (And yes, I understand sub-agents and machine parallelisation. That is not what I’m objecting to. It is the parallelisation of human attention that does not scale).

Finally, and this will bring me enemies from the corporate ladder who think software is built by typing: take breaks from your agents. And take those breaks earlier than you think you need them.

Those breaks are not just recovery. They are also a chance to build the skills the new developer role demands. So use those non-coding hours to deepen your domain expertise. A few ways to do that:

• Train as an end-user. This is the single best way towards becoming a domain expert. Master the problem domain.

• Grab a coffee. Many of the best ideas come away from the laptop. Your brain needs the occasional change of setting. Under the hood, it keeps operating. (The majority of all brain activity is automated and subconscious). When you relax, your brain delivers its insights that were worked on in the background.

• Do exploratory testing. Yes, automation is great, but there’s no limit to the creative ways we humans can break a system. Make it a challenge.

• Understand your product metrics and usage patterns. What features are people using, what are they ignoring, etc. This gives a different perspective on your code. Promise.

• Get involved in sales. This one might not be for everyone, but technical sales is a challenging role that gives you a much deeper understanding of where your product needs to be.

The point is to re-invest the time agents save into activities that deepen your expertise while giving your brain a recovery window.

Agentic coding is still new. But it's becoming increasingly clear that the workflows around agents have to respect human cognitive limits. The future holds more software than ever, and we need to come prepared to build it in a sustainable way.

After more than 30 years as a programmer, I no longer code manually. Sometime in October 2025 I went 100% agentic, and I’m not planning on going back.

My agentic shift came after decades spent learning various programming languages, tools, and ecosystems. That’s a massive investment in skills that are now, at least partly, automated.

So what happens next? Will there even be such a thing as a software developer in a few years? Or will our profession go the way of the lamplighters and horse carriages?

This Isn’t the Same Job Anymore

Agentic workflows have moved us way past mere prompting and into something closer to delegation and orchestration. And that gives us a view of what lies ahead.

In the short term, two forces are pulling in opposite directions:

1. Automation reduces the need for manual coding, suggesting fewer software people.

2. Yet expanding system complexity increases the need for more builders.

My bet is on the second force exerting the strongest pull. There has yet to be a technological revolution that did not expand the scope of what we build. AI will not shrink software. The future will see more software than ever, as there’s an infinite — and growing — amount of tasks to automate via code.

The difference compared to earlier seismic shifts is the pace. The industrial revolution took roughly 80 years (1760-1840), giving society time to adapt. This time, we don’t get generations. We get months.

The Illusion of Instant Software

You probably see this in your LinkedIn and X feeds. They are filled with stories like building a Linux clone in Visual Basic by chatting to a Claude Code cluster over voice. While taking a bath. No prior coding experience. No deep technical background. Just a prompt and a generous supply of tokens.

Now, here’s the reality: Building the first prototype of a product or feature was always the easy part.

Roughly 95% of the cost of a software product occurs after the initial version is released. Turning a prototype into a stable, reliable, and evolvable system is where the real work starts. Shipping is optional. Maintaining is not.

Once you have users, you get pressure:

• new features,

• bug fixes,

• scaling concerns,

• integration challenges,

• and a constant need to evolve the system without breaking it.

AI does not remove that complexity. Building successful production software has never been easy, and it won’t suddenly become trivial. Design, architecture, and what to build — the hardest parts — cannot be automated.

The Objection: “AI will handle it eventually”

But wait: did I really say that not everything will be automatable? I did. And that usually gets the same response:

AI is improving rapidly. Soon it will be able to build and maintain complex systems on its own.

Usually stated in a flat, matter-of-fact voice, as if that settles it.

It’s an appealing idea. I also believe it’s flawed—for at least three reasons:

1. We keep raising the bar

If we had stuck to the problems of the 1970s, programming would already be trivial. We didn’t. Instead, we created better tools, languages, and abstractions to take on bigger and more complex problems. AI will likely do the same.

Tomorrow’s systems will be even more ambitious.

2. Many Real-World Systems aren’t AI-Ready

Most real-world systems simply aren’t ready for autonomous agents. Long-lived legacy systems are shaped by years of implicit assumptions and accumulated technical debt while still being business critical.

For an agent to perform well, data quality is key. And in software, code is the data. Most production codebases are inconsistent, under-tested, and full of edge cases that even humans struggle to reason about. Sure, AI is useful on legacy systems, but fully autonomous development remains a pipe dream at best.

3. You can’t bet your career on “soon”

You just shouldn’t bet your career on the hopes and promises of “soon”. Even if full autonomy eventually becomes possible, the real question is: When?

We’ve been hearing that “AGI is around the corner” for years. Maybe it is. Most likely it isn’t. (Coincidentally, the AGI narrative is pushed by people who happen to sell language models...and rely on external funding for them).

Personally, I’m not waiting. I’m preparing for a world where the developer role changes. I’d rather be early than obsolete.

Subscribe now

Coding is Dead

Agents are automating the act of writing code. It’s easy to feel threatened. Uncertainty about one’s professional future is a big drain.

But here’s the good news: Code has no intrinsic value. It never had. (We just built our careers pretending it did.)

Code is a means to an end. What matters is what the code enables—the system, the behavior, the product. And this is where the human developer comes in. Because that human role does not disappear. It shifts.

Developers in 2027: Two Emerging Paths

I see two emerging and complementary developer roles:

First we have the expert generalist builder. In an AI-first workflow, the expert generalist is responsible for:

• deciding what to build

• deciding how to build it (at the system level)

• breaking work into meaningful increments that can be delegated to agents

These responsibilities are not new. They have traditionally been split across:

1. product managers

2. software architects

3. technical leads

What’s changing is that these three specialist roles are collapsing into a single generalist role. No, it won’t be an easy job. Each one of those used to pay well in the past. Now one individual has to master them all. But for one salary.

Alongside that, I also see a second role emerging: the enabler.

The enabler is responsible for the meta-layer of development. The work that makes agentic development effective by:

• optimizing build and deployment pipelines

• capturing constraints and patterns in machine-friendly formats (think: present day SKILLs)

• improving testability and optimizing coverage

• refactoring legacy systems to make them AI-friendly

This role is not about shipping features. It is about enabling agents to build features well. As such, the enabler is a vital support role for the expert generalist.

But what about all our hard-won knowledge?

All your prior knowledge will serve you well in the AI age. Rather, the challenge is to keep on learning. Continuously.

To be an expert generalist, our learning and purpose needs to shift. Details aren’t as important as the larger picture. For example, it might be more important to know the type of problems and systems that are a good fit for the Rust language rather than mastering the borrow checker syntax. The former is a strategic tool, the latter a now automatable task.

Unfortunately, and these are the bad news, the future of development will probably not be for everyone. I met great programmers who code because they love to code. And now those days are gone, with no obvious financial incentive for bringing them back.

But another group of developers are likely to thrive. As much as I loved to code by hand, I enjoy agentic coding even more. To me, code was always about what I could make it do, not syntax, not craft, definitely not the typing. Agents get me there faster.

My main worries early on were around just problem solving: When machines carry out our execution, how can we still stay in the loop to maintain effective mental models of the problem we’re working on? You see, problem solving is not a one-way street. It’s a constant iteration between observing, expressing, and reflecting.

Agentic Coding: Supporting Flow

Surprisingly, I’ve found that agents can support and strengthen that flow. In the past, I could easily get sidetracked by secondary tasks. Like restructuring the emerging code. I had an idea in my head, but now I wasn’t working on it; I was working on supportive and related tasks, but not the core. With agents taking over the details, I find it much, much easier to maintain the high-level thought and iterate on it.

That said, there’s a flip side to it.

Software development is definitely more mentally effortful with agents.

Maintaining a constant focus is draining, and I find that I can usually only sustain that intense high pace for a couple of hours before needing a break. (Thankfully, I can let a long-running agent make progress while I sip coffee).

Final Thought: From Coding to System Design

With AI, the developer’s role shifts from writing code to designing systems that can evolve safely, with agents doing the grunt work. But agents won’t replace human taste when it comes to deciding what to build.

Taste is a human quality. And building the right system is going to be key. Faster coding? Not so much. It’s already a commodity.

Even if code no longer serves as a moat or job security, strong engineering remains a competitive advantage. Teams that succeed in this shift to agentic development will iterate faster and build better systems. This is where systems thinking and domain expertise come in. Knowing what to build and how to build it matters more than execution.

Throughout my decades in various software companies, I’ve seen plenty of promising products fail. Not due to any flawed product ideas, but rather due to buggy, sub-par code preventing organizations to ship when the opportunity was rife.

If there’s one truly good thing coming out of the agentic revolution then it’s this: for many, bad code might become a distant memory of times less enlightened. But mark my words: an AI won’t set you up for that success on its own. Developers who fail to adopt are likely to ship the same sub-par code, only faster. Because the future of software development will not be less engineering. It’s more engineering at a higher level of abstraction.