Constraint-Driven Development

When we say spec-driven development, do we mean constraint-driven?

There is a thought I keep coming back to when I look at the current wave of AI-assisted software development:

It is not spec-driven development. It is constraint-driven development.

At first glance, this may look like another of my semantic nitpicks (hidden behind one of the most infamous AI-induced writing patterns). After all, software teams have always worked with some kind of specification, whether that came from a product requirement document, a Jira ticket, a design file, or a technical brief.

But coding agents expose a difference that was always there and that now becomes impossible to ignore. A spec tells you what should be built. A constraint tells you what must remain true while it is being built.

And in a world where agents can translate intent into code with increasing speed and confidence, that distinction matters a lot.

Let me explain.

Why specs are no longer enough

In traditional software development (traditional as in pre-2026), specifications were often incomplete and still somehow workable. Engineers would read between the lines, infer trade-offs, spot contradictions, talk to stakeholders, and silently repair ambiguity while implementing the solution.

That invisible repair work mattered more than many people realized.

However, coding agents do not do that in the same way. They are excellent at execution, but they are much more literal than experienced engineers. If the spec is incomplete, they do not necessarily slow down and question the framing. Many times, they just keep going. They can produce something technically coherent, syntactically correct, and locally reasonable while globally incorrect (or even harmful).

For example, if you ask a coding agent to "build an Airbnb for rural housing in the north of Spain", it may just go ahead and build it. It will fill in the gaps with assumptions about the marketplace, the users, the payments model, the trust model, the booking logic, the property supply, the identity flows, the review system, and the operational model. And if you let it run long enough, it may give you something that looks surprisingly complete.

But is that what we actually wanted? Is it secure? Is it safe? Is it reliable? Is it scalable? Does it reflect the real business constraints, legal constraints, trust boundaries, seasonality, and operational realities of that market?

That is exactly the problem. The more capable the agent is at execution, the easier it becomes to confuse output with understanding. This is why the problem is not that agents need better prompts. The problem is that a prompt without constraints is just a fast way of generating confident nonsense. It just looks plausible on the surface, especially if the reviewer is not an expert in the domain.

That is also why I think the growing narrative around "just give the agent a really good spec" is directionally correct but still insufficient. A spec by itself is often only a statement of desired features or outcomes. What it usually lacks is the boundary system around the problem.

That boundary system is where the real leverage now lives.

What constraints actually do

Let's not think about constraints as decorative details around the work, but instead as the thing that makes the work safe, useful, and coherent.

When we define constraints, we are telling the system:

• what is in bounds and what is out of bounds
• what trade-offs are acceptable and which ones are not
• what the agent can change freely and what must remain untouched
• where humans need to stay in the loop
• what quality bar, architecture, user experience, or business rule cannot be violated

This is much closer to engineering than many people think. Really. It is.

In fact, it connects with something I wrote before in A software development analogy nobody asked for:

when we automate software work, what we are really doing is constraining it with that automation. And you only automate the parts of the system that are sufficiently understood.

The question is? Is generic software development still sufficiently understood? That's probably true for the "outter loop" (producing digital copies of your designed/implemented software) but I wonder if that's true for the "inner loop" (the process of deciding what to build, how to build it, and how to verify it).

In any case, agentic development is forcing us to pay more attention to how we automate this inner loop.

The reason is simple. Agents make the text-writing part of software development cheaper. And when a previously expensive activity becomes cheap, the bottleneck moves somewhere else. As I argued in The holiday when software engineering changed forever, the constraint in software delivery is moving upstream. It is moving away from pure implementation and toward intent formation, context shaping, and constraint articulation.

This is textbook Theory of Constraints behavior.

So yes, code review queues may get longer. Testing systems may feel more pressure. Teams may experience a temporary flood of output. But that is not the same as saying those are now the main leverage points of the system.

The real leverage is earlier. It sits in the quality of the boundaries we define before the agent starts moving.

From feature design to constraint systems

This is also why I think software development roles are changing in a very concrete way.

Historically, a lot of architecture work was presented as feature decomposition, system decomposition, interface definition, and implementation planning. That still matters, of course. But in an agentic world, that is not enough.

The new task is increasingly about defining a constraint system:

• what autonomy the agent has
• what review loops exist
• what trust boundaries cannot be crossed
• what patterns, components, and abstractions must be reused
• what kinds of local optimization are forbidden because they break conceptual integrity

This is the direction I have been exploring in Constraint-Oriented Architectures. The point is not to become obsessed with writing more detailed prompts. The point is to shape an environment where good outputs are more likely to emerge and bad outputs have fewer places to hide.

That is a very different posture. It means the job is no longer just to describe the software. The job is to define the operating conditions under which software can be safely and effectively generated. In other words, the architect moves from drawing the building to defining the laws of physics inside the building site.

Why low-code mattered, and why this is different

I also think this helps explain something that always looked a bit confusing in our industry.

For years, low-code platforms were trying to solve a very real problem: enterprises needed guardrails for speedy development. The way those tools achieved that was by creating a separate system, like a visual builder or a metadata runtime. In other words, a constrained environment outside of normal code.

And that trade-off made sense, so did the solution. You lose flexibility, but you gained safety and speed and autonomy, which is what many teams need.

What coding agents are introducing now is a different possibility: the same guardrails can increasingly live inside the code environment itself. Project rules. Skills. Cookbooks. Design system conventions (DOs and ... DONT's, remember, we need constraints). Architecture constraints. Review workflows.

The interesting thing is not only that constraints can be embedded closer to code. It is that they can potentially be lifted and re-applied with much more fluidity. In a traditional low-code environment, when you hit an exception, you may need some kind of escape hatch. In a constrained coding environment, you can relax one boundary deliberately, solve the edge case, and then restore the system.

That can be a very powerful model.

But I don't think this means visual builders or low-code tools suddenly become irrelevant. Far from it. They may still find a very useful place in the agentic era, especially if a WYSIWYG or metadata-driven experience remains the best interface for certain kinds of product development. The point is not that one model replaces the other overnight. The point is that coding agents open a new path where constraints do not need to live in a separate runtime to be effective.

At the very least, it suggests that the future of software development may be less about finding one perfect specification interface and more about designing the right constraint layer around increasingly capable generators, whether that layer lives in code, in a visual environment, or somewhere in between.

The new inner loop of software development

If this is true (and I am not saying it is!), then the inner loop of software development is also changing.

It starts to look less like:

Spec > Code > Review

and more like:

Explain > Challenge > Delegate > Verify > Steer

Or, if we want to be more explicit:

1. Explain the problem and uncover what actually matters. Some people use plan mode, while others just enter into a Socratic conversation with the agent. Derive the constraints, trade-offs, and non-negotiables from this conversation.
2. Challenge the agent's proposed approach before too much code is produced.
3. Let the agent generate the implementation inside those boundaries.
4. Verify that the result works and that the constraints still hold.
5. Steer direction and go back to step 1 if needed

This is not a cosmetic workflow change, and it changes what good engineering looks like.

The valuable engineer in this world is not the person who can produce the maximum amount of code at the keyboard. It is the one who can distinguish signal from noise, identify what should not be built, encode the right constraints, and know when to challenge the machine before the machine scales the mistake.

In other words, the valuable engineer starts to look a lot like a product engineer: a product-minded engineer loaded with pre-AI principles but post-AI speed.

What this means for the future of software

There is another implication here that I find even more interesting.

If AI keeps making software creation cheaper, then more and more business activities become candidates for software mediation. Things that used to remain manual because the cost of encoding them in software was too high may now cross that threshold.

This is where the idea of services as software starts to matter.

What used to be a human activity supported by software increasingly becomes a software activity supervised by humans.

And if that is the direction of travel, then the bottleneck is not the ability to generate code for those new activities. The bottleneck is the ability to define the constraints, trust loops, and operational boundaries that make those new software-mediated activities trustworthy in the first place.

This is why I don't think the future engineer becomes irrelevant. Quite the opposite. If anything, the future engineer becomes more product-shaped. They become more responsible for conceptual integrity, not less. More responsible for quality of intent, not less. More responsible for shaping review and feedback systems, not less.

The mechanical center of gravity may move away from hand-writing every line of code, but the intellectual center of gravity moves toward something more demanding: deciding what should happen, what must never happen, and under which conditions autonomy is acceptable.

This is why I think the product engineer becomes such a central figure in the AI age. Not because engineering becomes less technical, but because technical leverage becomes inseparable from judgment, prioritization, user empathy, and taste. The engineer who will create the most value is the one who combines strong pre-AI principles with post-AI speed.

That is still engineering.

Actually, that may be software engineering in a more essential form.

Conclusion

So no, I don't think we are moving into a world of spec-driven development. Well, yes, but that description is too shallow for what is actually happening.

We are moving into a world of constraint-driven development through a new form of specs, where the quality of the outcome depends on three things working together:

• the capability of the model
• the quality of the coding agent
• the strength of the constraints

The code still matters. Verification still matters. Product taste still matters. But the leverage is moving.

And as always in software, good engineers will move with the constraint.