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
How I write software with LLMs
501–510 of 544 posts
Re: How I write software with LLMs
#502Earlier 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
> 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
#503Earlier 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…
Re: How I write software with LLMs
#504Earlier 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…
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
#505Earlier 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…
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
#506I 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
#507Earlier 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?
Re: How I write software with LLMs
#508Earlier 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.
Re: How I write software with LLMs
#509Earlier 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.
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
#510Earlier 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.
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.