Hacker News Reader

Comment by aselimov3 | Hacker News Reader

I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written. Slowly your brain just gets trained to mid thinking like an LLM. At least that’s my theory and I think there was some study that showed that interacting with an LLM at the start of a problem significantly narrowed the solution space to something sub optimal

View on HN

    >  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.

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.

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.

> If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written.

This is my experience as well, and I've been using Claude Code a lot.

Extremely impressive tools, but they're like fast food. They will solve your immediate problems quickly and cheaply, but you're going to have issues on the long term if that's all you use.

Have you tried drilling into the reasoning when this happens? This is why I usually leave it in "Plan Mode" and when it proposes a solution that seems unusual or unexpected, I point out why I think it is and ask it to justify it's position.

Sometimes I get the "you're right!" response, but often it will also explain why it made the decision it did, and it's rational enough that I accept the new approach.

It's still very much like a junior dev in this way - pretty good at 'just make it work', pretty good at monkey-see-monkey-do, and occasionally surprises you with something novel (to you).

> Sometimes I get the "you're right!" response, but often it will also explain why it made the decision it did, and it's rational enough that I accept the new approach.

I think this is kind of what I’m worried about. Referencing Karpathy, an LLM can basically convince any one of anything. Doing this enough times and your opinions just become the LLM opinion. Same with problem solving approaches. I see this for myself so I reserve time to formulate my own solutions. Maybe my solutions are worse but at least I’m training the muscle that may lead to me outperforming the LLM in specific spaces

> LLM can basically convince any one of anything This and revision to the mean I think are real problems

I've found myself on more than one occasion just stepping away and needing to really sit down and think and to not ask an LLM until I have a clear idea of what I want to do

The one thing that bothers me is that one process I really used to run is thinking in code, slowly sketching out a solution until it had the properties I wanted it to have

I find myself not really engaging with this at present and it really bothers me, I've been trying to figure out how to get back into doing it again because I think the most differentiated and interesting ideas and thinking I had were usually shaped by going through that process

However so far I've found working with LLM's just doesn't jive with that thought process and several months into using them I'm still figuring out how to go back to doing that

How much time do I want to spend on this vs. just writing the old-fashioned way?

Fast food might be the right approach if it's a business that prefers speed to maintainability, and they might move towards that with LLMs. I wish more developers would go with it instead of fight it. It's not like it's a personal failure you can't convince the business to slow down and prefer quality.

The quality of the craft can live on in open source and personal projects.

I agree, just like some people decide that they're OK with eating junk food every day, knowing the long term risk. They are free to take it.

Lol sure thing Sam!

More like developers who give quality away for free then are left wondering why businesses who make millions still end up squeezing the life out of them.

I agree this is a problem too, but I suspect mostly for novel(ish) software problems. For me, LLMs have expanded the solution space, because, while I used to be decent with SQL in Postgres, now I'm operating on a whole new level—the LLM's ability to make sense of Postgres' full suite of options, and the performance implications of the queries, is far beyond what I could have accomplished.

It's a mixed bag.

I've been working with Apache AGE (openCypher in Postgres) recently and found that left to its own device, the agent wrote terribly inefficient queries, even when given a test harness and instructions to examine the result of the query plan.

It just didn't seem to understand the graph traversal, even when given the graph schema and small snippets.

I ended up hand-writing the structural "skeleton" of the main query that I performance tuned to a certain extent and then handed it over to Codex to finish off. Once it had this skeleton to start from, it was able to do a much, much better job of writing this query.

That’s a good point but I think this article above would push back on this point slightly. I certainly am able to do a lot more with LLMs because it can produce a passable solution in a lot of places but I’m not sure it expands my solution space really. I tend to separate what I’m able to build and what I’m able to solve. I can build a frontend with an LLM but I don’t think I’m able to solve frontend engineering problems.

If you have a very specific decision in mind, there's no need to ask the LLM at all and hope it guesses it. Depending on how sure I am, I will either explain what I want vaguely, or even phrasing things as questions, or be direct and inflexible. It ends up writing the code I would.

It's not all that different from what happens if I am delegating a larger task to another human being. The only actual difference there is that wit a person, I'd rather underspecify as to give them ore of a sense of freedom and opportunity for growth, while the LLM isn't learning anything, so, if anything, it's easier.

I was mainly just speaking to the point of the article with regards to ability to think about code/solve technical problems. I think most EMs I speak to would say their technical skill set is degraded from years not writing code. I think if you just review code without writing it, your technical skills degrade regardless of whether you are reviewing junior or LLM code. In both cases you maybe gain architecture design and soft skills but you are definitely not improving your technical skill set

I'm not sure about this. I think it's much the same as when you work in an organization comprising humans, and many of them are not so right about everything. Perhaps this will be familiar :)

I've noticed that Claude with the current model can act most of the time like a trusted senior engineer sounding board for me. However on occasions we disagree. Recently we had a stand up argument about a proposed solution to a potential security risk in a system. I realized Claude had taken on a kind of "corporate culture" thinking on the problem (which was to do with use of a vault/broker to hold user credential data) that would be appropriate in some contexts, but wasn't in ours. The experience was totally like arguing with someone on the corporate Slack, but in the end I control what gets deployed so I won. But I'd say 90% of the time I get as much value out of Claude on these discussions as I would if I knew one competent person for each of the subjects we discuss, and had called that person for advice. Of course even though my network is...vast...I just don't know a competent person in every single field.

> You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one.

totally depends on how you use the tools. Plenty of people fall in to that scenario, but plenty of others explicitly tell the LLM tools what and how to build something.

How do you make it follow your instructions though? I often an agent like Codex how to build something, and then it just ignores me.

some models do ok with instruction, some don't. You still have to review pretty thoroughly and make corrections or re-prompt.

For the most part I use claude code w/ opus plan mode + sonnet implementation mode, and it does pretty well. I go through the planning process for anything other than the most basic changes.

> You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative

Not really. You write the specs, you write the architecture. You ask the model to implement your solution.

But the specs can’t be fully detailed or else they would just be code which is the point the article above makes. You can certainly limit where the LLMs have freedom by writing more detail but obviously that defeats the purpose of LLMs. What I mean more broadly though is more along the lines of baked in solutions. The LLM will generally prefer certain architectures/libraries/patterns. If you develop a spec alongside an LLM (which I think most people do) you will get pushed towards those. You kind of close yourself off to other ways of solving a problem.

You can stop this by detailing exactly what solution you want but I think continuous leaning on the LLM will lead you into a confined space.

Yes, and LLMs are also very supportive, you get less critical feedback.

That presumes that software has a wide solution space. In my experience writing software from the kernel all of the way to distributed systems is that the space is narrow. There are certainly a few long tail areas that require unique approaches, but you'll hit those a couple of times a decade.

I love software. It is my passion. I've practiced and studied it for decades. We should not delude ourselves on what it actually is. Writing software is more like plumbing a tract home, than computational fluid dynamics. I'm fine with that.

Reply on news.ycombinator.com