HN

Comments (122)

• Menu

  btrettel
  Similar to bragging about LOC, I have noticed in my own field of computational fluid dynamics that some vibe coders brag about how large or rigorous their test suites are. The problem is that whenever I look more closely into the tests, the tests are not outstanding and less rigorous than my own manually created tests. There often are big gaps in vibe coded tests. I don't care if you have 1 million tests. 1 million easy tests or 1 million tests that don't cover the right parts of the code aren't worth much.
• Menu

  suzzer99
  > Generally, though, most of us need to think about using more abstraction rather than less.Maybe this was true when Programming Perl was written, but I see the opposite much more often now. I'm a big fan of WET - Write Everything Twice (stolen from comments here), then the third time think about maybe creating a new abstraction.
• Menu

  reenorap
  As someone who has switched to exclusively coded using AI after 30 years of coding by myself, I find it really weird when people take credit for the lines of code ad features that AI generates. Flexing that one "coded" tens of hundreds of thousands of lines per day is a bit cringe, seeing as though it's really just the prompt that one typed.
• Menu

  njarboe
  German General Kurt von Hammerstein-Equord (a high-ranking army officer in the Reichswehr/Wehrmacht era):“I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined.Some are clever and diligent — their place is the General Staff.The next lot are stupid and lazy — they make up 90% of every army and are suited to routine duties.Anyone who is both clever and lazy is qualified for the highest leadership posts, because he possesses the intellectual clarity and the composure necessary for difficult decisions.One must beware of anyone who is both stupid and diligent — he must not be entrusted with any responsibility because he will always cause only mischief.”
• Menu

  johnfn
  As dumb as it is to loudly proclaim you wrote 200k loc last week with an LLM, I don’t think it’s much better to look at the code someone else wrote with an LLM and go “hah! Look at how stupid it is!” You’re making exactly the same error as the other guy, just in the opposite direction: you’re judging the profession of software engineering based on code output rather than value generation.Now, did Garry Tan actually produce anything of value that week? I dunno, you’ll have to ask him.
• Menu

  arthurjj
  LLMs not being lazy enough definitely feels true. But it's unclear to me if it a permanent issue, one that will be fixed in the next model upgrade or just one your agent framework/CICD framework takes care of.e.g. Right now when using agents after I'm "done" with the feature and I commit I usually prompt "Check for any bugs or refactorings we should do" I could see a CICD step that says "Look at the last N commits and check if the code in them could be simplified or refactored to have a better abstraction"
• Menu

  xhrpost
  I've had this exact sentiment in the past couple months after seeing a few PRs that were definitely the wrong solution to a problem. One was implementing it's own parsing functions to which well established solutions like JSON or others likely existed. I think any non-llm programmer could have thought this up but then immediately decide to look elsewhere, their human emotions would have hit and said "that's way too much (likely redundant) work, there must be a better way". But the LLM has no emotion, it isn't lazy and that can be a problem because it makes it a lot easier to do the wrong thing.
• singron
  I have noticed LLMs have a propensity to create full single page web applications instead of simpler programs that just print results to the terminal.I've also struggled with getting LLMs to keep spec.md files succinct. They seem incapable of simplifing documents while doing another task (e.g. "update this doc with xyz and simply the surrounding content") and really need to be specifically tasked at simplifying/summarizing. If you want something human readable, you probably just need to write it yourself. Editing LLM output is so painful, and it also helps to keep yourself in the loop if you actually write and understand something.
• jimbokun
  Time to teach the LLMs and the vibe coders one of the timeless lessons of software development:https://www.folklore.org/Negative_2000_Lines_Of_Code.html
• pityJuke
  Man, I cannot imagine how nice it must to be to work with leadership like this, who just gets it.
• eucyclos
  The reference to 'literature by the pound ' made me think of an apocryphal story about a pottery teacher who at the end of the year would grade his students on either the quality of a single piece or the weight of all finished pieces. With very few exceptions, the best piece of the year would be one of the ones where a student went for volume.Which is plausible if you need to touch each piece- more repetitions lead to more improvement if you're already motivated to improve anyway - but if the output is coming from an llm, I'm not sure ..
• spprashant
  At this point, I almost feel bad that people are piling on Garry Tan. Almost.
• mplappert
  I very much agree; I think laziness / friction is basically a critically important regularizer for what to build and for what to not build. LLMs remove that friction and it requires more discipline now. (Wrote some of this up a while ago here: https://matthiasplappert.com/blog/2026/laziness-in-the-age-o...)
• genxy
  The scariest things I have ever seen are super hard-working programmers.So much code, it wouldn't stop. Refactoring was harder than rewriting. Unit tests metastasized into bone. And now another PR.
• pythontongue
  Similar issue as social media making communication more effortless, and thus encouraging higher quantity over quality
• progbits
  Great article, I've been saying something similar (much less eloquently) at work for months and will reference this one next time it comes up.Quite often I see inexperienced engineers trying to ship the dumbest stuff. Back before LLM these would be projects that would take them days or weeks to research, write, test, and somewhere along the way they could come to the realization "hold on, this is dumb or not worth doing". Now they just send 10k line PR before lunch and pat themselves on the back.
• flumpcakes
  The more people boast about AI while delivering absolute garbage like in the example here, the more I feel happier toiling around in Nginx configurations and sysadmin busy work. Why worry about AI when it's the same old idiots using it as a crutch, like any new fad.
• dwg
  As a counterpoint, perhaps there is a sort of "natural selection" which will drive better abstractions due to being more token-efficient. Albeit perhaps a relatively smaller effect.
• warwickmcintosh
  laziness makes you understand the problem before writing anything. an LLM will happily generate 500 lines for something that needed 20 because it never has to maintain any of it.
• dzonga
  software engineering - let's break it down.engineering is about applying rules of thumb to solve problems.however what's not usually stated to most people in the profession - that 'software engineering' is also an art - which means do the most you can with constrains. at the edges that's when you create things that are notable.do LLMs spitting code - fit the 'Engineering or Art' part. NO
• Menu

  abcde666777
  Being a somewhat lazy individual myself, I'm wary of this statement. It feels too... comforting. "It's okay that I wasn't productive today, because laziness has merits".I consider my laziness a part of who I am, and I don't demonize it, but I also don't consider it my ally - to get the things I care about done I often have to actively push against it.
• rsanheim
  Bragging about loc was silly before ai. Now it’s not only silly, but also makes you look like a huge tool.
• jwpapi
  I‘m so happy about this article. I was forming a thought in my head the last couple of days, which is how to describe what it is that makes AI code practically unusable in good systems.And one of the reasons is the one described in this article and the other is, that you skip training your mental model when you don’t grind these laziness patterns. If you are not in the code grinding to your codebase, you don’t see the fundamental issues that block the next level nor you have the itch to name and abstract it properly so you wont have to worry about in the future, when somebody or you have to extend it.Knowing your shit is so powerful.I believe now that my competive advantage is grinding code, whilst others are accumulating slop.
• geophile
  Oh spare me the cult of Larry Wall. His language was crap, and his pontification was unbearable.That said, he's not wrong about laziness. I'd state it less cutely: Good software takes time, so be patient. The same can be said of most things created by people. Sure, there are flashes of inspiration, like Paul McCartney sitting down and just coming up with Get Back. But those are quite rare. And even in those cases, it often takes time to refine the idea to its final form.
• Menu

  glitchc
  Hard disagree with the initial assumption: Abstractions do not make a system simpler.Note: I would have added usually but I really do mean always.
• fragmede
  Since we all, stupidly, are leaning into LoC as a metric, because we can't handle subjectivity, at the very least, we could just do orders of magnitude for LoC. Was it a 10/100/1,000/10,000 LoC hour/week/day/month? 1,2,3,4 or 5. Dtrace's 60kLo, would then be a 5, Linux kernel is an8 (40M), Firefox is also an 8. Notepad++ is a 6,
• gnerd00
  oh this hits all the right notes for me! I am just the demographic that tried to perl my way into the earliest web server builds, and read those exact words carefully while looking at the very mixed quality, cryptic ascii line noise that is everyday perl. And as someone who had built multi-thousand line C++ systems already, the "virtues" by Larry Wall seemed spot on! and now to combine the hindsight with current LLM snotty Lord Fauntleroy action coming from San Francisco.. perfect!
• jauntywundrkind
  Abstractions and strong basis as a freedom to think freely at high levels.The slop drowning and impinging our ability to do good hammock driven development.Love it. Thanks Bryan.It's invaluable framing and we'll stayed. There's a pretty steady background dumb-beat of "do we still need frameworks/libraries" that shows up now. And how to talk to that is always hard. https://news.ycombinator.com/item?id=47711760To me, the separation of concerns & strong conceptual basis to work from seem like such valuable clarity. But these are also anchor points that can limit us too, and I hope we see faster stronger panning for good reusable architectures & platforms to hang out apps and systems upon. I hope we try a little harder than we have been, that there's more experimentation. Cause it sure felt like the bandwagon effect was keeping us in a couple local areas. I do think islands of stability to work from make all the sense, are almost always better than the drift/accumulation of letting the big ball of mud architecture accrue.Interesting times ahead. Amid so much illegibile miring slop, hopefully too some complementary new finding out too.
• Menu

  simianwords
  This is a person clearly grieving that his hard earned knowledge in his field is now not that valuable.It is * exactly * the same as a person who spent years perfecting hand written HTML, just to face the wrath of React.