The most useful thing I’ve learned about coding agents is to spend more time talking and less time reading their output. I’ve been using Claude Code for nearly a year, mostly on the Lance database. This post is the recipe I’ve landed on, an example of it in practice, and the lesson behind it.
When working on solving an issue, my typical workflow is:
Have a discussion with the agent. Inputs might be an issue, a Slack thread, or my own idea. I’ll say something like “read up on this and lmk what questions you have” or “I want to have a discussion about this”. Importantly, I don’t use plan mode. (Read why below.)
Have the agent distill our discussion into a plan. If it’s just one unit of work, write it in a temporary markdown file 1. If there are multiple units of work, I’ll have the agent create a GitHub issue for each. I don’t read the plan; I trust it’s a faithful summary of our discussion.
Assign a fresh agent to carry out the plan. If there are multiple tickets, I run an agent per issue in parallel. Often, it can get to completion without further guidance.
Ask the agent to draft a PR, then call my
/polish-prskill. This custom skill just mirrors the final pass I used to do on my own PRs: remove dead code, check test coverage, improve readability, and so on. 2Review in GitHub. I often review it like a PR from someone else, with comments directly in GitHub. Then I’ll tell the agent I left comments to address. If there are non-trivial changes, I’ll go back to step 4.
That’s the workflow. Compared to when I started, I spend a lot less time reading plans, babysitting permission gates, or reading exact code changes as they happen. Most of my time goes to the initial discussion and the final review. I’ll share a little bit more on how I landed on this and why I like this setup. But first, it’s helpful to see this workflow in the context of an example.
Example: a conversation, then two PRs
My colleague presented me a performance bug in our BM25 index. Prewarming all the posting lists into cache required thousands of 20-byte reads (ouch!). Not all the posting lists were small but—due to the Zipf-nature of natural language—most of them were. My idea: what if we could group the posting lists into chunks of 4KB? We had two key constraints. First, no breaking changes to the on-disk format. Second, we didn’t want to gate reading the posting lists on more IO. I let Claude know my idea and these constraints, then asked it to check whether this would work. This was my initial prompt.
Claude came back with a wrinkle: the offset data we needed to do the grouping was now lazily loaded. We can’t get them without more IO. But we didn’t need the individual posting list offsets; all we needed was offsets to the start of each chunk. These offsets are much smaller, so, Claude reasoned, why don’t we store these in the index’s header? A good find, and a reasonable suggestion. In a fast moving code base, agents make it much easier to keep up with the current state of the code.
I like the chunk offset idea. But putting it in the header? I thought we could do better. Elsewhere, we had an optimization called opportunistic read. We start reading a file by fetching the last block to get the last few bytes. Sometimes we capture more than one message. If the data is small, we often get the extra structure for free. If the data is large, we don’t pay the price of fetching something we may not use. This seemed like a good case for it—but I couldn’t recall if we implemented this for index files. Easy enough for an agent to find out, though.
Claude reported back that the optimization was partly there and we could finish it. So now we had two things to work on: the chunk offsets and the opportunistic read. At this point I ask Claude to create a GitHub issue for each.
This sort of conversation is typical of how I start my sessions. I bring an understanding of the problem, some ideas, and recollection of how we solved similar problems. Claude brings an up-to-date understanding of the codebase, some helpful suggested solutions, and some healthy pushback to my ideas. And we keep iterating until we find something we both agree will work.
From here, I closed the session, and opened two new sessions, each in their own worktree. I point each at their respective issue, and ask them if they have any questions before they begin implementing. This is my typical prompt now, when I have an issue I’ve already researched.
I’ll put the agents in Auto mode while they implement. First, it makes it much less distracting to not have to watch them for permission prompts. Second, for implementing tickets like this I’m not usually worried about permissions. I’m usually modifying library code and working on OSS projects. Plus the classifier is pretty smart about standard things. It always asks me before force pushing to a branch, for example. However, I can’t recommend using this mode in production environments. That kind of environment requires much more accountability and trust than an agent in Auto mode can provide.
With both a well-researched ticket and auto-permission mode, I find agents can finish the implementation without much guidance. This was the case here, giving me two pretty clean PRs 3.
Why I stopped using plan mode
When I first started using Claude Code, I would always use plan mode. I would tell it what I wanted, it would ask some questions, and then generate a plan. I would read the whole plan, and tell it to make some corrections. And then it would give me a whole new plan. On the second or third iteration, I usually got tired of reading that wall of text. (Okay, if I’m being honest, I probably got tired of it halfway through the first iteration.) Not only was course-correcting tiring, plan mode jumped to solutions. I needed my assumptions validated or my ideas probed, not an immediate implementation plan. And if I gave into the immediate suggestion, I often ended up with a PR that needed a major course correction.
At some point I came across Matt Pocock’s YouTube videos on working with coding agents. His videos focus on bringing software design principles—such as those from The Pragmatic Programmer4—to agentic coding workflows. The key skill was the grill-me skill, which tells the agent to interview the user (an approach Anthropic also recommends):
“Interview me relentlessly about every aspect of this plan until we reach a shared understanding.”
One of the key ideas is “until we reach a shared understanding”. When I was going straight into plan mode, we lacked this shared understanding. The agent, not knowing I wanted anything different, went straight into planning a solution to the problem as described in the initial prompt. However, finding a good plan takes several rounds of back and forth between the agent and the engineer. Both sides have valuable insights to contribute, but plan mode isn’t well structured to allow an easy exchange of ideas. An interview session is.
Agents aren’t mind readers — you have to tell them what you need. And good ideas take iteration; they are almost never the first one you think of. A conversation is a fantastic medium by which to share information and refine one’s thinking. It’s improved my agentic coding workflow drastically. In fact, I’ve found it useful in far more places. (I’ve even had a 15-minute conversation developing my next beer recipe5.) Try this in your next project. You will find it less exhausting and more productive.
Footnotes
A small aside—if you are writing your own skill, I highly recommend using Anthropic’s Skill Creator skill. If you give it some example PRs where you had to write additional commits to clean up its work, it can run a good evaluation loop to check the performance of the skill and make improvements.↩︎
You can see them at https://github.com/lance-format/lance/pull/7043 and https://github.com/lance-format/lance/pull/7042↩︎
The Pragmatic Programmer by Andy Hunt and Dave Thomas is a classic in software engineering, originally published in 1999. I read it recently and, like Matt, agree it’s as relevant as ever.↩︎
We settled on a Belgian-style Amber Wheat beer. Yes, it was delicious. 🍻↩︎