From the free book Delta: Closing the Specification Gap (Dhuri, 2026). The PDF is the canonical edition — figures, tables, and code formatting are simplified online.
Where the field actually is, where it is going, and four things that won’t change
“Every AI forecast is wrong. The useful question is not ’what will AI be able to do in five years?’ The useful question is ’what skills will still be valuable when AI can do more than it can today?’ Specification engineering is one of them.” — The engineers who thrive are not the ones who predict the future correctly. They are the ones who build a practice that works across multiple futures. In This Chapter
The Specification Gap never closes itself. Only deliberate engineering practice closes it. Models improve every year. The gap does not close automatically as they do. A more capable model given a vague specification produces a more capable wrong answer. The specification discipline this book teaches closes the gap — not any model improvement.
In five years, which part of your current role do you expect AI to handle routinely? Which part do you expect to become more valuable? The answer to the second question is where to invest your skill development time right now.
Mature. Reliable for well-specified tasks.
Use every day. This book’s core technique.
Production-ready at leading orgs. Mainstream in progress.
Claude Code + CLAUDE.md works. Requires specification discipline.
Works for well-defined pipelines. Novel coordination requires engineering.
Four-Stage Pipeline is reliable. Fully autonomous novel systems: not yet.
Reliable for migration, CRUD, test generation. Novel architecture: research territory.
Use for migration and documentation. Not novel architecture.
Production-ready for specific checks.
Add AI domain review to your pipeline now.
Promising experiments. Not enterprise-ready.
Watch this space. Not a 2026 investment.
A second shift is worth naming because it is reshaping job titles as you read this. The industry vocabulary moved from ’prompt engineering’ to ’context engineering’ and, in 2026, increasingly to ’orchestration.’ The forecasts are blunt: most engineers will spend more of their time directing and reviewing AI agents than typing implementation code, and the hard skill becomes decomposing a problem into tasks that specialized agents can execute and verify. This is not a different discipline from the one this book teaches. An agent you orchestrate is an agent you must specify for, hand off to, and verify — the Frame, the handoff contract, and the Verification Frame, applied to a team of workers instead of a single call. Orchestration without specification is just delegation of vagueness, scaled up. It is also worth saying plainly what the rest of the field is now calling this. ’Spec-driven development’ — writing a detailed specification that an agent references throughout implementation, and treating that spec as persistent, version-controlled context — is the named movement that has formed around exactly the practice in this book. The Specification Frame, the Ten Laws, and treating prompts as code (Chapter 11) are this book’s enterprise-grade, regulated-domain version of it, arrived at from the same evidence. If you adopt one idea from this chapter, let it be that the trend names will keep changing — prompt engineering, context engineering, orchestration, spec-driven development — and the underlying discipline they all circle is the one you already have. There is one more honest thing to say about where the field is. Generation got cheap; verification did not. As of 2026, the measured bottleneck has moved downstream — surveys put the share of engineers who do not fully trust AI output far above the share who reliably check it, and reviewers report that AI-written changes take more effort to review than human ones, precisely because they look right. The teams that come out ahead are not the ones generating the most code; they are the ones who can verify it fastest. That is the strongest argument for everything in this book: a specification is not only how you get good output, it is how you make that output cheap to verify. The Verification Frame in Chapter 5 is the concrete tool; the discipline behind it — specify, generate, then check against the same specification — is what does not change no matter how capable the models become.
17.2 Four Things That Do Not Change Truth 1: Domain expertise is the non-replicable contribution. AI training data contains vast amounts of general software practice. It contains almost no knowledge of your specific regulatory framework, your domain-specific type system, your painful production history, or the invariants your domain experts have learned over decades. The further your domain departs from average internet examples, the more valuable your expertise relative to statistical generation. This gap does not close with model improvements — it closes only when you specify your domain.
Truth 2: Specification precision always determines output quality. Models improve at reasoning, code quality, and error detection. They do not improve at reading minds. The gap between a vague specification and a precise one will always translate to a gap in output quality. Specification skill compounds with every model improvement: a better model + a good specification produces dramatically better output than a better model + a vague specification.
Truth 3: Critical evaluation shifts from generation to review. As AI throughput increases, the bottleneck moves from writing code to evaluating it. The engineer who can review AI-generated code for domain correctness — not just syntactic correctness but correctness against regulatory constraints, architectural patterns, and domain invariants — becomes more valuable as throughput increases. This what Part II of this book teaches.
Truth 4: Security requires continuous active investment. The attack surface of AI-integrated systems grows with capability. Prompt injection, data exfiltration, and agent privilege escalation evolve alongside defensive techniques. There is no point at which AI security is solved. It requires the same continuous attention as application security. Chapter 15 is not a one-time read — it is a quarterly review.
“A useful exercise: ask what your best developers do with AI tools that your average developers do not. The answer is rarely ‘they use better prompts’ — it is more often ‘they know exactly which domain constraints to include without looking them up.’ The best developers have internalized the domain. AI makes that internalization more economically valuable, not less. Hiring profiles benefit from treating domain knowledge and prompting fluency as complementary, not separate.” — Engineering Director, Healthcare Software company
From outlook back to practice. Chapter 18 applies the discipline where mistakes are hardest to undo: schemas, migrations, and queries — specifying reversible change for the data your business cannot lose. PART V SPECIALIZED USE CASES Chapters –1819
Two domains where AI generates the most expensive mistakes. Part V covers database and infrastructure prompting — two domains conspicuously absent from most AI development books and conspicuously present in the kinds of incident write-ups that circulate in published industry reports and post-mortems. These chapters exist because the most common observation in those reports is: ‘The application code was generated fine. The migration and the Dockerfile were generated wrong.’ Part V fixes that.