7 ms·

Claude regular spits out six helper functions instead of... A twenty line for loop. It overengineers most things. Overabstracting, deduplicating things that do

by shakna 12d ago

Claude regular spits out six helper functions instead of... A twenty line for loop. It overengineers most things. Overabstracting, deduplicating things that don't need to be. Building metaclasses because it saw a single orchestrator in the whole codebase. If it is a better engineer than you... You need practice.

raverbashing 12d ago
100% It is my pet peeve with Claude and why I don't prefer it for most stuff (also the comment spam - but that's a all of them in a way or another)
adjejmxbdjdn 12d ago
The funny thing is that if you never understand the codebase then you will keep thinking Claude is doing a great work delivering all this incredible software, when all it has done is created unnecessary tech debt.
- noir_lord 12d ago
  Which at some point the developers who actually still do know how to program are either going to have to clean up or in terminal cases rewrite. In a way all we've done (currently) is drastically expand the amount of technical debt across the whole industry. Should be profitable for the ones who can still actually program though and haven't let their skills atrophy by letting Claude do everything. I don't deny there are use cases for LLM's, I just don't buy the hype about them either. As with all tools, you have to understand how to use them to get done what you need to get done without sticking the chisel through your hand.
  - sigseg1v 12d ago
    But this is leaving out the part where the developers that clean up or rewrite... will do it using LLMs. Have you tried refactoring or porting codebases larger than a million lines of code pre-gen-AI and again post-gen-AI? It's night and day difference. One would be insane to schedule a team on 8 months worth of grunt work porting from one language or framework to another which can now be done by 1 person in 4 weeks. Of course the person driving it has to tell it exactly what to do and has to have the requisite knowledge to understand how to effectively structure or fix the software. Maybe new developers don't build this skill so easily anymore. But I don't see why a strong developers skills would atrophy in this case though unless they just never use their knowledge and never give instructions to the AI. To developers speaking of skill atrophy: are you still making sure that when using LLMs you are actively exercising skills like system design, debugging, reviewing for clean code and just in general doing effective code review? If you are doing that, why do you feel skill atrophy? And if you aren't doing it, why not? What about LLMs prevents us from exercising these skills?
  - budman1 12d ago
    2040. The demand for real programming skills will become infinite (again). someone who can actually read, understand, and debug code. when the clankers get stuck. unfortunately, there will be only be a dozen people.
throw839948499 12d ago
I am former java enterprise dev, so yes I often code this way. Unit testing, decomposition... Some projects CI refuse to merge commits with 20 line loop and duplicated code... But that is not a point. Claude can code tight compact loops, it just needs to be instructed to do so! If it does "enterprise code", it means it had no instructions about code style. If your documentation, spec, agent.md does not have proper guidance on coding style... yet another red flag!
- shakna 12d ago
  > it just needs to be instructed to do so! Considering how often it overrules, its own rules?
jjav 12d ago
> A twenty line for loop. It overengineers most things. Anecdote I like to tell.. I was working on a financial planning software, intentionally purely vibe coded as an experiment. I eventually discovered AI had implemented seven duplicate copies of tax calculation functions. All of them different. All of them wrong. All of them giving different answers for same input. Not even the most junior of newbie junior engineers would do something this crazy. But AI was happy to do it. It will solve the immediate problem, efficiently. Even if the most efficient solution is something ridiculous like this.
- UpsideDownRide 12d ago
  For some definitions of efficiency.
- ilija139 12d ago
  I have also a weird story to tell that a human did and it is as crazy as this. It happen in 2019 so no LLMs at all. A person that was hired as an expert in our startup spent more than one week full time working on implementing his solution to the problem we were having. I checked the code after one week to see the progress and was curious how they are implementing an already crazy sounding idea. I found that the whole week was spent re-implementing in python, python's built-in "float" function. That was it, the whole code was just that. Our problem was related to financial services and their implementation of "float" was not even correct.
  - lmf4lol 12d ago
    Jesus Christ... and then? What happened to him? What was the conclusion? Did he get paid?
    - budman1 12d ago
      of course he got paid. that is the deal for an employee, you put in the hours, you get a check. today, this individual is CTO- Vibecoding at Uber.
Foobar8568 12d ago
Oh and how is it any different than most software engineers? How many times I heard ORM are bad only to recreate the same shit? How many times I heard ORM had bad performance and see 1+n stuff everywhere? How many times I have seen tight coupling in the name of DRY?
- shakna 12d ago
  Its different, in that when you teach that engineer, they either leave because now they hate you, or they grow. They change to meet the standards of a project, rather than inventing their own. We don't get seniors, without juniors. I'd say more than half the job, is just... Learning. People grow.
  - spockz 12d ago
    Exactly. People ask how we get seniors with juniors using llm. The answer is the same. Review the code. Analyse write down what is wrong. What you expect to have been better. Force every change to be documented and explained enough.
    - orwin 12d ago
      It just takes forever now. The understanding is lower, the effort is lower, and frankly, I think the interest is lower too. I might be in the last generation who truly had fun working on a 'shrodinger' bug.
      - spockz 12d ago
        Yes. So find someone with intrinsic desire to engineer. Mentor them. In the mean time put a plethora of guardrails in place to make sure the AI Train doesn’t derail production. Oh. And keep showing your value. In the end every org can do with less low paid overeager uninterested juniors. Might as well let agents Do those tasks.
  - KronisLV 12d ago
    > Its different, in that when you teach that engineer, they either leave because now they hate you, or they grow. Or they just have their own hubris and ignore your (provably better) suggestions because their way is "better/easier/how we've always done things". And then you end up with someone sprinkling N+1 issues throughout the system and making systems with bad architectures throughout the years, not thinking about backpressure etc., as well as shoving ALL the dependencies into a single codebase cause they're not used to creating new ones, turning patches into eventual month long version upgrades because everything keeps breaking with anything newer than JDK 8 and some of the packages are deprecated and gahhhh I should pick up woodworking as a hobby. Though, to address the original claim: >> If it is a better engineer than you... You need practice. This feels like a thought terminating cliche. Like, it will spit out bullshit every now and then, and make assumptions that I don't think that many engineers would (e.g. since a lot of each app is environment-specific), but at the same time when you guide it and give it examples, it can really be quite good! So not that unlike humans at all, even competent devs might not necessarily know about every pattern in any given codebase, especially when one has been around for 10 years and grown quite a bit. It can be quite good if you have something like ArchUnit or your own tools for linting project architecture and patterns, alongside proper documentation that doesn't assume that you're a team member with X years of experience on system Y. AI just forces people to be less lazy and ignorant about knowledge transfer, which they should have also been for the sake of other humans!

by shakna 12d ago

raverbashing 12d ago

100% It is my pet peeve with Claude and why I don't prefer it for most stuff (also the comment spam - but that's a all of them in a way or another)

adjejmxbdjdn 12d ago

The funny thing is that if you never understand the codebase then you will keep thinking Claude is doing a great work delivering all this incredible software, when all it has done is created unnecessary tech debt.

noir_lord 12d ago
Which at some point the developers who actually still do know how to program are either going to have to clean up or in terminal cases rewrite. In a way all we've done (currently) is drastically expand the amount of technical debt across the whole industry. Should be profitable for the ones who can still actually program though and haven't let their skills atrophy by letting Claude do everything. I don't deny there are use cases for LLM's, I just don't buy the hype about them either. As with all tools, you have to understand how to use them to get done what you need to get done without sticking the chisel through your hand.
- sigseg1v 12d ago
  But this is leaving out the part where the developers that clean up or rewrite... will do it using LLMs. Have you tried refactoring or porting codebases larger than a million lines of code pre-gen-AI and again post-gen-AI? It's night and day difference. One would be insane to schedule a team on 8 months worth of grunt work porting from one language or framework to another which can now be done by 1 person in 4 weeks. Of course the person driving it has to tell it exactly what to do and has to have the requisite knowledge to understand how to effectively structure or fix the software. Maybe new developers don't build this skill so easily anymore. But I don't see why a strong developers skills would atrophy in this case though unless they just never use their knowledge and never give instructions to the AI. To developers speaking of skill atrophy: are you still making sure that when using LLMs you are actively exercising skills like system design, debugging, reviewing for clean code and just in general doing effective code review? If you are doing that, why do you feel skill atrophy? And if you aren't doing it, why not? What about LLMs prevents us from exercising these skills?
- budman1 12d ago
  2040. The demand for real programming skills will become infinite (again). someone who can actually read, understand, and debug code. when the clankers get stuck. unfortunately, there will be only be a dozen people.

throw839948499 12d ago

I am former java enterprise dev, so yes I often code this way. Unit testing, decomposition... Some projects CI refuse to merge commits with 20 line loop and duplicated code... But that is not a point. Claude can code tight compact loops, it just needs to be instructed to do so! If it does "enterprise code", it means it had no instructions about code style. If your documentation, spec, agent.md does not have proper guidance on coding style... yet another red flag!

shakna 12d ago
> it just needs to be instructed to do so! Considering how often it overrules, its own rules?

jjav 12d ago

> A twenty line for loop. It overengineers most things. Anecdote I like to tell.. I was working on a financial planning software, intentionally purely vibe coded as an experiment. I eventually discovered AI had implemented seven duplicate copies of tax calculation functions. All of them different. All of them wrong. All of them giving different answers for same input. Not even the most junior of newbie junior engineers would do something this crazy. But AI was happy to do it. It will solve the immediate problem, efficiently. Even if the most efficient solution is something ridiculous like this.

UpsideDownRide 12d ago
For some definitions of efficiency.
ilija139 12d ago
I have also a weird story to tell that a human did and it is as crazy as this. It happen in 2019 so no LLMs at all. A person that was hired as an expert in our startup spent more than one week full time working on implementing his solution to the problem we were having. I checked the code after one week to see the progress and was curious how they are implementing an already crazy sounding idea. I found that the whole week was spent re-implementing in python, python's built-in "float" function. That was it, the whole code was just that. Our problem was related to financial services and their implementation of "float" was not even correct.
- lmf4lol 12d ago
  Jesus Christ... and then? What happened to him? What was the conclusion? Did he get paid?
  - budman1 12d ago
    of course he got paid. that is the deal for an employee, you put in the hours, you get a check. today, this individual is CTO- Vibecoding at Uber.

Foobar8568 12d ago

Oh and how is it any different than most software engineers? How many times I heard ORM are bad only to recreate the same shit? How many times I heard ORM had bad performance and see 1+n stuff everywhere? How many times I have seen tight coupling in the name of DRY?

shakna 12d ago
Its different, in that when you teach that engineer, they either leave because now they hate you, or they grow. They change to meet the standards of a project, rather than inventing their own. We don't get seniors, without juniors. I'd say more than half the job, is just... Learning. People grow.
- spockz 12d ago
  Exactly. People ask how we get seniors with juniors using llm. The answer is the same. Review the code. Analyse write down what is wrong. What you expect to have been better. Force every change to be documented and explained enough.
  - orwin 12d ago
    It just takes forever now. The understanding is lower, the effort is lower, and frankly, I think the interest is lower too. I might be in the last generation who truly had fun working on a 'shrodinger' bug.
    - spockz 12d ago
      Yes. So find someone with intrinsic desire to engineer. Mentor them. In the mean time put a plethora of guardrails in place to make sure the AI Train doesn’t derail production. Oh. And keep showing your value. In the end every org can do with less low paid overeager uninterested juniors. Might as well let agents Do those tasks.
- KronisLV 12d ago
  > Its different, in that when you teach that engineer, they either leave because now they hate you, or they grow. Or they just have their own hubris and ignore your (provably better) suggestions because their way is "better/easier/how we've always done things". And then you end up with someone sprinkling N+1 issues throughout the system and making systems with bad architectures throughout the years, not thinking about backpressure etc., as well as shoving ALL the dependencies into a single codebase cause they're not used to creating new ones, turning patches into eventual month long version upgrades because everything keeps breaking with anything newer than JDK 8 and some of the packages are deprecated and gahhhh I should pick up woodworking as a hobby. Though, to address the original claim: >> If it is a better engineer than you... You need practice. This feels like a thought terminating cliche. Like, it will spit out bullshit every now and then, and make assumptions that I don't think that many engineers would (e.g. since a lot of each app is environment-specific), but at the same time when you guide it and give it examples, it can really be quite good! So not that unlike humans at all, even competent devs might not necessarily know about every pattern in any given codebase, especially when one has been around for 10 years and grown quite a bit. It can be quite good if you have something like ArchUnit or your own tools for linting project architecture and patterns, alongside proper documentation that doesn't assume that you're a team member with X years of experience on system Y. AI just forces people to be less lazy and ignorant about knowledge transfer, which they should have also been for the sake of other humans!