icon/copy-url

favicon-32x32

logo-2x

IT Consulting | Outsourcing | Vietnam

*The hottest job of 2023 no longer exists. The person who leads Claude Code explains why.*

In early 2023, Anthropic posted a job opening that made headlines: [Prompt Engineer and Librarian, paying up to **$335,000** a year](https://www.efinancialcareers.com/news/2023/01/chat-gpt-banking). No code required. The job was writing instructions to an AI in plain English. Andrej Karpathy captured the moment in a single line: "The hottest new programming language is English."

In mid-2026, Boris Cherny, who leads Claude Code at Anthropic, described his own job very differently: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

Three years separate those two sentences. In between, the skill of working with AI went through five distinct stages, and each stage absorbed the one before it.

| Year | Practice | The skill |
|---|---|---|
| 2023 | Autocomplete | Accept or reject the suggestion |
| 2023-2024 | Prompt engineering | Craft the instruction |
| 2025 | Context engineering | Design everything the model sees |
| Early 2026 | Harness engineering | Scaffold a single agent run |
| Mid-2026 | Loop engineering | Build systems that run the agents |

We lived through this arc at INNOMIZE. Every engineer on our team uses AI daily, and the way they use it today looks nothing like 2023. Here's the arc, what we learned at each stage, and how to tell which stage your team is actually in.

 ![](https://res.cloudinary.com/innomizetech/image/upload/v1781245919/production/article_five_stages_timeline_8e87e8756a.webp) 

## Stage 1: Autocomplete (2023)

*Accept or reject the suggestion.*

The first stage barely felt like a new discipline. Copilot suggested the next line, you pressed tab or you didn't. The AI was a faster Stack Overflow living in your editor. You were still the author of every decision; the model just saved keystrokes.

It mattered because it normalized AI in the workflow. But nobody redesigned anything around it, and nothing about the engineering changed. The bottleneck stayed exactly where it had always been: knowing what to build.

## Stage 2: Prompt engineering (2023-2024)

*Craft the instruction.*

ChatGPT changed the interaction model. Instead of completing your code, AI generated whole solutions from a description. The skill became wording: few-shot examples, role-play framing ("you are an expert engineer"), chain-of-thought incantations, output format hacks. Whole prompt libraries circulated like spellbooks, and the people who could construct good ones commanded six figures.

We went through this phase like everyone else. Our engineers kept shared prompt collections and traded phrasings that seemed to work. But we kept hitting the same puzzle: the prompt that produced great results on one project produced garbage on another. The difference was never the wording. It was what the model knew about the system it was writing for. We didn't have a name for that observation yet.

Then the models got better. Context windows grew from 4K tokens to hundreds of thousands. Function calling and tool use arrived. The elaborate prompt gymnastics stopped mattering, because [the model's own capability replaced the tricks](https://percolator.substack.com/p/from-hype-to-obsolescence-the-prompt). [Search "prompt engineer" on a job board today and you find almost nothing](https://www.salesforceben.com/prompt-engineering-jobs-are-obsolete-in-2025-heres-why/).

What killed prompt engineering as a job was the thing it never addressed: a perfect prompt with the wrong information still produces the wrong answer.

## Stage 3: Context engineering (2025)

*Design everything the model sees.*

By mid-2025, the industry had a name for what actually mattered. Shopify CEO Tobi Lütke called it [context engineering: "the art of providing all the context for the task to be plausibly solvable by the LLM"](https://simonwillison.net/2025/Jun/27/context-engineering/). Karpathy endorsed the term within days, and it stuck.

The shift sounds subtle. It isn't. Prompt engineering asks "how do I phrase this?" Context engineering asks "what does the model need to see?" The first is a writing problem. The second is an information architecture problem: which files the agent reads, which conventions it knows, which architecture decisions it can reference, which past discussions explain why the system looks the way it does.

For our team, this was the turning point. We started feeding agents our architecture docs, ADRs, and coding standards alongside the task, and the output changed character. It stopped generating code *for* the system and started reasoning *as* the system. That experience changed how we value documentation: it stopped being overhead and became infrastructure that agents consume.

This is also where we saw the first real divide between teams. Not who had better prompts. Who had better context to give. Teams with documented standards got code that belonged. Teams that kept knowledge in people's heads got plausible code that didn't fit their system. The industry data backed up what we were seeing: as we covered in [The AI Reality Check](https://innomizetech.com/blog/the-ai-reality-check-what-2025-taught-us), **88%** of companies used AI in 2025 but only **6%** captured real value. The differentiator was never the tool.

Through 2025, the most important piece of context grew into its own methodology. If AI can generate any implementation in seconds, the scarce skill is describing precisely what should exist. The spec stopped being documentation and became the source artifact. AWS launched [Kiro](https://builder.aws.com/content/31u60Xzm1ymjMpCi5kTmFutCyiN/hands-on-project-using-kiro-spec-driven-development) in mid-2025, an IDE that forces a requirements, design, tasks sequence before any code is generated. GitHub released [Spec Kit](https://github.com/github/spec-kit). Spec-driven development became [a methodology serious people analyze](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) rather than a trend.

We adopted a spec gate before the tooling existed, and it remains the single highest-ROI change we've made. A spec takes **30 to 60 minutes** to write. A reviewer walks through it with the author in **15 minutes**. That conversation catches design issues that would cost hours to find in code review. PRs with specs verify in minutes. PRs without specs turn review into archaeology. We documented the spec gate in detail in [our AI code review breakdown](https://innomizetech.com/blog/ai-code-review-is-broken-the-4-layer-model-that-fixed-it-for-our-team).


## Stage 4: Harness engineering (early 2026)

*Scaffold a single agent run.*

Once agents could work for hours instead of seconds, the question changed again. Context engineering decides what the agent sees. The next problem was what keeps a long-running agent on track after it starts.

In February 2026, Karpathy, who coined "vibe coding" only a year earlier, [drew the professional line](https://karpathy.bearblog.dev/sequoia-ascent-2026/): vibe coding raises the floor, letting almost anyone build software. Agentic engineering raises the ceiling. Agents, in his words, are "fallible and stochastic, but extremely powerful", and the discipline is coordinating them to go faster without sacrificing your quality bar. Two months later, Martin Fowler's team gave the infrastructure its name: [harness engineering](https://martinfowler.com/articles/harness-engineering.html), the scaffolding around an agent run.

A harness has two kinds of controls. Feedforward controls steer the agent before it acts: AGENTS.md files, specs, architectural constraints, coding standards. Feedback controls observe after it acts: linters, type checkers, tests, review agents. The craft is wiring both so the agent self-corrects instead of drifting.

 ![](https://res.cloudinary.com/innomizetech/image/upload/v1781245919/production/article_harness_controls_4075aee7f6.webp) 

Our [4-layer review model](https://innomizetech.com/blog/ai-code-review-is-broken-the-4-layer-model-that-fixed-it-for-our-team) is, in this vocabulary, our feedback stack: CI catches mechanical errors, AI review catches pattern and consistency violations, humans catch intent and product problems. The harness framing also explains something we learned by accident: every time an agent made a mistake, the fix that lasted was never "prompt better". It was tightening the harness, adding the standard, the check, the test that makes that mistake impossible to repeat.

The hard-won lesson of this stage: the issues that slip through automated review almost never live in the diff. They live in a config file nobody opened, a doc that no longer matches the code, a requirement that changed in a ticket thread yesterday. A better model with the same narrow context inherits the same blind spots. Wider context beats a better model.

## Stage 5: Loop engineering (mid-2026)

*Build systems that run the agents.*

The newest stage goes one floor above the harness. A harness scaffolds one agent run. A loop is the system that triggers, orchestrates, and repeats those runs: it discovers work, hands tasks to agents, verifies results, persists state, and decides what happens next. [Addy Osmani named the practice loop engineering](https://addyosmani.com/blog/loop-engineering/), synthesizing what practitioners like Cherny and Peter Steinberger were already doing. Steinberger puts it bluntly: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

The metaphor that separates the stages: a harness is the cockpit instruments. A loop is the autopilot program.

The building blocks are concrete: scheduled automations that kick off agent work without a human initiating it, isolated worktrees so parallel agents don't collide, documented skills and conventions that survive across runs, connectors that let agents take real actions, and sub-agents that split the maker from the checker so the system doesn't grade its own homework. Plus a memory spine: external state in files and boards, so the loop remembers what conversation context forgets.

Whatever the label, the underlying unit of engineering is no longer the prompt, the context, or even the spec. It's the cycle:

Spec → generate → review → verify → learn.


 ![](https://res.cloudinary.com/innomizetech/image/upload/v1781245923/production/article_loop_cycle_fa0627d975.webp) 

> Humans own the loop. AI runs inside it.

We'll be honest about where we are: parts of our loop run automated today, and parts don't. AI owns mechanical review. We're building the connection between task context (tickets, specs, requirement history) and the review stage, so agents see beyond the diff instead of depending on a reviewer to surface that context manually. Humans still own spec judgment and final verification, and we think that's correct, not a limitation.

The practitioners pushing loops furthest say the same thing. Osmani's warnings are specific: comprehension debt, where code ships faster than anyone can understand it, and cognitive surrender, where engineers stop having opinions and accept whatever the loop returns. His closing advice: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

## The pattern across all five stages

Look at the progression and one direction is obvious. Every stage moved the engineer further from the keyboard and closer to the thinking.

Autocomplete saved keystrokes. Prompt engineering optimized the instruction. Context engineering optimized the information. Harness engineering optimized the run. Loop engineering optimizes the system that turns intent into verified software, again and again, without a human typing prompts in the middle.

The constant underneath all five: unclear thinking is expensive regardless of who writes the code. AI didn't change the requirement for clear problem definition. It removed every excuse for skipping it, because the typing was never the bottleneck. [Sonar's 2026 developer survey](https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/) shows where the unaddressed cost landed: **96%** of developers don't fully trust AI output, yet only **48%** verify it. The teams that close that gap are the ones operating at stages four and five. The teams that don't are producing more code than they can trust.

## Where is your team?

A quick self-assessment, one check per stage:

- If AI mostly completes lines while engineers work the old way, you're at stage one.
- If your engineers share prompt templates and tips for phrasing, you're at stage two.
- If you've invested in documentation, conventions, and specs that agents consume, you're at stage three.
- If standards, checks, and layered review keep a long-running agent on track without hand-holding, you're at stage four.
- If agents are triggered by your systems rather than your keystrokes, with verification built into the cycle, you're at stage five.

Most teams we talk to have stage-five tools and stage-two habits. They bought the agents. They didn't redesign the workflow around them. The result is familiar: [more output, more incidents, more senior time spent fixing what AI produced](https://itbrief.asia/story/ai-code-praised-in-review-but-faults-rise-in-production).

We made this argument before the agents arrived, in [AI Adoption Is a Workflow Decision, Not a Tool Decision](https://innomizetech.com/blog/ai-adoption-is-a-workflow-decision-not-a-tool-decision):

> The tool is 20% of the outcome. The workflow is 80%.

Three years and five stages in, the ratio hasn't changed. The stakes have. Every stage raised the volume of what AI produces, which means every stage raised the cost of running it inside a workflow that was never redesigned.

The short version of three years of evolution: AI made the code free. The engineering became everything around the code.

## Work with us

INNOMIZE helps teams move from prompt-era habits to loop-era discipline. We embed as technical owners, bring the spec-driven process, implement layered review, and build the context infrastructure that makes AI output trustworthy. If your team has the tools but not the process, [let's talk](https://innomizetech.com/contact).

large_blog-cover-prompt-to-loop-engineering.webp

medium_blog-cover-prompt-to-loop-engineering.webp

small_blog-cover-prompt-to-loop-engineering.webp

thumbnail_blog-cover-prompt-to-loop-engineering.webp

blog-cover-prompt-to-loop-engineering.webp

From Prompt Engineering to Loop Engineering: Three Years That Changed How We Build Software