I recently ran a lunch-and-learn session on agentic coding — using AI agents to write, refactor, and reason about code. The tooling landscape is moving fast. Claude Code, Cursor, Gemini CLI, GitHub Copilot, Antigravity — new entrants and major updates are arriving monthly. It’s genuinely difficult to keep up.

Because of that pace, I deliberately avoided making the session a tool tutorial. Tool tutorials have a short shelf life. Instead, I focused on the mental models and workflow habits that make you effective regardless of which tool you’re using.

The underlying large language models powering these tools share the same fundamental strengths and limitations. They’re pattern matchers trained on vast corpora of code and text. They’re stateless within a session beyond their context window. Their confidence matches your confidence - even when you’re confidently wrong. Understanding these properties and building your workflow around them matters far more than learning the tips and tricks of any particular tool.

To prove the workflow works, we ended the session by building a fully functional web app from scratch, live, in under 30 minutes. More on that later.

The Agent Amplifies Your Clarity

This is the foundational principle, and everything else flows from it: the agent amplifies whatever you bring to it.

If you bring a clear problem statement, well-defined constraints, and a solid understanding of what “done” looks like — you get remarkably good output. If you bring vague requirements and fuzzy thinking, you get something much worse than nothing: you get confident-sounding confusion. Code that looks right, passes a quick glance, and quietly does the wrong thing.

This has some practical consequences that are worth sitting with:

  • If you can’t articulate the problem, the agent can’t solve it. It has no way to disambiguate. It will pick an interpretation and run with it — confidently.
  • If you can’t evaluate the plan, the agent will execute a bad one. It won’t push back. It won’t tell you the approach is flawed. It’s incredibly capable, but it’s also incredibly compliant.
  • If you skip review, bugs ship faster than ever. The agent removes the bottleneck of writing code. If review was already your weak link, that weakness is now amplified.

The key reframe here is that agentic coding puts more onus on clarity and decision-making, not less. The hard parts of software engineering — understanding the problem, making architecture decisions, evaluating trade-offs, reviewing output — those are still yours. The easy parts are now instant.

This is great news for experienced engineers. Your judgment, taste, and domain knowledge are more valuable than ever. But it means the path to getting value from these tools runs through your own clarity of thought, not through mastering a particular UI.

The Workflow: Plan Before You Execute

Most people’s first instinct with a coding agent is to describe what they want and let it rip. This works for small, well-understood tasks. For anything meaningful, it falls apart quickly.

The workflow I’ve found most effective borrows from design thinking — three distinct phases, each with a different balance of human vs agent ownership.

Phase 1: Problem Discovery (You Lead)

Before the agent touches any code, you need a clear problem statement. What are we actually solving? What does success look like? What are the constraints?

This happens outside the coding agent. Use a chat interface, a notepad, a whiteboard, a conversation with a colleague. The goal is to go from a vague idea to a clear, bounded problem statement. This is your job. The agent has nothing useful to contribute here because it doesn’t know what you care about, what your users need, or what your constraints are.

A problem discovery prompt should never include implementation details. You haven’t earned that clarity yet.

Phase 2: Solution Discovery (Collaboration)

Now bring the agent in — but in planning mode, not execution mode. Give it access to the codebase and ask it to propose an approach. Most tools have some form of this: a mode where the agent can read and reason about code but without the permission or instruction to modify it.

Your job in this phase is to review, challenge, and approve. Does the proposed approach make sense? Does it follow existing patterns in the codebase? Is it over-engineered? Under-engineered? This is a conversation, not a handoff. You should be looking for ambiguity and making decisions to turn it to clarity.

Phase 3: Implementation (Agent Leads)

Only after you have a clear problem statement and an approved plan should the agent start writing code. At this point, it has everything it needs: a well-defined problem, a reviewed approach, and access to the codebase for context. Your role shifts here: the agent writes, you read. All. The. Code. Every line of the diff is yours to review — that’s the deal.

The most common mistake is jumping straight to Phase 3. People skip problem and solution discovery, go directly to implementation, then spend cycles iterating on output they can’t properly evaluate because they never clarified what they actually wanted. The irony is that skipping the planning phases usually takes longer, not shorter.

Slowing down in Phases 1 and 2 makes Phase 3 dramatically faster. The agent produces better output on the first pass, you can evaluate it more confidently, and there’s less back-and-forth. This is true for basically any task beyond a one-line fix.

Specific Prompts = Specific Results

This is the single biggest lever you have for improving output quality, and it follows directly from how LLMs work. These models are next-token predictors operating on the context you provide. The more specific and unambiguous that context, the tighter the distribution of likely outputs — and the more likely you are to get what you actually want.

Compare:

“Fix the bug”

vs.

“The /users endpoint returns 500 when email contains a + character. Expected behavior: the email should be URL-encoded before the database query. Here’s the stack trace: …”

The first prompt could lead anywhere. The second gives the agent everything it needs: the symptom, the location, the expected behavior, and diagnostic information. It’s the difference between sending a junior engineer on a treasure hunt vs. handing them a well-written ticket.

Before hitting Enter on any prompt, I run a quick three-question litmus test:

  1. Would a senior engineer understand exactly what to build from this prompt? If not, the agent won’t either.
  2. Have I included the constraints that matter? Tech stack, patterns to follow, boundaries to respect.
  3. Am I describing the problem or jumping straight to a solution? Describing the problem gives the agent room to find a good approach. Dictating the solution means you’d better be right.

One related practice worth adopting: most agent tools support some form of project context file (CLAUDE.md, .cursorrules, copilot-instructions.md, and so on). Think of this as your onboarding document for the agent — the same brief you’d hand a new engineer on day one. Project structure, tech stack, coding conventions, how to build and test, what not to do. It’s a small investment that pays off on every interaction.

Revert and Redo > Iterate on a Bad Foundation

This one is genuinely counterintuitive. Engineers are trained to iterate. Write something, refine it, tweak it until it’s right. With agents, this instinct is often wrong.

When an agent produces output that’s heading in the wrong direction, the natural impulse is to give it corrective feedback and iterate. “No, not like that — do it this way instead.” The problem is that the agent now has a mess of wrong code in its context, plus your correction, and it tries to reconcile the two. The result is usually more wrong code built on top of wrong code.

A fresh start with a better prompt is almost always faster than patching bad output.

The practical workflow:

  • Git commit before every agent run. This is your safety net, full stop. It takes seconds and gives you a clean revert point.
  • If the output is fundamentally wrong: revert, improve your prompt, and try again from clean. Don’t try to salvage it.
  • If it’s close but not quite right: iterate, but only if the foundation is sound. There’s a meaningful difference between “the approach is right but there’s a bug” and “the approach is wrong.”

This feels wasteful to people at first. You’re throwing away code! But the code was wrong, and the agent can regenerate correct code in seconds once you give it better instructions. Your time is better spent improving the prompt than debugging generated output that started from a flawed premise.

Iteration on bad foundations compounds errors. A fresh start with better context is almost always faster.

Trust, But Verify

The agent writes code at machine speed. Your job is to review it at human speed.

This isn’t optional, and it’s not something you can skip “just this once.” The agent is confident whether it’s right or wrong. It won’t flag its own uncertainty. It won’t tell you when it’s guessing. The output always looks reasonable — that’s what makes it dangerous to skip review.

Things to watch for:

  • Hallucinated imports — Dependencies or modules that don’t exist. The agent has seen them in training data but they’re not in your project or your registry.
  • Over-engineering — Abstractions, services, or patterns you didn’t ask for. The agent is trained on a lot of enterprise code and sometimes brings that baggage.
  • Silent file changes — Modifications outside the scope of your request. Always check git diff --stat to see which files were touched.
  • Tests that don’t test — Tests that pass but don’t actually assert anything meaningful. Green CI doesn’t mean correct code.
  • Helpful refactors — Subtle changes to existing code that alter behavior in ways you didn’t expect or ask for.

The discipline is: read the diff (every line), run the test suite, manually verify the happy path, and check for unexpected file changes.

It’s also worth acknowledging that there are times when agentic coding is the wrong tool. Quick one-line fixes where typing is faster than explaining. Security-critical code paths where you need deep domain expertise in the review, not just pattern matching. And situations where the goal is learning — if you need to understand how something works, reading and writing the code yourself is far more valuable than generating it.

Knowing when not to use the tool is part of using it well.

The Demo: MoodSwing Todo

To put this workflow to the test during the session, we built a fully functional web app live — from concept to working code.

Problem Discovery

We started with a deliberately open question: what should we build? The requirement: something fun, self-contained, and achievable in a single session. This phase was all about defining the product — no code, no agent, just humans figuring out what would be entertaining to build.

The concept we landed on: a todo app with emotional instability. A perfectly functional task manager that celebrates your completions in wildly different emotional registers. We fleshed out the product details:

  • Three celebration personas, each with a completely different voice:
    • The Saint — new-age warmth and cosmic energy. “Your radiant energy just cleared ‘Buy groceries’ from the universe.”
    • The Snark — dry sarcasm and barely-concealed disappointment. “Wow. ‘Buy groceries’ is done. Truly mediocre.”
    • The Corporate — buzzword-laden business jargon. “Let’s circle back to how you moved the needle on ‘Buy groceries’.”
  • Procedural message generation — a Mad Libs-style engine so no two completions feel the same.
  • Multi-sensory feedback — confetti, screen shake, and a victory fanfare.

The output of this phase was a clear product brief — which became the prompt for the next phase.

Solution Discovery

Now we brought the agent in, in planning mode. We handed it the product brief and collaborated on the technical decisions:

  • Tech stack: React, Vite, Tailwind CSS — standard, nothing exotic.
  • What we weren’t going to do: no backend, no authentication, no external APIs, no database. localStorage for persistence. Keep it self-contained.
  • Architecture: component structure, how the procedural copywriting engine would work (template-based with combinatorial adjectives/nouns), Web Audio API for synthesized sound rather than audio files.

We reviewed the plan, challenged a few decisions, and approved the technical approach before writing a single line of code.

Implementation

With the spec locked, the agent built it — roughly 600 lines of code across 15 files: components, services, animations, the procedural copywriting engine, audio synthesis, the lot. Our job was to review the output line by line and test the result.

What the agent handled: component architecture, state management, localStorage persistence, confetti animations, audio synthesis, the entire template-based copywriting system.

What the human handled: the creative brief, the persona voice and tone design, the “is this actually fun?” judgment call, and reviewing every line of the diff.

The result is live at moodswingtodo.richardnichols.net — go add a task, complete it, and see which persona shows up to celebrate. Fair warning: The Snark is not impressed by your achievements.

The velocity was real. But it only worked because the phases were respected — product definition first, technical planning second, implementation last.

Invest in the Workflow

The tools are going to keep changing. Next month there’ll be a new entrant, a major update, a paradigm shift in how these interfaces work. That’s fine. The workflow doesn’t change, because it’s built on the properties of the underlying models, not the interfaces wrapping them.

Three things to take away:

  1. The agent amplifies your clarity — or your confusion. Invest in problem definition before you invest in prompting. The hard work happens before you open the tool.
  2. Plan before you execute. Discover the problem, then discover the solution, then implement. Skipping phases costs more time than it saves.
  3. Verify everything. The agent writes code at machine speed. Review it at human speed. Speed without review is just faster bugs.

If you’re exploring agentic coding, start with a low-stakes side project and practice the workflow. Build something fun. Get a feel for where the agent excels and where it needs guardrails. Develop your own sense of when to trust, when to challenge, and when to start over.

The mental model is what makes you effective. These tools don’t replace sound engineering, rather they amplify it - for good or bad.