Hello Curious Coders,

Have you ever worked with Claude Code, asked it to implement a feature, and felt that uncertainty about applying changes without being sure what was being altered and where?

The first time this happened to me, I realized the problem wasn’t the agent’s capability. It was that I had no checkpoints. I couldn’t see what was being generated in real-time, so I didn’t have the information I needed to make confident decisions.

Moving to a checkpoint-based workflow changed that. Suddenly, I could make explicit decisions about what to keep and what to throw away. My workflow improved because I stopped thinking about a development iteration as an all-or-nothing proposition.

In our first article of this series, I introduced five modes to stop vibe coding. This post is about the first step in that journey: moving to a workflow with built-in checkpoints so you have complete information at every decision point, instead of just being the puppet hitting accept or reject.

Ask → Plan → Agent: Three Checkpoints

The workflow Bruce teaches has three distinct stages, each one a checkpoint that forces an explicit decision before you move forward.

Ask is read-only exploration. You query the codebase, find patterns, and understand what’s there before deciding what should change. The model can read files and explain code, but can’t write anything yet. Your checkpoint question: “Do I understand what’s here?”

Plan is where you decide what should change before any code is touched. The model proposes a sequence of steps, you critique and refine it, and the plan becomes durable context you can refer back to throughout the session. Your checkpoint question: “Do I agree with what should change?”

Agent is execution with review. You let the tool write code, but only after you have a plan and a clear target. You’re not asking “Do whatever you think is right” – you’re asking for specific actions you’ve already agreed to. Your checkpoint question: “Do I accept these specific changes?”

Here’s what this looks like in practice. Suppose you need to add a LiveView event for a form submit.

You start with Ask: “Where are LiveView events handled in this module, and is there a pattern for validations?”

The model shows you the existing patterns. You review them. Checkpoint passed—you understand what’s there.

Then Plan: “Propose the minimal change list to add handle_event(“save”, …) with validation and error rendering. No code yet.”

The model gives you a numbered list of changes. You critique it, refine it, and confirm it matches your intent. Checkpoint passed—you agree with what should change.

Finally Agent: “Apply the plan to lib/my_app_web/live/user_live.ex. Keep changes scoped to the event, the form state, and the render section.”

The model writes code. You see the diff. You have complete information: what changed, where it changed, and why. Checkpoint passed—you accept the changes.

The shift is clear. You’re not giving the model an opening to redesign your component tree. You’re giving it a bounded change. This prevents the “yes loop” that turns into vibing—where you approve changes faster than you can evaluate them because saying yes feels like progress.

The Two-Level Safety Net

Bruce makes this progression practical by building in two layers of protection:

“I have two levels of protection against changing my code in ways that I don’t want. The first one is provided by the agent tooling: keep and undo. The second is GitHub.”
– Bruce Tate

The first level is immediate. Modern agents present changes as diffs—each one a checkpoint where you see exactly what’s being added or removed, and you can keep it or undo it before it touches your working directory. You have complete information right there: the change, the context, and the decision.

The second level is structural. Git is your time machine. If a change is correct but incomplete, you keep it. If the entire approach is flawed, you reset. By separating these two levels of undo, you can let the agent work on larger tasks without risking your codebase.

All-or-nothing tools erase those layers. You accept everything or reject everything and hope the next attempt is better. Checkpoint-based tools preserve them.

Context as a Skill

Even with powerful models, context is finite. In a session where Bruce built a Game of Life implementation, the conversation had already consumed 28% of the available context window just defining the grid and worker processes.

Checkpoint-based tools let you feed the model exactly what it needs. Instead of pasting entire files, you reference them with @symbols – tags like @LifeCore.ex or @LifeWorker.ex that tell the agent which parts of your codebase matter right now.

You don’t need to show the model everything. You need to show it the right thing. Ask mode helps you identify it. Plan mode helps you confirm it. Agent mode uses it.

The Elixir Parallel

There’s an Elixir lesson here. Elixir thrives when you respect boundaries and make state transitions explicit. We don’t let processes mutate each other – we pass messages. We model what changes, when it changes, and who’s allowed to change it.

Ask → Plan → Agent applies the same principle to AI. Ask is inspection. Plan is intent. Agent is the allowed state change. You’re not refusing automation – you’re enforcing boundaries to keep control of the process.

This is also how you catch “sleep creep” – the tendency for AI to introduce non-idiomatic patterns like unnecessary Process.sleep/1 calls into your tests. When you run the progression, you can intervene the moment the code deviates from Elixir’s design philosophy.

One Habit to Start Today

Before letting the agent write code, run the checkpoint sequence:

Ask: Understand the code. Where does the logic live? What’s the existing pattern? Do you have complete information about what’s there?

Plan: Decide what should change. Get a proposal, refine it, make it explicit. Do you agree with what the model wants to do?

Agent: Execute with review. Use keep/undo as your first safety net, Git as your second. Do you accept these specific changes?

If you run those checkpoints, you stop chasing the model and start directing it.

What’s Next

Working with checkpoints was my first step to improving workflows. But I’ve realized what I need to do next: I need to think about my prompts in a way that gives me the ability to take smaller steps and make strategic enhancements along the way.

In the next post, we’ll run the one-shot demo, building a Phoenix LiveView app in 30 minutes, and see why it looks so fast. It will feel impressive, and it is impressive. But all that speed without discipline has a cost.

As we move forward in this series, we’re going to look at improvements to workflow, whether you’re working in an editor or within a dedicated coding agent. Because the tool is just the first step. What really matters is learning to think differently about how you collaborate with AI.

– Paulo & Bruce