However I think it's aggrandizing what human engineers actually do with remarks like "Engineers own tradeoffs." My experience is that certainly less than half of the employed software engineers don't actually give a real analysis to questions like:
"Given these constraints, this team, this business, this infrastructure, this budget, these risks, and the expected evolution of the product, what is the most appropriate way to implement X, today?"
Thus I think AI is more able to replace the average engineer more than this article admits, however the inadequacy of "average engineering" will be much more apparent now: codebases can become large/complex enough to be unwieldy in months now when it used to take 5 years [a timescale where accountability is effectively impossible].
These get overlooked so often. The way you build software if you’re at the helm vs the way you need to build it when dealing with a more/less capable team and business, especially if someone else will be doing the deployment and will need lots of consultations, is way different.
This is my favorite part of software engineering. It's not just a set of rules you can apply to get the right answer. You need to use your judgement to make a context-appropriate decision.
It's been ten months since good models started landing and threatening our current job descriptions.
Do you think this is where it stops? This is where it begins.
Machines will be good at managing complexity too. You can't draw a line and say improvement stops here, because everything we've seen so far flies in the face of that.
I shudder to think what these models will be capable of in 24 months.
> Do you think this is where it stops? This is where it begins.
No, this is pretty much where it stops.
The models are good enough for the average coding task, and the slop they produce often is in the category of what a bad or careless dev that's being contracted out might produce.
Yea, they'll get better, but not in next-level sort of way.
The limitation is not the models or intelligence, it's the human in the loop. We're still stuck on stupid human issues ranging from usability bugs, to figuring out what the product should be, to how we should program in the first place.
I know the models are capable of sorting out issues it gets stuck on because it's writing error handling in the wrong way, or just it doesn't have the right abstractions, because we can't settle on the right way to program. I still see people arguing about dyanmic vs. static typing.
And obviously, there is a next level, but that's real singularity, and we're all out of jobs.
Lost me at the first assumption. People can argue about how useful AI is, but it's obviously not essential because we somehow managed to write code without it a few years ago. I would even say the code was better back then.
The two tasks of writing code and engineering software cannot be separated without damaging the integrity of the mental model of the engineer. Having architects who didn't interact with the code always produced map/territory mismatches.
This whole week I've been dealing with incidental complexity created by shortcuts taken and edge cases not handled in code written in the before times, both in mine and in others'. I realized at some point yesterday that these kinds of shortcuts would no longer be accepted with competent LLM use.
Have you looked at the machine instructions your compiler produces?
No? Why?
Because software languages are a pretty good abstraction.
To the extent that good abstractions are in place, you can avoid looking at code specifically.
Those don't perfectly well exist, so it takes a lot of self discipline and the right tools/methods, but invariably, AI will produce better systems.
That said, its very easy to produce slop, so well see much more of it.
But mostly, it will be AI from here on in, as a matter of productivity. There are some arguments on the margins but those will fade over the next few years.
'At minimum' - the 'power tools' are here to stay.
A compiler translating high-level code to machine code is a predictable and repeatable process.
An LLM translating a prompt to to high-level code has a much lower degree of predictability. To say an LLM prompt is a comparable abstraction is unfair, though I admit it's getting very close.
I don't get the use of "abstraction" in this context, I must admit.
Programming abstractions offer interfaces to functionality that are both simplified in use and restricted in capability. (e.g. any API or compiler.) I don't see how LLMs meet that definition.
It seems more like we're talking about offloading or delegation, here. And that's a valid business tactic, certainly, but it's not a software abstraction any more than a CTO is an abstraction of a tech lead, no?
> But yes, it has to fulfill some kind of contract defined by the absraction.
I don't follow. Is the contact here the design specification for the system? If so, again, I'd argue that's not an abstraction.
Higher level languages are still formal languages. I think there's a conceptual difference between moving from one formal language to another (machine instructions to asm or asm to C) and moving from a formal language to natural language. So yes, developing, looking at and understanding a formal description of your system has benefits for an engineer compared to handing off this step completely.
Sure but you only look at it when optimizing some performance critical code, usually the hot path. That is usually a tiny fraction of the codebase. I also use AI to generate large amounts of code but I only inspect the actual code when critical, delicate or architecturally important stuff is involved.
> Have you looked at the machine instructions your compiler produces?
> No? Why?
> Because software languages are a pretty good abstraction.
No, it’s because compilers produce deterministic output. I am so tired of this argument.
If I’m not concerned with the performance of my code, I can be 100% confident that that exact code will produce the correct assembly every time. That’s why I don’t read it. Not because I don’t care.
I don’t know, I could be wrong but I think one of the key aspects of system design which I don’t know if there is a lot of training data for us the “why” behind decisions. Separating out good design from bad isn’t always black and white and like the article mentions it’s about managing complexity and trade offs. It’s hard to capture in code/training data “we designed everything in a certain way but compromised in this one area because we were under time constraints and assumed we could fix it later”
A fun little exercise you can do is design a system and write some code and then ask LLM to explain why you wrote it that way. Results are varied and interesting but in my experience rarely capture the actual why behind decisions.
The real wild shit I'm seeing and having trouble reconciling with continuing my career in this field is that there seems to be a majority contingent of C-suite out there that is absolutely obsessed with force-feeding their organizations AI.
As an software engineer, I will readily admit that LLMs have greatly increased my output - especially on the menial work.
But now we have leadership telling everyone to "use moar AI" on everything, everywhere. I literally have observed folks dropping into incident Slack chats saying things like, "hey all - i asked Claude about this issue and then i had it write a solution. here's the PR." This feels like the kind of thing that should be a fire-able offense, but instead they're getting shout-outs from the CEO.
Hell, the next time I go on vacation, I think I could put Claude Code on YOLO mode for 2 weeks and I'd probably come back to find I'd been promoted.
I do not know how this is going to end, but I have a feeling it's going to get way darker before it gets better.
Sometimes these tradeoffs involve half a dozen over a few lines of code. And that’s where I’m hesitant to let an agent work. It’ll do fine with creating correct code. And you can somewhat constrain it to think about one other thing. But it loses track, ignores constraints, cheats, and do you layer complexity on top to prevent this? Or just look at a dozen lines of code to fix it?
Always reminds me of why OOP came about in the first place; it was a way to manage complexity and led to much better and grander software. Now nobody talks about OOP because abstractions are built into just about everything.
It was sold as a way to manage complexity but then made everything complex in a different way. For some problems, OOP makes sense, but for many I think it doesn’t. Unless you have a Rust like trait system that looks a lot like OOP but isn’t. That works well. Essentially don’t put state inside your classes, or you will be spending lots of refactoring time on moving variables up and down in the class hierarchy or throwing computer out of the window because a variable on second thought shouldn’t have been added near class Y.
AI writing code is a force multiplier and amplifies an orgs existing practices. In other words, if you lack structure and are a fan of chaos engineering, then that gets way worse. On the other hand, if you already have god workflows and an overall structure, it'll help you get things done more quickly.
Thanks, might be the best blog I've read in 2026. AI can of course do architecture as well but oh boy will you have a bad time when your application breaks and neither you or AI can fix it.
One question missing from the list, and it’s the first one I tend to ask… do we really need this? I’m not sure I’ve ever seen an agent pushing back on a request.
You can tweak them to do so. I personally tweak mine to act like a disappointed stack exchange veteran.
I personally recommend, but I understand many people do not want to be pushed back by something they see as little more than a servant.
This setup does work to also have agents argue with each other. That can be very interesting, though you have to set them up to be very skeptical. Otherwise they will tend to read another agents assertion as authoritative off the bat.
I am convinced much of the harness/prompt engineering we are doing now will also be automated away. Within 5 years the best practices for the most popular use cases will have been found, automated and fully baked in.
This. Software hypothetically can permit unlimited complexity. There are only so many ways you can try to build a bridge such that it won't collapse. There are an infinite number of ways that a set of instructions can reach a desired state given enough time, processing and memory resources. This, combined with our relative naivete in how to design and build software that does not approach infinite complexity compared to other engineering disciplines means that the primary thing about building software is managing complexity.
It is revisionist to say that software engineering was never about writing code. It was, in fact, a huge component, and it also wasn't easy. Sure most code is glue but even the glue was tedious and the actual hard and novel parts still aren't really done that well by AI (yet).
It's less about writing code now but we're lying if we try to pretend it was a distraction and not a big part of the real work.
And every claim about what the job actually is or was all along has an implied (for now) at the end of it.
These software engineering analogies are getting tiresome.
People are shouting “yeah the hard part was never writing code, it was managing complexity” as a sort of last hurrah before AI engulfs them.
This is reality: not only can AI write code. It can manage complexity.
Prompt: read the article in this thread then execute its principles on my codebase. Write a harness and programmatic procedures that will trigger you to respond with the articles philosophy to code changes. Be vigilant and monitor every aspect constantly.
I would say for the above prompt, AI is about 60 to 70 percent as a good as a human now. A year ago it was 20 percent. The gap is closing.
No the AI cannot. Did you even read the article? The principles in the article are not rules that can be applied or handed to a prompt. They are questions, not answers. Questions that are impossible to answer and that have no right answer except by human judgement in a concrete context.
Even a human could not “manage complexity” if it’s not in the right context. This is not about AI vs. human capabilities.
I have no idea why people believe AI will not be good at all the other things. It's a general reasoning machine, it surely can reason on many things beside the actual code.
I've been hearing this "writing code is not what being an enginner is" mantra for years like some sort of gotcha. (It was prevalent even before AI, and I think people underestimated a lot how many people were simply incapable of writing code even given all the specs and design choices.)
Technically it is not a reasoning machine. If it was a reasoning machine then we would not see results like this:
> To systematically investigate the role of end-user semantics of derivational traces, we set up a controlled study where we train transformer models from scratch on formally verifiable reasoning traces and the solutions they lead to. We notice that, despite gains over the solution-only baseline, models trained on entirely correct traces can still produce invalid reasoning traces even when arriving at correct solutions. More interestingly, our experiments also show that models trained on corrupted traces, whose intermediate reasoning steps bear no relation to the problem they accompany, perform similarly to those trained on correct ones, and even generalize better on out-of-distribution tasks.
Because it’s not about being “good at things”. You missed the whole point of the article. It’s not about AI vs. human capabilities, even a human could not build software if they are not in the right context.
Here’s an example: back in the 2000s, everyone was afraid programming was going to get outsourced to India or other countries. It didn’t happen, Sillicon Valley continues to spend billions to import engineers to work in person even though it’s 10x cheaper to hire remote outsourcers in India who are just as skilled programmers. Why do they spend 10x to move physical bodies to the office? Because it’s impossible to write good software without being in the physical context of the problem domain and team.
Similarly you cannot outsource to AI, because it cannot have complete context. No matter how good AI is, the problem is not mechanically solvable.
The complexity stuff is all absolutely true.
However I think it's aggrandizing what human engineers actually do with remarks like "Engineers own tradeoffs." My experience is that certainly less than half of the employed software engineers don't actually give a real analysis to questions like:
"Given these constraints, this team, this business, this infrastructure, this budget, these risks, and the expected evolution of the product, what is the most appropriate way to implement X, today?"
Thus I think AI is more able to replace the average engineer more than this article admits, however the inadequacy of "average engineering" will be much more apparent now: codebases can become large/complex enough to be unwieldy in months now when it used to take 5 years [a timescale where accountability is effectively impossible].
> this team, this business
These get overlooked so often. The way you build software if you’re at the helm vs the way you need to build it when dealing with a more/less capable team and business, especially if someone else will be doing the deployment and will need lots of consultations, is way different.
This is my favorite part of software engineering. It's not just a set of rules you can apply to get the right answer. You need to use your judgement to make a context-appropriate decision.
It's been ten months since good models started landing and threatening our current job descriptions.
Do you think this is where it stops? This is where it begins.
Machines will be good at managing complexity too. You can't draw a line and say improvement stops here, because everything we've seen so far flies in the face of that.
I shudder to think what these models will be capable of in 24 months.
> Do you think this is where it stops? This is where it begins.
No, this is pretty much where it stops.
The models are good enough for the average coding task, and the slop they produce often is in the category of what a bad or careless dev that's being contracted out might produce.
Yea, they'll get better, but not in next-level sort of way.
The limitation is not the models or intelligence, it's the human in the loop. We're still stuck on stupid human issues ranging from usability bugs, to figuring out what the product should be, to how we should program in the first place.
I know the models are capable of sorting out issues it gets stuck on because it's writing error handling in the wrong way, or just it doesn't have the right abstractions, because we can't settle on the right way to program. I still see people arguing about dyanmic vs. static typing.
And obviously, there is a next level, but that's real singularity, and we're all out of jobs.
Lost me at the first assumption. People can argue about how useful AI is, but it's obviously not essential because we somehow managed to write code without it a few years ago. I would even say the code was better back then.
The two tasks of writing code and engineering software cannot be separated without damaging the integrity of the mental model of the engineer. Having architects who didn't interact with the code always produced map/territory mismatches.
This whole week I've been dealing with incidental complexity created by shortcuts taken and edge cases not handled in code written in the before times, both in mine and in others'. I realized at some point yesterday that these kinds of shortcuts would no longer be accepted with competent LLM use.
Have you looked at the machine instructions your compiler produces?
No? Why?
Because software languages are a pretty good abstraction.
To the extent that good abstractions are in place, you can avoid looking at code specifically.
Those don't perfectly well exist, so it takes a lot of self discipline and the right tools/methods, but invariably, AI will produce better systems.
That said, its very easy to produce slop, so well see much more of it.
But mostly, it will be AI from here on in, as a matter of productivity. There are some arguments on the margins but those will fade over the next few years.
'At minimum' - the 'power tools' are here to stay.
A compiler translating high-level code to machine code is a predictable and repeatable process.
An LLM translating a prompt to to high-level code has a much lower degree of predictability. To say an LLM prompt is a comparable abstraction is unfair, though I admit it's getting very close.
The LLM will never produce the same output each time, it doesn't have to do that to have very strong level of abstraction.
But yes, it has to fulfill some kind of contract defined by the absraction.
It's less a problem of the LLM, and more so how we use them, and the inherent tooling around it.
I don't get the use of "abstraction" in this context, I must admit.
Programming abstractions offer interfaces to functionality that are both simplified in use and restricted in capability. (e.g. any API or compiler.) I don't see how LLMs meet that definition.
It seems more like we're talking about offloading or delegation, here. And that's a valid business tactic, certainly, but it's not a software abstraction any more than a CTO is an abstraction of a tech lead, no?
> But yes, it has to fulfill some kind of contract defined by the absraction.
I don't follow. Is the contact here the design specification for the system? If so, again, I'd argue that's not an abstraction.
Higher level languages are still formal languages. I think there's a conceptual difference between moving from one formal language to another (machine instructions to asm or asm to C) and moving from a formal language to natural language. So yes, developing, looking at and understanding a formal description of your system has benefits for an engineer compared to handing off this step completely.
Anyone who is involved in any sort of performance critical work looks at compiler output on a regular, if not daily basis.
Sure but you only look at it when optimizing some performance critical code, usually the hot path. That is usually a tiny fraction of the codebase. I also use AI to generate large amounts of code but I only inspect the actual code when critical, delicate or architecturally important stuff is involved.
Yes, but even HFT traders use Java and don't look at the compiler output.
Looking at the compiler output is a totally valid concept, but it's definitely a niche case.
> Have you looked at the machine instructions your compiler produces?
> No? Why?
> Because software languages are a pretty good abstraction.
No, it’s because compilers produce deterministic output. I am so tired of this argument.
If I’m not concerned with the performance of my code, I can be 100% confident that that exact code will produce the correct assembly every time. That’s why I don’t read it. Not because I don’t care.
No - perfect determinism is absolutely not required.
It's entirely the nature of the abstraction.
You want it to work as expected, it does not have to produce the same thing each time.
Sadly many managers decided to do so and the damage is done
I love to say that
We built houses before we had nailguns but now that we have them they're pretty essential to building a house.
Hammer and nail still works, it’s just not as fast and strains the builders.
Problem with the analogy is that the strain in software engineering is necessary for an in depth understanding of the code.
The question is whether that depth of knowledge is ultimately more helpful than the speed that we can build with AI.
AI can also generate the architecture for you based on the requirements, and ask the necessary clarifying questions.
It's not as good at system design as writing code, yet. But it feels like it's better than most of my coworkers.
I think in a few months, system architecture will have its Claude Code moment, and humans will be outclassed.
I don’t know, I could be wrong but I think one of the key aspects of system design which I don’t know if there is a lot of training data for us the “why” behind decisions. Separating out good design from bad isn’t always black and white and like the article mentions it’s about managing complexity and trade offs. It’s hard to capture in code/training data “we designed everything in a certain way but compromised in this one area because we were under time constraints and assumed we could fix it later”
A fun little exercise you can do is design a system and write some code and then ask LLM to explain why you wrote it that way. Results are varied and interesting but in my experience rarely capture the actual why behind decisions.
The real wild shit I'm seeing and having trouble reconciling with continuing my career in this field is that there seems to be a majority contingent of C-suite out there that is absolutely obsessed with force-feeding their organizations AI.
As an software engineer, I will readily admit that LLMs have greatly increased my output - especially on the menial work.
But now we have leadership telling everyone to "use moar AI" on everything, everywhere. I literally have observed folks dropping into incident Slack chats saying things like, "hey all - i asked Claude about this issue and then i had it write a solution. here's the PR." This feels like the kind of thing that should be a fire-able offense, but instead they're getting shout-outs from the CEO.
Hell, the next time I go on vacation, I think I could put Claude Code on YOLO mode for 2 weeks and I'd probably come back to find I'd been promoted.
I do not know how this is going to end, but I have a feeling it's going to get way darker before it gets better.
Sometimes these tradeoffs involve half a dozen over a few lines of code. And that’s where I’m hesitant to let an agent work. It’ll do fine with creating correct code. And you can somewhat constrain it to think about one other thing. But it loses track, ignores constraints, cheats, and do you layer complexity on top to prevent this? Or just look at a dozen lines of code to fix it?
Always reminds me of why OOP came about in the first place; it was a way to manage complexity and led to much better and grander software. Now nobody talks about OOP because abstractions are built into just about everything.
It was sold as a way to manage complexity but then made everything complex in a different way. For some problems, OOP makes sense, but for many I think it doesn’t. Unless you have a Rust like trait system that looks a lot like OOP but isn’t. That works well. Essentially don’t put state inside your classes, or you will be spending lots of refactoring time on moving variables up and down in the class hierarchy or throwing computer out of the window because a variable on second thought shouldn’t have been added near class Y.
I agree, but to manager the complexity you need far less swe.
AI writing code is a force multiplier and amplifies an orgs existing practices. In other words, if you lack structure and are a fan of chaos engineering, then that gets way worse. On the other hand, if you already have god workflows and an overall structure, it'll help you get things done more quickly.
Thanks, might be the best blog I've read in 2026. AI can of course do architecture as well but oh boy will you have a bad time when your application breaks and neither you or AI can fix it.
One question missing from the list, and it’s the first one I tend to ask… do we really need this? I’m not sure I’ve ever seen an agent pushing back on a request.
You can tweak them to do so. I personally tweak mine to act like a disappointed stack exchange veteran.
I personally recommend, but I understand many people do not want to be pushed back by something they see as little more than a servant.
This setup does work to also have agents argue with each other. That can be very interesting, though you have to set them up to be very skeptical. Otherwise they will tend to read another agents assertion as authoritative off the bat.
I am convinced much of the harness/prompt engineering we are doing now will also be automated away. Within 5 years the best practices for the most popular use cases will have been found, automated and fully baked in.
Bing Bing Bing...
How often do engineers get a say in product direction?
Every one keeps saying that AI isnt moving the needle on the bottom line.
Well duh, code doesn't move the bottom line, features do, products do.
If you're building all the wrong things faster, all your doing is performing a speed run to a legacy code base.
I started to look around the site and opened this: https://hack8s.com/409/ziglings-all-exercises-solve-v0-16-0
The site just goes into a reload loop on iOS?
All modern engineering is about managing complexity
Fair, but Software is very different from mech or chem eng though - enough so that it's worthy characterizing.
This. Software hypothetically can permit unlimited complexity. There are only so many ways you can try to build a bridge such that it won't collapse. There are an infinite number of ways that a set of instructions can reach a desired state given enough time, processing and memory resources. This, combined with our relative naivete in how to design and build software that does not approach infinite complexity compared to other engineering disciplines means that the primary thing about building software is managing complexity.
Is it only me who gets eye pop by just how the font is rendered on that website?
Same here, it was really tough on my eyes.
It is revisionist to say that software engineering was never about writing code. It was, in fact, a huge component, and it also wasn't easy. Sure most code is glue but even the glue was tedious and the actual hard and novel parts still aren't really done that well by AI (yet).
It's less about writing code now but we're lying if we try to pretend it was a distraction and not a big part of the real work.
And every claim about what the job actually is or was all along has an implied (for now) at the end of it.
Spitting out code as fast as our fingers could type has never been the job. There has always been a lot of think time.
Which is why the productivity of people of people has never been correlated with typing speed.
In other jobs productivity is correlated with typing speed and in those jobs a typing speed like 60wpm is part of the job requirements.
Software engineering was never about writing "just" code. Simply writing code was not enough in most business environments.
I didn't use the word "just"
I did. I am adding on to your argument. In general, a reply to you never needs to be a counter. It can be a build up too.
These software engineering analogies are getting tiresome.
People are shouting “yeah the hard part was never writing code, it was managing complexity” as a sort of last hurrah before AI engulfs them.
This is reality: not only can AI write code. It can manage complexity.
Prompt: read the article in this thread then execute its principles on my codebase. Write a harness and programmatic procedures that will trigger you to respond with the articles philosophy to code changes. Be vigilant and monitor every aspect constantly.
I would say for the above prompt, AI is about 60 to 70 percent as a good as a human now. A year ago it was 20 percent. The gap is closing.
No the AI cannot. Did you even read the article? The principles in the article are not rules that can be applied or handed to a prompt. They are questions, not answers. Questions that are impossible to answer and that have no right answer except by human judgement in a concrete context.
Even a human could not “manage complexity” if it’s not in the right context. This is not about AI vs. human capabilities.
The article is AI generated and there's nothing new in it. Just a bait for boomers. Hacker News version of what Gen Z calls "coal posting".
I have no idea why people believe AI will not be good at all the other things. It's a general reasoning machine, it surely can reason on many things beside the actual code.
I've been hearing this "writing code is not what being an enginner is" mantra for years like some sort of gotcha. (It was prevalent even before AI, and I think people underestimated a lot how many people were simply incapable of writing code even given all the specs and design choices.)
Technically it is not a reasoning machine. If it was a reasoning machine then we would not see results like this:
> To systematically investigate the role of end-user semantics of derivational traces, we set up a controlled study where we train transformer models from scratch on formally verifiable reasoning traces and the solutions they lead to. We notice that, despite gains over the solution-only baseline, models trained on entirely correct traces can still produce invalid reasoning traces even when arriving at correct solutions. More interestingly, our experiments also show that models trained on corrupted traces, whose intermediate reasoning steps bear no relation to the problem they accompany, perform similarly to those trained on correct ones, and even generalize better on out-of-distribution tasks.
https://arxiv.org/abs/2505.13775
Beyond Semantics: The Unreasonable Effectiveness of Reasonless Intermediate Tokens
Because it’s not about being “good at things”. You missed the whole point of the article. It’s not about AI vs. human capabilities, even a human could not build software if they are not in the right context.
Here’s an example: back in the 2000s, everyone was afraid programming was going to get outsourced to India or other countries. It didn’t happen, Sillicon Valley continues to spend billions to import engineers to work in person even though it’s 10x cheaper to hire remote outsourcers in India who are just as skilled programmers. Why do they spend 10x to move physical bodies to the office? Because it’s impossible to write good software without being in the physical context of the problem domain and team.
Similarly you cannot outsource to AI, because it cannot have complete context. No matter how good AI is, the problem is not mechanically solvable.