Plan before agentic code changes: when a short design step saves rework

A worked example: where the task becomes difficult

A fictional helpdesk wants organization accounts instead of individual-only accounts. The visible request sounds like adding a team selector, but tickets, invitations and permissions depend on the ownership model. A plan should uncover those consequences before editing the selector. Contrast that with correcting a label, where a long architecture discussion would add overhead without reducing a real risk.

Decisions to make before implementation

Describe the behavior that must remain valid for existing customers. Compare a small compatible extension with a broad rewrite, including data migration and rollback. Decide which uncertainties block implementation and which can be resolved through source inspection. Keep the plan tied to a selected approach and a bounded acceptance checklist rather than an endless catalog of possible features.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Identify state or ownership changes implied by the request.
• Ask for two feasible approaches grounded in the existing architecture.
• Select one approach with explicit migration and rollback boundaries.
• Convert the plan into implementation steps that each produce inspectable evidence.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Plan organization accounts for the current helpdesk. Inspect existing ticket ownership first. Compare a compatible membership layer with a broader redesign, including migration, access checks and rollback. Recommend one approach and list blockers separately. Do not edit yet; return an implementation scope that preserves current personal accounts.

Failure modes that an attractive preview can hide

A polished plan can conceal unsupported assumptions about database permissions or hosting. Require the agent to identify unavailable access and preserve a separate migration step when it cannot apply schema changes. Do not mark a migration complete because a SQL file exists. Also avoid approving a plan that bundles unrelated redesign work into a permission change.

Technical references: GitHub: getting useful results from coding tasks

Acceptance checks and the evidence to retain

Keep the selected design, rejected alternative, migration boundary and acceptance tests. The next implementation request should reference the plan without needing to repeat the whole discussion.

Specific answers

Common questions