A lot of programmers underuse AI because they’re afraid of the wrong thing.
They know AI can make mistakes.
They know it can guess.
They know it can drift away from the existing design, patch the wrong layer, or confidently explain something it hasn’t actually inspected.
All of that is true.
But there’s another mistake sitting on the other side of the road.
You can become so focused on what AI might do wrong that you stop letting it do what it’s genuinely good at.
That’s a waste.
At some point, if you’re going to use AI seriously, you have to let the big dog run.
AI is not just a code generator
One of the most common traps in AI-assisted programming is thinking the main value is code output.
Can it write this function?
Can it fix this bug?
Can it generate this component?
Can it convert this file?
Those are useful questions, but they’re too small.
AI can help write code, but some of its best work happens before and after the code.
It can help turn a rough idea into a written specification.
It can help break that specification into smaller implementation steps.
It can help identify open questions before work starts.
It can help maintain a changelog that says what actually changed instead of what everyone vaguely remembers changing.
It can help summarize a long work session into a clean handoff.
It can help compare what you planned to do against what you actually did.
It can help keep the boring connective tissue of a project from falling apart.
That kind of work matters.
Programmers often hate it.
AI doesn’t.
Yes, let it write code
That said, AI can absolutely write code.
That’s part of the point.
Sometimes people talk about AI-assisted programming as if the mature position is to keep AI away from the code and only use it for planning, notes, or documentation.
I don’t think that’s right.
AI can be extremely useful as a coding partner. It can draft an implementation faster than I can type it. It can look across files, spot a pattern, produce a first pass, revise that pass, and explain what it changed.
It can also help debug its own mistakes.
That matters.
If the AI writes something that doesn’t work, the answer isn’t always to throw the whole thing away. Often the answer is to make it inspect the actual code, compare the failure against the intended behavior, and identify where the mistake happened.
A good AI coding session can move very fast because the AI is something like a junior developer who knows the entire internet and can type 3,000 words a minute.
I can’t do that.
But I can supervise it.
I can tell it what problem we’re solving. I can make it read the right files. I can make it respect the architecture. I can stop it when it starts guessing. I can test the result. I can decide whether the code belongs.
That’s the deal.
The AI can write the code.
The human still owns the work.
The boring work is not optional
Most real software projects don’t fail because nobody could write the clever function.
They fail because the work gets muddy.
The goal changes, but nobody writes it down.
The implementation plan exists only in someone’s head.
The reason for a design decision is buried in a chat thread.
The changelog says “fixed bugs” when what actually happened was a storage rule changed, a UI path moved, and a shared helper got new behavior.
The next session starts, and now everyone has to reconstruct the state of the project from memory.
That’s where AI can be extremely useful.
Not glamorous.
Useful.
It can be the thing that keeps the project from losing its own thread.
A human developer may look at a messy half-page of notes and think, “I’ll clean that up later.”
AI can clean it up now.
A human developer may know the spec should be clarified before implementation starts, but want to get straight to the fun part.
AI can slow the work down just enough to ask, “What are we actually building?”
A human developer may finish a long session and be too tired to write a decent handoff.
AI can produce the handoff while the details are still warm.
That’s not fake productivity.
That’s project hygiene.
And project hygiene is one of the places AI shines.
Let AI carry weight, not judgment
The important distinction is this:
Don’t ask AI to own the judgment.
Ask it to carry the weight.
That means you still decide what matters.
You still decide what the product is supposed to become.
You still decide what standards the work has to meet.
You still decide whether a change belongs in the product, the framework, the data layer, the user interface, or nowhere at all.
But once those decisions are clear, AI can do a lot of the carrying.
It can draft the spec.
It can write the code.
It can debug the code.
It can explain the code.
It can turn the spec into a task list.
It can produce a test checklist.
It can summarize the implementation.
It can write the first pass of the release notes.
It can keep the change history honest.
It can create the next-session handoff.
It can take raw thinking and turn it into something another developer, another AI session, or your future self can actually use.
That is real work.
It just isn’t always the kind of work programmers like to admit is real work.
Give it room inside the fence
Letting the big dog run doesn’t mean opening the gate and hoping for the best.
It means building the fence first.
That fence might include:
- the project goals
- the coding standards
- the architectural boundaries
- the files or folders that matter
- the parts of the system that must not be changed
- the difference between product code and shared framework code
- the required testing path
- the expected output format
- the level of authority the AI actually has
Once those boundaries are clear, don’t keep the AI trapped doing tiny chores.
Let it help.
Let it write useful code.
Let it organize the work.
Let it find the gaps.
Let it prepare the boring documents.
Let it write the first draft of the things you were going to postpone.
Let it maintain the forward motion that usually gets lost between sessions.
The boundary is not there to weaken the AI.
The boundary is what makes it safe to use the AI more aggressively.
Programmers often guard the wrong work
A lot of developers are protective of the coding itself.
That makes sense. Code is the product. Code is where mistakes become expensive.
But then those same developers will casually skip the planning, the handoff, the change record, the test notes, the release summary, and the documentation updates.
That’s backwards.
If you’re going to supervise the code carefully, you should also care about the work that keeps the code understandable.
AI is especially good at helping with that surrounding work because it can hold a lot of context, reorganize messy material, and produce structured output quickly.
It doesn’t get offended if you ask it to rewrite the same plan three different ways.
It doesn’t resent being asked to compare two versions of a spec.
It doesn’t mind turning a rough conversation into a clean checklist.
It doesn’t complain that changelogs are boring.
That matters because boring work is where software discipline often leaks away.
AI can plug that leak.
Cost is part of the workflow
There’s another practical issue people don’t talk about enough.
Cost.
A workflow that looks impressive in a demo may not make sense if it requires a much more expensive plan, burns through usage limits, or spends a lot of time wandering through the repo just to rediscover what a well-written handoff could have told it in thirty seconds.
That doesn’t mean agentic workflows are bad.
It means workflow efficiency matters.
If the AI has to explore everything from scratch every time, that costs tokens, time, and money. If the work is guided by good project documents, clear constraints, and focused task instructions, the AI can often do more useful work with less waste.
That’s one of the reasons I like disciplined session-based work.
The AI is not sent into the project with a vague instruction to go figure things out. It starts with the relevant documents. It knows the task. It knows the boundaries. It knows what kind of output I need.
That kind of structure doesn’t just improve quality.
It can make the whole workflow cheaper.
This is not about agent worship
A lot of AI coding discussion right now turns into arguments about agents.
Should the AI run the repo?
Should it run the tests?
Should it create documents?
Should it plan the work?
Should it inspect the code?
Should it write reports?
Those are fair questions, but the label can become a distraction.
The real question is not whether your workflow is called agentic.
The real question is whether the AI is actually carrying useful work.
If your AI workflow already has the assistant reading the project documents, inspecting the code, writing useful code, debugging failures, maintaining the plan, writing the handoff, tracking what changed, and helping prepare the next session, then you may already be getting many of the practical benefits people associate with agents.
Maybe an agentic tool would automate more of that.
Maybe it would run more steps without your direct involvement.
Maybe it would save you a little mechanical work.
But the value is not in the label.
The value is in the structure.
A sloppy agentic workflow can still make a mess.
A disciplined session-based workflow can still get serious work done.
What matters is whether the AI has the right assignment, the right context, the right boundaries, and enough room to be useful.
The work AI is good at
Here are some jobs I’m happy to give AI.
Turn this rough idea into a spec.
Find the missing questions in this spec.
Break this feature into implementation steps.
Tell me which parts look risky.
Write the first implementation pass.
Inspect this failure and tell me where the mistake happened.
Compare this code against the existing pattern.
Explain what changed and why.
Summarize this work session for the next thread.
Compare this implementation against the original plan.
Write a changelog entry based on what actually changed.
Draft the release notes.
Turn these scattered notes into a clean project document.
Read this handoff and tell me what the next AI session needs to know.
That kind of work is not a consolation prize.
It’s some of the highest-value work AI can do because it keeps human judgment from getting buried under project noise.
The programmer still owns the decisions.
The AI carries more of the load.
That’s the deal.
Don’t make AI smaller than it needs to be
There’s a version of AI caution that is healthy.
Make it read the code.
Make it show its receipts.
Make it respect the architecture.
Make it stay inside the boundaries.
Make it stop when it starts guessing.
Those rules matter.
But there’s also a version of caution that becomes fear.
That version says:
AI might make a mistake, so only let it do tiny things.
AI might misunderstand, so don’t let it help shape the work.
AI might drift, so don’t let it touch anything important.
That sounds safe, but it leaves a lot of value on the table.
The better answer is not to make AI small.
The better answer is to make the assignment clear.
If the work needs judgment, you keep judgment.
If the work needs structure, cleanup, comparison, summarization, translation, organization, debugging, code drafting, or a first pass, let AI help.
That’s what it’s good at.
The practical rule
Here’s the rule I use:
Give AI power where it is strong, and give it boundaries where it is risky.
That means I don’t want AI casually redesigning a product architecture it hasn’t inspected.
But I absolutely want AI helping me maintain the documents that describe that architecture.
I don’t want AI making final release decisions for me.
But I absolutely want AI helping me summarize what changed, what still needs testing, and what should be carried into the next session.
I don’t want AI replacing developer judgment.
But I absolutely want it reducing the drag around that judgment.
That’s the balance.
Don’t hand AI the steering wheel and climb into the back seat.
But don’t make it sit quietly in the corner either.
Give it the right job.
Give it the rules.
Then let the big dog run.
Related field note
For the lived version of this lesson, see The Day Claude Tried to Sell Me My Own Workflow.
-- Charles