What Is Still Evolving
The individual practices are taught directly. That editorial choice does not amount to empirical validation of Intent Engineering as a combined paradigm. The team practices remain provisional.
The team and cross-team practices are extensions of the individual workflow, not settled field standards. Some of the problems named here are real, documented, and unsolved. That is the bar this book uses.
What is known and working
The individual-scale practices are documented in a growing body of evidence. Spec-Driven Development (SDD) at PR scope (one change folder, one spec, scoped to a single change) appears across OpenSpec, Spec-Kit, LeanSpec, and GSD variants as of mid-2026. The change-folder-as-isolation primitive for parallel work is this book's extension of those workflows. Intent-first PR review follows from matching review style to PR class.
Short-lived branches and trunk-based development have decades of documented practice behind them. The Intent Engineering application is narrower: change folder scope matches branch scope, and PR class matches review style.
The working taxonomy groups incompatible specs, stale agent instructions, context poisoning, and agent-accelerated drift as related team-scale failure modes. That grouping is synthesis. The controls above them remain unfinished.
Sources: Rick Hightower, "Agentic Coding: GSD vs Spec Kit vs OpenSpec vs Taskmaster AI", Spillwave, February 27, 2026, OpenSpec, Spec-Kit, LeanSpec, and GSD as active SDD variants. The change-folder-as-isolation primitive and intent-first PR review mapping are this book's synthesis.
What has patterns but not consensus
Multi-team coordination via shared ADR repositories borrows from mature architecture review cultures. Agent workflows still diverge here: one company keeps a central architecture repo, another mirrors ADRs into each product repo, a third links out from AGENTS.md and hopes developers follow the trail. Shared decisions are the recurring pattern. The packaging is still all over the place.
Inner source for .agents/ libraries follows well-understood shared-library mechanics. What is not standardized is versioning: when a shared skill file changes, how do dependent teams know? How do they test the skill against their own codebase before adopting the update? In the sources reviewed for this book, no shared package-management convention for agent instruction files appears as of mid-2026.
Multi-LLM critique (using a second model to review a spec before implementation) is not yet codified as a standard step in the SDD sources reviewed for this book as of mid-2026. Which models to use, how to structure the critique prompt, and how to weight the critique output against the developer's judgment remain matters of individual preference.
Sources: Rick Hightower, "Agentic Coding: GSD vs Spec Kit vs OpenSpec vs Taskmaster AI", Spillwave, February 27, 2026, the divergence across SDD frameworks and the absence of standardized review steps.
What is genuinely open
Documentation freshness worries me more than agent handoff. Files under docs/ age quickly after a run of change proposals. One or two people end up nursing the documentation and checking whether archived changes altered a decision, design, architecture boundary, or constraint. Agent instructions do not detect the missing update. A skill helps only when somebody remembers to run it. I still resort to asking an agent to compare the documentation against the source tree, which is useful but not a durable control.
OpenSpec and current Spec-Driven Development (SDD) workflows focus on the change and its code. In the workflows I reviewed for this book through mid-2026, I found no convincing feedback path from a completed change into the durable documentation set. Keeping Documentation Up to Date offers structural tripwires, but those checks detect suspect files rather than understand whether the design is still true. This part needs more work.
Infrastructure is another weak spot in my experience. Continuous Integration and Continuous Delivery (CI/CD), environments, and metrics belong in the intent, but I have worked on product teams that did not own those systems. A separate pull request and another group stood between the feature team and a change to development, staging, or production. The repo-local loop in this book does not account for that coordination cost yet.
There is also a capability floor. Among the coding agents I have used in 2026, weaker and cheaper models miss decisions and ignore instructions often enough to make this workflow frustrating. The book should not imply that any model with file access will behave the same way. Better models will move this floor, so I expect this assessment to need revision.
Multi-repo planning remains a gap in the SDD sources reviewed for this book. When one feature needs coordinated changes across three repositories, somebody still has to sequence the work, line up the PRs, and decide which repo carries the contract change first. OpenSpec's Workspaces roadmap names multi-repo planning as an in-development team problem. That is a straight admission of a gap, not a workflow.
Agent-to-agent handoff, where one agent completes a spec and hands the change folder to a different agent for implementation (across session boundaries), is experimentally described by Yegge's Agent Fleets framing but not yet practiced in any consistent form. The tooling does not yet support reliable agent memory across session boundaries in a way that makes handoff predictable.
No framework in the sources reviewed for this book has delivered governance without bureaucracy at scale. The practices described here are voluntary and pull-based. Teams adopt them because the local payoff is obvious, not because a central group wrote a policy deck. In the sources reviewed for this book, large-scale consistency still comes down to champions, review habits, and a few teams doing the tedious maintenance work. That approach does not scale cleanly to two hundred developers spread across ten repos.
Sources: Steve Yegge, "Revenge of the junior developer", Sourcegraph blog, March 22, 2025, the Agent Fleets stage of the six-wave model as the framing for agent-to-agent handoff. Fission AI, OpenSpec (ongoing), Workspaces roadmap naming multi-repo planning as an in-development team problem. Governance without bureaucracy is this book's open-problem framing.
The evidentiary bar for this book
The bar this book applies to itself is simple: strong claims need strong evidence, synthesis gets labeled, and moving practices get time bounds.
The individual practices (Foundation, Agent Instructions, Spec-Driven Development, Quality) have enough precedent to teach directly, but documentation feedback is not solved. There is less evidence for the team practices, and teams have not converged on one way of working. I expect to revise parts of this chapter as the field develops.
The next evidentiary step is empirical: worked examples other teams reproduce, reusable templates they adapt, and reports comparing changes before and after adoption. Useful reports should include the failures and upkeep cost, not only the clean result. The paradigm should change when repeated practice exposes a weak boundary, a needless artifact, or a control that fails under deadline pressure.
Intent Engineering is presented as a working synthesis for 2026, not the final form of the discipline. Publication starts the useful part of that process. Teams have to apply the practices, remove what does not earn its upkeep, and report where the model fails.
The current SDD tool set is still fragmented: multiple frameworks, different trade-offs, no dominant approach, significant experimentation still underway. That is the picture this book found. The individual-developer story is further along. The team and organization story is still messy.
These questions are unresolved. Some tooling gaps will close before the next edition. Documentation drift, ownership boundaries, and weak review discipline will remain when frameworks get new names. The work now is to distinguish limitations in today's tools from problems that require engineering judgment.
Sources: ThoughtWorks, Technology Radar Vol 34, April 2026, semantic diffusion across spec-driven development and harness engineering terminology, with no single dominant framework named. The "fragmented" reading of that assessment is this book's.