AI Coding Can Cost More Than a Human Engineer — Especially When Used Incorrectly

AI is only as effective as the person directing it

Give five people the same AI coding agent and you won’t get five equal results. I use these tools every day, on my own products and on client work, and the difference between users is bigger than the difference between tools.

AI coding tools multiply the skill of the person using them. An engineer who knows what to build, and how to check it, gets faster. Someone who can’t judge the output gets more output to judge, and more ways to go in circles.

• A junior developer gets working code quickly, but often can’t tell whether it’s good. So they ask the AI to check its own work, and then to check the check.
• An experienced engineer already knows what done looks like. They use the AI to draft, then compare the draft with what they know about the system, the users and the failure cases.
• A nontechnical user can get an impressive demo running in an afternoon. What they usually can’t see is the missing security check, the data that will be lost on the next deploy, or the hosting bill that arrives later.

AI doesn’t care which kind of decision it is executing. A good decision gets done sooner. A bad decision also gets done sooner, and now there is code to undo as well.

The junior developer and the login loop

Picture a junior developer asked to add login to a web app: sign up, sign in, and password reset. This is an illustration, but anyone who has led a team will recognize it.

They ask the AI agent to build it, and it does. They don’t fully follow the code, so they ask it to explain. Then they ask it to review the code. The review suggests changes, so they ask it to apply them. They run the tests, three fail, and they ask it to fix them. The fix breaks the password reset. They ask for a rewrite “using a cleaner approach,” then ask for another review of the rewrite. By the end of the week the feature mostly works, and nobody, including the developer, is sure why.

That loop is expensive because an AI coding agent rereads the conversation on every request. A long session that keeps asking for explanations, reviews and rewrites sends the same large context to the model again and again, so token usage grows with every lap. The bigger cost is the days spent, and the senior time needed to untangle the result.

Login is also a bad place to learn by trial and error. It touches passwords, sessions and account recovery, which are exactly where a plausible-looking mistake becomes a security problem.

I want junior developers using AI. I learned SIP from packet captures and a lot of trial and error, and today’s junior developers have a tutor that never gets tired of questions. What needs to change is how the work is set up:

• Mentorship. A senior engineer sets the task up and reviews it with them, not after them.
• Smaller tasks. “Add the password reset email” instead of “add login.”
• Clear acceptance criteria. Written before the first prompt, so there is something to check the output against.
• Learning separate from building. Ask the AI to teach how sessions and tokens work in a scratch session, on a small model. Then build the feature in a short, focused session.

I wrote more about why I enjoy this part of the job in why I enjoy mentoring. AI doesn’t replace that work. It makes it more important, because the junior developer can now produce code faster than they can learn from it.

A developer running the marketing

Now picture a capable software developer who has built a side product and wants customers. They ask the AI for a marketing plan. Then they ask it to rewrite the messaging, improve the SEO, and redesign the landing page. A week later they decide the target audience is wrong, so they ask for a new audience, new messaging and a reworked website.

Every answer looks reasonable, and that is what keeps the loop going. Without marketing experience, the developer has no way to judge which version is better, so the only move left is to ask again. The AI won’t say, “Stop rewriting the page and go talk to ten customers.” It answers the question it was given.

When people use AI outside their own expertise, most of the cost comes from rework. Missing domain knowledge removes the stopping rule: if you can’t tell a good answer from a weak one, you keep asking, and every round changes things without moving them forward.

I learned that side of the business the slow way, first running marketing at my family’s restaurant and later as CTO of a media publishing company where organic search was how the business grew. What publishing taught me about SEO is that you decide who the page is for before you write it, and you change one thing at a time so you can tell what worked. AI makes the writing faster. It doesn’t make that decision for you.

If you are outside your field, an hour with someone who knows it will usually save more than another week of prompts.

The hidden cost of endless AI reviews

Ask an AI agent to review code and it will find something. Another test. A refactor. A helper function. An edge case that can’t happen in your system. Apply the suggestions, ask again, and you’ll get a new list. It never runs out, because “could this be better?” always has an answer.

More AI reviews don’t always mean better software. Each round costs tokens and time, and the suggestions often add code that someone has to maintain. Software is good enough when it meets the written acceptance criteria, the risky paths are tested, a person who owns it has read it, and the next suggestion wouldn’t change anything for the user.

That last test matters most. Complexity should earn its place, and I’ve written about what that complexity costs to run. A layer the AI suggested still has to be run and maintained by someone on the team.

The real economics of AI coding

There are two ways to pay for AI coding tools, and they hide waste in different places.

Subscription plans charge a flat monthly price with usage limits. API billing charges for every token the model reads and writes. On a subscription, wasted loops show up as hitting your limit and waiting, or paying for extra usage. On the API, they show up on the bill.

• Subscriptions. Claude’s Pro plan is $20 a month billed monthly, Max starts at $100 a month, and Team seats start at $25 a month billed monthly. All of them include Claude Code. Usage resets on a rolling five-hour window, paid plans also have weekly limits, and Claude Code shares that allowance with chat. When you run out, you wait, upgrade, or buy usage credits at API rates. (From claude.com/pricing.)
• API billing. You pay per million tokens, with separate prices for input, output and cached input. Output costs about five times as much as input on the models below. Thinking counts as output.

Anthropic publishes a useful reference point. Across enterprise deployments of Claude Code, the average cost is around $13 per developer per active day and $150 to $250 per developer per month, and 90% of users stay below $30 per active day (Claude Code cost documentation).

For most teams that is less than a day of an engineer’s time each month. So the token bill usually isn’t the biggest cost. The biggest cost is the people time a bad loop burns, and the senior time it pulls in to clean up.

To make that concrete, here is a hypothetical comparison for one login feature, measured as cost per accepted change: everything spent until a change is merged and stays merged.

The assumptions behind it, all illustrative:

• Hourly cost. $120 an hour, fully loaded, for an experienced engineer and $70 for a junior developer. Use your own numbers.
• Without AI. 16 hours to build, an hour of review, two hours of fixes.
• Junior with AI. 24 hours across a week of loops, about 1,100 model requests carrying long conversations, one rejected attempt, six hours of senior review and rescue, then six hours of rework. That comes to roughly 311 million tokens, mostly the same conversation read again from cache.
• Experienced with AI. Six hours, about 150 focused requests, one hour of review, half an hour of fixes.
• Prices. Claude Opus 5.5 list rates from the table above, with a share of requests missing the cache after breaks.

Under those assumptions the junior developer with AI costs about $3,125, more than the experienced engineer working without AI. The AI tokens are only about 10% of that. The experienced engineer with AI comes in around $924. Change the assumptions and the numbers move, but in most versions I can construct, the hours cost far more than the tokens.

These are hypothetical numbers. In a future article I want to run the real experiment: give the same task to a junior engineer and an experienced engineer, both using AI, and compare total tokens, retries, human time and code quality.

AI makes engineering judgment more valuable

The most expensive code is code that works and solves the wrong problem. AI makes that code faster to write, so the person who can stop it before it is written matters more.

Experienced engineers save money with AI mostly by what they don’t ask it to build. They notice an unclear requirement, unneeded complexity, or the wrong architecture before the agent spends hours implementing it.

In the login example, an experienced engineer would ask questions before any code exists. Do we need to build login ourselves, or should we use the identity provider we already pay for? Does password reset by text message need a messaging vendor we don’t have yet? Does this need to be its own service, or a module in the app we already run? Each of those answers can remove days of work. No amount of prompting finds them if nobody asks.

The same judgment shows up after the code is written. An experienced engineer can read an AI’s confident explanation and see that it’s wrong, mostly because they have been wrong in production before. It is also why I care about not building work nobody needed.

Recommendations for engineering leaders

Giving everyone an AI agent is easy. Getting value from it takes the same management habits as any other engineering spend.

• Set AI usage budgets. A monthly budget per team, reviewed like any other cost. The point is to notice unusual spend, not to punish people for using the tools.
• Monitor tokens and runs. Claude Code shows session usage with /usage, and API organizations get usage reports and per-user analytics. Look at which tasks consume the most, and why.
• Set retry limits. If the agent hasn’t solved it after the third attempt, stop and bring in a person. A fourth attempt with the same context rarely does better.
• Pick the model for the job. A smaller, cheaper model handles most routine coding. Save the largest model for hard design and reasoning, and use the smallest for simple subtasks.
• Keep tasks small. Smaller user stories and pull requests help AI for the same reasons they help people: less context, clearer checks, easier review.
• Write acceptance criteria first. If you can’t say what done looks like, the agent can’t either.
• Keep people accountable for what ships. Someone who understands the code reads it, especially around login, payments and anything that deletes data.
• Pair AI with mentorship. Have senior engineers look at how juniors use the tools, not only at what they merge.
• Measure cost per accepted change. People hours plus tokens plus review plus rework, divided by changes that were merged and stayed merged. Lines of code and prompt counts don’t tell you much.

Start fresh sessions between unrelated tasks, too. Old context carried into a new task is sent again with every request, and you pay for it each time.

AI literacy vs. domain expertise

Knowing how to run Claude Code, Codex or another agent is a real skill, and it is mostly a skill of steering. Deciding where to go takes knowledge of the field.

Being good at operating AI coding agents doesn’t make someone a software architect, a marketing strategist or a product leader. AI literacy is knowing how to get output from the tool. Domain expertise is knowing whether the output is right, and what to ask for in the first place.

Strong teams need both, and they don’t need everyone to have all of it. A good team knows who has the expertise and brings them in early, which is what good teams do with knowledge in general. With AI in the loop, skipping that step costs more, because the wrong work gets built faster.

Short answers