Chapter 10. The Components of Activity¶
“Get the task done” — that’s roughly what most requests boil down to when we talk about working with a model. But the task, singular, simply doesn’t exist. There are five different actions we often call by one word, and the model does some of them well, some passably, and one it cannot do for us at all.
In Chapter 2 I talked about decomposing the task as an amplifier of your own variety. This chapter is about decomposition of a different kind: not of what we do, but of how we do it. This time it’s the activity itself we’ll have to take apart.
Five actions, not one¶
Every engineering task has five components.
Understand. Build your own picture of what you’re dealing with: what this task is even about and why anyone needs it; how the part of the system you’ll be changing is put together, and what it depends on; where the task’s boundaries run — what’s in, what deliberately stays out; and what can go wrong — where the fragile spots are, and what it costs if they break. The specification, the verification criteria, and the call on whether this is ready to enter the system all come out of this picture. And one more decision lives right here: what to do this task with — by hand, with the model as a means, or handed to an agent. That is the rough estimate by the law of Chapter 2: is your variety enough for what you are about to set in motion?
Specify. Turn our understanding into text you can work with: what should come out, what must not happen, how we’ll know it’s done. These are the same proxies and the same goal note from Chapter 6 — only now you can see where they come from: from understanding, and from nothing else. A specification with no picture behind it is a set of words the model will gladly complete with assumptions of its own.
Generate. Get the artifact itself — code, a migration, a config, a test, a piece of documentation. The only component where the result can be seen and touched within a minute — which is why it’s the one we’ve learned to call “the work.” In fact it’s the cheapest of the five: you can get as many variants here as you like, and none of them is worth anything on its own until it passes the next component.
Verify. Make sure at two levels: that what was generated matches the specification — and that the specification still matches the understanding, because halfway through it often turns out the picture was incomplete. The first level is covered by tests, automated checks in CI, and review; the second — only by a person who remembers what all of this is for. A green pipeline closes the first level and says nothing about the second.
Integrate. Build it into the living system — and into the living team. The merge, the deploy, the data migration, the documentation change — that’s the visible part. The invisible part: new knowledge about the system has to appear in the team’s heads — what changed, why this way, where the fragile spot is now. Without it the code is in production and the understanding isn’t, and the next task in this module starts from zero. This component can stretch across weeks while generation takes a day. Because integration isn’t deploying code — it’s new knowledge in the team and new behavior in your users’ lives.
Why components and not stages? Stages run in sequence. Components are independent: none of them follows from the rest. You can perfectly specify something you never understood — the specification will be flawless and wrong. You can perfectly verify something that will never be integrated. You can generate a ton of code without verifying a single line. Each component gets done or doesn’t get done on its own, and success in one says nothing about another.
Two regularities follow from this independence.
The first: each component has its own curve. They grow separately and atrophy separately. In a year, an engineer can double their generation speed and quietly lose the skill of reading other people’s code — because generation happens daily, and no attention is left for other people’s code and other people’s decisions. A component you don’t feed wastes away — no matter how brilliantly the other four are going.
The second: the chain is stable only when it’s closed. Integrate is not the end — it’s the entry into understand for the next task: what you build in today is what you’ll have to understand tomorrow. If the circle is broken and understanding doesn’t come back, every next task starts with less knowledge of the system than the one before. You’re moving forward through a codebase that grows more foreign to you by the day.
Hands on the yoke¶
Aviation lived through this story forty years before us.
The autopilot didn’t arrive to replace the pilot — it arrived to take one component off the pilot’s hands. Holding course and altitude for hours is monotonous work, and the machine does it better: steadier, without fatigue, without distraction. This is pure generation: there’s a specification — course, altitude, speed — and the autopilot executes it. Pilots handed this component over completely, and they were right to.
So what stayed in the cockpit? The pilot still understands the situation: the weather ahead, the state of the aircraft, what this vibration means. He still specifies — sets the autopilot’s mode and parameters. He still verifies — checks the instruments against what he feels himself. And he integrates — fits the flight into the schedule, the controllers, the crew. The autopilot took one of five components. Four remained — and holding them got harder. While your hands are on the yoke, attention holds itself: the plane demands it every second through effort and vibration. When automation holds the course, the hands have nothing to do — and watching over a system that does everything itself, and does it well, turned out to be separate, hard work that humans are bad at.
And here is what decades of experience showed. Crews perform worst not when the autopilot is working, and not when there is none. They perform worst at the moment it disengages and hands the plane back. A pilot who has spent years only entering parameters suddenly has to feel the machine with his hands — and the component has atrophied, because nothing fed it. The aircraft is sound, the weather is acceptable, and the crew loses it anyway, because the understanding of the situation has long lived not in the pilot but in the system that just said “your airplane.” Aviation has a bleak nickname for such pilots — children of the magenta line: the route line on the display they learned to follow without asking where it leads.
Aviation’s answer was not to give up the autopilot. Its answer was two rules. The first is about modes. An autopilot has several levels of autonomy, from “just hold the altitude” to “fly the route and land the plane yourself,” and the pilot must know at every second which mode is active, what the automation is doing and what is left to them; every mode change in the cockpit is called out aloud. The second is mandatory hours of hand-flying, so the component handed to the machine doesn’t die in the human entirely.
That is this chapter’s method. Now — what it’s made of.
Who decides here¶
Inside each of the five components there are three positions. The subject is the one who decides: asks the questions, chooses, accepts. The means is what the action is done through. The object is what it’s done to.
Take understanding an unfamiliar module. The object is the module. The means — the editor, the debugger, git blame, and now the model. In the input field sits your prompt: “show me where this function is called.” The subject is you: the question is yours, and you decide what the next one will be and when the understanding is enough to move on. The model here is a more powerful means than anything we’ve had before. But a means.
Now change a few words in the prompt: “explain this module to me.” Same object. Same means. And the subject? Who decides what matters in the module and what doesn’t, what to mention and what to skip, when the explanation is enough? The model. The questions are now asked by the model itself — its own, plausible ones, straight from Chapter 6. You’ll read the explanation and believe you’ve understood — but the understanding wasn’t formed by your head.
Here is the mechanism that makes the four roles from Chapter 2 so treacherous: you don’t go from Captain to Passenger by decision — you go by phrasing. Nobody says “I hand understanding to the machine.” They say “explain” instead of “show me where.” And from that moment the means sets the course of the work: the model has produced a solution — and you’re fixing it, piece by piece, in the order it generated it. The work is humming, but you didn’t write its plan.
So in every component the question is the same one: who decides here? Not “is the model involved” — it’s involved everywhere, and that’s fine. But who asks the questions and who accepts the answer.
The delegation map¶
Now the map itself. Each component gets its own level of model involvement: one we hand over fully, three partially, one never.
Generate — fully. This is the component worth handing over without regret — the way pilots handed over holding the course. The model generates faster, steadier, and doesn’t tire. Your position here is not to write code yourself “to keep the skill alive”: the skill of typing code by hand is worth exactly as much as it feeds understanding, and understanding is fed by reading and verifying, not by typing. Handing generation over fully, you stay the subject at the entry (specification) and at the exit (verification) — and that’s enough.
In the next three components the model is a means and the subject is you, and the boundary runs right through the middle of the component.
Specify — partially. The model can expand your goal note into acceptance criteria, find a case you missed, propose a structure. But what the goal is, you decide: a proxy the model formulated for itself is a proxy the model will optimize.
Verify — partially. The model will write tests, do a first review, catch the obvious. But a test you didn’t conceive verifies its understanding, not yours. So the criteria are yours — and at least one test for each of them, too.
Integrate — partially. The model will do the merge, fix up the config, write the release note. But the decision “this is ready to enter the system” belongs to whoever will answer for the system at three in the morning.
Understand — never. And here a clarification is needed, or the rule will be read wrong. “Never” does not mean “without the model.” The model is the best means of understanding engineers have ever had: it answers “where,” “why,” “what happens if” in seconds, from any point in the codebase. Use it generously. What you must not hand over is something else — the position of the subject: letting the model decide what matters here, and accepting that decision without asking a single question of your own. The test is simple: after a session of understanding, can you explain the module to a colleague with no model at hand? If yes — the understanding is yours. If no — it stayed in the session and will end with it.
Why is this the one component that can’t be delegated when the rest can? Not because the model understands code worse. Often it understands better. But understanding is the reference point for the other four. Whoever understands defines what the task even is: where its boundaries lie, what counts as success, what can be left alone. Specification, verification, and integration are performed from the position of the one who understands. If that position belongs to the model, you perform the other four components from someone else’s position — and you perform them as the object, even if you press every button yourself.
There is also a more general rule you can test any component against before handing it over. The result of a component has to hold up on its own — by its composition, not by an external prop. Generated code holds up on its own: it either passes the tests or it doesn’t, and the session that produced it isn’t needed for that. Understanding that lives only in the model’s context does not hold up: take away the session, and there is nobody on the team who knows why the module is the way it is. Systems assembled by an external force stand exactly as long as the force stays.
One module, two sessions¶
The task is real: add CSV export to the reports module in a legacy service that we didn’t write, and not this year.
Session one. A single prompt: “Here’s the reports module. Explain how it works and add CSV export with the same filters as the current HTML report.” The model gave three paragraphs of explanation — I skimmed them, they sounded plausible — and four hundred lines of code. Tests green; review read the code, not the module; merged and shipped to production.
Two weeks later — a ticket: for one client, the sums in the CSV don’t match the HTML report. Who on the team knows why? Nobody. The module was understood by a session that no longer exists. I opened a new chat, asked for an explanation again — and got a different one, also plausible. Two hours of debugging established: the module had two filtering paths — an old one and a new one behind a feature attribute — and the CSV had hooked into the old one, because the model picked the more plausible of the two. The three paragraphs of explanation never mentioned the attribute. Not because the model hid it — because nobody asked.
Session two, a different task in the same module, done by the method. First — an hour of understanding, the model as a means: “show me every place the filters are applied,” “how do these two paths differ,” “who turns this attribute on and for whom.” The questions mine, the answers its, and after each one — my decision where to dig next. Within an hour I could draw the module on a whiteboard — and did, for myself. Then the specification: five criteria, among them “works for both filtering paths, a test for each.” Then generation — handed over fully, four hundred lines in three minutes. Verification: the tests for the two paths I wrote myself before generating; the review was done by the model, and it found an encoding problem I would have missed. Integration — myself: the diagram stayed on the whiteboard, and the module’s documentation gained a paragraph — two traces of understanding that will outlive the session.
The score: an hour of “unnecessary” reading against two hours of debugging and two weeks of running in production with the bug. And one more difference the hours don’t show: after the second session, a human on the team understands the module. After the first — nobody does.
Code nobody understands¶
This chapter’s anti-pattern is the most common one I see right now, and the hardest to spot, because it looks like productivity.
The team generates fast. Tickets get closed. The code passes the tests. But ask anyone “why is this module built this way” — and you’ll get “that’s how it came out of the model.” Explanations of the code are sought from the model, not from people; review reads diffs, not the system; onboarding a new engineer is “ask the chat.” The understanding of the system belongs to no one.
The diagnosis, by this chapter’s rule: the component understand has been handed over fully — not by decision, but by a thousand small “explain”s instead of “show me where”s. The system was assembled by an external force in an unnatural order — the code appeared before the understanding — and it stands as long as the force stays. And that force is a session that lives a couple of hours or days.
This code is not bad. It’s often better than what hands would have written. But it stands on a prop that is no longer there, and the first non-typical situation — a bug that won’t reproduce, a requirements change that touches two modules at once — is the moment the autopilot disengages and tells the team “your airplane.” And the team that has spent years only entering parameters discovers it cannot feel the machine with its hands.
The cure is not a rewrite and not a ban on generation. The cure is returning the component. A separate session of understanding over the code that already exists: not “explain,” but “show me where,” “why are there two paths here,” “what breaks if.” A diagram on the whiteboard, a paragraph in the documentation, a review conversation about the system instead of the diffs. Understanding that outlives the session is the one line in the result of your work that the model cannot generate for you. The other lines of that result — that’s Chapter 11.
The components scale¶
So far we’ve been taking apart a single session. The same map works levels above.
The agent is the next level. It differs from a chat in that it performs several components in a row without you: sets itself intermediate tasks, generates, verifies its own result, moves on. An agent is components handed over wholesale. The question to ask it is the same as for a single session, only the price of a mistake is higher: who is the subject in understand? If the agent itself decides what matters in the task and what can be skipped, you’ve handed the autopilot not just the course but the understanding of the weather. How to build a construction that keeps the agent in the position of a means — that’s Chapter 14.
The team is one more level up. The five components get distributed among people: someone talks to the customer, someone writes requirements, someone generates with the model, someone verifies, someone builds it into the system. The distribution itself is fine — until all the understanding has gathered in one head. The temptation is the same as with the model: hand understand to the one person “who’s on top of it” and leave the rest with execution. Half a year later that one person goes on vacation — and the team finds itself in the same position as the engineer with a module understood only by a closed session.
The mechanics are the same at every level. What changes is only who owns the understanding — and what its loss costs.
In your craft¶
The five components don’t know what code is. Substitute your own material.
Text. An editor who writes to the model “read these interviews and write an article” has handed over understand: what mattered in those interviews, the model decided. The one who first asks — “which claims repeat across three sources,” “where do they contradict each other” — and then specifies the thesis and hands over generating the draft, remains the author. The difference shows a month later: the first can’t answer a reader’s “where is this from”; the second can.
Analytics. A dashboard the model generated on “show me what’s important in this data” is a picture of someone else’s understanding. The analyst who first formulated three questions to the data and then handed over building the charts is the subject; they know what’s not on the dashboard, and that knowledge is worth more than the dashboard itself.
Design. “Make a mockup for this feature” — generation and understanding in one prompt; the mockup will be plausible and foreign. The designer who first worked through the user’s scenario — themselves, with the model as a means: “what states can this screen have,” “what does the user do when the data doesn’t load” — and then handed over generating the variants, gets a mockup they can defend in front of the team.
To close — three questions for your own practice.
— Take your last task with a model and lay it out into the five components: in which of them were you the subject — and in which, no longer?
— Is there a module in your codebase that only a session that no longer exists understands?
— And deeper: when did you last ask the model “show me where” instead of “explain”?