Products Marketplace Blog About Contact Sign in Download
lac agent PlanMode: Think Before You Write Code

lac agent PlanMode: Think Before You Write Code

Most AI coding tools start writing the moment you hit Enter. lac agent's PlanMode puts a hard pause between the prompt and the first file write — and that pause is actually the useful part.

The problem with just letting it rip

There's a very specific kind of dread that happens when you give an AI agent a vague task and watch it immediately start rewriting four files at once. You didn't ask it to touch the auth middleware. You don't know why it's restructuring the router. By the time it's done you're staring at a diff that's twice as wide as the feature you actually wanted.

This used to be my default experience with agentic coding tools. Prompt in, chaos out, read the aftermath, figure out what broke.

lac agent has a mode that fixes this, and I don't use it nearly as much as I should: PlanMode.

What PlanMode actually does

When you're inside lac agent and you prefix your message with /plan, the agent doesn't write anything. It reads your project, thinks through the task, and outputs a structured plan — which files it intends to touch, what changes it'll make to each one, and in what order. That's it. Nothing moves until you approve.

It looks something like this in practice:

> /plan add rate limiting to the API using express-rate-limit

The agent comes back with something like:

  • Install express-rate-limit via npm
  • Modify src/middleware/index.js — import and configure the rate limiter, attach it to the router
  • Modify src/app.js — register the middleware before route handlers
  • Update src/config/defaults.js — add RATE_LIMIT_WINDOW_MS and RATE_LIMIT_MAX constants

You read it, you think "wait, I want the rate limit only on the /auth routes, not everything" — and you just say so. The agent adjusts the plan. Nothing has been written yet. No diff to untangle.

That back-and-forth on the plan is genuinely faster than reviewing the actual code after the fact. Especially on larger tasks.

When to use it vs. when to skip it

I don't use PlanMode for everything. For small, surgical tasks — "rename this function" or "add a missing return statement" — the overhead isn't worth it. Just let the agent do it and use undo if something goes sideways.

But there are a few situations where I always reach for /plan first:

  • Any task that touches more than two files. If the agent is going to be spreading changes across the codebase, I want to know the full surface area upfront.
  • Refactors. "Extract this logic into a service layer" is the kind of prompt where the agent's interpretation and your intention can diverge pretty badly. A plan makes that divergence visible before it costs you anything.
  • Greenfield features on an existing codebase. Where does the new code actually live? Does it fit the existing patterns? The plan forces the agent to be explicit about those decisions so you can push back.
  • Anything involving config or environment files. I am paranoid about agents touching .env, package.json, or anything that could silently break a build. PlanMode flags those upfront.

The undo system is the safety net PlanMode pairs with

Even with a good plan, things don't always go exactly right. The agent might implement step 3 in a way that conflicts with how step 1 turned out. That's where lac agent's undo system comes in.

After the agent makes changes, you can type /undo and it shows you a diff preview of exactly what it's about to revert — before it reverts it. Not a blind rollback. You can see the before and after, decide it's what you want, then confirm.

Redo works the same way. It's not just "ctrl+z for code" — it's diff-aware. You always know what's changing.

The combination of PlanMode and undo gives you real control at both ends of a task. You see the intention before execution and you can cleanly step back if the execution drifts.

PlanMode and .lac-memory.json work together

One thing that makes PlanMode more useful over time: it reads from .lac-memory.json. If you've already told lac agent things like "we use a service/repository pattern" or "don't put business logic in controllers," that context shows up in the plan. The agent's proposed file changes will already reflect your project's conventions instead of defaulting to whatever pattern it finds most common in training data.

If you haven't set up a memory file for your project yet, it's worth doing before you start using PlanMode heavily. Even a few lines about your folder structure and coding conventions makes the plans noticeably more accurate. You can set it up by just running lac agent in your project root and telling it how your project is organized — it'll write the memory file itself.

HTTP requests inside agent sessions

One more thing I keep forgetting people don't know about: lac agent has a built-in HTTP request runner. You can ask it to hit an endpoint and use the response as context for the next step — without leaving the terminal or switching to a browser tab. It's useful during PlanMode discussions too: "check what the current /users response looks like before you plan the refactor" is a completely valid instruction.

The practical starting point

If you've been using lac agent but skipping PlanMode because you didn't really know what it did, start with this: next time you have a task that touches more than one file, open your project and run:

lac agent
> /plan [your task here]

Read the plan. Push back on anything that looks off. Approve it once it matches what's in your head. The actual code write after that tends to go much smoother — because you both agree on what's happening before it happens.

lac-cli is free and open source. Install it with pip install lac-cli or grab the install script from the lac-cli page.

We use cookies to keep you signed in and to serve ads via Google AdSense. By continuing to use this site you agree to our Privacy Policy.