Hacker News Reader

Not insane at all. There are two types of developers: those who do it primarily for the outcomes, and those who do it primarily for the craft. These are fundamental orientations.

Do craft people like outcomes? Sure. Can outcome people appreciate craft? Sure. But fundamentally, you typically fall more in one camp than the other.

And this assertion comes from the outcome people. Is it insane? No. To assert it's insane is insane, because it shows a fundamental disconnect from the economics of software development.

Which is about right, because the craft people don't do something primarily for the economics.

I do care about craft, but I am not considering craft in my comment. My problem is that craft and correctness are often correlated, and I do care about correctness. I care that the software I ship to end users, and especially the libraries that other software is built upon, are relatively bug free. A good way to assure this is to spend a long time, as a human, reasoning over what the AI wrote.

At work, I've frequently used AI to rapidly build MVPs. Then I get back to work and spend a lot of time on my own, with the help of AI, and with the help of code review from my teammates, raising the quality and correctness bar. Much longer than it would've taken if I just wrote it myself out of the gate, though there is still a net AI productivity gain because writing is just so so much faster.

All this is to say is that I do not care* if AI or a human wrote a library in actuality, but if it is obvious from the code and readme that an AI (or an amateur human) wrote it, I will reject the library because it is clear it is not up to the spec I demand. But tovalds can use AI all he wants in linux as long as the correctness of the output remains the same.

* perhaps I care slightly because on a more personal level, I do think its a little sad, though in a professional capacity I do not care.

False dichotomy IMO.

I've rarely met a "craft" person that authors TLA+ models to find correctness issues in their systems. And yet as an outcome person I frequently ask my AI minions to do this and similar exercises.

What I think you're actually describing is competency using AI as a tool to drive effective and correct outcomes. That takes practice and systems - same as it ever was.

If you buy in, I think you'll find you can create great, correct systems... only more than you could ever do alone. Without N*N comms overhead. Without having to convince your louder, less competent teammate to actually finish their work.

> What I think you're actually describing is competency using AI as a tool to drive effective and correct outcomes. That takes practice and systems - same as it ever was.

Right, but I suspect (the author did not link the library) that this was not what was happening. I suspect the Java mods looked at the library for a solid 30 seconds and it was immediately obvious there was heavy AI usage in a more negative way.

I'd argue that in a commercial setting, the measurable deliverable is ROI impact.

And that doesn't always come from building more software. That's where the craft is. AI just helps you build more software.

It depends on how you use it.

AI helps you build more software in the same way that a C compiler helps you build more assembler.

I spend far more tokens on specification and verification than I do on actual feature-code generation.

And with it a small team of 3 developed something in just a few weeks that would have normally taken us 12 months. And we are selling it for multiple-seven figures to customers who (by all rights) should have been able to token-gen their way to the same outcome, but haven't.

So there is clearly some value in the people, and clearly some value in the AI. But I think people are misplacing/misattributing which goes where, in some cases.

I feel I fall into two camps for different projects. I have a hobby project where I'm writing native UI components by hand without AI, and managing memory in an Arena allocator I wrote myself. I also have a hobby project where I honestly don't touch the code, I just think in terms of systems run per frame and the time complexity of different algorithms, making Claude do it. Most personal projects are somewhere in between. I don't think either approach is insane, immoral, or any other hyperbole.

> I don't think either approach is insane, immoral, or any other hyperbole.

Agree! To me it comes down to intention and attention.

Depending on my *intention*, I should devote more or less of my *attention* to one thing vs another.

Another way to think about it is essential vs incidental attention, which I borrow from essential vs incidental complexity [0].

Many things require attention, or it doesn't perform correctly. Essential attention. Many, many more things don't require my full attention, and they'll still perform adequately. They satisfice.

Farm out the tasks that require only incidental attention.

[0]:https://github.com/papers-we-love/papers-we-love/blob/main/d...

Thanks for the link. Software is all about managing complexity. I like the point about testing and external reasoning. LLMs can write a lot of tests in short order, many of which don't do much to help the program. It enjoys "pinning" behavior, which is basically just confirming a golden path and doing nothing to actually examine the behavior of a module under various conditions.

Incorrect.

I tend to care about outcome more than I care about craft.

There's more to outcome than a finished product or a delivered feature. Maintainability, technical debt, correctess, security. And, of course, being congnitively in control of what you build. You still have to understand what you are doing to properly steer a LLM.

This was true of software development before LLMs as well.

AI assistance is not vibe coding. You can use AI and not let it write a single line of code.

When I make manual changes I run them through an audit and risk analysis agent to make sure I didn't miss anything important.

This has caught more errors than our test suite lately.

> AI rarely seems to write better code than humans

The thing is since Fable 5+ generation of models this is not true anymore.

I apologize for my skepticism, but I have literally heard this same claim made with every single generation of models that comes out.

For a while, I dutifully believed it, and would go try again, and it would be awful.

I'd then have another conversation like this, where someone would say something along the lines of, "sure, sure but this NEW model now fixes all that and is really awesome!"

I'll revisit it when I start seeing some real studies that show real productivity increases rather than stuff that just shifts the burden of broken slop onto PR reviewers while claiming awesome speed.

You may also consider that developers (like any person in any profession) exist on spectrum of competency, and you may just be better than most of them.

But models are climbing their way up the percentile charts.

90% of the software development in the work, by volume, can be done by people who are in the 50th percentile of skill.

So these model advances do meaningfully expand the amount of "useful" work that can be done without people. And simultaneously not be "good enough" for the specific kind of work you find yourself doing day to day.

Both can be true.

Grab the last 5,000 lines of code you wrote, and that you thought was bug-free. Run it through Opus 5.5 or Fable 5.1 and post what it finds (and be honest about it, given that nothing is at stake but an Internet argument.)

This is a poor test. Parity would be utilizing the models to implement the functionality of the 5k lines and comparing the outputs.

When's the last time you did that?

Never. I'm also not the OP you responded to. I'm just pointing out the flaw in your proposed test.

Try it, then get back to me about whether the test is "flawed." I guarantee that a frontier model will find more bugs in your code than you will find it a similar volume of code it wrote. I absolutely guarantee it.

Every developer needs to experience this particular flavor of ego death. Me, you, everybody.

>Every developer needs to experience this particular flavor of ego death. Me, you, everybody.

You seem like a deeply unpleasant person.

(Shrug) HN isn't a place where ignorance should be celebrated; there are plenty of other venues for that.

I have access to these models at work. I am not out of touch.

Is it? Go look at ai written pull requests on any open source project, even using the fancy models. The code works but they write needlessly verbose comments above everything, don't follow the existing code style, and reinvent the wheel instead of checking if the source already has implementations for things.

>> AI rarely seems to write better code than humans.

This assertion is at the crux of a lot of these debates. Fundamentally it depends on what is meant by "better code", does it not?

Code that is bug free? Frontier models are inarguably better at that, because they can think of far more edge cases and test each one much faster than you can. You can argue that its code and surrounding tests are frequently overkill, but that's a dial you can tweak until you're happy.

Code that is performant? Frontier models are inarguably better at that too. They can create a benchmark harness and run it over and over to optimize the code they wrote while you're still poring over the docs on which method of iterating over a list is faster.

Code that is secure? Frontier models are also better at that, for the above two reasons: they can create complex security vulnerability plans and run swarms of agents to audit the code and attack the system that runs that code until it's like a god damn fortress.

Code that is easily understood by humans and fits coherently with the rest? I think humans are better at this still, because humans are definitionally the best at understanding what is easily understood by humans. I posit that this definition of "better code" is quickly going out of fashion though.

> Code that is bug free? Code that is performant? Code that is secure?

I have found that on the level of an individual function, this might very well be the case. On the level of an entire system, it very quickly falls apart and you get a lot of redundancies which cause security, bug and performance recessions, because nobody has really solved the issue of AI understanding whole systems at the time of inference.

I think it goes beyond individual functions. AI is capable of building complex features in a coherent manner. But it has trouble realizing those features exist as part of a larger system and need to fit upstream and downstream workflows. IMO that's where human engineers come in.

> AI rarely seems to write better code than humans.

That's my experience as well.

AI does a decent job of reviewing and finding bugs, but it has no concept of what makes code good or bad - too much state, convoluted logic, no invariants, unnecessary methods, poorly defined abstractions, not relying on fail-fast etc.

It's similar to work from a junior developer with little experience maintaining code over a longer period of time.

To quote the author:

> I would never actually ship any code anymore without using AI to review it

I can very much understand how the author can come off as calling people insane for not using AI to generate the code itself, but the impression I got is that he's calling people insane for not using AI at all in the coding process, i.e. for refusing to use AI even for code review.

And let's be fair: if you're not willing to let a completely local model (so as to put aside privacy concerns and API cost concerns), in a sandbox with read-only permissions, conduct code review for you in 2026, then yeah, I think you're doing the equivalent of refusing to take antibiotics. You can decide to reject the review results, or re-word the proposed fixes, but to refuse AI assistance at all as a matter of principle during the review stage is no longer a mainstream defensible position.

If the author just used AI as one element of code review, would the author still have been banned? The answer is obviously unknowable, but I think it is unlikely.

> but to refuse AI assistance at all as a matter of principle during the review stage is no longer a mainstream defensible position.

Personally the position strikes me more like the people of yore who would write code entirely in vim/emacs or, god forbid, notepad++, while the rest of us were using IDEs. We can all sit on our high horses and croon about how much more productive they'd be if they just tried a little bit of AI – "come on bro, just a puff" – but they've got their workflow and it isn't broken.

Where do you draw the line with what's considered "AI"?

There's a very clear pattern regarding pushback against AI, and it's not as ideological or political as you're making it out to be.

Lots of devs absolutely hate linters just as much, or maybe even more, than LLMs. It's simply a matter of having precise control over the result that gels with the dev's thought process enough to approve a release.

Let's be honest here. If you've got at least an 8-hour day to wrap up a medium size change of less than 1k LOC, the debate over LLMs is more of a personality judgement than advocating for a productivity tool. It's still going to get reviewed anyway, and most bugs in the software most people write for a living aren't subtle mistakes.

Lots of devs absolutely hate linters just as much, or maybe even more, than LLMs.

I never had much use for lint, myself. Back when Dr. Dobb's Journal used to publish ads for a commercial linter that included "spot the bug" quizzes, I could always spot the bug.

The thing is, though, LLMs are good at spotting semantic issues, not just C++ footgun #69,105. That's the point where I stopped worrying and learned to love the bot, when it found more issues with my code than I found with its own. I think that was Opus 4.6.

What an absurd statement. It’s like saying that not using a static analyzer is no longer defensible. Wat?

Somehow, people have been writing software for decades without AI assistance. Nothing about the emergence of AI changes the fact that humans are more than capable of producing good software using just their mushy little brains.

Maybe if you’re writing security-critical software, extra review passes would be welcome. But most software is far from that.

> Somehow, people have been fighting off disease for eons without antibiotic assistance. Nothing about the emergence of antibiotics changes the fact that humans are more than capable of producing antibodies using just their mushy little white blood cells.

AI rarely seems to write better code than humans

You're using it wrong, then. If you don't at least run your code through a frontier model for review, you're either unnecessarily wasting time and opportunities to improve, if it's a hobby, or committing professional malpractice if someone is paying for your time.

Your code is not as bug-free as you think it is. No, really. Trust me on that. I didn't believe it either. You don't need to let a clanker write your code, but you need to let one -- ideally more than one --- review it.

If you don’t use [expensive SAAS black box] you’re committing professional malpractice.

How very convenient for the black box vendors! Boy oh boy, however did we poor, fleshy coders ever get by with just emacs and a compiler?

I use the best tools I can put my hands on, even if I have to pay for them. Not because I think I'm so awesome, but because I know I'm not.

I also maintain a strong local inference server, but I can't play in Opus 5.5's league.

Not being awesome and putting in the work is how you get better. (And you don't have to pay some scummy company in perpetuity to do it.)

I never said AI isn't valuable for code review. I also never said AI isn't valuable for writing code, if you read my comment carefully. All I said is that it is not *universally* good at *writing* code.

You said it "rarely seems to write better code than humans." That's no longer the case.

Do you have proof? I believe it is faster at writing code than humans