> Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine.

I'm right there with you, but this last sentence concerned me a bit.

In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can still get art and paintings that someone poured weeks of work into, but most people buy their wall-art and chachkas at HomeGoods.

The main difference is the disposability assumption, and software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are. This mindset doesn't align well with software that must continue to operate in order to support some process. A disposable countdown app, sure, throw it away, but anything built around long running business processes should not be treated in that way.

I have concerns that focusing on software craftsmenship frames the issue as "boutique and bougie and unneccessarily expensive" vs "what I need for my usage", instead of "maintable and trustworthy" vs "disposable".

[0] Is that an initiative that benefits large model providers like OpenAI/Anthropic? maybe, but that's not my point here.

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. Very easy if you know what you are doing; impossible if you don't. Keep m coming.

I've met a handful of people across my life that i'd call truly brilliant. Like, holy heck how in the world is this person this smart? Two things I've noted about really smart people are (usually mutually exclusively) 1) Sometimes they do not realize how smart they are, because it's simple to them, or because they know the subject they assume everyone else, say with a computer science degree, knows and recalls and understands all they do. I've had friends who go off on crypto related maths and I'm like "I passed that class, but know that I do not really know the subject you just talked about" ...

And 2) There's the people who it's painfully forefront of mind that they're smarter than most everyone around them. Some of them are jerks, some of them are exhausted by being surrounded by relatively "stupid" (again, relatively...) people. For the latter group i have some sympathy. Imagine walking through life and everything is clear, obvious, easy to process and having to watch humanity make stupid choices over and over and over again when the answers have been long known...

These two sentences hit home:

> The flow of data was so hard to follow, it seemed like someone was trying to cover up a murder.

> Just getting the code to run on your laptop took a week.

I always thought I’m the only one having problem understanding the data flow, or setting up a proper dev environment. Impostor syndrome (and sometimes toxic environments that pushed for “velocity”) didn’t help either.

Felt good to know I’m not the one.

Its never been quicker or cheaper to build something with bad foundational assumptions and principles. Its never been easier to add features whilst not recognizing that it comes with added responsibility. And it will never be too late to hire me for your V2 migration project.

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 customers use it because they once bought the tool and do not care enough to switch, because the tool in question is not interesting.

I was promised work soon that aligned more with my experience, but I do not foresee these customers to come to a stale company like this.

It's not surprising that this company is losing customers, employees, etc. But I have a mortgage to pay. Today I had the conversation about how they might not extend my contract, basically threatening me to take more ownership, do more work, for the same pay. Sadly I have to make it last until I find a new position that is actually interesting. I don't even need a lot of money, I could give a rat's ass about "growing". I just need enough to survive.

This might be a very unrelated comment, in which I apologize. I just do not have another vent to post this to.

This is such a low value article lol

I'm not even sure what it's trying to say. It's just someone patting themselves on the back.

Code that is written will have to maintained often by someone else than who wrote the code. So if one write code nobody else understands its an eventual maintenence failure.

You could optimize for different things. Code understandability by the team, speed, technical brilliance.

If you optimize for technical brilliance but nobody else on the team understands the code its still a failure.

Seen over engineered code

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 change for my life. Being a team player unfortunately won’t give you the same kind of upward mobility in this crazy industry, but it’s done amazing things for my mental health.

I was such a fool to lean hard into two production engineers to build the infrastructure around the two very profitable projects I built. I could have made so much more money spaghetti coding it all like a 10x boss and then jumped to Anthropic for one of those sweet 9-figure comp deals. Stupid, stupid, stupid me.

At least that's my takeaway here.

This is where determinism is useful to help avoid these. A tool like Archiet does the determinism side of things and generates working solutions, which can then be given to a human or AI to sort out any gaps. This saves time, tokens and the need to clean up after AI rockstar developers.

Archiet also ships with the right architecture documentation, without the right architecture or specs-driven documentation, AI rockstars need clean up.

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.

The ironic rockstar comparison is very good. The classic rockstar only cared about "new" technologies and wrote spaghetti code, the new 100x AI rockstar can do more damage.

It's a pity that the article ends cautiously with recommending to perhaps adapt AI usage practices. In this climate we are not there yet to publish the unfiltered opinion that generative AI is garbage and should be disposed of. Soon we will be.

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 rules in the prompt matters. Introduce new paradigms/tools/code into the main codebase because they solve a business problem, not because they are technically interesting. Careful development does not break 7 things to introduce one new feature, etc.

One argument I heard from a college that the experimental llm written code (not production ofc) should be "write only" - you specify the requirements and constraints and let the machine figure it out - you specifically avoid "fixing it" or "cleaning it up" or reviewing the code because it disrupts the state of this discrete optimizer (over code). Not saying that it is right, or that it should be applied in prod, just noting that this is one potential way to go for non-critical code with clear "win conditions".

Oh, yeah.

I'm reconciling with the fact, that, if I let AI write a bunch of code, I have to depend on that AI to maintain it.

I just spent the last week, hunting down memory issues in the app I'm writing. I had a lot of help from an LLM. It rewrote most of the view controller that implements the map screen. That view controller is now 4,000 lines long (but half of that is comments), but it works extremely well. It took many context resets and rewrites to get here.

I would not have done it that way, but then, I probably also wouldn't have fixed the issue. The issue was really in Apple's MapKit, and I needed to do some gymnastics, to keep it from jetsaming my app. It's not particularly good code; but it works.

I've made the difficult choice to leave the sloppy view controller in the project, with the option of completely ripping it out, in the future, and replacing it with less "intense" code. It's pretty much "firewalled." It won't be that difficult to do it, assuming I have the bandwidth (and Apple finally fixes the memory hog issue, which seems to have been around for a long time).

There's all kinds of options that I could have (and still can) explore, but I feel that this is the best one.

But this article is absolutely correct. I think we will have a "slopocalypse," when it comes time to pay the piper for the thousands of vibe-coded applications that are certain to be authored in the next couple of years.

>Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine.

Current AI coding is certainly very lacking in the craftsmanship department. But it is not obvious to me that that will always be the case. I don't think there's some fundamental reason AI could never produce code that matches or exceeds the craftsmanship of human experts.

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.

This is why I always work at a new company at least 6-12 months before making any major changes. I use that time to get into the flow of how things are being done (even if I think they are not efficient). I may make some suggestions but that's it.

Of course, I'll probably never get hired again anywhere so it doesn't matter anymore.

I heard this kind of rockstar stories a lot from my friends but I never encountered one in real life. I worked in small and big companies and no one with allowed to use any obscure language or tooling. I count myself lucky.

Opening paragraph is not the profile of a rockstar developer.

At least not the rockstars I had the pleasure of working with.

Like many other critiques along this line, I think the answer is: Yes, for now. For example, in my own code base, I have an agent dedicated to maintaining a sane data model. This agent reviews the plan in advance and again during code review. And then I review the code myself. This seems to be sufficient for my work, at least. YMMV. It was a good post though. I enjoyed the take and the writing.

I’m sure the general premise around AI-generated code is accurate. That being said, I’ve definitely had interesting moments where e.g. Claude produced code that matched the pre-existing codebase quite nicely, and slowly started building up its memory of how new pieces fit into the codebase in an idiomatic way. Then again, it started to throw in Tailwind-based CSS classes all of a sudden, because it assumed that Tailwind had been set up (it wasn’t).

Okay so "belt and suspenders" is an LLM-ism, it's not just me who recently learned that expression.

One thing I’ve found helps is leaning a bit more towards a modular almost microservice like model with clearly defined interfaces. Gives you a bit better control than a huge unified ball of AI spaghetti code

I don’t think the analogy between rock star developers and LLMs bears out here. Like any other tool, AI abides by the basic reality of garbage in/garbage out. If you don’t make sure the LLM has sufficient context then you get what you get. Same point with vague prompts.

AI tools are producing code on behalf of a developer. If that developer is fine putting their name on code that they don’t understand, applied to a code base they also don’t fully understand then you have a very human problem. The technology just magnifies this.

We are always the rockstar of someone else

Is the "Cleaning up after hundreds of AI rockstars" part a description of an actual experience? I don't feel that it is. I would expect much more swearing if it were the case.

The post seems to not address the fact that different product phases exist which in turn affect the software. Similarly, teams are different and get assembled for different purposes. There is also a difference if software was created in the past 24 months vs past 10 years. It is very easy to attack decisions made which look messy now, because many reasons. Everything looks obvious in hindsight. And then making it ad-hominem like does not sound smart, it is a clickbait, the issues are usually more complex.

I did cleanup after rockstar diversity hires. I am lgbtq person of color myself, but that does not count since I have penis and European origin!

Sometimes I wonder if any of this will even matter in a few years. How many of us compile code and then have to clean up the assembly, or even worry about what a compiler generates as long as it's correct?

I realized recently that this all has an unsavory element of ego to it. It doesn't help that LLMs have basically been trained to talk like they're performing in a movie, getting creative with techno-babble that sounds both plausible and exciting. I recently had to review some slop where the LLM was using terms like "event storm" to describe how some callbacks work, or "gating-solve" to describe a simple change to an if statement. Combine that with their sycophantic tendencies, and it really can make you feel like you're a star hacker in a Hollywood movie.

It reminds me a little of when Hegseth wrote "we're clean on opsec" in a message thread with confidential military information that he accidentally sent to a journalist. It seems like role playing/fantasy fulfilment for certain personalities. I struggle not to hold some contempt for people like this, who are making life difficult for everyone for their own petty reasons. I can sympathize when it's simple ignorance, but the ego chasing really is inexcusable and needs to be called out more.

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...

This is why I like a bit of 'wet-kiss'es while working on projects.

> You can lead the engineering, and guide the LLM to generate small snippets at a time.

Yes, yes you can, but you can't force the LLM user to _understand_ your feedback so that they reduce the burden on you, as the reviewer.

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.

I’ve cleaned up after outsourced code and it has a different flavor to AI rockstar code. In the former, you can see that the developer only care about the current ticket. After every merge, it’s a flurry of bug fixes, because they always break something unrelated. And that’s due to bad design, you will see a lot of copy pasted code and unused code.

As for the AI code, the most defining elements are unneeded complexity and low understanding of the abstraction involved. When you need a 10 lines functions, the AI will happily write an entire module because that’s how a fully implemented domain is like. But it’s not part of the requirements. As for the low understanding, you will see strange code, which are not fully antipattern, but are definitely not needed as it solves issue that the platform/library/framework doesn’t have or already have a solution for.

this resonates with me, but fortunately one difference between LLMs and rockstar developers, is that LLMs will at least _try_ to explain what they are doing, and why something has to be certain why. I've gotten quite a lot of mileage from being a five-year-old with Claude and just asking "why" until I'm satisfied

AI codes worse than even the most egotistic prima donna. I see future business opportunities in cleaning up the mess being created now.

I've said it before, I'll say it again, I'm convinced LLMs will be the thing to convince software engineers to get it together and create a licensing board.

Somebody wake me up when the ABET SWE PE is back.

"I am a rockstar developer and this characterisation is unwarranted" -- thought bubble emoji

> 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.)

Rockstars, AI or not, were 'successful' because they defined how success looks like. They created that perception and called it success. Not many people would bother going beyond the perceptions. They don't know how success or good code looks like. Rockstars gave them the playbook.

In reality, sometimes I wonder if there is really anything beyond perceptions.

Story time! I Worked with not just a "rockstar" but what I suspect was a "superstar" for about three years at my last gig. It was a small company with about 3-4 developers at any given time and we worked on an embedded Linux product in a moderately safety-critical industry that had a messy ~25 y/o codebase and a custom, roll-your-own Linux distro on custom hardware. Our "superstar" had been with the company for ~10 years and due to really high turnover I was the most senior of the rest of the staff with 3 years. The manager of the software team claimed to have 10+ years of software development experience on his resume and LinkedIn, but would ask CS 101 questions in our software planning meetings.

The basic workflow adopted by our manager was thus:

  1. Discover a bug or get a feature request
  2. Pass the task to the development team verbally
  3. Developers prioritize tasks based on which ones are more likely to be forgotten by management
  4. Approx 20% of tasks get completed
  5. Repeat step 1

Basically our superstar developer absolutely allowed our non-technical management to commit software development seppuku. His successes were highly visible, but his failures were not:

  1. Clobbering other developer's commits because he didn't know how to use git to rebase or merge changes
  2. Copy pasting (not forking) entire codebases to work on a new feature that then got so bloated they were impossible to merge
  3. Absolutely no documentation of any sort, not even comments.
  4. No automated testing of any sort on any of his code even though there was an effort by the rest of the team to do better testing.
  5. Refusal to use the common Docker development platform everyone else had standardized on, many times his code only worked on his machine.
  6. He wouldn't fix bugs, he would just re-write the core logic of the feature that had the bug and then he wouldn't bother to remove the old logic.
  7. Regular, daily code dumps of 1000-2000 LOC that contained new features that were not discussed by the team, sometimes from casual conversations with a sales person, sometimes completely made up by him out of boredom I guess.
  8. Our Linux BSP was stuck in Amber because the only copy of it was on his local machine (allegedly). When asked many many times by the rest of the team to get it in our company repo he would check in something that did not compile and was not even remotely close to what was being used on our boards.
  9. Instead of adding dependencies where needed he would take a 3rd party library, chop it up and copy-paste it into our code directly (see point 8).
  10. Last but not least just general slop code with 15-20 levels of indentation, no modularity, dirty hacks everywhere.

Nice Blog!

It’s literally no different than how to clean up old projects over the last 30 years of software engineering

I don’t understand why all this stuff is all of a sudden “new.”

It feels like we’ve got an entire generation of people who never had to spend their time factoring or doing hard infrastructure work

It’s actually pretty baffling how rare it is to find somebody who has consistent experience in refactoring that is under the age of 40

> Building software that lasts

Nah. Now everyone can build single purpose, single use, throw away software.

The photo in the article looks like AI slop but isn't - it was taken in 2019. It took me awhile to convince myself everything in it was real.

If you're just starting to learn programming, people will tell you that maintainability is important, and they'll mention John Ousterhout's concept of the "tactical tornado" as an anti-pattern.

The problem is that this approach implements features quickly but in a way that conflicts with the team's mental model, ultimately ruining the entire codebase.

A lot of blog posts initially framed this as a problem. I agreed to some extent.

But as I've gained more programming experience, I've come to realize that all programs degrade over time until they are reborn. Eventually, it seems that destructive innovation is necessary for longevity. And sometimes, new patterns emerge from that kind of disruptive feature development.

So you could say that AI rockstar developers and AI-driven development are close to being a "tactical tornado" because their codebases are bad, with poor maintainability and reliability.

Maintainable development, in my experience as a traveling contract developer, usually refers to code that is well-modularized and well-crafted, making it easy for someone like me to understand the codebase when I come on board. But when I saw the leaked Claude code, frankly, the code quality was disappointing—yet by my standards, it worked very well.

So I've changed my mind lately. I think we actually need a new classification of developer types: those who love creating new things but are bad at maintenance, versus those who are conservative, good at maintenance, and build beautiful code.

What makes me think not too badly of recent AI-Rockstar(or AI vibe)developers is that as any industry becomes more advanced, it becomes harder for stars to emerge. Work gets divided and specialized, and no single individual can master everything. For example, I'm confident in writing 60,000–90,000 lines of code by combining frameworks based on IoC (Inversion of Control). But I'm weak at large-scale programming like distributed systems or low-level programming. That's the difference in expertise. I'm strong at the macro level but weak at the micro level. You become cognitively optimized for your own domain.

vibe coding developers(or AI star developer)since AI is still far from being highly advanced—produce messy code, but they definitely bring a new kind of shock. And when you look at their internal structure, many developers mock them. This reminds me of Undertale. Undertale's code is full of if statements and an enormous number of branches—honestly, it seemed like the developer didn't even know the basics of coding. Yet that game became a historic success. The same goes for programming. Some people make the code components beautiful and efficient, while others focus on delivering what the end consumer wants.

So these days, I even think that the more AI developers create bad software using AI, the more new jobs will emerge to maintain that software. Everything always has two sides, it seems.

And in a way, maintainability means knowing how that feature fits into the overall shape and UX of the product. With new products, that prediction is often impossible

Please write a manual on how to cleanup after AI rockstar managers who think they can code.

Much needed right now as I slept only two hours since yesterday after solving a SEV-0 and having to wake up after a 2 hour nap, so I could be now cleaning up the fallout before business hours.

I am not a AI-denier, I am actually thankful I have AI right now to multiply my force, but frankly, people STILL need to review that fucking code, and the people who review the fucking code STILL need to be good enough to be able to write it themselves if they needed.

Whoever says otherwise is either an AI investor, a linkedin influencer or a complete imbecile.

--- EDIT

Please add a section on how to communicate and write a post mortem where the guilty is completely exhonerated without the blame falling on me as I try to save said manager's face.

30 odd years ago this post would have been titled "Cleaning up after compiler generated assembly" ...

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

> As you waded through the slop, you browsed job postings and fantasized about leaving

Just because you didn't understand something or haven't heard about a library, doesn't mean its slop. How do you make sure your definition of "clean code" is not a slop to others?

This isn't a problem with "rockstar" AI devs. This is a problem of management. Who would let someone come in and rebuild the core infra of their business without any planning or review?

This article feels is trying to justify their own inefficiencies (lack of library or language knowledge) instead of taking the time to learn from the rockstar and their technology choices.

As I was leaving my last job, I advocated everyone migrate from plain old es6 to typescript, b/c several times broken builds made it to production.

Certainly my coworkers may of felt upset that typescript is too verbose and pointless if everyone reaches for the "any" operator. But that doesn't mean the decision to move to Typescript was bad, it just means the company is "old school" and not willing to take the time to adopt modern workflows...

> 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.