Agility Needs an Executable Specification

A short ticket looks efficient when the people doing the work already share years of context. The analyst knows which exception matters. The engineer remembers why the obvious dependency was rejected. The tester recognizes the edge case nobody wrote down. A standup, a message, and a quick call patch the gaps as work moves. The specification exists, but pieces of it live in people and appear only when somebody asks the right question.

That arrangement is expensive, but human-paced delivery can hide the bill. Work waits while calendars line up. Decisions get repeated because the last conversation was not retained. A new person learns the system by interrupting an old one. The organization calls this collaboration when much of it is manual context recovery. The process feels adaptive because people continuously repair what the work failed to say.

An agent does not inherit the shared memory around a ticket. It receives the context the factory can assemble, makes the decisions that context permits, and fills the remaining gaps with plausible choices. That can produce clean code and the wrong system. The failure is not that the model lacked intelligence. The factory handed implementation an unresolved product decision and treated fluent output as resolution.

Adding a chat window does not fix the mechanism. If every uncertain choice routes to a person, you have built a fast typist attached to a human decision queue. Throughput rises only until that queue fills. If the agent guesses instead, the uncertainty moves downstream into review, testing, or production. Either way, the missing specification controls the speed of the line.

A useful specification connects three layers. The operational layer says where the software lives: who acts, what workflow changes, and which real-world constraints hold. The functional layer says what users can do, what success looks like, and what the system deliberately will not do. The technical layer records the architecture, interfaces, data, dependencies, and tradeoffs that make the behavior possible. Different organizations can name those layers differently. The separation is what matters.

Outer decisions must flow inward. Change a business constraint and the affected behavior should become visible. Change the behavior and the technical work should be recalculated. Without those links, three polished documents are just three places to become stale. A factory needs a connected specification it can inspect, challenge, decompose, and update as evidence arrives.

Specification is not a demand to predict the future or freeze a design before reality touches it. The point is to make the current decision explicit enough to test and cheap enough to revise. Breadth matters first: the actors, boundaries, failure conditions, non-goals, and consequences should exist before implementation goes deep on one friendly path.

Then treat change as an event the factory can route. New evidence should identify which assumption failed, which layer owns the decision, and which downstream work must be reconsidered. A changed requirement can invalidate a plan, tests, code, and release controls. If finding those effects depends on someone remembering a meeting, your process is not agile. It is relying on human memory to perform dependency analysis.

This is where software jobs split. Agents will take over repeatable translation between a decided requirement and proven software. Keeping people in that middle because the requirement remains vague does not protect good engineering. It preserves ambiguity as a source of employment. Organizations that specify decisions clearly will need fewer people to move tickets, relay context, write routine code, and manually check predictable consequences.

Human judgment moves to the choices the specification cannot make for itself: what deserves to exist, which tradeoffs are acceptable, what must never happen, and whether new evidence changes the destination. Those choices gain leverage because the factory retains them and applies them on every run. The model is replaceable. The connected record of intent, boundaries, proof, and correction is the productive asset.

Our position is simple: agentic engineering requires specification. Not a ceremonial document, and not a giant prompt written once. It requires an executable boundary between human intent and machine production. If you cannot state what success means, where the system sits, and what evidence can change the plan, the agents will not make you agile. They will make your uncertainty run faster.