[prymitive]

I need to write code because otherwise LLMs will write too much code, it’s only when you fully understand the problem you can generalise it enough to not end up with 10k lines and 5 abstraction layers for “hello world”. LLMs are token predictors, so all solutions are you tokens, the more problems to solve == the more tokens (code) to output.

[TacticalCoder]

> I need to write code because otherwise LLMs will write too much code, ...

I second that and I can give an example that happened to me yesterday with a totally SOTA model (a US, not Chinese model).

I needed to display an information on the client-side. Something trivial. I ask the LLM to do it. The thing went onto a rampage: it somehow found a way to pass the information from the server to the client during the initial handshake (already: why, just why?). Modifying both server-side code and client-side code. And it worked.

To an unsuspecting programmer/tester (or automated test)/user: the info is there, what was asked has been done. So it's perfect, flawless LLM victory right?

Except none of that sloppy-pasta was necessary: the info was already available on the client-side and was a one-line change, purely client-side.

These thing shall definitely, as of 2026, write way too much code.

And btw the companies selling metered tokens have a very serious incentive to produce the most complicated, rube-goldberg, solutions that use as many tokens as possible, while still kinda solving the problem.

That way not only you consume tokens to produce the code, but later on you consume tokens when working on that code (which btw is a guaranteed thing: for the LLM just introduced new bugs in that gargantic amount of crap it output).

Funnily enough the very same people who made fun of copy-pasta happen to be in love with sloppy-pasta. Go figure.

[softwaredoug]

LLMs love to defensively wrap code instead of thinking holistically about the big picture. That creates a lot of bloat.

A human coder might OTOH follow the Boy Scout rule and clean up as they go.

[krackers]

> it’s only when you fully understand the problem you can generalize

Peter Naur explained this decades ago

>Peter Naur argues that programming is fundamentally a human activity of building a mental "theory" - a deep conceptual insight into how a system's parts match the real-world problem it solves. He rejects the prevailing view that programming is merely the mechanical production of source code, specifications, and documentation. Instead, Naur posits that the true product of programming is the shared mental model held in the minds of the developers who built it.

As a human you're the one with the problem you want code to solve, so it's worth having an understanding the problem. Otherwise you risk an X/Y situation, where the LLM ends up solving a problem that may not actually satisfy what you need.

I think what LLMs allow you to do is better abstract away everything that's _not_ essential to the problem you care about, in the same way that libraries or any higher-level programming language does. Ultimately there's still a "core" of the problem that needs to be expressed formally though. When you see people "vibe coding" by prompting the LLM to add constraints at a time until they reach their desired end-goal, this is ultimately "programming" in a sloppy, non-formal way. Better to get the LLM to write everything else _surrounding_ the problem, so you can write and understand the core yourself.

[balder1991]

Basically, I’d say the LLM doesn’t have a “theory” of anything that wasn’t in its training. It’ll always treat your project as if it was reading a book for the first time.

As an example, if you chat with an LLM it can sort of explain concepts it learned in its training, because it created some internal representation of them. However it’ll never be able to explain things about your project unless you tell it (then it can simply repeat it, which is the same RAG does, the LLM is just spitting it out without any deep understanding of it).

You can try to cram as much context to it as possible and overload it with extra information, or you can understand this difference and separate a task that you know the LLM can handle because you’ll be able to leverage its knowledge and judge the final work yourself.

But this distinction needs to be more clear, I think. The LLM doesn’t have any deep understanding of anything you’re creaming into the context window the same way it does with concepts it learned during training from millions of examples and building some internal model of the concepts and their relationships.

[bigmattystyles]

That’s why even though 99% of my work is C#, llms have made it so I can finally call myself a low-level programmer, which I’ve always aspired to. I didn’t even have to do anything.

[supriyo-biswas]

So much this, the other day I wanted to set up a project running in K8s similar to our other modules at work, and it he thing ended up writing unit tests for a hello world implementation.

[h2aichat]

If tokens are the problem, SDD is the solution