Phase 0: The AI-Native Engineering Mindset · 40 min · Claude Code · Cursor · Git

From Implementer to Orchestrator

You own the spec, the harness, and the validation — the agent owns the typing.

Hiring signal: Interviewers for AI-native and applied AI engineer roles increasingly ask candidates to describe their role when an agent writes most of the code. Being able to name the five building blocks and show where you personally add value is a direct signal you've made the orchestrator shift, not just adopted a chatbot habit.

What you will learn

Explain the shift from implementer to orchestrator in your own words, using a concrete example from your own work
Name the five building blocks of AI-native engineering (agent, model, methodology, spec, context) and identify which ones a given team is missing
Diagnose why an unstructured, prompt-only workflow ('vibe coding') breaks down once a codebase reaches production scale
Run a readiness audit against a real repository and interpret the resulting score

Introduction

From Implementer to Orchestrator

Priya leads a four-person backend team at a Series B fintech. Eight months ago, she spent most of her day typing: reading a ticket, opening a file, writing the function, writing the test, committing. Today she spends most of her day somewhere else entirely — reviewing a spec she wrote that morning, watching Claude Code work through a multi-file refactor in a terminal pane, and reading a diff before it merges. The line count she personally typed this week is close to zero. The number of production incidents her team shipped is also close to zero, which is the part that matters.

Nothing about Priya's job title changed. Everything about what she actually does changed. That's the shift this course is built around, and it's worth being precise about what it is and isn't, because most of the public conversation about "AI coding" gets it wrong in one of two directions.

The first wrong direction says the job is basically the same, just faster — you still design the system, you just type less. That's not what happened to Priya's team. Her job now includes work that didn't exist two years ago: writing specifications an agent can build from, deciding which of four different coding agents to point at which kind of task, and designing the guardrails that keep an agent from doing something destructive at 2am when nobody's watching. None of that is "the same job, faster."

The second wrong direction says the job barely matters anymore — the AI does the engineering, humans just describe what they want. That's the "vibe coding" failure mode, and it's the reason Priya's team almost got fired from their previous employer's contract. Six months before she led this team, she was an IC on a project where everyone just prompted an agent and shipped whatever came out. It worked great for the first three weeks. By month two, nobody could explain why half the codebase behaved the way it did, a schema migration silently broke an internal API that three other teams depended on, and debugging a single incident took four days because there was no source of truth for what the system was supposed to do — only a pile of generated code and a Slack history of prompts. Thoughtworks calls this out directly: "throwing raw prompts at a chat interface and hoping for a usable result does not work in enterprise software development."

The role that's actually emerging

The accurate description is a role change, not a speed change. You own the specification, the harness, and the validation. The agent owns the typing. Thoughtworks' 2026 research frames this as five building blocks that every AI-native engineer has to get right, not just one of them:

Agent — which coding agent (terminal-based like Claude Code, IDE-native like Cursor, browser-based like v0) fits this task
Model — which underlying model to route to for this specific piece of work (a fast/cheap model for boilerplate, a frontier reasoning model for the gnarly architecture decision)
Methodology — the discipline that structures the work (spec-driven development, BMAD, or some other repeatable process — not "open chat, type prompt")
Specification — the durable artifact that describes what "done" means, independent of which agent or model builds it
Context — what the agent actually has in its window when it generates: which files, which rules, which prior decisions

Miss any one of these and the system degrades in a specific, predictable way. Skip the spec and you get silent drift — the code says one thing, nobody's documentation says another, and six months later no one can tell which is the intended behavior. Skip context engineering and the agent re-derives (or mis-derives) decisions your team already made last week. Skip methodology and you get what researchers call agent thrashing: the agent fixes one bug, introduces a new one, "fixes" that one, and loops for an hour while confidence in the system quietly erodes.

The orchestrator's actual job
An AI-native engineer's day is: write or refine a spec, choose the right agent and model for the task, assemble the context the agent needs, launch the generation, and validate the output against the spec — not against a vibe. If you can't point to the spec and the validation step in your last AI-assisted change, you were vibe coding, not orchestrating.

This isn't a demotion. It's a different, and in most ways harder, skill. Reading a diff critically and catching the subtle bug an agent introduced requires the same systems thinking as writing the code yourself — arguably more, because you're auditing someone else's (something else's) reasoning instead of your own. Writing a specification precise enough that an agent can't misinterpret it is a genuine engineering skill that most bootcamps never taught, because until recently nobody needed it.

Your teammate says: "I don't need to write specs — I just describe what I want in the chat and iterate until it looks right." Six weeks later, a new hire asks why the discount logic behaves differently in the checkout flow than in the admin refund flow. Nobody can explain it with confidence. What went wrong?

This is spec-code drift in its most common form: two pieces of code that should implement the same business rule quietly diverge because there was never a durable specification either could be checked against. "It looks right" in a chat session is not a source of truth — it evaporates the moment the conversation ends. A spec would have made the discount rule explicit and checkable in both places.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Why this survives the next tool, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.