Live data from Hacker News

Cleaning up after AI rockstar developers

codingwithjesse.com

131–140 of 401 posts

Re: Cleaning up after AI rockstar developers

#131
post #7

I kind of envy people who need to clean up after others. At least you're puzzling. My current job is genuinely just boring. It's tasks that are so simple, a junior could do it. But no, instead they needed a medior. I'm not saying I'm better than this, nor that no medior will pick it up. I just cannot push myself to care about the code this company makes. It's old, dusty and it serves no one of importance. These custo…

For a boring codebase how is your company not trying to throw tokens at it? Not saying its the right choice but definitely the trend I am seeing.

Perhaps they don't like slot machines

Re: Cleaning up after AI rockstar developers

#132
> Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of.

The author already describes himself as "not a rockstar developer", but if this is the definition of "rockstar" I need to recalibrate.

Being able to learn new languages and libraries, to me, is completely normal.

(Also: how funny is it to suggest rewriting code you self-admit you can't even read.)

Re: Cleaning up after AI rockstar developers

#133
Don't call them rockstars - call them "resume-driven developers."

We had one on our team in the past.

A bunch of microservices built on an in-house RPC framework he wrote, RabbitMQ, half-baked "monads" in an OOP language, esoteric naming, and no comments (the code should be self-documenting!), no docs.

Management adored him.

Once we started to grow, the problems started to appear: bad orchestration, uninformative logs full of PII, poor error handling, edge cases that were nearly impossible to fix within the existing abstractions, dependency hell, etc.

At that point, he moved on.

It took years and many hundreds of pull requests to clean it up.

Re: Cleaning up after AI rockstar developers

#134

Don't call them rockstars - call them "resume-driven developers." We had one on our team in the past. A bunch of microservices built on an in-house RPC framework he wrote, RabbitMQ, half-baked "monads" in an OOP language, esoteric naming, and no comments (the code should be self-documenting!), no docs. Management adored him. Once we started to grow, the problems started to appear: bad orchestration, uninformative log…

Or people with not enough time, not enough resources and too much overtime already to kill off any happyness in creating the product.

Re: Cleaning up after AI rockstar developers

#136
post #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.

Copy paste is a very, very under appreciated tool when it comes to programming.

You can always abstract later, but once you start it’s terribly difficult to reverse.

Re: Cleaning up after AI rockstar developers

#137
post #73

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…

> 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. The anti-LLM propaganda is getting ridiculous at this point. No project "needs 10GB" to compile, unless you're working with astronomically massive repos, and _no_ LLM will _ever_ generate that. Lint errors (depending on cause) are either meaningless or a result of poor pro…

> No project "needs 10GB" to compile

You've never tried to compile NextJS slop, have you? It absolutely can take that much. All those junkdevs have 64GB in their MBPs for a reason. NodeJS max heap is now dynamic because of this.

Re: Cleaning up after AI rockstar developers

#138

Earlier quoted context omitted.

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.

"Just have a stochastic machine redo the code with no oversight"

This is an utterly terrible idea.

Re: Cleaning up after AI rockstar developers

#140

> Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of. The author already describes himself as "not a rockstar developer", but if this is the definition of "rockstar" I need to recalibrate. Being able to learn new languages and libraries, to me, is completely normal. (Also: how funny is it to suggest rewriting code you self-admit you can't even…

The point is that developers like this purposefully introduce new languages and frameworks that only they (and maybe not even they) fully understand, so they make themselves harder to replace and ensure that they appear ahead of the curve. (Then they get bored and leave anyway.) It's totally valid to introduce new technologies when the problem calls for them, but doing it in a way that's purely detrimental to the rest of the team is very selfish.
Post reply on HN