> software development, as a “decide-execute-deliver sandwich”. AI compresses the “execute” layer — the middle of the sandwich — but the other two layers resist automation in a way that will not be overcome by capability improvements alone.

I really struggle to see why improved capabilities cannot deal with those other layers. I do not believe you have substantiated this claim about not being possible as capabilities improve.

> At one end of the pipeline, development teams need to decide what to build.

Developers are not the ones that do this largely. This role is far more on the side of "Product Owner". Sometimes your job covers both, but this is not the majority of the work and does not mostly require SE knowledge - some input usually.

> This layer is hard to automate because it requires thinking about user needs, market signals, organizational priorities, and in some cases regulatory constraints.

Hmm, these are language models that can talk through much of this already - but more importantly none of what is mentioned there requires software engineering. For parts that do (I'm sure someone would come to correct me if I said that there was none or seemed to suggest it is never ever ever relevant) this is a much smaller slice.

> As AI capabilities improve, the kinds of decisions that can be delegated to AI increase over time. But this does not make the “decide” layer thinner — once a decision can be delegated to AI, it is no longer a source of competitive advantage, and the value of human decision-making migrates upward. Software increases in complexity over time, so there is no ceiling to this process.

Now this is rather hidden but a huge leap in logic. The decide layer does get thinner for all the same projects, and then you simply assert that software will get more complex and so this cancels it all out.

A team of 5 may end up being able to ship what a team of 50 used to, and maybe now there are 10 teams outputting more - but is there not a clear limit to this? At some point do we not just need 45 fewer people? That there needs to be some engineers is not the same as needing anywhere near as many as we have.

For a time I think we will see increased output meaning more software, but that tails off as they get better.

> At the other end of the sandwich, human teams need to be accountable for what they deliver.

Why? And if we assume so, why does that need a software engineer?

> It is possible that some day in the future teams will ship mission-critical code without fully testing and understanding it,

You don't need to read code to test it, and people choose to ship products without fully understanding the code all the time. Literally any decision maker who is not a software engineer who knows the entire codebase does this. Companies fully ship systems that are far too complex for any single developer to even understand.

And much of software isn't mission critical. Or at least, if you want to say it is then the mission is low stakes.

> today’s AI is so unreliable that such haphazard practices would represent an existential threat to software teams and their customers.

I'd argue for a bunch of stuff this isn't true, and the whole point of the article is "never even if they get better" which is different.

> A central insight of AI as Normal Technology is that we can collectively choose to keep humans accountable through shared norms, law, and policy.

Sure, we can ban AI writing code, but will we? Is there a huge collective concern for all us high paid engineers being replaced by AI?