I run a small agent system every day. It helps me write, study, build cloud labs, and keep a publishing routine moving. For a long time I treated the prompt as the job. Get the instructions right, I thought, and the agent would do the rest.
The prompt was never the job.
The job is the set of decisions the agent would otherwise make for me. Which problem are we solving? How do we know it worked? What does the finished thing look like? Where do the pieces go?
Skip those decisions and the agent makes them itself, quickly, in the direction of least resistance. You find out three hundred lines later, when the shape is already set and expensive to change. I have read drafts that were technically fine and wrong at the same time. Correct output, wrong thing. That is not a prompt problem. It is a decision problem.
There is a name for the skipped step. Program design. It is the work of deciding the load-bearing parts before the agent cooks: the file layout, the types, the signatures, the flow. The parts you can review in seconds but that decide everything downstream.
Most people never do it. They go straight from idea to prompt. The agent builds, they review, they send it back, the loop repeats. It feels productive. It is mostly paying interest on decisions you did not make.
Why agents drift
It helps to understand why agents drift, because it is not bad luck.
Models are trained on problems where the answer is checkable. Did the tests pass? Did the output match? That is how they learn: try, get scored, adjust. Maintainability has no such score. Nobody can grade "will this be easy to change in six months" inside a training run, because that answer takes months to appear. So the model optimizes for what it can check. It writes code that passes, and it leaves slop that survives.
You see the result in small things. Error handling that catches, logs, and rethrows for no reason. Type casts that exist to satisfy a type checker. Dead branches left in place. None of it is wrong. All of it is debt.
The same logic explains why benchmark scores are weak evidence. A high score means the model solves one-off problems well. It does not mean the code will be easy to change next month, and there is no test for that. You can even check whether a model's own tests test anything: take its patch away, run its tests on the old code, and if they still pass, they were never testing anything.
People try to fix this by having one model review another. That raises the floor: the second model catches small mistakes, missing imports, obvious edge cases. It does not raise the ceiling. A reviewer trained on the same data shares the writer's blind spots, which is why the final judgment still needs a person who knows what the code is for.
None of this is a reason to stop using agents. It is a reason to stop treating them as decision makers. They are excellent at solving. They are unreliable at deciding. The fix is to decide first, then delegate the solving.
The pre-flight: four decisions
Before I let an agent build anything real, I lock four things.
1. The problem and the number
What are we solving, and how do we measure it? A measurable output changes everything. "Make the onboarding less confusing" produces one kind of work. "Make the number of people who finish onboarding go up" produces another. The agent can check the number, try three approaches, and keep what works. Tell it a target like "cut resource use by 20 percent" and it keeps optimizing until it gets there, because it can see the score.
No number, no score, no self-correction. The agent stops being a guesser and becomes a tuner.
2. The architecture
How do the pieces fit together? What are the endpoints, the tables, the flow? One conversation at this level can settle more than a week of back-and-forth on the output. It is cheap context: a design discussion costs a few thousand tokens, while a thousand lines of written code are hard to change. The deeper you are in the code, the more expensive every new decision becomes. Make the expensive decisions while they are still cheap.
3. The program design
Where do the files go? What are the types and the signatures? This is the step most people skip, and it is the one that hurts the most when it is skipped.
It is a set of small, readable decisions. Here is the shape. Here is where things live. Here is what each function promises. You can look at them in seconds and say yes or no. The agent fills in the rest.
If you skip this, the agent chooses the shape, and its first choice quietly becomes the foundation. Every later request gets built on top of a decision you never made.
4. The slices
Do not let the build happen all at once across every layer. Agents love to build horizontally: all the database, then all the services, then all the interface. Nothing is testable until the end.
I build vertically instead. The thinnest working path end to end, verified, then one layer deeper. A stub that works. Then the real call. Then the logic. Then the edge cases. Every step is checkable, and if the trajectory is wrong, you find out when it is cheap to turn.
This is how I learned to build before agents existed. It is the same habit, applied to a faster worker.
A second discipline: keep the context tight
There is a quieter version of the same problem that shows up inside long sessions. The agent works in a context window, and the fuller that window gets, the worse the decisions become. Somewhere past the halfway mark, quality drops. The model starts cutting corners the way a student rushes when the exam clock is running out.
The fix is boring and effective. When a session gets heavy, you stop, write everything important into a handoff document, and start a fresh session on top of that document. Decisions made, files touched, next steps. The context window resets, and the quality comes back.
The same discipline applies to the documents themselves. The rules you want the agent to follow do not belong in chat history. They belong in files the agent reads at the start: decisions, conventions, exclusions, written down once. That is deterministic context. It costs nothing to maintain and it saves the agent from guessing what you meant three sessions ago.
I do this with my own sessions now. It is the same instinct as the pre-flight: protect the quality of the decisions by keeping the environment clean.
What this looks like in a small system
This is not theory for me. My system runs on it.
Before any piece of public writing gets drafted, the direction is locked first: the reader, the tension, the thesis, what is excluded. The agent does not choose the angle. I do.
The measurable output is written down before drafting. A bank of 40 candidates becomes 20 approved posts. At least 10 notes, one call to action. The numbers are not bureaucracy. They are the score the agent can see, the same way the 20 percent target is the score for a heavy optimization job.
My cloud labs are built as slices. One working thing first, then the next layer. A bucket that lists objects, then the policy, then the logic. Never the whole system at once, because a whole system at once has no checkpoint.
And the verification stays human. The system can draft, but I read the final thing. This is the part of the story people skip last. The teams that stop reading the output entirely, that hand everything to review loops and test suites, are the teams that wake up one day inside a bug no agent can solve, inside code they no longer recognize.
Some teams route incidents straight back into the agent loop, so the alert at three in the morning becomes a pull request instead of a phone call. That works, but only because the review step still exists somewhere. You can automate the review. You cannot automate the judgment.
When you can skip this
The pre-flight is not for everything.
If you are exploring an idea that may not deserve to exist, if nothing is paying you yet, speed beats structure. Let the agent cook and see what comes out. A vertical slice is wasted on a sketch.
The moment you have something real, something with users, a codebase that must survive contact with next month's feature requests, the pre-flight becomes the cheapest insurance you have. Twenty minutes of decisions up front saves you from paying for them later, with interest, while the agent cheerfully ships the consequences.
The checklist
Next time you open an agent, run this before you prompt:
What problem are we solving, and for whom?
What is the number we are trying to move?
How do the pieces fit together?
Where do the files go, and what are the shapes?
What is the thinnest thing we can build end to end first?
What am I excluding?
Six questions. Five minutes. The agent will still move mountains. It will just move them in the direction you chose.
Final reflection
Delegation is a transfer of judgment, not a transfer of workload. You can hand the agent the execution. The direction, the measurement, and the final judgment are yours to keep.
The number is the lever. The decisions are the rails.