The problem with AI code edits
Here is the situation I used to find myself in constantly. I'd ask an AI assistant to refactor a function. It would rewrite the file. The file would look reasonable. I'd move on. Then twenty minutes later I'd notice that a helper function I wrote last week had quietly disappeared, or an import got renamed in a way that broke something three files away.
The issue isn't that the AI made a bad edit. It's that I had no clean way to see exactly what changed before committing to it. Copy-pasting into a diff tool is friction. Most terminal-based agents just dump the new file content and call it a day.
lac agent does something different. Every edit comes with a diff preview, and there's a proper undo stack sitting underneath the whole session.
How the diff preview actually works
When lac agent is about to write a file, it doesn't just write it. It shows you a before/after diff in the terminal — added lines in green, removed lines in red, the same format you'd see from git diff. You review it, confirm, and then it writes. That confirmation step is not a nag. It's the whole point.
What this means in practice: you can ask the agent to do something broad like "clean up this service layer and make the error handling consistent" and actually read what it intends to do before your files change. If it's about to delete something you want to keep, you catch it right there.
This is how it should always have worked. The AI proposes, you approve, then it lands.
Undo and redo go further than you'd expect
Even with a diff preview, you will occasionally approve something and then change your mind. Maybe the refactor was fine in isolation but broke the mental model you had for the module. That's where the undo stack comes in.
Inside a lac agent session, you can type /undo to revert the last file write. Type it again and you go back another step. The agent keeps a full history of every file it has touched during the session, so you can walk backwards through your changes without touching Git at all.
/redo moves forward again if you undid too far. It's a real undo stack, not just "here is the original file content I saved before I touched anything." Each individual operation is its own checkpoint.
If you're using /multi mode and a whole parallel agent session went sideways, there's a session-level undo that reverts everything from that run at once. But for normal single-agent work, the per-operation undo is what you'll reach for most.
Where the HTTP request runner fits in
This one surprises people. lac agent isn't just a file editor — it can also make HTTP requests directly from inside the session. You can ask it to hit an endpoint and use the response to inform what it writes next.
Say you're building an integration with an external API and you want the agent to generate a typed response model based on what the API actually returns. Instead of you copying a JSON response from Postman and pasting it in, you just tell the agent the endpoint and let it fetch the real data. It reads the shape of the response and writes the model from that. The whole loop stays inside one session.
It's also useful for validation. After the agent writes a route handler, you can ask it to hit http://localhost:3000/your-route and check whether the response matches what you expected. If it doesn't, the agent already has the error in context and can fix it without you doing anything.
This pairs well with the /watch browser monitor too — but that's a separate workflow. The HTTP runner on its own is already worth knowing about.
Putting it together in a real session
Here's roughly how a typical session looks when you use these features together:
- Run
lac agentfrom your project root - Ask it to make a change — something real, not trivial
- The diff preview appears. Read it. Confirm or reject
- If you confirmed and later want to back out, type
/undo - If the change involves an external API, tell the agent the endpoint and let it fetch before writing
- Use
/redoif you undo too aggressively
The session history is stored in .lac-memory.json at your project root, so the agent knows what it has already touched. That also means if you close the terminal and come back, the context is still there.
Why this matters more than it sounds
A lot of people are cautious about letting an AI write to their files because they've been burned before. The paranoia is rational. Files get clobbered, context gets lost, and suddenly you're doing archaeology in git reflog.
The diff-first, undo-stack approach flips that. You're not handing over write access and hoping for the best. You're reviewing every change before it lands and keeping a rollback path open the whole time. That's just good engineering practice applied to an AI agent.
Once you work this way for a week, going back to any tool that just silently overwrites files feels wrong.
Quick start
If you don't have lac-cli installed yet:
pip install lac-cli
Or with the shell installer:
curl -fsSL https://lacai.io/install.sh | bash
Then from any project directory:
lac agent
The first time you run it, the setup wizard walks you through picking your provider — Claude, OpenAI, or a local Ollama model. Config lives at ~/.lac/config.json if you ever want to edit it directly. After that you're in. Try asking it to refactor something, watch the diff, and then hit /undo just to feel what it's like to have the floor under you. You'll keep it.
Full docs at lacai.io/lac-cli.