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

81–90 of 107 posts

Re: The unbearable slowness of AI coding

#81

Post by dsiegel2275 »

kiitos wrote: post #48
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

They are about to land in this PR: https://github.com/Simon-Initiative/oli-torus/pull/5811

Re: The unbearable slowness of AI coding

#82

Post by danbmil99 »

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…

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

Re: The unbearable slowness of AI coding

#83

Post by abrookewood »

danbmil99 wrote: post #79

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 jus…

Yes, it's a common problem. There are 'memory' plugins that you can use to collect insights and feed it back to the LLM, but I tend just to update an AGENTS.md file (or equivalent).

Re: The unbearable slowness of AI coding

#84

Post by cruffle_duffle »

danbmil99 wrote: post #79

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 jus…

And the thing is all these “memory features” don’t help either because the “memory” is too specific either to the task at hand and not generalizable to all things, or it is time bound and therefore won’t be useful later (eg: “user is searching for a new waterbed with flow master manifolds”). And rarely can you directly edit the memory so you are stuck with a bunch of potential nonsense polluting your context (with little control when or why the memory is presented).

I dunno.

Re: The unbearable slowness of AI coding

#85

Post by cruffle_duffle »

CuriouslyC wrote: post #76
samrus wrote: post #68

Earlier quoted context omitted.

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.

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.

Re: The unbearable slowness of AI coding

#86

Post by robertfw »

deegles wrote: post #8
sc68cal wrote: post #3

Earlier quoted context omitted.

They probably don't have any tests, or the tests that the LLM creates are flawed and not detecting these problems

I tried using agents in Cursor and when it runs into issues it will just rip out the offending code :)

I've had similar cases where the fix to the test was.. delete the test. Ah, if only I'd realized that little hack earlier in my career!

Re: The unbearable slowness of AI coding

#87

Post by rootnod3 »

bdangubic wrote: post #46
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…

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

Re: The unbearable slowness of AI coding

#88

Post by belZaah »

There is no silver bullet (Brooks). The complex part of programming is not writing code. It’s the conceptualization of the problem. Even if one day Claude is able to crank out perfect code fully autonomously, the complex part of figuring out how to solve a given problem in software remains. And would still be as complex.

Re: The unbearable slowness of AI coding

#89

Post by thrown-0825 »

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?

yeah, when its a human its not a random chance and was them subverting testing and safety requirements to shortcut their way through their job.

Re: The unbearable slowness of AI coding

#90

Post by pipes »

jmvldz wrote: post #44
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!

Ha! Thanks :)
Post reply on HN