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.
WebAssembly is slightly easier than real assembly, but here Fable used WASM GC extensions, which are poorly documented and not yet super common.
Fable didn't even need to debug it; I believe essentially all the assembly worked correctly on the first try.
I have feelings about this, but I'm not pretending it isn't real.
I suspect that despite its translation abilities, this is true, but I'd like to see it do things in languages that are more or less appropriate for tasks to see how much the training corpus matters vs. its ability to translate. Assembly is a bit of an extreme example because you're either writing it as close to C as possible (C is essentially portable assembly) or you're writing complex, unreviewable code that happens to work. And who know if it's been trained on register allocation, or resorts to doing everything on the stack because it works.
Without a revolutionary new platform to build apps on that no one has ever developed for before, there is basically no reason to believe there is any software left that has some business or economic value that hasn't already been written.
We’ve created software for virtually every place we can put software. There’s nothing new.
It’s like bridges. We’ve seen all the ways bridges can be built by now. There’s nothing new left to discover.
It’s also a bit ironic to imagine that we’re at the end of new software ideas on a site owned(?) by YC.
I'm disputing this. You can have a training corpus in assembly as big as any other language: just feed the compiled result(in assembly) of the CRUD apps to the LLMs.
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.
How can you be sure that's what the code the LLM wrote actually does?
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.
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.
Yet...
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.
Code. It’s called code.”
- CommitStrip (https://www.reddit.com/r/ProgrammerHumor/comments/1p70bk8/sp...)
I think if you’re doing it right, the core of your code should be the simplest expression of the underlying business logic. Of course there’s always going to be supporting layers, and maybe those don’t need to be reviewed. But if you haven’t read the code, there’s an extent to which you don’t know the business logic.
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...
Yes, it's in the rules; run profiles, check code coverage, do a critical review, post the report and follow up tasks. 90% of people I've worked with did not follow these boy scout rules nearly as well as today's frontier LLMs.
Is the author implying this is bad?
> 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.
I'm sure plenty of meat humans out there would make the same mistake (sorry, you said to use local storage boss!). You might give them a scolding. And maybe document that policy. Maybe in a markdown file for the next person. IME the latest models are significantly better than the median engineer at following this feedback.
I don't think it's fruitful to blame the LLM any more than it is to blame someone working under you.
In fact I would say this is an excellent example of how engineering does NOT fundamentally change in the era of AI.
In this case things mostly sorta worked and the simplest way to see the problem was look at the code. And try to take it apart a bit to see where the problem was.
I felt I arrived at a better pattern I could trust that the agent could use much more efficiently this way than asking the agent to do it. I could then test that the pattern was being adhered to and therefore better trust the agent not to go off the rails.
I personally internalized the details a lot better by doing this writing. I wouldn’t have internalized it - or more likely played whack-a-mole - by guiding an agent.
How do I arrive at the patterns to check for without exploring the code? And capturing a real failure case?
You don't!
Have you tried adding rules/automations that make it explicit to review and fix the code for bloat (per your taste, with examples if needed)?
With this setup + a good frontier model you will never have to be on the lookout for code bloat. You can even get the agent to send you text message with the LOC-- if it makes you feel better.
I think I understand where you're coming from, that it's hard to "let go" (I've been coding for 30 years and it was hard for me). That's why I'm recommending to have agents write verifiable quantified reports of the things you care about, so you can build up some trust in the agent's work and you don't have to do things by faith.
How do you establish sane patterns when you’re in an exploratory /architectural mode? You could do this in English, sure, but many of us do this more efficiently and precisely in code in a way that lets us be careful, internalize details, and add measurement + QA to ensure it’s adhered to by agents or humans.
I’m not saying to write all the code. I’m saying it’s useful to write 5% of it. Then let an Agent stamp out / rewrite the rest
100% agreed. And it leads to far better LLM output and lower token usage, too, I find.
I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subconsciousness makes most of the decision ("this just feels right"). But for this to work you have to train it. And this does only work in a very limited way with code reviews or reading documentation. It requires repetition and deep focus.
When there is an issue in production with this mental model you will be able to point to the cause of an error message instantly. With generated code you'll search for a long time with your slow, conscious part of the brain.
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. Otherwise this will always be problematic.
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.
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.)
But currently e.g. I am working on an MES/Scada layer that integrates data from a load of different machines in a factory. These machines are from China, Korea, Germany, Sweden ... Upwards there is an ERP integration (and some other systems).
Sometimes machines are updated and suddenly behave differently. Giving error messages in Chinese.
The ERP has the nasty behavior of returning error messages where it is not clear whether the actual processing actually happened or not. There are some heuristics on parsing the error messages, but these also change with new versions.
Sometimes one machine overloads cloud infrastructure and completely unrelated functionality fails.
Sometimes the on-premise network stops working for whatever reason and data is lost.
Sometimes operators do not understand a perfectly valid error message like: "The batch you loaded into input position XY has expired on XZ and cannot be used for production": "But we have been told to use it..."
So when you get called out at night, because the production line stopped and "MES is displaying an error message", it is mostly about finding out what integration failed and who else to wake up. Getting this right is very much appreciated by your colleagues.
And this is where you need a mental model of how things are connected, what error message happens because of what external causes etc.
Observability can only work perfectly for known problems. In a complex system for unexpected problem you can either provide too much data, so analyzing it and finding the relevant part becomes really hard, or too little data which makes finding the issue impossible.
There are so many companies claiming to provide the perfect observability solution and there are certainly solutions that help. But it is all very far from perfect.
Not relying on people is managers wet dream. And for a lot of people it might be true that they can be easily replaced. But for complex systems there are always some key people that you cannot replace without causing issues.
By having an understanding built during their entire career.
Right now we live in a fairly-land of mixed capacity. LLMs being used in parallel with skilled people. But as time progresses, there will be no more skilled people, because no one will learn and develop those skills.
If you're in the world of LLMs now, you are basically completely stalled in your personal growth in this field. You will never improve, and some seem to say they lose capabilities as they rely upon LLMs.
The world always changes. But the decisions being made today, are being made by skilled people.
What will the world look like, when it's just all "bro, lol, just tell it to make your thing" and then done?
Same.
My difficulty is that for the past 8 years I've been working for (tiiiiny) SaaS business where I don't have anyone I can simply ask in-person "hey, can you show me how to 'do' all this newfangled AI agentic team coding?"; so my only direct-exposure is with the painful Copilot sidebar chat, which I now find myself allergic to.
So let's see elsewhere: while searching online for some (reputable) "agentic coding courses" my results are for the same kind of people who used to run those dodgy coding-camps from 10 years ago. I'm having difficulty finding resources for practicing SWEs like myself wanting a continuing-professional-development course experience, not a get-rich-by-buying-my-course video library from a contemptable AI booster
Even more surprisingly, my local major university (UW.edu) doesn't seem to offer any certificate courses for getting into agentic development either[1] despite offering courses on C++, Six Sigma, and actual ML/AI courses. It's maddening. I can't be the only one with this problem...
[1] https://www.pce.uw.edu/search?type=certificate&programType=c...
See how it fails or succeeds. Look at the supported features, try them out, think about how you might use them in your workflow.
Before you know it, you'll be proficient.
You have to learn how to self-teach.
My brain feels equally as exercised (in fact more so as I am not as good at agentic coding as I was at real coding)
But now I'm making highly polished Mac OS apps and I really like that move from JS.
I feel... conflicted.
fwiw I think the rationale behind it is counterproductive because the only difference between a OP submitting their article link and someone else submitting their article link is internet points.
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)
The job of the software engineer increasingly becomes to make himself unnecessary: to empower the nontechnical business users to do as much as reasonably possible, without his/her intervention.
This has, of course, been the dream of computing, since its inception! And the true aim of every "high level" or "beginner friendly" (looking at you javascript!) language.
But finally, now that the computer actually speaks English (and is beginning to stop making completely insane errors), it gradually becomes feasible.
Freeing the masses from the tyranny of the nerds!
A human coder might OTOH follow the Boy Scout rule and clean up as they go.
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.