Live data from Hacker News

Cleaning up after AI rockstar developers

codingwithjesse.com

121–130 of 401 posts

Re: Cleaning up after AI rockstar developers

#121
> Sometimes there's so much technical debt that it can never be paid off.

There is no such thing as technical debt in the age of AI. It's just a series of migrations that take minutes to come up with.

I migrated from two disparate databases using AI and it took minutes for it to write the migration code. I had it double-write the data, and then I told the AI to write code to compare between the two databases, and I then tested over the course of a week.. I fixed some small bugs, or more precisely I told the AI to fix the bugs and it did.

Then once I was satisfied, I switched it so that the new database was primary and the previous database was secondary. Then I tested to make sure the data was still in sync. Then I switched off the previous database, then I removed all traces of the previous code.

It was simple and relatively quick. The thought that there exists technical debt in this age is absurd. One person can do things an entire team used to take in a fraction of the time.

Re: Cleaning up after AI rockstar developers

#122

The first few sections hit me. I think that I used to be a “rockstar”, until I realized it wasn’t a good thing. Perhaps I could get things done 10x faster than my colleagues. But at some point I realized it wasn’t because I was 10x more productive than a normal person; it was that I worked in a way that made the normal people around me 1/10 as productive. Since then I’ve slowed down. It’s been an overall positive cha…

I've definitely shot my own foot off in the past by implementing things in a rockstar manner. In my case, it typically involves me over-abstracting something that really doesn't need it. Or building something for use-cases that never actually happen. So I have to try to keep YAGNI and KISS in mind whenever my mind wanders into over-abstraction territory.

Re: Cleaning up after AI rockstar developers

#123
The job when picking up a codebase made by human or machine always involves reverse-engineering the design intent from code. That's especially hard for LLM-generated code because the path to runtime was so rushed.

> It's more expensive to fix code at runtime than at compile time and at compile time than at design time. Unfortunately, AI rushes people to runtime as fast as possible.

https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-co...

Re: Cleaning up after AI rockstar developers

#124

Earlier quoted context omitted.

But... "time to market!", "we won't have cash by the time this gets implemented properly" etc etc are the usual suspects here.

Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame. I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a pr…

It’s not about pristine software. Customers expect something that works. But changes will then be requested and the expectation is that the software will continue working. It’s hard to do that with janky code.

If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.

Re: Cleaning up after AI rockstar developers

#125

I like fixing code made by AIs and others (outsourcing code is similar as someone else said already). Last week we found out some client tried to vibe some departmental tool; the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on. Now we have to fix it: its basically free 10k-50k euros over and over again for this type of work. V…

How much would it have cost to start from scratch?

Most devs will say less, but the reality is most of the time you build the wrong thing first, and the price you quote almost never gets what the client wants/expects and includes many overruns.

Every single contractor will say: that never happens when I do it...

This is a better solution for many businesses.

One, they already have a steaming pile of crap that kind of works. Forking that over to someone to "fix" for €10-50k is a steal - even if there's a decent chance they deliver nothing valuable.

You're talking about on the low end a few weeks of a dev's salary. You get next to nothing for that most of the time...

You could easily spend 4-5x that, take 3-4x longer and get something you can't use at all.

Happens all the time.

Re: Cleaning up after AI rockstar developers

#126
post #91

I think this is fine? Code used to be very expensive to generate, now it is cheap. Building glue logic between well-defined, well-documented APIs has never been easier or faster. There is a time and place for throwaway code that quickly automates a task. It is fast food to fine dining -- not everything needs to be a Michelin star experience. However, as always, AI usage is a matter of taste. Including your style rule…

I think an important caveat is that LLMs are prone to writing unnecessary code, i.e. there's almost a superfluity to it, that at the same time makes it less straightforward and more prone to unnecessary side effects, which it does catch and handle, but that again expands code further.

Then you add an agent that goes through the code and simplifies it. Before every sprint, you get the agent to simplify whatever it can without losing fidelity.

It's really that simple.

Re: Cleaning up after AI rockstar developers

#127
post #123

The job when picking up a codebase made by human or machine always involves reverse-engineering the design intent from code. That's especially hard for LLM-generated code because the path to runtime was so rushed. > It's more expensive to fix code at runtime than at compile time and at compile time than at design time. Unfortunately, AI rushes people to runtime as fast as possible. https://www.slater.dev/2025/09/abou…

One of the things that annoys me is that we could know what the original intent was, and indeed the preferred form for modification: the prompt! Yet for some reason there's no standard/tradition/expectation that people commit all their prompting.

Perhaps I should start trolling people that your software is not truly Open Source if it's not Open Prompt.

Re: Cleaning up after AI rockstar developers

#128
In my opinion the problem rather is that most managers do not value elegance of the code, and most programmers are either too obedient or too clueless to dissent to management. Also, most team members don't want to understand highly elegant code and its inner beaty.

If management and teams would instead value highly elegant code structures over lots of "spewed out" code lines "that (superficially) implement a feature", I would bet that the problem discussed in the article would be much less of an issue.

Re: Cleaning up after AI rockstar developers

#129
post #96

Earlier quoted context omitted.

I think you misunderstand why tech debt lingers around. It's not a capacity or capability problem. Organisations just don't want to deal with the accountability involved with "touching cold code". Whether it's a human or "AI agent" doesn't change the "It worked in prod, you touched it, you broke it, never touch anything again" dynamic.

That's one dimension of it, but in the context of this thread we are talking about how maintainable a codebase is for other humans. If your codebase is messy you depend on a few key employees and it might be hard to onboard new ones, so there has always been financial incentives to reduce tech debt.

> so there has always been financial incentives to reduce tech debt.

Yes. In practice, this does not weigh against organisational resistance.

AI really makes it worse by adding an explicit numerical cost to doing anything.

Re: Cleaning up after AI rockstar developers

#130
post #14

As much as it's true that a novice will generally use AI to build a sloppy mess, I've also had success unsloppifying through some careful prompting.

Any tips on how you unsloppify things? Are you using things like claude.md/copilot.md (or similar) to guide better, do you have specific types of prompts that you run, or do you adjust your code review practices in some way to more efficiently review lots of slop code?

One of my particular complaints is how code-gen LLMs tend to re-create the same code over and over again. Case in point, a use-case where a team name is generated from a list of team member names. The LLM re-generates this code in-line every time it needs to display the team name, rather than simply writing and reusing a utility style function.

I know I need to fix this. At this point I'm planning to just prompt something like "please list all the places where team names are generated/calculated", plus manually search through the codebase, then perform the abstraction myself. But I'm unsure how to prevent this (both this example, and other cases that could benefit from similar utility functions) continuing to occur in the future.

Post reply on HN