Then we go back to the old “the prototype works; I’m the boss and I’m telling you to deploy it to production”
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 process, the quality of code/architecture matters little if the low bar of functionality is met. Functionality can be sold to customers or used to test the market. It’s basically the whole MVP thing and the MVP should be a bit jank. If it wasn’t, you spent too much time/effort on it.
All said, there’s definitely some approaches to make it less jank from day one. Unfortunately, jankiness is a subjective metric.
If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.
That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.
Worse, often you need to spend years before you realize how an initial design decision was a mistake - not only are you proposing to throw away millions of dollars worth of work - you also don't know that your proposed better design is really better.
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.
Yes, there's probably a market for vibe-coded software, but if there is, then there's also a market for fixing other companies' vibe-coded mistakes...
Phrased another way, you pay company A to vibe-code some software or extra software features for you, then you subsequently pay company B -- to fix company A's vibe-coded mistakes!
(Hey, look on the bright side! It's more money for taxes, GDP, employment ("jobs jobs jobs!"), and the circular Internet economy! :-) )
If you're a reasonably talented developers, I think there will be money to be made picking up projects left behind by coding agents. Maybe you'll use AI tools to do this, maybe you charge to migrate to other platforms and maybe you are paid to simply do bugfixes.
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 prompt engineering. If you want your project linted/formatted a certain way make it clear to the LLM.
Most people have no clue what that means. Most Devs should know but I would wager that newer devs don't have enough opinion or exposure to do that.
This story doesn’t add up.
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.
Do you have any idea, even before modern LLMs, how much code out there was just given more memory instead of optimized? There are even good reasons for it (it can be cheaper than having devs spend time if there's more productive work to be had).
It can be very easy if said code needs to parse through gobs of data.
> _no_ LLM will _ever_ generate that
Did you even read the post? Seems you are being overly hostile, defensive and dismissive. Honestly, you sound like an astroturfer to me. I'm curious to check your history to see if you match the vibe.
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...
Many devs choose to just do their day job or decide to follow a cargo cult.
Probably not every dev can have the same output, but if you decide to keep thinking beyond what is the cultural average, then everyone could be smart in their own way. Most people don't realize they can do that.
I don’t claim to be book smart or have a high IQ or whatever but I feel this way about small things that I feel are common sense. It’s maddening to me to watch people fumble around. Or do X when obviously it will result in -Y a bad thing. I really have learned to just not vocalize it, most of the time. It’s especially unhealthy for my close family relationships as I just see so much of it that I could nag them to death.
my wife and i have two non-overlapping sets haha you can imagine how that plays out
Yesterday she literally failed miserably at a single task. Her mission was grocery shopping. She drove to grocery store, shopped, and came home and left the groceries in the car. Didn’t realize it until she was making breakfast the next morning and there was no milk.
I see this two ways; 1) I would never make that mistake 2) I know her quite well, partners for over 20 years now, and this kind of thing is just her normal par for the course type of “oops”. The second part is what frustrates me the most, I like to learn from my mistakes and she treats it as a given that she’s just spacey/dimwit by nature and leans into everything being an “accident”. Obviously not healthy if I treat her like a child so I just watch her fumble through life and try to have a sense of humor about it all.
However... NONE were "the 10x developer" who built up a huge mess. Which a team and I had to spend months and months cleaning up after.
At least not the rockstars I had the pleasure of working with.
> 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.
This one surprised me. Claude Code in the CLI has made standing up an app and debugging whatever random dependencies or docker BS a dream compared to the before times, when you'd have to learn the architecture while simultaneously troubleshooting whatever isn't working on your machine
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.
I didn’t have any major financial obligations like you though, so it was a much simpler decision for me.
Hang in there buddy and also thanks for the deeply human comment.
Maybe the problem is imagining that you need sixty three levels of granularity to describe experience or to establish superiority over sixty two categories of "lesser" engineers?
The point I made was that as an SSE (L63), there’s a certain amount of scope and autonomy that is expected neither of which I was getting and hence I resigned. I am not trying to bully or denigrate anyone junior.
The levelling system specifies the output and the characteristics of the output expected out of an engineer, that’s it. Whether I believe in it or not is beside the point, I was in the system so I did believe it otherwise progressing through my career would have been impossible.
I can very much relate.
Garbage products, by garbage companies, feeding on the laziness and tastelessness of most, as it's being capitalized by marketers.
And now, to make the matter worse - it's all being 100x by the LLMinazation of the entire field. Making code unmaintainable. And worse, making us all dumber.
I really wish we never have stumbled upon it.
I'm not even sure what it's trying to say. It's just someone patting themselves on the back.
I have found that a lot of the "massive amounts of bad code" left behind by "rockstar developers" is actually just a long slow drip of added complexity in the face of changing requirements. and I find that people think they're "refactoring the code for readability" when a lot of times, they are actually just "rewriting the code and therefore understanding it in that process".
I was expecting a lot more, or a worked example, or _something_ to that effect. 90% of the text is the author complaining and defining the problem, then a hand-wavy vague solution is presented in the penultimate paragraph. Barely relevant or useful, really.
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.
Then there's important code, like business logic, security related stuff and such. For that I'll happily use AI to brainstorm ideas and avenues, do code reviews where I'm prepared for it to be wrong and help with library suggestions etc, but where I want to write the code myself so I understand what's going on.
We'll see how it changes, been a wild ride so far.
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.
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.
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.
It's really that simple.
This is an utterly terrible idea.
At least that's my takeaway here.
The chasm between "Software Developer" and "Software Engineer" is getting wider. Articles like this and the comments under it give away who is an Engineer and who is just a coder.
If I had AI tooling at the time I'd probably be more inclined to have it both refactor / optimize the existing application, add automated regression tests etc, and use it to extract all of the features and requirements for it for a potential rebuild.
But honestly I think if that application was properly designed and factored (instead of nesting JS in HTML in strings in JS or concatenating XML from query results only for it to be converted to JSON taking up 50% of response time) its lifetime could've been extended, especially if it was then containerized into a HHVM or similar php optimizer.
But, hindsight.
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.
Once the LLM tells me "Okay, it's done, everything works" I always as it to do a thorough review, I tell it to split up the work among sub-agents with each one taking on a specific responsibility (look for code smells, look for bad architecture, review the data access model, DUPLICATE CODE, testability and unit testing, etc.)
After a certain number of revisions and reviews you'll come to accept the shortcomings it comes back. Usually there will be specific design decisions you made that the LLM keeps bringing up, once the review only brings that up and maybe some other minor issues it's time to move on.
I don't overly rely on markdown files and directions. I don't rely on tooling around it either. I just don't trust the LLM when it says "all done", tests pass, and deployment works. I make it to multiple reviews and iterations even when it thinks it's done.
Understand what you're writing. If you never build up the mental model of what the code is doing you'll never be able to discern what is slop and what isn't. There are no shortcuts.
Piling more prompts on might get you to the same end result, but without understanding you'll never know when you're there.
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.
But there's risk associated with every change, and it takes time to review, QA, monitor the rollout, communicate to stake holders, etc.
The refactor itself may be the smallest part of it.
Yes. In practice, this does not weigh against organisational resistance.
AI really makes it worse by adding an explicit numerical cost to doing anything.
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.
Of course, I'll probably never get hired again anywhere so it doesn't matter anymore.
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.
> 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...
Perhaps I should start trolling people that your software is not truly Open Source if it's not Open Prompt.
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.)
I've never heard of this guy. He's "self employed"
The article lacks any real detail and it just a guy patting himself on the back.
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.
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.
In reality, sometimes I wonder if there is really anything beyond perceptions.
> 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?
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
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
I even had a PE buy the company I worked at, put in a new CEO, and his goal was to rewrite the entire code base in a year. I asked him what problems this would solve and never got a straight answer besides "its yucky" and "people told me they dont like it."
I have had multiple upper management teams decide that "dealing with this product is too hard, let's start from scratch" as if the new thing wouldn't have the same problems of the old thing, but with less effort put into it.
People love to work on new, all the possibilities and none of the bugs!(yet)
Devs love new tech and the product people love something new to put their stamp on, but chasing that high can be ruinous.
I have seen over the past decades this concept of just reusable throw it away code becomes the norm and that’s why also I’m always surprised to look at people complaining about AI development and it’s like yeah it’s just the same as all other development at this point everything‘s just frameworks and throwaway code
I’m not even mad at it but it’s just one of those things where people are like “I’ve never dealt with anything like this”
But it’s the majority of operational software engineering since more or less forever
So in general most of the people have worked on a bunch of greenfield development, thought of the project 2 years old as aged out entirely, and never thought you might "maintain" something at all.
Getting product to prioritize refactoring a working product is like pulling teeth. Even if maintenance is a moderate drain on resources, work beyond maintenance on working solutions isn’t seen as a net win.
1) the speed at which AI-generated codebases grow is far in excess of what human developers can achieve. What took years to accumulate in the past can be produced in a few days/weeks.
2) past large codebases that end up in a similar state would often see a mixture of developer talent. So while you might have a few developers who produce dross, there will also be a few who can pull it back together. You start to see threads of sanity appear, and from that the potential to refactor further, rather than the uniform spaghetti monster that's near unassailable from every direction that we're now getting from the pure-AI projects.
3) external perception differs. AI has been pitched, sadly by sales, influencers and shills rather than experts in the field, to business leaders as the solution to all development problems. When you present this issue to stakeholders you're then immediately put on the defensive, e.g. it's initially viewed as negativity for the sake of negativity. With past technical debt discussions, outside of a few key parties (too often the person responsible for overseeing said debt developing), I've found that it's relatively straight forward to explain technical debt, the need to refactor and maintain systems as a going concern. For the technically disinclined it's easy to draw parallels with building maintenance: you don't expect to build an office and then never spend another cent, it takes continued investment and maintenance to keep it safe, clean, functional and compliant. The difficulty again with the AI projects here I think comes back to the accelerated timeline, as you're inevitably going to be saying months after it's created that it probably needs to be burnt to the ground in lieu of the far greater task of refactoring it. As opposed to a legacy project that has been going for years or decades, where it's a far more palatable concept to take drastic action.
Nah. Now everyone can build single purpose, single use, throw away software.
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.
Why are you allowing AI rockstar managers to (I assume) push without code review? Why are you cleaning up the fallout? It's not AI issue, it's people issue
My manager got the mandate she needs to start coding, she doesn't want that, no one in our team wants that, she's a great manager exactly where she is right now. Nonetheless, we are helping her to code to show something for the higher-ups so she can keep her job, we really don't want to lose one of our best managers because some C-level is anxious about AI...
- show increase in errors and outages caused by this approach
- integrate manager changes into your CI pipeline (coding / reviewing / testing / documentation)
- discuss how your manager can do the changes they need to do without sidetracking all other work
Make it indeed about the money: coding by PM + fixing what was coded + dealing with fallout is greater expense than coding by PM + automated guidelines + reviewing what was coded.
That is - if the environment you're working in is reasonable and it's not a power play by your PM
On your points:
Manager changes are always going to go through the usual pipeline, we are 10k+ people so there's not even a way to go all gung-ho pushing stuff. They need to be reviewed, approved, etc.
But we don't want our manager to code, nor does our manager, so we are just helping to cross the bare minimum expected from higher ups. For my team it's not an issue with our manager's code (those will be at max small fixes, well-defined, the most trivial stuff), the issue is they are mandating managers to do it.
I don't know what size of company you work at, where I am at there is simply no incentive for me to do all the extra work to show execs/higher management the issues cropping up.
I don't even have access to them, I have to pass through other channels, those might compile reports from many people to try to present a case, if they get to present a case then there's a whole other discussion to happen at director/VP/C-level about what they want to do, and since it goes against their big mandate it most likely will just be thrown out.
In this structure I have no motivation at all to go out of my way to perform data gathering/analysis, wrapping it all in a nice concise document explaining what the data means, potential remediation, etc. just to become a footnote in someone else's document that ultimately will not change anything from the VP/C-level mandate.
Same as it ever was.
The only difference now is that if you let it happen, it'll happen 100x as fast.
When I was mentoring junior devs, I would start by fully reviewing their code. If they had a ton of mistakes more than a few times, I would only review until the first mistake, and then reject it. Repeat, repeat, repeat, until they got the picture that I wasn't going to let mistakes through, and handing me a ton of mistakes was going to waste more of their time than mine.
I let the pain be their pain, instead of mine.
But good developers, I'd help them by doing a more thorough review and not wasting their time. Good developers were the ones that made an honest effort to follow the requirements to the letter and test their own work.
We further emphasized this by having a very simple coding test during the interview, and the only thing we cared about was whether they followed the requirements to the letter. There wasn't a lot left to the imagination, and the requirements were very clear. Anyone who missed them wasn't someone who would do well with us.
That very same test will help filter out a lot of AI-braindead candidates that don't check the AI's work as well.
Actually, I wish I still had the exact test so I could throw it against an AI and see what happens. I'm a little afraid that it would pass it too easily now. I'm not sure how I'd fix it to prevent them from just using AI.
It’s actually not much different than a decade ago cleaning up somebody else’s giant Visual Basic or PHP spaghetti code that stuck on the wall
AI is absolutely deterministic, just as much as a a car is, with a human driver (who is also soon going to be replaced with AI anyway) .. I ship more, fix more bugs, audit my code for security more and thoroughly enjoy not just the process of building, but also the asymmetric power i wield by out executing my well funded competitors with 100 developers and 10 testers dnd 5 devops and 10 full time sales staff.
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.
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.