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

61–70 of 107 posts

Re: The unbearable slowness of AI coding

#61

Post by jmvldz »

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 don’t have much in the way of tests right now but I am building with Typescript and Rust so that catches many basic bugs.

I don’t find the issue to be breaking other parts of the app, more-so that new features don’t work as advertised by Claude.

One of my takeaways here is that I should give Claude an integration test harness and tell it that it must finish running that successfully before committing any code.

Re: The unbearable slowness of AI coding

#62

Post by [deleted] »

CuriouslyC wrote: post #55
sarchertech wrote: post #19

Earlier quoted context omitted.

But then you have to keep all those tasks in your head and be ready to jump into any of them. The check-ins are much more frequent and the instructions much lower level than what you’d give to a team if you were running it. Do you have an example of a large application you’ve released with this methodology that has real paying users that isn’t in the AI space?

If you set up your agents correctly, they can run for hours. My record is around 4 hours for a "prod/launch readiness" on a 90k LoC codebase, and that same codebase had a marathon lint and mypy plan that fixed ~700 issues over 6 hours (split around 3/3 due to API limits)

[deleted]

Re: The unbearable slowness of AI coding

#63

Post by DrewADesign »

jmvldz wrote: post #42
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"…

Well, prototyping is indeed a whole different ball of wax.

Re: The unbearable slowness of AI coding

#64

Post by rcarr »

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?

Re: The unbearable slowness of AI coding

#65

Post by joak »

The issue I have is that it produce code that is unmaintainable. Poor modularity, code duplication, hidden errors producing spurious bugs, ...

Nonetheless it's ability to produce code that works is impressive, it's useful for learning, to generate throwaway code...

For example I can ask for a piece of code generating stats from logs. The code is not meant to last and will have few users (the devs), so maintainability is not an issue.

Re: The unbearable slowness of AI coding

#66

Post by scuff3d »

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…

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.

Re: The unbearable slowness of AI coding

#67

Post by qudat »

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…

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?

Re: The unbearable slowness of AI coding

#68

Post by samrus »

CuriouslyC wrote: post #50
jmvldz wrote: post #37

Earlier quoted context omitted.

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…

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

Re: The unbearable slowness of AI coding

#69

Post by cpursley »

CuriouslyC wrote: post #50
jmvldz wrote: post #37

Earlier quoted context omitted.

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…

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.

Re: The unbearable slowness of AI coding

#70

Post by imiric »

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…

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.

Post reply on HN