type safety, integration testing, and thorough readmes are now cheap, I don't know why any developer would not be using them with claude code. even if all the LLM services go under tomorrow you'll still have code that practically autocompletes itself.
The unbearable slowness of AI coding
31–40 of 107 posts
Re: The unbearable slowness of AI coding
#32[deleted]
Re: The unbearable slowness of AI coding
#33Gemini CLI is pretty weak, but the Gemini 2.5 pro is still the best for long contexts. Claude is great but it crumbles as you start to get in the 50-100k range. I find Gemini doesn't start to crack until the 150-200k range. It's too bad the tooling around it is mediocre at best.
Re: The unbearable slowness of AI coding
#34This 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.
Re: The unbearable slowness of AI coding
#35Prompting it better during development can really help here.
I have an emerging workflow orchestrated by Claude Code custom commands and subagents that turns even an informal description of a feature into a full fledged PRD, then an "architect" command researches and produces a well thought out and documented technical design. I can review that design document and then give it to the "planner" command, which breaks it down into Phases and Tasks. Then I have a "developer" command iterate through through and implement the Phases one by one. After each phase it runs a detailed code review using my "review" subagent.
Since I've started using this document-driven, guided workflow I've seen quality of the output noticeably improve.
Re: The unbearable slowness of AI coding
#36I'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…
"It isn't like programming. It is its own thing."
You articulated what I was wrestling with in the post perfectly.
Re: The unbearable slowness of AI coding
#37This 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 dot…
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.
Re: The unbearable slowness of AI coding
#38This should be called the eternal, unbearable slowness of code review, because the author writes that the AI actually churns out code extremely rapidly. The (hopefully capable, attentive, careful) human is the bottleneck here, as it should be
Ooh, that's a good title for another post! And yes, I agree with you.
Initially I would barely read any of the code generated and as my project has grown in size, I have approached the limits of that approach.
Often because Claude Code makes very poor architectural choices.
Re: The unbearable slowness of AI coding
#39Maybe I’ve misunderstood this, so correct me if I’m wrong… do actual professional developers let enough code be generated to include entire libraries that handle things as important as authentication , and then build on top of it without making sure the previously generated code actually does what it’s supposed to? Just accept local PRs written by AI, with a very sternly worded “now you better not make any bullshit”…
The mistake you’re making is assuming it’s the same group of people saying both things. The “strictly typed, no GC, optimize everything” crowd hasn’t suddenly turned into the “lol I don’t read my AI-generated PRs” crowd. Those are two different tribes of devs with completely different value systems. What’s changed isn’t that the same engineers did a 180 on principles, it’s that the discourse got hijacked by a new set…
No— I’m not assuming that but I absolutely can see how what I wrote could come across like that. Dominant voices in many communities change more frequently than the core principles of the people in them— some people just get louder, more visible, and more numerous and others fall to the wayside, especially when there’s marketing or some sort of ‘movement’ involved. (And there’s all sorts of ‘movements’ involved in tech hype and some of them are bovine.)
Your read on the situation concurs with mine. Cheers.
Re: The unbearable slowness of AI coding
#40> ... 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. I don't get this, how many git hooks do you need to identify that Claude had hallucinated a library feature? Wouldn't a single hook running your tests identify that?
I don't have a ton of tests. From what I've seen, Claude will often just update the tests to no-op so tests passing isn't trustworthy.
My workflow is often to plan with ChatGPT and what I was getting at here is ChatGPT can often hallucinate features of 3rd party libraries. I usually dump the plan from ChatGPT straight into Claude Code and only look at the details when I'm testing.
That said, I've become more careful in auditing the plans so I don't run in to issues like this.