Hacker News Reader

Comment by ryandvm | Hacker News Reader

There some real game theory mechanics at play when it comes to LLM usage in corporations. Devs are cranking out superficially superior code and documentation by just aiming the Claude Code fire hose at everything they can. Leadership encourages this because from what they can tell, there is no downside.

It's hard to say if this code is structurally better or worse than before, but it's certainly voluminous and as far as leadership could ever tell, with their flawed metrics, that is all that matters. It will be years before we figure out if this is a good idea and worth the cognitive atrophy.

Anyone not using LLMs all day is just not going to be as prolific. I can't imagine that the same factors aren't at play in the scientific research community where it's all about how much you can publish.

View on HN

> "superficially superior code"

Can you unpack that a bit? It produces measurably, meaningfully inferior code everywhere I see it in use.

> "leadership encourages this because from what they can tell, there is no downside"

As said 'leadership' I find this a bit puzzling. I'm seeing strong, quantifiable evidence of increasing churn, increasing incident count, and length of downtime from the date of our biggest push into GenAI, and I'm organizing efforts on my teams to mitigate those issues and actively reduce GenAI adoption.

If you mean my c-suite, you're mostly correct although they are already rumbling about seeing zero or negative ROI on GenAI investments.

> Anyone not using LLMs all day is just not going to be as prolific

Agreed, but prolific != productive.

The code written by agents generally seems to reflect what you (the human driver) asked for. If you discuss the approach and architecture first, asking the right questions in the process, and then let it implement - the result is quite on point with the frontier models. Might need some minor touch-ups if agent missed some common conventions or guessed the expectations wrong (but again, salvageable with follow-up prompts). And when it comes to line-by-line logic within functions, I would argue that today's models are LESS likely to make a mistake in there than humans - especially if you cross-review with another model (e.g. "write with Claude, review with GPT").

Humans write slop too, you know. Just saying.

> leadership

Not sure if its just me, lately I have started feeling pretty offensive about the increased usage of the word. Its management not leadership by any means.

> "leadership encourages this because from what they can tell, there is no downside"

For most people in management its easier to pick the current set of slangs/abbreviation's, general trend and go with it. Understanding the details would take time, raise questions and no one in management has time or political capital to spend on it.

What size company are you talking about?

Sure, by "superficially superior code" I mean that LLMs, by design, produce code that has syntax and idioms that are perfectly in line with industry norms due to the vast training corpus that it comes from. It looks great at first glance.

Normally, this is a signal that the developer is at least informed about best practices in the language and is usually a pretty good indicator that they're thinking clearly about the work they're doing. That, along with reputation, takes a lot of cognitive burden off the reviewer.

However, with LLMs that is all it means. You can be sure the code is norm-compliant, but in my experience that is all you can be sure of. There's not really a guarantee that it has thought deeply about the problem space.

It's like a bridge that looks great.

IMO, cognitive athrophy is the point. If humans become dependent on AI, those corporations will get enough leverage to change laws in their favor. For example, people don't want a huge data center in the middle of their city, but the corporations will say that the same people can't do anything without AI powered by this data center. That's why I think that making humans deficient and dependent on AI is the entire point.

This is just conspiracy nonsense.

>I can't imagine that the same factors aren't at play in the scientific research community

I can't speak for the entire scientific research community, but I can say that for basic biomedical research (not clinical research), LLMs are mostly ignored. They simply don't have the ability to parse most raw wet lab data.

This obviously has not stopped the creation of a legion of startups, new Asst Profs, etc, claiming that they are using "AI" to crack new frontiers. In practice, the most effective of these use machine learning, rather than LLMs.

> It's hard to say if this code is structurally better or worse than before, but it's certainly voluminous and as far as leadership could ever tell, with their flawed metrics, that is all that matters.

Hah. I've been working with ChatGPT-5.6 Sol and a lot of guidance to port a particular geometry from 2800 lines of Python-scripted Rhino3D (basically a custom parametric CAD kernel in there, plus use of it) to Python-scripted OCCT/FreeCAD (an existing CAD kernel) and it's up to 36,000 lines and only about half way there. And I've been setting goals and targets for duplication minimization, code size reduction, etc. The results are fine for my purposes, but if I put a positive value on "voluminous" I'd be super impressed; with my actual negative value assignment on lines of code, this is more "absolute crap but still useful to me."

I think "absolute crap but still useful to me" is a pretty high value and not worth neglecting, but I'm definitely scared by leadership who sees the toilet overflowng and assumes that means that value has been maximized.

> I think "absolute crap but still useful to me" is a pretty high value and not worth neglecting

If I extrapolate this example to my professional life, this code now manages millions of dollars, a single mistake can wipe it all out, it has to be maintained by 5 other engineers and understood by 5 other domain experts.

That's a real risk, yes. There's definitely a difference between cases where the code is the artifact being built, and cases where the code is being built to generate an artifact that is independently valuable and assessable. I'm happily in the latter case -- but I definitely share your fear of those who think current LLMs are valuable in the former case.

> It's hard to say if this code is structurally better or worse than before,

Huh?

But that's easy to tell?

It's better then incompetents code, worse then a motivated average dev... But good enough hence the real question is value aka time& money invested/quality.

That's much harder to tell, and I currently think opus/fable generated code is decent enough to be safely in favor - at least on subscription

> It's better then incompetents code, worse then a motivated average dev...

That's well put.

> But good enough hence the real question is value aka time& money invested/quality.

There's time invested SO FAR and time that will have to be invested to maintain it. In my experience, even with Fable, it's not there yet. It's the reason why it's easy to vibe code an app from scratch, but at some point when complexity significantly increases, the codebase becomes a mess.

> Leadership encourages this because from what they can tell, there is no downside.

This was my big fear before we saw price increases. Now I'm pinning all my hopes on AI being too expensive to justify further big corporate pushes. (Sigh.) I love having new tools, but I hate being pushed to use ______ tool to meet some managerial metric.

Reply on news.ycombinator.com