AI Engineering: How AI Rewrote the Discipline of Building Software

In the space of about three years, the word “engineering” has been bolted onto eight new nouns: feature, prompt, harness, loop, ontological, fleet, context, forward-deployed. It’s tempting to read this as vocabulary inflation — the industry’s usual habit of renaming old jobs to sound new. It isn’t. Each of these terms marks a place in the stack where the old skillset quietly stopped being sufficient, and someone had to name the gap before they could close it.

Put them in order and they trace an actual shape: engineering’s center of gravity has moved from writing deterministic code to designing the conditions under which non-deterministic systems behave reliably. Feature engineering shaped raw data into signal. Prompt engineering shaped natural language into instruction. Harness engineering shaped the entire system around a model. Loop engineering shaped that system’s behavior over time. Ontological engineering shaped what the system is allowed to mean. Fleet engineering shaped how many of these systems coordinate at once. Agentic context engineering shaped how they get better without retraining. And forward deployed engineering shaped how all of it survives contact with a real enterprise.

None of these disciplines retired the one before it. They stacked.

The stack, at a glance

What follows is a walk up that stack, one layer at a time. Each section opens with the same three questions: what limitation made this discipline necessary, why it emerged when it did, and how it moved AI, LLM usage, and agentic systems forward — followed by the patterns worth adopting and the anti-patterns worth naming out loud.

1. Feature Engineering: Transforming Raw Data into Predictive Power

Feature engineering is the original discipline in this list, and it’s worth starting here precisely because everyone assumed the large language model era would kill it. It didn’t — it relocated it.

Classic feature engineering is the craft of turning raw, messy fields — timestamps, free text, transaction logs — into the derived variables a model can actually learn from: a recency score instead of a raw date, a rolling average instead of a stream of readings, a one-hot encoding instead of a categorical string. For twenty years this was where the real skill in predictive modeling lived, because the model itself (a gradient-boosted tree, a logistic regression) was comparatively dumb about structure. The engineer supplied the intelligence up front.

Two things changed. First, LLMs made the equivalent work on unstructured data — text, documents, images — largely automatic; an embedding model does in one forward pass what an NLP team used to do in a quarter. Second, and less discussed, a new category of model arrived to do the same thing for structured data: tabular foundation models. SAP’s roughly €1 billion commitment to acquire Prior Labs in May 2026 was a direct bet on this shift — Prior Labs’ TabPFN, pre-trained on tens of millions of synthetic tables, is marketed explicitly on the promise that you can feed it raw, messy rows — missing values, mixed types, multiple tables — and skip most of the manual feature-engineering step entirely, producing production-grade predictions in a single forward pass rather than the traditional cycle of encoding, tuning, and validating features by hand.

That doesn’t make the discipline obsolete; it moves the judgment call upstream. The engineer’s job shifts from constructing features to deciding which raw signals are worth exposing to the model at all, and to catching the cases — small data, causal reasoning, regulatory explainability — where a hand-built feature still beats an in-context one. Feature engineering was the first proof that “give the model better inputs” beats “give the model more parameters.” Every discipline below is a variation on that same idea, one layer removed from the data.

2. Prompt Engineering: English Is a New Programming Language

Prompt engineering is the second-oldest discipline here and the most misunderstood, mostly because it’s been declared dead more times than any term should survive. The core insight, popularized in the early LLM era, was simple and still holds: natural language became an interface you could program against. Precision in English — specifying format, constraints, examples, and reasoning steps — started producing the same kind of leverage that precision in syntax used to produce in a compiled language.

What’s changed is scope, not validity. Prompt engineering optimizes a single turn: the wording, structure, and examples inside one call to one model. That’s genuinely useful and still underrated — most quality gaps in production AI trace back to underspecified instructions, not model limitations. But a single well-crafted prompt was never going to be sufficient to run a multi-step, tool-using, long-horizon agent, and trying to make it do that job is exactly what pushed the field toward the next layer up.

The patterns that still separate a good prompt from a mediocre one haven’t changed much: be explicit rather than implicit, show the model what “good” looks like rather than describing it abstractly, ask for reasoning before the final answer on non-trivial tasks, and specify structure (format, length, tags) instead of hoping the model infers it. The anti-pattern is treating prompt engineering as the whole job — polishing the wording of an instruction while the actual failure lives in the missing tool, the absent memory, or the nonexistent stopping condition. That gap is precisely what the next discipline exists to close.

3. Harness Engineering: Designing Everything Around an AI Model

If prompt engineering optimizes one exchange, harness engineering designs everything that happens before and after it. The formulation that’s caught on across the industry in 2026 is blunt: Agent = Model + Harness. The model is the reasoning engine; the harness is the tools it can call, the memory it can read and write, the sandbox it executes in, the guardrails that constrain it, and the observability layer that lets a human see what it did and why. A raw model produces text. A harness is what turns that text-producer into something that can reliably finish a real task.

The metaphor the field settled on is equestrian: the model is the horse, the harness is the reins, saddle, and bit that channel that power somewhere useful, and the engineer is the rider. It’s a good metaphor because it captures the asymmetry practitioners keep rediscovering — the gap between what a model can do and what you actually see it do in production is usually a harness gap, not a model gap. Databricks has published benchmark results showing the same model scoring dramatically differently depending purely on harness design, and LangChain’s research reportedly moved a coding agent from the bottom third to the top of a public leaderboard by changing the harness alone, holding the model constant.

Concretely, a production harness typically bundles: the system instructions (the prompt-engineering layer, now just one component among several), tool definitions and their descriptions, a memory architecture (what persists across turns and sessions), execution sandboxing, verification and evaluation checks, cost and rate limits, and structured logging. The Thoughtworks framing that’s become common vocabulary splits this into guides — the feedforward controls that shape what the agent attempts — and sensors — the feedback controls that tell you, and it, whether it worked.

The anti-pattern is the inverse of the formula: treating the model as the product and the harness as an afterthought. It’s the fastest route from an impressive demo to a system that quietly falls apart under real load, because nothing was designed to catch the failure, throttle the cost, or stop the agent when it should stop. Which is, not coincidentally, the exact problem the next layer is named for.

4. Loop Engineering: Patterns for Agent Loops

Somewhere between a single prompt and an autonomous system sits the loop: reason, act, observe, decide whether to continue, repeat. Loop engineering is the discipline of designing that cycle deliberately instead of letting it emerge by accident. The consensus that’s formed across frontier labs and independent practitioners in 2026 is that the difference between a great agent and a mediocre one, given the same underlying model, is almost always the loop design, not the model.

Production loops tend to take a small number of recognizable shapes, and it’s worth being explicit about the vocabulary because it maps directly onto how you’d actually build one:

• Goal loops — the agent runs until a defined, checkable condition is true (tests pass, ticket resolved), rather than for a fixed number of turns.
• Interval loops — the agent wakes on a schedule (a heartbeat or a cron) to check state and act if needed, rather than waiting to be invoked.
• Event-driven loops — a webhook or system signal triggers the cycle, rather than a timer.
• Fan-out orchestration — a task is split across multiple parallel sub-agents or worktrees, then reconciled, instead of run serially.

Layered onto any of these shapes are the controls that keep them safe:

Two frontier labs published converging guidance on this within days of each other in mid-2026 — Anthropic’s write-up on getting started with loops and OpenAI’s on the Codex agent loop — which is a reasonable signal that this has moved from “interesting idea” to “load-bearing production practice” rather than a trend. The through-line in both: the intelligence increasingly comes from a clear specification and a verifiable stopping condition, not from a longer single session. A while-loop with good governance beats a clever one-shot prompt every time the task has more than a couple of steps.

The anti-pattern to hold onto above all others: a loop without a real, independent check on its own output is not autonomy, it’s an unsupervised process with a bigger blast radius.

5. Ontological Engineering: Patterns and Anti-Patterns for Machine-Readable Meaning

This is the layer most engineers underestimate until it breaks something expensive. Ontological engineering is the discipline of formally defining what the entities, relationships, and constraints in a domain actually are — machine-readably, not just as prose in a wiki — so that an AI agent reasoning over enterprise data isn’t silently guessing at meaning.

The failure mode it addresses is mundane and everywhere: two departments use the same word for different things. Finance’s “customer” might mean a billing entity; support’s “customer” might mean a named contact within that entity; sales’ “customer” might mean an open opportunity. A human resolves this ambiguity instantly from context. An LLM-based agent, absent an explicit definition, just picks whichever meaning it encountered most recently in its context window — confidently, fluently, and wrong. Analysts have been blunt about the stakes here: Gartner has projected that a large share of enterprise applications will feature task-specific AI agents by 2026, and every one of them needs some form of formal semantic grounding to avoid this exact failure. It’s also why ontology has re-entered enterprise architecture roadmaps that had quietly shelved it a decade ago — Microsoft’s Fabric IQ, announced in late 2025, and comparable “semantic layer” investments from other major platforms are commercial validation that ontology-first architecture, not just bigger context windows, is how the industry is choosing to fight hallucination in agentic systems.

Enterprise ontology engineering itself isn’t new — it descends from decades-old work like the Toronto Virtual Enterprise ontology and the Financial Industry Business Ontology, and from upper-ontology frameworks like the Basic Formal Ontology that give domain ontologies a shared foundation to align against. What’s new is applying that discipline specifically to constrain agent behavior, rather than only to integrate databases. A recent industry framework worth knowing — the Agentic Ontology of Work — proposes eight first-class entity types (agents, skills, intents, contexts, policies, memory, confidence, outcomes) purpose-built for this: not a data-integration ontology repurposed for agents, but one designed from the start to govern what an agent is allowed to assert and do.

The most interesting frontier here is ontology evolution — using an agent’s own execution experience to refine the ontology itself, closing the loop between what the agent learns in the field and what the formal model says is true. Done well, this is where ontological engineering and the self-improving systems discussed in Section 7 start to converge. Done badly — letting the model silently rewrite its own definitions with no review — it’s one of the more dangerous anti-patterns on this list, because it can drift the meaning of “risk” or “compliant” without anyone noticing until an audit.

6. Fleet Engineering: Agent Orchestration at Scale

A single well-harnessed, well-looped, ontology-grounded agent is a solved problem for a growing set of tasks. Fifty to two hundred of them running concurrently is a different discipline entirely, and it’s the one organizations are hitting a wall on right now. Teams that scaled from a handful of agents to a real fleet have consistently reported the same uncomfortable discovery: the tooling and habits that worked for five agents break, sometimes catastrophically, at fifty.

Fleet engineering borrows its vocabulary and its instinct for rigor from infrastructure and SRE practice, applied to autonomous software rather than servers. A fleet has a lifecycle, and each stage has a failure mode worth designing against:

• Deploy — rolling a new agent or agent version out gradually (blue-green or canary patterns) rather than all at once, so a bad prompt or tool change doesn’t take down every workflow simultaneously.
• Monitor — centralized visibility into what every agent in the fleet is doing, not just the ones a human happens to be watching.
• Coordinate — choosing deliberately between centralized orchestration (one controller assigns work) and decentralized orchestration (agents negotiate directly), rather than defaulting to whichever was easiest to prototype.
• Scale — adding or shedding agent capacity in response to load, the same way you’d autoscale any other compute resource.
• Retire — shutting an agent down cleanly: draining its in-flight tasks, revoking its credentials, archiving its final state. Skipping this step is how organizations end up with “ghost agents” — retired in name but still holding permissions and quietly consuming resources or posing a security exposure nobody’s tracking.

Governance is not a bolt-on at this scale; it’s the load-bearing wall. The practices that separate a fleet that scales from one that becomes “expensive chaos” include execution receipts documenting what every agent did and why, policy engines that define what’s allowed without a human in the loop versus what requires escalation, human checkpoints on high-stakes actions, and circuit breakers that can halt an agent — or a whole class of agents — the moment an anomaly pattern shows up. The organizational shift underneath all of this is real: new roles are emerging specifically around agent supervision, orchestration, and governance, because managing fifty autonomous systems is a different job than writing the first one.

The anti-pattern is scaling agent count before scaling the operating model that manages them — treating fleet growth as a deployment problem when it’s actually a governance and observability problem wearing a deployment problem’s clothes.

7. Agentic Context Engineering: Building Self-Improving AI Systems

Every layer so far assumes a human designs the system once and periodically revises it. Agentic Context Engineering (ACE) — the framework introduced by researchers at Stanford, SambaNova, and UC Berkeley in October 2025 — asks a different question: can the system get better at its job from its own execution history, without anyone fine-tuning the underlying model?

The mechanism is context, not weights. ACE treats the agent’s context window as a living “playbook” — a curated set of strategies, corrections, and domain-specific tactics that accumulates as the agent runs, rather than a static system prompt written once and left alone. Three roles divide the labor: a Generator that acts and produces a trace, a Reflector that examines what happened and extracts a lesson, and a Curator that decides how that lesson gets folded into the playbook. The detail that makes this work in practice, and the part worth understanding even at a summary level, is that the Curator makes small, incremental “delta” edits rather than asking the model to rewrite the whole playbook from scratch on every update. That choice exists specifically to counter something the original paper documented clearly: LLMs have a measurable brevity bias when asked to condense accumulated context, and that bias quietly deletes the very details that made the playbook useful — a failure mode the researchers named “context collapse.” Delta updates, plus embedding-based deduplication to stop the playbook from bloating with near-duplicate lessons, is how ACE avoids it.

The reported results are the reason this moved from research paper to production pattern within months: double-digit accuracy gains on agentic benchmarks and a sizeable reduction in adaptation latency compared to prior context-adaptation approaches, achieved purely by curating context better, without touching model weights. The work has continued past the original paper — subsequent follow-ups and at least one open-source implementation have extended the same core idea, and it’s been accepted at a top-tier machine learning venue in 2026, which is a reasonable signal this isn’t a one-off benchmark artifact.

Why this belongs on the list of engineering disciplines rather than research curiosities: context engineering has real operational advantages over fine-tuning for enterprise use. A playbook is interpretable — a human can read it and understand what the agent has “learned.” It can be updated at runtime without a retraining cycle. And it can be shared across different underlying models, which decouples an organization’s accumulated agent knowledge from any single vendor’s model version. That combination — cheap, interpretable, portable, incremental improvement — is precisely what “self-improving system” needs to mean in an enterprise context, as opposed to the more speculative version of that phrase.

The discipline is young enough that its anti-patterns are still being learned in public, but the clearest one already visible: treating the playbook as a black box that grows forever. A self-improving system without curation, deduplication, and periodic human review of what it’s “learned” isn’t learning — it’s accumulating, and accumulation without review is exactly how an ontology (Section 5) or a playbook quietly drifts wrong.

8. Forward Deployed Engineering: Shift Left to Accelerate Tangible Business Impact

Every layer above this one can be built correctly and still never generate a dollar of business impact, because the hardest problem in enterprise AI in 2026 isn’t model capability — it’s the last mile between a working system and a customer’s actual environment. Industry reporting puts the enterprise AI pilot failure rate at roughly 95%, and the recurring reason isn’t the model underperforming; it’s what practitioners call the integration wall: legacy SQL databases, OIDC/SAML authentication, data residency requirements, change-advisory boards, and the simple fact that getting production credentials from a customer’s security team can take longer than building the prototype did.

Forward Deployed Engineering is the discipline built specifically to break through that wall — by embedding senior engineers directly inside a customer’s environment, with production access, rather than shipping software remotely and hoping it lands. Palantir invented the role in 2008 (internally, its practitioners were called “Deltas”; by 2016 Palantir reportedly employed more Deltas than conventional software engineers), on the structural premise that genuinely complex software cannot be deployed remotely into a genuinely complex institution. What’s changed in 2026 is how completely the rest of the industry has converged on the same conclusion. OpenAI launched a multibillion-dollar “Deployment Company” built around this model in May 2026, acquiring an applied-AI consultancy for its existing deployment expertise in the process. Anthropic confirmed a parallel enterprise-services initiative days earlier. AWS committed a billion dollars to extend a Forward Deployed Engineering motion through its partner network, explicitly building what it calls a reusable delivery harness — a direct, and telling, borrowing of Section 3’s vocabulary at the deployment layer. Job postings for the role grew roughly eightfold year over year through early 2026 by some counts, which is as clean a signal of a real skills shortage as the industry produces.

The “shift left” framing in the subtitle of this section is deliberate and worth taking literally, not as a slogan. In traditional software delivery, shifting left means moving testing and quality checks earlier in the pipeline, before problems compound. Forward Deployed Engineering applies the same logic to business impact: instead of building a generalized platform in isolation and hoping it fits every customer later, you put an engineer with production access inside the customer’s actual constraints from day one — their real data, their real authentication, their real compliance boundary — and let those constraints shape the system while it’s still cheap to change. The alternative, discovering an OIDC edge case or a data-residency rule during a launch week, is the expensive version of the same lesson every engineering discipline in this article has already learned: the earlier you encounter the real constraint, the less it costs you.

Practically, the work pattern that’s converged across labs and vendors follows a consistent shape: structured discovery with customer stakeholders, prototyping directly against the customer’s real (not synthetic) data, an evaluation harness built for that specific use case, production deployment under the customer’s actual governance, and a feedback loop where field learnings shape the platform roadmap rather than staying trapped in one engagement. That last point is the organizational anti-pattern worth naming explicitly: wiring forward-deployed engineers into a sales or GTM function, where the incentive is billable hours on one customer, tends to produce a consulting shop rather than a product company. The pattern that compounds is reporting the function into engineering (or product), so that what one FDE learns solving customer A’s integration problem becomes a reusable capability for customers B through Z — turning the most expensive, least scalable part of enterprise AI into the part that compounds fastest.

Putting it together: how engineering is evolving

Line the eight up and a pattern falls out that’s easy to miss when each term is encountered separately, as a headline or a job title. The unit of engineering work has moved, layer by layer, away from the artifact a human writes and toward the conditions under which a non-deterministic system operates reliably:

• Feature and prompt engineering are still about the input — shaping data and language so a single model call produces good output.
• Harness and loop engineering are about the system and its behavior over time — what surrounds a model, and how it acts across many steps without a human at the keyboard.
• Ontological and fleet engineering are about scale and meaning — what happens when the system has to share a consistent understanding of the world, and when there isn’t just one of it.
• Agentic context engineering and forward deployed engineering are about compounding and reaching the real world — how the system gets better on its own, and how any of the above survives contact with an actual enterprise instead of a demo environment.

The throughline across all eight is the same discovery, rediscovered at every layer: the model is rarely the bottleneck. The bottleneck is the design work around it — the features you expose, the instructions you give, the harness you build, the loop you constrain, the meaning you formalize, the fleet you govern, the context you curate, and the customer environment you actually ship into. “Engineering,” in the AI-native sense these eight terms are groping toward, increasingly means designing the scaffolding around a powerful but unpredictable core — which is exactly the discipline every one of these terms, from feature engineering to forward deployed engineering, was independently invented to name.

It’s a reasonable bet that this list isn’t finished. If the pattern holds, the next named discipline will show up wherever the current stack is quietly failing without a name for it yet — and whoever names it first will just be the first person willing to admit the old skillset stopped being enough.

Next Steps: Deep Dive into Each Engineering Discipline

Now that you understand the evolution of engineering in AI building and adoption, explore each discipline in depth:

Further reading

• Harness Engineering: The Complete Guide (amux.io)
• What Is an AI Agent Harness? (Databricks)
• What Is Ontology? Definition, Components & AI Use Cases in 2026 (Atlan)
• Ontology-Constrained Neural Reasoning in Enterprise Agentic Systems (arXiv)
• Loop Engineering: The Four Patterns (Agent Shortlist)
• AI Agent Fleet Management: Complete Scaling Guide for 2026 (Fastio)
• Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models (arXiv)
• How to Build a Forward-Deployed Engineering Function: A 2026 Founder’s Playbook
• The Complete 2026 Guide to the Forward Deployed Engineer