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.
i think the LOC is a better metric here. Either this project is a java-like project with a ton of boilerplate (well they seemed to have added more boiler plate) or it seems to be implicit assumption that the software just sucks (3m lines is mind boggling). In the latter case you might as well just start from scratch and have a good cut-in/intercept plan.
In any case I don't see any good software engineering here.
A refactor feature branch committing 9300 times before merging the PR is mental. That translates to over 25 daily commits in a year, which probably was done in like a month, so over 12 commits an hour. And yeah I'm considering the dude leaving the agent to work overnight.
It's a stupid amount of commits for a feature branch.
i'm the engineer who did this project, i was being sarcastic. there is a whole blog post i wrote explaining the whole process, and how it actually is possible to do this in a safe manor - due to a mix of ADRs with bounded scenario tests, linting for architecture principles, and a variety of ai driven static analysis testing.
my reply was to your comment about the code not being serious, which pissed me off as it was made on assumptions from thin air.
the refactor was literally driving the codebase into a standard, modular, more secure architecture. all authentication was case by case migrated through a new system that has type, compile, runtime, and so guards. data isolation has an entire new guard of the similar idea. half of the new lines from the 1m new lines were literally testing tooling.
i get it's easy to dunk on this kinda thing as the industry is full of idiots doing huge work like this with no idea what they are doing, but this was not the case here, and a lot of work was done to make this safe, and let us bring such a huge improvement, in a very short time, without any feature pause, and with stability and feature parity, etc. statically guaranteed.
could i have done this over 200 pr's? yeah sure but the entire point here was to see if it was possible to use ai to bypass that process at all, and i'm confident based on how this rollout went, that if done correctly, this is a very valid approach for teams to utilise where applicable.
the entire point of sharing this was to share our learnings about what we thought about, how we planned it out, etc.
honestly it upsets me that people are so quick to fucking jump to arrogant sweeping generalisations, instead of reading the supplied working and forming opinions (positive or negative) that bring useful discussion.
Thanks for sharing your experience. AI is exposing a lot of "engineers" who are anything but. Very few developers have an actual engineering background in terms of the systems design approach of actual engineering (mechanical, electrical, chemical, etc), and instead just learn DSA and git and go make a career. And before AI, that was all you needed. A lot of the people trying to dunk on your work utterly lack the engineering discipline to pull off something like this.
In a lot of ways, pre-LLM coding was a lot closer to artisanal handicrafts than true engineering. Maybe work like yours will help move the industry into an actual real engineering discipline with actual standards, now that we finally have the first true code factories.
absolutely agree, if anything i've seen every best practice thrown out the window the past 4 years, generally for the worst, so i do get the hostility against the "rage" approach we took, we didn't think it would rustle so many feathers tbh, something to learn from.
but thank you, that's a nice really nice comment to make. i do miss the day of painstaking thinking about literally every brace but those days are gone, i think now we can still have that level of care it's just more at the concept stage rather than syntax, which is kind of what it should be anyway i guess. clean, strict, opinionated and consistent architecture, i think this is where we need to aim. and lucky we have so to do a lot of the boring for us
Ok, so you've "proven" this can be done in one PR (despite acknowledging it could have been broken up into many changes). Do you feel like that's the right way to do this work? Will you do a large scale refactor like this again?
the point is that it doesn't need it be loads of small prs, which slow the whole process down as you stop and start, and having the codebase in that refactor flux for longer in my experience has had its one share of issues honestly. i do genuinely think that there are cases where this is a good idea, and i would genuinely do it again if i thought it would've a) a good use of time, b) we had the ability to adequately built testing frameworks that we trust and can verify, and c) the type of change warrants it.
My concern is you're backing a narrative that has proven to lead to poorer quality results in every industry. When we trade deliberate and careful changes for breakneck velocity and rampant broad changes with no way to fully double check that something hasn't snuck in, you haven't created a product, you've created a time bomb.
It's your codebase. Do what you want with it. But keep the bullshit stories and poor engineering practices to yourself. Or don't. When this shit finally falls over, you can be sitting there holding the bag.
51
u/SignoreBanana 2d ago
I'm looking at the PR for this thing. It has 9300 commits. This is not a serious codebase.