Designing Your Personal AI Coding Workflow
A concrete system: which tool, which task, which guardrails, and when to just write it yourself.
We've explored how open-source agents like Aider work and how they manage context. Now it's time to turn that understanding into a system you own, a personal workflow that holds up across every task in a real workweek. A personal AI coding workflow is not about picking one tool. It is a deliberate system with three parts: a triage rule that decides when to delegate to AI, a plan-first implementation loop with explicit checkpoints, and a context strategy that keeps the model focused on the right code. This article gives you a concrete system you can start using on Monday morning.
The biggest gain does not come from generating code faster. It comes from not having to switch back and forth between exploratory thinking and mechanical typing. When your workflow treats the AI as infrastructure rather than a clever autocomplete, the tool handles the typing while you stay focused on architecture and product decisions. The rest of this article maps out how to set that up.
The mental model: treat AI tools like an engineering team
Before we wire up concrete tools, we need a clear mental model. Think of your AI coding workflow as a small engineering team. You are the tech lead. The team has a planner, an implementer, a reviewer and a documentation writer. Each role suits a different mode of working. The planner is best at breaking ambiguous requirements into a crisp specification. The implementer turns that specification into working code, but only with a tight scope and a good plan to follow. The reviewer catches missing edge cases and inconsistencies. The documentation writer turns intent into prose without inventing new bugs.
This model maps onto a workweek. On Monday you start a feature: you work with the planner to write a structured plan file. On Tuesday you hand that plan to the implementer and approve each step as it lands. On Wednesday you bring in the reviewer for a sanity check on your pull requests. On Thursday you refactor a difficult module with the implementer in a more exploratory agent mode. On Friday you draft release notes with the documentation writer. The tools you assign to each role depend on your situation, but the separation of roles stays constant.
Now let's make this concrete.
How do I decide which tasks to delegate to AI and which to write myself?
Start with a simple triage rule: delegate anything that is mechanical, well specified and verifiable. Write yourself anything that needs deep product judgment, a novel algorithm, or an architectural decision that affects several teams.
This rule is not about capability. Modern agents can produce plausible code in every one of those categories. The distinction is about reversibility and the cost of an error. If the AI writes a wrong implementation of a well-specified API (application programming interface) endpoint, a test catches it and you roll back a commit. If the AI invents an authentication flow because a requirement was fuzzy, you might ship a security hole that no test covers. So before you delegate, ask: "Can I specify success objectively?" If you can write a test that captures the requirement, the task is a candidate for delegation. If success depends on judgment you haven't put into words yet, write it yourself, or work with the AI in a planning mode until those words exist.
Within a week, this splits cleanly. A new feature ticket arrives: "Add payment method caching to the checkout flow." The frontend states and the API contract are well understood, so once the plan is written, implementing it is a good task to delegate. Later in the week you need to design a retry strategy for a brittle downstream service. The right behavior depends on that service's failure modes and on your business commitments, so the design stays with you. You might use an AI chat to explore the trade-offs, but you don't ask an agent to ship the final implementation until you have written the specification yourself. This keeps your attention on the high-stakes thinking and hands the typing-heavy work to the machine.
Which mode should I use for each kind of task?
Every major tool now offers the same handful of modes, so choose by mode, not by product. You do not need four subscriptions: one tool that has all the modes is enough to start.
For understanding code before you change it, use an ask mode: a read-only chat that answers questions about the code without editing anything. Cursor, Copilot and Devin Desktop all have one, and Claude Code's plan mode is read-only too. This suits the Wednesday code review and the Friday documentation task. You point it at the exact files or diff, ask targeted questions, and nothing in your branch changes.
For a focused change inside code you already understand, use inline edit: select the code, describe the change, and review the diff right there. In Cursor that is inline edit (Cmd+K or Ctrl+K), as its inline edit guide shows; in VS Code it is Copilot's inline chat. This fits the Thursday refactor when you are modernizing one component: you control exactly what is touched, and the review is cheap because the change is local.
For a multi-file change, start in a plan mode, which researches the code and writes a plan without editing anything. Claude Code has plan mode (Shift+Tab cycles to it), Cursor has Plan Mode, Copilot in VS Code has a Plan agent (type /plan), Cline has Plan and Act, and Devin Desktop, Cognition's AI editor formerly called Windsurf, has a Plan mode too. Each keeps its plan somewhere different: Claude Code saves plans outside your repository by default, and Devin Desktop keeps its plan file outside the repository for the session. If you want a plan that survives across sessions and tools, save the approved version into your repository as plan.md.
Then switch to an agent mode to carry the plan out, with checkpoints. Ask the agent to implement one step at a time, run the tests after each, and stop for your review. Cline asks you to approve every file edit and command in Act mode; Claude Code in Manual mode asks before edits and commands, as its permission modes guide explains; Cursor and Copilot apply each edit and show it as a diff you can review and undo. Plan Mode and the Art of Not Letting the Agent Run Wild shows this loop in Claude Code.
For complex refactors that change behavior across many files, the same plan-then-execute loop works especially well in a terminal agent such as Claude Code. Ask it to analyze the codebase and propose a plan in plan mode, approve the plan, then have it make small commits with the tests run between each one, updating the plan as it goes. The result is a linear, reviewable series of small changes that you can bisect if something breaks.
For a well-specified task you are happy to review later, a cloud agent works on its own in a remote sandbox and comes back with a pull request: Claude Code on the web, Cursor Cloud Agents, the Copilot cloud agent and Codex Cloud all work this way.
Keep this table open during your week:
| Task type | Mode | Where you find it (October 2026) | Guardrail |
|---|---|---|---|
| Code review, exploration, documentation | Ask (read-only) | Cursor, Copilot, Devin Desktop; Claude Code plan mode | No file edits possible |
| Localized edit or small refactor | Inline edit | Cursor inline edit, Copilot inline chat, Devin Desktop Command | Review the diff before accepting |
| Planning a multi-file change | Plan | Claude Code, Cursor, Copilot, Cline, Devin Desktop | You review and edit the plan; save it as plan.md |
| Feature implementation from a plan | Agent, one step at a time | Claude Code, Cursor, Copilot, Cline, Devin Desktop | Tests per step, review each step's diff |
| Refactor with behavioral changes | Plan, then agent with small commits | Any agent; terminal agents suit long runs | Tests between commits, plan approved first |
| Bug with an unclear root cause | Ask or plan first, then agent | Any | Failing test first; explanation before code |
| Well-specified task to review later | Cloud agent | Claude Code on the web, Cursor Cloud Agents, Copilot cloud agent, Codex Cloud | Review the pull request; CI must pass |
How do I structure planning and execution across a workweek?
The plan-first workflow is the backbone of a reliable system. Without a plan, agents wander. With a plan, they become predictable.
Start your feature work on Monday morning with a planning session, in a plan mode or a separate chat. State the feature clearly, include links to the relevant specs or ticket, and ask for a structured plan. Good plans break the work into small, independent steps, each with a clear success criterion. A good prompt looks like this: "You are a senior engineer planning the implementation of feature X. The requirements are [link to ticket]. The API contract is [link]. The relevant files are [list]. Produce a plan.md with numbered steps. Each step must describe the files to modify, the expected changes, and the test that will verify it. Do not write code yet."
Once you have a first draft, question it. Ask the planner why it chose that order, what risks it sees, and how it would test the integration between steps. Edit the plan yourself to add missing constraints or to reorder steps for a cleaner commit history. Save the final plan in your repository, for example as plan.md. That file becomes the durable specification every later step refers to.
Now switch to execution. Ask the agent to implement step 1. It reads the plan, makes the changes, runs the tests and marks the step done. You review the diff, approve it, and let it move on to step 2. In a terminal agent the rhythm is the same: give it the plan, ask for the first step, a commit and a test run, and move to the next step only after you have reviewed the diff.
When you are fixing a bug later in the week, you don't need a full plan, but you still use a structured diagnostic prompt: "The bug: [description]. The failing test: [test]. The relevant files: [list]. First, explain your step-by-step reasoning about the root cause. Then propose a fix. Do not implement the fix until I confirm." This separates reasoning from action and gives you a chance to correct the model's understanding before it touches any files.
Plan first, then execute in small increments, and you get a natural review rhythm. You never review a large blob of generated code at once. Each step is small enough to understand in a minute or two, and tests catch mistakes before they cascade. The plan file itself becomes part of the history, documenting what the AI did and why.
What guardrails keep AI-generated code safe and reviewable?
Guardrails are the difference between a workflow you trust and one that quietly corrupts your codebase. Trusting AI-Written Code: Tests, Reviews, Guardrails, Part 3, covered verification in depth. Here we build it into your daily routine.
First, never let an agent change code without a test. Before it implements a step, it must find an existing test that covers the behavior or write one first. If you are following a plan, each step's success criterion already names a test, and the agent should not mark the step complete until that test passes. Review changes to test files separately, so the agent cannot make a step pass by weakening its test.
Second, work in small, reviewable diffs. Whether you use Cline's per-step approvals or Claude Code's commit-per-step approach, review each change before the next step begins. The review should take a minute or two. If a diff is too large to understand on one screen, the step was too big, so break it down. Small steps also make git bisect effective: if a bug appears later, you can find exactly which step introduced it.
Third, restrict tools by mode. Plan and ask modes cannot edit files. In agent mode, allow only the tools and areas the task needs. For a feature that only touches the cart service, keep the agent away from the auth and payment modules. That stops it from making "helpful" changes to unrelated code when it spots something it thinks is inconsistent.
Fourth, scope the context. Instead of giving an agent your whole repository, give it the files it needs by @-mentioning them; Cline, Cursor and Claude Code all support @file mentions. This applies Part 4's lesson: a smaller, relevant context produces better results than the whole codebase and a hope that the model's attention lands in the right place.
Finally, keep the plan file as the source of truth. If the agent deviates from the plan, stop it, ask why it thinks the change is necessary, update the plan if you agree, then continue. This stops the agent from drifting mid-implementation.
These guardrails are light, but together they build an audit trail and a safety net. After a week you have a series of small, test-backed commits and a plan that explains each one, which is far easier to read than a single giant commit that says "AI refactored checkout."
How do I manage context across a large codebase during a workweek?
Context management quietly multiplies the effectiveness of your workflow. Repo Context: Why Tools Succeed or Fail on Big Codebases explained how tools find code. Here we focus on what you, the engineer, can do to keep context tight across a week.
Start the week with a short context note for the feature. List the main modules, what each is responsible for, the key types and the interfaces between them. You can draft it with a chat tool ("Given the cart module, the product service and the payment gateway, summarize the flow and list the entry points and data structures"), then save it as context.md and point to it in your prompts all week. Lasting conventions belong in the project's memory file instead, such as AGENTS.md or CLAUDE.md, so every session reads them automatically.
During implementation, be explicit about which files the agent should read. @-mention files and folders in Cline, Cursor or Claude Code. Avoid "look at the whole codebase"; the model pulls in too much noise and its answers get worse. Build the context step by step instead: for step 1, give it the files that step needs; for step 2, those files plus any new ones.
Tools with a semantic index, such as Copilot's, still benefit from explicit scoping. The index helps the tool find related code, but telling it which module or area to focus on makes it less likely to pull the wrong code into the prompt.
A useful trick is to treat the plan file as a context map. Each step lists the files it touches. When you ask the agent to implement a step, give it exactly those files. The plan becomes a context specification, which makes the agent's job mechanical and your review easy.
For debugging or exploration, you can afford wider context in a read-only mode because nothing changes. Even then, pointing the tool at the specific error and the files it mentions gives sharper answers.
Context discipline also means knowing when to start fresh. If a session has gone through many rounds and the context window is filling with old tool calls and stale history, start a new one. Load the plan file and the current state of the code, summarize progress so far, and continue. That keeps the model from being confused by outdated information.
Quick reference
| Property | Value |
|---|---|
| Planning before agent execution | A plan.md with numbered steps and a verification test for each |
| Guardrail for any AI code change | A passing test, with test changes reviewed separately |
| Context scoping technique | @-mention files and folders; never "look at everything" |
| Mode for exploring and reviewing | Ask (read-only) |
| Mode for a focused edit | Inline edit |
| Mode for multi-step feature work | Plan, then agent one step at a time with approval |
| Mode for well-specified work to review later | Cloud agent that opens a pull request |
Test yourself
Your task is to implement a new "wishlist" feature across frontend and backend, with a shared API contract already defined in a spec. You've written a plan file with 5 steps. Which mode do you use for the initial implementation, and what is the checkpoint you set before pushing to CI?
Answer: Use an agent mode with the plan file, one step at a time and with your approval after each step: Cline in Act mode, Claude Code in Manual mode, or Cursor or Copilot in Agent mode. Each step ends with its own commit and a passing test run. The checkpoint before pushing is that all five steps' tests pass together and you have reviewed every step's diff. Then open a pull request from the feature branch with the per-step commits intact, and merge with a rebase or a merge commit rather than a squash, so reviewers can follow each step and git bisect can still find the step that broke something. If CI fails, bisect to the offending commit and re-plan that step instead of debugging one large change.
Frequently Asked Questions
Q: When should I override the AI's suggestion and write the code myself? When you can't state a clear success criterion, or when the change involves a novel algorithm or a security-sensitive path. Writing it yourself is faster than fighting the AI when the specification lives only in your head.
Q: How do I handle a plan that turns out to be wrong mid-implementation? Stop the agent. Discuss the gap in a planning session, update the plan file, and resume. The plan is a living document, but it should never change without your explicit approval.
Q: Can I use the same workflow with local models via Ollama? Yes, but context size and reasoning quality will usually be lower, so use smaller steps and simpler plans. Point your tool at the local API as described in Ollama's documentation, and try the workflow on a small, non-critical feature first.
Q: How do I make sure the AI doesn't introduce subtle bugs that pass my tests? Review the diffs, not just the test results. For logic-heavy code, use a second model in an ask mode as a reviewer: give it the diff and ask for an edge-case analysis. The two-human review becomes a human-plus-AI review.
Q: Is it worth paying for multiple AI tools at the same time? Usually not at first. Cursor and Copilot each now cover every mode in the table above, and Claude Code covers all of them except inline editing in the editor, so one tool is enough to build the habit. Add a second only when it fills a clear gap, such as a cloud agent for background work or an open-source agent for local models.
Build systems, not one-off prompts
If you want to stop guessing and start engineering your AI-assisted development, you need a system you can improve like any other piece of infrastructure. This series has walked you through the landscape, how the tools think, the trust model and the context strategies. The last piece is the workflow itself, and it's the piece you own. Subscribe to Internals Decoded at internalsdecoded.com to get this kind of breakdown every week: how real systems work under the hood, so you can build your own with confidence.
Sources
- VS Code: AI features cheat sheet
- VS Code: Plan work
- Cursor: Inline edit
- Cursor: Plan Mode
- Cline: Plan and Act
- Devin Desktop: Cascade modes
- Claude Code: Choose a permission mode
- Ollama
