The unbearable slowness of AI coding • Hacker News Board

Re: The unbearable slowness of AI coding

#41

Post by torben-friis » Thu, Aug 21, 2025, 8:49 PM UTC

stillpointlab wrote: post #28

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…

>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.

Re: The unbearable slowness of AI coding

#42

Post by jmvldz » Thu, Aug 21, 2025, 8:53 PM UTC

DrewADesign wrote: post #10

Maybe 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”…

I'm trying to prototype extremely quickly and I'm working on my project alone so yes, often I accept PRs without looking too closely at the code if my local testing succeeds.

I'm using Typescript and Rust and I think it's critical to use strict typing with LLMs to catch simple bugs.

I've worked at Uber as an infra engineer and at Gem as an engineering manager so I do consider myself an "actual professional developer". The critical bit is the context of the project I'm working on. If I were at a tech company building software, I'd be much more reticent to ship AI generated PRs whole cloth.

Re: The unbearable slowness of AI coding

#43

Post by pipes » Thu, Aug 21, 2025, 8:54 PM UTC

I've no idea why, but the phrase "it's addicting" is really annoying, I'm pretty certain it should "it's addictive". I've started seeing it everywhere. (Note, I haven't completely lost my mind, it's in that article).

Re: The unbearable slowness of AI coding

#44

Post by jmvldz » Thu, Aug 21, 2025, 8:57 PM UTC

pipes wrote: post #43

I've no idea why, but the phrase "it's addicting" is really annoying, I'm pretty certain it should "it's addictive". I've started seeing it everywhere. (Note, I haven't completely lost my mind, it's in that article).

Haha fair enough. Fixed!

Re: The unbearable slowness of AI coding

#45

Post by nchmy » Thu, Aug 21, 2025, 9:01 PM UTC

jmvldz wrote: post #38

nchmy wrote: post #26

This 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.

Welcome to vibe/agentic engineering

Re: The unbearable slowness of AI coding

#46

Post by bdangubic » Thu, Aug 21, 2025, 9:04 PM UTC

stillpointlab wrote: post #28

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…

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…

Re: The unbearable slowness of AI coding

#47

Post by kiitos » Thu, Aug 21, 2025, 9:10 PM UTC

thrown-0825 wrote: post #25

pluto_modadic wrote: post #9

Earlier quoted context omitted.

AI agents have been known to rip out mocks so that the tests pass.

I have had human devs do that too

cool, can you think of any differences between a human engineer, who is presumably employed by an employer and subject to review and evaluation by a manager and inherently assumed to be capable of receiving feedback and reliably applying it on a go-forward basis to their future work, and an LLM, when they each make this same kind of mistake?

Re: The unbearable slowness of AI coding

#48

Post by kiitos » Thu, Aug 21, 2025, 9:11 PM UTC

dsiegel2275 wrote: post #35

Prompting 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 i…

please share these discrete instructions.md you're describing

Re: The unbearable slowness of AI coding

#49

Post by CuriouslyC » Thu, Aug 21, 2025, 9:12 PM UTC

You can prompt Claude into (assess -> fix -> validate) -> assess -> ... loops pretty easily. You can do this with unit test coverage, and sometimes it's nice to come back to 100% coverage of the codebase (and the code review agent kept the tests from being hot garbage). You can push this with front end tests, playwright, etc to really get deep into validating your application without actually slogging through PRs (yet!).

My pattern with claude code is to let stuff simmer in the background with a detailed PRD, and just turn the screws with progressively more testing and type checking. I'll use repomix to put my entire codebase into gemini 2.5 pro, chat with it for a bit and then ask it to generate a highly detailed work plan for claude code to make the codebase more production hardened/launch ready. If I don't burn my plan tokens first, that gemini prompt can keep claude running for like ~3 hours usually. If you repeat this gemini plan -> claude implement step a few times gemini will eventually start to tell you to stop being a chicken and launch your great app.

Re: The unbearable slowness of AI coding

#50

Post by CuriouslyC » Thu, Aug 21, 2025, 9:16 PM UTC

jmvldz wrote: post #37

tarruda wrote: post #34

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 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.

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.