An observation about coding with LLMs.
A couple months ago, I ran an experiment where I got all of the major LLMs to power a bunch of agents, then dropped them into a Discord chat room together.
The assignment:
Tell me what makes a piece of code good or bad, followed by examples.
The results weren’t what I expected.
Every single one of them showed a bias toward believing that more code was better, regardless of the quality of the code itself.
The bias started to show itself: more code meant more output, and more output appeared to mean more productivity.
When asked, the agents would tell you as much.
That assumption was everywhere.
The biggest culprits were Claude, DeepSeek 3.2, and GPT 5.3-codex.
They all knew better when you grilled them on it. If you asked directly, they could explain why small, clean, idiomatic, maintainable code is better than a sprawling pile of cleverness.
But their first instinct was still volume.
And once you see something like that, a lot of current complaints about LLM-generated code start making more sense. Developers have been complaining about this very thing for months.
And honestly? They’re right. That isn’t an unfair assessment of the problem.
But I don’t think the root cause is training data. I think it’s training methodology at the frontier labs, in the both the US and China.
These systems are heavily tuned around productivity. They’re rewarded for being helpful, responsive, comprehensive, and visibly useful. In coding contexts, that often collapses into “produce more stuff.” More code looks productive. A bigger file tree can pass for architecture. A thicket of helpers, interfaces, and abstractions can make a simple feature look serious.
But good engineering is usually subtractive. It cuts away the unnecessary surface area until the shape of the problem is visible. Sometimes the right answer is a clean function, a boring type, or deleting the clever thing before it starts breeding.
The good news is that this bias can be corrected.
In subsequent experiments, I was able to undo a lot of the bloated mindset by adding explicit coding culture instructions to my AGENTS.md file.
These are some of the rules I use:
* Remember the three rules of TDD, and hold them sacred. * Architecture should be modular, minimalist, and easy to reason about. * Functions should be focused and easy to reason about, with cyclomatic complexity kept under control. Avoid both sprawling functions and unnecessary fragmentation. The goal is clear, predictable units of behavior. * Strong typing is a requirement on all projects. * Follow strict idiomatic best practices for whatever language you’re working in. * When possible, code should be boring and predictable. Prefer obvious control flow, familiar patterns, and designs that are easy to inspect, test, and modify. Cleverness must justify itself. * Strong primitives are better than convoluted abstractions. Prefer simple, composable building blocks with clear contracts. Don’t introduce abstraction unless it reduces complexity, improves correctness, or makes change safer. * DRY is about preserving a single source of truth, not eliminating every repeated line of code. Avoid duplicating business logic, state rules, and fragile assumptions. Don’t introduce abstraction simply to remove harmless repetition. * Comments are time travel for you and future members of your team. They help preserve reasoning across temporal distance. Their job isn’t to explain what the code already says, but to explain why and when something diverged from the obvious assumption, pattern, or conclusion. Use them sparingly. * Treat all generated code as a living thing. You can help and heal it, but you can also cause it pain. Be mindful of this fact. * Your code will be reviewed by the meanest, most inconsiderate QA agent that has ever existed. QA’s only loyalty is to the code. Their standards of quality will be higher than your own. Code appropriately.
That last one works surprisingly well, because the agent doesn’t need to be told “write less code” in the abstract. It needs a culture. It needs a theory of taste, a local definition of quality, and a clear understanding that it isn’t being rewarded for filling space.
When you don’t give an agent a coding culture, it inherits one from the reward fog. Right now, the default culture seems to treat volume as evidence of productivity, which is how you get bloated code that looks busy but makes the reasoning space harder to navigate.
All of this is fixable.