Get the top HN stories in your inbox every day.
seamossfet
nocman
> 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.
latexr
> 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.
doug_durham
I agree with OP's distinction. However just because you see software as a means to an ends, doesn't mean that you don't feel that quality and craft are unimportant. You can see the "craft" oriented folks as being obsessed with the form of their software. A "craft" oriented engineer might rewrite a perfectly functioning piece of software to make it what they perceive to be "easier to reason about". I consider most software rewrites to be borderline malpractice.
bit-anarchist
That example doesn't work well. All regulations come at the cost of freedom, and every freedom comes at the cost of regulations. While it isn't a strict binary (either 100% freedom or 100% regulation), enacting regulations do interfere with freedom. So this isn't just framing, it demonstrates a relationship between the two concepts, which may become relevant down in the discussion, if it already hasn't.
ttamslam
> 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.
westoncb
>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.
arijun
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).
Xirdus
Good abstractions translate directly into how quickly the devs can fix bugs and add new features.
jimbokun
The single line single character program, after a certain level of complexity, will no longer have the same behavior because it cannot be maintained.
If it’s software that will never be modified, sure it doesn’t matter.
skydhash
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.
mbesto
> obviously created by people the care deeply about the quality of the product they produce
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.
> 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.
MrRadar
> 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.
Terr_
> 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?
tkiolp4
SAP, Salesforce, Booking.com… all awful products. We use them because monopolies.
jimbokun
Now imagine how much they would make if their software was good.
Google, Facebook, Apple clearly care deeply about the quality of their code. They have to because bugs, bad performance, outages, vulnerabilities have very direct and immediate costs for them. I know Amazon and Microsoft have their critics but I bet they are also better than we give them credit for.
There are factors besides software quality that affect their success. But running bad software certainly isn’t going to help.
theshrike79
> You're right because there really isn't a consistent definition of what "high quality" software work looks like.
And if you can deterministically define "high quality software" with linters, analysers etc - then an AI Agent can also create high quality software within those limits.
delbronski
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.
jimbokun
I believe a lot if large software companies like Google, Facebook, Apple, Netflix, Microsoft have very high quality code. Past a certain level of complexity, bad code will just collapse under the weight of its low quality.
allajfjwbwkwja
There's a lot of space between web dev and medical equipment. I've never met a user that loved how often their work was lost or how long it took to implement feature requests amid all the ship-it-quick duct tape.
girvo
> then code quality just doesn’t really matter so much in the age of AI
Except at scale it really does, because garbage in garbage out. The crappier the code you feed the current models, the worse and more confusing the broken leaky abstractions, the more bugs the AI will generate.
layer8
The question is whether it has to be that way. Developers who are against slop don’t believe that the current state of software is the best possible world.
tau5210
Thank you for putting out a clear message. I completely agree.
> parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
and of course, this isn't even the worst. A lot worse can happen, such as data loss and corruption. Things that can directly affect people's lives in real life.
As a developer, these things are constantly on my mind, and I believe this is the case for people who do care about the quality.
As has been said elsewhere many times, AI producing code is not the same as say, a compiler producing machine code. It is not such a well-defined strong abstraction, hence why code quality still is highly relevant.
It is also easily forgotten that code is as much a social construct (e.g. things that have to be done in certain ways due to real life restrictions, that you wouldn't have to do in an ideal world).
Sometimes I feel very powerless though. It feels as if some of us are talking past each other, even if we seemingly are using the same words like "quality". Or in a way, that is what makes this more futile-- that we are using the same words and hence seemingly talking about the same thing, when we are referring to completely different things.
It is difficult to have a conversation about a problem when some of us don't even see it as a problem to begin with-- until it reaches a point when it starts affecting their lives as well, whether it be directly or indirectly. But that takes time.
Time will tell.
steveBK123
> 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.
ttamslam
> but not contemplating that it's going to be out in the wild for 10 years either way
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.
boplicity
> There is no substitute for high quality work.
That's where you get it wrong. The world is full of mediocre and low quality work in many, many fields. We all, in fact, depend on mediocre work in many ways.
Many, many people would prefer a solution with mediocre or even bad code than no solution at all while they wait for "high quality work" that never appears.
The magic of LLMs, especially as the technolgy improves, is that a truly mind boggling number of solutions to problems will be created with thoroughly mediocre (or worse!) LLM generated code. And the people benefitting from those solutions won't care! They'll be happy their problems are being solved.
deaux
No, you see, this is impossible, as I've been taught here on HN by the wise elders over and over. As soon as a pristine codebase is tainted by even 1% of LLM-generated code, any chance at potential user value instantly disintegrates. Especially if it claims to do anything remotely novel!
But seriously, the denial is incredible to watch. Our product wouldn't exist without LLMs, and our users are vocally thankful that it does, saving them time and money and helping them reach their offline goals.
[0] https://news.ycombinator.com/item?id=47505428
[1] https://news.ycombinator.com/item?id=47476893
Among countless others
strogonoff
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”.
iamcalledrob
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.
Benjammer
> 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?
iamcalledrob
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.
tabwidth
How long does that take though? Technical debt from sloppy code doesn't show up in the product until way later. By the time users notice, the team is already three features deep and can't back out.
FridgeSeal
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.
SpicyLemonZest
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.
theossuary
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.
bloppe
Yes, both the article and GP are making that exact point about it mattering from a customer's perspective.
undefined
Darmani
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.
mkehrt
> 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.
Speak for yourself. This is exactly the GPs point. Some people care more about the craft of code than the output. I personally find writing good code to be what motivates me. Obviously its a spectrum; shipping is good too. But it's not why I get up in the morning.
Darmani
Okay, I admit I went too hard on that one to fight against the OP. I too get extreme pleasure from condensing a 300-line function into 30 lines of simplicity, even when practical considerations (it has a clean interface and no-one's even needed to open this file in 2 years) would dictate elegance there is not helpful.
doug_durham
Code quality is a side-effect of caring. The most important part of product design is caring at all levels. However it's caring about the external details that is the most important. Coding language is largely a function of the population of good coders in your areas. Code evolvability is almost entirely subjective.
Darmani
> Code evolvability is almost entirely subjective
Explain how?
Code evolvability is one of the extrinsic quality markers ( https://www.pathsensitive.com/2023/07/the-11-aspects-of-good... ).
If it's easy to add new features without creating bugs, the code is evolvable. Else, it's not. Does not seem very subjective.
ambicapter
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.
renewiltord
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.
clan
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.
jstanley
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.
couchand
I think camp 1 would rather see ten useless things than one useful thing.
ytoawwhra92
> I think camp 2 would rather see one beautiful thing than ten useful things.
Unashamedly, I would, but this is a false dilemma. We can have ten beautiful and useful things.
The thing that drives the camp 2 folk crazy is that often it would have taken no extra effort (or perhaps even less effort overall) to make a good version of the thing but the people who made thing simply couldn't be bothered.
The attitude you're describing here has led directly to our world being full of profoundly disappointing objects that proliferate because they meet a minimum bar of usefulness.
People don't like the minimum bar. They'll take it if it's the only thing on offer, but they like better things.
undefined
d0mine
I don't get how camp 1 can ship more than one version (do they jump teams/companies each time?). If your code is immovable mess then how do you add features/fix bugs in time?
Imustaskforhelp
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.)
ambicapter
> 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.
globular-toast
You are not your job. Take pride in your work. Be kind to others. This is the true path.
xienze
> If it's harder to work with, it's harder to work with, it's not the end of the world.
Yeah it just takes longer and makes you miserable in the process. No biggie!
ytoawwhra92
People with this attitude never end up maintaining anything. When projects get to that phase the work becomes too difficult and boring for them, so they decide that they've "set the team up for long-term success" and move on to a new opportunity.
jmyeet
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-...
bloppe
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.
9rx
> It can get pretty hairy when you already have well-established customers with long-term use-cases that absolutely cannot be broken
LLMs are often poor at writing tests that provide useful information to human readers and poor at writing tests that can survive project evolution. To be fair, humans are also poor at these tasks if done in hindsight, after all the information you normally want to capture in tests has been forgotten. That boat has been missed for the legacy code no matter how you slice it. But LLMs are quite good at writing tests that lock in existing functionality in the rawest way. It seems like LLM-generation is actually the best hope of saving such a project?
davnicwil
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.
carlosjobim
Millions of companies work out of spreadsheets, which is incredibly low quality and inefficient code by programming standards (not Excel, but the spreadsheet itself).
Would those companies be better off just using pen and paper? Because "craft code" programmers don't have time for this, and not all companies can pay for bespoke software. Well, maybe now they can, with AI "slop".
Likewise, should people who don't have the skills or means to cook delicious and nutritious meals just starve without food? Or is it okay that they eat something which isn't perfect?
davnicwil
With respect I'm not sure what you're saying follows as a challenge to what I've said. Perhaps because I didn't phrase clearly enough.
I don't think that. In fact I spent years at a company whose product let people build software backed by spreadsheets so I'm at least a little acquainted with that corner of the world :-)
The thing I'm saying is that among those who want to engage in building software via coding, I don't accept that caring about coding craft and caring about building great products that solve problems for people are opposing points on a spectrum.
If anything I'd argue the opposite, that these qualities are correlated. Again, speaking about people who are interested in building software with code.
I think the thing of building useful software with software (like spreadsheets / AI builders) while deliberately not wanting to engage with coding is a discussion apart from this. There's apparent overlap because it's true to say that those people are concerned with building useful things and not necessarily concerned with coding. But the fact they're not concerned with coding by definition puts them out the scope of the first conversation, it's just a different thing.
Animats
Meanwhile, the complexity of the average piece of software is drastically increasing. ... The stats suggest that devs are shipping more code with coding agents. The consequences may already be visible: analysis of vendor status pages [3] shows outages have steadily increased since 2022, suggesting software is becoming more brittle.
We've already seen a large-scale AWS outage because of this. It could get much worse. In a few years, we could have major infrastructure outages that the AI can't fix, and no human left understands the code.
AI coders, as currently implemented, don't have a design-level representation of what they're doing other than the prompt history and the code itself. That inherently leads to complexity growth. This isn't fundamental to AI. It's just a property of the way AI-driven coding is done now.
Is anybody working on useful design representations as intermediate forms used in AI-driven coding projects?
"The mending apparatus is itself in need of mending" - "The Machine Stops", by E.M. Forster, 1909.
switchbak
I think we're heading for a real crisis here. We've got an imperfect system of constraints and bottlenecks, and we've just eliminated one of the main bottlenecks - the speed at which we can add new code. This just puts so much more strain on the rest of the system, I think the industry is going to have a quick lesson on the non-linear costs of software complexity.
I'm glad to see that the author of the article is putting an emphasis on simplicity here, especially given the nature of their business. Those that fully embrace the "code doesn't matter" approach are in for a world of hurt.
Long-term, I expect there will be more tooling and model advancements to help us in this regard - and there will certainly be a big economic incentive for that soon. But in the meantime it feels like a dam has been breached and we're just waiting for the real effects to become manifest.
Cthulhu_
I was curious about the claim about those vendor status pages, wondering if there's postmortems that actually single out AI. The source cited as [3] is a Reddit post with a poorly cropped chart, and it doesn't include any data from before 2022: https://www.reddit.com/r/sysadmin/comments/1o15s25/comment/n...
I'm not saying it's wrong, because I haven't actually looked for alternative sources, just that the source isn't great.
bootsmann
Amazon holds engineering meeting following AI-related outages - Financial Times https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f77...
mpweiher
> AI coders, as currently implemented, don't have a design-level representation of what they're doing other than the prompt history and the code itself.
That new design-level representation will be code.
It will need to be code, because prompts, while dense, are not nearly deterministic enough.
It will need to be much higher level code, because current code, while deterministic, is not nearly dense enough.
brandensilva
Even the prompt history is notoriously weak given how little Claude Code and some of the others display to give developers confidence in the process.
There needs to me more design rep indeed.
tdeck
Claude Code displays plenty in my opinion, if you make it ask you for approval before each code change. You can read the code as it's being built up and understand if it's going in a bad direction before it does that and then piles on more and more slop.
The trouble is people don't want to bother reviewing the changes.
LoganDark
Claude Code used to stream the thinking process in verbose mode. Now that has been replaced with "transcript mode" which doesn't actually give much more information and also doesn't stream anything. They also recently removed (in certain situations) the counter of how many tokens the model's generated in its response in progress, so the only way to tell if it's stuck is to wait 10 minutes and then retry.
Sure, I can read the diffs as they're generated (and I do). But proper transparency goes further than that, and it's being stripped away.
9dev
While I also view this development critically, why do you assume AI will be unable to fix the issues eventually?
yoyohello13
Whether they can or not in the future is kind of irrelevant. The fact is that right now they are not able to, but many are using them as if they are.
mycall
I tend to disagree. When guiding AI through many rounds of code review, it can self correct if shown where general issues exist. It does take practice for using the language of the model, i.e. drift instead of issues. Human in the loop is good enough to produce useful and accurate code today.
advael
At this point I can't help but conclude that to a certain class of writers, "economic incentives" are a form of benevolent god who will surely, inevitably make things better in directions they care about, and those who believe this also believe the overwhelming and constant evidence to the contrary of their position is just a temporary anomaly
Whatever the hell economics was supposed to do, right now it seems to be causing every industry to produce worse products, lay off more people, and concentrate wealth in an aristocratic subset of the population, and this has been going on for the better part of my entire lifetime. If we're to reverse this trend, we need to stop pretending that economics is a natural force and remember that it is a complex system made of policy decisions that can in fact be the wrong ones
cardanome
It also assumes free market competition which the AI space is already only in a very limited degree.
The whole business strategy for those companies is to be the one big monopolists that is left standing. That is why they are bleeding money offering token prices well beyond market rate so that they can grow.
Plus they can always lobby the state to ban foreign competition for security reasons.
nicbou
Economics is a natural force, but it does not specifically optimize for customer satisfaction.
advael
Complex systems having meaningfully describable properties doesn't intrinsically make those properties natural laws
rzmmm
And who knows what the economic incentives are in couple years. Maybe the focus shifts towards one-shotting complex million SLOC codebases which are order of magnitude more sloppy than the current outputs.
mcdeltat
But the free market! How could it be possible that the free market does not result in utopian society??? There MUST be a mistake
SwtCyber
Whatever system you design (market, regulated, hybrid) it still ends up creating incentives that shape behavior
username223
"I want to argue that AI models will write good code because of economic incentives. Good code is cheaper to generate and maintain."
This is possibly the dumbest version of an "economic incentives" argument. Current code is the result of current economic incentives. It is a mystery to me why making code generation cheaper will make it more "good" in any way, instead of being either more of what we have now, or worse.
reese_john
Why build each new airplane with the care and precision of a Rolls-Royce? In the early 1970s, Kelly Johnson and I [Ben Rich] had dinner in Los Angeles with the great Soviet aerodynamicist Alexander Tupolev, designer of their backfire Bear bomber. 'You Americans build airplanes like a Rolex watch,' he told us. 'Knock it off the night table and it stops ticking. We build airplanes like a cheap alarm clock. But knock it off the table and still it wakes you up.'...The Soviets, he explained, built brute-force machines that could withstand awful weather and primitive landing fields. Everything was ruthlessly sacrificed to cut costs, including pilot safety.
We don't need to be ruthless to save costs, but why build the luxury model when the Chevy would do just as well? Build it right the first time, but don't build it to last forever. - Ben Rich in Skunk Worksimiric
That's an interesting story, but not a great analogy for software.
If a technology to build airplanes quickly and cheaply existed and was made available to everyone, even to people with no aeronautical engineering experience, flying would be a much scarier ordeal than it already is.
There are good reasons for the strict safety and maintenance standards of the aviation industry. We've seen what can happen if they're not followed.
The fact that the software industry doesn't have similar guardrails is not something to celebrate. Unleashing technology that allows anyone to create software without understanding or even caring about good development practices and conventions is fundamentally a bad idea.
GuB-42
Soviet engineering wasn't sloppy. It was designed for robustness, loose tolerances and simplicity. It was well thought out design. In the same way that as much thought went into the cheap alarm clock than went into the Rolex watch, maybe even more so, the engineers just had different requirements.
It takes a lot of work to make cheap, low precision parts work together reliably. The Rolex has it easy, all the parts are precisely built at a great cost and everything fits perfectly. With the cheap alarm clock, you don't know what you will get, so you have to account for every possible defect, because you won't get anything better with your budget and the clock still needs to give you an idea about what time it is.
The parallel in software would be defensive programming, fault tolerance, etc... Ironically, that's common practices in critical software, and it is the most expensive kind of software to develop, the opposite of slop.
movpasd
There's a narrative that gets passed around in physics circles about how the Soviets were better at finding creative and analytical solutions than Americans, because of the relative scarcity of computing versus intellectual labour resources.
It would make sense to me that a parallel mechanism could apply to Soviet engineering. If material and technologically advanced capital are scarce, but engineers are abundant, you would naturally spend more time doing proper engineering, which means figuring out how to squeeze the most out of what you have available.
est
> Soviet engineering wasn't sloppy. It was designed for robustness, loose tolerances and simplicity
aka "fitting".
I wrote a blog on why Soviet-style engineering is bad https://blog.est.im/2026/stderr-04
haspok
Let me highlight this part:
> Everything was ruthlessly sacrificed to cut costs, including pilot safety.
If we translate this analogy back to AI driven software development, what would be the equivalent of "pilot safety"?...
kusokurae
Be very careful who sources your pacemaker.
kalaksi
And then everyone disagrees what counts as luxury in software.
dang
The authors updated their title so I've updated it here too. Previous title was "Good code will still win" - but it was leading to too much superficial discussion based entirely on the phrase "good code" in the title. It's amazing how titles do that!
(Confession: "good code will still win" was my suggestion- IIRC they originally had "Is AI slop the future?". You win some you lose some.)
Fraterkes
Never considered that the mods of this site are literally discussing with the people heading yc companies how to game their hn-titles for better interaction. How naive I am.
dang
We discuss these things all the time with people who email us whether they head yc companies or not.
dangisahomo
[dead]
simianwords
People are not emotionally ready to accept that certain layers of abstraction don’t need as much care and effort if they can be automated.
We are at the point where a single class can be dirty but the API of the classes should be clean. There’s no point reviewing the internals of a class anymore. I’m more or less sure that they would work as intended.
Next step is that of a micro service itself. The api of that micro service should be clean but internals may be however. We are 10% here.
yobbo
"The only reason people disagree with me is because they are emotionally deficient."
andersonpico
It goes from "llms can do everything as well or better to a human" to "quality doesn't really matter" really fast.
qsera
So may be a charitable interpretation could be that quality does not matter because LLMs can deal with any complexity that comes with the reduction in quality...
danielbln
It also went real fast from "GPT hallucinated a library, literally useless" to "this agent has created this entire service up to spec, no notes".
alt187
As opposed to me, who is perfectly rational.
yodsanklai
> the API of the classes should be clean
That's an issue I have with Claude actually. I found it very good at breaking abstractions to get the job done. This is what I'd call slope (more so than the class internals).
dcchambers
Does performance not matter?
What if your AI uses an O(n) algorithm in a function when an O(log n) implementation exists? The output would still be "correct"
keeda
> Does performance not matter?
No, unfortunately. In a past life, in response to an uptime crisis, I drove a multi-quarter company-wide initiative to optimize performance and efficiency, and we still did not manage to change the company culture regarding performance.
If it does not move any metrics that execs care about, it doesn't matter.
The industry adage has been "engineer time is much more expensive than machine time," which has been used to excuse way too much bloated and non-performant code shipped to production. However, I think AI can actually change things for the better. Firstly, IME it tends to generate algorithmically efficient code by default, and generally only fails to do so if it lacks the necessary context (e.g. now knowing that an input is sorted.)
More importantly though, now engineer time is machine time. There is now very little excuse to avoid extensive refactoring to do things "the right way."
NitpickLawyer
> Does performance not matter?
Performance can be a direct target in a feedback loop and optimised away. That's the easy part. Taking an idea and poof-ing a working implementation is the hard part.
simianwords
Also most performance optimisations exit at the microservice architecture level, or db and io level
paxys
As it stands today the average engineer is much more likely to ship an unoptimized algorithm than an AI.
inetknght
If it's not tested, it's not Engineered.
Test what you care about. If you care about performance, then test your performance. Otherwise performance doesn't matter.
simianwords
In most cases no. Bottleneck is usual IO.
pagecalm
Agreed on the economics side. Clean code saves you time and money whether a human or AI wrote it. That part doesn't change.
But I don't think the models are going to get there on their own. AI will generate a working mess all day long if you let it. The pressure to write good code has to come from the developer actually reviewing what comes out and pushing back. The incentive is there but it only matters if someone acts on it.
arnitdo
> AI will generate a working mess all day long if you let it. The pressure to write good code has to come from the developer actually reviewing what comes out and pushing back
You are reinventing the wheel again with yet another form of reinforcement learning. I don't use any form of LLM assistance for coding, but if I have to continually tell it what to do, how to do it, what not to do, what assumptions to make - I would rather stimulate my neurons more by doing that damn thing itself.
The narrative of "Yeah it will do everything, provided you tell it how to do everything!" seems baseless, personally. Even if you emulate the smartest human possible, can you emulate an idiot?
danielbln
You don't have to continually tell it, you tell it once, persist it as convention and move on with your life.
antdke
Yup - In the end, it’s still just a tool that adheres to the steering (or lack thereof) of the user.
socalgal2
When has this ever been true
Did the best processor win? no x86 is trash
Did the best computer language win? no (not that you can can pick a best)
The same is true pretty much everywhere else outside computers, with rare exception.
stephc_int13
The economic angle is not as clear cut as the authors seem to think.
There is an abundance of mediocre and even awful code in products that are not failing because of it.
The worst thing about poorly designed software architecture is that it tends to freeze and accumulate more and more technical debt. This is not always a competitive issue, and with enough money you can maintain pretty much any codebases.
wreath
Even with enough money, you may not be able to attract/keep talented engineers who are willing to put up with such a work environment (the codebase itself, and probably the culture that led to its state) and who want to ship well built/designed software but are slowed down by the mess.
pixl97
This completely depends on the current economy.
When you work with F500s you end up seeing code and culture that is absolute balls and that I would never work directly for all the time. And yet roles are always filled. And when the economy gets bad, they have decent engineers.
I call it the fast food quality theory of economics. When the economy is good, low pay jobs tend to have low quality employees and it shows in their products. When the economy gets bad higher quality employees end up downgrading because of layoffs and the quality of these low tier jobs improves.
woeirua
The most successful software in a field is typically NOT the best software. The authors of the article live in a world that does not exist. Clean code lost, many years ago.
sublinear
> economic forces will drive AI models toward generating good, simpler, code because it will be cheaper overall
Economic forces are completely irrelevant to the code quality of AI.
> I believe that economic incentives will start to take effect and AI models will be forced to generate good code to stay competitive amongst software developers and companies
Wherever AI succeeds, it will be because a dev is spending time on a process that requires a lot of babysitting. That time is about the same as writing it by hand. Language models reduce the need to manually type something because that's what they are designed to do, but it doesn't mean faster or better code.
AI is rubber duck that can talk back. It's also a natural language search tool. It's training wheels for devs to learn how to plan better and write half-decent code. What we have is an accessibility tool being sold as anything and everything else because investors completely misunderstand how software development works and are still in denial about it.
Code quality starts and ends with business needs being met, not technical capability. There is no way to provide that to AI as "context" or automate it away. AI is the wrong tool when those needs can be met by ideas already familiar to an experienced developer. They can write that stuff in their sleep (or while sitting in the meetings) and quickly move on.
aledevv
> good code will win
I don't fully agree this optimistic view. Unfortunately, for now, coding agents produce code that, if not further optimized upon "human" request, often generates more complexity than necessary.
It's true that this requires more computational effort for the agents themselves to debug or modify it, but it's also true that the computational cost is negligible compared to the benefit of having features working quickly.
In other words: agents quickly generate hyper-complex and unoptimized code. And the speed of delivery provides more immediate benefits than the costs resulting from bad code.
On the other hand, it's also true that the "careful eye" of an experienced developer can optimize and improve the output in a few simple iterations.
So overall (and unfortunately) the "bad code", if it immediately works, can wins against (or with) a good code.
jumploops
“John Ousterhout [..] argues that good code is:
- Simple and easy to understand
- Easy to modify”
In my career at fast-moving startups (scaling seed to series C), I’ve come to the same conclusion:
> Simple is robust
I’m sure my former teams were sick of me saying it, but I’ve found myself repeating this mantra to the LLMs.
Agentic tools will happily build anything you want, the key is knowing what you want!
jfreds
My issue with this is that a simple design can set you up for failure if you don’t foresee and account for future requirements.
Every abstraction adds some complexity. So maybe the PoC skips all abstractions. Then we need to add a variant to something. Well, a single if/else is simpler than an abstract base class with two concrete implementations. Adding the 3rd as another if clause is simpler than refactoring all of them to an ABC structure. And so on.
“Simple” is relative. Investing in a little complexity now can save your ass later. Weighing this decision takes skill and experience
miningape
I think what matters more than the abstract class vs if statement dichotomy, is how well something maps the problem domain/data structures and flows.
Sure maybe its fast to write that simple if statement, but if it doesn't capture the deeper problem you'll just keep running head first into edge cases - whereas if you're modelling the problem in a good way it comes as a natural extension/interaction in the code with very little tweaking _and_ it covers all edge cases in a clean way.
blanched
I’m aware I’m about to be “that guy”, but I really like how Rich Hickey’s “Simple Made Easy” clarifies simplicity here. In that model, what you’re describing is easy, not simple.
mememememememo
Yes. Which is why "I generated X lines of code" "I used a billion tokens this month" sound stupid to me.
Like I used 100 gallons of petrol this month and 10 kilos of rabbit feed!
julenx
The same people that pursue economic incentives are who I hear speaking about number of lines produced by developers as a useful metric. I sense a worrying trend toward more is better with respect to output, when the north star IMHO should be to make something only as complex as necessary, but as simple as possible. The best code is no code at all.
sph
People use stupid metrics like those because more useful ones, like "productivity" or "robustness" are pretty much impossible to objectively measure.
mememememememo
And because the other easy one, revenue, is not so impressive.
Get the top HN stories in your inbox every day.
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.