Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unbearable slowness of AI coding

joshuavaldez.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: The unbearable slowness of AI coding

#71

Post by cpursley »

CuriouslyC wrote: post #51
jmvldz wrote: post #40

Earlier quoted context omitted.

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…

Tell Claude to use a code review sub agent after every significant change set, tell them to run the tests and evaluate the change set, don't tell Claude it wrote the code, and give them strict review instructions. Works like a charm.

Any tips on writing productive review sub agent instruction?

Re: The unbearable slowness of AI coding

#72

Post by cpursley »

kiitos wrote: post #47
thrown-0825 wrote: post #25

Earlier quoted context omitted.

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?

Yes, the difference is about $197,600 of playing fair or $57,600 if offshoring.

Re: The unbearable slowness of AI coding

#73

Post by hn_throw2025 »

simonw wrote: post #56

I wonder if the author is using automated tests. My hunch is that good automated testing is an enormous factor with respect to how productive you can get with coding agent tools. Thorough tests? Just like working without LLMs you can confidently make changes without fear of breaking other parts of the application. No tests at all? Any change you make is a roll of the dice with respect to how it affects the rest of yo…

I’m reaching the same conclusion… I have been subscribing to LLMs for a couple of years, and trying to find the right balance and workflow that gets the best out of human and machine.

I now think TDD can play a big part. I don’t have much of a background in unit testing. For a recent TypeScript utility mini project, I took an outside-in approach using mocks where necessary. This started as a prototyping and modelling phase, getting the design right before committing to implementation code. This was about refining the types and function signatures, and mocking the components that didn’t exist at that point. The LLM didn’t have involvement at this stage, as it was about the problem domain, the shape and flow of the data. Moving on from there, I was able to save a lot of time because SuperMaven in Cursor had enough context and understanding at that point to make very precise guesses about what I wanted, so I could tab autocomplete through a reasonable amount of boilerplate implementation code. I was also able to get away with writing a couple of happy path tests for most components, and get the agentic LLM to generate sad path tests. Most of which I kept, including one that smoked out a flaw in my design.

That’s essentially the process I’m gravitating towards. Human begins the process, models the design, sets the constraints, and then the LLM saves time in a limited and supervised way whilst being kept on a short leash.

Re: The unbearable slowness of AI coding

#74

Post by rstuart4133 »

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.

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.

Re: The unbearable slowness of AI coding

#75

Post by CuriouslyC »

cpursley wrote: post #71
CuriouslyC wrote: post #51

Earlier quoted context omitted.

Tell Claude to use a code review sub agent after every significant change set, tell them to run the tests and evaluate the change set, don't tell Claude it wrote the code, and give them strict review instructions. Works like a charm.

Any tips on writing productive review sub agent instruction?

Yes. Go on ChatGPT, explain what you're doing (claude code, trying to get it to be more rigorous with itself and reduce defects) then click deep research and tell it you'd like it to look up code review best practices, AI code review, smells/patterns to look out for in AI code, etc. Then have it take the result of that and generate a XML structured document with a flowchart of the code review best practices it discovered, cribbing from an established schema for element names/attributes when possible, and put it in fenced xml blocks in your subagent. You can also tell claude code to do deep research, you just have to be a little specific about what it should go after.

Re: The unbearable slowness of AI coding

#76

Post by CuriouslyC »

samrus wrote: post #68
CuriouslyC wrote: post #50

Earlier quoted context omitted.

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…

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

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.

Re: The unbearable slowness of AI coding

#77

Post by stillpointlab »

rcarr wrote: post #64
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…

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

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

Re: The unbearable slowness of AI coding

#78

Post by CuriouslyC »

cpursley wrote: post #69
CuriouslyC wrote: post #50

Earlier quoted context omitted.

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…

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.

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.

Re: The unbearable slowness of AI coding

#79

Post by danbmil99 »

What bothers me is this: Claude & I work hard on a subtle issue; eventually (often after wiping Claude's memory clean and trying again) we collectively come to a solution that works.

But the insights gleaned from that battle are (for Claude) lost forever as soon as I start on a new task.

The way LLM's (fail to) handle memory and in-situ learning (beyond prompt engineering and working within the context window) is just clearly deficient compared to how human minds work.

Re: The unbearable slowness of AI coding

#80

Post by iLemming »

I wonder if the choice of programming language for vibecoding actually would become more relevant rather than less so. Initial collective instinct suggests that perhaps languages don't really matter anymore since LLMs help promote PL egalitarianism, but then if it's as the OP describes it - humans are now becoming code reviewers, maybe different aspects of various languages start granting practical advantages, like Clojure connected to a REPL allowing rapid execution/validation of generated code blocks, or advanced static type systems (Haskel, Rust, etc.) providing an edge from another angle?
Post reply on HN