{"slug": "code-is-cheap-er", "title": "Code Is Cheap(er)", "summary": "AI-generated code has become significantly cheaper and faster to produce, reducing the importance of raw coding skills in software development. This shift makes understanding code more expensive and dangerous, as developers risk losing control over systems they cannot comprehend, similar to the Sorcerer's Apprentice scenario. The growing complexity from cheap code threatens to overwhelm teams unless they maintain deep understanding and use AI incrementally.", "body_md": "# Code is Cheap(er)\n\nCarson GrossThere is no getting around the fact that, in the last year, code has gotten much cheaper to create. AI is able to generate reams and reams of code, often of reasonably decent quality, incredibly quickly. There is no point in pretending that this isn’t the case.\n\nAt times, when confronted with this admittedly uncomfortable fact, I have seen people I respect say something like “coding was never the problem.”\n\nWhile I appreciate the sentiment, I don’t completely agree with that: certainly coding was at least *part* of the problem.\n\nAnd that part of the problem has shrunk significantly with the advent of effective AI coding tools.\n\nSo what does raw coding becoming less important mean for software developers, people who, in the past, prided themselves (and often compared themselves) on their ability to code?\n\n[Understanding is Expensive(er)](#understanding-is-expensive-er)\n\nOne thing I see is that it means that *understanding* code has become more expensive. This is because when reams\nand reams of code are generated, rather than emerging painfully from a particular programmer’s fingers, there *is* no\nunderstanding of that code.\n\nIn as much as understanding that code needs to exist, it has to be done after the code is written, by reading the code.\n\nNote that conventional wisdom is that reading someone else’s code is harder than writing your own code.\n\nSome AI enthusiasts say “Who cares, you don’t understand the output of compilers.”\n\nI think that is a category error for multiple reasons:\n\n- Compilers are deterministic; LLMs are, by design, not\n- Compiler workflows retain their original source code; LLM workflows typically do not\n- Compiler output is to a narrowly constrained domain (machine code); LLM output is not (generalized software)\n\nI maintain that, in most cases and certainly for mission-critical software, developers still need to understand the underlying code even if it is generated by an LLM.\n\nAnd if code *is* generated by an LLM there is a stark danger: the LLM can produce code far faster than you, or anyone else,\ncan understand it. This is why I recommend incremental use of LLMs rather than allowing them to generate massive changelists\nthat neither you, nor anyone else, can understand.\n\n(There are times when this can be appropriate, such as in a mechanical refactor, but it is extremely dangerous when new semantics are being introduced into a code base.)\n\n[The Sorcerer’s Apprentice Trap](#the-sorcerer-s-apprentice-trap)\n\nOne movie scene that has been consistently coming back to me as I have watched AI garner more and more attention\nis [The Sorcerer’s Apprentice](https://video.disney.com/watch/sorcerer-s-apprentice-fantasia-4ea9ebc01a74ea59a5867853)\nfrom Disney’s movie *Fantasia*.\n\nIn this scene the apprentice decides to use magic to assist in the drudgery of cleaning. He enchants a broom which then proceeds to start cleaning things up. Things appear to be going swimmingly for a while, until the broom starts cleaning more and more vigorously, reaching a point where things start going swimmingly literally.\n\nThe chaos is resolved when the Sorcerer reappears and asserts control over the situation, glaring at the apprentice for his foolishness.\n\nThis seems like an apt metaphor for the AI era: you want to be a sorcerer and not an apprentice.\n\nAnd a sorcerer has to understand the code.\n\n[Complexity: Still Bad](#complexity-still-bad)\n\nHumans, generally, have a poor grasp of geometric and exponential curves.\n\n(This is why they believe in fairy tales such as compound interest.)\n\nThe core danger of code being cheap is [complexity](https://grugbrain.dev), which I assert, without proof, tends to grow\nat least geometrically and often exponentially with the size of a system.\n\nBefore LLMs there were prolific human coders.\n\nPerhaps you have worked with one: they can write *a lot* of code.\n\nI have seen prolific coders who lack a proper fear of complexity heap more and more code on top of an existing problem until the whole system collapses into an unmodifiable steady state, where any change creates as many bugs as it fixes.\n\nLLMs are incapable of fear of complexity, and are prolific coders.\n\nSeems dangerous to me.\n\n[The Subtractive, Constraining Engineer](#the-subtractive-constraining-engineer)\n\nTo address this danger of LLM-generated code, I propose the subtractive, constraining engineer:\n\nThis engineer [says no](https://grugbrain.dev/#grug-on-saying-no), closely examines LLM output, suggests simplifications and\ngenerally retains a firm hand when dealing with LLM-generated code.\n\nRather than priding themselves on the code they create, they pride themselves on the code (and layers) they *remove* from\nor prevent from entering systems.\n\nThis ethos is more sculptor and less builder.\n\nWhere the builder ethos still applies, to an extent, is at the system design level: a good engineer will need to know how to compose components effectively to create systems. However, even here, I think that the subtractive mindset will be useful: removing unnecessary components and system boundaries to simplify system deployment and inter-component interactions, etc.\n\nThe subtractive engineer is a different kind of engineer than most coders have been in the past. I will admit that I have always been sympathetic to the subtractive engineer mindset: I don’t mind saying no, I don’t mind polishing existing systems rather than heroic rewrites, etc.\n\nBut, admitting my own biases, I believe this approach is a productive way to engage with LLMs that retains the art of computer programming and properly acknowledges a dual reality: code has gotten much cheaper to create and complexity remains our apex predator.", "url": "https://wpnews.pro/news/code-is-cheap-er", "canonical_source": "https://htmx.org/essays/code-is-cheap/", "published_at": "2026-06-04 19:30:54+00:00", "updated_at": "2026-06-04 19:50:11.838284+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-tools"], "entities": ["Carson Gross"], "alternates": {"html": "https://wpnews.pro/news/code-is-cheap-er", "markdown": "https://wpnews.pro/news/code-is-cheap-er.md", "text": "https://wpnews.pro/news/code-is-cheap-er.txt", "jsonld": "https://wpnews.pro/news/code-is-cheap-er.jsonld"}}