Slow Down, Human

Fast code generation can make a workflow feel productive before the result has been checked. The useful question is whether the change meets its requirements, can be understood and can be maintained. Generation speed is only one part of that work.

This article describes four ways to collaborate with a coding agent. They are practical patterns rather than measured personality types. Use the pattern that fits the uncertainty, scope and feedback needed for the task.

Define the work before delegating it

A prompt is one part of the specification. It should identify the problem, the intended behavior, relevant constraints and how completion will be checked. Supporting code, documentation and examples may carry details that should not be repeated from memory.

For an authentication change, “add auth” leaves major decisions unresolved. A useful brief identifies the expected sign-in flow, session behavior, permitted data access, failure cases and existing conventions. Resolve security-sensitive choices against the application’s requirements rather than treating a longer prompt as inherently correct.

A clear brief reduces avoidable ambiguity. It does not guarantee production-ready output, and clarification during implementation is normal when new evidence appears. Record changed decisions so that the implementation and acceptance criteria remain aligned.

1. The handoff

A bounded handoff works when the problem and acceptance criteria are already clear. Give the agent the relevant context, authorized actions and expected deliverable. Let it implement within those boundaries, then inspect the actual result.

This fits repetitive changes, a well-defined bug or implementation under an agreed architecture. The risk is assuming that previous successful handoffs justify less precise requirements or less review for the next task.

2. The design conversation

When the problem is uncertain, use conversation to explore requirements and alternatives before implementation. Ask what information is missing, which assumptions carry risk and how different approaches would be evaluated.

This is useful for unfamiliar domains and architectural decisions. The output should be a concrete plan or decision record rather than an indefinitely growing discussion. Human attention remains necessary because the agent can propose plausible but unsuitable requirements.

3. Short iterations

For debugging and exploration, choose one observable step at a time. Inspect the result, update the hypothesis and decide what to do next. Small steps can make it easier to identify which change caused a result.

This approach needs a durable account of what has been established. Otherwise repeated experiments and discarded hypotheses can clutter the session. Distinguish confirmed facts from tentative explanations and failed attempts.

4. A continuing project session

Longer sessions can preserve useful context across related tasks. Their value depends on retaining relevant decisions and keeping the current objective clear. Elapsed time alone does not establish when a session becomes unreliable.

Use concise checkpoints that record the current state, important evidence, unresolved questions and next action. Keep authoritative project knowledge in its approved durable location so that a future session can recover it without replaying an entire conversation.

Decide when to reset from evidence

A new session is useful when the task changes substantially or the active context no longer helps. Repeated mistakes deserve diagnosis: missing source material, ambiguous requirements, a client bug and context pressure require different remedies.

Before restarting, preserve the current work and write a faithful handoff. Include relevant paths or references only in the authorized workspace. Then load the information needed for the new task and verify that the continuation reflects the actual state.

Compaction can help manage a long conversation, but a summary can omit important details. Reopen original sources when the exact rule, code or evidence matters. Do not assume that information being present in a long context guarantees that it was used correctly.

Measure completed work

Assess correctness, review effort, rework and escaped defects alongside time spent. If comparing workflows, use comparable tasks and retain the measurement limitations. A faster first draft can still require more effort to finish.

Give the agent a way to test its work, then inspect whether those tests cover the requirements and actually ran. For consequential changes, use the established independent review process and reconcile its findings rather than treating model agreement as proof.

The practical discipline is to make the next action clear and the result checkable. Sometimes that means a detailed handoff; sometimes it means stopping to resolve a question. Choose deliberately, and judge the workflow by the completed result.