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

101–107 of 107 posts

Re: The unbearable slowness of AI coding

#101

Post by bdangubic »

rootnod3 wrote: post #94
rootnod3 wrote: post #87

Earlier quoted context omitted.

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

one of the likely reasons you are getting downvoted is that you made a snarky remark. (unsolicited) word of advice - you should always listen to the enthusiasts (if you are not one of them), they have figured something out before you did (nothing wrong with that, many people are much smarter than you and I)...

Re: The unbearable slowness of AI coding

#102

Post by deterministic »

I am still way more productive using customer code generators than using AI.

However AI’s are great for quickly learning how to use external tools/libraries (like JasperReports) and for quickly writing parser functions.

It is like any other tool: good for some things bad for others.

Re: The unbearable slowness of AI coding

#103

Post by andrekandre »

cruffle_duffle wrote: post #85
CuriouslyC wrote: post #76

Earlier quoted context omitted.

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.

  > The amount of time writing that spec can take more time than just doing it by hand.
one thing about doing it by hand is you also notice holes/deficiencies in the spec and can go back and update it, make the product better, but just throwing it to an llm 'til its perfect-to-spec probably means its just going to be average quality at best...

tho tbh most software isn't really 'stunning' imo so maybe thats fine as far as most businesses are concerned... (sad face)

Re: The unbearable slowness of AI coding

#104

Post by andrekandre »

ants_everywhere wrote: post #23

I've found LLMs to be very good at writing design docs and finding problems in code. Currently they're better at locating problems than fixing them without direction. Gemini seems smarter and better at architecture and best practices. Claude seems dumber but is more focused on getting things done. The right solution is going to be a variety of tools and LLMs interacting with each other. But it's going to take real hu…

  > very good at writing design docs
sorry if this is a newbie-is question, but where does the information for design docs come from?

from 'product briefs' or something else?

Re: The unbearable slowness of AI coding

#105

Post by chipsrafferty »

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…

The reason these tools haven't achieved greatness yet is because 99% of us are struggling at work with domain knowledge - how does this special project work in the frame of this company. If an AI tool is unable to "learn the ropes" at a specific company over time, they will never be better than a mid-senior developer on day 1 at the company. They NEED to be able to learn. They NEED to be able have long-term memory and to read entire codebases.

Re: The unbearable slowness of AI coding

#106

Post by chipsrafferty »

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

I would never say "it's addictive" in any context.

Re: The unbearable slowness of AI coding

#107

Post by kiitos »

cpursley wrote: post #72
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?

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

the difference between an arbitrary LLM and a human engineer is completely described by the salary you would pay to the human engineer? in all other dimensions they are indistinguishable? nice, super cool
Post reply on HN