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

How I write software with LLMs

stavros.io

Post reply on HN
Print view View original

361–370 of 544 posts

Re: How I write software with LLMs

#361

Post by anthonyrstevens »

jplusequalt wrote: post #329
petcat wrote: post #275

Earlier quoted context omitted.

The point is that expert humans (the GCC developers) writing code (C++) that generates code (ASM) does not appear to be as deterministic as you seem to think it is.

Classic HN-ism. To focus on the semantics of a statement while ignoring the greater point in order to argue why someone is wrong.

I think it's a perfectly fine point. The OP said (my interpretation) that LLMs are messy, non-deterministic, and can produce bad code. The same is true of many humans, even those whose "job" is to produce clean, predictable, good code. The OP would like the argument to be narrowly about LLMs, but the bigger point even is "who generates the final code, and why and how much do we trust them?"

Re: How I write software with LLMs

#362

Post by anthonyrstevens »

sarchertech wrote: post #336
Kye wrote: post #333

Earlier quoted context omitted.

This seems to apply easily to LLMs as language coprocessors that can output code. How long was it before people trusted compilers?

If you don't understand the difference between something that rigorously translates one formal language to another one and something that will spit out a completely different piece of software with 0 lines of overlap based on a one word prompt change, I don't know what to tell you.

"rigorously" is doing a lot of heavy lifting here.

Re: How I write software with LLMs

#363

Post by raw_anon_1111 »

mikkupikku wrote: post #286
FeepingCreature wrote: post #229

Earlier quoted context omitted.

LLMs massively reduce the cost of "let's just try this". I think trying to migrate your entire repo is usually a fool's errand. Figure out a way to break the load-bearing part of the problem out into a sub-project, solve it there, iterate as much as you like. Claude can give you a test gui in one or two minutes, as often as you like. When you have it reliably working there, make Claude write up a detailed spec and br…

Claude is surprisingly good at GUI work I've been learning, not just getting stuff working but also creating reasonably tasteful and practical designs. Asking claude in the browser to mock up a GUI and then having claude code implement it is a surprisingly powerful workflow.

I’m far away from a web developer or a web designer. But I think I intuitively understand how to put myself in the shoes of the end user when it comes to UX.

I noticed that Claude is awful at understanding what makes good UX even as simple as something as if you have a one line input box and button that lets you submit the line of text, you should wire it up so a user can press return instead of pressing the button or thinking about them being able to tab through inputs in a decent order

Re: How I write software with LLMs

#364

Post by highfrequency »

> I’ll tell the LLM my main goal (which will be a very specific feature or bugfix e.g. “I want to add retries with exponential backoff to Stavrobot so that it can retry if the LLM provider is down”), and talk to it until I’m sure it understands what I want. This step takes the most time, sometimes even up to half an hour of back-and-forth until we finalize all the goals, limitations, and tradeoffs of the approach, and agree on what the end architecture should look like.

This sounds sensible, but also makes me wonder how much time is actually being saved if implementing a "very specific feature or bugfix" still takes an hour of back and forth with an LLM.

Can't help but think that this is still just an awkward intermediate phase of development with adolescent LLMs where we need to think about implementation choices at all.

Re: How I write software with LLMs

#365

Post by borski »

vanviegen wrote: post #129
borski wrote: post #38

Earlier quoted context omitted.

I never said therapists were only for those in crisis; that is a misreading of my argument entirely. An LLM cannot parse the complexity of your situation. Period. It is literally incapable of doing that, because it does not have any idea what it is like to be human. Therapy is not an objective science; it is, in many ways, subjective, and the therapeutic relationship is by far the most important part. I am not saying…

As you said earlier, therapists are (thoroughly) trained on how to best handle situations. Just 'being human' (and thus empathizing) may not be such a big part of the job as you seem to believe. Training LLMs we can do. Though it might be important for the patient to believe that the therapist is empathizing, so that may give AI therapy an inherent disadvantage (depending on the patient's view of AI).

> Just 'being human' (and thus empathizing) may not be such a big part of the job as you seem to believe.

The word “just” is not in my comment anywhere. Being human is necessary, but not sufficient.

And no, you cannot train an LLM to be human.

An LLM is not a therapist. Please do not confuse the two.

You cannot train an LLM on how to be human.

Re: How I write software with LLMs

#366

Post by borski »

emp17344 wrote: post #338
vanviegen wrote: post #129

Earlier quoted context omitted.

As you said earlier, therapists are (thoroughly) trained on how to best handle situations. Just 'being human' (and thus empathizing) may not be such a big part of the job as you seem to believe. Training LLMs we can do. Though it might be important for the patient to believe that the therapist is empathizing, so that may give AI therapy an inherent disadvantage (depending on the patient's view of AI).

Socialization with other humans has so many benefits for happiness, mental health, and longevity. Conversely, interaction with LLMs often leads to AI psychosis and harms mental health. IMO, this is pretty strong evidence that interaction with LLMs is not similar to socialization with real humans, and a pretty good indicator that LLM “therapy” is significantly less helpful or even harmful than human-driven therapy.

Precisely.

Re: How I write software with LLMs

#367

Post by AstroBen »

petcat wrote: post #237
awakeasleep wrote: post #230

Earlier quoted context omitted.

Explain how fragility of implementation, like spaghetti code, high coupling low cohesion fit into your world view?

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about (and actually want!). But when we review the ASM that GCC generates we are not concerned with the "spaghetti" and the "high coup…

This is fantasy completely disconnected from reality.

Have you ever tried writing tests for spaghetti code? It's hell compared to testing good code. LLMs require a very strong test harness or they're going to break things.

Have you tried reading and understanding spaghetti code? How do you verify it does what you want, and none of what you don't want?

Many code design techniques were created to make things easy for humans to understand. That understanding needs to be there whether you're modifying it yourself or reviewing the code.

Developers are struggling because they know what happens when you have 100k lines of slop.

If things keep speeding in this direction we're going to wake up to a world of pain in 3 years and AI isn't going to get us out of it.

Re: How I write software with LLMs

#368

Post by moduspol »

akhrail1996 wrote: post #22

Genuine question: what's the evidence that the architect → developer → reviewer pipeline actually produces better results than just... talking to one strong model in one session? The author uses different models for each role, which I get. But I run production agents on Opus daily and in my experience, if you give it good context and clear direction in a single conversation, the output is already solid. The ceremony…

To me, such techniques feel like temporary cudgels that may or may not even help that will be obsolete in 1-6 months.

This is similar to telling Claude Code to write its steps into a separate markdown file, or use separate agents to independently perform many tasks, or some of the other things that were commonly posted about 3-6+ months ago. Now Claude Code does that on its own if necessary, so it's probably a net negative to instruct it separately.

Some prompting techniques seem ageless (e.g. giving it a way to validate its output), but a lot of these feel like temporary scaffolding that I don't see a lot of value in building a workflow around.

Re: How I write software with LLMs

#370

Post by borski »

wiseowise wrote: post #137
borski wrote: post #58

Earlier quoted context omitted.

I never said great engineers didn’t write code. But writing the code was never the point. The point has always been delivering the product to the customer, in any industry. Code is rarely the deliverable. That’s my point.

> But writing the code was never the point. Is that why most prestigious jobs grilled you like a devil on algos/system design? > The point has always been delivering the product to the customer, in any industry. Code is rarely the deliverable. That’s just nonsense. It’s like saying “delivering product was always the most important thing, not drinking water”.

> Is that why most prestigious jobs grilled you like a devil on algos/system design?

No. That’s because interviews have always sucked, and have always been terrible predictors of how you do on the job. We just never had a better way of deciding except paying for a project.

> That’s just nonsense. It’s like saying “delivering product was always the most important thing, not drinking water”.

That’s… not an argument? It’s not even a strawman, it’s just unrelated.

The thing a customer has always paid for was the end product. Not the code. This is absolutely trivial to see, since a customer has never asked to read the code.

Post reply on HN