Cleaning up after AI rockstar developers
93 points by jesseskinner
93 points by jesseskinner
So not only do I have to clean up after the chatbot finishes whatever garbage it decides to dump on my head, now I have to clean up after all the people who don't bother.
Can't wait for the bubble to pop.
But it has always been like this, AI just amplifies the problem. You can also make the argument that cleaning up is easier.
if something makes an existing problem worse then that thing is bad. The fact that the problem existed previously at a lesser magnitude does not actually absolve the thing that makes it worse.
is cleaning up easier? LLMs are very good at generating code. in my experience, they are less good at offering workable, non-obvious solutions for refactoring and maintenance. i have seen some people argue they are useful for those things, but given the generative nature of LLMs, i suspect that it is an asymmetric situation where the people making things messy get a larger boost than the people trying to clean up.
I've used them for refactors and migrations that would be painful/annoying to do by hand. Mostly in cases where I knew what I needed to do (combine these two values that co-occur everywhere into one struct, split this 5kloc file up logically, etc) but sometimes I'll just ask Claude "hey, give me some ideas" and pick the ones that sound good.
e.g. I used it recently for "find all properties in our application config files that are unused, use the commit history to identify the commit that deleted the last usage, then generate a bunch of draft PRs that remove the properties from the config files, grouped by CODEOWNERS or by your guess for the team if CODEOWNERS doesn't help, with the link to the PR that removed them in the message". I absolutely could have done this by hand. It would have been mind numbingly boring.
thanks for the concrete examples! that does seem useful.
it’s not immediately clear to me that such assistance levels the playing field with respect to a putative “AI rockstar” from the OP—anecdotally, i see a lot more people posting “i wrote a greenfield project with LLMs” or “i rewrote an existing project with LLMs,” rather than “i simplified and cleaned up an otherwise nasty codebase with LLMs.” LLMs seem to be more readily useful for churning out new code than for maintenance. i suspect that, at industrial scale, realizing the potential maintenance benefits would require a lot of discipline.
edit: arguably my last couple sentences don’t put the case strongly enough… the status quo is that proper maintenance already requires a fair amount of discipline, it doesn’t come for free. my conjecture is that LLM coding tools require an even higher level of discipline if you want them to become a maintenance benefit, rather than a maintenance burden. cf. You Need AI That Reduces Your Maintenance Costs
I've used an LLM for refactoring ancient C codebases that are based around global variables, where I wanted to start off by moving all the globals into one giant GlobalContext struct and then plumb it everywhere.
It worked pretty well, it was able to catalog every global (including mutable static locals hidden in functions, preprocessor macros, and generated code) into a big document, generate the new type and it accessor functions, then spawn concurrent sub-agents to rewrite each subsystem in parallel. My input was limited to writing the initial skeleton of the context type + accessor functions.
The only part I found "LLM-like" vs just a regular deterministic refactoring tool is that it discovered a global named i and decided to dedicate a few sentences to writing a preemptive apology along with some indignation about the judgement of the original programmer. I thought that was pretty funny.
ha, that is funny. i can only imagine what commentary might be supplied for some of the more terse Haskell code i have written… probably enough single letter variables for Claude to go on strike over it.
There is not much useful advice in this article.
It feels like it's someone's pet peeve dressed up in two buzzwords to make it sound better. While I am always suspicious of "rockstar developers", terrific devs do exist. But they don't do what is described; they work within what's there until it isn't possible, improve the codebase as is, not play with new, untested things and leave the place better off and stabler when they do go through tests, scripted deployments, linting, etc.
And then "AI" seems bolted on to expecting this behavior to get worse. That's probably fair but it's assuming facts not yet in evidence as best I can tell. Having worked as a consultant off and on for decades, I too have cleaned up a lot of messy codebases, some times from people who got out over their skis, most times from teams that just didn't know a better way existed. In neither of those cases did I ever think, "Hmm, must have been a rockstar/ ninja/ buzzword developer".
The agent doesn't remember anything it did yesterday
Solvable problem - use memory approaches etc. Not universally good, but trending better
It doesn't care whether this code will fit with all the other code in the system
This tends not to be my experience - usually LLM generated code will tend to look a lot like similar code in related areas - basically whatever the code has read to get oriented.
It also doesn't care whether the system is becoming more understandable, or worse.
Solvable - use the LLM to judge this and ratchet down. Ironically an LLM is an easier approach to measuring this than other tooling as how easy something is to understand is a non deterministic property of a system (often). It's reasonable to ask in a fresh session "how much of the system does someone need to understand to understand this newly added code" and optimize that down.
The AI has a toolbox of best practices that probably don't apply here.
The process of using an AI will often be similar to training a junior that comes into a new project with those same ideals. With a junior you tell them verbally and then expect them to carry that knowledge and extrapolate. With an AI, you document it in an AGENTS.md / CLAUDE.md file and you have this forever.
When asked to review your code, it comes up with a long list of improvements, many of which you disagree with
Codex (which I'm more familiar with) is tuned to keep this list small, concise, and high value. YMMV with other models, but again, this is an instruction level thing. The things you care about often are worth documenting. Using AI makes this a necessary thing.
Legitimately curious, what is the recommended mode of behavior when you join a company, and discover that they are still using create-react-app in 2026? Just don't say anything?
If it's a new project, point out that it's now deprecated and no longer recommended.
If it's an old project, congrats you found technical debt. Everyone has it. The best way to argue for fixing this sort of thing is to make a good business case for it. Is it really a liability if it works? How does it stack up against other technical debt? What are the implicit risks taken by not upgrading this? What's the effort required to upgrade this? If it's low effort and your coworkers want this, another thing you can do is just do the work without asking for permission. This works best if you have buy in from the people affected by this change and it doesn't get in the way of your deliverables. Maybe not something you would do week 1.
Generally it's always better to ask questions and find out why things the way they are vs stating how things should be. Every code base with history is a reflection of thousands of decisions that you don't know yet. Arm yourself with knowledge and empathy.
Asking questions is so powerful. I’m often surprised by what people align on as needs changing but just isn’t the priority right now, versus what is intentionally not done because of business trade-offs.
When joining, I prefer to observe before pointing everything that should be done in a different way. There is a balance between changing everything when a new people join the team and focusing on what makes an impact. When joining, you don't know yet what makes an impact.
I like the WTF journal approach to this https://www.simplermachines.com/why-you-need-a-wtf-notebook/
Very interesting article. Can you recommend any other resources for learning more about this part of being a software engineer?
The Unwritten Laws of Engineering has a lot of helpful advice if you're starting out. I read the original 1944 edition, which is somewhat dated and sexist. This updated version should address these issues, though.
not sure what part do you mean by "this part" but for team dynamics / being strategic about where to put the effort in tech decisions, these come to mind: The Manager's Path, The Staff Engineer's Path, Choose Boring Technology, some of the stuff from Sean Goedecke.
It really depends on what battles you want to pick. Personally, I don't think it's worth it but I am not you. Legacy code is everywhere and the cost of rewriting away from frameworks like create-react-app is so much greater than just limping along with what people are already familiar with.
As a non-web-developer, what is the meaning of this question? That create-react-app or React is outdated?
create-react-app was the original tooling you'd use to scaffold out a react frontend if you didn't want to do it from scratch. It's deprecated now because there are better options.
I'm honestly not sure what those better options are. Next.js? That just railroads you towards Vercel and seems to have a lot of complexity that's counter productive if you're not Vercel.
I once tried to create a new React Native app (a slightly different topic, I know) and found that the old, deprecated solution was a nice-ish local thing and what the React Native docs tried to guide me towards was some company's product whose main purpose was to let you build your apps in the cloud (though it also supported building locally if you jumped through some hoops). There's a pattern here.
EDIT: I found it, it's Expo. A "full-stack React Native framework with powerful cloud services". Not exactly what I'm looking for when I wanna make an app.
I'm honestly not sure what those better options are.
Vite is one better option.
Next.js?
Yes. If you are building a web application, you absolutely should use a full-stack framework. I don't see any reason for creating a separate project for your client-side code and a separate project for your server-side code.
Vite is a replacement for WebPack, not for create-react-app.
Do you think so? I think that react-scripts is a build tool that conceptually equivalent to Vite. Is there anything that create-react-app can do that Vite cannot?
Vite is a build tool. create-react-app is a tool which sets up a whole project, using WebPack as a build tool.
I think that they are not conceptually the same. In this context, Vite's bundler "rolldown" would be conceptually the same as webpack. And you can use Vite to set up a project as well:
npm create vite@latest
Looking through the CRA home page, I think the only thing that CRA did that a combination of Vite and Vitest won't do for you out of the box is linting. Otherwise Vite comes with a bunch of preset project structures for different frameworks, handles builds, and Vitest integrates with all that for testing.
Yes. If you are building a web application, you absolutely should use a full-stack framework. I don't see any reason for creating a separate project for your client-side code and a separate project for your server-side code.
I think that having the frontend and the backend in the same repo is the correct decision (usually), but that doesn't imply a full-stack framework.
Any reason to ignore React Router 7? Asking since it's what currently pays my bills.
Isn't React Router now TanStack Router? That's just a client side router library, right?
React Router 7 is currently an alternative to Next, i.e. it has server side rendering and all the bell and whistles. It's the sequel to Remix v2. Remix v3 is an alternative to Next, but it does not use React even if it uses JSX.
TanStack is a full blown framework AFAIK.
And React Router handles compiling Typescript to JavaScript and bundling and all that stuff too? Weird name...
I don't remember the story by hearth, but IIRC by the time CRA was active, there was React Router and Reach Router, both client side. Then they joined forces to create Remix (v1 and v2). Later (as in recently) they decided to take different paths so React Router guys decided to go back to their brand and continue working on Remix code base, while the people of Reach refactored Remix from scratch.
React Router being a server framework is just an evolution of a well known brand.
I'm probably mixing it up with React Query which one day was suddenly just called Tanstack Query.
I think I’d approach this less as “CRA in 2026, yikes” and more as working out what it’s actually costing the team, what opportunity is being left on the table by not moving, and whether this is really the highest leverage thing to fix right now.
It might be a useful signal. Being that far behind on a fairly mainstream frontend tool can say something about ownership, maintenance habits, or how much the team keeps up with modern development practice. But it might also just be a stable part of the system that doesn’t change much, where nobody has yet had a good enough reason to pay the migration cost.
So I’d want to measure the pain rather than just assume it: build times, dev server speed, CI time, dependency update friction, security noise, onboarding pain, test setup weirdness, blocked React/tooling upgrades, etc.
There’s also a real value to lack of churn. Stable boring stuff that keeps working is basically free, while change always has a cost: migration time, regressions, edge cases, and all the cleanup you only discover once you start.
So I think the answer is mostly ROI. If CRA is actively slowing the team down or blocking useful work, then it’s worth making a small concrete migration plan. If it’s just old and unfashionable, note it as tech debt and spend the effort somewhere with clearer leverage.
I just want you know that I feel so incredibly validated that people hate CRA now.
I hated back in 2020 when it was still cool.
What an odd comment. CRA was a way for a beginner to kick off a react project without futzing with webpack configs, and is simply superseded now by things like Vite. It was never cool or uncool. Hating a beginner bootstrap tool, either in 2020 or now, is interesting.
Its's bad now, it was bad in 2020.
Anything that generates boilerplate is bad because it teaches the developer nothing and perpetuates the tool that requires that useless boilerplate in the first place.
The relevance of this comment on a submission about cleaning up after a technology that sprays text is excellent
Anything that generates boilerplate is bad because it teaches the developer nothing
I don’t know create-react-app. How does the boilerplate it generates compare to cargo init or uv init? Some boilerplate is good to automate and tiring to always write out by hand. But I don’t know how CRA is going overboard with it.
If it's been there for years, and it's working, then it's probably just fine for now. But start documenting the specific issues that it's causing. For a large application, maybe it's contributing significantly to the build time or reloads are slow when working on the project. Maybe having to work around CRA makes keeping dependencies up-to-date harder. Maybe you need SSR — I can't remember how well CRA supports that.
(I really like a good sprint retrospective for keeping track of these sorts of things. We used to have a column for things we found good in the sprint, a column for things we found bad, and a suggestions column. Stuff that consistently found itself in the bad or suggestions column was stuff that we needed to take seriously and consider fixing.)
Once you know what your actual problems are, not just the vague fuzzy feeling that the whole project is out of date, then you can try and fix those. How much buy-in you need to get using the documented problems will affect how this part works, but there's always the EAFP principle — it's easier to ask for forgiveness than permission. If you can work on some improvements in the background and then demonstrate that those improvements are genuinely worthwhile, then the cost to implementing them is basically nothing because the work is already done, while the benefits are clear.
i haven’t been in such a position myself, but here are options that stick out to me based on a handful of years in industry.
option 1) say nothing, keep your head down, accept that the decision is perhaps important to someone above your pay grade. work on best practices in your specific domain, hope that domain is not the create-react-app thing itself. ask for a change of team if it is. if that doesn’t work, either start practicing radical acceptance or looking for new work.
option 2) speak up, be prepared to defend your position. be prepared to accept a substantial amount of responsibility and ownership if you succeed. be prepared to politely accept it if you are shut down in the face of a well reasoned argument, understanding that this probably means the technical merits have been deemed secondary to some organizational or political issue. go back to option 1.
I can't find the link now, but I remember a blog post about how to onboard oneself into a new workplace: for the first weeks, just keep a list of strange things (both technical and organizational). Then, once you found co-workers with a clue, just start asking "hey why is $THING that way?" You might get a good explanation, or a "yeah we didn't get around to fixing this yet, be great if you could do it", or "hmm why is this a problem, could you explain?" In any case, you get to be a helpful, clueful co-worker in no time with that strategy :)
Along with the note about tech debt, read https://randsinrepose.com/archives/the-blue-tape-list/ and talk to your manager about the article too. Basically: make a list of the issues you see, but recognize that you night better understand why they exist once you're around a little longer (see also: Chesterton's Fence).
Half the issue with dealing with Rockstars is the ego, but at least with Rockstars that wrote human code, they had the introspection and intention to back it up.
Conversely, "Rockstars" that are a human wrapper over the AI have just as much if not more bravado while being entirely ignorant of half of even the problems they claim to solve.
Not all devs are created equal, some people are just more interested and better at programming, AI might just make it more obvious who the good devs were. It's hard to tell if the AI will benefit bad devs or hurt them in the long term.
I find you get a lot of leverage by apply FP approach to the fullest to make context free components that can be snapped together in different ways. As long as you separate the individual building blocks that abstract over implementation details from a specific context dependent tasks, then you can easily rearrange the blocks in a different way when your requirements change or you decide on a different approach. Another benefit here is that you can reason about these pieces in isolation without needing overall context of how they're arranged. And then you can look at the way you snap them together to understand the high level logic.
Functional languages provide a really good foundation for working with LLMs because they make it natural to write code in a way which restricts context. And that helps both the model and the human using it by limiting the scope of what need to be understood about a particular piece of functionality in a program.