AI-Native Development
Your next development skill is direction.
Use AI models across the development cycle, from understanding a repository to reviewing a tested, maintainable change.
Generating code is the easy part. The valuable skill is knowing what context to supply, which approach to choose, and how to decide whether a change deserves to ship. Develop a repeatable workflow around a real repository.
Your learning path.
01A model is a collaboratorWeek 1 · ≈4 hours+
Understand the strengths and failure modes of model-assisted work, and calibrate trust accordingly.
Objectives
- Describe why a model produces fluent, confident, wrong output.
- Choose between chat, inline completion and agent workflows for a given task.
- Select a model on task fit, cost and data constraints rather than on rank.
Topics
- Probabilistic output, plausible errors, and context limits
- The five shapes of plausible failure
- Chat, inline completion, and coding-agent workflows
- Choosing a model without chasing a leaderboard
- Data boundaries: what must never leave your machine
Concepts
Plausible failure
Output that is fluent, well-structured, confidently explained, and wrong — the dominant risk of assisted development.
Workflow shape
Whether the model completes, converses or acts. Each shape has a different review obligation.
Data boundary
The line customer data, secrets and private code may not cross — decided before the convenient paste.
Exercise
Compare two model workflows on the same small programming task.
Deliverable
A short comparison noting where each workflow helped, where it misled you, and what you would use next time.
02Read the repository firstWeek 1 · ≈4 hours+
Help a model understand the system it is changing — deliberately, not by hoping it infers.
Objectives
- Assemble a context pack that fits on one screen.
- Identify and state the invariants a change must not break.
- Decide what must not be shared, before sharing anything.
Topics
- Architecture maps, dependency boundaries, and conventions
- Selecting files and explaining what must stay true
- Why volume is not context
- Keeping the context pack in the repository, shared and current
- Secrets, private code, and data-sharing boundaries
Concepts
Context pack
The curated set of files, conventions and invariants supplied before a model is asked to change anything.
Invariant
Something that must remain true after the change — stated explicitly, because it cannot be inferred from code alone.
Convention debt
Six competing patterns in one repository. A model will faithfully reproduce whichever one it was shown.
Exercise
Build a repository context pack and identify three invariants.
Deliverable
A one-screen context.md committed to the repository, with invariants and out-of-scope areas stated.
Lesson material is being prepared for this module.
03Plan a small changeWeek 2 · ≈3 hours+
Make intent specific before asking for implementation — and reject a plan cheaply.
Objectives
- Turn an ambiguous request into scoped, independently reviewable steps.
- Require an assumptions list and read it as a diagnostic on your own brief.
- Reject a plan with a specific, actionable reason.
Topics
- Breaking work into independently reviewable steps
- Acceptance criteria and useful examples
- Requesting alternatives and the reasons they were dropped
- Clarification, assumptions, and technical trade-offs
- The cost asymmetry between rejecting a plan and rejecting a patch
Concepts
Change plan
The agreed approach and its trade-offs, reviewed before implementation begins and cheap to reject.
Assumption list
What the model had to decide because you did not say. The most useful output in the cycle.
Reviewable step
A change small enough that a reviewer can honestly hold all of it in their head at once.
Exercise
Turn an ambiguous feature request into a scoped change plan.
Deliverable
A change plan with alternatives considered, assumptions surfaced, and one documented rejection.
Lesson material is being prepared for this module.
04Implement and debugWeek 2 · ≈4 hours+
Run short iterations with explicit evidence rather than reassurance.
Objectives
- Reproduce a defect before proposing any fix.
- Keep diffs small enough to review honestly.
- Test competing hypotheses instead of accepting the first explanation.
Topics
- Patch review and controlling the size of changes
- Reproducing bugs before proposing fixes
- Interpreting logs and testing competing hypotheses
- Recognising a fluent explanation produced without execution
- Knowing when to discard the thread and restart
Concepts
Reproduction
The failing case that defines the bug. A fix is a reproduction that stops reproducing.
Hypothesis testing
Generating several candidate causes and disproving them, rather than adopting the first plausible story.
Context rot
The point at which a long thread carries more confusion than context, and restarting is cheaper than correcting.
Exercise
Fix a seeded bug with a regression test and an explanation.
Deliverable
A verified fix, a regression test derived from the requirement, and a short debugging notebook.
Lesson material is being prepared for this module.
05Review, test, and secureWeek 3 · ≈4 hours+
Apply the same standards you would to any contributor — and one or two more.
Objectives
- Review a generated change through six explicit lenses, in order.
- Distinguish tests that verify the requirement from tests that echo the diff.
- Identify the security and dependency risks assisted changes most often carry.
Topics
- Six review lenses: correctness, contract, security, tests, maintainability, blast radius
- Unit, integration, and behavior-focused test selection
- Input validation, authorization, and dependency risks
- Avoiding tests that merely repeat the implementation
- Reviewing what is absent as carefully as what is present
Concepts
Tautological test
A test derived from the implementation, so it agrees with the bug and proves nothing.
Blast radius
What breaks if this change is wrong, and how quickly it can be undone.
Silent contract break
A refactor that preserves every call site and quietly changes the meaning of one of them.
Exercise
Review an AI-generated change and document the defects you find.
Deliverable
A review dossier covering all six lenses, with findings ranked by blast radius.
Lesson material is being prepared for this module.
06Ship with confidenceWeek 3 · ≈4 hours+
Turn scattered good habits into a reusable development method your team can adopt.
Objectives
- Define where the human checkpoints sit and why each is defensible.
- Record decisions so a reviewer can audit what was accepted and rejected.
- Measure rework and review time, not output volume.
Topics
- Checkpoints for planning, implementation, and review
- Decision logs and auditable acceptance
- Release notes, rollback thinking, and evidence summaries
- Measuring review time, rework and change-failure rate
- Rolling a personal method out to a team without ceremony
Concepts
Decision log
A short record of what you accepted, what you rejected, and why — the artefact that makes a review defensible.
Rework rate
The proportion of shipped change that has to be revisited. The honest counterweight to throughput.
Ceremonial review
Approval given without scrutiny. Worse than no review, because it manufactures accountability.
Exercise
Deliver the capstone pull request and your personal AI workflow.
Deliverable
Capstone pull request, decision log, and a one-page personal development playbook.
Lesson material is being prepared for this module.
Who this is for +
- Software developers beginning to use AI in everyday work.
- Experienced engineers looking for a more systematic workflow.
- Technical leads who review AI-assisted changes.
Before you begin +
- Basic programming experience in any language.
- Comfort reading code, using Git, and running tests.
- An editor with an AI assistant or access to a chat model.
What you will learn +
- Select models using task difficulty, cost, latency, and data constraints.
- Build a concise context pack for an unfamiliar repository.
- Turn a request into a small, reviewable implementation plan.
- Use models to explore failures and improve test coverage.
- Review generated code for security, maintainability, and correctness.
- Build a personal workflow that includes explicit human checkpoints.
Applied assignments +
Repository context pack
An architecture summary, conventions, and preserved invariants.
Debugging notebook
A reproducible bug, competing hypotheses, and a verified fix.
Review dossier
A structured review of correctness, tests, and security.
Your capstone project +
Ship a small feature in an existing repository
Capstone brief +
Take a feature from request to review-ready patch. Submit a change plan, a focused implementation, relevant tests, and a decision log explaining what you accepted or rejected from the model.
Assessment +
A 60-minute practical scenario exam: select a model workflow, improve a context pack, review a patch, and justify the tests needed before release.
What you will produce +
- Repository context template
- Model-selection worksheet
- Code-review checklist
- Personal development playbook
The method, explained +
Kicker
THE METHOD, EXPLAINED
What does AI-native development mean?
AI-native development is not using a model occasionally. It is redesigning your working method around one — deciding what context to supply, where to place human checkpoints, and what evidence a change must carry before it ships.
- The first months of model-assisted work usually produce a speed-up in typing and no change in outcomes. The reason is that typing was never the constraint. Understanding an unfamiliar system, choosing an approach, and deciding whether a change is safe are the constraints, and none of them improve because completions arrive faster.
- What does change outcomes is treating the model as a collaborator with a specific and consistent profile: fast, broad, confident, and structurally unable to know what it was not told. That profile implies a method. Supply context deliberately rather than hoping it infers your conventions. Ask for a plan before an implementation. Keep changes small enough to review honestly. Require evidence — a failing test that now passes, a reproduction that no longer reproduces — rather than reassurance.
- The team-level version of the same idea is the one that decides whether this works: reviewers apply the same standard to generated code as to human code, the context that produces good results is written down and shared rather than re-discovered per developer, and the metric you watch is rework and review time, not lines produced.
Principles
Context is the real input
Output quality tracks the quality of the context pack far more than the choice of model. Invariants, conventions and boundaries have to be stated.
Plan, then implement
Ask for an approach and its trade-offs before any code. A plan is cheap to reject; a 600-line patch is not.
Keep the diff reviewable
A change you cannot review honestly is a change you are accepting on faith. Small, independently reviewable steps beat one confident sweep.
Demand evidence, not confidence
A fix is a reproduction that stops reproducing. Fluent explanation is not verification.
Know what must never leave
Secrets, customer data and private code have boundaries. Decide them before the convenient paste, not after.
Measure rework, not output
Velocity that produces review backlog and defect churn is not velocity. Track review time and change-failure rate alongside throughput.
Loop caption
The AI-assisted change cycle. The diamonds are the human checkpoints that make the speed safe.
When heading
Where model assistance is strongest — and weakest
When yes
- Explaining unfamiliar code, dependencies and call paths.
- Drafting tests, fixtures and boilerplate against a clear contract.
- Generating candidate hypotheses for a bug you can reproduce.
- Mechanical refactors, migrations and translations with a verifiable result.
- Reviewing your own work for the things you stopped seeing.
When no
- Decisions that depend on organisational context it has never been given.
- Architecture with long-lived consequences and competing stakeholders.
- Anything where a plausible-but-wrong answer is expensive and hard to detect.
- Security-critical logic accepted without independent review.
Misconceptions
“It writes the boring parts, so review matters less.”
Boring code fails in boring, expensive ways. Generated code carries the same review obligation as any contribution — arguably more, since no one has held the whole of it in their head.
“A bigger model would fix this.”
Most disappointing results are context failures, not capability failures. Fix the context pack before changing the model.
“Tests it wrote prove it works.”
Tests written from the same misunderstanding as the implementation agree with it perfectly. Derive tests from the requirement, not from the diff.
“Measuring this is impossible.”
Review time, rework rate, change-failure rate and defect escape rate are all measurable, and all more honest than counting accepted suggestions.
Course glossary +
Context pack
The curated set of files, conventions and invariants supplied to a model before it is asked to change anything.
Invariant
Something that must remain true after the change. Stated explicitly, because a model cannot infer what was never written down.
Change plan
The agreed approach and its trade-offs, reviewed before implementation begins and cheap to reject.
Decision log
A short record of what you accepted from the model, what you rejected, and why — the artefact that makes a review defensible.
Plausible failure
Output that is fluent, well-structured, confidently explained, and wrong. The dominant risk of assisted development.
Rework rate
The proportion of shipped change that has to be revisited. The honest counterweight to raw throughput.
Compare the approaches +
Every method is driven by something
The “-driven development” family is usually presented as a list of competing camps. It is more useful to read it as a single question asked repeatedly: which artefact is allowed to decide what gets built? Each method answers differently, and the answers compose more often than they compete.
| Method | What drives the work | Primary artefact | Strongest at | Costs you |
|---|---|---|---|---|
| VIBE — Vibe coding (no method) | An informal prompt and whatever comes back | Working code, no written intent | Throwaway prototypes and personal tools | No definition of correct; silent architectural drift |
| TDD — Test-Driven Development | A failing test written before the code | A unit test suite | Tight feedback, regression safety, design pressure on interfaces | Describes units well and product intent poorly |
| BDD — Behaviour-Driven Development | A shared example of behaviour in business language | Given–When–Then scenarios | A common language across product, QA and engineering | Scenario suites rot quickly without ownership |
| ATDD — Acceptance-Test-Driven Development | An acceptance criterion agreed before work starts | Automated acceptance tests | Customer-visible definition of done | Needs real discipline to stay automated and current |
| DDD — Domain-Driven Design | The domain model and its ubiquitous language | Bounded contexts and a shared model | Complex domains, integration boundaries, long-lived systems | Heavy for small systems; easy to cargo-cult |
| MDD — Model-Driven Development | A formal model that code is generated from | A UML or domain-specific-language model | Regulated, repetitive or multi-target generation | Tooling lock-in and painful round-tripping |
| CDD — Contract-First / API-First | An interface contract agreed before either side is built | An OpenAPI, protobuf or schema definition | Parallel work across teams; verifiable integration | Says nothing about behaviour behind the interface |
| TyDD — Type-Driven Development | The type system and its signatures | Types that make illegal states unrepresentable | Correctness by construction in expressive languages | Bounded by what your type system can actually say |
| DocDD — Documentation-Driven Development | The user-facing document written first | README, changelog or API documentation | Outside-in thinking; catching bad ergonomics early | Documentation drifts the moment attention moves on |
| SDD — Spec-Driven Development | A written specification of behaviour, constraints and non-goals | The specification plus a requirement-to-evidence matrix | Directing AI agents; keeping human judgment on what and why | Specification maintenance; over-specifying wastes effort |
Note
These are layers, not rivals. A mature spec-driven workflow typically states acceptance criteria in BDD-style examples, expresses interfaces as contracts, and verifies the result with tests that a TDD practitioner would recognise. What spec-driven development adds is the part the others predate: an artefact precise enough to hand to a non-human implementer, and a traceable answer to “how do we know it did what we asked?”
Closing heading
Where spec-driven development sits
Closing
- Ahead of TDD, not instead of it. TDD starts once you know what the unit should do; the specification is where that knowledge is decided, argued over and recorded.
- Above the contract. An API contract fixes the shape of an interface. The specification fixes what happens behind it, including what must never happen.
- Beside the domain model. Domain-driven design gives you the language to write a precise specification in. The specification is where that language gets used to settle a concrete behaviour.
- Against vibe coding — but only on work that will outlive the afternoon. The method earns its cost where correctness is contested, expensive or durable.
Teaching perspective +
This course uses a fictional AI teaching persona, not a real instructor.
Name
Noah Reed
Role
AI-assisted software development
Bio
Noah is the teaching persona for our AI-assisted development track. His course perspective focuses on working confidently in an existing codebase: understanding context, selecting tools, reviewing changes, and testing the result.
Approach
Use a model to accelerate your thinking, then use engineering evidence to check the work.