We've Been Doing 'AI Engineering' for Twenty Years
These days, every few weeks I see another talk or framework launch presenting some “breakthrough in agent development”, most of which are techniques we have been using in production systems for decades, now rebranding as “AI Engineering.”
Before you read this as an anti-AI post: it’s the opposite. I’m more enthusiastic about this technology than anyone you’ll meet — I barely write code by hand anymore, I build with agents every day, and I think LLMs are the most exciting shift I’ve seen in a long career full of shifts. The parts that are genuinely new are thrilling. My problem isn’t with the technology. It’s with the narrative that the engineering around it fell out of the sky in 2023.
To be frank, most of what gets sold as new discipline for building with LLMs is software engineering best practice that has existed for twenty years. The people rediscovering it are either new or selling something.
The Recycled Technology Terms
Auth & security. API keys, OAuth, JWTs, least privilege, input sanitization. None of this was invented for LLMs. What is new is that feeding untrusted text into a powerful model creates fresh attack surfaces — prompt injection. Even then, prompt injection is, at its core, a subset of indirect injection. The answer is the same discipline we’ve always had: treat untrusted input as hostile, scope credentials tightly, sanitize at the boundary.
Retry & resilience. Rate limiting, Exponential backoff, circuit breakers, idempotency keys, dead letter queues. This is classic distributed systems material. An LLM is, operationally, a flaky and expensive microservice. Treat it like that.
Observability. Logging, tracing, metrics, dashboards, correlation IDs. We’ve had OpenTelemetry and the whole discipline since the microservices era. Now it’s called “agent tracing” because the call goes through an LLM instead of a REST endpoint. The span still has a start time and an end time.
Testing & evaluation. The discipline is recycled: regression suites, canary releases, A/B testing, drift monitoring, CI gates. Running evals on every prompt change is running test suites on every commit. But I’ll concede this is only half a rebrand — the measurement is genuinely new territory and hard. Tests assert against a spec; evals score fuzzy output against rubrics, baselines, or an LLM judge whose own judgment needs calibrating. That part came from ML evaluation, not software testing.
Orchestration & workflows. State machines, sagas, workflow engines, queues, task routers. Every “multi-agent orchestration framework” I’ve looked at is rediscovering this, usually with fewer guarantees.
API gateways. This one is the rebrand in its purest form: every API gateway vendor now sells an “LLM gateway” or “AI gateway,” and the feature list is the same product with the nouns changed. Rate limiting, key management, routing, caching, quotas, analytics — except request quotas became token budgets, response caching became semantic caching, and upstream load balancing became model fallback routing. To be fair, the adaptations aren’t zero-effort — token-based metering and cross-provider failover take real work — but the architecture diagram hasn’t changed in fifteen years: a proxy in front of an unreliable upstream, enforcing policy.
A lot of the “new” pain — hallucinations, non-determinism, token costs — is forcing teams to apply rigor they should have been applying all along. LLM exposed that you never had proper fallbacks, monitoring, caching or input validation in the first place.
The Rebranding Dictionary
If you want the pattern at a glance — and take this one with a grain of salt, it’s half joke, half truth, and every row is a little unfair on purpose:
| The 2026 term | What we used to call it |
|---|---|
| LLM gateway | API gateway |
| Agent memory | State management, session storage |
| Agent tracing | Distributed tracing |
| Guardrails | Input/output validation, DAST |
| Human-in-the-loop | Approval workflows |
| Agent handoff | Message routing |
| Tool calling | RPC, function dispatch |
| Structured outputs | Schema validation |
| Durable agent execution | Workflow engines, sagas |
| Prompt versioning | Version control |
Even the “Agent” Isn’t New
We talk about autonomous software entities that hold state, pass messages, and coordinate with each other as if they were a 2023 invention. The actor model described exactly that many years ago. Are you old enough to remember Erlang or Akka?
What actually changed is that the agent’s decision-making core is now an LLM instead of hand-written rules. That’s a real change — but it’s a change to the brain, not to the systems engineering around it. The plumbing an agent needs to survive production was designed decades ago.
Even the Protocols Are Recycled
MCP and A2A deserve their own entry, because we’ve shipped this idea before. More than once.
MCP is JSON-RPC plus capability discovery, openly modeled on the Language Server Protocol — the same M×N trick: one protocol, so every AI app doesn’t have to integrate every tool. The bigger promise, machine-readable service contracts that a client can discover and consume, is exactly what WSDL and UDDI sold us in 2001. A2A goes back even further: Agent Cards and task delegation between agents are the agent directories and Contract Net Protocol that multi-agent systems research built in the 80s and 90s. We designed protocols for software agents to discover and negotiate with each other before most of today’s AI engineers were born. Almost nobody used them.
But honestly, every earlier attempt died for the same reason. The consumer was dumb. A developer still had to read the WSDL and hand-write the glue code, so a standard interface description bought you very little. What changed isn’t the protocol design — it’s that the client can now read an interface description at runtime and figure out how to use it. MCP tool descriptions are prompts as much as schemas. Same idea, smarter consumer. That’s why MCP got more adoption in eighteen months than UDDI got in a decade. The old idea finally works — not because the protocol got smarter, but because the client did.
Even the Manifestos Are Recycled
The community is now reinventing its own literature. “12-Factor Agents” already exists — a genuinely useful set of principles for production LLM apps, modeled explicitly on Heroku’s 12-Factor App from 2011. Read the factors: own your control flow, keep agents small and focused, make them stateless reducers. That advice would have been at home in any microservices talk.
To be clear, I’m not mocking it — it’s good guidance, and the title is an honest admission of where the ideas come from. That’s exactly my point. When a field needs its own 12-factor manifesto, it’s telling you it has started being operational and production ready.
What’s Actually Hard
I’m not claiming everything is repackaging. Some things genuinely are different — and honestly, these are the most interesting problems I’ve worked on in years:
Evaluation is genuinely hard. Traditional software has specs — the output is right or it’s wrong. LLM output is fuzzy and context-dependent. Good evals need human baselines, LLM-as-judge (with its own flaws), or domain-specific metrics. This is a real evolution of testing, not just a rename.
Non-determinism at scale. Even at temperature zero, model behavior drifts over time as providers update and deprecate. Reasoning traces are verbose and painful to debug. Reproducing a failure is harder than replaying a request.
Tool use and planning loops. Agents calling tools in loops introduce failure modes that classic systems rarely hit: infinite loops, tool misuse, cascading errors across steps. The primitives — retry, state, timeouts — are old, but composing them around a probabilistic planner is not trivial.
Cost and latency as first-class constraints. Every call has a price tag and variable latency. Optimization becomes economic: caching, routing to smaller models, speculative execution, distillation. Most web engineers never had to think about per-request unit economics this way.
The safety surface. Prompt injection, jailbreaks, output filtering. Standard web apps never had an input channel that could talk the application layer into doing something else.
Why the Hype Cycle Exists
A few forces feed it:
- Newcomers are flooding in, many without backend or distributed systems experience. To them, a circuit breaker is a new idea.
- Venture capital loves novel-sounding categories. “Agent reliability platform” raises money; “we added retries” does not.
- Framework vendors need differentiation. “Our agent framework has built-in observability!” — so does every service mesh since 2017.
- We’ve seen this movie before. SOA came back as microservices. Key-value stores came back as “web scale” NoSQL. Rediscovery-and-rebrand is one of this industry’s oldest patterns — and this field can’t even hold its own name: prompt engineering became context engineering became agent engineering in under three years.
The Job Title Is Part of the Rebrand
We’ve watched this play out with titles, too. “DevOps” started as a culture, became a job title, and within a few years every sysadmin who learned Jenkins and cloud was a DevOps Engineer — then an SRE, then a Platform Engineer, with largely the same job description and a higher salary. “Data Scientist” got the “sexiest job of the 21st century” treatment, and half the job postings were business analyst roles or DBAs wearing a new badge.
“AI Engineer” is on the same trajectory: mostly backend/fullstack engineering plus one new class of unreliable, expensive API, priced as a brand-new profession. Nothing wrong with taking the raise — I would. Just don’t confuse a title change with a skills change. The engineers who thrive in these waves are the ones who had the fundamentals before the title existed, and they’ll still have them when the next title arrives.
The Bottom Line
The healthiest teams I see treat LLM calls like any other unreliable integration: wrap them in proper abstractions, add monitoring, have fallbacks, version prompts like code, test rigorously. The “AI engineer” chaining prompts in a framework without basic engineering hygiene is building fragile, expensive toys.
The people telling you it’s all brand new are usually selling something — or they’ve never shipped a complex system before.
And none of this reduces my excitement — it’s the source of it. We get to wrap decades of proven engineering around a genuinely new kind of capability, and that’s exactly why this is the best time to be building software that I can remember. The magic is real. The plumbing is old. Enjoy the first. Don’t buy the second twice.