The Prescription Model: How Senior Engineers Get Better Output from AI

The code ships. Tests pass. The PR gets merged.

Three sprints later, someone hits a wall trying to extend a feature built in that session. The AI made a schema decision nobody reviewed. It introduced a pattern inconsistent with everything else in the codebase. It "solved" the ticket and silently created technical debt that now takes two days to untangle.

This isn't a prompting problem. The prompt was fine. The problem came earlier, before the AI touched anything.

Most teams are getting mediocre output from AI not because they're using the wrong model or writing weak prompts. They're skipping the handoff, throwing work at AI the way a bad manager throws work at a junior: paste the ticket, wait for output, review when it's done. That process was broken before AI. It's just faster now.

I've managed engineering teams for 8 years. The failure pattern is the same whether the person on the other end is a junior developer or an AI agent. The handoff was never the problem. The missing prescription was.

Senior engineers have always written prescriptions

Strong technical leads have never just handed a ticket to a junior developer and said "figure it out." What they actually do is prescribe the implementation: the approach, the files to touch, the pattern to follow, the things not to change, what "done" looks like.

That's not micromanagement. It's how domain knowledge and architectural judgment get transferred before the work starts, the "we tried that in 2023 and it caused X" knowledge that a junior developer has no way of knowing on their own.

AI collapsed the seniority gradient. Every developer now has access to something that writes code as fast as a junior engineer, but without the senior engineer's judgment about what that code should look like or what it needs to respect. The AI fills those gaps with guesses. This is exactly the gap the Forward Deployed Engineer model addresses at scale: embedding technical judgment into delivery instead of leaving it to chance. The prescription is what an FDE does before the code gets written.

Why most teams skip it

The default workflow: open a chat window, paste in the ticket, wait for output, review when it comes back.

This works often enough to feel like a process, so teams keep doing it while the subtle failures accumulate. Code that meets the spec but violates a convention from three months ago. A dependency introduced because the AI didn't know an equivalent utility already existed. An architectural decision made at the function level that should have been made at the system level, by a human.

The AI isn't writing bad code in isolation. Nobody wrote down what "good" looked like in this context before it started. Every gap in the prescription is a decision the AI makes on its own, confidently, without flagging that it made one.

The Prescription Model

Before any AI-assisted coding task, write the prescription. Five components:

1. The roadmap. One or two sentences: what are we building, why, and how it fits into what already exists. Not the ticket description. The engineering context. "We're adding a rate limiter to the API gateway, using the existing middleware pattern in src/middleware/, not a new library."

2. The context. Relevant files, existing patterns, and decisions already made. Which modules does this touch? What pattern should be followed? If there's a convention in the codebase that the AI won't find on its own, write it here.

3. The constraints. What should not happen. This is the most skipped part and the one that prevents the most damage. Don't modify the schema. Don't introduce new external dependencies. Don't change the public API surface. Write the things that feel obvious to you. They're not obvious to the AI.

4. The expected output. What does done look like? Include edge cases, error states, and the acceptance criteria in engineering terms, not product terms. "Returns a 429 with a Retry-After header when the limit is exceeded" is useful. "Users can't spam the endpoint" is not.

5. The review criteria. How will you evaluate the output? Name it before the AI writes a line. Does it follow the existing error handling pattern? Does it have test coverage for the three failure cases you identified? Defining this before you see the output stops you from accepting something that "looks fine" when it actually doesn't meet the standard you had in your head.

That's the whole model. It takes five to ten minutes to write for most tasks. The AI code review at the end of a well-prescribed task takes half the time, because you already know what you're checking for. The rework rate drops significantly.

Systematizing it with an AI harness

At the individual level, the prescription is a discipline. At the team level, it can be automated into a harness.

A repo-specific AI harness feeds the model the codebase structure, established conventions, and past architectural decisions automatically. The prescription a developer writes on top of that gets lighter, because the model isn't re-learning the codebase on every task.

This is how we run AI-assisted delivery at SociiLabs. The harness handles the systematic context. The engineer handles the task-specific prescription. The output gets reviewed against criteria written before the work started, not against gut feel after the fact. A junior engineer working this way produces output closer in quality to what a senior engineer would ship unassisted. That's the point of an AI engineering workflow built around prescription rather than prompting.

A practice you can start this week

Before the next AI coding task your team runs, write the prescription first. Five components, one page maximum. Then review the output against the criteria you wrote before you saw the result.

Do that for five tasks in a row. Track which parts of the prescription the AI ignored or got wrong. Those are the places where your prescription needs to be more specific, or where the harness needs to be better at passing context.

No new tooling. No process overhaul. Just the discipline of writing it down before the AI starts.

Teams that do this well stop thinking of AI as a tool they prompt. They think of it as an engineer they brief. The briefing is the work. The code that comes back is just the output of it.

This is how we run AI-assisted delivery at SociiLabs. If you're building with AI and want structure, not chaos, let's talk.