As a software guy (developer, engineer, whatever we call it now), I think demand is growing invisibly, in the form of higher expectations. We run a product search engine that's about as dumb as it's always been, yet non-tech colleagues say it has "degraded," because everyone now treats contextual search (vector search, etc.) as the baseline. Seemingly the same feature, but making it feel modern takes significantly more to execute.
Another example: a few years ago, building "chat" meant high-latency messaging between humans, and plain REST was enough. Now that the interface involves talking to agents, streaming is expected. The user wants to watch the response appear as the model generates it and calls tools. Again, seemingly the same feature, but a lot more under the hood. This is maybe why the middle of the sandwich doesn't actually shrink: AI compresses the per-unit effort, but the spec for any given feature keeps inflating to fill it back up (see also Parkinson's Law).
The other thing I'd add is the uncertainty about where to re-skill and how to get across a discontinuity like the one in your programmer-vs-software-developer(engineer) chart. Say you're a designer with a decade of experience. You know a lot, you've shipped a lot. But every opening now has dozens of applicants reaching the final stages (4–5 interviews, all competing), so demand clearly isn't on the candidate's side. That pushes you to find an adjacent domain to jump into, and doing that well is much harder than it sounds. Sounds like the individual-level story the next essay is setting up.
It's like an arms-race mixed with game-theory powered by Jevon's paradox where it feels like the Red Queen scene where you are running in place just to stand in the same spot to keep up with the pace.
A brief comment— the demand is falling dramatically for junior roles. Which means in 5 years there won’t be enough seniors to decide and deliver. Execution is where juniors “learn the ropes,” and this is being consumed by AI coding tools.
Might some of the drop be an overshoot that will need to be corrected in the near future? My employer went through that, even saying they weren’t interested in senior people because they were top heavy and needed a lot more bodies.
Very good, well researched set of facts - a breath of fresh air in an environment polluted by hype.
> AI sometimes decimates demand for the product, in cases like Chegg (homework help) or Stack Overflow (technical help)
I realize that your primary point here was about job losses, but I wanted to add a small nuance about Stack Overflow in particular. AI companies have appropriated a public good (public answers to technical problems) and are replaying those answers back now (for a fee). But LLMs can only answer questions that have already been answered in the past - I therefore think that as technology evolves and new programming languages and paradigms emerge, a different set of questions will be asked - at this point, the need for a product like Stack Overflow will re-emerge. My guess is that AI companies have only temporarily redirected the demand towards themselves, and have not really obviated the need.
The sandwich framing holds up better than most jobs-automation models because it names where the work actually moves. Compress the execute layer and the binding constraint shifts to deliver, where integration, review, and someone owning the outcome do not get cheaper just because the code does. That layer also absorbs more work as execution gets cheap, which is why demand can stay healthy while individual roles still churn.
Anecdotally, my experience supports your analysis. Our internal AI training explicitly discourages "vibe coding" and promotes a model where you are supposed to analyse a problem, break into sub-tasks, supervise the "agent" at each step etc. This makes AI just another evolution of "high-level programming"; if you can't "think like a programmer", you won't be able to follow the model. It is also true that in any case, a fairly small minority of my time was spent coding before AI arrived.
The claims made for AI agents make me nostalgic for my youth, when some people thought that formal proof systems were going to revolutionize programming and eliminate all bugs. But the proof of correctness was relative to some specification, and somebody had to write that specification in some language that could be read by the proof tool, which is to say "programmed".
I remember the same thing about proofs. For a while, I tried to learn a couple of the formal specification languages, and they were way harder than the procedural languages I was trained to use.
Emily Riehl has expressed enthusiasm about formal proof systems in mathematics, e.g. LEAN, so I try to keep an open mind. But even she seems to be attributing value to the effort needed to formalize a proof in steps that LEAN will accept.
Thanks. Have you read the famous paper that explains why mathematicians don’t read computer-generated proofs? I forget who wrote it, but it was quite influential.
I also think it is very likely if you sandwich too much the edges / bread will rupture from the pressure on the inside. Interpreting the metaphor - this is when the humans cannot handle the mess from the code. I think it is important to consider the possibility that these systems will continue the *speed* trajectory but not with the right velocity. Vitaly's remark about juniors is just one area where we have to be extremely careful. I have no capacity to even begin to study that question, but I think we as an industry may be at serious risk if we don't get an answer to this.
Also, in some domains at least there will also always be a "good enough, who cares?" aspect to any automation/replacement/different approach, and that's where the "CEO wants the demo" will matter - if not necessarily in software but in other domains. A friend is a classical musician and I'm worried that she will encounter people who will say "$1000 for the excellent human or $10 for the mediocre but passable robot. I'll take the robot." Is this going to happen in software? I'm currently a cyber security professional, and the difference might be in that area.
One aspect of the latter that I think we can work on to help prevent that outcome would be to stop talking about "non-functional requirements". Security, performance, resilience, accessibility, etc. are *not* optional, even if they come in degrees.
The sandwich is the most useful frame I've seen for this, and it matches my practice from the outside-in: I'm a designer, not an engineer, and I ship small working tools I never read the code for. What I do all day is the decide and deliver ends — holding the spec, deciding what the thing should be, verifying it does that in the world. The execute layer is the part I happily hand off.
Which is exactly why I'd take the other side of your democratization bet. You argue the barrier was never syntax — it's judgment and accountability. I think that's right, but it cuts against you, not for you. If syntax is the part AI ate and judgment is what's left, the people producing more software won't necessarily be software engineers. They'll be whoever brings the domain judgment and is willing to own the delivery.
Your spectrum also flattens a third practitioner your two columns can't hold: high judgment, high accountability, zero code review — verifying at the level of behavior, not source. That's neither vibe coding nor agentic engineering — I've started calling it intent coding. From where I sit, it might be a lot of what "more software" actually ends up looking like.
I think there are two different types of judgement required to create good software - judgement about the solution (solution domain judgement) and judgment about the software itself (software domain judgement). The latter includes how to build the software cost effectively, securely, robustly, how to build for scale, how to account for compliances, where and how it is to be hosted, which libraries are to be used, how the software is to be decomposed into parts that can be independently executed by teams, and so on - this is the judgement that prevents lawyers from building enterprise- or even consumer-grade legal software (though AI may allow them to build software for themselves - which is amazing progress in itself).
I may know everything about washing clothes, but just because I have a supremely powerful 3D printer, it doesn't mean that I will be successful at building washing machines.
This is a sharper cut than mine. "Software domain judgment" names the boundary I was clumsily pointing at when I said it breaks where correctness hides below the surface. And I'll be straight: at enterprise or consumer grade, you're right, and I don't have that judgment. The "for themselves" tier is exactly where I live, and I'm not pretending otherwise.
The one place I'd complicate the analogy: a 3D printer is dumb, but an LLM sitting on a managed platform isn't. A lot of software-domain judgment has already migrated from the person to the substrate. Vercel or Supabase encodes hosting and scaling decisions, managed auth encodes a security posture, and the model defaults to mainstream libraries. The builder inherits all of that without possessing any of it. So it's less "know clothes, own a printer" and more "own a printer that has studied a million washing machines."
One honest bound, though. Defaults only carry the common case. Software-domain judgment is exactly what you need when the defaults are wrong for your situation, and "the defaults are wrong for you" is close to a definition of enterprise-grade. So the substrate keeps widening the tier you can build without judgment, without ever touching the tier where you can't. The boundary you drew is real. It's just moving, and how fast it's moving is the part worth arguing about.
I agree with you about the limits of the 3D printer analogy - it is more like a 3D printer that is able to download the plan for any part from the internet :) This still doesn't give me the ability to create a washing machine - in many cases, the software solution being built is novel or their code / logic is hidden behind servers - in such cases, LLMs haven't trained on enough of the same type of software (enough washing machines) to be able to generate another one with small variations (notable exceptions are certain types of games, eCommerce / blog websites)
> So the substrate keeps widening the tier you can build without judgment
I beg to differ - there is no evidence to support that coding LLMs are only going to get better. Today's LLMs have already ingested all the world's code and there isn't any more - there is growing suspicion that autophagy (LLMs ingesting LLM-generated outputs) / feeding LLMs engineered or synthetic data is likely to make them worse. I think there is a real chance that they may get worse or stagnate (not immediately perhaps, but in a few years).
Of course, we haven't even talked about what happens when the VC-funded token subisidies run out - I wonder how many individuals will be able to afford coding LLMs then.
On novelty, full agreement, and it strengthens the boundary rather than weakening it: the tier where my mode works is precisely the tier where the software is a recombination of patterns the model has seen a million times. Forms, trackers, glue code. My tools are boring by design. Nobody intent-codes their way to novel infrastructure.
One clarification, because I said it badly: by "substrate," I didn't mean the models keep improving. I meant the platform layer around them. Vercel, Supabase, managed auth. That layer encodes software-domain judgment through ordinary platform engineering, and it would keep absorbing decisions even if model capability froze today. The widening I'm betting on lives mostly there, not in the weights.
Regarding autophagy, one reason a code may be the most collapse-resistant domain is that it produces its own ground truth. Generated code can be compiled, run, and tested, so synthetic training data with execution feedback isn't a copy of a copy, the way synthetic prose is. I hold that loosely; I'm reasoning from outside the field. Your economics point is the one that lands hardest for me, and my only answer is that my tier doesn't need frontier: small, boring tools were already within reach of much weaker models, and open-weight models running locally are already covering a growing share. The personal-software floor looks more durable than the subsidy. Whether that's true is probably the real open question, more than capability.
Orthogonally, I am assuming that you are human using an LLM to respond. If you are a pure bot, I'm impressed - you are making pretty good points. I am pure human, by the way :)
Pure human, promise. Spanish is my first language, Rioplatense Spanish at that. I think and argue in Spanish, and I use an LLM to render my side in English so it doesn't read like a translation. So your assumption was right on both counts.
Which is, now that you name it, the same arrangement we've spent three rounds discussing: I hold the position and the judgment, the model executes the rendering, and I verify the output at the level of behavior, not word by word. My English comments are intent-coded too. Consider this thread a live demo.
So yes, there is a human in the loop after all. The fine print nobody mentions: the loop runs at all hours, and the human never gets to leave it.
This third practitioner sounds to me like a product owner with an LLM instead of a development team. This model works as long as that person can guide an LLM to fully code to the requirements. I'm not sure how feasible that is, in the absence of knowing code and doing code reviews.
Which elements of the vibe coding column do you think this third practioner does not meet?
Fair challenge — let me take the direct question first. Two elements it doesn't meet: supervision and evaluation. I supervise the process — direct it, reject outputs, redirect — rather than letting it run unwatched. And I evaluate the result hard, just at the behavior/requirements level, not the source level. The post's vibe coder "doesn't evaluate output beyond noticing when things are visibly broken," and that's the line I'm on the far side of. What I do concede is code review: I don't do it, and often couldn't. So this isn't agentic engineering with the credential filed off — it shares vibe coding's no-code-review trait but rejects its no-supervision and no-evaluation ones.
Which is why "product owner with an LLM instead of a dev team" doesn't land as a dunk for me — it's close to the actual claim. Product-owner work is the decide and deliver layers, the parts your essay says resist automation. The LLM ate the execute layer in the middle; it didn't eat the ends.
On feasibility: I do ship this way, but the boundary is real and it's basically your consequence axis. It works for small, single-purpose, low-stakes tools where behavior-level verification is enough — internal utilities, prototypes, personal software. It breaks exactly where correctness hides below the surface: security, data integrity, multi-user state. Those failures aren't "visibly broken," which is where the 9x-vulnerability number bites, and I'm not claiming this scales past it. Only that it's a real mode for a class of artifacts that never justified a dev team in the first place.
Most certainly I was not intending to dunk on you! And I think you are definitely right that this approach opens up new possibilities in the personal space where paid development was never a consideration. Very much like another comment noting ai art usage by streamers with low/no following.
No worries at all — took it that way. And the streamer-art parallel is exactly right: same mechanism. The cost of creation drops below the point where commissioning anyone was ever on the table, and a tier of artifacts that simply never existed starts getting made. Not substitution — net-new stuff under the old economic floor.
What I find genuinely interesting is what that floor-drop surfaces. Most of what I build this way are things I'd never have paid for or learned to code for; they'd just have stayed friction I lived with. The open question I don't have a good answer to yet is whether that long tail stays personal and disposable, or whether some of it matures into something that crosses back into "worth doing properly."
Verifying only behavior is going to miss security vulnerabilities, no? Somehow the attack surface has to be defined, and this is inherently structural.
I like "intent coding." The scarce skill may no longer be writing code, but defininng outcomes, exercising judgment..and taking responsibility for what gets shipped/deployed..
I substantively agree with the points raised in this piece. As a senior software engineer I expect that the number of jobs will only grow in response to the advent of AI. Specifying a domain well, choosing the correct invariants, meeting regulatory and other burdens cannot be automated away with current technology. What I have noticed in my day to day affairs is that AI can produce locally convincing yet globally incomprehensible or self-defeating code. LLMs are interesting and have their uses but a grounded view (like what this article shares) of their capacities and limits is more reasonable. I mostly use them like a lossy search engine.
One piece of low hanging fruit for responsible use of coding tools is to have it write little pieces of code according to a template so you can save yourself some typing. Another is to use the same technique to write little python scripts that generate code according to some straightforward template, etc..
What these two things have in common is that you already know what you want to type, can visualize it in your head, and you can quickly get some dumb piece of code or an LLM to make it for you. In my last job, there were probably 1 million lines of code in our company code base that I was intimately familiar with, and from which I could draw good size chunks to copy and paste from and do a little massaging to get what I wanted.
These various chunks of code had already been through design review and code review so I knew the design was solid, and the only code review I would need is to make sure that I didn’t leave any bits of the old code behind that would cause a problem.
This would be fine, if the results were consistent and reliable. But every run is like a game of roulette.
You can build tests to catch failures, but you're either writing the tests yourself (which can be as complex as the actual code you are trying to create) or you're having the LLM write that, too.
That's the worst thing about this technology: the tension between the temptation to use it and the feeling of nausea you get deploying something you can't possibly check in detail.
Or even worse, having AI write scripts that launch emails, but don’t handle it properly when the email server starts rejecting emails. iThen you have a mess that you don’t know how to clean up.
But I did note that you should know what good code will look like, as well as how to test it.
Replace AI (vibe-coding, Agentic engineering) with offshoring, and the sandwich model and its impact remains fairly intact. Offshoring was very much teh same concept - software dev teams in India could develop code more cheaply than domestic SW engineers, so management decided to go in this direction. But this created all sorts of frictions, that made the process not much less costly, and certainly increased the issues of the elements outside teh coding. It also forced the development cycle back towards the waterfall method, rather than the iterative approach that was gaining mind share at the time.
I have been retired from developing and managing SW for over 2 decades, and it seems the development process has become more complex with more frameworks and languages added to dev ops. Can AI solve the complexity issue? I suspect not, as there are decisions to be made that increase the non-coding bottlenecks.
It seems to me that we have been here before, with the promises of AI repeating the same errors as offshoring.
I would certainly like to know whether vibe coding really democratizes throwaway app development or whether this is still thrown back to the SW team (jnr. coders?) for execution? I have a feeling this will not happen any more than other attempts have largely failed - visual programming and spreadsheet code beyond simple cell computations.
Just got off the phone with our daughter, who just had an important ai-coded in house tool screw something up. You’re right: ultimately, someone has to be able to roll up their sleeves and dig through logs of what went wrong, for example. A “working” tool can hit an anomalous condition, and totally fail. Then the vibe coders are suddenly helpless because they never understood how the app actually did its job.
I cannot express in words how much you have done for me to increase my sanity and clarity in how I understand AI and its effects.
Of course, your framework *might* turn out to be wrong, as is true for every model, but it is such a breath of fresh air and clear thinking in the discourse that was direly needed
People outside the field are often surprised to learn how programming is not the hardest part of the job. In larger tech organisations where dedicated roles like product manager handles the admin or client interaction responsibilities, ~50% programming.
In small to medium orgs where the software engineer wear multiple hats they are less exposed, ~20% programming. Most of harder parts are figuring out what the clients actually want, understand constraints like office politics, budgets, feasibility, anticipating and mitigating when the system fails, solving edge-cases, legal liability, taking responsibility when things go wrong, etc...
Software development is also, unlike other fields like law or accountancy, not purely a cost centre. Some software are related to cost centre (IT operations) but most software are also critical for the profit (unique selling point) of the business.
Amen. Coding is easy –– knowing what to code, knowing what it will cost, and planning for the effort of proving to other people that the resulting system is going to do all that it is supposed to do and none of that which it is not supposed to do are where the headaches come from.
I really like your summary of the bottlenecks (deciding & specifying, verifying, and understanding). This makes it clearer to me why humans work is not only required but also still difficult. Specifying is hard. Even if AI never makes mistakes, verification is required because the specification could be wrong and you'd only catch that by verifying. Building understanding is hard and necessary to have the information needed for specifying in the next iteration.
As a non-software engineer with an interest in this topic I appreciate your clear explanations. I had a suspicion that many of the “AI is taking software engineer jobs” claims were false or misleading but your explanation of what is happening behind the scenes helped clarify what is actually happening. This type of analysis needs to be more common in reporting of this topic rather than just acceptance of claims at face value.
On a separate topic, I think your point about entrepreneurship is interesting. Anecdotally, I have come across this in my own experiments with AI. For example, I was experimenting with streaming on Twitch recently. I’m not an artist and as a new streamer I didn’t think it wise to spend a lot of money on art assets so I used Canva and Gemini to create what I needed. While streaming I would come across artists looking for work and many lamented that AI was making it harder for them to find work because people could create what they needed themselves. I imagine this has less of an effect on established artists but I would be curious to see how AI is impacting these areas of small entrepreneurship. On the flip side I’m sure some artists have found ways to take advantage of it so it might go both ways.
The part that intriges me is that AI is best at generating the one layer only humans can sign off on. Eight times the code, but someone still has to understand it and stand behind it, and that reading is the slow part. So the tool floods the pipe with the exact thing it can't take responsibility for. That is probably why the gains feel muted and why supervising is what wears people out by 11am. You are not writing less, you are verifying more, and verifying was always the tiring part. Makes me wonder whether the honest metric isn't lines written or releases shipped but hours spent checking code you didn't write.
"Becoming an AI-native firm has become memetic. You restructure the org (read fire employees), you wire a frontier API through every workflow, and you report tokens consumed to the board as evidence of transformation, right up until the token bill becomes unbearable and you quietly hire people back. Tokens consumed is the lab’s revenue line, repackaged as your productivity metric. You are reading your transformation off somebody else’s invoice.
It gets worse because the party that printed the invoice is in the business of hollowing you out. Meter your inputs, make tokenmaxxing the measure of productivity, drain your decision traces, sell the frontier model back to you at a markup. The contracts now mostly promise that your prompts will never train the next model, and the promise is mostly kept. The lab learns from the aggregate anyway, which workflows the economy routes through it, where the failures cluster, which evals matter, and the next model arrives fitted to your industry, whether or not it ever saw your data. You pay in cash, and then again in exhaustion and dependence."
I think this is an important corrective to the habit of treating software work as only code generation. In practice, a lot of the value sits in judgment: understanding business context, handling edge cases, managing change, and making accountable decisions when the tradeoffs are not obvious. That is also where governance shows up. For AI use in engineering, the question is less whether a model can produce output and more whether the organization can review, trace, and own the result. The human role does not disappear there, it becomes more explicit.
As a software guy (developer, engineer, whatever we call it now), I think demand is growing invisibly, in the form of higher expectations. We run a product search engine that's about as dumb as it's always been, yet non-tech colleagues say it has "degraded," because everyone now treats contextual search (vector search, etc.) as the baseline. Seemingly the same feature, but making it feel modern takes significantly more to execute.
Another example: a few years ago, building "chat" meant high-latency messaging between humans, and plain REST was enough. Now that the interface involves talking to agents, streaming is expected. The user wants to watch the response appear as the model generates it and calls tools. Again, seemingly the same feature, but a lot more under the hood. This is maybe why the middle of the sandwich doesn't actually shrink: AI compresses the per-unit effort, but the spec for any given feature keeps inflating to fill it back up (see also Parkinson's Law).
The other thing I'd add is the uncertainty about where to re-skill and how to get across a discontinuity like the one in your programmer-vs-software-developer(engineer) chart. Say you're a designer with a decade of experience. You know a lot, you've shipped a lot. But every opening now has dozens of applicants reaching the final stages (4–5 interviews, all competing), so demand clearly isn't on the candidate's side. That pushes you to find an adjacent domain to jump into, and doing that well is much harder than it sounds. Sounds like the individual-level story the next essay is setting up.
It's like an arms-race mixed with game-theory powered by Jevon's paradox where it feels like the Red Queen scene where you are running in place just to stand in the same spot to keep up with the pace.
A brief comment— the demand is falling dramatically for junior roles. Which means in 5 years there won’t be enough seniors to decide and deliver. Execution is where juniors “learn the ropes,” and this is being consumed by AI coding tools.
Might some of the drop be an overshoot that will need to be corrected in the near future? My employer went through that, even saying they weren’t interested in senior people because they were top heavy and needed a lot more bodies.
Very good, well researched set of facts - a breath of fresh air in an environment polluted by hype.
> AI sometimes decimates demand for the product, in cases like Chegg (homework help) or Stack Overflow (technical help)
I realize that your primary point here was about job losses, but I wanted to add a small nuance about Stack Overflow in particular. AI companies have appropriated a public good (public answers to technical problems) and are replaying those answers back now (for a fee). But LLMs can only answer questions that have already been answered in the past - I therefore think that as technology evolves and new programming languages and paradigms emerge, a different set of questions will be asked - at this point, the need for a product like Stack Overflow will re-emerge. My guess is that AI companies have only temporarily redirected the demand towards themselves, and have not really obviated the need.
The sandwich framing holds up better than most jobs-automation models because it names where the work actually moves. Compress the execute layer and the binding constraint shifts to deliver, where integration, review, and someone owning the outcome do not get cheaper just because the code does. That layer also absorbs more work as execution gets cheap, which is why demand can stay healthy while individual roles still churn.
Anecdotally, my experience supports your analysis. Our internal AI training explicitly discourages "vibe coding" and promotes a model where you are supposed to analyse a problem, break into sub-tasks, supervise the "agent" at each step etc. This makes AI just another evolution of "high-level programming"; if you can't "think like a programmer", you won't be able to follow the model. It is also true that in any case, a fairly small minority of my time was spent coding before AI arrived.
The claims made for AI agents make me nostalgic for my youth, when some people thought that formal proof systems were going to revolutionize programming and eliminate all bugs. But the proof of correctness was relative to some specification, and somebody had to write that specification in some language that could be read by the proof tool, which is to say "programmed".
I remember the same thing about proofs. For a while, I tried to learn a couple of the formal specification languages, and they were way harder than the procedural languages I was trained to use.
Emily Riehl has expressed enthusiasm about formal proof systems in mathematics, e.g. LEAN, so I try to keep an open mind. But even she seems to be attributing value to the effort needed to formalize a proof in steps that LEAN will accept.
https://www.cs.cmu.edu/~pattis/misc/socialproofs.pdf
Thanks. Have you read the famous paper that explains why mathematicians don’t read computer-generated proofs? I forget who wrote it, but it was quite influential.
I also think it is very likely if you sandwich too much the edges / bread will rupture from the pressure on the inside. Interpreting the metaphor - this is when the humans cannot handle the mess from the code. I think it is important to consider the possibility that these systems will continue the *speed* trajectory but not with the right velocity. Vitaly's remark about juniors is just one area where we have to be extremely careful. I have no capacity to even begin to study that question, but I think we as an industry may be at serious risk if we don't get an answer to this.
Also, in some domains at least there will also always be a "good enough, who cares?" aspect to any automation/replacement/different approach, and that's where the "CEO wants the demo" will matter - if not necessarily in software but in other domains. A friend is a classical musician and I'm worried that she will encounter people who will say "$1000 for the excellent human or $10 for the mediocre but passable robot. I'll take the robot." Is this going to happen in software? I'm currently a cyber security professional, and the difference might be in that area.
One aspect of the latter that I think we can work on to help prevent that outcome would be to stop talking about "non-functional requirements". Security, performance, resilience, accessibility, etc. are *not* optional, even if they come in degrees.
The sandwich is the most useful frame I've seen for this, and it matches my practice from the outside-in: I'm a designer, not an engineer, and I ship small working tools I never read the code for. What I do all day is the decide and deliver ends — holding the spec, deciding what the thing should be, verifying it does that in the world. The execute layer is the part I happily hand off.
Which is exactly why I'd take the other side of your democratization bet. You argue the barrier was never syntax — it's judgment and accountability. I think that's right, but it cuts against you, not for you. If syntax is the part AI ate and judgment is what's left, the people producing more software won't necessarily be software engineers. They'll be whoever brings the domain judgment and is willing to own the delivery.
Your spectrum also flattens a third practitioner your two columns can't hold: high judgment, high accountability, zero code review — verifying at the level of behavior, not source. That's neither vibe coding nor agentic engineering — I've started calling it intent coding. From where I sit, it might be a lot of what "more software" actually ends up looking like.
I think there are two different types of judgement required to create good software - judgement about the solution (solution domain judgement) and judgment about the software itself (software domain judgement). The latter includes how to build the software cost effectively, securely, robustly, how to build for scale, how to account for compliances, where and how it is to be hosted, which libraries are to be used, how the software is to be decomposed into parts that can be independently executed by teams, and so on - this is the judgement that prevents lawyers from building enterprise- or even consumer-grade legal software (though AI may allow them to build software for themselves - which is amazing progress in itself).
I may know everything about washing clothes, but just because I have a supremely powerful 3D printer, it doesn't mean that I will be successful at building washing machines.
This is a sharper cut than mine. "Software domain judgment" names the boundary I was clumsily pointing at when I said it breaks where correctness hides below the surface. And I'll be straight: at enterprise or consumer grade, you're right, and I don't have that judgment. The "for themselves" tier is exactly where I live, and I'm not pretending otherwise.
The one place I'd complicate the analogy: a 3D printer is dumb, but an LLM sitting on a managed platform isn't. A lot of software-domain judgment has already migrated from the person to the substrate. Vercel or Supabase encodes hosting and scaling decisions, managed auth encodes a security posture, and the model defaults to mainstream libraries. The builder inherits all of that without possessing any of it. So it's less "know clothes, own a printer" and more "own a printer that has studied a million washing machines."
One honest bound, though. Defaults only carry the common case. Software-domain judgment is exactly what you need when the defaults are wrong for your situation, and "the defaults are wrong for you" is close to a definition of enterprise-grade. So the substrate keeps widening the tier you can build without judgment, without ever touching the tier where you can't. The boundary you drew is real. It's just moving, and how fast it's moving is the part worth arguing about.
I agree with you about the limits of the 3D printer analogy - it is more like a 3D printer that is able to download the plan for any part from the internet :) This still doesn't give me the ability to create a washing machine - in many cases, the software solution being built is novel or their code / logic is hidden behind servers - in such cases, LLMs haven't trained on enough of the same type of software (enough washing machines) to be able to generate another one with small variations (notable exceptions are certain types of games, eCommerce / blog websites)
> So the substrate keeps widening the tier you can build without judgment
I beg to differ - there is no evidence to support that coding LLMs are only going to get better. Today's LLMs have already ingested all the world's code and there isn't any more - there is growing suspicion that autophagy (LLMs ingesting LLM-generated outputs) / feeding LLMs engineered or synthetic data is likely to make them worse. I think there is a real chance that they may get worse or stagnate (not immediately perhaps, but in a few years).
Of course, we haven't even talked about what happens when the VC-funded token subisidies run out - I wonder how many individuals will be able to afford coding LLMs then.
On novelty, full agreement, and it strengthens the boundary rather than weakening it: the tier where my mode works is precisely the tier where the software is a recombination of patterns the model has seen a million times. Forms, trackers, glue code. My tools are boring by design. Nobody intent-codes their way to novel infrastructure.
One clarification, because I said it badly: by "substrate," I didn't mean the models keep improving. I meant the platform layer around them. Vercel, Supabase, managed auth. That layer encodes software-domain judgment through ordinary platform engineering, and it would keep absorbing decisions even if model capability froze today. The widening I'm betting on lives mostly there, not in the weights.
Regarding autophagy, one reason a code may be the most collapse-resistant domain is that it produces its own ground truth. Generated code can be compiled, run, and tested, so synthetic training data with execution feedback isn't a copy of a copy, the way synthetic prose is. I hold that loosely; I'm reasoning from outside the field. Your economics point is the one that lands hardest for me, and my only answer is that my tier doesn't need frontier: small, boring tools were already within reach of much weaker models, and open-weight models running locally are already covering a growing share. The personal-software floor looks more durable than the subsidy. Whether that's true is probably the real open question, more than capability.
Orthogonally, I am assuming that you are human using an LLM to respond. If you are a pure bot, I'm impressed - you are making pretty good points. I am pure human, by the way :)
Pure human, promise. Spanish is my first language, Rioplatense Spanish at that. I think and argue in Spanish, and I use an LLM to render my side in English so it doesn't read like a translation. So your assumption was right on both counts.
Which is, now that you name it, the same arrangement we've spent three rounds discussing: I hold the position and the judgment, the model executes the rendering, and I verify the output at the level of behavior, not word by word. My English comments are intent-coded too. Consider this thread a live demo.
So yes, there is a human in the loop after all. The fine print nobody mentions: the loop runs at all hours, and the human never gets to leave it.
This third practitioner sounds to me like a product owner with an LLM instead of a development team. This model works as long as that person can guide an LLM to fully code to the requirements. I'm not sure how feasible that is, in the absence of knowing code and doing code reviews.
Which elements of the vibe coding column do you think this third practioner does not meet?
Fair challenge — let me take the direct question first. Two elements it doesn't meet: supervision and evaluation. I supervise the process — direct it, reject outputs, redirect — rather than letting it run unwatched. And I evaluate the result hard, just at the behavior/requirements level, not the source level. The post's vibe coder "doesn't evaluate output beyond noticing when things are visibly broken," and that's the line I'm on the far side of. What I do concede is code review: I don't do it, and often couldn't. So this isn't agentic engineering with the credential filed off — it shares vibe coding's no-code-review trait but rejects its no-supervision and no-evaluation ones.
Which is why "product owner with an LLM instead of a dev team" doesn't land as a dunk for me — it's close to the actual claim. Product-owner work is the decide and deliver layers, the parts your essay says resist automation. The LLM ate the execute layer in the middle; it didn't eat the ends.
On feasibility: I do ship this way, but the boundary is real and it's basically your consequence axis. It works for small, single-purpose, low-stakes tools where behavior-level verification is enough — internal utilities, prototypes, personal software. It breaks exactly where correctness hides below the surface: security, data integrity, multi-user state. Those failures aren't "visibly broken," which is where the 9x-vulnerability number bites, and I'm not claiming this scales past it. Only that it's a real mode for a class of artifacts that never justified a dev team in the first place.
Most certainly I was not intending to dunk on you! And I think you are definitely right that this approach opens up new possibilities in the personal space where paid development was never a consideration. Very much like another comment noting ai art usage by streamers with low/no following.
No worries at all — took it that way. And the streamer-art parallel is exactly right: same mechanism. The cost of creation drops below the point where commissioning anyone was ever on the table, and a tier of artifacts that simply never existed starts getting made. Not substitution — net-new stuff under the old economic floor.
What I find genuinely interesting is what that floor-drop surfaces. Most of what I build this way are things I'd never have paid for or learned to code for; they'd just have stayed friction I lived with. The open question I don't have a good answer to yet is whether that long tail stays personal and disposable, or whether some of it matures into something that crosses back into "worth doing properly."
Verifying only behavior is going to miss security vulnerabilities, no? Somehow the attack surface has to be defined, and this is inherently structural.
I like "intent coding." The scarce skill may no longer be writing code, but defininng outcomes, exercising judgment..and taking responsibility for what gets shipped/deployed..
Exactly. And the weight of it moves upstream—judgment before code, responsibility after. The craft got lighter; the accountability didn't.
I substantively agree with the points raised in this piece. As a senior software engineer I expect that the number of jobs will only grow in response to the advent of AI. Specifying a domain well, choosing the correct invariants, meeting regulatory and other burdens cannot be automated away with current technology. What I have noticed in my day to day affairs is that AI can produce locally convincing yet globally incomprehensible or self-defeating code. LLMs are interesting and have their uses but a grounded view (like what this article shares) of their capacities and limits is more reasonable. I mostly use them like a lossy search engine.
One piece of low hanging fruit for responsible use of coding tools is to have it write little pieces of code according to a template so you can save yourself some typing. Another is to use the same technique to write little python scripts that generate code according to some straightforward template, etc..
What these two things have in common is that you already know what you want to type, can visualize it in your head, and you can quickly get some dumb piece of code or an LLM to make it for you. In my last job, there were probably 1 million lines of code in our company code base that I was intimately familiar with, and from which I could draw good size chunks to copy and paste from and do a little massaging to get what I wanted.
These various chunks of code had already been through design review and code review so I knew the design was solid, and the only code review I would need is to make sure that I didn’t leave any bits of the old code behind that would cause a problem.
This would be fine, if the results were consistent and reliable. But every run is like a game of roulette.
You can build tests to catch failures, but you're either writing the tests yourself (which can be as complex as the actual code you are trying to create) or you're having the LLM write that, too.
That's the worst thing about this technology: the tension between the temptation to use it and the feeling of nausea you get deploying something you can't possibly check in detail.
Or even worse, having AI write scripts that launch emails, but don’t handle it properly when the email server starts rejecting emails. iThen you have a mess that you don’t know how to clean up.
But I did note that you should know what good code will look like, as well as how to test it.
Replace AI (vibe-coding, Agentic engineering) with offshoring, and the sandwich model and its impact remains fairly intact. Offshoring was very much teh same concept - software dev teams in India could develop code more cheaply than domestic SW engineers, so management decided to go in this direction. But this created all sorts of frictions, that made the process not much less costly, and certainly increased the issues of the elements outside teh coding. It also forced the development cycle back towards the waterfall method, rather than the iterative approach that was gaining mind share at the time.
I have been retired from developing and managing SW for over 2 decades, and it seems the development process has become more complex with more frameworks and languages added to dev ops. Can AI solve the complexity issue? I suspect not, as there are decisions to be made that increase the non-coding bottlenecks.
It seems to me that we have been here before, with the promises of AI repeating the same errors as offshoring.
I would certainly like to know whether vibe coding really democratizes throwaway app development or whether this is still thrown back to the SW team (jnr. coders?) for execution? I have a feeling this will not happen any more than other attempts have largely failed - visual programming and spreadsheet code beyond simple cell computations.
Just got off the phone with our daughter, who just had an important ai-coded in house tool screw something up. You’re right: ultimately, someone has to be able to roll up their sleeves and dig through logs of what went wrong, for example. A “working” tool can hit an anomalous condition, and totally fail. Then the vibe coders are suddenly helpless because they never understood how the app actually did its job.
I cannot express in words how much you have done for me to increase my sanity and clarity in how I understand AI and its effects.
Of course, your framework *might* turn out to be wrong, as is true for every model, but it is such a breath of fresh air and clear thinking in the discourse that was direly needed
People outside the field are often surprised to learn how programming is not the hardest part of the job. In larger tech organisations where dedicated roles like product manager handles the admin or client interaction responsibilities, ~50% programming.
In small to medium orgs where the software engineer wear multiple hats they are less exposed, ~20% programming. Most of harder parts are figuring out what the clients actually want, understand constraints like office politics, budgets, feasibility, anticipating and mitigating when the system fails, solving edge-cases, legal liability, taking responsibility when things go wrong, etc...
Software development is also, unlike other fields like law or accountancy, not purely a cost centre. Some software are related to cost centre (IT operations) but most software are also critical for the profit (unique selling point) of the business.
Amen. Coding is easy –– knowing what to code, knowing what it will cost, and planning for the effort of proving to other people that the resulting system is going to do all that it is supposed to do and none of that which it is not supposed to do are where the headaches come from.
I really like your summary of the bottlenecks (deciding & specifying, verifying, and understanding). This makes it clearer to me why humans work is not only required but also still difficult. Specifying is hard. Even if AI never makes mistakes, verification is required because the specification could be wrong and you'd only catch that by verifying. Building understanding is hard and necessary to have the information needed for specifying in the next iteration.
As a non-software engineer with an interest in this topic I appreciate your clear explanations. I had a suspicion that many of the “AI is taking software engineer jobs” claims were false or misleading but your explanation of what is happening behind the scenes helped clarify what is actually happening. This type of analysis needs to be more common in reporting of this topic rather than just acceptance of claims at face value.
On a separate topic, I think your point about entrepreneurship is interesting. Anecdotally, I have come across this in my own experiments with AI. For example, I was experimenting with streaming on Twitch recently. I’m not an artist and as a new streamer I didn’t think it wise to spend a lot of money on art assets so I used Canva and Gemini to create what I needed. While streaming I would come across artists looking for work and many lamented that AI was making it harder for them to find work because people could create what they needed themselves. I imagine this has less of an effect on established artists but I would be curious to see how AI is impacting these areas of small entrepreneurship. On the flip side I’m sure some artists have found ways to take advantage of it so it might go both ways.
The part that intriges me is that AI is best at generating the one layer only humans can sign off on. Eight times the code, but someone still has to understand it and stand behind it, and that reading is the slow part. So the tool floods the pipe with the exact thing it can't take responsibility for. That is probably why the gains feel muted and why supervising is what wears people out by 11am. You are not writing less, you are verifying more, and verifying was always the tiring part. Makes me wonder whether the honest metric isn't lines written or releases shipped but hours spent checking code you didn't write.
"Becoming an AI-native firm has become memetic. You restructure the org (read fire employees), you wire a frontier API through every workflow, and you report tokens consumed to the board as evidence of transformation, right up until the token bill becomes unbearable and you quietly hire people back. Tokens consumed is the lab’s revenue line, repackaged as your productivity metric. You are reading your transformation off somebody else’s invoice.
It gets worse because the party that printed the invoice is in the business of hollowing you out. Meter your inputs, make tokenmaxxing the measure of productivity, drain your decision traces, sell the frontier model back to you at a markup. The contracts now mostly promise that your prompts will never train the next model, and the promise is mostly kept. The lab learns from the aggregate anyway, which workflows the economy routes through it, where the failures cluster, which evals matter, and the next model arrives fitted to your industry, whether or not it ever saw your data. You pay in cash, and then again in exhaustion and dependence."
https://unfilteredramblings.substack.com/p/ai-companies-should-help-their-customers
I think this is an important corrective to the habit of treating software work as only code generation. In practice, a lot of the value sits in judgment: understanding business context, handling edge cases, managing change, and making accountable decisions when the tradeoffs are not obvious. That is also where governance shows up. For AI use in engineering, the question is less whether a model can produce output and more whether the organization can review, trace, and own the result. The human role does not disappear there, it becomes more explicit.