> The role of the human engineer […] has been to reduce risk in the face of ambiguity, constraints, and change. That responsibility not only endures in a world of Write-Only Code, if anything it expands.
> The next generation of software engineering excellence will be defined not by how well we review the code we ship, but by how well we design systems that remain correct, resilient, and accountable even when no human ever reads the code that runs in production.
As a mechanical engineer, I have learned how to design systems that meet your needs. Many tools are used in this process that you cannot audit by yourself. The industry has evolved to the point that there are many checks at every level, backed by standards, governing bodies, third parties, and so on. Trust is a major ingredient, but it is institutionalized. Our entire profession relies on the laws of physics and mathematics. In other words, we have a deterministic system where every step is understood and cast into trust in one way or another. The journey began with the Industrial Revolution and is never-ending; we are always learning and improving.
Given what I have learned and read about LLM-based technology, I don't think it's fit for the purpose you describe as a future goal. Technology breakthroughs will be evaluated retrospectively, and we are in the very early stages right now. Let's evaluate again in 20 years, but I doubt that "write-only code" without human understanding is the way forward for our civilization.
> Write-Only Code is not a prediction about what we should want. It is a description of what happens when software production scales beyond human attention.
Have we considered whether it's even a good idea to produce software at scales beyond human attention? I'm beginning to suspect that, in terms of the net amount of economic effort and sheer quantity of software produced, we are already creating simply too much software relative to the amount of economic effort we put into hardware, construction, and human capital. Most human needs and desires can only be met through manipulation of atoms, and it seems as though we've largely refocused on those which can be met through manipulation of numbers and symbols - not because anyone really wants their life to revolve around them to the exclusion of everything else - but because they're the easiest markets to profitably scale for the least amount of capital input.
We already have effectively write-only code. It's all the assembly language and eventually machine code that we produce from other languages.
The problem with "write-only code" as it relates to LLMs is that we don't have a formal definition of the input the the LLM, nor do people typically save the requirements, both implicit and explicit, that were given the LLM to generate the code. English language will never be a formal definition, of course, but that obviously doesn't prevent the creation of a formal definition from English nor reduce the value of the informal description.
This is very similar to the problem of documentation in software development. It is difficult to enumerate all the requirements, remember all the edge cases, recall why a certain thing was done in a certain way. So computer programs are almost never well documented.
If you knew that you currently have a bunch of junior developers, and next year you will replace all of them with senior developers who could rewrite everything the junior developers did, but taking only a day, how would that affect your strategy documenting the development work and customer/technical requirements? Because that's what you have with current LLMs and coding agents. They are currently the worst that they'll ever be.
So there are two compelling strategies:
1) business as usual, i.e. not documenting things rigorously, and planning to hack in whatever new features or bugfixes you need until that becomes unsustainable and you reboot the project.
2) trying to use the LLM to produce as much and as thorough documentation and tests as possible, such that you have a basis to rewrite the project from scratch. This won't be a cheap operation at first, (you will usually do strategy #1), but eventually the LLMs and the tooling around managing them will improve such that a large rewrite or rearchitecture costs <$10k and a weekend of passive time.
I am old. This immediately triggered "Perl!?" in me...
Joke aside: Programming languages and compilers are still being optimized until the assembly and execution match certain expectations. So prompts and whatever inputs to AI also will be optimized until some expectations are met. This includes looking at their output, obviously. So I think this is an overblown extrapolation like many we see these days.
Ha! I had someone doing a task the other day and the llm they used wrote a regex in Perl. I joked that in 25 years all the seems to have changed is the number of layers between me and Perl.
I helped updating ancient fortran to slightly less ancient C once. The company that depended on the ancient fortran no longer had any fortran programmers.
The resulting software upgrade was a nightmare that nearly killed that company. I shudder if someone needs to fix 20 year old AI write only code and I feel for the poor AI that has to do it. Because an AI 'intelligent' enough to do that deserves holidays and labor rights.
I’ve started doing a quick background check on authors before I dive into their content. This piece starts with the assumption that the writer is closely involved in engineering, but a little research reveals they don't actually work in active software development.
I’ll pass on this.
p.s. I’m happy to read authors with opposing views. Issue is with people who make claims, without having recent direct experience.
I remember when everything was "machine learning" as opposed to the current LLM stuff. Some of the machine learning techniques involve training and using models that are more or less opaque, and nobody looked at what was inside those models because you can't understand them anyway.
Once LLM generated code becomes large enough that it's infeasible to review, it will feel just like those machine learning models. But this time around, instead of trying to convince other people who were downstream of the machine learning output, we are trying to convince ourselves that "yes we don't fully understand it, but don't worry it's statistically correct most of the time".
He is trying to use a different phrase “write-only code” to define exactly the same thing Karpathy defined last year as “vibe coding”.
For what it is worth, in my experience one of the most important skills one should strive to get much better at to be good at using coding agents is reading and understanding code.
I think there's some value in pure vibe coding. To your point though, the best way to extract that value is to know intimately at which point the agents tend to break down in quality, which you can only do if you read a lot of their output. But once you reach that level, you can gain a lot by "one-shotting" tasks that you know are within their capacity, and isolating the result from the rest of your project.
I thought "vibe coding" had come to mean "I used an LLM to generate this code", but didn't really imply we'd given up trying to review and read the output. The author is taking it one-step further by suggesting we not bother with the latter.
It's true that the meaning of "vibe coding" has been somewhat diluted - but the original definition as set forth by Karpathy was to forget that the code even exists (no review, no reading the commits, nothing).
Sure, but the article is talking about people who can and do read code now but will develop software without reading code in the future. Kind of like you rarely look at the object code that the compiler produces.
> In the Write-Only Code story, that same engineer becomes a systems designer, a constraint writer, and a trade-off manager.
This is also what I see my job to be shifting towards, increasingly fast in recent weeks. I wonder how long we will stay in this paradigm, I dont know.
the real issue isn't whether AI writes the code -- it's whether you treat the output as a first draft or a final product.
i run multi-pass generation for everything now. first pass gets the structure, second pass refines, third pass i actually read and edit. it's basically a diffusion process for code. one-shotting complex logic with an LLM almost always produces something subtly wrong.
also learned the hard way that using the best frontier model matters way more than clever prompting. paying 10x more for opus over a cheaper model saves me hours of debugging garbage output. the "write-only" framing misses this -- it's not that you never read the code, it's that the reading/editing ratio has flipped.
This article assumes that AI bubble will never break, and the prices will never go up. While the major LLM providers are located in USA and China, but mostly USA I can imagine the service becoming a hostage for some political interests, and being blocked for a country or more... This also can become a weapon as creation of invisibly malicious code might be advised by LLMs or even executed by LLMs running loose... So I'd say, copying some other author which I read here, that LLM is an exoskeleton and we're not going anywhere, just being strengthened by it and sped up, and constantly held accountable for the code we together with LLM generate
in ~2005 i lead a team to build horse-betting terminals for Singapore, and there server could only understand CORBA. So.. i modelled the needed protocol in python, which generated a set of specific python files - one per domain - which then generated the needed C folders-of-files. Like 500 lines of models -> 5000 lines 2nd level -> 50000 lines C at bottom. Never read that (once the pattern was established and working).
But - but - it was 1000% controllable and repeatable. Unlike current fancy "generators"..
If $x_{T+1}=$|mathbb(E){stitch^\top
gauge^(-1)stitch]$.
Lemma - The system still runs,because $pattern$ is stable ($||pattern<1$) the system remains bounded (The app doesn't crash yet) Multi-modal $NEWT decouple real time rendering (60 fps) from AI computation(<100ms) and network calls (Async latency to 5ms stitch count makes sense). The dominant eigenvector in the latent coupling.
> LLMs are clearly a massive productivity boost for software developers, and the value of humans manually translating intent into lines of code is rapidly depreciating.
This take is so divorced from reality it's hard to take any of this seriously. The evidence continues to show that LLMs for coding only make you feel more productive, while destroying productivity and eroding your ability to learn.
Re productivity: the METR study is seriously flawed overall, and:
1. if you disaggregate the highly aggregated data, it shows that the slowdown was highly dependent on task type, and tasks that required using documentation or novel tasks were possibly sped up, whereas ones the developers were very experienced with were slowed down, which actually matched the developers' own reports
2. developers were asked to estimate time beforehand per-task, but estimate whether they were sped up or slowed down only once, afterwards, so you're not really measuring the same thing
3. There were no rules about which AI to use, how to use it, or how much to use it, so it's hard to draw a clear conclusion
4. Most participants didn't have much experience with the AI tools they used (just prompting chatbots), and the one that did had a big productivity boost
5. It isn't an RCT.
See [1] for all.
The Anthropic study was using a task far too short to really measure productivity (30 mins), and furthermore the AI users were using chatbots, and spent the vast majority of their time manually retyping AI outputs, and if you ignore that time, AI users were 25% faster[2], so the study was not a good study to judge productivity, and the way people quote it is deeply misleading.
Re learning: the Anthropic study shows that how you use AI massively changes whether you learn and how well you learn; some of the best scoring subjects in that study were ones who had the AI do the work for them, but then explain it afterward[3].
That’s the conclusion you get when you sit in the board of 20 companies where all the CEOs are telling you the same thing but you don’t understand that you are all just selling the same golden shovel to each other. Obviously this can also be backed by their own experiences too: 100% of code is written by AI, because last time they actually wrote code was in 2010.
Stupid VC bullshit from someone who will not be woken up in the middle of the night by vibe coded garbage that is incredibly insecure and falls over if you look at it the wrong way.
There will be more of it where it does not matter.
Maybe eventually with times.
At the moment, in my experience, most systems rely on hyperlinear semantics. Especially scalable ones.
Current llms cannot physically handle this at the moment. Maybe with biological or quantum (sic) computing.
But even then it is quite impressive.
Concretely in my use case, off of a manual base of code, having claude has the planner and code writer and GPT as the reviewer works very well.
GPT is somehow better at minutiae and thinking in depth. But claude is a bit smarter and somehow has better coding style.
> The role of the human engineer […] has been to reduce risk in the face of ambiguity, constraints, and change. That responsibility not only endures in a world of Write-Only Code, if anything it expands.
> The next generation of software engineering excellence will be defined not by how well we review the code we ship, but by how well we design systems that remain correct, resilient, and accountable even when no human ever reads the code that runs in production.
As a mechanical engineer, I have learned how to design systems that meet your needs. Many tools are used in this process that you cannot audit by yourself. The industry has evolved to the point that there are many checks at every level, backed by standards, governing bodies, third parties, and so on. Trust is a major ingredient, but it is institutionalized. Our entire profession relies on the laws of physics and mathematics. In other words, we have a deterministic system where every step is understood and cast into trust in one way or another. The journey began with the Industrial Revolution and is never-ending; we are always learning and improving.
Given what I have learned and read about LLM-based technology, I don't think it's fit for the purpose you describe as a future goal. Technology breakthroughs will be evaluated retrospectively, and we are in the very early stages right now. Let's evaluate again in 20 years, but I doubt that "write-only code" without human understanding is the way forward for our civilization.
Would I use a write-only HTML sanitizer for untrusted HTML: No!
Would I care to review CSS, if my site "looks" good? No!
The challenge becomes: how can we enforce invariants/abstractions etc without inspecting the code.
Type systems, model checking, static analysis. Could become new power tools.
But sound design probably still goes far.
> Write-Only Code is not a prediction about what we should want. It is a description of what happens when software production scales beyond human attention.
Have we considered whether it's even a good idea to produce software at scales beyond human attention? I'm beginning to suspect that, in terms of the net amount of economic effort and sheer quantity of software produced, we are already creating simply too much software relative to the amount of economic effort we put into hardware, construction, and human capital. Most human needs and desires can only be met through manipulation of atoms, and it seems as though we've largely refocused on those which can be met through manipulation of numbers and symbols - not because anyone really wants their life to revolve around them to the exclusion of everything else - but because they're the easiest markets to profitably scale for the least amount of capital input.
We already have effectively write-only code. It's all the assembly language and eventually machine code that we produce from other languages.
The problem with "write-only code" as it relates to LLMs is that we don't have a formal definition of the input the the LLM, nor do people typically save the requirements, both implicit and explicit, that were given the LLM to generate the code. English language will never be a formal definition, of course, but that obviously doesn't prevent the creation of a formal definition from English nor reduce the value of the informal description.
This is very similar to the problem of documentation in software development. It is difficult to enumerate all the requirements, remember all the edge cases, recall why a certain thing was done in a certain way. So computer programs are almost never well documented.
If you knew that you currently have a bunch of junior developers, and next year you will replace all of them with senior developers who could rewrite everything the junior developers did, but taking only a day, how would that affect your strategy documenting the development work and customer/technical requirements? Because that's what you have with current LLMs and coding agents. They are currently the worst that they'll ever be.
So there are two compelling strategies:
1) business as usual, i.e. not documenting things rigorously, and planning to hack in whatever new features or bugfixes you need until that becomes unsustainable and you reboot the project.
2) trying to use the LLM to produce as much and as thorough documentation and tests as possible, such that you have a basis to rewrite the project from scratch. This won't be a cheap operation at first, (you will usually do strategy #1), but eventually the LLMs and the tooling around managing them will improve such that a large rewrite or rearchitecture costs <$10k and a weekend of passive time.
I am old. This immediately triggered "Perl!?" in me...
Joke aside: Programming languages and compilers are still being optimized until the assembly and execution match certain expectations. So prompts and whatever inputs to AI also will be optimized until some expectations are met. This includes looking at their output, obviously. So I think this is an overblown extrapolation like many we see these days.
Ha! I had someone doing a task the other day and the llm they used wrote a regex in Perl. I joked that in 25 years all the seems to have changed is the number of layers between me and Perl.
> I am old. This immediately triggered "Perl!?" in me...
Same same.
I thought it would be about APL
me too
I helped updating ancient fortran to slightly less ancient C once. The company that depended on the ancient fortran no longer had any fortran programmers.
The resulting software upgrade was a nightmare that nearly killed that company. I shudder if someone needs to fix 20 year old AI write only code and I feel for the poor AI that has to do it. Because an AI 'intelligent' enough to do that deserves holidays and labor rights.
Do you mind sharing how exactly it turned out to be a disaster? What went wrong?
I’ve started doing a quick background check on authors before I dive into their content. This piece starts with the assumption that the writer is closely involved in engineering, but a little research reveals they don't actually work in active software development.
I’ll pass on this.
p.s. I’m happy to read authors with opposing views. Issue is with people who make claims, without having recent direct experience.
But you can be a software dev even if you do not work in software dev. Plenty of those individuals in open source, for example.
I remember when everything was "machine learning" as opposed to the current LLM stuff. Some of the machine learning techniques involve training and using models that are more or less opaque, and nobody looked at what was inside those models because you can't understand them anyway.
Once LLM generated code becomes large enough that it's infeasible to review, it will feel just like those machine learning models. But this time around, instead of trying to convince other people who were downstream of the machine learning output, we are trying to convince ourselves that "yes we don't fully understand it, but don't worry it's statistically correct most of the time".
He is trying to use a different phrase “write-only code” to define exactly the same thing Karpathy defined last year as “vibe coding”.
For what it is worth, in my experience one of the most important skills one should strive to get much better at to be good at using coding agents is reading and understanding code.
> good at using coding agents is reading and understanding code.
You can understand the code using an agent; it's much faster than reading the code.
I think the argument the author is making is that: given this magic oracle that make code, how we so contain and control it.
This is about abstractions and invariants and those will remain important.
I think there's some value in pure vibe coding. To your point though, the best way to extract that value is to know intimately at which point the agents tend to break down in quality, which you can only do if you read a lot of their output. But once you reach that level, you can gain a lot by "one-shotting" tasks that you know are within their capacity, and isolating the result from the rest of your project.
I thought "vibe coding" had come to mean "I used an LLM to generate this code", but didn't really imply we'd given up trying to review and read the output. The author is taking it one-step further by suggesting we not bother with the latter.
It's true that the meaning of "vibe coding" has been somewhat diluted - but the original definition as set forth by Karpathy was to forget that the code even exists (no review, no reading the commits, nothing).
https://xcancel.com/karpathy/status/1886192184808149383?lang...
A lot of people doing vibe coding can barely (or not at all) understand how to read code.
Sure, but the article is talking about people who can and do read code now but will develop software without reading code in the future. Kind of like you rarely look at the object code that the compiler produces.
I, too, appreciate the clarification in the term "write-only code".
> In the Write-Only Code story, that same engineer becomes a systems designer, a constraint writer, and a trade-off manager.
This is also what I see my job to be shifting towards, increasingly fast in recent weeks. I wonder how long we will stay in this paradigm, I dont know.
the real issue isn't whether AI writes the code -- it's whether you treat the output as a first draft or a final product.
i run multi-pass generation for everything now. first pass gets the structure, second pass refines, third pass i actually read and edit. it's basically a diffusion process for code. one-shotting complex logic with an LLM almost always produces something subtly wrong.
also learned the hard way that using the best frontier model matters way more than clever prompting. paying 10x more for opus over a cheaper model saves me hours of debugging garbage output. the "write-only" framing misses this -- it's not that you never read the code, it's that the reading/editing ratio has flipped.
This article assumes that AI bubble will never break, and the prices will never go up. While the major LLM providers are located in USA and China, but mostly USA I can imagine the service becoming a hostage for some political interests, and being blocked for a country or more... This also can become a weapon as creation of invisibly malicious code might be advised by LLMs or even executed by LLMs running loose... So I'd say, copying some other author which I read here, that LLM is an exoskeleton and we're not going anywhere, just being strengthened by it and sped up, and constantly held accountable for the code we together with LLM generate
Write-only blog posts.
Only read by ai crawlers to be reused in training data.
write-once read-never?
something that was not perl ;)
in ~2005 i lead a team to build horse-betting terminals for Singapore, and there server could only understand CORBA. So.. i modelled the needed protocol in python, which generated a set of specific python files - one per domain - which then generated the needed C folders-of-files. Like 500 lines of models -> 5000 lines 2nd level -> 50000 lines C at bottom. Never read that (once the pattern was established and working).
But - but - it was 1000% controllable and repeatable. Unlike current fancy "generators"..
If $x_{T+1}=$|mathbb(E){stitch^\top gauge^(-1)stitch]$. Lemma - The system still runs,because $pattern$ is stable ($||pattern<1$) the system remains bounded (The app doesn't crash yet) Multi-modal $NEWT decouple real time rendering (60 fps) from AI computation(<100ms) and network calls (Async latency to 5ms stitch count makes sense). The dominant eigenvector in the latent coupling.
How many cs are in the word "abacus"?
> “AI writes the code” is already true inside many enterprise teams
I'm highly doubtful this is true. Adoption isn't even close to the level necessary for this to be the case.
In fact claims of widespread adoption started over the holidays when typically nothing happens.
> LLMs are clearly a massive productivity boost for software developers, and the value of humans manually translating intent into lines of code is rapidly depreciating.
This take is so divorced from reality it's hard to take any of this seriously. The evidence continues to show that LLMs for coding only make you feel more productive, while destroying productivity and eroding your ability to learn.
Re productivity: the METR study is seriously flawed overall, and:
1. if you disaggregate the highly aggregated data, it shows that the slowdown was highly dependent on task type, and tasks that required using documentation or novel tasks were possibly sped up, whereas ones the developers were very experienced with were slowed down, which actually matched the developers' own reports
2. developers were asked to estimate time beforehand per-task, but estimate whether they were sped up or slowed down only once, afterwards, so you're not really measuring the same thing
3. There were no rules about which AI to use, how to use it, or how much to use it, so it's hard to draw a clear conclusion
4. Most participants didn't have much experience with the AI tools they used (just prompting chatbots), and the one that did had a big productivity boost
5. It isn't an RCT.
See [1] for all.
The Anthropic study was using a task far too short to really measure productivity (30 mins), and furthermore the AI users were using chatbots, and spent the vast majority of their time manually retyping AI outputs, and if you ignore that time, AI users were 25% faster[2], so the study was not a good study to judge productivity, and the way people quote it is deeply misleading.
Re learning: the Anthropic study shows that how you use AI massively changes whether you learn and how well you learn; some of the best scoring subjects in that study were ones who had the AI do the work for them, but then explain it afterward[3].
[1]: https://www.fightforthehuman.com/are-developers-slowed-down-... [2]: https://www.seangoedecke.com/how-does-ai-impact-skill-format... [3]: https://www.anthropic.com/research/AI-assistance-coding-skil...
Your comment is so divorced from reality...
That’s the conclusion you get when you sit in the board of 20 companies where all the CEOs are telling you the same thing but you don’t understand that you are all just selling the same golden shovel to each other. Obviously this can also be backed by their own experiences too: 100% of code is written by AI, because last time they actually wrote code was in 2010.
Stupid VC bullshit from someone who will not be woken up in the middle of the night by vibe coded garbage that is incredibly insecure and falls over if you look at it the wrong way.
There will be more of it where it does not matter. Maybe eventually with times. At the moment, in my experience, most systems rely on hyperlinear semantics. Especially scalable ones. Current llms cannot physically handle this at the moment. Maybe with biological or quantum (sic) computing.
But even then it is quite impressive.
Concretely in my use case, off of a manual base of code, having claude has the planner and code writer and GPT as the reviewer works very well. GPT is somehow better at minutiae and thinking in depth. But claude is a bit smarter and somehow has better coding style.
Before 4.5, GPT was just miles ahead.