The Three Disciplines of AI Engineering

Every team "using AI" right now is running one of three workflows, usually without naming it. The main observation is really just on how, more specifically how much autonomy the AI receives before a human checks the work.

That single variable - autonomy before review - is what lets a team know exactly why they gave the AI the room they did, and what they expected back for it.

We call these the Three Disciplines: AI-augmented, outcome-led, and product-led. They are not maturity levels you climb once and stay at. They are modes you select per piece of work, the way you already select a testing strategy per piece of work. These disciplines were not designed on a whiteboard; they were extracted from a client engineering team we advised, where we tuned AI autonomy deliberately and watched what happened when the discipline matched the work - and when it didn't.

Where you enter depends on your role

Before the disciplines themselves, an observation that explains a lot of team friction: different roles have their first real AI experience in different disciplines, and each one lands where it does for the same reason - you enter at the boundary you can personally verify.

• A senior engineer enters AI-augmented. Their first session is pair-shaped by instinct: small asks, every line read, because reading every line is what they can do. The review boundary sits at the code, where their judgment lives.
• A junior engineer, or a technical-adjacent role, enters outcome-led. They cannot yet hold a line-level review boundary on unfamiliar patterns - but they can hold a testable outcome: acceptance criteria, a passing suite, a working endpoint. The AI fills the middle they cannot yet judge.
• A product manager enters product-led. Their first AI experience is feature-shaped: describe the behavior, get a working thing, evaluate it from the outside. There is no code review boundary available to them at all - product behavior is the only boundary they can hold.

None of these entries is wrong. Each one is the rational starting point for what that person can verify. The growth happens when the entry point stops being the only point. The senior engineer learns when line-by-line review is the right call and when it's overhead. The junior learns when passing tests is enough and when it isn't. The PM learns which features can run in product-mode and which ones need a tighter review boundary. Your entry discipline is where you happened to start - not the discipline the work in front of you requires. The rest of this piece is about choosing deliberately.

One framing note: this piece looks at the spectrum from the engineering-centric side - the review boundaries, the risk, the code. A product-centric view of the same spectrum exists, starting from behavior and working inward, and it deserves its own treatment.

The Baseline: AI-Augmented Engineering

This is the baseline. If you are unsure which discipline to use, use this one.

The mental model is pair programming. AI-augmented engineering is turn-based: the human defines a small ask, the AI proposes a change, the human reviews every line before continuing. Nothing moves forward without human eyes on it.

The cycle is context → ask → review → commit → repeat.

The AI has the least autonomy here. The human stays inside the implementation loop the entire time, not just at the end. The unit of completion is a branch commit - not a session, not a feature.

This is the right discipline when:

• engineering judgment is required continuously
• the codebase patterns are still being shaped
• the cost of a subtle implementation mistake is high
• the domain is unclear or the standards are still being discovered

Auth, payments, secrets, permission boundaries, new architectural patterns - this is where they live. The review boundary sits as close to the code as it can get, because failures in these areas rarely show up in tests. They show up in incident reports.

Before using it, these must be true:

• the human reviewer understands the code being changed
• each turn can be reviewed before the next turn begins
• the work can be split into small, turn-sized changes
• the human remains accountable for every line

That last condition is the defining one. In this discipline there is no such thing as "the AI wrote it." A human approved every line, so a human owns every line.

This is the safest discipline. When in doubt, start here - and graduate up deliberately, not by drift.

Graduating Up: Outcome-Led AI Engineering

Outcome-led AI engineering is closest to TDD.

In TDD you do not dictate the implementation. You define the test that proves the outcome, and the implementation earns its way in by passing it. Outcome-led works the same way: instead of reviewing every turn, the human defines a testable outcome, hands the AI coding guidelines and constraints, and lets it work toward that outcome with more autonomy. The human reviews at the session level, not at every intermediate step.

The AI owns more of the middle of the implementation loop. The unit of completion is a PR, not a branch commit.

This works when the outcome is clear, the validation path is strong, and the codebase already has patterns the AI can follow. "Add this endpoint with these tests" is outcome-led. "Figure out how auth should work" is not. The first is easy to complete by a machine, the second, well, the range of possible answers here can get wide.

Before using it, these must be true:

• the outcome can be tested
• acceptance criteria are explicit
• the AI has enough coding guidelines to stay inside local standards
• the codebase already has patterns the AI can follow
• the reviewer can evaluate the final PR without inspecting every intermediate turn

If any of those are not true, move the work back to AI-augmented, the safest of the approaches as you are able to maintain a closer reach to the code itself.

Highest Autonomy: Product-Led AI Engineering

Product-led AI engineering sits one level above outcome-led. It is closest to BDD.

Where TDD specifies how the code should behave, BDD specifies how the product should behave - and that shift in altitude is exactly the shift here. The human defines product behavior: what should exist, who it is for, what the user or business needs. The AI gets the most room to interpret how those outcomes get implemented, as long as the product behavior is achieved and broad technical constraints are respected.

The review lens widens accordingly: does the feature behave correctly, does it fit the product intent, does it stay within acceptable engineering boundaries. You are reviewing a feature, not a diff.

New features can start here when the implementation area is low-risk and the repo has strong automated checks. But product-led does not mean unbounded. Guardrails still exist - repo standards, tests, linters, and review. The autonomy is delegated, not surrendered.

Before using it, these must be true:

• the product behavior is clear
• the feature can be validated from the outside
• the repo has strong automated checks
• the AI has enough product context to avoid building the wrong thing
• the implementation area is not high-risk boundary code

Auth and payments should never be product-led. The cost of a subtle mistake is too high. That is not a claim that AI cannot help in those areas - it is a claim that the review boundary must move closer to the code. Same AI, different discipline.

Picking a Discipline

Pick based on the work, not the tool. The tooling is identical across all three disciplines; the discipline is a property of the task.

Two axes do most of the filtering: who the work faces, and what it costs when it is subtly wrong.

Risk dominates. A low-risk customer feature can start product-led. A high-risk internal change may still need AI-augmented review - "internal" is not a synonym for "safe," as anyone who has watched an internal billing script misfire can confirm. The matrix is a starting filter, not the final answer.

The underlying rule is simple enough to argue with:

The more autonomy you give the AI, the stronger the outcome definition and validation boundary must be. If the boundary is weak, pull the work back to a lower-autonomy discipline.

Autonomy is never free. It is purchased with validation.

Onboarding the LLM Like the Engineer It Is

None of this works until the codebase is ready for an LLM engineer.

The phrase "LLM engineer" here does not mean a human role. It means the LLM acting as an engineer, operated by a manager - and the manager is your human engineer.

So treat this like onboarding a new developer, because that is what it is. A new developer needs tooling knowledge, repository orientation, standards, known boundaries, and people to ask when they are stuck. An LLM needs the equivalent: context files, coding standards, examples, validation commands, and explicit boundaries.

You would not onboard a new developer and immediately put them on the payment processor. You would not treat a 30/60/90 plan as proof that every engineer can work on every part of the system. Engineering organizations already understand this with people - ladders, onboarding expectations, SDLC rules, and role-specific responsibilities exist for a reason. Even after onboarding, a junior engineer is likely not suited to work independently on payments, auth, or secrets.

The same applies to AI. The LLM is available on day one. That does not mean the codebase is ready to give it autonomy everywhere on day one. Availability and authorization are different things, and conflating them is how high-autonomy disciplines end up running inside high-risk code.

So yes, you need an LLM onboarding process - the same way you need a human onboarding process, per role, per seniority, per team, per area of the system.

And you already have your perfectly working human engineering onboarding process to use as the baseline.

Right?

...

Unfortunately, most of us don't. In twenty years of running engineering organizations, engineering onboarding is far from perfect - and if your company cannot onboard a human engineer well, what exactly is the plan for the LLM to be a good engineer on day one?

The human routes around your gaps: hallway chats that end up making decisions, relationships, a brain that fills in what the documentation never said. The LLM cannot. It cannot ask a clarifying question in a hallway, learn who owns what, or infer the unwritten rules. It only has the context, tooling, standards, and boundaries the team makes explicitly available to it.

Which produces a claim worth writing down: if your human onboarding path is unclear, your LLM onboarding path will be worse. The teams that struggle most with AI autonomy are usually the teams whose tribal knowledge never made it into the repo. The LLM did not create that gap. It just stopped letting anyone route around it.

The onboarding file governs behavior. The delivery system underneath it - local reproducibility, pipeline trust, deployment confidence - determines whether the onboarding can actually be acted on. That foundation is covered in Delivery Maturity for AI Enablement.

Quick Reference

Where to Start

Name the discipline before the work starts. Without a named discipline, each engineer improvises the autonomy level per task - and the riskiest code ends up running at whatever autonomy level happened to be in play that day. Naming it forces the conversation: what is the validation boundary here, and is it strong enough for the autonomy we are about to grant?

Default to AI-augmented. Graduate work to outcome-led when the preconditions hold. Reserve product-led for low-risk areas with strong automated checks. And before granting autonomy anywhere, do the onboarding work - the explicit context, standards, and boundaries an engineer with no hallway access needs.

This is the core of how we run AI Dev Team Enablement: onboarding a codebase for LLM engineers, selecting the discipline per piece of work, and measuring whether the autonomy you granted is being repaid. If you want to pressure-test where your team's work falls on the matrix, talk to an engineer - the one on the call is the one on the engagement.