The Engineer Who Stays

This January, a single line of code went around the software world:

It is a loop. It hands an AI coding agent the same instructions again and again, feeding every error back in until the software works. Its author, the open-source developer Geoff Huntley, told The Register it had been used to clone commercial products for roughly US$10 of compute an hour. His summary was blunt: “product features can now be cloned.”

That is the part of the story everyone talks about.

The other part is quieter. On 19 February, Anthropic retired Claude 3.7 Sonnet, a model it had released almost exactly a year earlier. Any application still calling it stopped getting answers. Nothing inside those applications had broken. The ground underneath them had moved.

Between those two moments sits a question I now hear from founders and operations leaders every week. If AI can build us a system to replace our off-the-shelf or legacy software, who keeps it working next year? Who changes it when a process changes, when the model is retired, when the technique it was built with goes out of fashion?

The industry has started to answer with a job title: the forward deployed engineer. How fast that role has spread tells you more about AI-built software than any demo does.

Building Got Cheap. Keeping Did Not.

Shift 01 · February 2025 to January 2026 · Vibe coding · Ralph loops

First, building collapsed in price

In February 2025, Andrej Karpathy gave a name to a new way of working. In “vibe coding”, he wrote, you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

Within a year, forgetting the code had become a technique. Huntley’s loop, nicknamed the Ralph Wiggum loop, runs an agent unattended until the result passes. Anthropic released a plugin for it. Boris Cherny, who created Claude Code, has said he uses it. Y Combinator startups reportedly build with it.

Martin Fowler, one of software’s most respected voices, drew the line early. Vibe coding suits disposable software used by its author or a small group who understand the risks. Anything more complex or widely used still needs real engineering. Because the models are non-deterministic, he noted, asking one to enhance a working system can break parts that should have stayed the same.

The prototype is no longer the expensive part. It is now the cheapest thing in the building.

Code that took a quarter to write now takes a weekend. Code that has to keep working still takes forever.

Shift 02 · 2023 to 2026 · Models · APIs · Techniques

Then, the ground started moving

Look at how quickly the craft itself has been renamed.

Prompt engineering was the hot job title of 2023. Vibe coding arrived in February 2025. By June, Shopify’s Tobi Lütke and Karpathy were arguing for “context engineering”, which Lütke described as “the art of providing all the context for the task to be plausibly solvable by the LLM.” The same month, McKinsey’s QuantumBlack published its blueprint for an “agentic AI mesh” of many cooperating agents. In December, the Model Context Protocol that lets agents reach tools moved to a new Linux Foundation body. Loops took over in January. By July 2026, practitioners were writing about “graph engineering”: “The agents fill the nodes. The engineering lives in the edges.”

Each label describes something real. Together they mean a system built in the best style of mid-2025 is, by today’s standards, a single-agent design waiting for a graph.

The models move faster still. Claude 3.5 Sonnet was released in June 2024 and retired in October 2025. Claude 3.7 Sonnet lasted a year. OpenAI’s Assistants API, launched in November 2023, was shut down on 26 August 2026, with developers moved to a different API. Anthropic commits to at least 60 days’ notice before it retires a public model. Sixty days is a long time for a vendor. It is not long for a mid-market company whose original builder has moved on.

When Anthropic launched a new enterprise services firm in May, its own announcement said Claude’s capabilities change monthly or even weekly, and that the systems built on it have to evolve as the models improve. That is the vendor telling you the maintenance schedule.

AI-written software does not age like traditional software. It ages at the speed of the models it depends on.

Your app was finished the day it shipped. The world it runs in was not.Kintoro

Shift 03 · 2025 to 2026 · GitClear · DORA · Veracode · METR · MIT

Finally, the bill arrived

None of this was a surprise to anyone who has run software for a living. An old rule of thumb, the 60/60 rule, says roughly 60% of a system’s lifetime cost is maintenance, and roughly 60% of that maintenance is enhancement: changes people asked for, not bugs. That was before AI made the first version cheap.

The early evidence suggests AI makes the second number harder, not easier.

GitClear found that in 2024, for the first time, copy-pasted code outnumbered code that was moved and reused. More duplication means more places to change when something shifts. Veracode’s chief technology officer put its finding plainly: the models “make the wrong choices nearly half the time, and it’s not improving.” METR’s study is the one I think about most. The gap between how productive AI feels and what it actually costs is exactly where maintenance bills hide.

The business data points the same way. MIT’s NANDA initiative reported in August 2025 that about 95% of enterprise generative AI pilots showed little or no measurable effect on profit. Tools bought from specialised vendors succeeded about 67% of the time. Internal builds succeeded only a third as often. “Almost everywhere we went,” said lead author Aditya Challapally, “enterprises were trying to build their own tool.” Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing rising costs, unclear value and weak risk controls.

None of these numbers say “don’t build with AI.” They say “don’t build with AI and walk away.”

The Role That Lives Inside the Problem

The forward deployed engineer is not new. Palantir built its business on the role, which it calls a Delta, and drew the distinction cleanly. Its product engineers, the Devs, focus on “one capability, many customers.” Its Deltas focus on “one customer, many capabilities.” They sit inside the customer’s operation, learn how the work is really done, and build on the platform until the outcome is reached. As one Delta put it, the job involves “significantly more engineering and technical work than a consultant.” When a customer needs something the product cannot do, good Deltas push the fix back into the core product.

Then generative AI made every company a potential Palantir customer, and the role exploded.

This year the frontier labs went further. On 4 May, Anthropic, Blackstone, Hellman & Friedman and Goldman Sachs announced a new firm to bring Claude into mid-size companies. Goldman’s Marc Nachmann described the aim as “democratizing access to forward-deployed engineers.” A week later, OpenAI launched the OpenAI Deployment Company with more than US$4 billion of backing and bought the consultancy Tomoro to start with about 150 forward deployed engineers. OpenAI said the unit would give customers “systems designed to improve as new models, tools, and deployment patterns come online.”

The companies that make the models have concluded that a model is not a product until someone stays to make it work.

It is not a universal answer. Writing in Forbes in April, Peter Bendor-Samuel argued that forward deployed engineers earn their keep in fast-changing, AI-driven environments, but can add risk to stable systems with strict governance and release processes. Analysts at Constellation Research expect buyers to see lab-owned services arms as a lock-in risk. Both points matter, and I come back to them below.

The labs stopped selling software alone. They are selling the people who stay.

Building Yourself on the FDE Path

For engineers, analysts and operations people, this is the most interesting career shift of the AI era. The job sits between three older ones: the software engineer, the business analyst and the consultant. It rewards people who can do all three badly enough to need the others, and well enough to finish the work.

The postings list the obvious skills. Python appears in 66% of them, AI agents in 35% and experience with large language models in 31%. The skills that decide whether a system is still working in eighteen months are harder to list. In my experience they come down to five habits:

The last habit is the one that separates a forward deployed engineer from a contractor with a better title. A contractor delivers a build. A forward deployed engineer leaves behind a system that the business, the platform and the next engineer can all keep moving.

The real output of a forward deployed engineer is not code. It is a system that keeps fitting the business as both of them change.

Getting the Benefit Without the Treadmill

Which brings us to the question in every boardroom that has watched an AI demo: how do we get the benefits of AI without signing up for constant tweaking and upgrades?

The honest answer is that you cannot remove the tweaking. The models will keep changing, and so will your processes. What you can decide is who carries that work, and how much of your system it is allowed to touch.

The pattern I trust separates the system into layers that change at different speeds.

At the centre sits the system of record: customers, orders, money, permissions and approvals. It should be deterministic and change slowly, because a mistake there commits the business. Around it sits a layer the business owns: its rules written as data, the context its agents read, and the test cases that prove a change is safe. At the edge sit the agents, prompts and models. They should be cheap to replace, because they will be replaced.

McKinsey’s mesh guidance lands in the same place. Keep prompts, tools, instructions and data separate from any single vendor’s platform. Give every agent the least access it needs. Re-test agent pipelines on every deployment, especially when the underlying model changes.

Before you commission an AI-built replacement for any core system, ask five questions:

If the answer to any of them is “the person who built it,” you have bought a project, not a system.

There are three workable routes. Own it, by building forward deployed capability in-house, which makes sense when the software is your competitive edge. Rent it, from a services firm or a lab’s deployment arm, with a clear eye on lock-in. Or buy a platform that has the forward deployed model built in: a vendor that absorbs model and technique changes across many customers while your people keep the decisions. Most growing companies will use a mix. The mistake is choosing none of them and assuming the build will look after itself.

The question is no longer whether AI can build your software. It is who will keep it fitting your business as everything underneath it changes.The central question

Software Is No Longer a Project

For thirty years, business software was something you bought or built, then lived with. AI has changed the first half of that sentence beyond recognition. It has made the second half harder.

The forward deployed engineer is the industry admitting it. The most valuable software now comes with someone, or something, that stays: watching the models, learning the process, rewriting the context and proving each change is safe before it reaches the people who depend on it.

At Kintoro, that principle shapes how we build piMonk: AI agents handle the routine work and absorb the constant change at the edge, while people keep control of the decisions that commit the business.

The most valuable engineer of the AI era is not the one who builds fastest. It is the one who stays.

Every AI system will drift. Plan who stays.

Replacing software with AI? Decide who will tend it before you decide who will build it.

Kintoro builds piMonk, a suite of business applications for growing mid-market companies. Our approach is to let AI agents handle routine work while people retain control of decisions that commit the business. Keeping those agents current as models and techniques change is part of that responsibility. Learn more at kintoro.com.

Editorial note: This draft is built from the dated public sources listed above. The brief described the shift from vibe coding to agentic meshes as ten months; the dated sources put it closer to eighteen months (February 2025 to July 2026), so the article uses the dated version. Confirm the About Kintoro line about keeping agents current, and recheck figures before publishing.