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.
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.
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.
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.
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 efficient, 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
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.
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.
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!
So I took over an open source project called Omnivore. It's a reading app in the vein of Pocket. The hosted version used pdf-lib to inject some functionality into the pdf viewer. Namely, highlighting, note taking, and storing location. pdf-lib is a licensed application, so when taking it to fully self-hosted this needed to change.
I migrated it over to pdf.js. And I went through the entire process. I added all the functionality bit by bit. It didn't take exceptionally long, maybe 1-3 days. But that process was really satisfying. I found a bug, fixed it, and then found a stackoverflow issue where someone was also experiencing the same issue and suggested the fix. https://stackoverflow.com/questions/59151218/pdfjs-error-on-...
I'm pretty sure an ai could have done all of this. And therein lies my fear and my upset with AI. Not only would it have robbed me of that experience, but it shows that I have in a way been devalued. Because I do think that took a level of skill. And now that's gone...
I’ll be very curious how / if the Bun port to Rust works out.
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)
And I'm not saying this as some sort of AI maximalist. If progress keeps up, I seriously doubt software engineering and development will, as we know it today, will be a thing in the next 5-10 years. Maybe humans will be left with designing the UI, but everything else will be abstracted away and AI will be doing all the actual work behind the scenes.
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.
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.
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.
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.
It's even got a name: sloppy-pasta.
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.
One way to "stay relevant" would be to admit that.
And that is a far stronger abstraction than LLMs :)
Can I use agents to code a SWE project? yes, with nuances.
Can I write code for a SWE project? yes, with nuances.
Its more options now, I'll write code about projects I deeply care and will use llm at work where its shared slop and forced usage.
Even without AI I barely write code. 95% of time are spend setting up integrations, configs, copying & adjusting code from previous projects.
Why are you building a software factory though, and why weren't you immediately adding CI to every project?
> It’s our job to build the software factory - not just the software. Software engineers maintain the assembly line allowing anyone to prompt for a change and ship immediately.
Again, why? Where are you working where this is considered a good idea? This would mean that the software engineers are not just being completely kicked out of all business decisions, but asked to build a moat that ensures they stay on the other side of it.
Any business that intentionally devalues the insights gained through implementation will eventually starve itself to death by making too many passive thoughtless moves. No insight will ever be gained just spot checking AI. Is their intention really just to make tiny amounts of profit while riding the thing into the ground? Crabs in a bucket, man.
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.
> Before a couple of years ago, it might have taken me an hour to type out and debug that code.
Are you not running and testing your code?
> Are you not running and testing your code?
Why would you think that?
Because you’re claiming to not debug, and that you’ve gone from 1 hour to 10 seconds. I can only go off of what you tell me here.
Then there's the mass. I don't need that anymore. The mountains of boilerplate, etc.
I write little islands which need high judgement that are then connected by the obvious goo.
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.
Usually, when people say AI code is terrible, it's because they either don't understand the theory well but have grown through hands-on experience and can't explain things properly to the AI, or they don't know what they don't know. Or there are the very few who are just far better coders than AI. Some people will say they're among the rare few who can write better code than AI, and for some that may be true. But in my experience, the vast majority are not. Even from my perspective as a beginner, I could see flaws when I looked at their git code. It's a metacognition problem.
Realistically speaking, at the script level, it's quite common to see AI surpass human programmers as you increase the input level. You might disagree, but that's probably because you're a specialist in that field, deeply immersed in a very narrow area—it only holds true in that limited scope. In the general domain, most people would agree that AI writes code well.
Human programmers don't know much outside their own domain. But AI, while it loses in very narrow specialist areas, writes better code than humans across the broader range. It loses in the 1% zone (the expert's domain), but wins in the other 99%. Usually, when that's the case, you have two choices: become the 1%, or learn how to use AI.
Since I'm a non-native English speaker, I'm already at a disadvantage compared to native speakers in programming skills, so I chose the latter. But I still code. Not for any other reason—if I don't maintain at least some typing muscle, I won't be able to review AI code properly.
That's why I think coding is essential. Even if I can't understand the entirety of AI's output, I still need to understand the core business logic. At the very least, the core logic requires human understanding, so coding is necessary.
And I should mention that I have 30+ years of programming experience.
I’ve stopped using llms to generate architecture, which i design and write myself and let the machine pattern match the gaps. I also use it to review issues which I lot of the times push back against.
I’m working on a stateful application sitting on top of a data warehouse and have to implement a stream of messy half defined feature requests and navigate on top of an ever changing infrastructure layer. LLMs rarely get the infra layer even if it is written as code and have hard time grasping how to deal with tech debt, when and how to re-architecture parts of the stack or even implement stuff based on a detailed openspec design.
Usually, it produces code that would take three or four humans days to figure out—in just 20 minutes.
Even the professors and PhDs who hire me all use AI. Honestly, they hold PhDs and professorships, which puts them in a league I can't even touch—and even they use it. AI just does it really well.
Honestly, I learned from your book, 'rossant'—I never expected a programmer like you to say something like that. I thought my perspective was because I'm only an intermediate-level programmer. But you're in the 1% expert category I mentioned
.... 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.
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.
Beyond hobby projects, most clients often don't really know what they want. And that's generally what we call domain modeling. This is definitely an area where AI is weak. As you know, it mainly pulls from generic patterns.
When there are specific constraints, AI struggles with core business logic. And as you said, it's also weak at choosing the right direction or the goal to pursue. But as you also know, 80% of programming is built on what others have already created. Originality is only about 20%. And in that 80%, AI is absolutely dominant. I agree with you and I've upvoted your comment.
I really like your perspective
Interesting article btw
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.