"Code is Cheap(er)" by Carson Gross https://htmx.org/essays/code-is-cheap/

I can sign off on basically every sentence here.

</> htmx ~ Code is Cheap(er)

In this essay, Carson Gross argues that as AI makes code cheap to produce, understanding code becomes the expensive and scarce resource. He warns of the complexity that LLM code can generate and proposes the subtractive, constraining engineer as the discipline needed to keep systems comprehensible & stable.

@nolan i can'tcompletly agree with that. My view of code is more like working with clay or colors. Doing the coding is for me like working with the material modelling it getti g a feel. Somehow artistic. With llms i have the feel it is more line a delegator. Or someone that just watches from the outside. You dont get the feel of the system you detach. And this in my opinion will result in just shoving more and more code in a system.

I guess the biggest problem is that with llm you are not restricted which will lead to poor design. If you restrict yourself like only using tech x and have your restricted time you will create much smarter systems. At least this is what artists do all the time restricting themselfs to create something new and get creative. This gets totally lost with llms.

This article was the one that makes also that point. I describe llm generated code as fas food it gets the job done but its bad in the long term for your health. Non llm code is like cooking for yourself or eating out in a 5 star restaurant.
https://bcantrill.dtrace.org/2026/04/12/the-peril-of-laziness-lost/

The peril of laziness lost | The Observation Deck

@nolan the supply of code has exceeded demand for most of the century so far and LLMs have just made it worse.

We don't need all this code...there is even too much of the well-written stuff. We need to stop with the building of layer cakes from Hell, take a deep breath and start over.

@nolan Thanks for the link! I think I roughly agree (the Fantasia reference is good!) up until the last section, on the “subtractive engineer.” I’d argue that “understanding” is not a discrete task in an assembly line of software engineering. I guess we could choose that, but it feels like a fast path to burnout for experienced engineers, and a not-particularly-promising way of building expertise for early career folks.
@nolan I’d be open to the idea that we can build understanding in ways that involve less typing, for sure, but it’s a very different productivity multiplier than tech IPOs are promising, and I suspect there’s a reason programming languages haven’t broadly become much higher-level than they currently are.
@nolan I'm no software engineer but when asked to review code people got from genAI for data science tasks, I can certainly say that the main feedback I give is "this part is useless", or "redundant", or "superfluous", or "inconsistent". The complete opposite of something designed to be light, understandable, reviewable, maintainable, and that we can learn from. I get overwhelmed by how much waste is generated by these plagiaristic "disposable solutions" machines.