How to read: the steps rise because AI takes on more execution at each phase — but the dashed line shows what really changes: in phase 1 you decide every line; in phase 3 you decide the system that the agent works on. That’s why engineering matters more, not less.
Learning path map
Detailed content
🧭 Where AI Really Fits in Engineering
The three phases (autocomplete, assistant, agent), what an agent needs to work, the engineer’s new role, and the tools’ real limitations.
Three stages of AI use in development. Phase 1 suggests lines as you type. Phase 2 answers questions, explains, and generates files on request. Phase 3 receives a task and executes it: reads the repository, edits files, runs commands and tests, analyzes errors, and tries to fix its own implementation.
Each phase requires a different kind of control. Applying phase 1 habits to a phase 3 agent is the source of most accidents: you’re reviewing one line while it has already changed eighteen files.
Autocomplete = suggestion · Assistant = on-demand response · Agent = execution with tools · Human responsibility shifts from the line to the system.
The list of an agent’s operational prerequisites: controlled access to the repository, context, documentation, tools, execution environment, memory, state, permissions, rules, tests, completion criteria, an interruption mechanism, and action logging.
When an agent “doesn’t work,” an item from this list is almost always missing—the model isn’t weak. This is the fastest diagnosis there is.
An agent is an operational component within a controlled system · Without a completion criterion, there is no completion · Without a record, there is no audit.
The shift in work: less typing every line, more specifying, assembling context, setting limits, designing verification, and judging results.
Anyone who keeps measuring productivity by lines written becomes invisible; anyone who structures the system AI works in multiplies the entire team.
Specify > type · Judging the result is a core skill · Speed without verification is accelerated risk.
Durable engineering knowledge—architecture, testing, operating systems, networks, APIs, security, databases, and infrastructure—used to evaluate what AI produced.
Without fundamentals, you won’t notice broken concurrency, security failures, modeling errors, fragile dependencies, or impacts on another system—and the code still passes the tests.
The more code is generated, the more valuable the ability to evaluate it becomes · Tools change; understanding of systems stays.
What AI still gets systematically wrong: it sees only the context you provided, doesn’t know unwritten rules, assumes how integrations behave when it can’t observe them, and confuses “test passed” with “intent fulfilled.”
Knowing where the tool fails is what determines which tasks you delegate today and which require human approval.
Missing context = assumption · Passing the test ≠ being correct · A known limit becomes a rule, not a surprise.
The way of working where the only input is the sentence of the moment: no specification, no tests, no limits, and no independent review.
It seems productive for a week, then costs you the following month: semantic duplication, inconsistencies between modules, and changes no one can review.
AI speeds up production and speeds up errors too · The differentiator isn't the prompt; it's the system around it.
📐 Spec-Driven Development
How to turn intent into a structured specification that reduces ambiguity—and that an agent can execute and verify.
A workflow where the specification comes before the code: intent → structured specification → plan → implementation → tests → verification.
The specification is the only artifact that defines what “right” means. Without it, the agent and human negotiate the definition of done along the way.
Spec ≠ generic text · The goal is to reduce ambiguity · Every spec ends with a verifiable criterion.
The standard outline: problem, objective, scope, out of scope, inputs, outputs, contracts, error conditions, constraints, acceptance criteria, tests, and definition of done.
Every missing field becomes a decision the agent makes on its own—usually the most generic one possible.
"Out of scope" prevents reckless refactoring · "Contracts" protect API consumers · "Definition of done" ends the discussion.
The task’s explicit boundaries, plus the list of observable conditions that prove it’s complete.
An agent without boundaries "improves" what wasn't requested; vague criteria return work that looks done but isn't.
Acceptance criteria are verifiable, not subjective · Negative scope matters as much as positive scope.
The part of the spec that defines formats, interfaces, and behaviors to preserve, as well as what should happen in each failure case.
Almost every serious production regression starts with an implicit contract that no one wrote down and the AI had no way to guess.
Error conditions are requirements · Compatibility is a contract · The unhappy path needs a spec just as much as the happy path.
The canonical pair: a one-line request versus the version that specifies payment methods, idempotency, states, webhooks, retries, logs, compatibility, sensitive data, tests, rollback, and merge blocking.
It’s the quickest exercise for calibrating the team: everyone immediately sees how many decisions were hidden in that short sentence.
Ambiguity doesn't disappear; someone decides it · The better the spec, the lower the chance of a decision that conflicts with the system.
The practice of translating each acceptance criterion into an automated test, closing the spec → test → implementation → verification loop.
A rule written in text is useful; the same rule as a test is reliable—and it’s what lets you delegate execution to the agent without losing control.
A test is the executable spec · Without a test, “done” is an opinion · The verifier is what authorizes autonomy.