AI engineering doesn’t hold still. Every few months there’s a new term everyone’s supposed to already know, and half the internet starts panicking that they missed something. Nobody bothers walking you through how we actually got from one term to the next. So here’s the real chain: five shifts, and each one exists because the last one hit a wall.
1/ Prompt Engineering (2022–2023): Learning to Talk to a Genius With Amnesia
When ChatGPT showed up in November 2022, it felt like magic. No API keys, no integrations, no onboarding — you just typed like you would to a person and got something useful back. Except the model was oddly picky. Miss a math question? You forgot to tell it to think ‘step by step’. Wanted your summary in a specific format? Describing the format in words barely worked; you had to hand it two examples and let it copy the pattern.
That’s how prompt engineering became a thing. Chain-of-thought, ReAct, few-shot prompting, self-consistency — a whole vocabulary sprang up just for talking to these models correctly. For a hot minute it was the most talked about skill in tech, and people were literally selling prompts on marketplaces like they were stock tips.

Here’s what nobody wanted to say out loud: none of that was supposed to be necessary. The entire pitch was “talk to it like a person.” If you needed a secret handshake to get a good answer, you’d basically rebuilt the wall the product was supposed to tear down. So Anthropic, OpenAI, and Google went and fixed it at the source — they trained the models to just get better at reading intent. Prompt engineering didn’t die so much as get quietly absorbed into the model itself.
2/ Context Engineering (Early 2024): The Engine Needs a Car
Once the models got easier to talk to, companies started plugging them into actual business processes — a support agent that reads a ticket and pulls up order history, a quoting agent that reads a client brief and spits out pricing. And that’s where the next wall showed up: the model knows the whole internet. It knows nothing about your business.
It’s never seen your customer records, your internal wiki, your pricing sheet, your refund policy. Getting it useful meant feeding it that entire world — that’s context engineering, and it’s a genuinely hard problem for three reasons.
a/ The context window is finite, so you’re always choosing what makes the cut.
b/ The model is stateless — the second a session ends, it forgets everything, so anything worth keeping has to live somewhere else and get pulled back in later.
c/ And there’s context rot: pack a model’s window with noisy, irrelevant junk and it starts losing the plot, even when the answer you need is sitting right there in front of it.
This is the era that gave us serious RAG pipelines, agent memory systems, and observability tooling that actually did something. Back to the car: 2022 was the invention of the engine. Context engineering is what gave it a frame and a set of wheels. Basic, but it moved.

3/ Harness Engineering (Late 2025): The Engine Alone Was Never Going to Cut It
By late 2025, teams weren’t satisfied with “fetch context, answer a question” anymore — they were building agents that ran long, multi-step jobs, and context engineering alone couldn’t hold that weight.
A long-running agent needs a file system, or it loses its place halfway through. Some tasks — reconciling two enormous spreadsheets, say — make way more sense as a script than as a model chewing through thousands of rows in its head, which means the agent needs a sandbox to actually run that code somewhere safe. Understanding why an agent made a call after the fact means logging and observability. Keeping it away from your production database means access control. And the genuinely gnarly tasks needed sub-agents — smaller agents spun up with their own clean slate, each doing their piece and reporting back.

Everything that isn’t the model itself is the harness. People started defining an agent, plainly, as model plus harness. Context engineering didn’t go anywhere — it just became one department inside a much bigger org chart. This is the dashboard, the seatbelt, the mirrors. The car isn’t just functional anymore. It’s got an operating system.
4/ Loop Engineering (Early 2026): Taking the Human Out of the Driver’s Seat
Loop and graph engineering aren’t new technology. They’re what you build once the harness already exists and you start looking for ways to squeeze more out of it. Loop engineering solves one very specific annoyance: up until now, a person had to kick off every run and decide what happened next. A loop hands that job to the agent itself.
Strip away the buzzword and a loop is really just five parts:
1/ A trigger (a schedule, an event, a file landing somewhere),
2/ A goal the agent can check on its own,
3/ An optional checker to confirm the work is actually done,
4/ Somewhere to leave notes between runs since the agent forgets otherwise,
5/ A stop condition so it doesn’t burn tokens all night on something it can’t finish.

Say you’ve had your eye on a $250 pair of sneakers and your ceiling is $200. Set up a loop: check the price every two hours, log it to a file, ping you on Slack and stop the moment it drops under $200, and if the page breaks or the price disappears entirely, stop and flag it instead of guessing. That’s one prompt, and it contains all five ingredients. Loops are shockingly easy to spin up in something like Claude Code — just don’t leave one running forever, because they’re notorious for quietly eating tokens. Back to the car: this is self-driving. The vehicle already exists. Now you’re building the system that takes the driver out.
5/ Graph Engineering (Late 2026): Traffic Laws for a City Full of Agents
Graph engineering matters once you’ve got several agents and several loops all running at the same time and they need to stay out of each other’s way. It’s the coordination layer — a decision tree for how agents hand work off to each other instead of every one of them running blind.
Launch of tools such as GrokBot, New Claude Cowork (introduction of threads in Claude Projects), Codex Work, are all examples of AI tools trying to sell themselves as good Graph Engineering solutions.

Here’s a concrete version: building a research pipeline for an article on this exact topic. Instead of one long prompt, you sketch out a graph. Three researcher sub-agents run in parallel — one hunting down primary sources and key claims, one tracking every number back to where it came from, one collecting real examples worth using. Their findings merge into a single outline, with any disagreements flagged. A drafting agent writes from that outline. Then a separate critic agent — one that never saw the drafting happen, so it has no reason to go easy — checks the draft against a fixed rubric: every claim sourced, every number attributed, the brief actually answered. Fails a check, it goes back to the drafter with notes, up to twice, before the final version comes out the other end.
Each node is a piece of work. Each edge is a dependency — what has to happen before what. None of this makes any single agent smarter. It’s purely there so a bunch of agents can operate around each other without crashing, which is exactly what a road system does for cars: lanes, lights, right of way. It doesn’t upgrade the vehicle. It just keeps everyone from colliding.
The Takeaway
New AI jargons are going to keep showing up, two questions are worth keeping in your back pocket every time a new term lands: What problem did this come from? And what does it control that the last one didn’t? That’s the difference between a real new layer solving a real new problem, and someone repackaging an old idea to sound fresh on a conference slide.
Get freshly brewed hot takes on Product and Investing directly to your inbox!


Leave a Reply