The silent death of good code

There is a real advantage to having good code especially when using agents. "Good Code" makes iteration faster, the agent is unlikely to make mistakes and will continue to produce extensible code that can easily be debugged (by both you and the agent).

A couple months ago I refactored a module that had gotten unweildly, and I tried to test if Claude could add new features on the old code. Opus 4.5 just could not add the feature in the legacy module (which was a monster function that just got feature-crept), but was able to completely one shot it after the refactor.

So there is clear value in having "clean code", but I'm not sure how valuable it is. If even AGI cannot handle tech debt, then there's value is at least building scaffolding (or atleast prompting the scaffolding first). On the other hand there may be a future where the human doesn't concern himself with "clean code" at all: if the value of "clean code" only saves 5 minutes to a sufficiently advanced agent, the scaffolding work is usefuless.

My reference is assembly - I'm in my early 30s and I have never once cared about "clean" assembly. I have cared about the ASM of specific hot functions I have had to optimize, but I've never learned what is proper architecture for assembly programs.

There is still a market for good code in the world, however. The uses of software are nearly infinite, and while certain big-name software gets a free pass on being shitty due to monopoly and network effects, other types of software will still find people who will pay for them if they are responsive, secure, not wildly buggy, and can add new features without a 6 month turnaround time because the codebase isn't a crime against humanity.

On another note, there have been at least four articles on the front page today about the death of coding. As there are every other day. I know I'm tired of reading them, but don't people get bored of writing them?

I could certainly see the point they were trying to make, but pointed out that compilers produced code from abstract syntax trees, and the created abstract syntax trees by processing tokens that were defined by a grammar. Further, the same tokens in the same sequence would always produce the same abstract syntax tree. That is not the case with coding 'agents'. What they produce is, by definition, an approximation of a solution to the prompt as presented. I pointed out you could design a lot of things successfully just assuming that the value of 'pi' was 3. But when things had to fit together, they wouldn't.

We are entering a period where a phenomenal amount of machine code will be created that approximates the function desired. I happen to think it will be a time of many malfunctioning systems in interesting and sometimes dangerous ways.

That audience is changing. Increasingly, the primary reader is an agent, not a human. Good code now means code that lets agents make changes quickly and safely to create value.

Humans and agents have very different constraints. Humans have limited working memory and rely on abstraction to compress complexity. Agents are comfortable with hundreds of thousands of tokens and can brute-force pattern recognition and generation where humans cannot.

We are still at the start of this shift. Our languages and tools were designed for humans. The next phase is optimizing them for agents, and it likely will not be humans doing that optimization. LLMs themselves will design tools, representations, and workflows that suit agent cognition rather than human intuition.

Just as high-level languages bent machine code toward human needs, LLMs let us specify intent at a much higher level. From there, agents can shape the underlying systems to better serve their own strengths.

For now, engineers are still needed to provide rigor and clearly specify intent. As feedback loops shorten, we will see more imperfect systems refined through use rather than upfront design. The iteration looks less like careful planning and more like saying “I expected you to do ABC, not XYZ,” then correcting from there.

The problem with this argument is many do not believe this sort of leverage is possible outside of a select few domains, so we're sort of condemned to stay at a low level of abstraction. We comfort ourselves by saying it is pragmatic.

LLMs target this because the vast, vast majority of code is not written like this, for better or for worse. (It's not a value judgment, it just is.) This is a continuation (couldn't resist) of the trend away from things like SICP. Even the SICP authors admitted programming had become more about experimentation and gluing together ready-made parts than building beautifully layered abstractions which enable programs to just fall out of easily.

I don't agree with the author, BTW. Good code is needed in certain things. It's just a lot of the industry really tries to beat it out of you. That's been the case for awhile. What's different now is that devs themselves are seemingly joining in (or at least, are being perceived to be).

People talk about writing the code itself and being intimate with it and knowing how every nook and cranny works. This is gone. It’s more akin to on call where you’re trudging over code and understanding it as you go.

Good code is easy to understand in this scenario; you get a clear view of intent, and the right details are hidden from you to keep from overwhelming you with detail.

We’re going to spend a lot more time reading code than before, better make it a very good experience.

So having used Claude Code since it came out I’ve decided the resulting code is overall just as good as what I’d see in regular programming scenarios.

I agree it is sad though. I changed careers from one I was unhappy with into software development. Part of what drew me to software was that (at least sometimes) it feels like there is a beauty in writing what the author describes as great code. It makes you really feel like a 'master craftsman', even if that sounds a bit dramatic. That part of the profession seems to fading away the more agentic coding catches on. I still try to minimize use of any LLM's when doing personal projects so I can maintain that feeling.

- PMs hate it because you're busy putting up scaffolding instead of painting

- Managers hate it because they have to cover for it

- Other engineers hate it because they could be doing it better

- VPs and directors hate it because they can't think beyond the release cycle, so the engineer is an architecture astronaut who should focus

There is basically no reward for actually putting thought into a programming solution anymore. The incentives are aligned against it unless you can get your manager to run interference for you.

https://users.cs.utah.edu/~elb/folklore/mel.html

But now, reading, understanding, and maintaining the software is the job of coding agents. You are free to do the interesting work: setting goals and directions for the agents, evaluating the finished product, communicating with stakeholders, etc. This has always been the hard and interesting part of systems design: solving real-world problems for people and businesses.

Afaic, people designing circuits still do care about that.

> Good Assembly

The thing with the current state of coding is that we are not replacing "Coding Java" with something else. We are replacing it with "Coding Java via discussion". And that can be fine at times but it still is a game of diminishing returns. LLMs still make surprising mistakes, they too often forget specifics, make naive assumptions and happily follow along local minima. All of the above lead to inflated codebases in the long run which leads to bogged down projects and detached devs.

This is the point that everybody needs to calm down and understand. LLMs are fantastic for POCs _which then get rewritten_. Meaning: the point is to rewrite it, by hand. Even if this is not as fast as shipping the POC and pretending everything is ok (don't do this!) it still drastically speeds up the software engineering pipeline and has the potential to increase Good Code overall.

A perfectly reasonable rule in software organizations is: For greenfield code, LLMs are strictly required for 1st-pass prototyping (also required!). And then: Hand writes (within reason) for production code. Your company will not lose their competitive edge following this guideline, and this includes your hard-earned skills.

I think "good code" t was a "nice" pursuit but became too much of an end in itself while code was always - for me - just a means to create something that "just werks"

But I'm not sure the "good code" fans need to worry because they might be able to obsess over "proper prompting" and the "correct way to use agents" or "appopriate ai tooling" or something like that on this next wave of "code creation"

The authors colleague needed a couple of tries to write a kernel extension and somehow this means something about programming. If it was not for LLMs I would not have gone back to low-level programming, this stuff is actually getting fun again. Lets check the assembly the compiler produced for the code the LLM produced.

I also make sure to describe and break down problems when I ask an agent to implement them in such a way that they produce code that I think is elegant.

It seems to me like people think there's only two settings: either slaving away carefully on the craft of your code at a syntactic level, manually writing it, or shitting out first pass vide-coded slop without taking care to specify the problem or iterate on the code afterwards. But you can apply just as much care to what the agent produces, and in my experience, still see significant speedups, since refactoring and documentation and pulling out common abstractions and so on are something that agents can do extremely reliably and quickly, but otherwise require a lot of manual text editing and compile/test passes to do yourself.

As long as you don't get hung up on making the agent produce exactly character for character, the code you would have produced, but instead just have good standards for functionality and cleanliness and elegance of design.

I believe the right use of AI makes it possible to write more beautiful code than ever before.

Good code isn't dying. The cost of bad code just went up.

AI is at best a good intern or a new junior developer. We're locking in mediocrity and continuing enshittification. "Good enough" is codified as good enough, and nothing will be good or excellent. Non-determinism, and some amount of inaccuracy on the margins continually, no matter the industry or task at hand including finance, just so we can avoid paying a person to do the job

If the function is a black box, but you’re sure the inputs produces a certain output without side effects and is fast, do you NEED “good code” inside?

After about 10yrs of coding, the next 10 of coding is pretty brainless. Better to try and solve people/tech interaction problems than plumbing up yet-another-social/mobile/gaming/crypto thing.

For example, I think LLM benefit from having very verbose code that repeats and repeats the same important code/comments/strings/exceptions all over the place. We are going to produce more code than ever before.

From what I have seen so far, productivity will go up but there will more and more rot underneath the systems that we build. The fact that LLMs are tireless is both a blessing and a curse. It will never stop writing code until you tell it to.

We will arrive in a future where we NEED LLMs to understand our own code. At that point, do you hire another highly skilled and expensive individual to manage the complexity of your codebase or spend 100$ more ask an LLM to fix it (and promise we will do the refactor in the future!)

In a sense, we have had this before. We no longer write assembly. We don't program against the hardware anymore, even if you are writing C, you are writing against the abstract C machine. We are no longer writing against any machine, it is more of a concept now. This is just another step of abstraction. "Can you please change this list to be sorted alphanumerically" will no longer involve a calculated change in UI code. It is more like telling the computer what to do.

The way I am using LLM now is to get the rough general direction. "Can you please write me an NFS driver for this new filesystem with stub functions", then it spits out ~500 lines of code that I can now study. After I am done learning, I will usually rewrite everything myself. But this is probably not productive for future LLM uses. It might be better to keep the code as is if I want to keep using LLMs to iterate.

Frankly, I don't know how I feel about this. It is probably just a part of getting older and seeing the world move past you? For god's sake I am not even 30 yet.