Live data from Hacker News

How I write software with LLMs

stavros.io

501–510 of 544 posts

Re: How I write software with LLMs

#501

Earlier quoted context omitted.

[dead]

Agentic pipelines and systems fall into the same issues as humans who work together, mostly communication. It's not like they can dump their full context to the "manager" agent, they need to condense stuff, which will result in misinterpreted information or missing information on decisions down the line. IMO this was more relevant when agents had limited context windows

This I believe is true. Have been working on an Agentic architecture and whenever there was a new requirement the simple workflow was to create an specific agent for that. Earlier the context windows were small and this was the default solution. Overtime our total agents have become vast that it is a headache to maintain and debug.

Re: How I write software with LLMs

#502

Earlier quoted context omitted.

In a non-trivial app you can't test your way through all of the e2e workflows and thoughtful design isn't what I'm talking about. How many bugs have you seen that passed your automated and manual testing? Probably 99.9% of them. Now imagine that you take those same test suites and you unleash an agent on the code that has far worse reasoning capabilities than a human and you tell them they can change anything in the…

So if bugs pass through testing which they have forever, wouldn’t that imply that humans are just as fallible as AI - and slower? I never suggested letting agents code for a day on end. I use AI to code well defined tasks and treat it like a mid level ticket taker

If you have an employee who codes 2x faster than everyone else but produces 10x the bugs, would your suggestion to be to let him rip and stop reviewing his code output?

> I never suggested letting agents code for a day on end. I use AI to code well defined tasks and treat it like a mid level ticket taker

It doesn’t matter how long you’re letting it run. If you aren’t reviewing the output, you have no way of knowing when it changes untested behavior.

I regularly find Claude doing insane things that I never would have thought to test against, that would have made it into prod if I hadn’t renewed the code.

Re: How I write software with LLMs

#503

Earlier quoted context omitted.

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

It's well understood that programming interviews are a pretty shitty tool. They're a proxy for understanding if you have basic skills required to understand a computer. Notably, most companies don't rely on these alone, they have behavioral questions, architecture questions, etc. Have you ever done an interview at these companies you're talking about? They're 8 hours lol maybe 1 is spent programming. But it's just ve…

Gold luck passing Leetcode before you even get to all of these. Whether they’re shitty or not is irrelevant, they’re here and it’s a fact.

Re: How I write software with LLMs

#504
post #370

Earlier quoted context omitted.

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

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

Who cares? They’re here, and they will stay here for foreseeable future.

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

Yeah, and they didn’t pay for the water that you drank. Without which, you know, you’ll fucking die. Code is part of the package, just like you eating and shitting in the process.

Re: How I write software with LLMs

#505

Earlier quoted context omitted.

So if bugs pass through testing which they have forever, wouldn’t that imply that humans are just as fallible as AI - and slower? I never suggested letting agents code for a day on end. I use AI to code well defined tasks and treat it like a mid level ticket taker

If you have an employee who codes 2x faster than everyone else but produces 10x the bugs, would your suggestion to be to let him rip and stop reviewing his code output? > I never suggested letting agents code for a day on end. I use AI to code well defined tasks and treat it like a mid level ticket taker It doesn’t matter how long you’re letting it run. If you aren’t reviewing the output, you have no way of knowing w…

> It doesn’t matter how long you’re letting it run. If you aren’t reviewing the output, you have no way of knowing when it changes untested behavior.

You’re focused on the output , I’m focused on the behavior. Thats the difference. Just like when I delegate a task to either another developer or another company like the random Salesforce integration or even a third party API I need to integrate with.

Re: How I write software with LLMs

#506
I've seen something similar with forecasting.

I can get more accurate forecasts by having distinct agents do different research tasks, summarize, and then feed those summaries to an agent that uses judgment to forecast.

I think it is all about managing context.

Re: How I write software with LLMs

#507
post #195

Earlier quoted context omitted.

Anything or anyone. Being polite to your surroundings reflects in your surroundings.

Did you thank your keyboard for letting you type this comment?

No. I would not consider that a useful form of politeness towards an object (but, clearly, others disagree). I chose to wash hands, clean the keyboard regularly and steer clear of abusing it in other ways.

Re: How I write software with LLMs

#508

Earlier quoted context omitted.

Can you bolt superpowers onto an existing project so that it uses the approach going forward (I'm using Opencode), or would that get too messy?

These are just skills, so you can add the skills to your setup and start using them whenever you like.

Thanks

Re: How I write software with LLMs

#509

Earlier quoted context omitted.

If you have an employee who codes 2x faster than everyone else but produces 10x the bugs, would your suggestion to be to let him rip and stop reviewing his code output? > I never suggested letting agents code for a day on end. I use AI to code well defined tasks and treat it like a mid level ticket taker It doesn’t matter how long you’re letting it run. If you aren’t reviewing the output, you have no way of knowing w…

> It doesn’t matter how long you’re letting it run. If you aren’t reviewing the output, you have no way of knowing when it changes untested behavior. You’re focused on the output , I’m focused on the behavior. Thats the difference. Just like when I delegate a task to either another developer or another company like the random Salesforce integration or even a third party API I need to integrate with.

Unfortunately you are not equipped to observe and test all or even most of the behavior of a non-trivial system.

And if you attempt to treat every module in your system like it’s untrusted 3rd party code you’ll run into severe complexity and size limits. No one codes large systems like that because it’s not possible. There are always escape hatches and entanglements.

Re: How I write software with LLMs

#510

Earlier quoted context omitted.

I've actually found that well-written well-documented non-spaghetti code is even more important now that we have LLMs. Why? Because LLMs can get easily confused, so they need well written code they can understand if the LLM is going to maintain the codebase it writes. The cleaner I keep my codebase, and the better (not necessarily more) abstracted it is, the easier it is for the LLM to understand the code within its…

I somewhat agree. But that’s more about modularity. It helps when I can just have Claude code focus on one folder with its own Claude file where it describes the invariants - the inputs and outputs.

If you don’t read the code how the heck do you know anything about modularity? How do you know that Module A doesn’t import module B, run the function but then ignore it and implement the code itself? How do you even know it doesn’t import module C?

Claude code regularly does all of these things. Claude code really really likes to reimplement the behavior in tests instead of actually exercising the code you told it to btw. Which means you 100% have to verify the test code at the very least.

Post reply on HN