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.
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.
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 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
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.
I like the decide-execute-deliver sandwich framing. Explains why the "% code written by AI" metric is disconnected from the jobs question. It also mirrors an argument Luis Garicano has made: that tasks aren't jobs, and automating a task within a job bundle doesn't eliminate the bundle.
I explored a related thread in The Last-Meter Economy: https://rajeshachanta.substack.com/p/the-doorman-and-deepseek arguing that the bottleneck in AI's economic impact isn't capability but the institutional and physical infrastructure between technology and deployment. Your sandwich model is the software-specific version of that argument.
Separately, the entrepreneurship point deserves more work. I see founders of early-stage gaming companies iterating dramatically faster because the execution cost has collapsed, but the judgment layer (what to build, what to ship, what to be accountable for) remains entirely human. That's AI lowering a big constraint for the provider — which is a different economic story from the displacement narrative, and a more interesting one.
Absolutely when you deepdive at the intersection of Software programming ( techniques, lifecycle..) and LLMs (AI form) . Rest is all dis/misinformation fueling the misbeLIEf. Why hype coding when there are 100+ bigger challenges to address for productivity, risk mitigation and accelerate GDP?
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.
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.
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 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
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.
I like the decide-execute-deliver sandwich framing. Explains why the "% code written by AI" metric is disconnected from the jobs question. It also mirrors an argument Luis Garicano has made: that tasks aren't jobs, and automating a task within a job bundle doesn't eliminate the bundle.
I explored a related thread in The Last-Meter Economy: https://rajeshachanta.substack.com/p/the-doorman-and-deepseek arguing that the bottleneck in AI's economic impact isn't capability but the institutional and physical infrastructure between technology and deployment. Your sandwich model is the software-specific version of that argument.
Separately, the entrepreneurship point deserves more work. I see founders of early-stage gaming companies iterating dramatically faster because the execution cost has collapsed, but the judgment layer (what to build, what to ship, what to be accountable for) remains entirely human. That's AI lowering a big constraint for the provider — which is a different economic story from the displacement narrative, and a more interesting one.
Absolutely when you deepdive at the intersection of Software programming ( techniques, lifecycle..) and LLMs (AI form) . Rest is all dis/misinformation fueling the misbeLIEf. Why hype coding when there are 100+ bigger challenges to address for productivity, risk mitigation and accelerate GDP?