Hacker News new | ask | show | jobs
by CharlieDigital 31 days ago

    >  Slowly your brain just gets trained to mid thinking like an LLM
Regression to the mean.

I am doing a lot of the code reviews on my team and I can see that LLMs have a hard time with OOP (or are perhaps specifically guided to avoid) and writes a lot of `private static` utility functions. A lot of duplicated small utilities that can end up becoming a maintenance nightmare should the behavior need to be normalized/fixed. String key formatting, for example. JSON serialization behavior, another very common one. At a higher level, it needs very active guidance to search for existing code and re-use interface contracts via DI consistently (we have instructions and skills for this, but hit or miss on usage and adherence)

It generates very repetitive code and doesn't have the wits to refactor is in a way that is reusable, even in simple cases (basic JSON serialization).

It really dislikes to create object and type hierarchies on its own (e.g. move the repetitive serialization to a base class) and prefers to write one-offs. Works, but not very elegant; lots of duplication and touch points for regressions.

It also has a tendency to write more "verbose" solutions where sometimes simpler ones will work.

4 comments

Cleaning up tech debt is a must with AI for a lot of these orphaned utilities and anti patterns.

My hope is eventually open source models get far enough along we just train the models on company specific code needs.

Until then it is a lot of wack a mole with skills, hooks, system prompts, and interweaving deterministic needs.

can you say which llms you're using? have you tried different ones and how were they?
Team is a mix; I'm personally using Codex, gpt-5.5 high fast + Claude Opus 4.6 (occasionally Sonnet 4.6).

Mix of CLI (Codex) and GH Copilot (if I want active line selection).

We have a set of custom skills and knowledge base as well.

Predictable yeah. We're far better to find the right overarching narrative of the architecture and the necessary intermediate layers of abstractions. LLMs will invent verbal structs that sound okay but not have the elegance of a senior OOP. Although once the good foundation is there, agents can be great at extending and maintaining features on it.
This sounds very much like a problem of the context, that should be solvable by having a file with instructions on how to do generic utilities somewhere in the code (e.g. AGENTS.md)
We have; but it's also not easily practical because there is some judgement involved and it's not really feasible to point out all of the edge cases (bloating the context).

What is not clear to me is whether this is inherent desirable behavior on the part of the agent or not. Why? Because for the agent, the code is more isolated and its immediate changes have a lower blast radius by internalizing some behavior (`private static`) versus touching a shared method or hierarchy.

I can see why the underlying models may be steered this way, but it creates a different kind of problem when things really should be shared.