Model handoff patterns for long engineering projects

Why long tasks go off track

Long engineering tasks often drift for a simple reason: one chat tries to hold the whole job.

The same thread ends up carrying the original goal, code changes, failed tests, review notes, bug fixes, and a trail of guesses from earlier in the day. At first, that feels efficient. Later, it becomes a mess. The model still writes fluent answers, but it stops keeping the right priorities in view.

In one crowded conversation, the model has to juggle the request, the current code, logs, reviewer feedback, and temporary assumptions. Once the context gets full, newer details start pushing older constraints aside. A fresh stack trace can matter more than a rule that appeared 50 messages earlier. If the team said "do not change the database schema," that rule can quietly disappear behind patches, retries, and explanations.

This is where bad handoffs begin. One person thinks planning is finished, but the coding step starts with only part of the plan in focus. Then the same thread shifts into review mode while still carrying assumptions from the coding step. The review loses distance. It stops being a real check.

The cost is easy to spot. Engineers redo work. Reviewers catch bugs that came from missed requirements, not tricky logic. Small changes spread into unrelated files. A task that should take an afternoon turns into two days of cleanup.

A common example starts with something small, like adding audit logs to an admin action. After a long back-and-forth, the model also changes response shapes, touches helper functions that had nothing to do with the task, and breaks a test that no longer matches the product intent. The code problem was not especially hard. The process was.

The fix is not a better monologue. It is a better split.

Split the work into three jobs

Long tasks get easier when planning, coding, and verification stop sharing the same crowded space.

Each stage should have one job and one output. Planning defines the scope, constraints, risks, and done criteria. Coding follows that brief and produces the patch. Verification checks the patch against the brief and produces a clear pass or fail decision.

That separation matters because each step needs a different mindset. Planning should stay above implementation unless a technical detail changes scope. Coding should stay narrow and avoid side edits. Verification should start fresh and act like a careful teammate who did not write the code.

When one thread tries to do all three, small assumptions stick around too long. A guess made during planning sneaks into implementation. A shortcut taken during coding gets defended during review. The model is then judging work it already talked itself into.

A simple API change shows the difference. Planning decides which endpoint changes, what must stay the same, and what could break. Coding updates the handler and tests. Verification checks edge cases, confirms unchanged routes still work, and compares the result to the original brief. Each step looks at one slice of the problem instead of the whole pile at once.

It sounds almost too obvious, but it saves real time. Teams spend less effort untangling mixed instructions and more effort fixing actual problems.

Build a planning brief that people can use

A good brief prevents one person from planning a change in detail while someone else codes the wrong thing.

Start with the goal in plain language. Keep it to one or two sentences. Say what problem you are fixing, who it affects, and what result you want. If the goal needs a full paragraph, it is still too fuzzy for a clean handoff.

Then draw a hard line around scope. Say what can change and what must stay untouched. A coder should know whether they can rename APIs, change data shape, touch tests, or update UI copy before they open an editor.

Most useful briefs answer five things:

1. What is the goal?
2. What files, services, or docs are involved?
3. What constraints matter?
4. What does done look like?
5. What is off limits?

The definition of done needs to be concrete before coding starts. "Support bulk upload" is vague. "Users can upload 100 CSV rows, see row-level errors, and save valid rows without breaking the current single-upload flow" gives the coder a target and gives the reviewer something specific to check.

Inputs matter too. Name the files to inspect first, point to existing tests, and state any scope limits. If the change must stay inside one service or one pull request, say so. If the coder needs sample data or a failing test case, include it.

Short is better than exhaustive. If someone cannot reread the brief in under two minutes, trim it. Remove background that does not affect the work. Cut repeated context. Keep the signal.

This matches a practical pattern used in AI-assisted engineering work at oleg.is: sort the problem once, write a tight brief, and hand off only what the next step actually needs. Large context dumps feel thorough, but they usually create more drift than clarity.

Run the handoff step by step

A long task usually goes wrong when the next model inherits too much noise. Start each run with the planning brief, not a full transcript.

That one habit fixes a lot. Old chat history mixes solid decisions with abandoned ideas, half-finished code, and guesses that never got confirmed. A clean handoff keeps the next run focused on what still matters.

A simple sequence works well:

1. Ask the planning run for a file-by-file change plan.
2. Review the plan and cut anything vague or out of scope.
3. Ask the coding run to list its assumptions before it writes code.
4. Let it change a small batch of files, then stop.
5. Save a short summary of what changed, what passed, and what still looks risky.

The file-by-file plan matters more than many teams expect. "Update auth" is too broad. "Edit login form validation in app/login, adjust session checks in the API handler, and add one regression test" gives the coder a path and makes review faster.

Assumptions deserve their own line before code starts. If the coder assumes a feature flag already exists, or that one service owns validation, write that down first. Catching a bad assumption takes seconds. Fixing code built on it can take an hour.

Keep each batch small enough that a person can scan it without fatigue. After the batch, save a plain summary with the files touched, decisions made, tests run, and open questions. If the summary says everything important in ten lines, do not pass the whole conversation forward.

For example, if a team changes a Next.js front end and a Go API, the next run does not need every prompt from the morning. It needs the current plan, the latest summary, and the hard constraints. That is enough to keep the work moving without letting context window limits pull the task off course.

Verify in a clean context

Review works better when the reviewer starts fresh.

If the same thread that planned and coded the change also reviews it, the model often repeats its earlier mistakes instead of spotting them. A new context forces the review to rely on the brief, the diff, and actual evidence.

Give the reviewer only the original brief, the changed files, and a short handoff note from the coding step. That note should say what changed, which tests the coder ran, what still seems risky, and what they chose not to touch. Keep it tight. If you paste the whole project history, you lose the benefit of a clean read.

The reviewer should check the code against the brief first, not against the coder's explanation. Explanations can sound tidy even when the patch misses the point. Start with direct questions: does the change solve the requested problem, does it stay inside scope, and does it break any stated rule?

Then check the corners. Long tasks often fail there. A function may work on the happy path and fail on empty input, retries, old data, or partial errors. The review step is not there to admire the code. It is there to doubt it.

Ask for proof, not confidence. A useful review packet includes the exact tests that ran, sample outputs or logs, any skipped tests and why, known limits that remain, and a clear note on anything that still needs human judgment.

After that, make a plain decision. Accept it if the change matches the brief and the proof is enough. Fix it in review if the issue is small and obvious. Send it back if the code drifted, hides risk, or lacks evidence.

A small startup team can save hours with this habit. One model writes the patch, another checks it in a fresh context, and a person steps in for the final call on risk.

A simple example scenario

Say a startup team wants one small feature: let account admins export the last 30 days of audit log entries to CSV.

This works well as a handoff task because it touches product behavior, backend logic, and tests, but it is still small enough to finish in a few passes.

The planner does not write code. The planner turns the ticket into a short brief someone else can use without reading a week of chat history. The brief says the goal is to export audit logs for one workspace. It sets limits: 30 days only, admins only, CSV only. It points to the likely files: the audit API, export job, admin settings page, and the test suite. It also calls out risks like large exports, permission checks, and date formatting across time zones. Done means the CSV downloads correctly, empty exports still work, and regular users get blocked.

The coder picks up that brief in a fresh context and works in batches. First comes the backend endpoint and permission check. Then the CSV generation and 30-day query cap. After that, the admin page button and tests for admins and regular users.

Because the coder only sees the brief and the current batch, the context stays clean. Old discussion about future export formats does not leak into the work.

Then a verifier opens another fresh context. The verifier reads the brief, scans the diff, and tests the feature like a skeptical user. The export works. Permissions work. The button appears in the right place. One issue still slips through: entries created near midnight UTC show the wrong date for an admin in another time zone.

That goes back as a small handoff: keep stored timestamps in UTC, format dates for the user's time zone in the CSV output, and add one test that crosses midnight. The coder fixes that case without reopening the whole task.

That final result is tighter than a single long session. The planner kept the scope small. The coder moved in clear chunks. The verifier caught the missed case before release.

Mistakes that break the process

Long tasks usually fail for boring reasons.

A team starts with a clean plan, then keeps stuffing more chat history into each step until the model starts mixing old ideas, dropped options, and new requests into one messy answer. A planner hands over a transcript instead of a brief. A coder adds refactors that nobody approved. A reviewer starts patching code instead of judging it.

Scope drift is one of the biggest problems. If the coding model decides to rename modules, clean up style, or change user flow on its own, the handoff stops being a handoff and turns into improvisation. Sometimes the patch even looks nicer on paper, but it no longer matches the agreed job.

Weak summaries cause the next break. Without a short written note, each model has to guess what matters. That is where small errors start to pile up.

Tests can fool teams too. Passing tests only show that the code matches the tests. If the requirements changed midway and nobody updated the handoff, green results do not prove the feature is right. They only prove the old assumptions still run.

Watch for a few early warning signs:

• The coding prompt includes rejected ideas, stale debates, and unrelated logs.
• The diff touches more files than the brief called for.
• Nobody can point to a short handoff summary.
• The reviewer starts editing instead of reviewing.
• Tests pass, but the result does not match the approved behavior.

When these signs appear, stop and reset the process before the confusion spreads.

Quick checks before each handoff

A handoff usually fails because the next person trusts a stale brief. A few quick checks catch most of that.

Start with the ticket. Make sure the goal still matches the current request, not the version people discussed two hours ago. Scope drifts all the time after a bug comment, product note, or quick Slack decision. If the ticket changed, update the brief before anyone writes more code.

Then read the brief like a stranger would. It should name the files or modules in play, the limits on the change, and the risks. If it says "update auth flow" but never names the middleware, session logic, or rollback risk, the next person will fill in the blanks and probably guess wrong.

Use a short checklist:

• Confirm the ticket still matches the current goal.
• Make sure the brief names exact files, boundaries, and risks.
• Compare the coder summary with the actual diff.
• Check that verification covers both the normal path and edge cases.
• Record open questions for the next pass.

The diff check matters. People and models both summarize intent better than outcome. A summary may say "added validation," while the diff also removed a fallback, changed a config value, or skipped one test file. Read the diff and the summary side by side.

Verification also needs two views. Test the normal path, then test the awkward path: empty input, duplicate requests, bad permissions, partial failure, rollback. One clean demo is not enough for long engineering tasks.

Finish with a written note for the next pass. One line is often enough: "API limit still untested" or "migration order needs review." Good handoffs feel almost boring, and that is usually a good sign.

When to reset the context

Keep a model chat alive only while the task stays narrow. Once the job changes shape, the old context starts hurting more than helping.

A chat that began with API design should not also absorb bug triage, test fixes, and deployment notes. Reset the context when planning turns into implementation, implementation turns into verification, new files or systems enter the task, or the model starts missing earlier decisions.

One chat should own one subtask. Keep it tight, name it, finish it, then hand it off. Reuse context only for a narrow job. If you ask the same chat to plan, code, explain, defend, and verify, it starts carrying too many half-finished assumptions.

Store the real memory outside the chat. A short handoff note works better than a long conversation history. Put the goal, scope, files touched, decisions made, checks still needed, and open questions in one place the team can scan fast.

A simple example makes this clear. A team plans a refactor for an authentication service. The planning chat decides which files to change and which risks to watch. The coding chat should get that brief, not the full debate. Then the verification chat should get the diff, test results, and expected behavior without the design chatter mixed in.

Small, named handoffs beat one giant session. "Plan auth refactor," "Implement token refresh change," and "Verify login edge cases" give people and models a clean lane. "Finish auth work" invites drift.

Next steps for your team

Start small. Do not push this across every repo at once. Pick one task your team repeats often, such as fixing the same class of bugs, shipping a small feature, or updating an API with tests. A narrow trial makes the process easier to judge because the work stays familiar.

Write a one-page handoff template and keep it plain. Most teams only need the goal, likely files or systems, limits and risks, done criteria, and what the next person must verify. Use that template for a few runs before changing it again. Process tweaks need a little time before you can tell whether they help.

Then track the things your team already feels in practice: rework, review time, and bugs that slipped through. If this cuts one review round and saves 20 minutes per task, people notice fast.

A simple rule works well: one person owns planning, one person or model owns coding, and one fresh reviewer or model checks the result in a clean context. That separation sounds strict, but it usually removes more confusion than another round of prompt editing.

If your team relies heavily on AI coding and the results still feel uneven, an outside process review can help. Oleg Sotnikov, through oleg.is, advises startups and small teams on practical AI-assisted development and Fractional CTO workflows. The useful part is not more ceremony. It is building a handoff setup that fits your team, your stack, and the kind of mistakes you actually make.

The best first test is simple: run one recurring task through planning, coding, and verification this week, then compare the result with your usual approach.