A few days ago, I had one of those AI conversations that got more interesting as it went along.
I was talking with Claude about whether I should change the way I code with AI.
Right now, my normal workflow is session-based. I work in threads. I give the AI project guidance. I make it read the startup documents. I make it inspect the code. I keep the work bounded. I use handoffs when a thread gets too long or when the task changes shape.
That workflow has grown up over time because I’ve been burned enough to know what happens when the AI starts guessing, drifting, or working from summaries instead of the actual project.
But agentic coding has been getting a lot of attention, and it was worth asking the question honestly.
Would I benefit from changing how I work?
So I asked Claude.
The pitch made sense
At first, Claude gave me the expected pitch.
Agentic coding can inspect the repo.
It can create plans.
It can run tests.
It can work through implementation steps.
It can generate documents.
It can keep track of what changed.
It can maintain context across a larger task.
It can reduce the amount of manual coordination the developer has to do.
None of that was wrong.
In fact, it sounded pretty good.
If I were starting from a workflow where I was just throwing prompts at a chatbot and hoping for the best, that would have been a major improvement.
But the longer we talked, the more the conversation started to turn.
The list started sounding familiar
Claude would name one of the benefits.
The agent can create a plan.
And I’d think, yes, we already do that.
The agent can keep project documents updated.
Yes, we already do that too.
The agent can inspect the repo before making changes.
That’s already part of the startup discipline.
The agent can write code.
Yes. That’s a big part of the workflow.
The agent can debug what went wrong.
We do that too.
The agent can maintain a changelog.
That’s already part of the process.
The agent can prepare handoffs.
Yes. Constantly.
The agent can summarize what happened and help the next session start cleanly.
That’s not a future benefit for me. That’s Tuesday.
The funny part was that Claude wasn’t wrong about the value of those things. Those things are valuable.
That was the point.
The surprise was that I wasn’t missing them.
I was already getting most of that value from the way I was using AI inside a structured session-based workflow.
I do let the AI write code
One thing I don’t want to gloss over is that I absolutely let the AI write code.
I’m not using AI as a secretary while I sit there doing all the “real” programming by hand.
That would miss the point.
A lot of the time, the AI is writing the implementation. It’s making the changes. It’s inspecting the files. It’s explaining the pattern it found. It’s taking the next pass when the first version isn’t right.
And when something goes wrong, the AI can often help find the mistake much faster than I could by hand.
That doesn’t mean I blindly trust it.
I don’t.
But if the AI introduced a bug, it can often compare the intended behavior against the actual code and tell me where the failure happened. It can trace the path. It can explain the mismatch. It can suggest the smaller fix.
That’s useful.
The way I think about it is pretty simple.
The AI is like a junior coder who knows the entire internet and can type 3,000 words a minute.
I can’t compete with that typing speed.
I don’t need to.
My job is to guide the work, check the result, set the boundaries, and make sure the code still belongs to the project we’re actually building.
I wasn’t writing all that stuff
One of the assumptions hiding in the agent pitch was that I must be doing a lot of that coordination manually.
And if I were, the argument would be stronger.
If I personally had to write every handoff, every implementation plan, every changelog note, every startup summary, and every next-session instruction, then sure, I’d be looking for a way to get that burden off my desk.
But that’s not what’s happening.
The AI is already doing a lot of that work.
I’m not sitting there lovingly handcrafting project documents because I enjoy paperwork.
I don’t.
I’m having the AI maintain them because that’s one of the things AI is good at.
It can take the messy flow of work and turn it into something structured.
It can keep track of decisions.
It can summarize progress.
It can write the boring-but-important notes that make the next session safer.
That’s not me doing clerical work instead of using an agent.
That’s me using AI to make the workflow less clerical.
The remaining benefit got smaller
By the end of the conversation, Claude had walked itself into a much narrower conclusion.
The main thing I might gain from switching workflows was not some revolutionary improvement in planning, documentation, context management, coding, debugging, or change tracking.
I was already doing those things.
The main benefit was more mechanical.
An agent might save me from downloading a zip file, unzipping it over the repo, and typing the one-letter command from my batch file that builds and runs the application.
That’s not nothing.
Automation has value.
But it’s also not the same as saying my whole workflow is missing the future.
At that point the conversation became less about agentic coding and more about something else:
What work is the AI already carrying?
That’s the question that matters.
Then we talked about cost
The conversation also turned into something more practical.
Money.
In my normal workflow, I’m not using some giant enterprise AI setup. I’m mostly working with regular paid accounts.
With ChatGPT, I often hand the AI a zip file that contains the full repo, minus the things it doesn’t need, like dependency folders and generated bulk. When I get an iteration back, I can get a full repo package and lay it over the existing working folder.
With Claude, I work differently because Claude is more sensitive about usage limits. There, I usually ask for a zip file that contains only the changed files and any new or updated documents. That keeps the work tighter and helps avoid burning through the budget too quickly.
That difference matters.
It’s not just about which AI is smarter. It’s about shaping the workflow around the tool you’re using.
By the end of the conversation, Claude was basically saying that for the way I work, switching to a more agentic coding setup would almost certainly mean moving up to a more expensive plan. And the funny part was that Claude also recognized I might not get much practical benefit from doing that.
Not because agentic coding has no value.
Because I was already getting a lot of the useful parts.
The AI was already helping with specs, plans, code, debugging, documentation, changelogs, and handoffs. The difference was that my workflow was guided instead of exploratory.
I wasn’t asking the AI to wander through the repo and figure out what kind of work it needed to do.
I was giving it a defined job.
That turns out to matter a lot.
The label was less important than the work
I’m not against agentic coding.
For some teams and some tasks, it makes a lot of sense.
If you want an AI to fan out across a repo, run tests, make repeated passes, and handle a larger amount of mechanical execution, agents can be useful.
But that conversation reminded me that labels can blur what’s really happening.
A session-based workflow can be sloppy.
An agentic workflow can be sloppy.
A session-based workflow can be disciplined.
An agentic workflow can be disciplined.
The real difference is not the name.
The real difference is whether the AI has the right context, the right boundaries, the right task, and the right level of authority.
If it does, it can help a lot.
If it doesn’t, giving it more autonomy may just let it make a bigger mess faster.
The useful part was already there
What I took from that conversation was not, “Agents are bad.”
That’s too simple.
What I took from it was this:
I had already let the AI take over many of the parts of programming that programmers usually hate doing.
The planning.
The cleanup.
The handoff writing.
The changelog maintenance.
The session summaries.
The comparison between what we meant to do and what we actually did.
The reminders about what the next session needs to know.
And yes, the coding too.
That’s the important part.
The AI wasn’t just standing beside the work making notes about the work. It was doing real implementation work inside a structure that kept me in control of the result.
That’s the stuff that keeps real work moving.
It’s also the stuff that’s easy to neglect because it doesn’t always feel like coding.
But when that work is neglected, the coding gets worse.
The project loses memory.
The next session starts fuzzy.
The same mistakes repeat.
The AI begins guessing from old summaries instead of reading the current state.
The human starts carrying too much in their head.
That’s exactly the kind of drag AI can reduce.
Letting AI do the work it can do
That conversation with Claude helped clarify something for me.
I don’t need AI to be magic.
I don’t need it to replace my judgment.
I don’t need it to own the project.
But I do want it carrying as much of the right work as possible.
If AI can turn rough thoughts into a working spec, let it.
If it can turn the spec into an implementation plan, let it.
If it can write the first pass of the code, let it.
If it can find the bug it introduced, let it.
If it can explain what changed, let it.
If it can keep the changelog honest, let it.
If it can summarize the session so the next thread starts cleanly, let it.
If it can maintain the boring documents that keep a project from losing its shape, let it.
That’s not giving up control.
That’s using the tool.
The funny part
The funny part is that Claude did make a good case for agentic coding.
It just also made a good case that I had already built a lot of the important habits into my existing workflow.
By the end, the conversation had gone from:
You should consider agents because they can do all these useful things.
To something closer to:
Actually, you’re already having the AI do most of those useful things. The agent might mostly save you a little mechanical handling, but it would probably cost more.
That’s still worth knowing.
But it’s a very different conclusion.
It also gave me a better way to think about the larger issue.
The goal is not to use the trendiest AI workflow.
The goal is to get the most useful work out of AI at the quality level, control level, and cost level that makes sense.
For me, that means a disciplined session-based workflow still has a lot going for it. It lets the AI write code, inspect code, debug code, maintain documents, prepare handoffs, and keep the work moving without handing over more autonomy than the task actually needs.
That was the real lesson.
Not session-based good, agentic bad.
More like this:
Use enough AI to carry the work.
Use enough structure to keep the work yours.
Related guide
For the broader lesson behind this field note, see Let the Big Dog Run.
-- Charles