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.

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

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

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.

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.

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'm not even sure what it's trying to say. It's just someone patting themselves on the back.

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.

At least that's my takeaway here.

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

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.

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.

Completing each individual programming task is easy. Engineering the system in a sustainable way that changes can be traced, understood and reasoned about is difficult.

The problem is, as many other comments have pointed out, typically the business doesn't value this.

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

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

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.

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

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.

This cascades of short sentences are a giveaway.

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.

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.

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.

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

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.

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

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

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

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

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

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.

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

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.

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

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

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.