Live data from Hacker News

How I write software with LLMs

stavros.io

251–260 of 544 posts

Re: How I write software with LLMs

#251

I randomly clicked and scrolled through the source code of Stavrobot - The largest thing I’ve built lately is an alternative to OpenClaw that focuses on security. [1] and that is not great code. I have not used any AI to write code yet but considered trying it out - is this the kind of code I should expect? Or maybe the other way around, has someone an example of some non-trivial code - in size and complexity - writt…

It's the kind of code you should expect if you don't run a harness that includes review and refactoring stages.

It's by no means the best LLMs can do.

Re: How I write software with LLMs

#252
The world could use one less "how I slop" article at this point.

This reminds me of the early Medium days when everyone would write articles on how to make HTTP endpoints or how to use Pandas.

There’s not much skill involved in hauling agents, and you can still do it without losing your expertise in the stuff you actually like to work with.

For me, I work with these tools all the time, and reading these articles hasn’t added anything to my repertoire so far. It gives me the feeling of "bikeshedding about tools instead of actually building something useful with them."

We are collectively addicted to making software that no one wants to use. Even I don’t consistently use half the junk I built with these tools.

Another thing is that everyone yapping about how great AI is isn’t actually showing the tools’ capabilities in building greenfield stuff. In reality, we have to do a lot more brownfield work that’s super boring, and AI isn’t as effective there.

Re: How I write software with LLMs

#253
post #237

Earlier quoted context omitted.

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…

A compiler uses rigorous modeling and testing to ensure that generated code is semantically equivalent. It can do this because it is translating from one formal language to another. Translating a natural prompt on the other hand requires the LLM to make thousands of small decisions that will be different each time you regenerate the artifact. Even ignoring non-determinism, prompt instability means that any small chan…

As if when you delegate tasks to humans they are deterministic. I would hope that your test cases cover the requirements. If not, your implementation is just as brittle when other developers come online or even when you come back to a project after six months.

Re: How I write software with LLMs

#254

Earlier quoted context omitted.

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

You did see the part about my unit, integration and scalability testing? The testing harness is what prevents the fragility. It doesn’t matter to AI whether the code is spaghetti code or not. What you said was only important when humans were maintaining the code. No human should ever be forced to look at the code behind my vibe coded internal admin portal that was created with straight Python, no frameworks, server s…

> It doesn’t matter to AI whether the code is spaghetti code or not. What you said was only important when humans were maintaining the code.

In my experience using AI to work on existing systems, the AI definitely performs much better on code that humans would consider readable.

You can’t really sit here talking about architecting greenfield systems with AI using methodology that didn’t exist 6 months ago while confidently proclaiming that “trust me they’ll be maintainable”.

Well you can, and most consultants do tend to do that, but it’s not worth much.

Re: How I write software with LLMs

#257
post #242

Earlier quoted context omitted.

This definitely is the case. I was talking to someone complaining about how llms don't work good. They said it couldn't fix an issue it made. I asked if they gave it any way to validate what it did. They did not, some people really are saying "fix this" instead of saying "x fn is doing y when someone makes a request to it. Please attempt to fix x and validate it by accessing the endpoint after and writing tests" Its…

If you tell a human junior developer just "fix this" then they will spend a week on a wild-goose chase with nothing to show for it. At least the LLM will only take 5 minutes to tell you they don't know what to do.

Do they? I’ve never got a response that something was impossible, or stupid. LLMs are happy to verify that a noop does nothing, if they don’t know how to fix something. They rather make something useless than really tackle a problem, if they can make tests green that way, or they can claim that something “works”.

And’ve I never asked Claude Code something which is really impossible, or even really difficult.

Re: How I write software with LLMs

#258

> One thing I’ve noticed is that different people get wildly different results with LLMs, so I suspect there’s some element of how you’re talking to them that affects the results. It's always easier to blame the prompt and convince yourself that you have some sort of talent in how you talk to LLMs that other's don't. In my experience the differences are mostly in how the code produced by the LLM is reviewed. Develope…

This definitely is the case. I was talking to someone complaining about how llms don't work good. They said it couldn't fix an issue it made. I asked if they gave it any way to validate what it did. They did not, some people really are saying "fix this" instead of saying "x fn is doing y when someone makes a request to it. Please attempt to fix x and validate it by accessing the endpoint after and writing tests" Its…

There are subtler versions of this too. I've been working on a TUI app for a couple of weeks, and having great success getting it to interactively test by sending tmux commands, but every once in a while it would just deliver code that didn't work. I finally realized it was because the capture tools I gave it didn't capture the cursor location, so it would, understandably, get confused about where it was and what was selected.

I promptly went and fixed this before doing any more work, because I know if I was put in that situation I would refuse to do any more work until I could actually use the app properly. In general, if you wouldn't be able to solve a problem with the tools you give an LLM, it will probably do a bad job too.

Re: How I write software with LLMs

#259
post #237

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…

Valid points. But crucial part of not "letting go" of the code is because we are responsible for that code at the moment.

If, in the future, LLM providers will take ownership of our on-calls for the code they have produced, I would write "AUTO-REVIEW-ACCEPTER" bot to accept everything and deploy it to production.

If, company requires me to own something, then I should be aware about what's that thing and understand ins and outs in detail and be able to quickly adjust when things go wrong

Re: How I write software with LLMs

#260

Earlier quoted context omitted.

Also developer UX, common antipatterns, etc This “the only thing that matters about code is whether it meets requirements” is such a tired take and I can’t imagine anyone seriously spouting it has has had to maintain real software.

The developer UX are the markdown files if no developer ever looks at the code. Whether you are tired of it or not, absolutely no one in your value you chain - your customers who give your company money or your management chain cares about your code beyond does it meet the functional and non functional requirements - they never did. And of course whether it was done on time and on budget

[dead]
Post reply on HN