Comment by trio8453
6 hours ago
The LLMs know design principles too, being an experienced developer doesn't make you as special as you might think.
6 hours ago
The LLMs know design principles too, being an experienced developer doesn't make you as special as you might think.
Don't get me wrong, LLMs are way better than me at most things, but I don't think you can deny that the current generation of models makes questionable decisions sometimes. Especially on project structure, API boundaries, and code duplication. I also think they just have bad taste in general, though of course that's more subjective.
I’m not sure how to say this without sounding smug, but the last year has shown that most of those things just… don’t matter. It’s just the next level of the “variable naming PR comment battle”, so will become obsolete very soon.
Obviously there are mission critical systems where it matters, but if “your code can be A/B tested” or “slowly rolled out”, chances are, it doesn’t matter.
You'll find that design matters when token spend starts facing real accounting.
Tech debt is still tech debt, even if there exist models that can wade through, because it's going to require increasingly sophisticated models navigating increasingly large context windows and increasingly speculative workspace operations to keep making progress on it.
Vendors like Anthropic and OpenAI are laying a pit trap when they demonstrate how their models can independently code their whole platform as it becomes increasingly byzantine and inscrutable because not only do they benefit from internal/prerelease models but they have effectively unlimited spend because all that spending acts as a lure to draw you into their trap.
For everybody else, design still matters. People are just working really hard to make you forget.
4 replies →
> I don't think you can deny that the current generation of models makes questionable decisions sometimes
Sometimes, not enough to believe you that you can do it better. And even if you could, to believe that it's overall worth it to work in that way.
What still is true for all fields of LLMs: if you can’t tell they do it suboptimally, you are just not that knowledgable in that area.
It still applies to all things LLms can do from law to code to art to ideas.
They can do it - and very acceptably - but only to the untrained eye.
You can work the way you want to work. In my experience, letting the agent make every decision leads to a big ball of mud that requires touching dozens of files to make a change. More context is needed, it burns through tokens much faster, and the agent takes shortcuts and builds technical debt. So the way I prefer to work is to have changes targeted to a single file or small set of files where I've defined the API. Maybe that will change in the future, I'm not set in stone here.
3 replies →
To be fair, if LLMs were good at decisions, we would not need people.
I keep hearing that humanity is going to be superseded by models that I can barely force to actually abide by a modular repository design.
I can see three likely explanations for how my personal experience with modern AI programming tools differs so much from a lot of the advocacy I see online.
1. We are working on different types of application and code.
2. I am in a bubble and no-one in it has experienced the standards and productivity that SOTA AI tools can achieve.
3. The advocates are in a bubble and no-one in it has experienced the standards and productivity that expert developers can achieve.
I hope the answer is 1. I fear the answer is 2. I suspect the answer is 3.
I've been doing this a long time and i would say since the last 3 months or so i've spent more time learning from llm code than correcting llm code. It's not bad and takes approaches and makes decisions i wouldn't have thought of. I'm not too ashamed to admit that, a model just as access wider and deeper experience with code than I do.
> doesn't make you as special as you might think.
Way to come off as incredibly insecure. There's no need to randomly put people down.
I'm not the one who's claiming to be above the latest models in some aspect of coding in this interaction.
No one at all claimed that, certainly not the person you responded to. They're talking about how to use these tools in a way that gives you insight into what they produce. So, as an engineer, you know the shape of the output, before it's made.
That's it. Maybe you should go re-read?
Its really sad that you think that an intelligence that cannot learn is better than you at everything.
The advantage I have is that I know things that are not in the training distribution. Things about our business, our product, and its internal architecture. Without this knowledge, some new features cannot be designed successfully.
Some day I expect that will change, but all the patchwork "memory" systems, all the docs etc, will never get there because at some point they just pollute context. Knowledge has to be integrated, and that is what happens during sleep for humans, during pre-training and RL for models. LLMs are terribly inefficient at learning though and degrade generally during fine-tuning.
Why is that so hard to believe? I don't always do this, but I do course-correct Claude on almost every big change. YOLOing it would superficially look fine, until the latent issues catch up with you.
1 reply →
Unlike a lot of humans, Claude's not gonna be a dick to you for thinking you're superior.
Maybe they are?
The LLMs have been trained on all kinds of code. They often choose a hacky solution because that's what they encountered in similar situations in their training. It generally only takes a few words to guide them to a better design than what they saw in the wild, but if you don't guide them, they follow the herd.
It generally only takes a few words to guide them to a better design than what they saw in the wild, but if you don't guide them, they follow the herd.
That certainly can be true but I would challenge "generally". If you're working on something novel then it's not exactly unusual for even SOTA models to produce a first attempt that makes some very bad assumptions but then get stuck when instructed to use correct axioms instead. This looks a lot like the suduko meme - without any real insight into the problem the models end up just iterating around in circles and never finding a solution.
You probably won't see this very often if you're working on simple CRUD web applications where there are millions if not billions of lines of code in the training data set. IME you will probably see it quite frequently if you're working on - for example - software to control some kind of equipment or analyse the results of some kind of experiment where the LLM might have little if any training data about the field you're operating in.
That's a great perspective. Come to think of it, I wonder about the quality of the build123d code it generated when I vibe-coded a prototype complex assembly. Now I'm curious.