Craftsmanship is not dead in other industries in the same way it is being talked about for software.

Sure, that cheap desk that arrived in a flat box and got assembled by me and a screwdriver was mass produced in a factory. But it's design had way more expert craftsmanship put into it than would ever be feasible for a bespoke product. High upfront design cost, then mass produced at a low marginal cost.

That had been the state of art for software from the beginning. When you download Firefox, there is no expert programmer carefully building you an artisinal web browser. There is a CDN server sitting in a data center somewhere copying bytes out of its cache for you.

One of the things AI us threatening to do is replace the CAPEX craftsmanship, which has not happened at scale in other industries.

What AI has had more success at it replacing low end "artisinal" software; which is a category that has thus far been so uneconomical is essentially doesn't exist.

Physical industries are very different than software. Leather shoes are made many times, 1x per customer. Code is created once, using the same product for all customers. This gives a lot more leverage on investing in a quality product.

I also don't agree that software is disposable for the same problem. If it's a temporary problem sure, the code is thrown away and we create something new when another, different problem comes up that can be solves with software.

But if it's an enduring problem? The code sticks around.

Thought experiment: would a junior developer armed with a modern day gpt-5.5 or opus 4.8 in 2015 would have been considered a 10x developer (assuming nobody knew they were using AI)?

Slightly agree. :)

I don't think handmade shoes are the right comparison, unless you're talking about software that's meant to be used by just one person.

The more apt comparison might be to the engineers building and maintaining the manufacturing equipment in the shoe factory. It's a degree removed from the consumer, but there's definitely still craftsmanship involved there.

"software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are"

Software has been the most disposable object in our lives since you could push a new build over the web. Builds change overnight, new versions every month with small updates. You have it backwards. Software has very little to no regulation compared to physical products and requires little to no effort to change. It has been disposable for decades at this point.

The change is large numbers of developers feel they are becoming disposable.

We will see if that is actually true if any of the AI companies can actually monetize their government cash infusions.

Software engineers are not artists nor shoemakers. They are factory makers.

A good analyst makes a hand-crafted, custom report in a day. A programmer makes a factory that makes thousands of reports per second for a thousand clients.

I am yet to find a factory at HomeGoods.

Now the kind of factories we make might change, but isn't it the fun part?

> In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives.

What if for a lot of software projects out there you don't need craftsmanship but you need something closer to real engineering: "This is what a sane PostgreSQL setup and transaction management for your app looks like, this is how you do validations and the ORM layer and logging and interaction with APIs and request queueing, this is how a good front-end page looks like, here's the off-the-shelf component library you use, here's how your process errors and show toast messages and handle redirects without messing around with browser history, here's all the accessibility and mean things you DON'T do (like hijacking scroll, not having contrast, having too many animations etc.)."

You don't have a rockstar building a bridge, nor do you usually have craftsmen taking risks on innovative materials and new approaches: most of the time, you just build the damn bridge in ways that have worked for decades and have been proven. Software industry doesn't seem to know what is proven or works, cause it's a moving target. Outside of maybe niches like writing code for airplanes, completely different standards there, not sure if most devs would personally want to work in those conditions, though.

Instead on one hand you have orgs and devs that are moving too fast and create a lot of churn without nailing down what works and doesn't, on the other hand you have a lot of people (myself included) that often have to push out slop because tech stacks are a mess and you still have deadlines which don't care about any of that, and largely the state of software development seems like a comparison between Windows 9X, the UI/UX of which was at least partially based on usability studies, and the modern version which... well, you can see for yourself.

I don't think craftsmanship is dead, but I do think we've built a lemon economy.

The thing that creates the lemon markets is that you can't really distinguish quality until after purchase. This is extra hard with software because the average population is tech illiterate. It's even hard to distinguish when people are tech literate (and not all of HN is). Same thing with cars, most people can't tell the difference, so they buy based on price.

We kinda did this to ourselves. We pushed everything online and killed all the stores. Remember when no one would buy anything online because how risky it was? Then they created "free returns, no questions asked" and people would buy a few things and then send it back? That gave a store like feel with the convenience of home. So everyone moved online, the stores struggled to keep up, the Internet retailers kept running in the red (just like physical stores), the physical stores died, then the online sites needed to get a profit, so free returns stopped or diminished (or drove up the cost of goods. Yay arbitrage! It's like paying for credit card fees when you pay with cash \o/). So now everything is just worse.

We do similar things everywhere. We've started running the whole economy this way. By looking at it through a spreadsheet. Data is great, don't get me wrong, I'm an incredibly mathy person myself, but these are just proxies. To do good data analysis you also need to see beyond the math. To see where the proxy measurement isn't perfectly aligned with the desired measurement. How the measurement[0] can mislead you.

  > "what I need for my usage"

[0] all measurements are proxies. You can't measure anything directly. No, you can't measure a meter. You can measure a comparison to a meter stick. You can measure the time of flight of a laser. You can do all sorts of things like that but everything is always a proxy. If you think this just matters for high precision, well... just look at any house.

[1] an incredibly talented third party could get you exactly to where you need but now you've just doubled the people working

Yeah, even though I like 'craftsmanship' here, stakeholders don't. I think "durability" is pretty good. 'Engineering standards' perhaps. I think we'll start to see the groundwork laid for software engineering as a proper engineering field, where specific performance characteristics are required for certain stakes.

Code can be like "heavy machinery", maybe needs license to operate. If an app has sensitive data in it, it becomes like a residential structure subject to building codes and inspections. I shudder to think of how this would play out it our oligarchic, anti-competitive environment though.

> but anything built around long running business processes should not be treated in that way.

Arguably they are even more willing to cut corners though. Nothing by IBM or SAP should be considered "crafted", yet those companies have a strong place in the world of business today.

In some ways they are giving you a spec and UI mocks to implement.

This X a 1000.

I work in IR for small to medium sized business. The past few years have seen my business increase well beyond what I can reasonably handle and my bank account feels like a dragons pile of gold.

I will always always be on the side of security should be integrated and planned for and by no means do I want to see breaches.

That being said giving people of dubious expertise the ability to blast out an app in an hour has been an absolute windfall for me and others.

Agencies that focus on this sort of work are going to make bank. We’ve already gotten some work like this, and it’s just going to keep coming as people think they can vibe code their products. Like you said, easy money.

Lots of people are gambling on AI with big bucks. Some of it is promising but all those bets won’t pay off. I like to think of this mindset as being the human slot machine that people are shoving money into.

Are clients really paying for it? It’s really fascinating actually. Is it because the ”client” built it so they have sentimental value and sold it to themselves before you receive the request?

Did you use AI to rewrite it?

So how does one find these sorts of clients?

why fix it when you can just easily re-write/generate it from scratch?

How much would it have cost to start from scratch?

Interesting!

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! :-) )

> 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 prompt engineering. If you want your project linted/formatted a certain way make it clear to the LLM.

And then you’ve got a third problem - that well north of 50% believe themselves to be in that last sentence of yours

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

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.

Yup, I've known and met such people.

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.

I would say there are two explanations for group 2.

The first is that you aren't as smart as you think you are, because if you actually understood the people around you in any real way, you would instantly find them less frustrating. But instead you are using flawed heuristics, built out of your own insecurities, to interact with the world.

Possibility two is that you are smart, but you have developed a malformed coping mechanism whereby you take all your negative traits (social ineptness, anxiety, impatience) and treat them all as simple the nature outgrowth of your prodigious intelligence. This is a common coping mechanism, and the neat thing is, it has nothing to do with intelligence. You can be dumb as a brick and still feel like you're in a world of morons who are inferior to you.

In fact, I suspect these two explanations are one explanation.

> painfully forefront of mind that they're smarter than most everyone around them

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.

It's lonely being an outlier, especially in a trait that's so fundamental to how you see the world. Despite best effort, it's hard to relate to most people, and they especially find it hard to relate to you. The delta of lived experience is quite wide, often insurmountable.

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

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

You are not alone. I was in this exact same position at MSFT and I put in my resignation. I am an L63 but the work I was doing, was something an L60-L61 could do and I frequently felt I was in one of those Bullshit jobs (courtesy of David Graeber). I was paid handsomely but once the sign on stock ran out, I saw that I was staying in the job just for security. I felt like one of those Hooli engineers who were sunbathing at the Hooli office terrace waiting for their stocks to vest. I am only 9 years into my career and I didn’t see that as the optimal thing for my career rn.

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.

At first I thought "medior" was a strange typo for "senior", but on seeing it twice I had to check - apparently it's used in some parts of Europe to mean "mid-level"

Take a good look at the codebase you're working on. My guess is there's plenty opportunities to clean up after others, or even yourself.

> I just cannot push myself to care about the code this company makes.

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.

> basically threatening me to take more ownership, do more work, for the same pay

I am a bit curious here. Does that simply mean to should to extra hours and do bullshit duties or is there actually more coding work opportunities? Or do they expect that you should prove more valuable out of nowhere?

I don't want to downplay your experience. In the latter cases, I wonder if you can actually do something.

I love this kind of comment. It's so human. Good luck, friend.

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.

there is certainly code that sucks; but the article strikes me as someone conflating "code that sucks" with "code that is complex and big and takes a while to get used to".

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

tl;dr: "Slow down and think about what you're doing when using an LLM." Saved you five minutes.

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

So far my take has been that there is code that isn't very important, in the sense that if it works it works, it won't be modified or extended much if at all, and it's easy to verify that it works as expected. This type of code I'm happy with letting the AI go wild on.

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.

Yeah, v1 is sloppy, then I tell the LLM to clean it up. Every 1 prompt of building tends to require 1-5 prompts of clean up. Simple, fast, clean good code.

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.

I wish I had current-day AI (and a big credit card) for my previous job, they had a big legacy mess made by a productive but not very good developer, but my job was to rebuild it.

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.

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.

Absolutely. I really don't think the future will be humans reading and picking apart an AI-generated codebase, there will be tech debt agents or whatever running overnight.

or linters

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.

The fact that LLMs fundamentally do not, and cannot, have understanding or reasoning. I don't think you can produce craftsmanship through sheer volume of throwing stuff at the wall and seeing what sticks.

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

In 6-12 months you could ship a new product or a large feature. This strategy might actually put you on a performance improvement plan instead.

You need a CTO to lay down the golden path.

If you're reviewing the code yourself, then I don't think this article is about you.

No that expression has been around a long time.

In the UK we call it 'Belt and Braces'

https://wordhistories.net/2018/12/13/belt-braces/

It could be but there’s always been so called “10x developers” who just make 10x messes. I think it’s the continuation of an existing phenomenon.

https://www.tyleo.com/blog/the-terminal-star

This was my take as well.

We are finding out that ram is neither cheap and unlimited.

Funny, the element of ego I'm seeing are the devs that can't accept that LLMs write perfectly good code at a faster pace. It's always "slop" this or "vibe coded" that. Meanwhile I've personally shipped multiple apps and professionally we've done HUGE things in these past 6 months using LLM tools.

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.

That makes as much sense as having a licensing board for hammers or socket wrenches or welders.

There's a difference between introducing new things because they are a well thought out appropriate choice and completely ignoring the standards of the company because you want to do resume driven development. I believe the author is talking about the latter.

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.

Just look at the author's accolades. They are very light.

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.

Sure there is. Actually getting to the moon.

I'll avoid trying to guess what the author meant, but I found it rather relatable. Some of these "rockstars" pick weird languages, niche database, esoteric frameworks and whatnot, not because they're needed, but because that's the rockstar thing to do at that moment. And then they leave and you're stuck managing a Cassandra database and a Rust application when everything else around you is MariaDB and Java, and you have to maintain an application in an abandoned JavaScript framework, even though dynamic frontend wasn't a requirement.

This is a guy who has 20 years of 1 year of experience. His blog includes his linkedin and github, just give it a look over.

Programming is for humans first. Cleanness and code quality is judged according to that.

That's because the businesses got into the habit of new C level means new project, obviously the old code is bad.

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)

In my experience, this is because a modern engineering organization is laser focused on delivering value. Value rarely aligns with refactoring an existing, working implementation. If need the data, you build an integration on the output data. If something isn’t working well enough, you fix that one thing, you don’t refactor half the application.

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.

It's different because LLMs can generate code that immediately needs to be refactored at speeds that were unfeasible before. There was a practical limit on the amount of technical debt that could be created in a day before, now that limit is 10x or 100x higher. It can be generated far faster than it can be fixed.

The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:

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.

You're just witnessing "Software Developers" cry out over LLMs.

"Software Engineers" are embracing LLMs and getting shit done same as before.

> how to clean up old projects

What’s “new” is indeed the “new” bit in cleaning up new projects.

Then reconstitute it later, even if slightly different. Nobody cares because it's small.

I believe GNU Emacs was created in 1984 or 1985, and it's still going strong. I guess it's not easy to work on it due to the long history, but I understand it's been refactored as the developers went along.

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

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

No, no, much better: make it a SKILL.md ;)

I run a whole ass month long class on exactly this

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

Hmm, ~30 years ago the compilers that I was using were generating generally fine assembly/machine code. Some of the other tooling was more troublesome: cross platform high performance numerically stable code and C++ static template deduplication paid for a lot of beers around then, and I needed them.

Compilers are deterministic and they actually possess domain knowledge of what they are trying to do. AI models are non-deterministic, have no real domain knowledge due to lack of an underlying world model, and their way of "writing" software is to spew out something that looks like something that they have been trained on, then iterate on it long enough until it has reached the level of being barely runnable.

> There is no such thing as technical debt in the age of AI.

Producing new technical debt quickly doesn't mean there's no more technical debt.