6 ms·

The peril of laziness lost

480 points by gpm 6mo ago

gnerd00 6mo ago
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!
suzzer99 6mo ago
> 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.
- badlucklottery 6mo ago
  >WET - Write Everything Twice I've always heard this as the "Rule of three": https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
  - hackable_sand 6mo ago
    Antymony with DRY
    - deleted 6mo ago
      [deleted]
    - jpfr 6mo ago
      Probably the second rewrite is really tight with good abstractions and little repetition. So no, the end result can still be DRY.
- nixpulvis 6mo ago
  I've been advocating for writing everything twice since college.
- layer8 6mo ago
  More than twice is a rather low bar, I don’t think that it conflicts with the quote from Programming Perl.
  - suzzer99 6mo ago
    I don't think it's a hard rule, more of an ethos. If you know there are going to be a bunch of something, write the abstraction out of the gate. If you have three code entities with a lot of similar properties, but the app is new and you feel like there's a good chance they might diverge in the future, then leave them separate.
- dasil003 6mo ago
  Totally agree with this, the beauty of software is the right abstractions have untold impact, spanning many orders of magnitude. I'm talking about the major innovations, things like operating systems, RDBMS, cloud orchestration. But the majority of code in the world is not like that, it's just simple business logic that represents ideas and processes run by humans for human purposes which resist abstraction. That doesn't people from trying though, platform creation is rife within big tech companies as a technical form of empire building and career-driven development. My rule of thumb in tech reviews is you can't have a platform til you have three proven use cases and shown that coupling them together is not a net negative due to the autonomy constraint a shared system imposes.
  - genxy 6mo ago
    That is where I put systems programmers, they need to extract an abstract algebra out of the domain. If they are able to accomplish this, the complexity of the problem largely evaporates. Use the wrong abstraction and you are constantly fighting the same exact bug(s) in the system. Good design makes entire classes of bugs impossible to represent. I don't believe the trope that you need to make a bunch of bad designs before you can do good. Those lessons are definitely valuable, but not a requirement. A great example is the evolution from a layered storage stack to a unified one like ZFS. Or compilers from multipass beasts to interactive query based compilers and dynamic jits. The design and properties of the system was always the problem I loved solving, sometimes the low level coding puzzles are fun. Much of programming is a slog though, the flow state has been harder and harder to achieve. The super deep bug finding, sometimes, if you satisfactorily found it and fixed it. This is the part where you learn an incredible amount. Fixing shallow cross module bugs is hell. Don't you have to be really seasoned to in good faith, attempt to couple two systems and say where that would be productive? You can't prove this negative. I would imagine a place like that would have to have a very strong culture of building towards the stated goals. Keeping politics and personalities out of it as much as possible.
- HarHarVeryFunny 6mo ago
  Writing twice makes sense if time permits, or the opportunity presents itself. First time may be somewhat exploratory (maybe a thow-away prototype), then second time you better understand the problem and can do a better job. A third time, with a new abstraction, is where you need to be careful. Fred Brooks ("Mythical Man Month") refers to it as the "second-system effect" where the confidence of having done something once (for real, not just prototype) may lead to an over-engineered and unnecessarily complex "version 2" as you are tempted to "make it better" by adding layers of abstractions and bells and whistles.
  - wcarss 6mo ago
    I agree with what you're saying about writing something twice or even three times to really understand it but I think you might have misunderstood the WET idea: as I understand it, it's meant in opposition to DRY, in the sense of "allow a second copy of the same code", and then when you need a third copy, start to consider introducing an abstraction, rather than religiously avoiding repeated code.
    - HarHarVeryFunny 6mo ago
      Personally, even for a prototype, I'd be using functions immediately as soon as I saw (or anticipated) I needed to do same thing twice - mainly so that if I want to change it later there is one place to change, not many. It's the same for production code of course, but when prototyping the code structure may be quite fluid and you want to keep making changes easy, not have to remember to update multiple copies of the same code. I'm really talking about manually writing code, but the same would apply for AI written code. Having a single place to update when something needs changing is always going to be less error prone. The major concession I make to modularity when developing a prototype is often to put everything into a single source file to make it fast to iteratively refactor etc rather than split it up into modules.
      - skydhash 6mo ago
        The danger with people that claims to follow DRY is that they don’t check first that they are repeating yourself. As soon as they’re encounter similarity, they assume equality and rush to abstract it. But if one knows the domain enough to know that some logic is the same, not just similar, then no need to write it twice first.
- jimbokun 6mo ago
  That will still result in more abstraction than the average programmer.
- raincole 6mo ago
  I agree. It's crazy how many layers of abstraction have been created since 1991 (when Programming Perl was published.)
- marcus_holmes 6mo ago
  "Duplication is far cheaper than the wrong abstraction" Sandi Metz https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
  - suzzer99 6mo ago
    And adding an abstraction later is much easier than removing an unneeded one, which can be very hard or even impossible depending on the complexity of the app.
johnfn 6mo ago
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.
- fao_ 6mo ago
  Yeah! It's not like code quality matters in terms of negative value or lives lost, right?! https://en.wikipedia.org/wiki/Horizon_IT_scandal https://en.wikipedia.org/wiki/Horizon_IT_scandal Furthermore, > As for the artifact that Tan was building with such frenetic energy, I was broadly ignoring it. Polish software engineer Gregorein, however, took it apart, and the results are at once predictable, hilarious and instructive: A single load of Tan’s "newsletter-blog-thingy" included multiple test harnesses (!), the Hello World Rails app (?!), a stowaway text editor, and then eight different variants of the same logo — one of which with zero bytes. Do you think any of the... /things/ bundled in this software increased the surface area that attacks could be leveraged against?
  - 8note 6mo ago
    > included multiple test harnesses (!) ive seen plenty of real code written by real people with multiple test harnesses and multiple mocking libraries. its still kinda irrelevant to whether the code does anything useful; only a descriptor of the funding model
    - flir 6mo ago
      If I'm reading this correctly ("a single homepage load of http://garryslist.org http://garryslist.org downloads 6.42 MB across 169 requests"), the test harnesses were being downloaded by end users. They weren't being installed as devDependencies.
  - SvenL 6mo ago
pityJuke 6mo ago
Man, I cannot imagine how nice it must to be to work with leadership like this, who just gets it.
simianwords 6mo ago
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.
- lapcat 6mo ago
  > This is a person clearly grieving that his hard earned knowledge in his field is now not that valuable. He's co-founder and CTO of his own company, so I think he's doing fine in his field.
  - simianwords 6mo ago
    It doesn't change the fact that much of what (I think) he prides in himself in is getting commoditised.
    - wiseowise 6mo ago
      LLMs dissolved your brain if you think they commoditize what a guy like this[0] prides in himself. https://bcantrill.dtrace.org/about/ https://bcantrill.dtrace.org/about/
    - pxc 6mo ago
      What he prides himself in (in this context) is craft, which LLM use probably can enable, but definitely isn't commoditized by the kind of vibe coding that Garry Tan is doing.
    - 0xBA5ED 6mo ago
      I would seriously consider if you've developed an imaginary caricature in your mind that you apply to people you don't know. Further, I would consider if any living person actually lives up to it.
    - bcantrill 6mo ago
      On the one hand, I admire (at some level) you sticking to your guns here, willing to take on all comers. On the other, though, I don't entirely understand the inference that you're drawing from the piece; what, exactly, is getting commoditized?
arthurjj 6mo ago
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"
- layer8 6mo ago
  It’s difficult to define a termination criterion for that. When you ask LLMs to find any X, they usually find something they claim qualifies as X.
  - arthurjj 6mo ago
    Agreed. If I'm looking at what it proposes then about 1/2 the time I don't make the changes. If this were fully automated you would need an addendum like "Only make the change if it saves over 100 lines of code or removes 3 duplicate pieces of logic". There are other scenarios you would want to check for but you get the idea.
- JeremyNT 6mo ago
  I agree, it's not a fundamental characteristic but a limitation of how the tool is being used. If you just tell these things to add, they'll absolutely do that indiscriminately. You end up with these huge piles of slop. But if I tell an LLM backed harness to reduce LOC and DRY during the review phase, it will do that too. I think you're more likely to get the huge piles if you delegate a large task and don't review it (either yourself or with an agent).
- ocrow 6mo ago
  I've tried this approach of instructing the LLM to look for opportunities to abstract, but it's not good at finding the commonalities after the fact, when possibly related functions have already diverted unnecessarily. It writes "sloppy" code, that is to say code that is locally correct but which fails to build towards overall generalizations, but that sloppy code is a cul-de-sac: easy to write, but adding to messiness, and really tough to improve. When a good programmer writes a new feature, they are looking for both existing and new abstractions that can be applied. They are considering their mental model of the whole system and examining whether it can be leveraged or needs to be updated. That's how they avoid compounding complications. In order to take a big picture view like that, the LLM needs the right context. It would need to focus on what its system model is and decide when to update that system model. For now, just telling it what to write isn't enough to get good code. You have to tell it what to pay attention to.
mplappert 6mo ago
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-of-ai/ https://matthiasplappert.com/blog/2026/laziness-in-the-age-o...)
singron 6mo ago
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.
- theshrike79 6mo ago
  My rule of thumb is that documentation for AIs can be written by AIs Documentation for humans should be written by humans. Or at the very least read through and signed off on by humans.
flumpcakes 6mo ago
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.
njarboe 6mo ago
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.”
- quantummagic 6mo ago
  Where my fellow ninety-percenters at?
  - dijit 6mo ago
    I think we put too much negative emphasis on people who aren’t as gifted intellectually. In reality, the world works because of human automotons, honest people doing honest work; living their life in hopefully a comforting, complete and wholesome way, quietly contributing their piece to society. There is no shame in this, yet we act as though there is.
    - Jtarii 6mo ago
      The movie Perfect Days captures this perfectly.
    - xboxnolifes 6mo ago
      This is what pains me with how many people respond negatively toward the idea of everyone being able to earn an honest living and raise a family. Too often the idea of "deserving it" comes into it as if doing your small part to contribute to society is not enough.
    - ChosenEnd 6mo ago
      Human automatons? Why would you have mercy for automatons? Just call them cattle, we might feel more compassion towards them if we don't think of them as machinelike.
progbits 6mo ago
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.
btrettel 6mo ago
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.
- colechristensen 6mo ago
  It's a struggle to get LLMs to generate tests that aren't entirely stupid. Like grepping source code for a string. or assert(1==1, true) You have to have a curated list of every kind of test not to write or you get hundreds of pointless-at-best tests.
  - gpm 6mo ago
    > have a curated list of every kind of test not to write I've seen a lot of people interact with LLMs like this and I'm skeptical. It's not how you'd "teach" a human (effectively). Teaching (humans) with positive examples is generally much more effective than with negative examples. You'd show them examples of good tests to write, discuss the properties you want, etc... I try to interact with LLMs the same way. I certainly wouldn't say I've solved "how to interact with LLMs" but it seems to at least mostly work - though I haven't done any (pseudo-)scientific comparison testing or anything. I'm curious if anyone else has opinions on what the best approach is here? Especially if backed up by actual data.
    - jerf 6mo ago
      It's going to be difficult for anyone to have any more "data" than you already do. It's early days for all of us. It's not like there's anyone with 20 years of 2026 AI coding assistant experience. However we can say based on the architecture of the LLMs and how they work that if you want them to not do something, you really don't want to mention the thing you don't want them to do at all. Eventually the negation gets smeared away and the thing you don't want them to do becomes something they consider. You want to stay as positive as possible and flood them with what you do want them to do, so they're too busy doing that to even consider what you didn't want them to do. You just plain don't want the thing you don't want in their vector space at all, not even with adjectives hanging on them.
xhrpost 6mo ago
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.
- nulltrace 6mo ago
  It also doesn't bother checking what's already in your project. Grep around a bit and you'll find three `formatTimestamp` functions all doing almost the same thing.
spprashant 6mo ago
At this point, I almost feel bad that people are piling on Garry Tan. Almost.
jauntywundrkind 6mo ago
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=47711760 https://news.ycombinator.com/item?id=47711760 To 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.
fragmede 6mo ago
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,
jwpapi 6mo ago
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.
jimbokun 6mo ago
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 https://www.folklore.org/Negative_2000_Lines_Of_Code.html
glitchc 6mo ago
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.
- love2read 6mo ago
  the thing about abstractions is that nothing implies that they aren’t leaky abstractions, which may be worse than no abstraction for future bug hunters
- dap 6mo ago
  I’m curious what you think an abstraction is. Even running “ls” involves several layers of abstraction: a shell, a process (abstracts memory), a thread (abstracts CPU)… you think it would be simpler if you had to deal with all that to list a directory (another abstraction)? Even bits are an abstraction over analog voltage levels.
  - glitchc 6mo ago
    You're taking it out of context. I'm specifically referring to abstractions introduced in the codebase to maximize code reuse, as per the OP's comment.
    - dap 6mo ago
      I don't think these things are as different as you think. I started at "ls" and worked down. If you work up, you get things like a "socket", an "object" within a programming language, a "linked list" in a standard library, an "HTTP client" within an application-level package. You can keep going up and rattle off lots of useful abstractions in application-level code. There are certainly _bad_ abstractions that ought not to exist, which I think is what you're getting at. There are poorly built abstractions, and leaky abstractions. But abstraction itself isn't the problem -- abstraction is what allows us to build anything at all without being crushed by the sheer complexity.
      - glitchc 6mo ago
warwickmcintosh 6mo ago
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.
pythontongue 6mo ago
Similar issue as social media making communication more effortless, and thus encouraging higher quantity over quality
abcde666777 6mo ago
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.
- teaearlgraycold 6mo ago
  [dead]
dzonga 6mo ago
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
geophile 6mo ago
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.
dwg 6mo ago
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.
reenorap 6mo ago
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.
- HarHarVeryFunny 6mo ago
  Meta apparently now has a "leaderboard" for who is using the most AI - consuming the most tokens. Must make Anthropic happy, since Meta is using Claude, and accounts for some significant percentage (10%? 20%?) of their total volume.
  - WatchDog 6mo ago
    Token usage is a different and more sympathetic heuristic than LOC produced. The metric by itself tells you nothing about what value those tokens produced, but to some extent it represents the amount of thinking you are able to offload to the computer for you. Wide breadth problems seem to scale well with usage, like scanning millions of LOC of code for vulnerabilities, such as the recent claude mythos results.
    - HarHarVeryFunny 6mo ago
      The trouble with rewarding token usage is the same as rewarding LOC written/generated - if that's what you are asking for then that is what you will get. Asking the AI to "scan the entire codebase for vulnerabilities" would certainly be a good way to climb the leaderboard!
      - WatchDog 6mo ago
        Absolutely, no one should be rewarded for either tokens used or LOC generated. I just think in the absence of any incentives, token usage is a better heuristic as to value produced than LOC generated.
- 6mo ago
genxy 6mo ago
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.
rsanheim 6mo ago
Bragging about loc was silly before ai. Now it’s not only silly, but also makes you look like a huge tool.
- theshrike79 6mo ago
  I have no idea what the loc of any of my projects are. Why would I care? And why do other people care? It's not "line of code" is an uniform measurement you can apply between languages. A 1 loc Perl program can do more things than a 1000 lines of Enterprise-grade Java.
eucyclos 6mo ago
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 ..
red_admiral 6mo ago
> 37K LoC per day across 5 projects I remember the days when we talked about mythical man-months and why LoC was not a good metric to measure programmer output. And then Ken Thompson said [1] > One of my most productive days was throwing away 1000 lines of code. Or the famous -2K LoC story: > Bill Atkinson, the author of Quickdraw [...] had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code [...] it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. [2] [1] disputed: https://skeptics.stackexchange.com/questions/43800/did-the-creator-of-unix-say-one-of-my-most-productive-days-was-throwing-away-10 https://skeptics.stackexchange.com/questions/43800/did-the-c... [2] https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
bustah 6mo ago
[flagged]
juanre 6mo ago
Should we be talking about LLMs' taste and proclivities? Because these can also be prompted. You can put your Claude or Codex in the mind of someone who remembers Larry Wall and his three virtues, and it will do a fantastic job at uncovering the lacking abstractions and poor quality _in someone else's code_. The jury is still out in my mind. Can I use these tools to create software that does not suck? Will the speed at which code can be created and modified lead to a change in our ideas of what good code looks like? Last week I had a good idea for a change in architecture in my software that will make it much more powerful. I set a team of 12 agents on it, mostly unsupervised, with a pretty weak org structure. After a day and a half, and way too many tokens spent, they managed to build the entirely wrong thing. All tests passed. The next few days have been spent with a much simpler structure: two teams, each of two agents, one coding (Codex is better at it these days) and one reviewing and keeping things aligned with the docs (Claude). This may have worked, I am still not sure. My best guess right now of how good software development will look like with these tools: the effort/tokens spent on reviewing needs to be commensurate with the effort spent on coding.
ossianericson 6mo ago
The friction Cantrill describes does not go away, it just moves. In my experience, if you don't do the "lazy" thinking before the model touches anything, you pay for it when trying to maintain something you didn't mentally build. The spec becomes the place where the laziness discipline has to live now.

480 points by gpm 6mo ago

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!

suzzer99 6mo ago

> 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.

badlucklottery 6mo ago
>WET - Write Everything Twice I've always heard this as the "Rule of three": https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
- hackable_sand 6mo ago
  Antymony with DRY
  - deleted 6mo ago
    [deleted]
  - jpfr 6mo ago
    Probably the second rewrite is really tight with good abstractions and little repetition. So no, the end result can still be DRY.
nixpulvis 6mo ago
I've been advocating for writing everything twice since college.
layer8 6mo ago
More than twice is a rather low bar, I don’t think that it conflicts with the quote from Programming Perl.
- suzzer99 6mo ago
  I don't think it's a hard rule, more of an ethos. If you know there are going to be a bunch of something, write the abstraction out of the gate. If you have three code entities with a lot of similar properties, but the app is new and you feel like there's a good chance they might diverge in the future, then leave them separate.
dasil003 6mo ago
Totally agree with this, the beauty of software is the right abstractions have untold impact, spanning many orders of magnitude. I'm talking about the major innovations, things like operating systems, RDBMS, cloud orchestration. But the majority of code in the world is not like that, it's just simple business logic that represents ideas and processes run by humans for human purposes which resist abstraction. That doesn't people from trying though, platform creation is rife within big tech companies as a technical form of empire building and career-driven development. My rule of thumb in tech reviews is you can't have a platform til you have three proven use cases and shown that coupling them together is not a net negative due to the autonomy constraint a shared system imposes.
- genxy 6mo ago
  That is where I put systems programmers, they need to extract an abstract algebra out of the domain. If they are able to accomplish this, the complexity of the problem largely evaporates. Use the wrong abstraction and you are constantly fighting the same exact bug(s) in the system. Good design makes entire classes of bugs impossible to represent. I don't believe the trope that you need to make a bunch of bad designs before you can do good. Those lessons are definitely valuable, but not a requirement. A great example is the evolution from a layered storage stack to a unified one like ZFS. Or compilers from multipass beasts to interactive query based compilers and dynamic jits. The design and properties of the system was always the problem I loved solving, sometimes the low level coding puzzles are fun. Much of programming is a slog though, the flow state has been harder and harder to achieve. The super deep bug finding, sometimes, if you satisfactorily found it and fixed it. This is the part where you learn an incredible amount. Fixing shallow cross module bugs is hell. Don't you have to be really seasoned to in good faith, attempt to couple two systems and say where that would be productive? You can't prove this negative. I would imagine a place like that would have to have a very strong culture of building towards the stated goals. Keeping politics and personalities out of it as much as possible.
HarHarVeryFunny 6mo ago
Writing twice makes sense if time permits, or the opportunity presents itself. First time may be somewhat exploratory (maybe a thow-away prototype), then second time you better understand the problem and can do a better job. A third time, with a new abstraction, is where you need to be careful. Fred Brooks ("Mythical Man Month") refers to it as the "second-system effect" where the confidence of having done something once (for real, not just prototype) may lead to an over-engineered and unnecessarily complex "version 2" as you are tempted to "make it better" by adding layers of abstractions and bells and whistles.
- wcarss 6mo ago
  I agree with what you're saying about writing something twice or even three times to really understand it but I think you might have misunderstood the WET idea: as I understand it, it's meant in opposition to DRY, in the sense of "allow a second copy of the same code", and then when you need a third copy, start to consider introducing an abstraction, rather than religiously avoiding repeated code.
  - HarHarVeryFunny 6mo ago
    Personally, even for a prototype, I'd be using functions immediately as soon as I saw (or anticipated) I needed to do same thing twice - mainly so that if I want to change it later there is one place to change, not many. It's the same for production code of course, but when prototyping the code structure may be quite fluid and you want to keep making changes easy, not have to remember to update multiple copies of the same code. I'm really talking about manually writing code, but the same would apply for AI written code. Having a single place to update when something needs changing is always going to be less error prone. The major concession I make to modularity when developing a prototype is often to put everything into a single source file to make it fast to iteratively refactor etc rather than split it up into modules.
    - skydhash 6mo ago
      The danger with people that claims to follow DRY is that they don’t check first that they are repeating yourself. As soon as they’re encounter similarity, they assume equality and rush to abstract it. But if one knows the domain enough to know that some logic is the same, not just similar, then no need to write it twice first.
jimbokun 6mo ago
That will still result in more abstraction than the average programmer.
raincole 6mo ago
I agree. It's crazy how many layers of abstraction have been created since 1991 (when Programming Perl was published.)
marcus_holmes 6mo ago
"Duplication is far cheaper than the wrong abstraction" Sandi Metz https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
- suzzer99 6mo ago
  And adding an abstraction later is much easier than removing an unneeded one, which can be very hard or even impossible depending on the complexity of the app.

johnfn 6mo ago

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.

fao_ 6mo ago
Yeah! It's not like code quality matters in terms of negative value or lives lost, right?! https://en.wikipedia.org/wiki/Horizon_IT_scandal https://en.wikipedia.org/wiki/Horizon_IT_scandal Furthermore, > As for the artifact that Tan was building with such frenetic energy, I was broadly ignoring it. Polish software engineer Gregorein, however, took it apart, and the results are at once predictable, hilarious and instructive: A single load of Tan’s "newsletter-blog-thingy" included multiple test harnesses (!), the Hello World Rails app (?!), a stowaway text editor, and then eight different variants of the same logo — one of which with zero bytes. Do you think any of the... /things/ bundled in this software increased the surface area that attacks could be leveraged against?
- 8note 6mo ago
  > included multiple test harnesses (!) ive seen plenty of real code written by real people with multiple test harnesses and multiple mocking libraries. its still kinda irrelevant to whether the code does anything useful; only a descriptor of the funding model
  - flir 6mo ago
    If I'm reading this correctly ("a single homepage load of http://garryslist.org http://garryslist.org downloads 6.42 MB across 169 requests"), the test harnesses were being downloaded by end users. They weren't being installed as devDependencies.
- SvenL 6mo ago

pityJuke 6mo ago

Man, I cannot imagine how nice it must to be to work with leadership like this, who just gets it.

simianwords 6mo ago

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.

lapcat 6mo ago
> This is a person clearly grieving that his hard earned knowledge in his field is now not that valuable. He's co-founder and CTO of his own company, so I think he's doing fine in his field.
- simianwords 6mo ago
  It doesn't change the fact that much of what (I think) he prides in himself in is getting commoditised.
  - wiseowise 6mo ago
    LLMs dissolved your brain if you think they commoditize what a guy like this[0] prides in himself. https://bcantrill.dtrace.org/about/ https://bcantrill.dtrace.org/about/
  - pxc 6mo ago
    What he prides himself in (in this context) is craft, which LLM use probably can enable, but definitely isn't commoditized by the kind of vibe coding that Garry Tan is doing.
  - 0xBA5ED 6mo ago
    I would seriously consider if you've developed an imaginary caricature in your mind that you apply to people you don't know. Further, I would consider if any living person actually lives up to it.
  - bcantrill 6mo ago
    On the one hand, I admire (at some level) you sticking to your guns here, willing to take on all comers. On the other, though, I don't entirely understand the inference that you're drawing from the piece; what, exactly, is getting commoditized?

arthurjj 6mo ago

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"

layer8 6mo ago
It’s difficult to define a termination criterion for that. When you ask LLMs to find any X, they usually find something they claim qualifies as X.
- arthurjj 6mo ago
  Agreed. If I'm looking at what it proposes then about 1/2 the time I don't make the changes. If this were fully automated you would need an addendum like "Only make the change if it saves over 100 lines of code or removes 3 duplicate pieces of logic". There are other scenarios you would want to check for but you get the idea.
JeremyNT 6mo ago
I agree, it's not a fundamental characteristic but a limitation of how the tool is being used. If you just tell these things to add, they'll absolutely do that indiscriminately. You end up with these huge piles of slop. But if I tell an LLM backed harness to reduce LOC and DRY during the review phase, it will do that too. I think you're more likely to get the huge piles if you delegate a large task and don't review it (either yourself or with an agent).
ocrow 6mo ago
I've tried this approach of instructing the LLM to look for opportunities to abstract, but it's not good at finding the commonalities after the fact, when possibly related functions have already diverted unnecessarily. It writes "sloppy" code, that is to say code that is locally correct but which fails to build towards overall generalizations, but that sloppy code is a cul-de-sac: easy to write, but adding to messiness, and really tough to improve. When a good programmer writes a new feature, they are looking for both existing and new abstractions that can be applied. They are considering their mental model of the whole system and examining whether it can be leveraged or needs to be updated. That's how they avoid compounding complications. In order to take a big picture view like that, the LLM needs the right context. It would need to focus on what its system model is and decide when to update that system model. For now, just telling it what to write isn't enough to get good code. You have to tell it what to pay attention to.

mplappert 6mo ago

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-of-ai/ https://matthiasplappert.com/blog/2026/laziness-in-the-age-o...)

singron 6mo ago

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.

theshrike79 6mo ago
My rule of thumb is that documentation for AIs can be written by AIs Documentation for humans should be written by humans. Or at the very least read through and signed off on by humans.

flumpcakes 6mo ago

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.

njarboe 6mo ago

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.”

quantummagic 6mo ago
Where my fellow ninety-percenters at?
- dijit 6mo ago
  I think we put too much negative emphasis on people who aren’t as gifted intellectually. In reality, the world works because of human automotons, honest people doing honest work; living their life in hopefully a comforting, complete and wholesome way, quietly contributing their piece to society. There is no shame in this, yet we act as though there is.
  - Jtarii 6mo ago
    The movie Perfect Days captures this perfectly.
  - xboxnolifes 6mo ago
    This is what pains me with how many people respond negatively toward the idea of everyone being able to earn an honest living and raise a family. Too often the idea of "deserving it" comes into it as if doing your small part to contribute to society is not enough.
  - ChosenEnd 6mo ago
    Human automatons? Why would you have mercy for automatons? Just call them cattle, we might feel more compassion towards them if we don't think of them as machinelike.

progbits 6mo ago

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.

btrettel 6mo ago

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.

colechristensen 6mo ago
It's a struggle to get LLMs to generate tests that aren't entirely stupid. Like grepping source code for a string. or assert(1==1, true) You have to have a curated list of every kind of test not to write or you get hundreds of pointless-at-best tests.
- gpm 6mo ago
  > have a curated list of every kind of test not to write I've seen a lot of people interact with LLMs like this and I'm skeptical. It's not how you'd "teach" a human (effectively). Teaching (humans) with positive examples is generally much more effective than with negative examples. You'd show them examples of good tests to write, discuss the properties you want, etc... I try to interact with LLMs the same way. I certainly wouldn't say I've solved "how to interact with LLMs" but it seems to at least mostly work - though I haven't done any (pseudo-)scientific comparison testing or anything. I'm curious if anyone else has opinions on what the best approach is here? Especially if backed up by actual data.
  - jerf 6mo ago
    It's going to be difficult for anyone to have any more "data" than you already do. It's early days for all of us. It's not like there's anyone with 20 years of 2026 AI coding assistant experience. However we can say based on the architecture of the LLMs and how they work that if you want them to not do something, you really don't want to mention the thing you don't want them to do at all. Eventually the negation gets smeared away and the thing you don't want them to do becomes something they consider. You want to stay as positive as possible and flood them with what you do want them to do, so they're too busy doing that to even consider what you didn't want them to do. You just plain don't want the thing you don't want in their vector space at all, not even with adjectives hanging on them.

xhrpost 6mo ago

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.

nulltrace 6mo ago
It also doesn't bother checking what's already in your project. Grep around a bit and you'll find three `formatTimestamp` functions all doing almost the same thing.

spprashant 6mo ago

At this point, I almost feel bad that people are piling on Garry Tan. Almost.

jauntywundrkind 6mo ago

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=47711760 https://news.ycombinator.com/item?id=47711760 To 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.

fragmede 6mo ago

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,

jwpapi 6mo ago

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.

jimbokun 6mo ago

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 https://www.folklore.org/Negative_2000_Lines_Of_Code.html

glitchc 6mo ago

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.

love2read 6mo ago
the thing about abstractions is that nothing implies that they aren’t leaky abstractions, which may be worse than no abstraction for future bug hunters
dap 6mo ago
I’m curious what you think an abstraction is. Even running “ls” involves several layers of abstraction: a shell, a process (abstracts memory), a thread (abstracts CPU)… you think it would be simpler if you had to deal with all that to list a directory (another abstraction)? Even bits are an abstraction over analog voltage levels.
- glitchc 6mo ago
  You're taking it out of context. I'm specifically referring to abstractions introduced in the codebase to maximize code reuse, as per the OP's comment.
  - dap 6mo ago
    I don't think these things are as different as you think. I started at "ls" and worked down. If you work up, you get things like a "socket", an "object" within a programming language, a "linked list" in a standard library, an "HTTP client" within an application-level package. You can keep going up and rattle off lots of useful abstractions in application-level code. There are certainly _bad_ abstractions that ought not to exist, which I think is what you're getting at. There are poorly built abstractions, and leaky abstractions. But abstraction itself isn't the problem -- abstraction is what allows us to build anything at all without being crushed by the sheer complexity.
    - glitchc 6mo ago

warwickmcintosh 6mo ago

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.

pythontongue 6mo ago

Similar issue as social media making communication more effortless, and thus encouraging higher quantity over quality

abcde666777 6mo ago

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.

teaearlgraycold 6mo ago
[dead]

dzonga 6mo ago

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

geophile 6mo ago

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.

dwg 6mo ago

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.

reenorap 6mo ago

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.

HarHarVeryFunny 6mo ago
Meta apparently now has a "leaderboard" for who is using the most AI - consuming the most tokens. Must make Anthropic happy, since Meta is using Claude, and accounts for some significant percentage (10%? 20%?) of their total volume.
- WatchDog 6mo ago
  Token usage is a different and more sympathetic heuristic than LOC produced. The metric by itself tells you nothing about what value those tokens produced, but to some extent it represents the amount of thinking you are able to offload to the computer for you. Wide breadth problems seem to scale well with usage, like scanning millions of LOC of code for vulnerabilities, such as the recent claude mythos results.
  - HarHarVeryFunny 6mo ago
    The trouble with rewarding token usage is the same as rewarding LOC written/generated - if that's what you are asking for then that is what you will get. Asking the AI to "scan the entire codebase for vulnerabilities" would certainly be a good way to climb the leaderboard!
    - WatchDog 6mo ago
      Absolutely, no one should be rewarded for either tokens used or LOC generated. I just think in the absence of any incentives, token usage is a better heuristic as to value produced than LOC generated.
6mo ago

genxy 6mo ago

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.

rsanheim 6mo ago

Bragging about loc was silly before ai. Now it’s not only silly, but also makes you look like a huge tool.

theshrike79 6mo ago
I have no idea what the loc of any of my projects are. Why would I care? And why do other people care? It's not "line of code" is an uniform measurement you can apply between languages. A 1 loc Perl program can do more things than a 1000 lines of Enterprise-grade Java.

eucyclos 6mo ago

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 ..

red_admiral 6mo ago

> 37K LoC per day across 5 projects I remember the days when we talked about mythical man-months and why LoC was not a good metric to measure programmer output. And then Ken Thompson said [1] > One of my most productive days was throwing away 1000 lines of code. Or the famous -2K LoC story: > Bill Atkinson, the author of Quickdraw [...] had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code [...] it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. [2] [1] disputed: https://skeptics.stackexchange.com/questions/43800/did-the-creator-of-unix-say-one-of-my-most-productive-days-was-throwing-away-10 https://skeptics.stackexchange.com/questions/43800/did-the-c... [2] https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html

bustah 6mo ago

[flagged]

juanre 6mo ago

Should we be talking about LLMs' taste and proclivities? Because these can also be prompted. You can put your Claude or Codex in the mind of someone who remembers Larry Wall and his three virtues, and it will do a fantastic job at uncovering the lacking abstractions and poor quality _in someone else's code_. The jury is still out in my mind. Can I use these tools to create software that does not suck? Will the speed at which code can be created and modified lead to a change in our ideas of what good code looks like? Last week I had a good idea for a change in architecture in my software that will make it much more powerful. I set a team of 12 agents on it, mostly unsupervised, with a pretty weak org structure. After a day and a half, and way too many tokens spent, they managed to build the entirely wrong thing. All tests passed. The next few days have been spent with a much simpler structure: two teams, each of two agents, one coding (Codex is better at it these days) and one reviewing and keeping things aligned with the docs (Claude). This may have worked, I am still not sure. My best guess right now of how good software development will look like with these tools: the effort/tokens spent on reviewing needs to be commensurate with the effort spent on coding.

ossianericson 6mo ago

The friction Cantrill describes does not go away, it just moves. In my experience, if you don't do the "lazy" thinking before the model touches anything, you pay for it when trying to maintain something you didn't mentally build. The spec becomes the place where the laziness discipline has to live now.