The unbearable slowness of AI coding

2025-08-2118:39137102joshuavaldez.com

I’ve been coding entirely with Claude Code for the past two months. At first it was exhilarating. I was speeding through tasks. I was committing like mad. ...

Show article

19 Aug, 2025

I’ve been coding entirely with Claude Code for the past two months. At first it was exhilarating. I was speeding through tasks. I was committing like mad.

Now, as I’ve built up a fairly substantial app, it’s slowed to a crawl. Ironically, the app I’m building lets me parallelize many instances of Claude Code at once.

Often, I’ll have 5 instances running while I’m thinking about new features.

The slowness comes in when I actually need to review all the PRs. One by one, I have to apply them locally. One by one, I have to step through the console logs. One by one, I have to tell Claude to fix the issues it created.

Yes, it’s faster. I’m committing an incredible amount of code these days—more than I ever have.

It also feels incredibly, maddeningly slow. Once you’ve felt that first boost of speed with Claude Code, you want every coding task to feel like that. It’s addicting.

Instead, as you build, you still have to serve as Claude’s QA engineer.

Maybe one day we’ll solve that. But I’m skeptical it will be in the form of a CLAUDE.md. I can barely get Claude to consistently follow the bare set of rules I have, much less ensure it performs a complex integration test for a web app.

Until then, I’ll keep pulling PRs locally, adding more git hooks to enforce code quality, and zooming through coding tasks—only to realize ChatGPT and Claude hallucinated library features and I now have to rip out Clerk and implement GitHub OAuth from scratch.

Read the original article

Comments

By stillpointlab 2025-08-2120:116 reply

I'm still calibrating myself on the size of task that I can get Claude Code to do before I have to intervene.

I call this problem the "goldilocks" problem. The task has to be large enough that it outweighs the time necessary to write out a sufficiently detailed specification AND to review and fix the output. It has to be small enough that Claude doesn't get overwhelmed.

The issue with this is, writing a "sufficiently detailed specification" is task dependent. Sometimes a single sentence is enough, other times a paragraph or two, sometimes a couple of pages is necessary. And the "review and fix" phase again is totally dependent and completely unknown. I can usually estimate the spec time but the review and fix phase is a dice roll dependent on the output of the agent.

And the "overwhelming" metric is again not clear. Sometimes Claude Code can crush significant tasks in one shot. Other times it can get stuck or lost. I haven't fully developed an intuition for this yet, how to differentiate these.

What I can say, this is an entirely new skill. It isn't like architecting large systems for human development. It isn't like programming. It is its own thing.

By scuff3d 2025-08-2122:26

This is why I'm still dubious about the overall productivity increase we'll see from AI once all the dust settles.

I think it's undeniable that in narrow well controlled use cases the AI does give you a bump. Once you move beyond that though the time you have to spend on cleanup starts to seriously eat into any efficiency gains.

And if you're in a domain you know very little about, I think any use case beyond helping you learn a little quicker is a net negative.

By jmvldz 2025-08-2120:39

"It isn't like programming. It is its own thing."

You articulated what I was wrestling with in the post perfectly.

By bdangubic 2025-08-2121:041 reply

It isn't like programming. It is its own thing.

Absolutely. And what I find fascinating that this experience is highly personal. I read probably 876 different “How I code with LLMs” and I can honestly say not a single thing I read and tried (and I tried A LOT) “worked” for me…

By rootnod3 2025-08-222:072 reply

According to most enthusiasts of LLM/agentic coding you are just doing it wrong then.

By bdangubic 2025-08-2210:301 reply

not sure this is really true/fair, I think what LLM/agentic code enthusiasts will say is that they have found their way to be effective with it while naysayers will fight the "this is sh*t" battle until they are eventually out of the workforce.

By rootnod3 2025-08-2216:271 reply

So, why do you only opt for that side of the argument? Why not indulge in the side of the naysayers will be able to keep a job after the bubble bursts because they still know how to code by hand? And that exact sentiment is what I was alluding to.

There is maybe some truth to the LLM vibe coding and there maybe is some truth to the “old guard” saying “this is shit”, because this might be shit for very good reasons.

By bdangubic 2025-08-2220:29

I’ve been doing this sht for 30 years and one thing I can tell you I learned - when you see something as “groundbreaking” (controversial?) as llms and see many people telling you how much more productive they are with it there are almost always two camps:

- those fighting HARD to tell you at the top of their lungs “oh this is sht, I tried it and it is baaaad

- those going “hmmm let me see how I can learn etc to get to the point where I am also a lot more productive, if ____ and ____ can learn it so can I…”

You always want to be in the second camp…

By rootnod3 2025-08-2216:391 reply

I seem to have forgotten the golden rule to never speak out against LLMs, yet you be subjected to instant downvotes. I don't mind the downvotes, but bring some counterpoints to the discussion and make it worth the platform.

EDIT: typo

By bdangubic 2025-08-2222:50

one of the likely reasons you are getting downvoted is that you made a snarky remark. (unsolicited) word of advice - you should always listen to the enthusiasts (if you are not one of them), they have figured something out before you did (nothing wrong with that, many people are much smarter than you and I)...

By kace91 2025-08-2120:49

>I haven't fully developed an intuition for this yet, how to differentiate these.

The big issue is that, even though there is a logical side to it, part is adapting to a close system that can change under your feet. New model, new prompt, there goes your practice.

By rcarr 2025-08-2122:141 reply

For the longer ones, are you using AI to help you write the specs?

By stillpointlab 2025-08-2123:08

My experience is: AI written prompts are overly long and overly specific. I prefer to write the instructions myself and then direct the LLM to ask clarifying questions or provide an implementation plan. Depending on the size of change I go 1-3 rounds of clarifications until Claude indicates it is ready and provides a plan that I can review.

I do this in a task_descrtiption.md file and I include the clarifications in its own section (the files follow a task.template.md format).

By JeremyNT 2025-08-2219:17

> What I can say, this is an entirely new skill. It isn't like architecting large systems for human development. It isn't like programming. It is its own thing.

It's management!

I find myself asking very similar questions to you: how much detail is too much? How likely is this to succeed without my assistance? If it does succeed, will I need to refactor? Am I wasting my time delegating or should I just do it?

It's almost identical to when I delegate a task to a junior... only the feedback cycle of "did I guess correctly here" is a lot faster... and unlike a junior, the AI will never get better from the experience.

By tarruda 2025-08-2120:314 reply

This illustrates a fundamental truth of maintaining software with LLMs: While programmers can use LLMs to produce huge amounts of code in a short time, they still need to read and understand it. It is simply not possible to delegate understanding a huge codebase to an AI, at least not yet.

In my experience, the real "pain" of programming lies in forcing yourself to absorb a flood of information and connecting the dots. Writing code is, in many ways, like taking a walk: you engage in a cognitively light activity that lets ideas shuffle, settle, and mature in the background.

When LLMs write all the code for you, you lose that essential mental rest. The quiet moments where you internalize concepts, spot hidden bugs, and develop a mental map of the system.

By danbmil99 2025-08-2123:38

Has anyone else had the experience of dreading a session with Claude, because his personality is often chirpy and annoying; he's always got positive things to say; and working with him as the main code author actually takes away one of the joys of being a programmer -- the ability to interact with a system that is _not_ like people -- it is rigid and deterministic, not all soft and mushy like human beings.

When I write piece of code that is elegant, efficient, and -- "right" -- I get a dopamine rush, like I finished a difficult crossword puzzle. Seems like that joy is going to go away, replaced by something more akin to developing a good relatioship with a slightly quirky colleague who happens to be real good (and fast) at some things -- especially things management likes, like N LOC per week -- but this colleague sucks up to everyone, always thinks they have the right answer, often seems to understand things on a superficial level, and oh -- works for $200 / month...

Shades of outsourcing to other continents...

By qudat 2025-08-2122:271 reply

As a staff swe I spend way more time reading, understanding code, and then QAing features.

Writing code is my favorite part of the job, why would I outsource it so I can spend even more time reading and QAing?

By h3lp 2025-08-2219:31

That's a great insight---the problem with LLMs is that they write code and elegant prose for us, so we have more time to do chores. I want it the other way around!!!

By jmvldz 2025-08-2120:412 reply

100% yes. QA'ing a bunch of LLM generated code feels like a mental flood. Losing that mental rest is a great way to put it.

By CuriouslyC 2025-08-2121:162 reply

MCP up Playwright, have a detailed spec, and tell claude to generate a detailed test plan for every story in the spec, then keep iterating on a test -> fix -> ... loop until every single component has been fully tested. If you get claude to write all the components (usually by subfolder) out to todos, there's a good chance it'll go >1 hour before it tries to stop, and if you have an anti-stopping hook it can go quite a bit longer.

By samrus 2025-08-2122:371 reply

Youve got to be doing the most unoriginal work on the planet if this doesnt produce a bowl of disfunctional spaghetti

By CuriouslyC 2025-08-2122:561 reply

Every sentence you will ever write in your entire life will be made from a finite set of letters. The magic is in how you arrange them.

If you have a really detailed, well thought out spec, you do TDD and you have regular code review and refactor loops, agentic coding stays manageable.

By cruffle_duffle 2025-08-2123:481 reply

It takes an incredibly detailed spec to get an LLM to not go completely off the rails and even then. The amount of time writing that spec can take more time than just doing it by hand.

There is way too much babysitting with these things.

I’m sure somehow somebody makes it work but I’m incredibly skeptical that you can let an LLM run unsupervised and only review its output as a PR.

By andrekandre 2025-08-233:11

  > The amount of time writing that spec can take more time than just doing it by hand.

one thing about doing it by hand is you also notice holes/deficiencies in the spec and can go back and update it, make the product better, but just throwing it to an llm 'til its perfect-to-spec probably means its just going to be average quality at best...

tho tbh most software isn't really 'stunning' imo so maybe thats fine as far as most businesses are concerned... (sad face)

By cpursley 2025-08-2122:421 reply

Can you elaborate on what you mean by anti stopping hook? Sometime I take breaks, go on walks, etc and it would be cool of Claude tried different things and even branches etc that I could review when back.

By CuriouslyC 2025-08-2123:20

Basically, all LLMs are "lazy" to some degree and are looking for ways to terminate responses early to conform to their training distribution. As a result, sometimes an agent will want to stop and phone home even if you have multiple rows of all caps saying DO NOT STOP UNTIL YOUR ENTIRE TODO LIST IS COMPLETE (seriously). Claude code has a hook for when the main agent and subagents try to stop, and you can reject their stop attempt with a message. They can still override that message and stop but the change of turn and the fresh "DO NOT STOP ..." that's at the front of context seem to keep it revving for a long time.

By rstuart4133 2025-08-2122:51

Another way of saying thing is only an AI reviewer could cope with the flood of code an AI can produce.

But AI reviewers can do little beyond checking coding standards.

By imiric 2025-08-2122:44

Programming and vibe coding are two entirely separate disciplines. The process of producing software, and the end result, is wildly different between them.

People who vibe code don't care about the code, but about producing something that delivers value, whatever that may be. Code is just an intermediate artifact to achieve that goal. ML tools are great for this.

People who program care about the code. They want to understand how it works, what it does, in addition to whether it achieves what they need. They may also care about its quality, efficiency, maintainability, and other criteria. ML tools can be helpful for programming, but they're not a panacea. There is no shortcut for building robust, high quality software. A human still needs to understand whatever the tool produces, and ensure that it meets their quality criteria. Maybe this will change, and future generations of this tech will produce high quality software without hand-holding, but frankly, I wouldn't bet on the current approaches to get us there.

By doctoboggan 2025-08-2119:48

When building a project from scratch using AI, it can be tempting to give in to the vibe and ignore the structure/architecture and let it evolve naturally. This is a bad idea when humans do it, and it's also a bad idea when LLM agents do it. You have to be considering architecture, dataflow, etc from the beginning, and always stay on top of it without letting it drift.

I have tried READMEs scattered through the codebase but I still have trouble keeping the agent aware of the overall architecture we built.

Hacker News