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

91–100 of 107 posts

Re: The unbearable slowness of AI coding

#91

Post by bdangubic »

rootnod3 wrote: post #87
bdangubic wrote: post #46

Earlier quoted context omitted.

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.

not sure this is really true/fair, I think what LLM/agentic code enthusiasts will say is that they have found their way to be effective with it while naysayers will fight the "this is sh*t" battle until they are eventually out of the workforce.

Re: The unbearable slowness of AI coding

#93

Post by rootnod3 »

bdangubic wrote: post #91
rootnod3 wrote: post #87

Earlier quoted context omitted.

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

not sure this is really true/fair, I think what LLM/agentic code enthusiasts will say is that they have found their way to be effective with it while naysayers will fight the "this is sh*t" battle until they are eventually out of the workforce.

So, why do you only opt for that side of the argument? Why not indulge in the side of the naysayers will be able to keep a job after the bubble bursts because they still know how to code by hand? And that exact sentiment is what I was alluding to.

There is maybe some truth to the LLM vibe coding and there maybe is some truth to the “old guard” saying “this is shit”, because this might be shit for very good reasons.

Re: The unbearable slowness of AI coding

#94

Post by rootnod3 »

rootnod3 wrote: post #87
bdangubic wrote: post #46

Earlier quoted context omitted.

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.

I seem to have forgotten the golden rule to never speak out against LLMs, yet you be subjected to instant downvotes. I don't mind the downvotes, but bring some counterpoints to the discussion and make it worth the platform.

EDIT: typo

Re: The unbearable slowness of AI coding

#95

Post by octodoctor »

CuriouslyC wrote: post #75
cpursley wrote: post #71

Earlier quoted context omitted.

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

[dead]

Re: The unbearable slowness of AI coding

#96

Post by kerblang »

hodgehog11 wrote: post #12

AI tools seem excellent at getting through boilerplate stuff at the start of a project. But as time goes on and you have to think about what you are doing, it'll be faster to write it yourself than to convey it in natural language to an LLM. I don't see this as an issue with the tool, but just getting a better idea of what it is really good for.

I tend to think of it as magical incantations rather than boilerplate, and the AI is Harry Potter, except in this case Harry is a pathological liar & psychopath - but a useful one...

Re: The unbearable slowness of AI coding

#97

Post by JeremyNT »

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…

> What I can say, this is an entirely new skill. It isn't like architecting large systems for human development. It isn't like programming. It is its own thing.

It's management!

I find myself asking very similar questions to you: how much detail is too much? How likely is this to succeed without my assistance? If it does succeed, will I need to refactor? Am I wasting my time delegating or should I just do it?

It's almost identical to when I delegate a task to a junior... only the feedback cycle of "did I guess correctly here" is a lot faster... and unlike a junior, the AI will never get better from the experience.

Re: The unbearable slowness of AI coding

#98

Post by h3lp »

qudat wrote: post #67
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?

That's a great insight---the problem with LLMs is that they write code and elegant prose for us, so we have more time to do chores. I want it the other way around!!!

Re: The unbearable slowness of AI coding

#99

Post by bdangubic »

rootnod3 wrote: post #93
bdangubic wrote: post #91

Earlier quoted context omitted.

not sure this is really true/fair, I think what LLM/agentic code enthusiasts will say is that they have found their way to be effective with it while naysayers will fight the "this is sh*t" battle until they are eventually out of the workforce.

So, why do you only opt for that side of the argument? Why not indulge in the side of the naysayers will be able to keep a job after the bubble bursts because they still know how to code by hand? And that exact sentiment is what I was alluding to. There is maybe some truth to the LLM vibe coding and there maybe is some truth to the “old guard” saying “this is shit”, because this might be shit for very good reasons.

I’ve been doing this sht for 30 years and one thing I can tell you I learned - when you see something as “groundbreaking” (controversial?) as llms and see many people telling you how much more productive they are with it there are almost always two camps:

- those fighting HARD to tell you at the top of their lungs “oh this is sht, I tried it and it is baaaad

- those going “hmmm let me see how I can learn etc to get to the point where I am also a lot more productive, if ____ and ____ can learn it so can I…”

You always want to be in the second camp…

Re: The unbearable slowness of AI coding

#100

Post by kiitos »

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

Earlier quoted context omitted.

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.

nope not that
Post reply on HN