5 ms·
What we lost the last time code got cheap
- andybak 6mo agoPersonally I've found one of the biggest gains with coding agents is in helping me read code. Actually - that's a lie. I don't read the code. Mostly (unless my spidey-sense goes off) I ask the LLM to read the code and tell me what it does. And then I make a decision based on that. I guess I'm wondering if the article is missing half the picture. Yes - AI is wrong some of the time (and that % varies based on a host of variables). But it can read code as well as just write it. And that does matter as it changes the trade-offs this article is weighing up.
- esafak 6mo agoIt lets you understand the code base at reduced granularity when you want. Or zoom in beyond the written lines to explain _why_ some code is the way it is.
- chris_st 6mo agoI asked Claude to tell me why something was implemented the way it was, and got an excellent response. One data point, would love to hear more examples.
- rectang 6mo agoI agree, Claude has been pretty great at explaining code. It even does well at explaining to me old code that I wrote by hand — including both non-intuitive quirks and flaws. Claude in its default configuration has untapped potential for explaining and documenting code because it defaults to writing no comments. I added this to my global CLAUDE.md and so far so good: # Comments Keep existing comments unless they're wrong or stale. Err slightly toward adding short explanatory comments for non-obvious code.
- chris_st 6mo agoAwesome, stealing that!
- ai_fry_ur_brain 6mo agoWhy not just read the code.. Ya'll are literally letting your brain atrophy by using llms this way.
- casper14 6mo agoHow do I know this comment isn't just AI?
- aspenmartin 6mo agoWhy not just read the assembly?
- andybak 6mo agoDespite you using "literally" purely for emphasis, I would dispute this based on both the literal and popular meaning of "literally".
- foobarian 6mo agoIt's been pretty great for ramping up into codebases too. "Give me a summary of project in current checkout in markdown form."
- y3ahd0g 6mo agoI like to constrain it as much as possible to ignore variables and function names; the human stuff. With a new code base my first goal understand how it CRUDs state. What structures and what operations? Less concerned at the outset if its sorting carrots or processing orders for shirts. AI seems to work way better for me when I tell it to ignore the use case and focus on surfacing runtime and mathematical operations embedded in the code. Constraints on new abstraction and telling it to stick to math terms and types and objects also seems to help avoid hallucinations and layers of useless indirection.
- dilyevsky 6mo agoThe "It’s harder to read code than to write it" was always silly. The example spolsky gives to support it is basically "devs like to rewrite other devs code, therefore reading is hard" which is obviously bunch of nonsense. That's like saying reading poetry is harder than writing poetry because poets keep writing new poems despite the fact that Shakespeare already wrote it. Now that you can recruit LLM to explain any complicated codebase to you it's even less true.
- pixl97 6mo agoThis isn't a great analogy. The thing about code is it is part of a whole. While often code can be read in smaller pieces and understood, quite often you have to understand a very large part, if not all the work to really see what is going on. This is why things like SAST are topical. They miss all kinds of exploits because they don't understand the program. The more in depth you try to scan the more the memory requirements explode. Now LLMs are much better at this, but between context windows and costs you can bankrupt yourself pretty quick putting code bases in context memory.
- dilyevsky 6mo agoThis analogy directly addresses spolsky’s botched argument. The point is devs went into this career to dev not read other people’s code whether it makes business sense or not. What you said applies to writing code just as well as reading it so clearly writing cant be easier than reading - it’s at least as hard and most definitely harder
- Aurornis 6mo agoThere are times when reading the code is necessary, but oh boy are LLMs so much faster at finding the part of the codebase I want to read. Several projects I work on call into or interact with gigantic codebases. A couple years ago I would have to allocate 30 minutes some times to either trace through the code base or setup and attach a debugger to step through the code until I found the part I needed to know about. Now I send an LLM to go find it and it comes back with a list of files and line numbers in minutes. It’s still not perfect. I had a codebase walk this morning where even GPT-5.5 extra high failed to find something I knew was in there on the first pass. It got it with some more directed prompting. If you delegate trust 100% to an LLM you will get bit eventually.
- BosunoB 6mo agoExactly, and that's why this maxim about "understanding the code base" being the bottleneck is also somewhat misleading. Claude is even better at helping you understand the code base then it is at writing code! It can look at a bunch of files and give you an accurate run down in ten minutes.
- nabbed 6mo agoI worried this blog post was going to pivot into a marketing pitch for some product, but no, it just describes the issue where the AI tool that generates your code probably won't document its reasons for the choices it makes. That documentation problem exists in the pre-AI era too, except that the reasons might exist in the heads of your co-workers and could possibly be teased out. I know nothing about AI code generation (or about AI in general), but I wonder if you could include in your prompt a request that the AI describe the reasons for its choices and actually include those reasons as comments in the code.
- radicalbyte 6mo agoVery few developers do that especially on early / key parts of the codebase.
- andybak 6mo agoIsn't one of the common criticisms of AI code that it's a bit too keen to write extensive comments - even when they probably aren't needed?
- Semaphor 6mo agoIME the comments are not useful though. I'm not the biggest fan of AI code, but the codes still way higher quality than the "this is what this does" comments
- mbauman 6mo agoWell the comments tend to be superfluous "whats" (describing the code itself) instead of the more helpful "whys." And they're almost never the most useful "why nots".
- idle_zealot 6mo ago> And they're almost never the most useful "why nots". Really? I find that Claude really likes to write "why nots" in comments when iterating on implementations and fixing bugs, to the extent that the comments grow into spot-logs of overly-specific documentation of what was tried and why it was scrapped.
- deleted 6mo ago[deleted]
- htx80nerd 6mo ago>The cost of producing code has collapsed. AI tools can generate functional, adequate, perfectly average code at a speed and cost that would have been unimaginable even five years ago. And like the outsourcing wave of the early 2000s, the economics are real and rational. Nobody is wrong for using these tools. The code they produce is often fine. It works. It passes tests. It might ship as-is. After using AI for months (Claude, Gemini, ChatGPT) it is extremely rare for their code to work 'as is' first shot and almost always requires several iterations and cleaning up edge-cases. When it does work 'first shot' it's usually when it's transferring existing working code to a new project which is slightly different.
- simonw 6mo agoHave you tried the "use red/green TDD" trick? I believe that increases the chances of one-shot code working, though it's also possible that it did that against Opus 4.5 and isn't necessary against Opus 4.7 but I haven't spotted the difference yet.
- sanderjd 6mo agoYeah this is the way. Thinking about how it will verify that it has done the right thing is the key. This been be set up at the AGENTS.md level. Very simple things like: "Write tests and make sure they pass." "Run lint after each change." "Write API docs in XYZ format." In my experience, they are very good at fixing things they've done wrong after discovering them during those kinds of steps.
- bluebands 6mo agotry gpt-5.5-xhigh fast in codex mac app, preferably with TDD and /goal, with a clearly defined end result it's unbelievable, it will do the iterations for you, it will easily work 12 hours straight until it's a good output
- sanderjd 6mo agoWeird, this isn't my experience at all (mostly writing Python lately). Granted, it usually doesn't implement things exactly the way I want them to be implemented, and I iterate a lot on that. But I think it's been like a year? at least six months, since the code didn't work on the first try.
- kadhirvelm 6mo agoCurious what other teams are doing to keep encouraging people to think critically about their code? I’ve been finding it harder to keep people motivated, keep them engaged with all the changes coming in. And I can’t blame them, it’s been overwhelming. Is everyone else just using more AI..?
- zeeveener 6mo agoPersonally, guiding junior teammates down the path away from purely "Writer of Code" to "Implementer of Functionality" has been working well for me. If you get them involved in the design process, they feel heard. Feeling heard is one surefire way to have a person feel involved. Feeling involved fosters a sense of ownership and pride which in turn helps keep a person engaged.
- copperx 6mo agoManagement 101.
- kadhirvelm 6mo agoYeah I like that, there’s probably something to this full stack builder persona that could keep people motivated long term. So long as they feel ownership, seems like that’s a pretty good bet for long term engagement
- somewhatgoated 6mo agoMore AI is always the answer.
- sanderjd 6mo agoYeah this is a good call out. What I've been doing so far is just hoping and praying that people naturally evolve their entire way of working without becoming demotivated or burned out. Seems like a bad strategy.
- evilduck 6mo agoI had a senior engineer last week just completely fail to implement an entire subsection of acceptance criteria on a story before creating a PR and got the answer/attempted excuse that the AI agent "missed it" and they didn't double check the work. This is something I haven't seen a senior engineer do in recent memory prior to AI entering the workplace, they at least read the requirements back then even if they misinterpreted them. Literally just a few minutes ago I had a senior architect send out a clearly Claude-generated .docx project proposal filled to the brim with stuff that is outright not permitted in our organization due to legal constraints and IT policy decisions. This guy has been with the organization for a few years so none of our limitations should have been a surprise. I got to page two before I replied that it was unprofessional to send me AI slop and expect me to be the first to read it. Some people seem really great with AI as a force multiplier. For others their brain just shuts off entirely. Sorting out how it will affect each person is the real challenge now. We don't even mandate AI usage, it's just there if you want to use it which makes it even more frustrating. As for my approach? A one on one discussion reiterating my expectations that they remain thoughtfully engaged and if needed followed up by formal verbal warnings and then PIPs.
- deleted 6mo ago[deleted]
- _diyar 6mo agoI think a huge gap in the market today is documentation that is both easy for humans to navigate and understand, but also readily ingestible for agents.
- allthetime 6mo agoSelf generating docs based on docstring comments are great. LLMs are capable of generating architectural overview docs from these. What more do you need?
- croemer 6mo agoReads at least partially like LLM writing, for example: > When code production gets cheap, the cost doesn't disappear. It migrates. > It was true then. It is unavoidably true now.
- lamename 6mo agoDo you disagree with the point made?
- recursive 6mo agoForming a human opinion about slop is like asymmetrical warfare. Or maybe a closer analogy is a Gish Gallop. It can be generated with way less effort than it takes to comprehend it, much less form a coherent opinion on it.
- Forgeties79 6mo agoVery parallel to the asymmetric bullshit principal
- rogerrogerr 6mo agoLLMs are running a gish gallop at Internet scale. It is not necessary or possible to disprove every sequence of tokens that emerges from one. https://en.wikipedia.org/wiki/Gish_gallop https://en.wikipedia.org/wiki/Gish_gallop
- Forgeties79 6mo agoIf I want a boring, rote LLM answer I will prompt it myself. I don’t read blogs to have a middleman between me and a prompt.
- jraph 6mo agoIt matters whether something is written using an LLM even if we put aside the ethical aspects. Firstly, if your text is deadly boring to read, your point might not get across optimally and one might not just be interesting reading slop. Secondly, you might just been reading the LLM's opinion, and I'm just not interested neither. Thirdly, even if you are just using the LLM as an assistant, we know that your opinion itself may be influenced by the suggestions and since you are still under the impression you are writing yourself (which you are somewhat, not saying), you may internalize the suggestions as your own opinion. There are recent (probably imperfect) studies about this stuff.
- gojomo 6mo agoThe context of when that previous experience - Heartland outsourcing to India – happened would be helpful. The 90s? The 00s? The 10s?
- lamename 6mo agoThe link in the article that is right near the words you're talking about links to a wikipedia page that says the book is from 2005. So I conclude it was 2005 or soon after
- pmmucsd 6mo agoRelated (maybe the same thing): Whenever an agent is planning there are often architecture and product choices that it asks humans to make. None of this intent is captured in the code or comments. We started a decisions.md file and updated CLAUDE.md and AGENTS.md to create an entry in the decisions.md file everytime it has to ask a human about what to do. It captures the intent so at least we have doc that describes why certain choices were made.
- alexhans 6mo agoTo me, design files living in the repo are what captures these high and low level decisions. They should express intent which is paramount for automation. Where are you keeping your design? If it's a WYSIWYG doc like word, what would it take for you to switch to a more text driven world?
- crooked-v 6mo agoThe structure https://acai.sh/ https://acai.sh/ uses feels to me like a decent starting point for this kind of thing that avoids the "single giant file" issue.
- nostrademons 6mo agoHuman coders have the same problem too - oftentimes the most important question that future maintainers have of the code is "Why was this decision made?", but that's not captured anywhere in the code itself. The right place for this is usually in the design doc or commit message, and robust engineering organizations will ensure that commits are cross-referenced back to design and requirements docs so you can trace decisions from git blame back to the actual rationale. The same process also works pretty well with LLMs. Google, for example, is internally championing a process where the engineer has a dialog with the LLM to generate a design doc, oftentimes with an adversarial LLM to poke holes in the design. Once the design is fully specified, the last step is to ask the LLM to turn the design doc into code. This creates a human-readable artifact that traces the decisions that the human and AI collaboratively made, which then can be traced back from the code.
- irq-1 6mo ago
- wiremine 6mo ago> The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is. I don't disagree, but I've been thinking about this a bit: a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it. I'm not advocating that we fire devs, or evangelizing that LLms are awesome. But I do wish there was a slightly more honest take on the pre-LLM world: it's not just about cost reduction, it's about solving some long-term structural deficiencies of industry.
- bluefirebrand 6mo ago> a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it. I don't think anyone truly disputes this, but I don't think it's a good argument. If we already had a sort of poor quality output when humans were at the helm, then what can we expect from AI steered by the sort of humans that produced poor quality code? My guess would be even more poor quality code, at much higher volumes than before. It is impossible for me to see this as an improvement over "some people always made poor quality code"
- wiremine 6mo ago> then what can we expect from AI steered by the sort of humans that produced poor quality code. Great point, and I think that's my argument: above-average engineers can now produce more above average code. We don't need as many (any?) below-average developers moving forward.
- bluefirebrand 6mo agoIt's possible, but I think unlikely. For one thing, most managers can't really tell who is above or below average. We still in 2026 have "lines of code" as a usual metric for judging the quality of a dev. So how do you think that will play out in reality?
- wiremine 6mo ago
- olsondv 6mo agoWhen I generate code with AI, I will read through each change as it makes them (babysitting). If I don’t understand it, then I ask for explanation right away. At least by the end I have a grasp on what each change does and the reasoning. Then, I can make a PR and highlight the same info for my reviewer and for longevity. Our codebase style is not to litter comments everywhere. We go back to the code review for details and discussion. Obviously, this only works if the changes are small.
- sanderjd 6mo agoYeah I work in pretty small chunks and do a lot of iteration on each chunk. This is harder when I'm reviewing other peoples' work. It has definitely gotten to the point where I spend more time reviewing than implementing and find it to be the much more difficult part of the job. Which honestly sucks.
- synapsehire 6mo ago[flagged]
- jbvlkt 6mo agoI do not understand why this is so unpopular today? I feel like everyone now thinks that basically all of SW engineering is outdated. We are supposed to forget all lessons learned and let agents to go through this? My opinion is to not care who did the job. But we should apply the same standard to human and AI output. I do not buy "we should not look at code". If we should not look at it what we should check instead to have the same control over final product? Because not having control over final product is so stupid right now.
- larsfaye 6mo agoThe "don't look at the code" movement is a fad that we simply have to go through to prove that the real problems were never obvious, but lie in the subtle nuances and interplay between all the moving parts of what makes software function in the first place. We have to abuse the tool before we learn to properly use the tool.
- rrr_oh_man 6mo ago> The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is The blog posts they [LLMs] write are often fine. They work. They pass tests. They might ship as-is
- cicko 6mo agoWhat is wrong with using LLMs to analyze and explain code? Am I missing something? Before writing code, this is an even easier task to accomplish using AI.
- sanderjd 6mo agoThere is something to this, but to the concluding paragraph: I think these tools already are extremely good at helping us understand code, in addition to helping us generate it.
- 0xjeffro 6mo agoCoding agent to me, means shifting my brain from memory-bound to compute-bound
- fdvlol 6mo ago[flagged]
- mvandermeulen 6mo agoThat’s a cricket ball
- deterministic 6mo ago> The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is. Often is not goo enough. I always carefully review AI generated code and sometimes find and fix bugs. Apparently (according to a Google survey I think?) AI's produce 1.7 times the number of bugs that a human typically does.