The Definition of the Work
TL;DR I blamed the models when big AI chunks stalled. The real subject was unfinished translation of intent into buildable work. Architecture's program-to-construction-documents path, Definition of Ready, and why commander's intent is not enough for models.
I’ve spent a lot of hours handing maintenance and ops work to AI. Small, well-bounded tasks finish so fast it feels unfair. The bigger chunks, the ones still fuzzy in my own head, stall out.
That split used to look like a tools problem. It isn’t. It is a craft problem with an old name: the definition of the work.
The speed split
The pattern is boring once you notice it. A ticket with clear inputs, a known surface, and an obvious done-when gets chewed through before the coffee cools. Rename a field. Add a log line. Patch a null check that already has a test. The model moves like a junior who somehow already knows the repo.
Then I drop a larger piece of work that I still only half understand. “Improve reliability around this flow.” “Clean up the messy part of onboarding.” “Make this ops path less fragile.” Nothing is wrong with the wording as English. Everything is wrong with it as work. The session starts confident and ends circling. I add more chat. I paste more files. The mush does not become a building.
I’ve watched tiny tickets fly while the undefined ones sit there like a half-drawn plan waiting for someone to finish thinking. That scene is the whole essay in one room.
I blamed the tool
The natural operator move is simple. If execution stalls, upgrade the executor. Bigger model. Longer context. Better prompt. Another agent in the loop. I did all of that more than once.
The diagnosis was incomplete.
The model only ever sees what we make explicit, or what we put where it can retrieve it. Michael Polanyi put the deeper problem in one line: we can know more than we can tell. A lot of what I “know” about a system lives as subsidiary judgment. I feel which edge cases matter. I remember the incident that made a weird constraint real. I carry the political half of a product wish that never made it into the ticket. When I hand a mushy chunk to a model, I am not failing to prompt hard enough. I am failing to finish translating observation into something another actor can execute without sharing my head.
Architecture already had the language
Architects have been naming this translation for a long time.
Client vision arrives as goals and constraints. The architectural program is the first formal move: required functions, areas, performance, what the building must do. That program is already a translation. It is not yet enough to build.
Then comes schematic design, design development, and finally construction documents. Drawings and specs detailed enough for a contractor to price and build. Dimensions. Materials. Tolerances. How pieces meet. The AIA path through basic services is basically a pipeline from intended experience to buildable language. Shop drawings come later, when specialty trades push work to fabrication level. The architect reviews those for conformance with design intent. The review does not invent the intent. It checks against it.
There is a quieter risk in modern practice too. Building-programming exchanges warn that when requirement updates live only in participants’ memory, the built thing drifts. The program was supposed to be a shared artifact. When it slides back into heads, the project loses its spine.
Map that to AI ops and the speed split stops looking mysterious. Construction-document clarity is when the model flies. Program-still-in-my-head is when it stalls. AI does not fail because it “cannot build.” It fails because nobody finished the buildable language.
Product owners were already translators
Software already has a local version of the same craft.
A product owner connects needed value to implementable work. Acceptance criteria turn a story’s intent into testable fitness. Definition of Ready is the shared agreement that an item has enough clarity, scope, criteria, and dependency resolution to start. Disciplined Agile treats that readiness as a team practice, not theater. Mike Cohn’s caution still matters: treat Definition of Ready as a stage-gate and you freeze learning. Treat it as a living agreement about what “startable” means, and it unlocks capacity.
My lived split is Definition of Ready with worse lighting. The small tasks already meet ready. The big mush is a backlog item that never became ready, then handed to a model that cannot invent the missing human judgment. With AI capacity on the team, that translation stops being project-management hygiene. It becomes the center. The model is fast when the work is already defined. When the work is still an idea living only in human context, you get impressive demos on the small stuff and fog on everything else.
Why commander’s intent is not enough for models
Military doctrine has a tempting counterexample. Mission command, in U.S. Army ADP 6-0, asks for clear purpose and a desired end state so subordinates can act without further orders when the plan breaks. The Prussian root, Auftragstaktik, pushed the same idea after armies learned that rigid orders die on contact with reality. Intent that survives chaos is a feature among humans who share training, trust, and tacit context.
That is exactly why the analogy breaks for models.
A trusted subordinate can fill gaps because they share a world. They have walked the ground. They know the unit. They can smell when initiative helps and when it harms. A model does not share that world. Vague intent is enough fuel for a demo. It is not enough fuel for ops. Handing a model commander’s intent without construction documents is how you get confident output that does not fit the building.
The tension to hold is real. Do not Taylorize every thought into an instruction card. Do not romanticize vague prompts either. Humans can run on intent. Models need more of the buildable layer unless you have engineered the missing context into tools, state, and retrieval that actually recover it.
Other languages that connect many actors
Architecture and ready are the spine. A short gallery helps because the same translation problem keeps getting reinvented.
Frederick Winslow Taylor’s task idea was brutal and clarifying: management plans the workman’s task in advance, with written instructions for what, how, and time allowed. Instruction cards and route sheets turned shop knowledge into assignable work. The power is obvious. The deskilling risk is obvious too. Over-specifying can hollow out human craft. Under-specifying leaves AI with nothing to execute. Keep the mechanism. Do not worship the culture around it.
Christopher Alexander’s pattern language is gentler. Patterns give many actors a shared way to execute one idea: context, problem, solution, stated generally enough to adapt locally. Small AI tasks often match existing patterns. Known bug forms. Known refactors. Undefined work has no pattern yet. Someone still has to invent the language.
Contracts make the same cut in legal clothes. An agreement needs terms certain enough to identify breach and remedy. An “agreement to agree” on essential terms often fails. Specs, statements of work, and acceptance language are how abstract commercial intent becomes executable duty. Handing AI a vague product wish is closer to an unenforceable agreement to agree than to a statement of work. The model cannot perform what was never specified.
What changes when AI is the work power
When the executor was only human, unfinished definition still hurt, but trusted people papered over the gaps. They asked clarifying questions in the hallway. They carried tacit context into the afternoon. They refused work that was not ready without calling it philosophy.
AI capacity removes some of that soft buffer. Translation of abstract product intent into executable work becomes more central, not less. Prompt engineering is incomplete. Context engineering helps: curating what enters a limited attention window, tools, state, examples, retrieved facts. Anthropic’s framing of effective context engineering for agents is useful as far as it goes. It is still packing. Packing mush more carefully does not make a building. You still need a defined work object.
The practical stance I am trying to keep is dull on purpose. Spend more time finishing the construction documents, or the Definition of Ready, and less time hoping the model invents them. Ask what still lives only in a human head. Write the constraints as constraints. Name the done-when. Surface the dependency that everyone in the room already “knows.” If a chunk is still mush, do not scale agent capacity against it. Finish the translation first.
Back to the room
I go back to the stalling chunk and ask a simpler question than “which model?” What was still only in human context? Which part of the program never became a drawing? Which acceptance line was still a vibe? Which shop detail was I hoping the agent would invent while reviewing for an intent I had not finished stating?
The craft has a name. Definition of the work. Architects already practiced it. Product owners already practice a version of it. Mission command explains why human intent is not automatically AI-ready work. Polanyi explains why “just tell the model” fails when the knowing is still tacit.
Building with AI is still building. Someone still has to make the work buildable. Lately that someone has been me, holding the construction documents in my head and wondering why the crew looked confused.