The Specification Domain

The Division of Operating Domains

The AI-assisted paradigm introduces a division in the operating domains of software engineering.

In the previous era, an engineer was concerned with both the design of software and its implementation. You thought about what to build, and then you built it. Traditional development already recognizes this separation to some degree, where organizations hire architects and implementers, and the division between “what” and “how” is a recurring theme in software engineering literature.¹ But in practice, most engineers still operated across both domains daily. Design and implementation were interleaved, each informing the other in tight loops.

The future I see is an explicit separation between the engineering involved in designing software and solving engineering problems, and the translation of that design into functioning code. The parallel to memory-managed languages is exact. Engineers once dealt with program logic and memory management; suddenly they only dealt with one half. Now, engineers deal with design and implementation; increasingly they only deal with design.

Engineers of the Specification Domain

Engineers of this emerging era operate in the specification domain. They still solve problems, hard problems, problems that require deep expertise and careful judgment. But their output is a set of natural language documents that describe the system: its architecture, its behavior, its constraints, its edge cases. The AI handles the compilation step, converting those specifications into functioning code.

This is more a focusing of attention than a reduction in scope. Specification-layer problems (drift between intent and implementation, quiet assumptions that conflict with future requirements, over-engineered abstractions, under-specified edge cases) have always existed alongside implementation problems. Engineers dealt with both. Now they can focus on the layer where design decisions live and where the consequences of good and bad judgment are highest.

There is still substantial work to be done here, and real craft involved in doing it well. But at this moment, we are not paying enough attention to it, because we conflate our interaction with AI as an end-to-end operation covering both halves of the task.

”I Have Never Read the Manifest Code”

A memorable engineering effort in building Workscope-Dev was a large refactor of the manifest system: the mechanism that tracks which files are installed, manages updates, and handles uninstallation. It touched every stage of the build pipeline and every lifecycle function in the product. I spent my effort on the design: stressful decisions about what data to include, how to handle edge cases around content preservation during updates, how the manifest must be handled specially in certain phases. I agonized over every design choice and felt genuine relief when it was complete and covered by tests.

I have never read the Python code that implements it.

This isn’t neglect. It’s the new relationship between the engineer and the implementation. The specification is the system. The code is the compiled artifact. I must trust the compilation step (with its rails and safeguards) the same way a traditional developer trusts their compiler: not blindly, but through verified output.

This isn’t skipping validation. The tests pass. I’ve stepped through each phase of its process and confirmed that its behavior matches the specification. But reading the implementation line-by-line would be like reading bytecode: technically possible, occasionally useful for debugging, but not where I add value.

Why Spec Diffs Get More Scrutiny Than Code Diffs

In this new operating model, something counterintuitive happens: specification changes get more careful review than code changes.

A few things drive this. First, design is my assignment. The human is responsible for architecture and specification, and when AI drafts specs on my behalf, I read every word because it bears my judgment. Second, specification errors propagate forward. A design inconsistency may not only cause a bug but also make entire phases of future work impossible. You don’t want to discover on the front lines that your troops have the wrong formation. Third, the return on careful review is highest at the design level. Nearly every significant error I’ve caught in a year of AI-assisted development was at the design layer, not the code layer. Automated quality systems catch code-level issues effectively. But design-level issues require the engineer’s judgment: a missing abstraction, a quiet assumption that conflicts with a future feature, a misjudged level of complexity.

This inverts the traditional review hierarchy. In traditional development, code review is the critical bottleneck. In specification-domain engineering, spec review is.

What Spec-Layer Tooling Looks Like

Building Workscope-Dev has been, among other things, an exercise in discovering what tooling for the specification domain looks like when you build it from practice rather than theory.

Most mature categories of code tooling have a specification-domain analogue. Most haven’t been built yet. Building WSD has made some of them visible.

Multi-agent review is spec-layer testing: automated verification that design documents are consistent, complete, and aligned with implementation. Rather than performing syntax checking, we are performing semantic checking. Does this specification contradict that one? Does the interface described here match the contract defined there? Are there edge cases that two documents handle differently?

Hierarchical task tracking is spec-layer project management: documentation that doubles as executable work assignments. Specifications become the operating system for the build process itself, and a change to a specification propagates through the task hierarchy the way a type change propagates through a codebase.

Rules enforcement with veto power is the spec-layer compiler error. Your design document says X, your implementation does Y, and the system won’t let you proceed until they agree.

These are first-generation tools, built through daily practice rather than elegant theory. The specification domain will eventually have its own mature toolchain. But someone has to build the first versions, and that starts with recognizing that the shift has already happened.