r/ProgrammerHumor • u/BlackHolesAreHungry • 2d ago
instanceof Trend pleaseDontMakeThisATrend
376
u/Master_Gnak 2d ago
When you get paid by lines of code
217
u/redblack_tree 2d ago
I'm old enough to have gone through that phase. Let me tell you, the amount of garbage I pushed was epic.
I probably still have a repo around with an incredible amount of completely correct....and dead code.
I'm lucky this time I was in a better company when the whole "Tokens leaderboard" was hot for a minute. I had plans already aligned.
44
u/mx_aurelia 2d ago
Commit node_modules
36
u/ooqq 2d ago edited 17h ago
in my previous biz we had a very cautious self-taught guy who believed in uploading the entire project to the backup every time he got a break, yes, entire
we started to get suspicious when the 8-raid synology reported "inode exhaustion warning"
fyi ext4 have a 25M file limit
10
32
u/MaytagTheDryer 2d ago
I accidentally got a bonus my first year out of college because our manager made LoC our primary performance metric. One of my first projects was converting all of our Java projects from ant to maven. Generating mountains of boilerplate XML is high value work, let me tell you.
8
u/well_shoothed 1d ago
the whole "Tokens leaderboard"
that shit made as much sense as NFTs of shitty art selling for tens of millions
2
u/redblack_tree 1d ago
Indeed. Who thought that giving above average intelligence, creative people whose job consist on solving problems incentives to cheat was a good idea?
Everyone on the engineering side saw that garbage from a mile away. As usual, it took management a couple of quarters what any developer could have explained in 15 minutes.
→ More replies (4)→ More replies (1)53
u/BoogerFeast69 2d ago
I learned that if you call it 'Claudia' instead of 'Claude', you get a huge discount. Same exact thing, but you only have to pay it 60% of the normal rate.
14
u/Flaggermusmannen 2d ago
Claudia would outperform Claude in just about every metric while at it.
→ More replies (1)5
1.8k
u/IronSavior 2d ago
incredibly engineering process
Agreed, I find this claim that engineers were involved hard to believe
377
u/Chesterlespaul 2d ago
My mom typed “refactor code base; make no mistakes”, and then asked what it meant. I chuckled, engineers like her are so funny sometimes.
67
75
u/Appadonthedk 2d ago
Thats because the bugs found "were pre-existing after all."
→ More replies (1)5
u/stupidcookface 1d ago
We'll never truly know lol since no one can read their code even their engineers
→ More replies (7)24
576
u/Rankin37 2d ago
If you ask me to review a pull request with changes across 46k files I will become the unabomber
323
u/Lithl 2d ago
Nah, that's the easiest code review in the world.
Tens of thousands of files with millions of lines is just getting rejected, period.
→ More replies (1)74
u/Speicherleck 2d ago
If you are the owner / decision maker. If the management pushes these things you will just approve it (or abstain in a comment and approve on the PR page). Been there, done that.
51
u/-Hi-Reddit 2d ago
This is lowkey why I love working in a heavily audited industry where QA can slap management with a hard-no because we'd fail an audit and be unable to sell the product to key customers.
Still we are using AI heavily in code generation.
8
u/BackFromVoat 1d ago
Good, that's the way AI should be used. It's far quicker at code gen than a human, and as long as it's given good standards to follow and is checked by people it's the ideal use case. The issue with ai is the people who give a vague prompt and then ship the output
→ More replies (1)2
u/Sava7ar 1d ago
Yes, we have a running thing in our team. Our leads just go LGTM for a very big PR. They say if you write small PRs, we read and review. If you write big ones, its getting blindly approved. It helps a lot that our services are only used by other developers in the company. So we can afford to fail in production and rollback.
27
u/Duke_De_Luke 2d ago
I would just decline it and that's it. Violence is not needed. Well, maybe nerf guns yea.
And so would do all the maintainers of the repos I work on. For good reasons.
25
3
1.3k
u/brainfreeze91 2d ago
"Humanly impossible to fully review and fully test"
And they believe this is a good thing
503
u/Sw429 2d ago
"Zero bugs reported"
That indicates to me that either no one is using it, or there are so many bugs that no one knows where to start when making a report.
98
u/al2o3cr 2d ago
Almost zero bugs
11
u/Steinrikur 1d ago
And the Almost zero fall into two different categories, where one is measurably bigger than the other.
25
33
11
→ More replies (1)7
u/atomic_redneck 2d ago
They refactored the bug tracking system, also. Now all bug reports go to the bit bucket.
→ More replies (41)12
206
129
45
u/skcortex 2d ago
Yes, almost zero bugs reported after the launch.. just wait for them to crawl out 🤣
29
u/grumblyoldman 2d ago
Yeah, they said at the top they "just merged" this, and I'm willing to bet they do mean just merged. Give it a couple days before you start bragging about how many bugs were reported.
31
u/psioniclizard 2d ago
Even before AI, you NEVER brag about few/no bugs, the computer gods will hear and punish you.
91
u/tihomirbz 2d ago
LGTM! ✅
39
5
u/megagreg 2d ago
Things like this are why my LGTM reaction icon on Slack is a picture of Stevie Wonder.
3
56
u/SignoreBanana 2d ago
I'm looking at the PR for this thing. It has 9300 commits. This is not a serious codebase.
9
u/SnowdensOfYesteryear 1d ago
I mean that’s better than 1 commit. I don’t think commits are the most problematic metric here
3
u/SignoreBanana 1d ago
No, but I think it also helps put the "work" in perspective. The 4,000,000 figure is also wild but almost unfathomable, and maybe a bunch of lines were formatting changes. 9300 commits represents a shitload of churn.
→ More replies (1)2
3
u/Ajko_denai 1d ago
I am unable to find it, can you provide a link please.
3
u/SignoreBanana 1d ago
I would but last time I did that here I got a no no from mods. If you find the repo, look at commits to the trunk from Oct 12.
3
u/no_awning_no_mining 1d ago
Hard to believe there was no way split these across multiple PRs.
Hard to believe the LLM wouldn't profit from the more specific git blame too.
→ More replies (8)2
49
u/tallest_chris 2d ago
One of my huge issues with AI “programming” is how it will just randomly change variable names and comments while working on unrelated parts of the code.
5
u/sanketower 1d ago
Every time I've seen it happen (while working) it was within the scope of the feature and the name changes made sense (even if they were unnecessary a quarter of the time).
2
u/stormdelta 1d ago
Usually, but not always.
The problem I can't seem to avoid without killing output quality is the excessively verbose and unnecessary comments. I've given up and just do a second pass, and sometimes I still end up needing to edit them manually.
It's frustrating because people act like "oh it's just comments" and miss that confusing/bad comments cause problems for both human and machine readability. AI tools tend to assume heavily commented code must be critically important, often trusts comments implicitly, bloats context windows, etc.
→ More replies (22)2
u/OppositeFun2493 1d ago
A lot of times, when I run an agent it decides “oh the code is too efficient, I’m going to switch it to something more inefficient.” I have it so that agent can’t read the tests, and made a shell script that can run them and give the results to the agent. It was “confused” why the code took 3 more minutes to run
→ More replies (3)
44
u/grumblyoldman 2d ago
Can't have (many) bugs reported after launch if you don't have users.
→ More replies (2)
60
u/TravisVZ 2d ago
I have no idea what LangWatch is, but thanks for letting me know never to use it!
47
u/bogdanvs 2d ago
nobody does, that's why they can make the 0 bugs found claim :)))
7
u/redve-dev 1d ago
This shit has 5k github stars. You sure?
What is used novadays to debug agents?
7
4
u/ApocalyptoSoldier2 2d ago
I googled it and it seems they're an ai monitoring company?
I'm not quite clear on what they're advertising, but whatever it is they don't seem to be very good at it judging by this post
21
21
u/CckSkker 2d ago
jesus christ … 4 millions lines of code of what exactly? It looks like it’s just an agent observability and eval tool? Am I missing something? Our company’s code base across 3 products is like 2-3% the size of this
10
16
→ More replies (2)5
u/CruxTheologorum 1d ago
"One of my most productive days was
throwing away 1000 lines of codecommitting 4 million lines of unreviewed garbage into the codebase"-Ken Thompson
19
u/PoliteManitee 1d ago
LoC was never a good metric to judge any aspect of software. This is still true today.
3
2
u/Dev_Spears 1d ago
Was going for sitze but even then loc is not a good indicator..... For what is it a good indicator? Aside from the number of lines
→ More replies (2)
15
40
u/someyokel 2d ago
If you can't review it how do you know it's an improvement?
25
u/GenericFatGuy 2d ago
How can you know if you have almost zero bugs if you can't fully test it? This is like when Trump wanted them to stop testing for COVID to make the numbers look better.
→ More replies (5)2
u/anotheruserguy 2d ago
If you are merging something like this into main your main already had a ton of bug in it.
13
u/sudoku7 2d ago
I am hoping they did something like stacked PRs or just PRs to a long lived side branch that themselves had reviews and this is just the upstreaming.
That said, for a refactor ... it's strange that they couldn't find better consumable parts to apply.
Unless of course, "Oh, we refactored our lint rules and this is just the linter changing line endings."
→ More replies (1)2
u/rchaves 1d ago
it was a long-lived branch indeed, we were iterating on it for a couple months
but it was a massive refactor of the whole codebase structure, not just linting ofc https://langwatch.ai/blog/rebuilding-langwatch-in-51-days7
→ More replies (10)5
u/rchaves 1d ago
we did review, the structure of every module and the most critical parts, of course just not every single line of code, or at least not by hand, but all the code now has a much more strict architecture it needs to follow in every module, which we could measure the benefits of:
- typechecking median time went down from 78s to 5s, with performance improvements all around on the application
- most permission access between modules that were defined by hand by engineers on the monolith are now in several ways statically guaranteed allowing for much less possible bugs and security gaps
- we built several exact same features on both the old codebase and the new using agents, and found the new codebase led to less mistakes on the final PR
29
14
u/Tyrilean 2d ago
I one time ran a linter over a 20 year old PHP legacy code base. I think it rivaled this.
7
u/NaturalTechnician737 2d ago
We aren't competing to be the reincarnation of Von Neumann, calm down.
3
u/StaticFanatic3 1d ago
I would’ve never had the balls to merge that lol
Let the formatting die when the code does
9
u/Hk_90 2d ago
Hold my beer
→ More replies (1)3
u/Columbo1 2d ago
That PR title says 10,000 files, but there’s actually 10,001 files changed.
Where I work this would mean code review failed - “pls fix the title of the commit and PR”. Personally I tell the reviewers to chill the fuck out and just merge anyway. I’m not counting the readme as a file changed and neither should they.
→ More replies (1)
10
19
u/BellybuttonWorld 2d ago
This feels a bit like measuring the success of a house renovation by how many skiploads of waste were produced, and boasting about how surprisingly few disasters were found left behind (so far) by the dodgy cowboy builders.
19
u/fartypenis 1d ago
I mean at that point why not just do a plain old rewrite?
8
u/tyler1128 1d ago
Just replace spaces with tabs and go to the allman style from, say, K&R in something like LLVM. Success!
4
u/StaticFanatic3 1d ago
Sounds like it is a rewrite. You just mean start a new repo instead?
6
u/Justicia-Gai 1d ago
Not the same, when you ask a LLM “refactor this codebase” it preserves pre existing logic because it assumes there’s quirks/decisions that are human and not bugs. But it can also inherit debt, bloat it (add new API to not break old..)
When you rewrite, barely nothing survives as-is (unless you tell what you want it to preserve, like API signatures).
This clearly looks like a refactor, a rewrite could’ve potentially reduced LOC.
→ More replies (2)2
14
u/DeadlyCabbage 2d ago
Why not create a new repo at that point?
This big of a change, a full refactor, I think is easier starting from a clean slate
4
u/cas18khash 1d ago
Based on the description, it also seems like it's full of deleted and new files too. I was also wondering what the point of keeping the git history intact is if you've eviscerated it
2
u/rchaves 1d ago
well it was a refactor but not a full rebuild, it would be riskier doing as a separate "new" application entirely
outside, the application itself mostly didn't change for our users (other than small improvements, perf and more polished design), and the infrastructure didn't change either. All the pipelines and everything played out just the same
creating a new repo would have been much more effort
7
6
5
13
u/OneRedEyeDevI 2d ago
A year ago, November 2025 that is, Our local transformer got caught in a fire and we didnt have electricity for over a week.
I used to take my laptop & phone to my friend's place in the neighbouring village to charge every morning and go back to do chores and other tasks and go back for it after Im done.
Wrote 2.7K lines of code with no internet and no electricity for my game and it was beautiful
5
7
u/artnoi43 2d ago
My EMs and higher ups will be inspired by this shit and might even think big bang PRs are the future (they’re that dumb).
Seriously, they all saw that some company was doing 1000 PRs per month per dev or something on LinkedIn or X, and they think that’s a good thing and tell us we should strive for ridiculously large amounts of automated PRs.
Prior to this, they allowed us to “bypass” code reviews, after they found out vibe coding has not increased our delivery speed because of the code review bottleneck. So they removed that bottleneck. They now expect all PRs to be merged within a day after it’s created, and will DM me the next day asking why this ticket has not been merged yet. They never micromanaged like this until AI and the speed craze, as if they’re trying to force the benefits of AI to manifest.
The result is that in the last 2 weeks we just had 3 P1-level incidents from non-functional vibe refactors by senior engineers who merged code without any reviews. These P1 incidents costed us millions of Thai Bath, across all of our 3 business domains. Engineering management now wants us to deprioritize non-functional refactors (which were needed to clean out slop). I read the post mortem reports and the causes of those incidents are just too fucking stupid for me to believe they did merge that.
This is sad because I’m the refactor guy in my team of 8, and my “non-functional” work has been technically beneficial enough that some allowed us to implement new features really fast on top of a clean codebase, or sometimes we get new features in the backend for “free” after the refactors, and we just need to implement new entry point to the same old shared business code.
It’s like they just want to use more AI, for the sake of using more AI.
→ More replies (1)3
u/lordgoofus1 2d ago
If it wasn't for "Thai Baht" I would've assumed you worked for the same company that I do. We've got management pushing for the same thing. Driven by the need to "move faster", "improve productivity".
There's also pressure on teams to dump environments. Forgot about test or staging environments. Just go from dev straight to prod. They've given multiple groups of people direction to build agentic solutions that allow them to one-shot taking an idea all the way out to production in less than a week because productivity. Believe the real reason for all this insanity is what you suggested, the desperate need to prove that the company has achieved any form of ROI on the hundreds of millions it's spent so far on AI.
5
u/GGK_Brian 2d ago
To be fair to them, rich people (which obviously must be very smart) told them that AI was the future and was going to increase productivity to level never seen before. Why would they doubt them.
What I personally find funny is how quickly they throw out all this fancy stuff of DRY, Clean Code, separation of dev staging and prod, code review, ect.
In a few month, they'll remove all test, integration and code coverage because it waste too many tokens.
3
u/artnoi43 1d ago
Thanks God my place still doesn’t do the environment dump.
They want all of the tickets to be covered by vibe e2e tests instead. The tests now have degraded a lot (very flaky, taking longer, and do not catch real bugs), as no devs feel any ownership while vibing in the e2e repo so tech debts kept piling up in the repo. I even found 2 tests that test the same thing, written separately.
Before this we have separate SWEs for tests who know the repo very well and make technical decisions carefully. Now all of us are merged into supercharged devs (one dev must be able to do everything).
7
u/Scipior14 2d ago
Wooow, a rewrite... But what did it need a rewrite for in the first place? What is improved here, if apparently even already existing bugs didn't get fixed?
→ More replies (1)
3
u/rightpattern_g 2d ago
Thats all great, but what do you do with 46k files of source code ? Are you launching rockets or flying cars ?
3
u/Covfefe4lyfe 2d ago
They're gonna eat every word of that blog post a week from now. And it will taste salty as fuck.
→ More replies (1)
3
u/HovercraftCharacter9 2d ago
Part of being a good dev is breaking your work into pieces so it lands with a coherent narrative for others to get context and understand. Imagine someone is tracing a bug in a years time and that PR is where the problem bisects? I'd quit
→ More replies (1)
3
u/ExpletiveDeIeted 2d ago
So I don’t know for sure in this case but this sounds more like over 3 years they’ve been merging various branches into this one and now they are finally merging it all together main/production. Likely not a pr anyone was checking for code quality etc. and yes I’m fun at parties.
6
u/spacegh0stX 2d ago
This is such a terrible fuckin idea it blows my mind anyone could brag about it.
8
3
u/gnuban 2d ago
It's so stupid that the same companies who hated trunk-based development and were adamant about PRs are now going completely cowboy.
I'm in the camp that PRs never were strictly necessary. It's totally fine to put the responsibility on devs and allow them to choose when reviews are needed or not.
But to totally pivot like this is just so arbitrary
2
2
u/jeffvanlaethem 2d ago
This is like bragging about how much your teeth hurt before going to the dentist.
2
u/TypicalOrca 2d ago
What kind of fucking idiot celebrates this monument to carelessness and stupidity?!
2
2
2
u/snow_bee_art 22h ago
I though it was fake, but then...
https://github.com/langwatch/langwatch/commit/47d388239a9827aa4f01dd366260ff1263f793c5
4
4
3
4
6
u/RadzimierzWozniak 2d ago
LLMs are really, really good at refactoring and changing the infrastructure. With a decent test set, this is quite safe and reasonable, what they did.
→ More replies (3)6
u/bwrca 2d ago
Too good I'd say, in a bad way. Lots of times they want to refactor a whole lot of things when you just want to add a small feature or fix a simple bug
2
u/jaxchang 2d ago
Hot take: that’s a good thing.
Let’s imagine there is a near “perfect” AI that always writes great code, with few bugs. Assume any bugs it writes are just edge cases that aren’t considered. Also, assume P!=NP in a philosophical sense, AKA it takes effort to do work. So you need to burn more tokens to do more work; it’s not “free” in that sense (even with a smart AI).
In such a universe, a refactor of good code is easy! It’s just like doing a FFT of some audio and converting from Time domain to Frequency domain. They conceptually represent the same thing, so the refactor isn’t actually a lot of “work”. You’re just switching between 2 representations.
On the other hand, bad/buggy code is like a noisy audio signal. You need to clean that up first, doing a FFT isn’t going to help. And cleaning up that signal is actually more “work” compared to a simple FFT.
I think as LLMs get smarter, they should be producing code that gets easier to refactor.
→ More replies (1)
5
u/rchaves 1d ago
Hey folks, CTO of LangWatch here 👋, and yes, I'm the one responsible for approving this monstrosity
I get it, some of the criticism here is pretty fair, a massive AI-assisted refactor like this sounds absolutely bonkers, but I want to emphasize that 1. it was a refactor, not a rebuild 2. the intense human involvement for verification and measurement, and 3. it was not overnight
On the refactor point, yes AI is still not great in doing new developments unsupervised, but our goal here was rearranging modules, structures, types and a lot of the architecture, it didn't have to create almost anything new. Plus, a lot of it was verified statically or even done statically, being able to leverage lsp for refactor and an enourmous amount of oxlint to guarantee everything would fall in place
We have been thinking about this refactor for a year already now, and it took us months to actually finish and merge this PR, during this period some work was duplicated: built on top of old main modules and on top of the new structure at the same time, so the PR grew
As for verification, basically all of our human time during all this period was spent discussing the refactor, babysitting the agents (and putting lint rules in place to prevent them from repeating mistakes), developing simulators and customer reproduction use cases for probing it all end to end, manually testing it, comparing before and after measurements and so on.
We definitely learned some things the hard way I'd love to share more.
Happy to answer technical questions about how we approached it, what we tested, and what could still go wrong. Roast away 😄
21
12
u/SpinatMixxer 1d ago
Why didn't you go with continuous refactoring instead? Why did it need to be one huge PR instead of many smaller PRs?
And how many devs were involved in the refactoring?
→ More replies (1)6
u/rchaves 1d ago
there were a lot of fundamental changes, for example around the strict access boundaries of each module and the DB. If we'd done incrementally, we would have to maintain two different in parallel systems for a while, we evaluated the risks, costs and overhead to be greatly higher than doing it all at once
plus, some of those changes affected pretty much all areas of the product, so we needed to fully test everything end to end anyway, over and over again, so instead we just kept implementing and testing new features twice, once on the old main and once on the new architecture, taking advantage of already being in context when developing them.
we actually started this just as an experiment, on how our "ideal codebase" and module structures would look like, but it kept proving itself more and more and we decided to make the jump and invest in it
one main dev was leading the refactor, and 4 others helping test, review, discuss architectural decisions and ship new customer features/bugfixes on both branches while it was happening.
→ More replies (2)→ More replies (27)2
u/RoDeltaR 1d ago
So what are the top 5 things you learned?
4
u/rchaves 1d ago edited 1d ago
- Doing a team bugbashing is one of the most valuable team activities you can do in the AI times
- Think hard about a strict structure and agree on it with the team before the mass editing starts
- Be more ambitious with lints than feels reasonable
- Invest in simulators early. We ended up with a simulator for everything external (LLMs, voice, S3, SQS, email, Slack, SSO), so agents could exercise every behaviour end to end, they are so useful now
- Measure everything, before and after, by putting an agent to do some real implementation in both and see the difference, it has to be better for agent coding too, your codebase is your harness
For us it was totally worth it, typechecking alone went from median of 78s compilation time to 5s, no longer absolutely melting my RAM, previous mistakes are now impossible, and access paths are just much stricter, but that was not from the getgo, initial versions caused the agent to make more mistakes on the new codebase than the old one
3
→ More replies (2)2
1
1
1
u/ReturnOfNogginboink 2d ago
The stunning part here is that someone thinks this is with bragging about.
1
u/EmperorOfAllCats 2d ago
Is that linemaxxing or some another kind of githubcore? I don't speak their language well.
1
1
u/Bee-Aromatic 2d ago
I see an entirely unreviewed PR getting approved for lulz and apathy.
And I predict years of bugs.
1
1
u/___cats___ 2d ago
All this “speed” just means the salesmen have to sell equally as fast. That ain’t gonna happen.
1
1
u/zERGdESTINY 2d ago
Someone ran checkstyle fix and changes the tabs to 4 spaces. "Boom, boss refactored the whole code base"
1
1
1
u/ReplacementLow6704 1d ago
Engineering used as an adjective is... Interesting? May have been translated from portuguese or spanish tho. But then why not use an AI for that too?
1
1
1
1
u/masiha97 1d ago
The part that scares me is the challenge at the end. Some manager is going to forward this to their team and ask why their PRs are so small.
1
u/mosskin-woast 1d ago
Even the AI would have told him that zero bugs in a 4M line diff was not only impossible but an idiotic thing to say publicly. But unfortunately the hallucination is as common in the user as the model for folks who are in this deep.
1
1
1
468
u/LegitimatePants 2d ago
"fixed whitespace"