The abstraction layer above prompting is already here, and adoption is moving faster than most teams realize

The dominant mental model of AI-assisted engineering, one developer, one prompt, one response, is giving way to something structurally different. The new arrangement has AI systems generating their own instructions, chaining models of different costs and capabilities, and operating on tasks without a human in the loop at each step. This is not a refinement of prompting. It is a different abstraction layer sitting on top of it.

Fiona Fung, a product leader at Anthropic, describes the company’s recently launched routines feature as a concrete instance of that shift. Rather than a developer writing a prompt and waiting for a response, a routine allows the AI itself to generate the prompts, then act on them, including creating pull requests from feedback without manual intervention at each turn. Fung places the launch roughly one to two months before June 2026. The capability is new, but the direction it represents has been visible to practitioners for longer.

What makes the shift legible as a structural change rather than a feature launch is the broader adoption pattern. Jason Lemkin, tracking enterprise software closely, told Harry Stebbings that routing workflows across different AI models has become widespread practice across all but the smallest startups, and that this happened within the last 90 days. That is a fast-moving baseline. The teams that were still treating AI as a single-model, single-prompt tool at the start of that period are now the exception rather than the rule.

In a year maybe we won't. The models and the harnesses will get so good you won't have to do that anymore. Jason Lemkin

The economics of multi-model routing partly explain its rapid spread. Greg Isenberg describes the basic architecture: chain an expensive frontier model to plan the work, then hand execution to a cheaper model. The result, in his framing, is frontier-level quality at an affordable price. That tradeoff makes the architecture accessible to teams that cannot justify running every task through the most capable and most costly model available. Cost discipline and quality are no longer in direct tension once the orchestration layer handles the routing.

The design implication of all this is a change in where engineering judgment gets applied. When Fung describes routines, the key word is abstraction: the engineer no longer writes individual prompts but instead defines the conditions under which the system will generate and act on prompts autonomously. The skill required has shifted from turn-by-turn collaboration to something closer to systems architecture, specifying goals, boundaries, and feedback loops rather than inputs and outputs at each step.

The current moment, for all its apparent velocity, is itself transitional. Lemkin is direct about this: the models and harnesses are improving fast enough that within a year, manually correcting agent behavior will likely become unnecessary. Developers today still intervene, still course-correct, still sit close enough to the loop to catch errors. That proximity is a feature of the current generation of tooling, not a permanent condition. The teams building workflows now are building them for a world where that manual correction step exists. They are also, whether they intend to or not, building toward the world where it does not.

What changes when the correction step disappears is the nature of the engineering role itself. Writing prompts was a skill. Designing the system that generates and manages prompts is a different skill. The teams reorganizing around that discipline now are not just moving faster. They are practicing something that will be table stakes within a short horizon, and the distance between current practice and that horizon is smaller than most planning cycles account for.