The Enterprise AI Propagation Delay

You can't make decisions without a world model. The world model for software devs is being completely upended by agentic coding. What follows is my map of what's happening and my prediction on the best course of action for software developers struggling with these changes. Let's start with the facts.

Developers are getting destroyed. US software development postings on Indeed are 27.5% below February 2020, and people still looking say they've been searching longer than at any point in their careers. Among new job postings, 71% between May 2025 and May 2026 were senior roles, and 37% had AI in the title. If you aren't already senior or don't have a previous work history at a big-brand tech firm, you're going to feel completely shut out.

Coding agents are improving exponentially. Agents can now create very sophisticated software entirely on their own in an afternoon. The tools doing this are barely a year and a half old. If you're not using these tools daily, it may be tempting to dismiss this progress, so be careful here. The models are improving at software tasks faster than you can imagine and show no signs of slowing.

Enterprises aren't seeing AI gains. A 2026 CEO survey (4,454 CEOs across 95 countries) found 56% saw no cost or revenue improvement from AI at all, and only 30% saw any revenue lift. Gartner puts it at one in five AI investments producing any measurable return. The gains that do exist are concentrated: Magnificent Seven profit margins went from roughly 15% to 25%, while the rest of the S&P 500 sat near 10% the whole time.

The value is showing up in the companies building AI, not the ones buying it.

Put those three facts side by side, and they don't fit. If the tools are as good as the second fact says, the third shouldn't be true. And if enterprises aren't getting value from AI, then AI isn't doing the work of the engineers in the first fact. Not yet. Those engineers aren't being cut because companies captured the gains. They're being cut on the expectation that the gains are coming. Any explanation has to account for all three at once. Here's mine.

The Propagation Gap

My working theory is that the technology is real, but a gap exists between it and enterprises' ability to use it. Call it a propagation delay. The capability exists at the edge, but institutions that would pay for it haven't rewired themselves to absorb it yet.

This has happened before. Paul David's 1990 paper "The Dynamo and the Computer" traced factory electrification and found it took forty years from the first central power station for electrified factories to reach 50% diffusion. The delay wasn't the technology. Factories pulled out the steam engine but kept the same floor plan built around a central drive shaft. The gains came only when they redesigned the plant around what electricity made possible.

The redesign is the hard part, and it doesn't happen on its own. Someone had to understand both electricity and factories well enough to draw the new floor plan. Enterprises are in the same spot now. The models work. What they're missing is anyone who knows what the business looks like rebuilt around them.

Prototypes != Enterprise Deployments

Here is why the gap exists. The skill that rapidly builds working software is not the skill that builds an enterprise implementation.

You can build a huge piece of software without sophisticated architecture, because the code runs, or it doesn't. That's why vibe-coding works, and why it looks like magic on X every day.

Enterprise software has no such shortcut. To do its job, it needs ground truth, which means it isn't just the application. It's all the business data: what the company does, what it costs, how it functions. The model has to sit on top of that, retrieve from it, and apply that knowledge. There is no compile error for "retrieved the wrong policy document."

That is a different kind of work. You can ingest a hundred terabytes of business documents with the wrong embedding model, and it's useless. You can chunk it badly or waste money rerunning an embedding when a re-ranking would have sufficed.

This is also why the improvement curve from the second fact doesn't just eat this work next. Models get good fastest at tasks with a clear pass/fail signal, and code has one. Whether the model pulled the right policy for this company is a test nobody has written, and only people inside the business could write it.

Enterprise implementations are not vibe coded. It takes expertise, and enterprises will need it in spades the moment they wake up. The engineers who get flushed are the ones who thought the job was coding.

The ones who win will be the ones who leveled up now on enterprise implementation before the demand fully starts.

Engineering is not Entrepreneurship

Before I get to what I think the move is, I need to address an obvious answer. If agents can build a product in an afternoon and nobody is hiring, why look for a job at all?

Some people say software engineering is changing so that all engineers become entrepreneurs. Maybe there's some truth to that, but I don't think it's the whole story. Not everyone has that risk tolerance, and not everyone wants it. AI doesn't collapse the distinction between employer and employee.

I used to hold entrepreneurship in some sacred, lofty state and say it was always the better way. If you have the runway to miss ten times and hit on the eleventh, and the constitution for it, do it. But you will never be as good as someone hyper-specialized in depth in one domain. You hire those people, and that's the work they want to do. Different skills, different appetite.

The FDE Opportunity

Put the last three sections together, and you get a spec. The work that closes the gap is enterprise implementation, not prototyping. The person doing it has to be inside the customer's business, because that's where the ground truth lives. And for most engineers, it has to be a job, not a company.

That spec already has a name: the Forward Deployed Engineer (FDE). The role has the perfect overlap of characteristics: you're an employee, you're specialized, but you also bring a customer-facing perspective to zero in not on the task to be done, but on the value someone is actually pursuing. Mix that with enterprise implementation expertise, and you have what will be in demand soon.

It's still obscure. Almost every talk about FDEs traces back to Palantir, and half the people giving them open with "I came from Palantir." We are roughly a quarter generation from the invention of the role.

The funny part is that the demand curve for this kind of thing doesn't ramp. It goes from nearly zero to insane. That's what happened with model trainers: nobody knew who they were, and within two years they were fielding pay packages for $100 to $200 million-plus for a few.

The FDE curve is now bending the same way. Lightcast counts FDE postings up more than 1,000% from January through August 2026 versus the same period in 2025, and more than 4,600% versus 2023, against 13% growth for tech postings overall. Median advertised pay is above $188,000, versus roughly $145,000 for a traditional software engineer. The labs and hyperscalers are building whole organizations around it.

OpenAI launched a Deployment Company in May with a $4 billion investment for roughly 150 FDEs on day one. AWS committed $1 billion to its own FDE org in June, Microsoft put $2.5 billion into a 6,000-person "Frontier Company," and Anthropic formed a $1.5 billion enterprise-services venture too.

Notice who is writing those checks. It's the same companies where all the value is showing up. Their growth depends on enterprises absorbing what they sell, and the surveys say enterprises can't. So instead of waiting for buyers to redesign the plant, vendors are hiring people to do it for them inside the customer. They wouldn't spend billions on it if the deployments weren't working. The dynamo had nobody paying to speed it up. This does. That's why I don't think this delay takes forty years, and why demand for the role goes vertical instead of ramping.

The Strategy

So that's the map. And here's what I think the high-reward strategy is for current engineers who feel lost.

Survive long enough to bridge the gap. The labs tell the world engineers are over, then post hundreds of engineering roles. That message exists to drive their product and their token burn. Their hiring tells you what they actually believe, and what they're hiring is specialists in exactly this area.

Build specialized expertise now. Software engineering is not solved, but it is changing rapidly. More rapidly than it ever has. Demand for enterprise implementation is coming, and the best use of your time is to go hard and fast on upskilling now in preparation for it.

Don't doom yourself out of growth. The characteristics of people getting the smaller pool of available tech jobs now are unlikely to match the characteristics of people who get the tech jobs to come.

Go back to the first fact. Seventy-one percent senior, big-brand résumés only. Those are the old market's filters, applied by people who haven't figured out what the new job is yet.

Working at a big company doesn't mean you know how to implement inside an enterprise. A lot of those people were hired by managers with a quota to fill, on the logic that nobody gets fired for hiring ex-Meta. Do they actually possess generative enterprise deployment expertise? Or are they resting on the traditional HackerRank SWE evaluations that are now irrelevant? The current importance of résumé logos will be eclipsed by people who can effectively implement this tech inside real businesses to solve real problems at scale.

Accelerate.