Hacker News Reader

It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code.

There are some cases where the most profitable code is also good code. We like those.

But in most (99%+) cases, the code is not going to survive contact with the market and so spending any time on making it good is wasted.

Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up.

Once you show PMF though the balance changes to long-term sustainability and maintainability.

What's going to be interesting is getting to a place where it generates better code than we would from specs. You can get better and better generated code by filling in the context the model infers. Do that long enough, and well, a perfect spec is just code.

We do live in interesting times.

> Any time you spend writing perfect code instead of your MVP is burnt runway

This. Once we crashed a product/company becaues of "we want it to be engineered perfectly" :-X

To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it.

Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.

I think the industry-wide hope is that AI manages the AI-written code, but it’s unclear whether that’s actually going to work out in practice. Right now, my experience is that is dicey. I’ve had AI mess up a codebase to the point where I threw it away and restarted. Maybe I was doing it wrong, though, in that I was looking at the code and was increasingly horrified by the slop. I get the feeling that in this new world, we’re supposed to ignore how the sausage is made and just focus on the final outcome.

IME AI-native engineering requires a lot of infrastructure to make it viable. Teams who are just opening up cursor and putting it on "auto" and trying to one shot features may get stuff that works but is indeed slop.

Since the beginning of the year, I've been spearheading a low-stakes AI-native project (an internal tool). No one's written a single line of code. And we've learned so much from this experience. The first rule was our product manager, who is technical but isn't typically in the weeds, needs to be able to one-shot prompts with cursor auto. And so many rules stem from there, from e2e tests to ensure he doesn't break stuff, to custom linters to ensure that code lives in the right place, to architectural spec sheets so the LLM doesn't try to do raw DB queries from the client.

We're still not there, but we're getting closer and learning and improving every day.

I think the folks who are vibe coding a lot either aren't working in a team, or they are omitting the fact that they have spent a long time building harnesses to ensure the LLM doesn't run amok.

And I think the people who hate vibe coding are likely just asking Claude Code to do X without using Skills that have opinionated ways to do X.

All that said, I don't think we should ignore how the sausage is made at all. Part of what makes me able to move quickly in this project is knowing where stuff lives. I may not understand the line-by-line code, but if I know where to look to find out why I'm missing data that's in the DB, I can move a lot faster than if I have no idea what's going on in the codebase. Then when I find the problematic file or function, I can ask the LLM why it's like X and tell it it should be like Y.

Cool. Are you restricting the AI to be very focused on a function or an architectural blocks that is envisioned, or are you giving it more freedom? I seem to have less slop when I really constrain things, but that takes a lot of work (e.g., specs) and dialogue with the AI (“focus on X, now let’s design block Y,” etc.).

I give it freedom but with the predefined restrictions. I use a plug-in called Obra Superpowers. Whenever I want to start on a block of work, whether it's a ticket or if I just want to tackle tech debt, I start with the brainstorm command. I say something vague like "implement X" or "last time i tried to vibe code Y, Z happened. I don't want that to happen again. Let's improve the harness."

It'll ask follow questions, which I answer, then generate specs that I manually review. If it looks good, it'll generate a plan. If not then I'll give it feedback.

When the scope of work is well-defined (ie my boss says users should be able to do Y) then this process is fairly seamless.

When it's not well-defined then it does take a bit longer and more dialogue as you said. But because everything is documented and written down, we have a pretty good feedback loop (boss asks why it works like X, I can look at the generated spec/plan, or ask the AI to, to understand why).

Ok, so it’s constrained by specs, but you dialog with the AI and have it create the specs. I should try that. I’ve been creating my own specs and having it work from those and then iterating, but that’s not exactly quick and I find myself thinking, “At this rate I could do it faster myself.”

Yeah definitely agreed. I'm lucky I'm that my boss is willing to invest in this little experiment so the point isn't "can we do this faster manually" it's "how can we build our AI infrastructure such that it can actually be faster."

And also, I'm taking care of my infant daughter while working so my workflow is often "launch an AI agent from my computer while she's asleep, review plan on my phone while feeding or napping the little one, approve it and execute it" so it's often running when I'm not really in a mental space to be thinking deeply.

In my experience (30+ years) writing good code (and good automatic tests) makes me way more productive.

Both when initially writing the code and later when maintaining it.

Good code dramatically reduce bugs and makes the remaining bugs more visible.

I spend almost zero time fixing bugs. Because there aren't many. Not a brag. Just the truth.

To me, it instead sounds like you care about the code you produce. You judge it more harshly than you probably do other code. It sounds like you are also meeting deadlines, so I'd call that a success and more production than what a lot of people tend to put out into the world.

I often have a lot of time between projects, and am able to really think about things, and write the code that I'm happy with. Even when I do that, I do some more research, or work on another project, and immediately I'm picking apart sections of my code that I really took the time to "get right." Sometimes it can be worse if you are given vast amounts of time to build your solution, where some form of deadline may have pushed you to make decisions you were able to put off. At least that's my perspective on it, I feel like if you love writing software, you are going to keep improving nearly constantly, and look back at what you've done and be able to pick it apart.

To keep myself from getting too distressed over looking at past code now, I tend to look at the overall architecture and success of the project (in regards to the performing what it was supposed to, not necessarily monetarily). If I see a piece of code that I feel could have been written far better, I look at how it fits into the rest. I tend to work on very small teams, so I'm often making architecture decisions that touch large areas of the code, so this may just be from my perspective of not working on a large team. I still do think if you care about your craft, you will be harsh on yourself, more than you deserve.

This is the product that's claiming "coding is a solved problem" though.

I get a junior developer or a team of developers with varying levels of experience and a lot of pressure to deliver producing crummy code, but not the very tool that's supposed to be the state-of-the-art coder.

Sure, but as I stated, even "professional" code is pretty bad a lot of the time. If it's able to generate code that's as good as professional code, then maybe it is solved.

I don't actually think it's a solved problem, I'm saying that the fact that it generates terrible code doesn't necessarily mean that it doesn't have parity with humans.

Hard to argue with that.

You can get AI to generate the best code you have ever seen. It just takes time and direction. I can write "poetic" code, but it takes orders of magnitude more time. I can also write beautiful code with AI, but it is also time and brain intensive.

It generates terrible code when used in a nearly open loop manner, which all coding agents are currently doing.

And look what damage comes from that human generated code.

Now we get hyper mass production of the same quality.

The bet is that it will be trivial for them to invest in cleaning up Claude Code whenever they face real competitive pressure to do so. My best guess is that it's a bad bet - I don't think LLM agents have solved any of the fundamental problems that make it hard to convert janky bad code to polished good code. But Claude Code is capable in my experience of producing clean code when appropriately guided, so it's not that there's no choice but jank. They're intentionally underinvesting in code quality right now for the sake of iteration speed.

Have you tried just asking CC to make a codebase more elegant? It’s surprisingly effective up to a point. No reason to think that won’t work better down the road.

Down the road AI is smarter than all of us. Today (including one time literally today), my experience is that it’s occasionally helpful at cleaning up its own mess but often tries to change behavior in a way that’s unacceptable for a production project.

  > often tries to change behavior

yes, and (in my experience) at the same time re-write the unit tests that are supposed to guarantee behavior doesn't change...

No one cares about code quality. No one has ever cared about code quality. It’s only been tolerated in businesses because no one could objectively say that ignoring code quality can result in high velocity. With coding agents, velocity is now extremely high if you get humans out of the way.

It really shows that nobody cares about uptime at github or the jankiness of claude.

I wouldnt say that customers are indifferent, but it wouldnt be the first time that investor expectations are prioritized far above customer satisfaction.

"No one cares about code quality" - disagree. As a dev, I care about code quality in that shitty code makes my life suck.

As a user of terrible products, I only care about code quality in as much as the product is crap (Spotify I'm looking at you), or it takes forever for it to evolve/improve.

Biz people don't care about quality, but they're notoriously short sighted. Whoever nerfed Google's search is angering millions of people as we speak.

> Whoever nerfed Google's search is angering millions of people as we speak

This guy, supposedly:

https://news.ycombinator.com/item?id=40133976

Nobody cares about costs until they pay them themselves.

Regarding code quality and tech debt, it's sensible not to care if it doesn't lead to anything observable. Do you really care of some "bad" code somewhere that hasn't changed for 5 years but keeps working fine, and has no new requirements?

On the other hand, if you work on an active codebase where fixing one bug inevitably leads to another, maybe it's worth asking whether the code quality is simply too low to deliver on the product expectations.

It's not even obvious to me in which direction coding agents move the needle. Do you want higher quality, at least at a higher (design) level, when you heavily use agents, so that you know know the mess will at least compartmentalized, and easier to deal with later if needed? Or do you just assume the agent will always do the work and you won't need to dig into the code yourself? So far I've mostly done the former, but I understand that for some projects, the latter can make sense.

"Code quality" here isn't referring to some aesthetic value. Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while. They get to the point where fixing one bug causes another, and then the codebase is in such a state that no human or agent can salvage.

People who say they don't care about the quality of code produced by agents are those who haven't been evolving non-trivial codebases with agents long enough to see just how catastrophically they implode after a while. At that point, everyone cares, and that point always comes with today's agents given enough lines and enough changes.

Yep. Good quality, succinct code saves time and money. Always has and always will.

> Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while

That's not true, and I'm not sure what that even means. It's totally up to you the human to ensure AI code mergable or evolvable, or meet your quality standard in general. I certainly have had to tell Claude to use different approaches for maintainability, and the result is not different than if I do it myself.

Sure, if you vigilantly review the agent's output and say no when it's wrong (which happens very frequently) then things work. I meant that without such ver close supervision things don't converge because agents make mistakes that compound.

And yet, velocity is a terrible metric to go by. It is only interesting in so far that you can spit something out before somebody else.

When agents became a thing I was hoping that we will finally be able to go through all the outstanding bugs, tighten the bolts so to speak. Instead, we produce _more_ stuff.

We have now 100 half-baked versions of everything because everybody can give their own spin on anything.

> crummy code, but not the very tool that's supposed to be the state-of-the-art coder

Why not? It is subject to the same pressures, in fact it is subject to more time pressure than most corp code out there. Also, it's the model that's doing the coding, not the frontend tool.

I thought the sales pitch of all of this is that the AI was supposed to relieve people from having to do a bunch of annoying bootstrap coding and to do it in a way that we could extended easily.

I have a subscription to Claude Code and despite my skepticism, it has been pretty good at just getting a goofy PoC thing going. When I look at the code, it’s usually insane unless the prompt was so narrow and specific like about writing a function that does one thing and only one thing.

Outside of small, personal projects, I am still really uncomfortable at having agents run wild. I see the result, and then I spend a bunch of time having to gain the context of what is going on, especially if I ask it to implement features in spaces I have general knowledge, but not expertise. So, the problem remains the same. These things still need handholding by people who understand the domain, but having people become glorified PR reviewers is not an acceptable path forward.

Arguing that there is lots of bad production code kinda avoids the actual issue that is going on here. Yes, a lot of sloppy code can and has been written by people. I’ve seen it myself, but it feels like the actual thing is that, we are now enabling that at scale and calling it “abundance” when instead we are really generating an abundance of completely avoidable security holes and logic errors.

Exactly. I thought AI was going to be smarter. I thought AI would give us expert coders. Instead we have idiot savants.

Does the pressure affect the LLM's judgement in the same way it does a developer whose job is on the line?

i once scolded an ai for being too late when i figured out an issue before it could come back with an answer: it made an excuse that it took too long to start up, lol

i would guess telling it to "hurry up" would produce even worse code than already does without hand-holding or maybe it would make an excuse again...

I mean, hasn't it learned from reading other's code? I don't think it can be any better than the common patterns and practices that it has been trained on. Some outlier of amazing code is probably not going to make much of a difference, unless I am completely misunderstanding LLMs (which I very well may be, and would gladly take any criticism on my take here).

Yes, but, that’s a low bar, no? I mean, when they first started talking about AI, were you envisioning a mediocre AI that is just average, or were you imagining an expert?

> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked.

Absolutely. The difference is that the amount of bad code that could be generated had an upper limit on it — how fast a human can type it out. With LLMs bad code can be shat out at warp speed.

Oh I don't disagree with that. I am getting pretty tired of people making multi-thousand-line pull requests with lots of clearly AI-generated code and expecting it to be merged in.

I think the better unit to commit and work with is the prompt itself, and I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.

> I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.

The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.

If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic.

Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.

How is "fairly close to deterministic" anywhere near good enough? LLMS aren't anywhere near cheap enough to do this either.

That said it's so trivial to do, why haven't you done that already?

I have actually, for my personal projects. I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists. I have a Java version that works right now and I will likely be pushing it within the next week.

But more generally, I actually have been building some CI stuff to automate how I'm saying.

I don't have much of a say how this is handled at work so they're just committing the generated code, but I actually am doing what I am talking about.

Sounds like a fun project. And are you committing code for this library? Because it sounds like you are, and if that's the case I don't think you're actually doing what you're talking about.

I'm writing the "assume" code by hand. Regular non-artificial intelligence, or the closest that I ever get to it, so no hypocrisy on that.

  > I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists.

This is very much like good old djinn [1], which would generate code from Haskell type specification.

[1] https://mail.haskell.org/pipermail/haskell/2005-December/017...

And this is why I boldly compare current LLM craze to the much less hyped craze of strong type systems. I was a part of that strong type system discussion, advocating for them. ;)

You don't have to convince me.

LLMs are neat, code generation is neat, but I do wish that people had learned type theory and instead used those.

I'm not aware of djinn, but I do remember the "Type Driven Development" that Idris had that I thought was absurdly cool; when you make the type specification clear enough, there ends up being basically exactly one reasonable way of writing the code, in which case it can just be "deduced" by machinery.

I'm a huge advocate for formal methods, and it does sort of bother me that pretty much all work on that seems to have been refocused on AI.

  > If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic.

Your prompt may work on the specific state of code base and not before or after some changes. Your tests can check for the specific behavior but not for the absence of undesirable behaviors induced by absence of some specific code or by addition of other specific code.

  > I assure you that's already happening. A lot.

Thank you for assurance. Can we have less of it? Thank you again.

Hell sometimes the ai may look at values in .env or other uncommited stuff. Its execution path may depend on which commands are available in the environment. The specific model and settings. On top of the inherent randomness if you havent set model heat to 0. i suspect it is very hard to get consistent reproducible ai runs

But then who's responsible for reviewing and correcting the ai-written code ?

> and then replacing those hacks with better code just never happens

Yeah, we even have an idiom for this - "Temporary is always permanent"

We'll fix it later.

But as a great man once said: Later == Never.

"There's nothing more permanent than a temporary solution."

> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked.

At a place I worked at with their core product written in Python, it was exceptionally common for engineers to make shell calls for file operations that had easy Python-native functions.

For example, rather than `os.remove("some_file")`, they'd do `os.system("rm some_file")`. Sometimes, the file name being acted on included user input.

I found so many shell injections that could have easily been prevented.

This is not just true of code; it is true of everything - the whole world is held together with spit, bailing wire, a prayer, and some old dude who remembers.

It doesn't mean it's something to strive for

Totally agree; we've created a system that goes so far beyond technical debt we're going to have to call it technical usury, and we're piling it up at rapid rates.

Given that most code gets thrown away, perhaps it won't matter much.

Perhaps

i worked at companies in US

where uptime monitoring was Page Refresh by QA team.

where there was no centralized logs

postgres had no backup or replication or anything

> I suspect if people saw the handwritten code

Somehow, everyone has forgotten the terrible code quality that existed prior to 2020.

https://www.youtube.com/watch?v=UjZQGRATlwA

Like, come on. Software has been shit for decades. AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.

>AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.

I have noticed a spike in web apps exhibiting random failures and glitchy behavior over the past few months.

  > AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.

Most probably, you are not looking into that well enough.

Average duration for AWS outages [2] was 1.5 hours per outage, 38 hours total. Most recent AWS outage in 2026 [1] downed AWS for 13 hours, a third of 38 hours spanning an year before, and was caused by AWS LLM coding tool.

[1] https://www.theguardian.com/technology/2026/feb/20/amazon-cl...

[2] https://www.cherryservers.com/blog/cloud-outages