> Some people say that the move from high level languages to AI-generated code is like the move from assembly to high level programming languages.
> I do not agree with this simile.
I spent a while believing that the transition to AI-based development was similar to the shift to lower → higher level programming languages. However, like the author I now believe that this is an apples to oranges comparison, albeit with a slightly different take.
Chiefly it's because working with an LLM is working with output that is stochastic by nature and involves a different kind of broader, systems kind of thinking. The LLM ultimately outputs a deterministic product: code. You can decide (as a junior or newcomer) if you want to understand the code, or not.
I don't think it will matter that much in the end -- in the general sense -- whether software developers take it upon themselves to understand code though. I think if you want to become a well-rounded craftsperson or a "true engineer", you are always doing yourself a service to understand inner workings and "how the sausage is made".
Plenty of roles today which are instrumental to software products do not rely on code understanding. Product managers, Product designers, Designers (in general).
Somebody who designs an object or appliance made by injection-moulding plastic doesn't need to understand how to create moulds or make a model using wood -- but it sure helps them, as a thinking person, understand their products and the world better.
On the other hand, another value of not getting to the point immediately is in order to build suspense. Like the author, it took me a while to realise how important suspense and build-up is in order to communicate memorably and persuasively.
I spent a large portion of my early twenties learning (through doing) about how important it is to "get to the point" by "keeping it simple", but it took me a great deal longer to understand how much more valuable it is to actually make a point by taking the listener on a bit of a mental journey first.
So fun to see my music (created when I was 15 years old) is still sitting there! Sadly though my flash animations (that were 'blammed'[0] almost immediately) aren't there, which I wish I could find somehow.
I really like the premise of this article because I am intensely interested in learning about software factories. As much as "software factory" is a buzzword, it's still SOTA and it's absolutely going to happen / keep happening in the tech industry over the next few years.
However, I can't read this, not because I refuse to -- I want to -- but because my the cogs in my mind just stop whirring at all of the LLM-isms, my eyes glaze over, and I stop being able to follow what the article is trying to communicate to me. I would love for the OP to call me out and correct me (that they haven't used LLMs to write this).
I was bothered by the writing and fought through it, and carefully went through everything in the article... and you didn't miss anything. It's a tweet expanded to article length.
The factory analogy is tenuous, because real software is always bespoke, it’s not about producing gazillion copies of the same thing. Factories are about reliability and tolerances, aspects which are inherently intractable with LLMs.
One tragedy of this is that I stop reading when things don't make sense. There are a few connections in the article that seem tenuous. In the past I might have thought through it, considered the situation, and realized that the author had a different perspective and, if I shifted my mindset, there was a real insight there.
Now I just assume that it's AI-slop and there's no other "way of thinking" that I can adopt to make it sensible. I'm surely missing out on learning through some human-written articles, but the volume of slop means that I can't spend all my time digging through nonsense in the hope that there's a gem of insight.
In your second paragraph, that was true before AI-slop, at least for me. There was enough human slop that I couldn't bother to spend my time digging through it in the hope of finding a gem.
AI makes it worse, of course, because the ratio of slop to non-slop is worse.
LLMs being used as a tool in general (and in the future) to automate creation and maintenance of software is not mutually exclusive to one person using LLMs to create an article.
writing prose and writing code are two different things
I can get good code out of LLMs. I can rarely get good writing out of them.
Maybe it's a skill issue, but it's not inherently a contradiction that they're better at some things than others. It's much easier to RL coding than writing.
I like to delete all AI comments, and write my own. If I can't write a comment, I don't understand the code well enough to have my name on the commit. I often delete the resulting comment, because AI likes to add many more than are necessary.
The most enlightening experience I had from programming was picking up Elixir for Advent of Code[0] 3 years ago. At that point in my career, I knew what I was doing and had built various apps and systems. TypeScript and React was my safe-space, but which I often committed the sin of over engineering things to be as functional as possible in.
I'd tried Go, which I didn't really like because it was too imperative for my taste and also required you to write every... single... thing you needed from scratch. (Not trying to start a flame war here -- it's just how I felt using it).
One of my engineers was kind of obsessed with Elixir (he was / is extremely smart) and he convinced me to give it a go over Christmas break. It really was the functional Valhalla he had made it out to be. I felt like I'd finally found a language that "got" how I wanted to approach writing code. Unfortunately, startup life got in the way, and I was hardly going to suggest an Elixir rewrite (well, I did try, but anyway).
I'm planning on re-approaching Elixir, as a haven to write code as a human. I still use LLMs for writing code pretty much daily, but if you're looking for something that's different and fun, I would recommend checking it out. It's just a shame to hear that the author is, for now at least, stopping their engagement with the community due to how they perceive it's changing!
It's probably the language that punches the furthest above it's weight in community size vs. what you can do with it (and what is being done with it professionally), and I don't think it's even close really. The quality and capability and breadth of libraries people publish is really incredible, from web all the way down to embedded.
> It's just a shame to hear that the author is, for now at least, stopping their engagement with the community due to how they perceive it's changing!
Want to clarify for others reading that the author of _Elixir_ isn't stopping, just the author of this post. José has been shockingly responsive on recent issue/pr threads I've posted on Elixir-related repos recently, often same day. They also don't seem to use any bot-based code review, which is incredibly refreshing in contrast to many other repos[1] in 2026 (Sorry for the callout, it's just such a good example). Elixir projects have been a joy as a fairly new contributor, compared to other ecosystems.
What did you need to write with golang? I found the exact opposite effect when I tested elixir and then went to go.
Exlixir has a great std lib but fewer packages than I'd like in the community. I can't even recall what I wanted!
With go the std lib seems bigger (although very lacking in some data structures) but the third party packages are incredible.
I also find both languages similarly useful since I was mostly interested in sane concurrent primitives in a lang. The OTP is not that useful to me since I haven't had to run these services in anything close to serious but you can (kinda) take the OTP to other languages (they're principles after all).
This is a great follow-up that I don't have a satisfactory answer for, because I can't really recall. I _think_ I was trying to do something with Firebase w/ high parallelism using goroutines. I just remember the feeling of imperativeness when I was iterating through results, etc, and not having a built-in mapping function.
Elixir was totally different -- was just scratching an "intellectual" itch, and it fit my needs like a glove in terms of feeling.
I'm confident that I could learn to like Go, though, lots of people I know rave about it.
> The OTP is not that useful to me
Also agree, didn't really get into OTP even, just enjoyed the style and structure of the language itself!
OP here - longtime HN user. I submitted this story to a writing contest a few months back, but didn’t hear anything from them.
I posted it here on a punt and getting front page of HN is 10x the feeling any writing contest could give me!
Thanks to all who read and commented, and glad to hear it resonates with some of you!
[EDIT]: There've been a lot more comments since I wrote this one. I want you all to know that I've read every single comment and am ever so grateful for everyone who responded here / took the time to read the story!
Also see a lot of comments echoing your point about missing the fact that it was fiction... Next post might have a stronger disclaimer! (But I fear it actually worked in my favour here)
It so was. It's amazing how easily we can all tell what's written by a real person these days. It's gotta be like the early days of CGI.... ten years from now it'll be so hard to tell :(
This reads so well I was supposed to go out for a workout but I couldn't stop until I finished it.
Incredibly engaging yet simple writing that flows well.
The ending is quite abrupt, I'd consider another short scene. Perhaps one at Aaron's funeral where there's a little more exposition about the shooter, such as with a conversation with Aaron's mom, or with the wider group of friends. For example, we don't know if the bet was paid out, or if the bettor had some relationship to the shooter.
The shooting itself could have a bit more conflict and tension. Imagine if, for example, there was some kind of animosity due to a fight between Aaron and the narrator. (Instead of them drifting apart.) Then imagine that the narrator saw the bet before the race, saw someone suspicious, put two and two together, and tried to warn Aaron?
If you're doing any kind of inference that is multi-modal and non-factual, opinions and biases will affect any kind of assessment of a visual that you provide to a model.
For example, a UI / UX professional being asked to appraise a website screenshot may determine that the image in question has "desirable" traits which are inherently not deterministically measurable. Such as, if the interface elements have strong information hierarchy, or if they are deemed to be "fashionable" with current UI trends.
Is 16 px or 14 px a better font-size value for a subheading, in a hypothetical layout? Immediately that kind of decision, where both options are objectively good for 12 px paragraph text, suddenly becomes an issue of taste that cannot be evaluated crudely by an algorithm.
I have to say: Yes, there is a lot of velocity from Cloudflare pushing out AI-adjacent features as of late.
But also: What they've doing with Workers et al. has made them a platform for fully-fledged apps and deployments. I personally love the ecosystem and use it for all of my projects now. It's like the perfect blend of ease-of-use and DX of Heroku, and breadth of services of AWS / GCP. Well, maybe not quite AWS or GCP, but that's kind of the point -- they've created an opinionated system of "objects" that are all highly extensible to the point where in my opinion you can pretty much deploy anything you want on it.
It took me a bit of time to learn the "Cloudflare way" of doing things, but once I started making on it I saw just how flexible (and low cost!) everything is.
> I do not agree with this simile.
I spent a while believing that the transition to AI-based development was similar to the shift to lower → higher level programming languages. However, like the author I now believe that this is an apples to oranges comparison, albeit with a slightly different take.
Chiefly it's because working with an LLM is working with output that is stochastic by nature and involves a different kind of broader, systems kind of thinking. The LLM ultimately outputs a deterministic product: code. You can decide (as a junior or newcomer) if you want to understand the code, or not.
I don't think it will matter that much in the end -- in the general sense -- whether software developers take it upon themselves to understand code though. I think if you want to become a well-rounded craftsperson or a "true engineer", you are always doing yourself a service to understand inner workings and "how the sausage is made".
Plenty of roles today which are instrumental to software products do not rely on code understanding. Product managers, Product designers, Designers (in general).
Somebody who designs an object or appliance made by injection-moulding plastic doesn't need to understand how to create moulds or make a model using wood -- but it sure helps them, as a thinking person, understand their products and the world better.