I was well into building a Chrome extension when I found out it couldn’t do the one thing the whole idea was for.
The tool’s biggest value was meant to be on a phone, and extensions aren’t supported in Chrome’s mobile app.
I’d approved the plan and the task list after skimming them, so I found out late.
That’s when I became very aware of how I’d been reviewing my agent’s work.
When I started working with AI agents, I read every plan line by line, because the work mattered and the agent was new.
But somewhere along the way, I started skimming and letting the agent proceed.
While I was still the person approving the work, in practice I was waving it through 😬
So this is about why I stopped reading my agent’s plans, what I got wrong about the fix, and the small thing I changed.
Why I Skimmed the Plan for My Chrome Extension and Approved It Anyway
I’d done the initial exploration and research with my agent, and it all sounded good. At least from my skimming.
Then came the plan and the task list.
They looked generally okay, but I didn’t read every line because, quite frankly, it was overwhelming.
The plan was split into sections and features, yet nothing about the layout invited me to go through it. It was dense and wordy, and it kept referencing variables it planned to use later, names for things that didn’t exist yet.
Plans do that, since they lay things down ahead of time, but it makes them hard to picture. I was also relatively new to Chrome extensions, which didn’t help.
I approved it. The agent scaffolded the project (it set up the files and folder structure), and I reached a checkpoint where I had to verify the result. My feedback was short: I can’t access it on mobile.
The agent said Chrome’s mobile app doesn’t support extensions and suggested a browser that does. That’s not what I wanted, and it wasn’t what I thought we’d planned.
The whole point was Chrome on mobile, yet here I was with an MVP hard-blocked by a limitation of Chrome itself.
If I’d known that up front, I wouldn’t have gone as far as I did, because it invalidated the product idea in my head.
I skimmed the plan, approved it, the agent scaffolded the project, and only then did a checkpoint tell me the idea couldn’t work the way I’d pictured it 🤦♀️
Related: Try This Free Chrome Extension To Capture You’re Best Ideas
Why AI Agent Plans Read Like Machine-Generated Reports
The plans I get from agents are very specific and very technical, and they’re organized as lists of everything that’s about to happen. The main point is somewhere inside.
A plan that lists everything it’s going to use is a shopping list for a meal I haven’t seen yet, so it doesn’t do much in helping me visualize what I’ll end up with.
Breaking it into sections doesn’t fix that, because each section still runs wordy.
Lately I’ve seen plans that include a diagram, and even then there are too many words around it and too much planned ahead of time in one place.
All the information is there. It’s just that my eye has nowhere to settle on the specifics.
The most human-readable, friendly plan I’ve seen came from the early version of Google’s Antigravity IDE. It used formatting and highlighted the key takeaways I needed to know.
I’ve since moved primarily to Cursor, which doesn’t do a great job of formatting its plans or making them easy to read. A wall of text, some tables, and a potential diagram don’t really do much for delivery.
Hey! Since its recent updates, I haven’t used it much, so I can’t vouch for whether that still stands. That’s my experience with both, and tools change quickly, so check how yours does.
Why Asking Your AI Agent to Explain a Confusing Plan Costs Time and Usage
When a plan overwhelms you, asking the agent what it means should be the fix. The problem is that it costs more than it looks.
Every “what do you actually mean here” is a round trip: you send the question, wait, and read the answer. That takes time, and depending on how you pay for your agent, it can also eat into your usage quota.
None of that is big on its own, but across a day of work it adds up, and clarifying starts to feel like a tax.
Apparently I decided that not understanding the plan was cheaper than asking about it. So I asked less than I should have, and mostly let the agent get on with it. I would check the implementation itself (terrible idea).
Now, nothing breaks when you skip a question. The plan runs, the diff shows up (a diff is the list of lines the agent added and removed), and everything looks plausible.
In my case, the first signal came at a checkpoint, after the agent had already scaffolded the project.
Note 💬
I write about code, so code is my example, but the same thing happens if you approve AI-drafted research, writing, or planning documents. This isn’t a case of working with an AI model only for coding. It applies to generating plans and getting responses across any use case that you do with any AI model or agent.
What a Caveman LinkedIn Thread Taught Me About How AI Agents Respond
I found out you can change how an agent responds in an unlikely place: a LinkedIn post about Caveman, a tool that makes your coding agent answer in short, caveman-style sentences.
I’ve never used Caveman. In fact, I never heard of Caveman before, and honestly, I skimmed the post. The comments were actually what caught my attention since that’s where people were replying the way Caveman replies.
I found that funny, and I could see why the need arose. The repo says it started as a joke, and it now has over 100,000 stars on GitHub. It was built around the concept of saving tokens. One of its own examples squeezes a 63-token explanation of why a React component re-renders down to 20 😅
If you’re wondering what that even looks like, the most compressed mode reads: “Inline object prop, new ref, re-render. useMemo.”
For anyone who knows React, you know that useMemo is a hook that caches a value between renders; that’s instant. But if you don’t, you’re rebuilding the reasoning the longer version spelled out. Shorter and clearer are two vastly different things.
While I wouldn’t use it myself because it’s literally unintelligible to me, I was inspired.
It wasn’t compression that I was after, but delivery. That was something I could change, and I never thought of it that way.
Tip: Caveman’s README is transparent about its shortcomings, providing complete sentences for security warnings and irreversible actions. If you’re curious about the token side, read that before anyone’s summary of it, including mine.
How I Got My AI Agent to Explain Plans Like a Senior Engineer Would to a Junior
I’m an engineer who works with features, design systems, and complex integrations. I wasn’t trying to simplify any of that, and I wasn’t trying to cut it down the way Caveman does.
What I wanted was the information presented so it makes sense, sticks, and hits. I also know that looks different for different people.
Think about telling an AI to explain something like you’re five, or like you would to a fifth grader, or a junior engineer. Contrary to what it suggests, none of those make the content simpler. Instead, they pick who the explanation is for, and the delivery changes to fit.
So I wrote a global user rule that does that for plans and summaries. It targets a junior engineer, with the explanation coming from a senior standpoint, in a voice close to the one I use for THT posts.
It’s what I find myself doing when I liaise with other teams or explain things to PMs and other engineers. I break the problem down so the other person can follow it.
The same applies to a plan, because you weren’t part of every step, every idea, and the reasoning behind each change. You need to know what motivated those changes and what they do. A clinical, very technical report leaves that reasoning out unless you probe, and every probe is another round trip.
For a plan, that means the assumptions get stated in plain lines. If mine had said “this assumes extensions run in Chrome on mobile,” I could have quickly checked that. I can’t prove it would have saved me, but I’d have had the chance.
For a summary, I want what a good pull request description gives a reviewer: what changed, which decisions mattered, and what to inspect first.
Explore: Why AI Code Review Is Now Secretly Killing Developers
What a Global User Rule Changed About How My AI Agent’s Plans Read
These are my observations, and none of them is a measurement. The main point comes through when you first read it.
The explanation sounds like a helpful engineer talking instead of a machine-generated report.
Plans stay detailed enough that I can implement them without guessing. And I can find what needs my attention without skimming several paragraphs.
The rule is by no means ironclad, and that’s on purpose. My goal wasn’t to over-engineer, nor did I want it to become a system in itself that ends up burning more tokens.
A global user rule makes some plans and responses more digestible (it’s not a guarantee for all). You can take it further into a shared package, but I haven’t measured token usage, so I’m making no savings claim.
My claim is about clarity.
How This Rule Differs From My Implementation Brief
If you read my earlier post on the implementation brief, you’re probably wondering how the two fit together.
I think of it like this:
The brief is a post-work learning layer. It explains decisions instead of listing activity, and it adds to the agent’s normal summary instead of replacing it.
It doesn’t translate the work into plain English, because that was never its job.
The rule covers how the agent delivers its communication before plans and after summaries.
The brief helps me learn from finished work. The rule helps me understand the agent while the work is still mine to steer.
Either one stands alone.
Related: How to Understand AI-Generated Code in 5 Minutes
Why a Clear AI Agent Plan Still Doesn’t Replace Checking the Work
The checkpoint is what caught my extension problem. A clearer plan might have raised it sooner, and a readable plan still wouldn’t have replaced the checkpoint.
A readable summary can still leave out a failure, hide an assumption, or overstate what got done.
Two-thirds of developers say their top frustration with AI is output that’s almost right, but not quite. Almost-right work reads fine, and so does a fluent summary of it 💁♀️
For instance, say a summary tells me all the tests pass. It reads exactly the same whether forty tests ran or four.
What better communication gives me is a more informed review, and the review still means opening the diff, reading the test output (what passed and what didn’t), and checking the logs (what happened while the work ran).
A summary that says which tests ran, which got skipped, and which decision to double-check gives my attention somewhere to go.
A smooth paragraph saying everything went well doesn’t.
Tip 📍
Before you approve a summary that reads well, open the diff and the test output anyway. If clarity lowers the cost of understanding, you can spend what you saved on checking instead of decoding. However, if you treat clarity as a replacement for checking, you swapped one fake review step for another.
A Three-Question Test for Any AI Agent Plan or Summary
You don’t need my rule or any tool for this one. Grab the last plan or summary your agent gave you and ask three things:
- Can I state the main point after one read?
- Do I understand the work well enough to act without guessing?
- Can I point to what still needs my attention?
The first is the easiest to fool yourself on, because it’s easy to feel like you understood something while scrolling past it.
But ask yourself if you can say the main point back in one sentence. No? Then reread once and try again. And if the second attempt fails too, the delivery is the problem, and your attention is fine.
The second is about guessing. If you’d have to ask the agent to fill in a step before you could do the work yourself, the plan has a gap, however polished it reads.
And the third is about priority. Because if each paragraph looks equally important, it’s not gonna do you any good. That means nothing got prioritized, and you’re back to scanning everything.
If any answer is no, the output failed, however complete or short it was. A thorough plan you can’t summarize hasn’t communicated, and neither has a tight plan that skips the assumption you needed. This applies whether you’re researching, writing, or coding.
It’s a Wrap
I skimmed one plan and found out late that my extension couldn’t run where I wanted it. I can’t change what an agent writes by default, but I can change how I ask it to say it.
These days, I want mine to communicate like a helpful engineer: make the main point clear, provide enough detail to act on, and make the parts that need me easy to find.
If you only do one thing after reading this, run the three-question test on one plan this week. And if it fails, you’ve found the problem without changing any tools.
For anyone who wants to see what I tried, my engineering communication standard is here: Workflows GitHub repo.
Check it out, let me know your thoughts, and keep the curiosity going.
‘Til next time, friends 👋
