AI-Assisted Software Development

An introduction to the terminal — the text-based interface AI agents use to navigate your file system, install packages, and make network requests. You will run five essential commands hands-on: `mkdir`, `cd`, `touch`, `ls`, and `curl`. After this lesson, you will be comfortable opening a terminal, creating folders and files, listing their contents, and making HTTP requests from the command line — the same operations you will watch AI agents perform throughout the rest of the course.

A hands-on tour of the Integrated Development Environment: the tool that combines a file explorer, a code editor, and a terminal in one window. You will see how IDEs evolved from simple text editors to AI-integrated platforms, and create files both through the graphical UI and through the terminal. After this lesson, you will know how to navigate an IDE, understand its three main panels, and recognize that the terminal and the UI are two equally valid paths to the same file system.

Introduces AI coding assistants — how they live inside your IDE, why they behave differently from deterministic tools like the terminal, and how to send your first natural language instructions. You will open the AI chat panel, ask it a question, and watch it create a real file on your file system from a single sentence. After this lesson, you will understand what AI assistants can do, why their variability is by design rather than a bug, and how to locate and use one in your IDE.

Explores the AI's ability to run terminal commands on your behalf — listing files, installing packages, running project scripts, and checking your development environment — all through the chat interface. You will see the act-observe-respond loop that makes agentic behavior useful, and learn why you should always read the confirmation prompt before approving a command. After this lesson, you will know how to delegate terminal work to the AI, interpret what it reports back, and keep yourself safe by treating every approval as a checkpoint.

Covers the five core Git concepts every developer needs: repository, branch, commit, isolation, and merge. Following a live demo from `git init` through two branches, independent changes, and a final merge into main, you will see branch isolation in action — watching files change as you switch between branches. After this lesson, you will be able to set up a Git repository, work safely on feature branches without touching the stable codebase, commit meaningful snapshots of your work, and merge changes back — a foundation that pairs directly with AI-assisted workflows.

Demonstrates the simplest possible way to use AI: paste a problem, send it, and review what comes back. Using a classic duplicate-detection algorithm as the example, you will send a raw prompt to an AI tool and see a complete working solution appear in seconds. After this lesson, you will understand what the naive approach is, when it is genuinely useful (learning, prototyping, standalone problems), and where its limits begin — which sets the stage for every improvement that follows.

Takes the same naive approach from the previous lesson and moves it into the IDE. You will paste the same problem into an AI copilot, but this time the solution lands directly in a project file — no copy-pasting required. After this lesson, you will know how to use an AI assistant inside your IDE, understand what makes it different from a standalone chat tool, and recognise that file-level action is the beginning of genuinely agentic behaviour.

Introduces a critical habit: writing your prompt in a markdown file instead of typing it into the chat box. You will create a `task.md` file with a structured problem description, reference it from the AI chat panel with a single short message, and watch the agent produce a solution from the file's content. After this lesson, you will understand the difference between a prompt and context, know how to build persistent and reusable task files, and have the foundational habit of professional AI-assisted work.

Upgrades the markdown task file into a spec — a single document that instructs the AI to deliver both working code and a test suite. Adding one sentence to the task file is enough: the agent initialises a Node project, writes multiple solution approaches, runs and fixes the tests, and produces documentation from that single instruction. After this lesson, you will know how to write a spec that drives full deliverable quality, and understand why regression tests are a standard expectation in professional software work.

Solves the key limitation of the spec-driven approach: the AI rebuilding from scratch every time. Using Git branches and a second spec file that references the first, you will direct the AI to add a test suite to an existing codebase — making only the changes needed, leaving every existing file intact. After this lesson, you will be able to build on real code incrementally, use spec hierarchies to manage dependencies between tasks, and apply the branch-per-change pattern that keeps AI-assisted work clean and auditable.

Reframes what success means for a software project: working code is necessary but not sufficient — the real goal is a product that genuinely solves the problem it was built for. It argues that in the AI era, developers increasingly act as technical leads who set direction, define requirements, and review output rather than just writing code. After this lesson, you will understand why a development process is a skill multiplier, and how structure is what turns AI assistance from fast-but-random into fast-and-right.

Walks through the four stages shared by virtually every software development methodology — requirements, design, implementation, and testing — and explains how AI tools fit into each one. You will see why the process is iterative rather than linear, and how to calibrate the right amount of upfront work versus the risk of analysis paralysis. After this lesson, you will have a transferable mental model you can apply to any team, methodology, or project context, and know exactly what kind of AI help is most useful at each stage.

Sets up the project foundation from scratch: a project folder, a Git repository on `main`, a `docs` directory for all documentation, and a `.gitignore` that keeps documentation and code cleanly separated. You will also see why clean workspace structure makes AI assistance more precise — when you can point the AI at just the right folder, its context is sharper. After this lesson, you will be able to set up a versioned, well-organised workspace that supports disciplined AI-assisted development from the very first commit.

Creates the first artifact of the development process: a product vision document that answers what we're building, who it's for, and what makes it worth building. You will seed a markdown file with your intent, ask the AI to develop it into a complete vision document, and review the output — understanding that the direction is yours and the AI is the collaborator. After this lesson, you will know how to create a concise, purposeful vision document that anchors every decision downstream and gives any AI session instant context about the project.

Explains what makes a requirement effective — measurable, unambiguous, testable, traceable, unique, and complete — and what makes one useless. Through direct comparison of a precise requirement and a vague one, you will build the skill of evaluating requirement quality before any code is written. After this lesson, you will be able to identify weak requirements, write better ones, and apply the quality criteria that keep AI-generated implementation aligned with what you actually intended to build.

Establishes the structure for a Product Requirements Document, including the key technique of listing referenced documents with file paths at the top — giving the AI a self-contained document it can fully trace. You will create `PRD.md`, set up the Referenced Documents section pointing to the product vision, and write the prompt the AI will execute. After this lesson, you will know how to build structured documents that give AI assistants complete context without pasting anything into the chat, and how this pattern scales as the project grows.

Executes the PRD prompt from the previous lesson using a single short chat message — directing the AI to find and run the prompt already written inside the document. The AI reads the product vision through the reference, generates over a hundred organized requirements across multiple sections, and writes them directly into the PRD file. After this lesson, you will be able to trigger a complete structured AI generation task from a document reference, and you will have a working PRD to review, critique, and refine.

Teaches the two core activities of software design: decomposition (identifying the major components of the system and their responsibilities) and connections (defining how those components interact through interfaces). Using both a vehicle and the Todo app as concrete examples, it builds intuition for why the wiring between components is where the hardest bugs originate. After this lesson, you will be able to decompose any software system into well-defined components, reason about the data flow between them, and validate that a design fully addresses the requirements before writing a single line of code.

Applies the design theory to produce an actual high-level design document using the AI. You will create the design file with a referenced PRD and a detailed prompt, watch the AI produce a three-tier architecture (client, application, data) with defined component connections and an ASCII diagram, and see it validate the design against every PRD requirement before writing the output to the file. After this lesson, you will be able to produce a complete, validated, AI-generated high-level design document using the same document-driven pattern you used for the PRD.

Shows how to use an independent AI review session to stress-test the design before implementation begins — catching gaps while they are still cheap to fix. The AI returns a structured assessment with prioritised findings; you select the most critical one (a missing testing strategy), and the AI adds it directly to the design document. After this lesson, you will know how to run a fast AI-powered design review, apply human judgment to prioritise findings, close critical gaps in a single follow-up prompt, and understand the complementary role of experienced human reviewers.

Introduces the planning phase as the bridge between a validated design and working code, explaining why skipping it leads to integration problems, tasks started in the wrong order, and blocked developers. It also frames why planning is especially important for AI-assisted work: a scoped, well-described task is a precise AI prompt, while "build the whole app" is not. After this lesson, you will understand what the planning section produces, why it multiplies implementation speed, and what the next two lessons will cover.

Defines what belongs in a good implementation plan: tasks that are scoped, buildable, and verifiable; dependencies that are made explicit; and acceptance criteria that define done for each task. Through the Todo app's task service as a concrete example, you will see how component-level decomposition becomes a list of session-sized tasks ordered by dependency. After this lesson, you will be able to evaluate whether a plan is ready to build from, write useful task descriptions, and understand why the plan effectively becomes the script for every AI implementation session.

Applies the same document-driven generation pattern to produce a first-draft implementation plan. You will create `Implementation-Plan.md` with referenced PRD and design documents, write the structured prompt inside it, trigger the AI to fill it in, and verify that the output has the correct shape — referenced documents intact, approach summary present, tasks ordered and grouped, acceptance criteria per task, and dependency overview at the end. After this lesson, you will have a first-draft plan on disk and a clear checklist for evaluating its structure before the review step.

Runs an independent AI review session on the draft plan using the same document-driven pattern, produces a findings report in a separate file, and applies human judgment to decide what to address. On camera, one high-severity finding — a missing CSRF protection task — is selected and fixed with a targeted single-prompt update. After this lesson, you will be able to commission an independent AI review of any planning document, triage findings by real risk rather than completeness, and apply selective fixes that leave the rest of the plan intact.

Introduces the critical path — the minimal chain of dependent tasks that must all complete before the product works end to end — and shows how to read it from the implementation plan's dependency overview. You will walk through the ~12 tasks on the critical path for the demo app and contrast them with the many valuable features that can be deferred. After this lesson, you will be able to identify the critical path in any implementation plan and use it to decide what to build first, shipping a working MVP rather than a partially completed everything.

Executes the first critical path task — monorepo scaffolding — end to end using the branch-per-task workflow for the first time. You will see the AI read the task definition from the plan, scaffold a complete monorepo with a React frontend, a Node API backend, and a shared types package, run all acceptance criteria (install, dev servers, lint, typecheck), and pass them. After this lesson, you will have internalized the branch-implement-validate-merge loop that drives every subsequent implementation task.

Executes Task T1.1 — the database schema for core entities — and shows why the data model must come before any backend service can do real work. Two prompts are used: the first sets up a local Postgres development database via Docker Compose, and the second implements the Prisma schema with six tables, three enums, and a smoke test. After this lesson, you will know how to scope a data model task precisely, spin up a local dev database for an AI session, and validate a migration against acceptance criteria before merging.

Demonstrates a nuance in following the critical path: the next reachable task is determined by dependencies, not just the headline order. T2.5 (auth middleware) depends on T2.4 (JWT utilities), so T2.4 comes first. You will implement a focused `jwt.ts` utility — three functions, unit tests, nothing more — and see what scope discipline looks like in practice. After this lesson, you will understand dependency-driven sequencing, know how to write a tightly scoped task prompt with an explicit guardrail, and see why each task being mergeable on its own matters.

Teaches a high-leverage habit: before closing an implementation session, use its accumulated context to produce the PR description. The same session that just built the JWT utilities writes a complete description — title, summary, files changed, rationale, test instructions, and a clear scope boundary — from a single prompt, saved directly to a file in the repo. After this lesson, you will know how to drain a live AI session's context before closing it, and why the "out of scope" section of a PR description makes code review faster and more trustworthy.

Returns to the critical path for T2.5 — the first task that explicitly composes prior work. The prompt names the existing JWT verifier and the Prisma list-ownership models the middleware should reuse, and states plainly: do not re-implement them. You will validate four acceptance-criteria outcomes (missing token, invalid token, insufficient permission, and success pass-through) before merging. After this lesson, you will know how to write compositional prompts that direct the AI to build on top of the existing codebase rather than solving problems you already solved.

Steps back from task execution to name the pattern explicitly: a seven-step loop (locate, branch, prompt, review, validate, commit, merge) and six durable insights that transfer to any project. You will see why the plan drives the prompt, how scope is largely self-managed when the plan is visible to the AI, why the session should be drained before closing, and why acceptance criteria — not confidence — are the definition of done. After this lesson, you will have a clear, named mental model of the full execution workflow that you can apply to any stack, any AI tool, and any implementation plan.

Synthesises the entire course journey — from terminal commands to a validated, executed implementation plan — and names the five enduring capabilities students leave with: structured communication with AI, documentation as the source of truth, incremental development with Git, the execution loop, and validation discipline. No new tools or patterns — just a clear view of how far the workflow has come and what it enables from here. After this lesson, you will be able to articulate what you have learned in transferable terms, continue the demo project to a working MVP on your own, or apply the full workflow directly to your own project.