They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.

I'm as hateful of LLMs hollowing out the job market as the next guy, but the reality is the frontier LLMs are really good at writing anything that's been done and documented on the Internet a million times and unfortunately most of what software devs have been doing the last couple decades is shitting out cookie cutter CRUD apps.

I have my doubts about whether the state of the industry is going to advance as long as we're having LLMs do all the creation, but that's another diatribe.

> Apparently it's not obvious to everyone, but if you can't write code, you can't review it.

There's more to it than that: writing is thinking. If you stop writing code, you aren't thinking anymore.

Many argue that they're now thinking at a higher level (maybe they weren't before?), but, guess what, that high-level design can be done better by the LLM than by you anyway. It's only temporary.

I’m finding it all boils down to cognitive differences.

Some people find code easier to read than the English description. It’s more precise and many experienced devs can scan it and know what’s happening

Many other people can’t read code. Or they find English easier to read than code.

Thats not a knock on anyone. Maybe the latter will rule the world because the former focuses too much on irrelevant details. Or maybe me there are just different types of problems that need differing levels of attention to detail.

Pretty sure Casey Muratori and Demetri Spanos cover why in one of their videos online.

Less about “trusting” the llm and more about how complex it is to work with binaries due to machine code being different per machine and hard to interpret the context of the code as well as offsets.

In that sense because high level languages come with the ability to add context to what code does. It’s like the understanding a human has when given decompiled C code ghidra gives you vs C source code a developer wrote.

Also the compiler helps the llm write “compiled / working code”, if it just spat out machine code it most likely not even run at all.

But yea generally if you can’t write code at all, reviewing it is even harder.

First of all, obviously there's more training data on high level languages than assembly / compiled binaries. Secondly, Python, Java or even C is portable to another device. You know, one of the main points of high level languages: that you don't have to rewrite your app from scratch each time you want to change the machine it runs on.

Thirdly, compilers also do type checking and other static analysis and dynamic checks (array length etc). So it's not only got more guardrails against "mistakes" by the LLM, but it's also most likely "easier" for the LLM to "reason" about (in the sense that LLMs can reason).

There's no intrinsic value to having humans read the code, so as soon as LLMs are good enough to work on their own, companies will no longer need to keep developers who can read code as a backup solution.

> Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much

No, people do advocate for this. It may simply not be as portable however as something that is high level able to be compiled to assembly for many machines.

I have a few personal projects, i let codex do all the code - i do the thinking and testing.

One time, something didn't work as expected - its the first time it happened with this project. I read through the section of code and it was perfectly readable and well-written.

Turned out a plugin wasn't effecting the audio, so i just got it to pad some blank audio onto the beginning before processing it, then remove it at the end of the process. That fixed the issue, there was nothing wrong with the code but my ability to think laterally is what made it work.

We're getting to the stage where you can just ask them to write code and they will do what you want, and it writes good code. Its up to you to test everything beyond the internal tests it writes.

> Apparently it's not obvious to everyone, but if you can't write code, you can't review it.

Why review it at all? The trend is to vibe code everything with agent harnesses and tokenmaxxxing.

This isn’t obvious at all. Editors can evaluate and improve the work of writers even without being bestselling novelists themselves. Richard Williams coached his girls to world championships without winning one himself. Roger Ebert never even made a movie.

No defense for not writing or reading code if want to call yourself a software engineer or programmer.

However I do think there is reason to use Java or Python (as much as I loathe both) they have GC, and it'd be a lot easier for AI to fuck up memory safety in something like assembly or C.

Ask the ai what the game theory is for training employees... the Nash equilibrium is under training and self funded certification/training for devs in low trust environments.

dump out assembly?

aargh! haalp!

Which rock are you living under these days.

Nowadays everything is IR or MLIR ... or AIR ...

whoops, i may have skipped a few generations. hard to keep up with the dynamic pace these days. got a job to save. sorry suh.

mumble javascript mumble framework of the half-week ...

walks off muttering

churning out assembly code would cost far more in tokens, wouldn't make financial sense for the improved performance which doens't matter that much for most use cases.

just to add to your excellent observation

by writing code by hand - you're the author & editor at the same time.

if you're skilled enough - you quickly get to the desired state vs the llm which while might produce a lot of code - but it likely won't give the end state you desire.

an analogy - Jason Fried gave - producing software by llm's is like bragging you're a photographer by pressing the shutter button on an automatic camera.

while the art of photography - is about producing the single perfect photo - that communicates the photographers intent (what they want the world to see & experience).

likewise in software - what we make should be deliberate.

> but no, they don't trust the LLM that much

Yet...

>if you can't write code, you can't review it.

I don't write code anymore and I doubt I ever will ever again.

On the flipside I review exponentially more code than ever before.

>Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much

It's not "not trusting" the llm its that the llm has been undergoing reinforcement learning is on coding. Plus generating assembly is extremely token inefficient.

Original link: <https://web.archive.org/web/20260521130338/https://www.commi...>

My other article on this topic advocates for using code over specs :)

It’s ok to talk to the agent in code. Or create examples for it to follow.

https://softwaredoug.com/blog/2026/07/04/write-code-not-spec...

This is why you need lisp.

First you write a programming language in which the language primatives are the business logic primatives, then you write a trivial program that describes what the business does in the new language.

> For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works.

We already tried this with humans. It works so poorly that it got the derogatory name “ivory tower architect”. It usually results in theoretical designs that are unworkable in the actual system, implementation teams (or LLMs) that work around the architecture and a lot of slowing down of velocity as the architect and implementers argue past each other.

> With generated code you'll search for a long time

The observability people will claim that if the dynamic runtime behaviour of your system makes it hard to find the source of a behaviour, your system must be made more transparent and observable. They would also claim this was always the case -- we should never have relied on people's mental models being amazing because people move around.

(I don't know yet where I stand on this but I'm trying to learn more.)

I personally am advocating for writing small amounts of code because I think it makes you more productive

Spending a day manually reworking the architecture in my experience can save you $1000s in tokens and weeks of headaches.

We’re trying to build a software factory with hands tied behind our back

>There are a lot of not so great software engineers doing mediocre work.

Yeah, and they are all producing 10x as much mediocre work now.

> The relevant question is who is going to pay you to write code manually.

Hopefully companies in the industries where software quality matters and is regulated, e.g.: medicine, aviation, nuclear, etc.

Although this market is relatively small.

> I need to write code because otherwise LLMs will write too much code, ...

I second that and I can give an example that happened to me yesterday with a totally SOTA model (a US, not Chinese model).

I needed to display an information on the client-side. Something trivial. I ask the LLM to do it. The thing went onto a rampage: it somehow found a way to pass the information from the server to the client during the initial handshake (already: why, just why?). Modifying both server-side code and client-side code. And it worked.

To an unsuspecting programmer/tester (or automated test)/user: the info is there, what was asked has been done. So it's perfect, flawless LLM victory right?

Except none of that sloppy-pasta was necessary: the info was already available on the client-side and was a one-line change, purely client-side.

These thing shall definitely, as of 2026, write way too much code.

And btw the companies selling metered tokens have a very serious incentive to produce the most complicated, rube-goldberg, solutions that use as many tokens as possible, while still kinda solving the problem.

That way not only you consume tokens to produce the code, but later on you consume tokens when working on that code (which btw is a guaranteed thing: for the LLM just introduced new bugs in that gargantic amount of crap it output).

Funnily enough the very same people who made fun of copy-pasta happen to be in love with sloppy-pasta. Go figure.

LLMs love to defensively wrap code instead of thinking holistically about the big picture. That creates a lot of bloat.

A human coder might OTOH follow the Boy Scout rule and clean up as they go.

> it’s only when you fully understand the problem you can generalize

Peter Naur explained this decades ago

>Peter Naur argues that programming is fundamentally a human activity of building a mental "theory" - a deep conceptual insight into how a system's parts match the real-world problem it solves. He rejects the prevailing view that programming is merely the mechanical production of source code, specifications, and documentation. Instead, Naur posits that the true product of programming is the shared mental model held in the minds of the developers who built it.

As a human you're the one with the problem you want code to solve, so it's worth having an understanding the problem. Otherwise you risk an X/Y situation, where the LLM ends up solving a problem that may not actually satisfy what you need.

I think what LLMs allow you to do is better abstract away everything that's _not_ essential to the problem you care about, in the same way that libraries or any higher-level programming language does. Ultimately there's still a "core" of the problem that needs to be expressed formally though. When you see people "vibe coding" by prompting the LLM to add constraints at a time until they reach their desired end-goal, this is ultimately "programming" in a sloppy, non-formal way. Better to get the LLM to write everything else _surrounding_ the problem, so you can write and understand the core yourself.

That’s why even though 99% of my work is C#, llms have made it so I can finally call myself a low-level programmer, which I’ve always aspired to. I didn’t even have to do anything.

So much this, the other day I wanted to set up a project running in K8s similar to our other modules at work, and it he thing ended up writing unit tests for a hello world implementation.

If tokens are the problem, SDD is the solution

That quote is the lead in to an example I talk about after this quote illustrates what I often see.

> Agents bias to making the current change as safely as possible. I had a situation in a previous codebase where one morning, pre-caffeinated, my meat brain mentioned using browser local storage. So some random state was managed in local storage. Everything else through a backend database. When I looked at the code, the amount of wrapping and indirection to preserve this idiotic human mistake probably tripled the LoC. Agents can amplify our one-off bad decisions by being so conservative.

You can of course solve this many ways. And many of boils down to just how a particular humans brain works. Some will solve this by not reading code. Some will read / write code.

Whatever works for you is great. But many there is upside to the precision of not having code intermediated through the LLM for many.

The thing is with a wish machine, you can one shot something very easily.

But then you realize software is the accumulation of 1000s of wishes. And you want this but not that. Many little micro decisions of exactly what you want in every nook and cranny.

In the current paradigm (LLMs) we still have to manage all this. But maybe in the future we have something impossible to imagine.

You’re assuming that progress will continue at the same rate (it’s plateaud a bit as far as I can tell, I can look for sources tomorrow but am on phone now :))

& I think it’s fairly demonstrated that the industry isn’t profitable for training ever increasingly huge models, which get exponentially more expensive each iteration

Already loathing the idea of not even being able to directly blame humans and their incapability for making shitty websites, that require JS for everything, including typing a text in an input field. If we get there and the LLMs build the same crap, dialed up to 110, because even more suits want first and foremost fancy looks, rather than function, and because that's the majority of training data corpus they learned from ... I might have an existential crisis coming in. The web already sucks hard enough. At least let me blame incapable human beings for this situation.

There is magic in telling computer do something and seeing it zap through it billions of times faster than by any other means.

Exactly this. I got into this field because designing programs and writing code is enjoyable. I'm probably behind on using AI and need to get more up to speed, but I never want to stop coding by hand.

If you're also happy getting paid for it, then the company will just stop paying you. If you rely on such income to have a visa, you'll 100% sure to accept that you're forced into this and you will give up coding, or else.

100% agree. I don't understand why there is pushback against this.

> and no different than copy and paste from stack overflow

This isn't really the point of your comment, and for that I apologise, but: not all of us did that. For many good reasons, too.

>architecture design and LLM just exposes how bad people are at designing dynamic architectures

Speak for yourself. A lot of people have great abilities at designing "dynamic architectures" and anything else an LLM is used for. It sounds like you don't realize that an LLM is only capable of what it does because it was trained on human-written code.

> ... and no different than copy and paste from stack overflow.

It's even got a name: sloppy-pasta.

I'm not sure this is a good combination?

I mean you're basically saying it is a good thing if the LLM messes up so you have a reason to debug the code.

99% of code ever written has always been shit. Most of it has been thrown out or not in use anymore, or EVER used. Most people arent going anything particularly unique or complicated or performance focused.

My code is/was worse than AI's, but at least I get paid, so what do I care about the bad news you have.

This isn't the first or even the tenth attempt at making computer programming accessible to everyone. Remember COBOL? COBOL made the computer speak English. It didn't help.

A specification detailed enough to control every aspect of the resulting product is called a program. Compilers are AI. The prevalence of compilers hasn't harmed the programming industry at all, quite the opposite.

Update: since I have posted this my computer has made several completely insane errors. I guess we're not quite there yet haha.

Do you like to look at code? I’m finding it’s really just a personal preference. And honestly not worth getting worked up about either way.

I was fairly confused myself as the author :)

This was actually my original submission last week. There was a front page submission last night from someone else (hence the comments). Then my old post got re-upped just now (1 hr ago)

I think what we’re learning is that up front slower experience can be valuable for maintaining the maintainers own understanding of the project

I’ll be very curious how / if the Bun port to Rust works out.

+1, I don’t understand who these greenfielders are. Either I wait on the CI to finish, or I’m in a meeting.

I’m old enough to remember coders being made fun of for doing copy-pasting from stackoverflow all day.

And that sort of yak shaving is something LLMs are great at.

The boilerplate was always boilerplate though. You never needed to write it to already have that code in your project, so I'm confused by what you mean.

Generating boilerplate is strictly inferior than something already written and tested by the authors of the tools. You will eventually have to make slight adjustments to it, and those decisions can be just as impactful as your "high judgment" code. Those decisions are what actually enable your high judgment code to stay clean and straightforward.

Poor decisions in code architecture are some of the biggest blunders of all. Once you have begun to fill in the blanks on some boilerplate code, it ceases to remain boilerplate code. If you let AI make those adjustments, you will eventually blunder the codebase in precisely this way. You'll first recognize it when your high judgment code seems too verbose. You'll then soon realize some things are impossible without adjusting the boilerplate you started off with. Then the AI will fail to grasp what you want and you'll have to manually untangle a lot of the slop that you let grow out of control. Good luck with that.

this is the way

Ai will fall apart as an industry but it's likely that models on par with e.g. opus 4.8 will be runnable on a home server within the next year and a half and that model hosts will still exist. I figure these tools aren't likely to go away.

Before my time ppl mostly did things in asm, I bet the vast majority of people reading this have never touched assembly and will never have any reason to. This is quickly becoming true of most "code". AI has changed that.

One way to "stay relevant" would be to admit that.

In fact, it's better not to generate it imo. Like you said the quality is higher, and by the time I get done reviewing the LLM's output I haven't really saved time over just doing it myself. LLMs are only useful for things you can verify extremely quickly (like a short script), or for things where you don't care about the quality.

In fact, not many people know that these days, but a human doing a thing by bashing their head against it, often tends to improve. My hand-written code is my best yet. My breadth of knowledge, wider than ever.

But the attraction of LLM code is not that you get quality.

The selling point is that you know have a quality Vs time tradeoff that is a lot better than you used to have.

I can spend 10 seconds typing out a prompt that will generate ok code.

Before a couple of years ago, it might have taken me an hour to type out and debug that code.

https://news.ycombinator.com/item?id=48883660

> AI is a tool. Learn how to use it!

If you think that everyone agrees on the "correct" way to use it, you're mistaken. If you think that your way is the best possible way to use it, you're arrogant. And if you think that the way you think is correct is obvious and that everyone should already know that's the right way, you're delusional.

I don't write code anymore, because AI writes better code than me. I could write code, but the next AI would find 10 ways to make it better and more consistent with the rest of the AI-generated codebase. So I just let it write all of it. However, I inspect it all carefully and I constantly asks it to reflect on the code quality, to refactor, to reorganize, to make the code as good as possible. The end result is code that is much better than anything I could have written myself.

And I should mention that I have 30+ years of programming experience.

"The deeper the prompt, the better the code actually gets."

.... and in the and you end up with a very deep prompt that exactly specifies the behavior. This is what a programming language is.

I'd rather describe a data structure in a language designed for this task, than a prompt the might be interpreted in many different ways.

In my experience AI often overlooks generalizations of ideas iteratively arrived at. I need to give it the idea, that something could be generalized and nudge it, to arrive at the solution.

I imagine at competitive coding the goal is quite clear, but in a real world project, the goal is not always so clear, and especially in hobby projects the ideas and goals are not that clear. I get inspiration on how to improve my project or its usability, not the LLM. I instruct it to do something a specific way, because it doesn't do anything on its own, and I need to tell it what to generalize, which it failed to see, because it didn't consider a simplification which is technically less precise, but due to user context and human nature doesn't matter (in this case it was interpreting "now" to mean the current second, which is a small time range, instead of a mere point in time).

So it still takes a ton of hand holding in a more open project. I imagine, one could also code it up in the same amount of time. But it is good for generating tons of test cases. Though one will have to review those, and impose a test style on them, give examples and so on.

I've got a coin that answers questions. You have to give it a heads or tails query, then flip the coin, and it returns an answer. It's incredible. Now, it doesn't get the right answer every single time, but we're all learning how to use the new coin technology, and this is only the first generation of coin. The next model of coin is going to be even better. Soon we're not going to need humans any more, for any question we have, we'll be able to use the coin.

So, the developers have finally found their Silver Bullet?

I've seen so many of these already. It would be hilarious to see Brooks proving right once again.

[flagged]