3/31/2026 at 6:01:11 PM
I find most developers fall into one of two camps:1. You treat your code as a means to an end to make a product for a user.
2. You treat the code itself as your craft, with the product being a vector for your craft.
The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster.
Personally, I fall into the first camp.
No one has ever made a purchasing decision based on how good your code is.
The general public does not care about anything other than the capabilities and limitations of your product. Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively.
With that said, I do have respect for people in the latter camp. But they're generally best fit for projects where that level of craftsmanship is actually useful (think: mission critical software, libraries us other devs depend on, etc).
I just feel like it's hard to talk about this stuff if we're not clear on which types of projects we're talking about.
by seamossfet
3/31/2026 at 6:52:23 PM
> No one has ever made a purchasing decision based on how good your code is.absolutely false.
> The general public does not care about anything other than the capabilities and limitations of your product.
also false.
People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly).
The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.
by nocman
3/31/2026 at 7:44:42 PM
> You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.Exactly, thank you for putting it like that.
So far it’s been my observation that it’s only the people who think like the OP who put the situation in the terms they did. It’s a false dichotomy which has become a talking point. By framing it as “there are two camps, it’s just different, none of them is better”, it lends legitimacy to their position.
For an exaggerated, non-comparable example meant only to illustrate the power of such framing devices, one could say: “there are people who think guns should be regulated, and there are people who like freedom”. It puts the matter into an either/or situation. It’s a strategy to frame the conversation on one’s terms.
by latexr
3/31/2026 at 8:23:11 PM
> obviously created by people the care deeply about the quality of the product they produceThis obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.
> There is no substitute for high quality work.
You're right because there really isn't a consistent definition of what "high quality" software work looks like.
by mbesto
3/31/2026 at 8:34:05 PM
> This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.Those first three are "enterprise" or B2B applications, where the person buying the software is almost never one of the people actually using the software. This disconnect means that the person making the buying decision cannot meaningfully judge the quality of any given piece of software they are evaluating beyond a surface level (where slick demos can paper over huge quality issues) since they do not know how it is actually used or what problems the actual users regularly encounter.
by MrRadar
3/31/2026 at 8:38:42 PM
Which might be true, but is totally irrelevant to the OP's comment.by mbesto
3/31/2026 at 8:41:43 PM
Users care about quality, even if the people buying the software do not. You can't just say "well the market doesn't care about quality" when the market incentives are broken for a paricular type of software. When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software (see Windows in the consumer OS market, which is perceptibly losing share to MacOS and Linux following a sustained decline in quality over the last several years).by MrRadar
3/31/2026 at 9:20:36 PM
> You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product.What about caring and being depressed because quality comes from systems rather than (just) individuals?
by Terr_
3/31/2026 at 8:34:32 PM
SAP, Salesforce, Booking.com… all awful products. We use them because monopolies.by tkiolp4
3/31/2026 at 8:49:52 PM
I couldn't book travel at a previous company because my address included a `.`, which passed their validation. Awful, awful software. I wouldn't expect slop code to improve it.by cdrnsf
3/31/2026 at 8:58:42 PM
Garbage software that is slow as a dog has been winning. While we’ve been obsessing over our craft and arguing about what makes software beautiful, slow crappy software has taken over the world.Quality of code is just not that important of a concept anymore for the average web developer building some saas tool. React code was always crap anyways. Unless you are building critical systems like software that powers a plane or medical equipment, then code quality just doesn’t really matter so much in the age of AI. That may be a hard pill to swallow for some.
by delbronski
3/31/2026 at 7:01:32 PM
> People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly).I would classify all of those as "capabilities and limitations of your product"
I read OPs "good code" to mean "highly aesthetic code" (well laid out, good abstractions, good comments, etc. etc.), and in that sense I agree no customer who's just using the product actually cares about that.
Another definition of "good code" is probably "code that meets the requirements without unexpected behavior" and in that sense of course end users care about good code, but you could give me two black boxes that act the same externally, one written as a single line , single character variables, etc. etc. etc. and another written to be readable, and I wouldn't care so long as I wasn't expected to maintain it.
by ttamslam
3/31/2026 at 8:02:58 PM
>but you could give me two black boxes that act the same externally, one written as a single line , single character variables, etc. etc. etc. and another written to be readable, and I wouldn't care so long as I wasn't expected to maintain it.The reality of software products is that they are in nearly in all cases developed/maintained over time, though--and whenever that's the case, the black box metaphor fails. It's an idealization that only works for single moments of time, and yet software development typically extends through the entire period during which a product has users.
> I read OPs "good code" to mean "highly aesthetic code" (well laid out, good abstractions, good comments, etc. etc.)
The above is also why these properties you've mentioned shouldn't be considered aesthetic only: the software's likelihood of having tractable bugs, manageable performance concerns, or to adapt quickly to the demands of its users and the changing ecosystem it's embedded in are all affected by matters of abstraction selection, code organization, and documentation.
by westoncb
3/31/2026 at 7:58:13 PM
But those aesthetics stem from that need for fewer bugs, performance, maintainability. Identifying/defining code smell comes from experience of what does and doesn’t work.> I wouldn't care so long as I wasn't expected to maintain it.
But, if you’re the one putting out that software, of course you will have to maintain it! When your users come back with a bug or a “this flow is too slow,” you will have to wade into the innards (at least until AI can do that without mistakes).
by arijun
3/31/2026 at 7:57:27 PM
Good abstractions translate directly into how quickly the devs can fix bugs and add new features.by Xirdus
3/31/2026 at 8:46:28 PM
[dead]by myrak
3/31/2026 at 8:01:20 PM
But the thing is that someone has to maintain it. And while beautiful code is not the same as correct code, the first is impactful in getting the second and keeping it.And most users are not consuming your code. They’re consuming some compiled, transpiled, or minified version of it. But they do have expectations and it’s easier to amend the product if the source code is maintainable.
by skydhash
3/31/2026 at 7:01:11 PM
> The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.Exactly. A lot of devs optimizing for whether the feature is going to take a day or an hour, but not contemplating that it's going to be out in the wild for 10 years either way. Maybe do it well once.
by steveBK123
3/31/2026 at 7:04:10 PM
> but not contemplating that it's going to be out in the wild for 10 years either wayI think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.
by ttamslam
3/31/2026 at 8:11:03 PM
>I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.And in almost all of those cases, they'd be wrong.
by coldtea
3/31/2026 at 7:12:57 PM
In my experience the code will, but by year 5 nobody is left who worked on it from inception, and by year 10 nobody knows anybody who did, and during that time it reaches a stage where nobody will ever feel any sense of ownership or care about the code in its entirety again.by benoau
3/31/2026 at 8:00:52 PM
I come into work and work on a 20 year old codebase every day, working on slowly modernizing it while preserving the good parts. In my experience, and I've been experimenting with both a lot, LLM-based tools are far worse at this than they are at starting new greenfield projects.by contextfree
3/31/2026 at 8:20:36 PM
This conversation shows how diverse the field is!When it comes to professional development, I've almost never worked on a codebase less than 10 years old, and it was always [either silently or overtly] understood that the software we are writing is a project that's going to effectively live forever. Or at least until the company is no longer recognizable from what it is today. It just seems wild and unbelievable to me, to go to work at a company and know that your code is going to be compiled, sent off to customers, and then nobody is ever going to touch it again. Where the product is so throwaway that you're going to work on it for about a year and then start another greenfield codebase. Yet there are companies that operate that way!
by ryandrake
3/31/2026 at 7:08:30 PM
It's important to know which type of repo/project you are in and hire/code accordingly.I've seen mismatch in each direction..
by steveBK123
3/31/2026 at 8:04:26 PM
How can you possibly know which type of repo you're in ahead of time? My experience is that "temporary" code frequently becomes permanent and I've also been on the other side of those decisions 40 years later.by AlotOfReading
3/31/2026 at 8:04:19 PM
Unless you’re producing demos for sales presentation (internally or externally), it’s always worth it to produce something good. Bad code will quickly slow you down and it will be a never ending parade of bug tickets.by skydhash
3/31/2026 at 8:34:22 PM
indeed, being on-call cleanses many developers of slopulist habitsby steveBK123
3/31/2026 at 9:21:31 PM
I treat the code I produce as my craft and I appreciate I can afford it and enjoy the output.I know engineers who aren't that lucky and struggle in "enterprise" software development, where slop was a feature for decades - people making decisions won't use the software (their low paid employees will) and software monstrosities need a hell a lot of support which sometimes brings more revenue than the original purchase.
by oxag3n
3/31/2026 at 7:11:46 PM
If a product looks pretty and seems to work great at first experience, but is really an unmaintainable mess under the hood, has an unvetted dependency graph, has a poorly thought through architecture that no one understands, perhaps is unsustainable due to a flawed business model, etc., to me it simply suffers from bad design[0], which will be felt sooner or later. If I know this—which is, admittedly, sometimes hard to know (especially in case of software products compared to physical artifacts)—I would, given alternatives, make the choice to not be a customer.In other words, I would, when possible, absolutely make a purchasing decision based on how good the code is (or based on how good I estimate the code to be), among other things.
[0] The concept of design is often misunderstood. First, obviously, when it’s classified as “how the thing looks”; then, perhaps less obviously, when it’s classified as “how the thing works”. A classification I am arriving at is, roughly, “how the thing works over time”.
by strogonoff
3/31/2026 at 7:50:55 PM
Demos might ne nice an flashy. But eventually you actually have to have generally working product. Too many issues with too many annoyances and eventually users of even enterprise software will be heard. Especially so if there is some actual loss of money or data that is not corrected very fast.In the end software is means to the end. And if you do not get to end because software is crap it will be replaced, hopefully by someone else.
by Ekaros
3/31/2026 at 7:02:26 PM
And yet somehow the shittiest buggiest software ends up being the most popular.Look through the list of top apps in mobile app stores, most used desktop apps, websites, SaaS, and all other popular/profitable software in general and tell me where you see users rewarding quality over features and speed of execution.
by paxys
3/31/2026 at 7:09:10 PM
I don’t think this search will really reveal speed of execution and feature set rewarded over quality either.by thfuran
3/31/2026 at 7:54:03 PM
You have it backwards. Excellent software becomes popular, and then becomes enshittified later once it already has users. Often there is a monopoly/network effect that allows them to degrade the quality of their software once they already have users, because the value in their offering becomes tied to how many people are using it, so even a technically superior newcomer won't be able to displace it (eg. Youtube is dogshit now but all of the content creators are there, and all of the viewers are there, so content creators won't create content for a better platform with no viewers and viewers won't visit a better platform with no content).If your goal is to break into the market with software that is dogshit from day 1, you're just going to be ones of millions of people failing their get-rich-quick scheme.
by applfanboysbgon
3/31/2026 at 7:37:05 PM
> The longer your product exists the more important the quality of the code will beFrom working on many many old and important code bases, the code quality is absolutely trash.
by fooker
3/31/2026 at 7:24:02 PM
>> No one has ever made a purchasing decision based on how good your code is.> absolutely false.
Actually, you are both correct.
Nobody makes a purchasing decision based on code quality.
But they may later regret a purchasing decision based on code quality.
by EFreethought
3/31/2026 at 8:22:15 PM
The history of technology is filled with examples where between two competing analogous products, the inferior always wins. It does not matter if it is only slightly inferior or extraordinarily inferior, both win out. It's often difficult to come up with counter-examples. Why is this? Economic pressure. "Inferior" costs less. Sometimes the savings are passed on to the customer... they choose the inferior. Other times the greedy corporate types keep all of it (and win simply because they outmarket the competitor). It does not matter.If there are people who, on principle, demand the superior product then those people simply aren't numerous enough to matter in the long run. I might be one of those people myself, I think.
by NoMoreNicksLeft
3/31/2026 at 8:42:13 PM
If code is craft and minimalism is hip then why ruby, and python, and go and... when it's electrical state in machines?That's the minimalism that's been lost.
That's why I find the group 2 arguments disingenuous. Emotional appeal to conservatism, which conveniently also props up their career.
Why all those parsers and package systems when what's really needed is dials min-max geometric functions from grand theft auto geometry to tax returns?
Optimization can be (and will be) engineered into the machine through power regulation.
There's way too many appeals to nostalgia emanating from the high tech crowd. Laundering economic anxiety through appeals to conservatism.
Give me an etch a sketch to shape the geometry of. Not another syntax art parser.
by yabutlivnWoods
3/31/2026 at 6:26:43 PM
Sloppy technical design ends up manifesting in bugs, experiential jank, and instability.There are some types of software (e.g. websites especially), where a bit of jank and is generally acceptable. Sessions are relatively short, and your users can reload the webpage if things stop working. The technical rigor of these codebases tends to be poor, but it's generally fine.
Then there's software which is very sensitive to issues (e.g. a multi-player game server, a driver, or anything that's highly concurrent). The technical rigor here needs to be very high, because a single mistake can be devastating. This type of software attracts people who want to take pride in their code, because the quality really does matter.
I think these people are feeling threatened by LLMs. Not so much because an LLM is going to outperform them, but because an LLM will (currently) make poor technical design decisions that will eventually add up to the ruin of high-rigor software.
by iamcalledrob
3/31/2026 at 6:45:15 PM
> the quality really does matter.If this level of quality/rigor does matter for something like a game, do you think the market will enforce this? If low rigor leads to a poor product, won't it sell less than a good product in this market? Shouldn't the market just naturally weed out the AI slop over time, assuming it's true that "quality really does matter"?
Or were you thinking about "matter" in some other sense than business/product success?
by Benjammer
3/31/2026 at 8:38:35 PM
A lot of software is forced upon people against their will, and purchased bu people who will never use it.This obscures things in favour of the “quality/performance doesn’t matter argument”.
I am, for example, forced to use a variety of microslop and zoom products. They are unequivocally garbage. Given the option, I would not use them. However, my employer has saddled us with them for reasons, and we must now deal with it.
by FridgeSeal
3/31/2026 at 7:28:54 PM
Yes, I think the market will enforce this. A bit. Eventually. But the time horizon is long, and crummy software with a strong business moat can out-compete great software.Look at Windows. It's objectively not been a good product for a long time. Its usage is almost entirely down to its moat.
by iamcalledrob
3/31/2026 at 6:54:54 PM
Yes, both the article and GP are making that exact point about it mattering from a customer's perspective.by bloppe
3/31/2026 at 7:06:20 PM
Even if you're confident you can stop your own company from shipping terrible products, I worry the trend is broad enough and hard enough to audit that the market will enforce it by pulling back on all purchases of such software. If gamers learn that new multiplayer games are just always laggy these days, or CTOs learn that new databases are always less reliable, it's not so easy to convince them that your product is different than the rest.by SpicyLemonZest
3/31/2026 at 6:56:43 PM
Yes, there's every reason to believe the market will weed out the AI slop. The problem is, just like with stocks, the market can stay irrational longer than you can stay solvent. While we all wait for executives to learn that code rigor matters, we still have bills to pay. After a year when they start trying to hire people to clean up their mess, we'll be the ones having to shovel a whole new level of shit; and the choice will be between that and starving.As someone who also falls into camp one, and absolutely loves that we have thinking computers now, I can also recognize that we're angling towards a world of hurt over the next few years while a bunch of people in power have to learn hard lessons we'll all suffer for.
by theossuary
3/31/2026 at 7:06:03 PM
No-one comes out of the womb caring about code quality. People learn to care about the craft precisely because internal quality -- cohesion, modularity, robustness -- leads to external quality (correctness, speed, evolvability).People who care about code quality are not artists who want to paint on the company's dime. They are people who care about shipping a product deeply enough to make sure that doing so is a pleasant experience both for themselves and their colleagues, and also have the maturity to do a little bit more thinking today, so that next week they can make better decisions without thinking, so that they don't get called at 4 AM the night after launch for some emergency debugging of an issue that that really should have been impossible if it was properly designed.
> No one has ever made a purchasing decision based on how good your code is.
Usually they don't get to see the internals of the product, but they can make inferences based on its externals. You've heard plenty of products called a "vibe-coded piece of crap" this year, even if they're not open source.
But also, this is just not true. Code quality is a factor in lots of purchasing decisions.
When buying open source products, having your own team check out the repo is incredibly common. If there are glaring signs in the first 5 minutes that it was hacked together, your chances of getting the sale have gone way down. In the largest deals, inspecting the source code
It was for an investment decision rather than for a purchase, but I've been personally hired to do some "emergency API design" so a company can show that it both has the thing being designed, and that their design is good.
by Darmani
3/31/2026 at 9:20:40 PM
It's the end of era where the plucky code crafter gets to have a seat at the table of production. Those skills are going to become less and less useful going forward. Industry is going to stop hiring those types.The future of software looks a lot more like factory production lines with a small group of architect-tier engineers working on a design with product management and then feeding it into the factory for prototyping and production.
If you're not an experienced late senior or principal engineer at your career stage by now there is basically no future for you in this industry. Lower end roles will continue to be reduced. People who can build and maintain the factory and understand its outputs are going to be the remaining high-value software talent.
by voidfunc
3/31/2026 at 6:33:09 PM
This is like when people decided that everyone was either "introvert" or "extrovert" and then everyone started making decisions about how to live their life based on this extremely reductive dichotomy.There are products that are made better when the code itself is better. I would argue that the vast majority of products are expected to be reliable, so it would make sense that reliable code makes for better product. That's not being a code craftsman, it's being a good product designer and depending on your industry, sometimes even being a good businessman. Or, again, depending on your industry, not being callous about destroying people's lives in the various ways that bad code can.
by ambicapter
3/31/2026 at 6:35:34 PM
I’m an introvert. I make sure that all my “welcome to the company” presentations are in green. I am also an extrovert in that I add more green than required.by renewiltord
3/31/2026 at 6:17:09 PM
I respect your opinion and especially your honesty.And at the same time I hope that you will some day be forced to maintain a project written by someone else with that mindset. Cruel, yes. But unfortunately schadenfreude is a real thing - I must be honest too.
I have gotten to old for ship now, ask questions later projects.
by clan
3/31/2026 at 6:20:10 PM
I'm in camp 1 too. I've maintained projects developed with that mindset. It's fine! Your job is to make the thing work, not take on its quality as part of your personal identity.If it's harder to work with, it's harder to work with, it's not the end of the world. At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies.
I think camp 2 would rather see one beautiful thing than ten useful things.
by jstanley
3/31/2026 at 6:58:06 PM
I think camp 1 would rather see ten useless things than one useful thing.by couchand
3/31/2026 at 6:40:58 PM
I think I fall in camp 1.5 (I don't fall in camp 1 or camp 2) as in I can see value in prototyping (with AI) and sometimes make quick scripts when I need them, but long term I would like to grow with an idea and build something genuinely nice from those prototypes, even manually writing the code as I found personally, AI codebases are an hassle to manage and have many bugs especially within important things (@iamcalledrob message here sums it up brilliantly as well)> I think camp 2 would rather see one beautiful thing than ten useful things.
Both beautiful and useful are subjective (imo). Steve job's adding calligraphy to computer fonts could've considered a thing of beauty which derived from his personal relation to calligraphy, but it also is an really useful thing.
It's my personal opinion that some of the most valuable innovations are both useful and beautiful (elegant).
Of course, there are rough hacks sometimes but those are beautiful in their own way as well. Once again, both beauty and usefulness is subjective.
(If you measure Usefulness with the profit earned within a purely capitalistic lens, what happens is that you might do layoffs and you might degrade customer service to get to that measure, which ultimately reduces the usefulness. profit is a very lousy measure of usefulness in my opinion. We all need profit though but doing solely everything for profit also feels a bit greedy to me.)
by Imustaskforhelp
3/31/2026 at 6:34:16 PM
> At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies.Ah yes, if you aren't shitting code out the door as fast as possible, you're probably not shipping anything at all.
by ambicapter
3/31/2026 at 6:53:38 PM
That isn't a fair reading.by Nevermark
3/31/2026 at 7:53:45 PM
Neither is the original assertion. There are thousands of examples of exceptionally well crafted code bases that are used by many. I would posit the Linux kernel as an example, which is arguably the most used piece of software in the world.by jplusequalt
3/31/2026 at 9:11:57 PM
> [...] one beautiful thing than ten useful thingsThey didn't say beautiful/crafted things were not necessary.
They were critiquing viewpoints that all code needs to be.
Even if we (for humorous purposes) took their 1 in 10 ratio as a deadly serious cap on crafting, 10% of projects being "exceptionally well crafted code" would be a wonderful world. I would take 1% high craft to 99% useful! (Not disjointly of course.)
by Nevermark
3/31/2026 at 8:35:49 PM
I keep seeing this idea repeated, but I don't accept the dichotomy between those who care about 'crafting code' and those who care about 'building products' as though they are opposite points on a spectrum.To me, the entire point of crafting good code is building a product with care in the detail. They're inseparable.
I don't think I've ever in my life met someone who cared a lot about code and technology who didn't also care immensely about detail, and design, and craft in what they were building. The two are different expressions of the same quality in a person, from what I've seen.
by davnicwil
3/31/2026 at 9:20:18 PM
That’s non sense. Every software people pay or use as their professional tool should be carefully crafted. Would you buy a house/car/anything or value knowing that people who built it don’t care about their craft as long as you got it in your hands and pay for it ? Or maybe you produce something cheap and worthlessby shinycode
3/31/2026 at 9:16:04 PM
It all depends on the tools. AI will surely give a competitive advantage to people working with better languages and tooling, right? Because they can tell the AI to write code and tests in a way that quashes bugs before they can even occur.And then they can ship those products much faster than before, because human hours aren't being eaten up writing out all of these abstractions and tests.
The better tooling will let the AI iterate faster and catch errors earlier in the loop.
Right?
by sornaensis
3/31/2026 at 7:14:43 PM
Craft, in coding or anything else, exists for a reason. It can bleed over into vain frivolity, but craft helps keep the quality of things high.Craft often inspires a quasi-religious adherence to fight the ever-present temptation to just cut this one corner here real quick, because is anything really going to go wrong? The problems that come from ignoring craft are often very far-removed from the decisions that cause them, and because of this craft instills a sense of always doing the right thing all the time.
This can definitely go too far, but I think it's a complete misunderstanding to think that craft exists for reasons other than ensuring you produce high-quality products for users. Adherents to craft will often end up caring about the code as end-goal, but that's because this ends up producing better products, in aggregate.
by alecbz
3/31/2026 at 9:08:20 PM
i've learned in two years of unemployed hacking that there is a camp 3: you treat code like an evolving life form, requiring both ingenious introspective craft and utilitarian grit to survive and thrive. a product is a trajectory of software in time, and software is a trajectory of code in time; this is no different from how our genetic code determines our physical existence, which then shapes our lives. there is no spectrum between code vs product; if you want to remain relevant in software design, you must see them as layers of a larger whole (and there are many, many more layers once you go beyond the binary of code VS product).by ppqqrr
3/31/2026 at 9:25:11 PM
I think some people are misunderstanding your point.Yes, some people left to their own devices would take twice as long to ship a product half as buggy only to find out the team that shipped early has taken a massive lead on distribution and now half the product needs to be reworked to catch up.
And some people left to their own devices will also ship a buggy mess way too early to a massive number of people and end up with zero traction or validation out of it, because the bugs weren't letting users properly experience the core experience.
So we've established no one is entirely right, no one is entirely wrong, it's ying/yang and really both sides should ideally exist in each developer in a dynamic balance that changes based on the situation.
-
But there's also a 3rd camp that's the intersection of these: You want to make products that are so good or so advanced *, that embracing the craft aspect of coding is inherent to actually achieving the goal.
That's a frontend where the actual product is well outside typical CRUD app forms + dashboard and you start getting into advanced WebGL work, or complex non-standard UI state that most LLMs start to choke on.
Or needing to do things quicker than the "default" (not even naive) approach allows for UX reasons. I ran into this using Needleman-Wunsch to identify UI elements on return visits to a site without an LLM request adding latency: to me that's the "crafty" part of engineering serving an actual user need. It's a completely different experience getting near instant feedback vs the default today of making another LLM request.
And it's this 3rd camp's feedback on LLM development that people in the 1st camp wrongly dismiss as being part the 2nd craft-maxxed group. For some usecases, slop is actually terminal.
Intentionally contrived example, but if you're building a Linear competitor and you vibecode a CRDT setup that works well enough, but has some core decisions that mean it'll never be fast enough to feel instant and frontend tricks are hiding that, but now users are moving faster than the data and creating conflicts with their own actions and...
You backed yourself into a wall that you don't discover until it's too late. It's only hypervigilance and strong taste/opinion at every layer of building that kind of product that works.
LLMs struggle with that kind of work right now and what's worrying is, the biggest flaw (a low floor in terms of output quality) doesn't seem to be improving. Opus 4.6 will still try to dynamically import random statements mid function. GPT 5.3 tried to satisfy a typechecker by writing a BFS across an untyped object instead of just updating the type definitions.
RL seems to be driving the floor lower actually as the failure modes become more and more unpredictable compared to even GPT 3.5 which would not even be "creative enough" to do some of these things. It feels like we need a bigger breakthrough than we've seen in the last 1-2 years to actually get to the point where it can do that "Type 3" work.
* good/advanced to enable product-led growth, not good/advanced for the sake of it
by BoorishBears
3/31/2026 at 6:26:24 PM
I mostly agree with this. Part of the confusion with the discourse around AI is the fact that "software engineering" can refer to tons of different things. A Next.js app is pretty different from a Kubernetes operator, which is pretty different from a compiler, etc.I've worked on a project that went over the complexity cliff before LLM coding even existed. It can get pretty hairy when you already have well-established customers with long-term use-cases that absolutely cannot be broken, but their use-cases are supported by a Gordian Knot of tech debt that practically cannot be improved without breaking something. It's not about a single bug that an LLM (or human) might introduce. It's about a complete breakdown in velocity and/or reliability, but the product is very mature and still makes money; so abandoning it and starting over is not considered realistic. Eager uptake of tech debt helped fuel the product's rise to popularity, but ultimately turned it into a dead end. It's a tough balancing act. I think a lot of LLM-generated platforms will fall eventually into this trap, but it will take many years.
by bloppe
3/31/2026 at 7:11:50 PM
Professionally, I've always been in camp #2. The quality of your code at least partially represents you in the eyes of your peers. I imagine this is rapidly changing, but the fact will always remain that readable code that you can reason about is objectively better.For personal projects, I've been in both camps:
For scripts and one-offs, always #1. Same for prototypes where I'm usually focused on understanding the domain and the shape of the product. I happily trade code quality for time when it's simple, throwaway, or not important.
But for developing a product to release, you want to be able to jump back in even if it's years later.
That said, I'm struggling with this with my newest product. Wavering between the two camps. Enforcing quality takes time that can be spent on more features...
by qaid
3/31/2026 at 7:08:14 PM
I think developers fall into two camps:1. you care about shipping working, tested code that solves a specific business/user problem
2. you care about closing tickets that were assigned to you
by farmeroy
3/31/2026 at 8:28:19 PM
Trying to describe craftsmanship always brings me back to the Steve Jobs quote:“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
by ryandrake
3/31/2026 at 8:35:14 PM
Steve Jobs didn't really know anything about cabinetry, because using plywood / MDF in places where it won't be seen but which would benifit from dimensional stability is absolutely common and there's no reason it shouldn't be.by mikkupikku
3/31/2026 at 8:54:54 PM
You might be missing the point of the quote. He's not talking about whether it is commonly done. He's talking about the mentality that justifies sacrificing the aesthetic and artistry, in favor of things like "dimensional stability". He is giving a reason why it shouldn't be done, and people can disagree about whether the reason is a good one.by ryandrake
3/31/2026 at 9:18:42 PM
He's saying that carpenters who make nice things wouldn't use a material like that, but they objectively do and this doesn't sacrifice the aesthetic or artistry.He specifically calls out the use of the material in a place it wouldn't be seen as something that the carpenter making beautiful cabinets wouldn't do, but that's actually something they absolutely do. He's trying to argue some other point by way of this analogy, but his analogy is wrong because he doesn't know anything about it. It would be like if I was trying to argue my point by way of car analogy but the example I chose was to say that car enthusiasts insist on genuine OEM parts, I'm only exposing myself as somebody who doesn't understand car people.
by mikkupikku
3/31/2026 at 8:13:40 PM
How about the type of developer who comes up with statistics and made up "camps" as if enjoying the craft itself makes you, out of necessity of the false premise, unable to enjoy the fact that what you made is useful enough to people that they choose your product because you are obsessed with making a good work?John Carmack has talked about it in a podcast a few years ago, and he's the closest popular programmer that I can think of who was simply obsessed with milking every tiny ounce of GPU performance, yet none of his effort would matter if Doom and Quake weren't fun games.
by Thanemate
3/31/2026 at 6:07:51 PM
That's true, but I think there is a gray area in between. As things scale up in one way or another, having high quality is important for both #1 and #2. Its hard to extend software that was designed poorly.The question where experience comes in is when quality is and isnt worth the time. I can create all sorts of cool software I couldn't before because now I can quickly pump out "good enough" android apps or react front ends! (Not trying to denigrate front end devs, it's just a skill I dont have)
by roland35
3/31/2026 at 7:02:28 PM
> it's hard to talk about this stuff if we're not clear on which types of projects we're talking about.It mystifies me when people don't intuit this.
For any suitably sized project, there are parts where elegance and friction removal are far more important than others. By an order or two of magnitude.
I have shipped beautifully-honed, highly craft code. Right alongside jank that was debugged in the "Well it seems to work now" and "Don't touch anything behind this in-project PI" category.
There are very good reasons and situations for both approaches, even in one project.
by Nevermark
3/31/2026 at 8:28:05 PM
It’s much more complex. Part of your value as an engineer is having a good feel for balancing the trade offs on your code.Code is usually a liability. A means to an end. But is your code going to run for a minute, a month, a year, or longer? How often will it change? How likely are you going to have to add unforeseen features? Etc. Etc. Etc.
by Waterluvian
3/31/2026 at 8:13:59 PM
It is possible to exist in both camps. The quality of the process affects the quality of the product, and the quality of your thought affects the quality of the process. It's a cycle of continual learning, and from that perspective, thought, process and product are indivisible.Treating code as a means to an end doesn't guarantee success for your product anymore than treating code as a craft.
by pm
3/31/2026 at 7:00:06 PM
I think type1 vs type2 dev requirements are also dependent on lifecycle / scale of your project, not just that its library / framework / mission critical software.If you aren't even sure if your idea is even gonna work, whether you have PMF, or the company will be around next year.. then yeah.. speed over quality all day long.
On the other hand, I've never done the startup thing myself, and tend to work on software project with 10-20 year lifecycles. When code velocity maximalism leads to outages, excess compute cost and reputational issues.. good code matters again.
Re: "No one has ever made a purchasing decision based on how good your code is." Sonos very much could go out of business for agreeing with this line. I can tell you lots of people stopped buying their products because of how bad their code quality became with the big app change debacle. Lost over a decade of built up good will.
Apple is going through this lately with the last couple major OS releases across platforms and whatever is going on with their AI. This despite having incredible hardware.
by steveBK123
3/31/2026 at 8:07:43 PM
> With that said, I do have respect for people in the latter camp.Well, you certainly should. Those people made AI based coding a possibility in the first place.
by amelius
3/31/2026 at 8:27:43 PM
> The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster.I'm weird, I'm part of camp 2, but I think AI can be used to really craft some interesting things. While I appreciate camp 1, camp 2 is what produces better codebases that are easier to maintain, myself and others have realized, that the best practices for humans are also the best practice for AI models to fit your code.
by giancarlostoro
3/31/2026 at 8:41:58 PM
Yes great so we sell shit. No one buys a ticket because ofnhow safe the 737 Max plane is or buys a post office franchise based on how good the software Fujitsu sold the post office is, but fuck lets take some pride in outselves and try to ship quality work.by mememememememo
3/31/2026 at 8:12:46 PM
I think this is a false dichotomy. If you're passionate about your craft, you will make a higher quality product. The real division is between those who measure the success of a project in:- revenue/man-hour, features shipped/man-hour, etc.
- ms response time, GB/s throughput, number of bugs actually shipped to customers, etc.
People in the second camp use AI, but it's a lot more limited and targeted. And yes, you can always cut corners and ship software faster, but it's not going to be higher quality by any objective metric.
by fasterik
3/31/2026 at 8:19:33 PM
I think this is a false dichotomy. Maybe there is some theoretical developer who cares about their craft only due to platonic idealism, but most developers who care about their craft want their code to be correct, fast, maintainable, usable, etc. in ways that do indeed benefit its users. At worst, misalignment in priorities can come into play, but it's much more subtle than developers either caring or not caring about craft.by peacebeard
3/31/2026 at 6:45:36 PM
I think "make a product" is the important point of disagreement here. AI can generate code that users are willing to pay for, but for how long? The debate is around the long-term impact of these short-term gains. Code _is_ a means to an end, but well-engineered code is a more reliable means than what AI currently generates. These are ends of a spectrum and we're all on it somewhere.You ever notice how everyone who drives slower than you is a moron and everyone who drives faster than you is a maniac? Your two camps have a similar bias.
by allknowingfrog
3/31/2026 at 7:50:57 PM
I view every single line of code as a liability, the best solution is if you can avoid writing any code. Does that put me into group 1 or group 2?by dirkc
3/31/2026 at 7:59:17 PM
> No one has ever made a purchasing decision based on how good your code isBecause the ones that sell crappy code don’t sell to people that can tell the difference.
You think I’d pay for Jira or Confluence if it wasn’t foisted upon me by a manager that has got it in with the Atlassian sales rep?
I don’t even need to see Atlassian’s source code to know it’s sh*t.
by throwatdem12311
3/31/2026 at 8:17:20 PM
It's easy to write off critics of this slop development as just "caring about the wrong thing", but that is couched in incorrect assumptions. This is the unfortunately common mistake of confusing taking responsibility with some sort of "caring about the code" in an artistic sense. I can certainly appreciate the artistry of well-written code, but I care about having a solid and maintainable code-base because I am accountable for what the code I write does.Perhaps this is an antiquated concept which has fallen out of favor in silicon valley, but code doesn't just run in an imaginary world where there are no consequences and everything is fun all the time. You are responsible for the product you sell. If you sell a photo app that has a security bug, you are responsible for your customers nude photos being leaked. If you vibe-code a forum and store passwords in plaintext, you are responsible for the inevitable breech and harm.
The "general public" might not care, but that is only because the market is governed by imperfect information. Ultimately the public are the ones that get hurt by defective products.
by solid_fuel
3/31/2026 at 7:45:32 PM
> No one has ever made a purchasing decision based on how good your code is.I routinely close tabs when I sense that low-quality code is wasting time and resources, including e-commerce sites. Amazon randomly cancelled my account so I will never shop from them. I try to only buy computers and electronics with confirmed good drivers. Etc.
by yobbo
3/31/2026 at 6:12:19 PM
> The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster.I am in both camps. Always have been.
Code janitors about to be in high demand. We’ve always been pretty popular with leadership and it’s gonna get even more important.
Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things
My output is org velocity.
by Swizec
3/31/2026 at 6:40:43 PM
> Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking thingsI'm currently of the opinion that humans should be laser focused on the data model. If you've got the right data model, the code is simpler. If you've got the relevant logical objects and events in the database with the right expressivity, you have a lot of optionality for pivoting as the architecture evolves.
It's about that solid foundation - and of course lots of tests on the other side.
by joshmarlow
3/31/2026 at 8:41:24 PM
> I 'm currently of the opinion that humans should be laser focused on the data modelyes. good programmers talk about data structures, bad programmers talk about code
by Swizec
3/31/2026 at 6:47:25 PM
How do you even converge on the right data model without refining code? Elegant code and elegant data model are the exact same thing!by JambalayaJimbo
3/31/2026 at 6:51:15 PM
It's called "systems analysis". Programmers are generally pretty terrible at it because it requires holistic, big-picture thinking. But it used to take up the bulk of the design activity for a new enterprise system.by bitwize
3/31/2026 at 6:42:21 PM
I agree and I like how you describe it. The phrase from Django, "perfectionists with deadlines", also resonates with me.by benatkin
3/31/2026 at 6:19:33 PM
> My output is org velocity.Amen, slow and steady and the feature fly wheel just keeps getting faster.
by acedTrex
3/31/2026 at 6:23:09 PM
>slop cannonsI am stealing that phrase haha
by seamossfet
3/31/2026 at 8:19:56 PM
false dichotomy - you need to care about both.by squidsoup
3/31/2026 at 6:47:16 PM
> No one has ever made a purchasing decision based on how good your code is.There are two reasons for this. One is that the people who make purchasing decisions are often not the people who suffer from your bad code. If the user is not the customer, then your software can be shitty to the point of being a constant headache, because the user is powerless to replace it.
The other reason is that there's no such thing as "free market" anymore. We've been sold the idea that "if someone does it better, then they'll win", but that's a fragile idea that needs constant protection from bad actors. The last time that protection was enacted was when the DOJ went against Microsoft.
> Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively.
Any semblance of accountability for that has been diluted so much that it's not worth mentioning. A bug someone wrote into some cloud service can end up causing huge real-world damage in people's lives, but those people are so far removed from the suits that made the important decisions that they're powerless to change anything and won't ever see that damage redressed in any way.
So yeah, I'm in camp #2 and I'm bitter about AI, because it's just accelerating and exacerbating the enshittification.
Someone on the HN wrote recently that everyone who's foaming at the mouth about how AI helps us ship faster is forgetting that velocity is a vector -- it's not just about how fast you're going, but also in what direction.
I'd go further and say that I'm not even convinced we're moving that much faster. We're just cranking out the code faster, but if we actually had to review that code properly and make all the necessary fixes, I'm pretty sure we would end up with a net loss of velocity.
by CodeMage
3/31/2026 at 8:09:07 PM
>No one has ever made a purchasing decision based on how good your code is.That's however what makes for stable systems, deep knowledgable engineers, and structurally building the basis for the future.
If all you care about is getting money for your product slop, it's not different than late night marketed crap, or fast fashion...
by coldtea
3/31/2026 at 6:45:57 PM
This is a very useful insight. It nicely identifies part of the reason for the stark bifurcation of opinion on AI. Unfortunately, many of the comments below it are emotional and dismissive, pointing out its explanatory limitations, rather than considering its useful, probative value.by quantummagic
3/31/2026 at 8:23:28 PM
I find most home inspectors fall into one of two camps:1. You treat the house as a means to an end to make a living space for a person.
2. You treat the building construction itself as your craft, with the house being a vector for your craft.
The people who typically have the most negative things to say about buildings fall into camp #2 where cheap unskilled labor is streamlining a large part of what they considered their art while enabling people in group #1 to iterate on their developments faster.
Personally, I fall into the first camp.
No one has ever made a purchasing decision based on how good the pipes inside the walls are.
The general public does not care about anything other than the square footage and color of your house. Sure, if you mess up and one of the houses collapses then that'll manifest as an outcome that impacts the home owner negatively.
With that said, I do have respect for people in the latter camp. But they're generally best fit for homes where that level of craftsmanship is actually useful (think: mansions, bridges, roads, things I use, etc).
I just feel like it's hard to talk about this stuff if we're not clear on which types of construction we're talking about.
by solid_fuel
3/31/2026 at 8:35:20 PM
The general public does not know how to identify or care about the pipes in the walls. They do care when they bust and cause tens of thousands of dollars of damage. Thats why they hire someone with a keen eye to it to act on their behalf.by Gigachad
3/31/2026 at 7:14:04 PM
"I have an opinion and everyone on the planet agrees with me, if you disagree, you don't matter" is not a useful insight, and is, in fact, far more emotional and dismissive than any of the replies to it.by bakugo
3/31/2026 at 7:54:35 PM
That's a horribly broken misrepresentation of what was said in the original post. If that's what you took away from it, you're not reading carefully or critically.by quantummagic
3/31/2026 at 8:38:49 PM
[dead]by ratrace
3/31/2026 at 8:26:20 PM
With AI you actually don't need to choose anymore. Well laid out abstractions actually make AI generate code faster and more accurately. Spending the time in camp 2 to design well and then using AI like camp 1 gives you the best of both worlds.by theredsix
3/31/2026 at 6:43:44 PM
> No one has ever made a purchasing decision based on how good your code is.If you have buggy software, people don’t use it if there are alternatives. They don’t care about the code but hard to maintain, buggy code will eventually translate to users trying other products.
by yakattak
3/31/2026 at 7:04:08 PM
You need both to be a great software engineer. The "means to an end" people will happily slop out PRs and let the "craft" people worry about it.by JambalayaJimbo
3/31/2026 at 7:50:00 PM
I'm going to re-characterize your categorization:1. The people who don't understand (nor care) about the risks and complexity of what they're delivering; and
2. The people that do.
Widespread AI usage is going to be a security nightmare of prompt injection and leaking credentials and PII.
> No one has ever made a purchasing decision based on how good your code is.
This just isn't true. There's a whole process in purchasing software, buying a company or signing a large contract called "due diligence". Due diligence means to varying degree checking how secure the product is, the company's processes, any security risks, responsiveness to bugfixes, CVEs and so on.
AI is going to absolutely fail any kind of due diligence.
There's a little thing called the halting problem, which in this context basically means there's no way to guarantee that the AI will be restricted from doing anything you don't want it to do. An amusing example was an Air Canada chatbot that hallucinated a refund policy that a court said it had to honor [1].
How confident are we going to be that AIs won't leak customer information, steal money from customers and so on? I'm not confident at all.
[1]: https://arstechnica.com/tech-policy/2024/02/air-canada-must-...
by jmyeet
3/31/2026 at 7:47:15 PM
3. You use the act of writing code to think about a given problem, and by so doing not only produce a better code, but also gain a deeper understanding of the problem itself - in combination a better product all around.by somewhereoutth
3/31/2026 at 7:00:42 PM
Now you done it! Yeah, one of the difficult things is being able to see both sides. At the end of the day, I happen to write code because that's how I can best accomplish the things I need to do with the minimum of effort. While I do take pride in elegance and quality of code, it is always a means to an end. When I start gold plating, I try to remind myself of the adage I learned in a marketing class: No one ever needed a drill, they needed the ability to make holes.It is strange, but not really upsetting to me, that I am not particularly anal about the code Claude is generating for me anymore but that could also be a function of how low stakes the projects are or the fact nothing has exploded yet.
by tclancy
3/31/2026 at 7:08:06 PM
You realize you’re essentially building a false dichotomy? I work in video games where code really is a means to an end but still see that authorship is important even if that code is uuuuugly due to it being the expression of the game itself. From that perspective I’m neither worried about craft or product but my ability to express myself though code as the game behaves. Although if you really must have only two categories I’d be in camp one.As such AI is a net negative as it would be in writing a novel or making any other kind of art.
by meheleventyone
3/31/2026 at 8:03:49 PM
3. Coding is fun, prompting not so muchby ggregoire
3/31/2026 at 7:17:30 PM
I generally fall into the first camp, too, but the code that AI produces is problematic because it's code that will stop working in an unrecoverable way after some number of changes. That's what happened in the Anthropic C compiler experiment (they ended up with a codebase that wasn't working and couldn't be fixed), and that's what happens once every 3-5 changes I see Codex making in my own codebase. I think, if I had let that code in, the project would have been destroyed in another 10 or so changes, in the sense that it would be impossible to fix a bug without creating another. We're not talking style or elegance here. We're talking ticking time bombs.I think that the real two camps here are those who haven't carefully - and I mean really carefully - reviewed the code the agents write and haven't put their process under some real stress test vs those who have. Obviously, people who don't look for the time bombs naturally think everything is fine. That's how time bombs work.
I can make this more concrete. The program wants to depend on some invariant, say that a particular list is always sorted, and the code maintains it by always inserting elements in the right place in the list. Other code that needs to search for an element depends on that invariant. Then it turns out that under some conditions - due to concurrency, say - an element is inserted in the wrong place and the list isn't sorted, so one of the places that tries to find an element in the list fails to find it. At that point, it's a coin toss of whether the agent will fix the insertion or the search. If it fixes the search, the bug is still there for all the other consumers of the list, but the testing didn't catch that. Then what happens is that, with further changes, depending on their scope, you find that some new code depends on the intended invariant and some doesn't. After several such splits and several failed invariants, the program ends up in a place that nothing can be done to fix a bug. If the project is "done" before that happens - you're in luck; if not, you're in deep, deep trouble. But right up until that point, unless you very carefully review the code (because the agents are really good at making code seem reasonable under cursory scrutiny), you think everything is fine. Unless you go looking for cracks, every building seems stable until some catastrophic failure, and AI-generated code is full of cracks that are just waiting for the right weight distribution to break open and collapse.
So it sounds to me that the people you think are in the first camp not only just care how the building is built as long as it doesn't collapse, but also believe that if it hasn't collapsed yet it must be stable. The first part is, indeed, a matter of perspective, but the second part is just wrong (not just in principle but also when you actually see the AI's full-of-cracks code).
by pron
3/31/2026 at 8:19:26 PM
It can be especially bad if the architecture is layered with each one having its own invariant. Like in a music player, you may have the concept of a queue in the domain layer, but in the UI layer you may have additional constraints that does not relate to that. Then the agent decide to fix a bug in the UI layer because the description is a UI bug, while it’s in fact a queue bugby skydhash
3/31/2026 at 8:39:42 PM
Shit like this is why you really have to read the plans instead of blindly accepting them. The bots are naturally lazy and will take short cuts whenever they think you won't notice.by mikkupikku
3/31/2026 at 8:45:59 PM
As developers we have a unique advantage over everybody else dealing with the way AIgen is revolutionizing careers:Everybody else is dealing with AIgen is suffering the AI spitting out the end product. Like if we asked AI to generate the compiled binary instead of the source.
Artists can't get AIgen to make human-reviewed changes to a .psd file or an .svg, it poops out a fully formed .png. It usurps the entire process instead of collaborating with the artist. Same for musicians.
But since our work is done in text and there's a massive publicly accessible corpus of that text, it can collaborate with us on the design in a way that others don't get.
In software the "power of plain text" has given us a unique advantage over kinds of creative work. Which is good, because AIgen tends to be clumsy and needs guidance. Why give up that advantage?
by Pxtl
3/31/2026 at 7:43:29 PM
This is absolutely false. The purpose of craft is a make a good product.I don’t care what kind of steel you used to design my car, but I care a great deal that it was designed well, is safe, and doesn’t break down all the time.
Craft isn’t a fussy thing.
by coffeefirst
3/31/2026 at 6:34:51 PM
It's perfectly possible to write very clean code with AI, it just takes a lot more time and prompting.by logicchains
3/31/2026 at 8:38:59 PM
Easier to just write it yourself.by Gigachad
3/31/2026 at 7:57:40 PM
I was just using an app that competes with airbnb. That the app's code is extraordinarly unreliable was a significant factor in my interactions with others on the app, especially, I gradually realized I couldn't be sure messages were delivered or data was up-to-date.That influenced some unfortunate interactions with people and meant that no one could be held to their agreements since you never knew if they received the agreements.
So, well, code quality kind of matters. But I suppose you're still right in a sense - currently people buy and use complete crap.
by joe_the_user
3/31/2026 at 7:23:58 PM
> No one has ever made a purchasing decision based on how good your code is. The general public does not care about anything other than the capabilities and limitations of your product.The capabilities and limitations of your product are defined in part by how good the code is. If you write a buggy mess (whether you write it yourself or vibe code it), people aren't going to tolerate that unless your software has no competitors doing better. People very much do care about the results that good code provides, even if they don't care about the code as an end in itself.
by bigstrat2003
3/31/2026 at 6:58:24 PM
While creating good software is as much of an art as it is a science, this is not why the craft is important. It is because people who pay attention to detail and put care into their work undoubtedly create better products. This is true in all industries, not just in IT.The question is how much does the market value this, and how much it should value it.
For one-off scripts and software built for personal use, it doesn't matter. Go nuts. Move fast and break things.
But the quality requirement scales proportionally with how many people use and rely on the software. And not just users, but developers. Subjective properties like maintainability become very important if more than one developer needs to work on the codebase. This is true even for LLMs, which can often make a larger mess if the existing code is not in good shape.
To be clear, I don't think LLMs inevitably produce poor quality software. They can certainly be steered in a good direction. But that also requires an expert at the wheel to provide good guidance, which IME often takes as much, if not more, work than doing it by hand.
So all this talk about these new tools replacing the craft of programming is overblown. What they're doing, and will continue to do unless some fundamental breakthrough is reached, is make the creation of poor quality software very accessible. This is not the fault of the tools, but of the humans who use them. And this should concern everyone.
by imiric
3/31/2026 at 6:10:09 PM
I agree on the software dev camps.> The general public does not care about anything other than the capabilities and limitations of your product.
It's absolutely asinine to say the general public doesn't care about the quality and experience of using software. People care enough that Microsoft's Windows director sent out a very tail-between-legs apology letter due to the backlash.
It's as it always has been, balancing quality and features is... well, a balance and matters.
by packetlost
3/31/2026 at 6:13:33 PM
The public doesn't care about the code itself, they absolutely care about the quality and experience of using the software.But you can have an extremely well designed product that functions flawlessly from the perspective of the user, but under the hood it's all spaghetti code.
My point was that consuming software as a user of the product can be quite different from the experience of writing that software.
Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product.
I'd just be careful to separate code elegance from product experience, since they are different. Related? Yeah, sure. But they're not the same thing.
by seamossfet
3/31/2026 at 6:20:24 PM
There are other players in the game: the business and the market.Good code makes it easier for the business to move fast and stay ahead of the competition while reducing expenses for doing so.
by blackbear_
3/31/2026 at 8:00:03 PM
That's true, but excel '98 would still cover probably 80% of users use cases.A lot, and I mean a lot, of software work is trying to justify existence by constantly playing and toying with a product that worked for for everyone in version 1.0, whether it be to justify a job or justify charging customers $$ per month to "keep current".
by WarmWash
3/31/2026 at 6:19:49 PM
That's fair!> Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product.
I'm sure that's the case in basically everything, it sorta doesn't matter (until it does) if it's cordoned off into a corner that doesn't change and nominally works from the outside perspective.
But those cases are usually isolated, if they aren't it usually quickly becomes noticeable to the user in one way or another, and I think that's where these new tools give the illusion of faster velocity.
If it's truly all spaghetti underneath, the ability to make changes nosedives.
by packetlost
3/31/2026 at 6:50:52 PM
I have yet to meet anyone whose problem with AI is that the code is not aesthetically pleasing, but that would actually be an indicator to me that people are using these things responsibly.My own two cents: there's an inherent tension with assistants and agents as productivity tools. The more you "let them rip", the higher the potential productivity benefits. And the less you will understand the outputs, or even if they built the "correct thing", which in many cases is something you can only crystalize an understanding about by doing the thing.
So I'm happy for all the people who don't care about code quality in terms of its aesthetic properties who are really enjoying the AI-era, that's great. But if your workload is not shifting from write-heavy to read-heavy, you inevitably will be responsible for a major outage or quality issue. And moreso, anyone like this should ask why anyone should feel the need to employ you for your services in the future, since your job amounts to "telling the LLM what to do and accepting it's output uncritically".
by almostdeadguy
3/31/2026 at 7:04:38 PM
>But if your workload is not shifting from write-heavy to read-heavy, you inevitably will be responsible for a major outage or quality issue.I think that's actually a good way to look at it. I use AI to help produce code in my day to day, but I'm still taking quite a while to produce features and a lot of it is because of that. I'm spending most of my time reading code, adjusting specs, and general design work even if I'm not writing code myself.
There's no free lunch here, the workflow is just different.
by seamossfet
3/31/2026 at 6:32:41 PM
Facebook.com is a monstrosity though, and their mobile apps as well are slow and often broken. And the younger generations are using other networks, Facebook is in trouble.by slopinthebag
3/31/2026 at 6:11:47 PM
> You treat your code as a means to an end to make a product for a user.It isn’t that though, the “end” here is making money not building products for users. Typically people who are making products for users cares about the craft.
If the means-to-end people could type words into a box and get money out the other side, they would prefer to deal with that than products or users.
Thats why ai slop is so prevalent — the people putting it out there don’t care about the quality of their output or how it’s used by people, as long as it juices their favorite metrics - views, likes, subscribes, ad revenue whatever. Products and users are not in scope.
by ModernMech
3/31/2026 at 6:20:49 PM
Yeah, I'm not trying to defend slop.I don't think all means-to-end people are just in it for money, I'll use the anecdote of myself. My team is working on a CAD for drug discovery and the goal isn't to just siphon money from people, the goal is legitimately to improve computational modeling of drug interactions with targets.
With that in mind, I care about the quality of the code insofar as it lets me achieve that goal. If I vibe coded a bunch of incoherent garbage into the platform, it would help me ship faster but it would undermine my goal of building this tool since it wouldn't produce reliable or useful models.
I do think there's a huge problem with a subset of means-to-end people just cranking out slop, but it's not fair to categorize everyone in that camp this way ya'know?
by seamossfet
3/31/2026 at 6:33:44 PM
This is just cope to avoid feeling any shame for shipping slop to users.by slopinthebag