Who is Doing the Reps? Staying Fit in an AI-Assisted Workflow

I have been using AI tools a lot.

Not in a casual, once-in-a-while, “look what the robot did” sort of way.

I mean they are actually part of my daily workflow now.

They help me write. They help me plan. They help me inspect code. They help me get back into projects faster after the daily parent-work interruptions: snacks, missing shoes, and the sacred duty of standing near a child while they complete a task they absolutely do not need help with.

AI is in the workflow now, and that is the useful part.

It is also the part that makes me nervous.

Because the question is not just whether AI can do the work. The question is who is still doing the reps.

The Suspiciously Cheap Miracle

A lot of the AI tools I use right now feel too good for what they cost.

That does not mean they are free. I am paying for some of them. I use paid plans. I use APIs. I am not standing outside the data center with a burlap sack trying to steal tokens through the fence.

But it still feels like a lot of this is subsidized. Because it is.

The tools are powerful, the prices are still relatively approachable, and every company involved seems to be sprinting through the same land grab while pretending this is all very normal and sustainable. That creates a strange working environment, one where I can build real habits around tools that may not be priced anywhere near their long-term cost.

That’s the part that makes me uneasy. And it’s not because I think AI is just a passing fad. It’s here, and it’s not going back in the box. I have no desire to be the guy hand-stitching buggy whips in the corner while everyone else drives away in cars. I like technology too much to reject it on principle, and honestly, I’d get bored halfway through defending the purity of the whip.

The concern is different.

The concern is that I build my productivity around these tools while they are still in the magical introductory pricing phase, and then one day the real bill arrives.

By then, the workflow is normal. The speed is normal. The output is normal. The expectation is normal.

And I am the one left figuring out how to keep producing at that level after the subsidy fog clears.

That is not a comfortable dependency.

I Am Trying Not to Become Weird About It

The obvious answer would be to stop using the tools so much.

That is also, for me, the wrong answer.

I am not interested in pretending the old way was better just because it was harder, slower, and involved enough open tabs to qualify as a cry for help.

The old way had plenty of problems. Some of those problems were just accepted because we did not have better options yet.

AI is very good at some things I genuinely dislike doing. It is also very good at some things I like doing, which is where this gets more complicated.

So instead of trying to remove AI from my workflow, I have been trying to make the workflow less dependent on one very specific version of AI: the heavily subsidized, extremely capable, flagship model doing everything for me while I sit there feeling productive and slightly suspicious.

I am not trying to replace the whole workflow in one heroic motion. I am just trying to stop pretending the buffet has no bill.

The two things I keep coming back to are pretty simple:

• Use APIs more, where the cost is closer to actual usage.
• Use local and open-weight models more, where I can run the thing myself and see what is actually possible outside the giant hosted magic box.

Neither one is a complete replacement, and that is fine.

The point is not to become an AI monk, living off-grid with a ThinkPad and a pile of data I’ve stored and indexed myself. The point is to understand which parts of my workflow actually need the expensive magic, and which parts have just been lazily wandering over there because the door was open and the snacks were free.

The Flagship Model Problem

The most uncomfortable part is that the flagship models are really good.

That sounds obvious, but it matters.

When I lean into models like Fable or GPT-5.5, they can absorb an alarming amount of the process. If I prompt them well, they can inspect a codebase, understand how things are set up, propose a plan, write the code, adjust the tests, run through the failure cases, and help audit the result.

That is not a small helper. That is a forklift.

There are still important things for me to do as a developer. I have to understand what I am building. I have to know whether the direction makes sense. I have to decide which tradeoffs are acceptable. I have to catch the places where the model is confidently marching toward a cliff with a backpack full of abstractions.

I have not been replaced yet, but my job title has definitely changed. It feels less like I am the one turning every bolt and more like I am standing beside a tiny mechanical savant with a clipboard, a laser pointer, and absolutely no instinct for when the plan has become stupid.

But the raw amount of work these tools can absorb is real. And when you get used to that, going back feels strange.

Not impossible. Just strange, in the way using a hand screwdriver feels strange after you’ve been using a drill. You can still do it. You may even be better at feeling what is happening. But part of your brain is standing nearby asking why we have chosen to make this one screw our whole afternoon.

AI Changes Which Parts of You Do the Reps

This is the part I did not like noticing.

When I switched away from heavy AI-assisted and agent-based development for some tasks, and tried to do more by hand again with smaller models, local models, and open-weight models, I could feel that some of my skills had softened.

Not disappeared. But softened.

The writing-code-by-hand muscle was not getting as much regular use. The small instincts were slower. The “I know exactly where this goes” feeling took longer to show up. Some of the mechanical speed had faded a little.

That is not the fault of the tools, exactly. That is just how skills work. If you stop using a thing, it gets weaker. This is apparently still true even if the thing has syntax highlighting and strong opinions about semicolons.

The more interesting part is that not all of my skills got worse. Some of them got better.

I got better at deciding what I wanted to build. I got better at steering projects. I got better at spotting whether work was going in the right direction. I got better at describing the shape of a problem, breaking it into useful steps, and catching the places where a proposed solution did not match the actual goal.

That makes sense. Those were the skills I was still using every day.

The AI was doing more of the raw implementation, but I was still doing the direction-setting. So the direction-setting muscles got stronger, and the typing-every-line-from-scratch muscles got less exercise.

That feels like the real tradeoff. Not “AI makes you worse.” More like: AI changes which parts of you are doing reps.

And the parts that stop doing reps will eventually complain when asked to lift something.

Writing Code by Hand Still Matters

One of the lessons for me is that I still need to write code by hand.

Not all the time. Not as a moral position. Not because I believe every function should be hand-carved from a single block of locally sourced PHP.

Just enough that the muscles stay alive.

Pick a project. Pick a puzzle. Pick something mildly annoying that can become impossible to ignore in the traditional way. Then solve it without handing the whole thing to an agent.

That might mean a small script. It might mean a toy app. It might mean fixing some weird thing in a personal project. It might mean building something unnecessary enough to be fun, but useful enough that I actually care if it works.

The point is to keep my hands in the work, because I do not want to become someone who can direct the machine but cannot do the work without it. That seems like a bad place to end up, especially if the machine later sends an invoice with enterprise pricing.

And if that hand-written code is headed for production, it still makes sense to run it past an AI for a second look. Security, performance, edge cases, the usual suspects. There is no prize for ignoring tools that can help.

The goal is not to avoid AI. The goal is to avoid becoming helpless without it.

Local Models Are Better Than I Expected

The other thing I have been playing with is local and open-weight models, and they are surprisingly good.

For writing, they can be extremely useful. They help me organize notes, brainstorm ideas, clean up messy thoughts, do rough edits, and pull structure out of a brain dump. All of that works better than I expected.

Sometimes a lot better.

For coding, it depends.

If the task is small and contained, they can be genuinely handy. A single script. A single page. A small bug. A focused function. Something where the relevant context fits comfortably in the prompt without dragging half the codebase in behind it like a moving truck.

For that kind of work, local models can be great.

The trouble starts when the project gets large.

A big codebase is not just a pile of files. It is conventions, history, weird decisions, naming patterns, framework behavior, tests, edge cases, and that one helper class someone wrote in 2019 that now quietly holds the kingdom together.

The flagship models are better when a project has a lot of moving parts. They have bigger context windows, better reasoning, better tool use, and generally more ability to hold the shape of a project in their head.

Local models are improving, but they are not magic. At least not the same kind of magic.

And honestly, that is fine. The lesson was not “local models can replace everything.” The lesson was “local models can replace more than I thought, and the places they cannot replace are worth noticing.”

That is useful information.

The Context-Loading Machine

One of the biggest things AI has changed for me is not even the code writing. It is context loading.

Before AI, a lot of development work had this painful ramp-up period. You would sit down to work on a project, open the editor, stare at the file tree, and begin the sacred ritual of remembering what on earth was happening.

Follow the route, find the controller, find the service, find the view, find the component, find the helper, find the test, remember the naming convention, remember why the naming convention is not followed here, stare into the abyss of the blinking terminal cursor for spiritual reasons.

Then maybe, after two or three hours, the project would finally be back in your head enough to do the actual work.

That was always the hidden cost. And if you got interrupted, which is apparently still legal, the whole thing could collapse. You would come back later and have to reload it again.

AI is very good at reducing that pain.

Even when I do not want it to write the code, I can ask it to help me load the project into my own head:

• Explain the moving parts.
• Show me where this flow starts.
• Tell me what files matter.
• Trace this behavior.
• Point out the likely places this bug could live.
• Summarize the route from form submission to email send.

That sort of thing.

It is not replacing my understanding. It is helping me build the understanding faster. That is a major difference.

It means I can work in smaller chunks. I do not always need a perfect five-hour uninterrupted block to make meaningful progress. I can get back into the project faster, do the work, and then step out without feeling like I wasted the entire session just rebuilding the map.

I used to be able to count on long, uninterrupted stretches of time. Now I have kids, and the schedule has other ideas.

That may be one of the most valuable parts of the whole thing. Not glamorous. Not very sci-fi. Just a very good way to stop losing the first half of the work session to mental boot time.

Where the Expensive Models Still Earn It

I do not think the answer is to avoid the high-end models. That would be silly. Sometimes they are exactly the right tool.

If I need deep codebase understanding, a serious audit, a complex implementation plan, or help with something where a mistake would be expensive, the better model is often worth it.

The trick is using it intentionally. Not every problem needs the forklift.

• Sometimes I need the big model to inspect the whole project and help plan the work.
• Sometimes I need a cheaper API call to explain a few files.
• Sometimes I need a local model to help organize notes.
• Sometimes I need to close the chat window and write the thing myself like a person who remembers where the semicolon key lives.

That mix feels healthier. It also gives me a better sense of the real cost of my workflow.

API usage helps because the meter is visible. Local models help because they remind me what is possible without renting a slice of the giant machine. Hand-written work helps because I stay attached to the craft instead of becoming a project manager for tools.

All three matter.

The Current Plan, Such as It Is

So for now, my rough rule is this:

• Use the powerful models where they actually matter.
• Use APIs when I want a clearer relationship between usage and cost.
• Use local or open-weight models for writing, small coding tasks, exploration, and understanding pieces of a project.
• Keep writing code by hand often enough that I do not end up as a slightly confused project manager for my own work.

That is not a perfect system. It is barely a system. But it is better than doing nothing.

Because the danger is not that AI exists. The danger is not even that I use it a lot.

The danger is that I quietly build my whole working life around a temporary pricing reality, let certain skills weaken, raise the expectations around my output, and then act surprised when the bill becomes real.

That seems avoidable. Or at least more avoidable than pretending I am not already using the tools.

The Bill

AI is not going away. I am not going away from AI either. But I do want to be more honest about what I am depending on.

These tools make me faster. They help me think. They help me write. They help me code. They help me get back into complicated projects without spending half the day loading the whole thing into my head one file at a time.

That is all real.

But they also change me a little. They change which skills I practice. They change where I spend my effort. They change what kind of work feels normal. They change what level of output I start to expect from myself.

That is worth paying attention to, because eventually the real pricing shows up.

Maybe slowly. Maybe all at once. Maybe not as dramatically as the bubble-pop people expect. Maybe just through usage caps, higher tiers, slower models, worse defaults, or the quiet disappearance of the strangely generous thing everyone built their day around.

Either way, I do not want to be surprised.

The bill is still in the mail. I want to hold onto the understanding behind the math before it fades into something I can no longer do on my own.