Chapter 16 — Final Review and Capstone

“Real artists ship.” — Steve Jobs

“For we are his workmanship, created in Christ Jesus for good works, which God prepared beforehand, that we should walk in them.” — Ephesians 2:10

Why This Matters

This is the last chapter of the last core book.

There is no Week 17. After the capstone, the sequence we have been walking together since the first page of Coding 1 — C++ to Java to Python, structures to systems, the keyboard as the gym — is finished. Not your work. Your course. The work is just beginning, and the whole point of this chapter is to convince you of that and then get out of your way.

By design, this chapter teaches no new technical material. Its job is to do three things. First, to compress thirty-two weeks of training into a single map you can hold in your head — here is everything you now know, and here is how the pieces fit. Second, to walk you up to the door of Project 14, the take-home full-stack capstone, and tell you exactly how to do it well — because the way you approach it is itself the final lesson. Third, to send you off: to say plainly what it means that you can now build a real internet-aware application alone, the thing that used to take a team, and where you can go from here without anyone left to sequence the next course for you.

The thesis of this book has been one sentence, and you have now earned every word of it:

AI builds what you specify. The architect decides what’s worth building — and what it will cost.

Phase 1 taught you the cost. Eight weeks of building structures by hand, measuring them, and watching the asymptotics lie at real scale. Phase 2 taught you the system. Eight weeks of servers, databases, and front ends, with the right-tool decision foregrounded in every project. Week 15 taught you the architect’s method — how to turn a pile of constraints into a chosen stack and a drawn system. And all of Phase 2 taught you to direct agentic AI: to delegate the building without surrendering the judgment.

The capstone asks you to do all of it at once. One application. Your architecture. Your justified database. Your front end. Your agent, logged. That is the final exam, and it is also — and this is the part that should land — the actual job. What you are about to do for a grade is the same shape as what a working software architect does for a living. The fact that you can do it, alone, in a take-home week with a 60-minute defense, is the diploma. The grade is just the receipt.

The Christian question for this last week is the largest one the book asks: what can a Christian engineer build? We have circled it for fourteen projects. This week we answer it the only way it can be answered — by building something, well, and standing behind it.

16.1 — Everything You Now Know (The Whole Map)

A one-paragraph reminder of each chapter. If any of these don’t ring a bell, that’s where your gap is. Re-read before the capstone.

Phase 1 — The Cost of Everything

Chapter 1 — The Architect’s Question. Big-O is the language of cost. Before you can choose the right tool, you must be able to say what a tool costs — in time and in space. The architect measures; the amateur guesses. You learned to predict a curve, instrument it, run it at scale, and confirm or correct your prediction.

Chapter 2 — Arrays and the Memory You Can Feel. Contiguous memory, cache locality, amortized doubling. A Python list is a dynamic array — append is amortized O(1) because the buffer doubles. You built one by hand and felt the occasional expensive append.

Chapter 3 — Linked Lists and the Cost of Pointers. O(1) splice in theory; pointer-chasing cache misses in practice. The lesson that made the whole of Phase 1 worth it: the asymptotically “worse” structure (the array) usually wins the footrace because the cache loves contiguous memory. Asymptotics can lie.

Chapter 4 — Stacks, Queues, and Deques. Linear ADTs are interfaces, not implementations. The same stack sits on an array or a linked list, and the choice is a real tradeoff under a real constraint. The ring buffer that makes an array-backed queue O(1) on dequeue.

Chapter 5 — Hash Tables: The Magic and the Fine Print. Average O(1) lookup, with fine print: collisions, load factor, the space cost, and the adversarial worst case (hash flooding) that is a real security concern for servers. CPython’s dict is open-addressing. You built chaining and probing both.

Chapter 6 — Trees: When Hierarchy Is the Shape. Ordered lookup, range queries, predecessor/successor — the things a hash map can’t do. O(log n) when balanced, O(n) when it degrades to a sorted-insert stick. This is exactly the decision a database makes when it picks an index — a forward-link you cashed in during Week 12.

Chapter 7 — Graphs and the Shape of Connection. Recognizing the graph hiding inside a problem, then choosing adjacency list vs matrix as a space/time tradeoff on sparse vs dense data. BFS for shortest hops; DFS for connectivity.

Chapter 8 — Concurrency, Threads, and Midterm Review. Threads vs processes vs the event loop, mapped to I/O-bound vs CPU-bound vs many-connections workloads. The Python GIL: CPU-bound threads don’t parallelize, I/O-bound ones effectively do. The midterm tied Phase 1 together under a clock.

Phase 2 — The Right Tool, the Real System

Chapter 9 — Your First Server. A server is a program that waits at a port and answers requests. You built a JSON API with Node’s bare http module — no framework — so you understand what a framework hides. The request/response cycle; status codes; Node’s single-threaded event loop.

Chapter 10 — APIs, JSON, and FastAPI. You built the same API again in Python with FastAPI, so the stack choice became a felt decision. Pydantic models are specifications — the Coding 2 skill in a new key. The auto-generated /docs. The Node-vs-FastAPI comparison under three different constraints.

Chapter 11 — Persistence I, SQLite. In-memory data dies on restart; a database is how a program remembers. SQLite: serverless, single-file, real SQL — the perfect MVP database. Parameterized queries, never string concatenation, because of injection.

Chapter 12 — Persistence II, PostgreSQL. When SQLite’s “one writer at a time” stops being enough, you reach for a client/server database with MVCC. Connection pools, migrations, indexes (the tree/hash tradeoff from Weeks 5–6, chosen for you), transactions, ACID. And the discipline of justifying the migration rather than cargo-culting it.

Chapter 13 — Persistence III, MongoDB. Not all data is relational. The document store, schema flexibility as a tradeoff, denormalization vs join cost. The architect’s memo at the center of the persistence arc: relational or document, defended against the real constraints, with the conditions you’d flip your answer named.

Chapter 14 — The Front End That’s Good Enough. HTML/CSS/JS, fetch() to your own API, forms, rendering. The MVP philosophy: a front end that is honest and usable beats one that is beautiful and late. “Good enough” is an engineering judgment, not an excuse.

Chapter 15 — Architecting the Whole System. The method: constraints in, chosen stack out. Where agentic AI accelerates (the modules) and where the human must decide (which modules exist, and why). MVP scoping. Deployment realities — the gap between “runs on my machine” and “runs.”

That is Coding 3. That is, with the two books before it, the whole core sequence.

Coach’s Note — Read that map and notice something. Phase 1 isn’t a detour you took before the “real” web programming. Every Phase 2 decision you made was a Phase 1 lesson cashed in. The index you added in Week 12 is the tree from Week 6. The injection you guarded against is the adversarial-keys attack from Week 5. The event loop that keeps Node serving while one request waits is the I/O-bound thread story from Week 8. You did not learn fifteen unrelated things. You learned one thing — the cost of every choice — fifteen times, in fifteen keys.

16.2 — The Architect’s Method, One Page

You will run this exact sequence in the capstone. It is the integration of everything. Memorize the order; the order is the discipline.

Steps 1 through 5 are the architecture, and they are yours. No agent does them for you, because no agent knows your constraints, and the constraints are the whole game. Step 6 is where the agent earns its keep — it writes module bodies fast. Steps 7 and 8 are where you prove the thing is real and that you understand it.

Coach’s Note — The single most common failure on a take-home full-stack build is starting at Step 6. The student opens the editor, prompts the agent “build me a prayer-request board with a database,” and accepts a pile of plausible code they did not architect and cannot defend. It compiles. It even runs. And in the live session, the first question — “why SQLite and not Postgres here?” — has no answer, because no one decided. Steps 1–5 are an hour of writing that saves you the week. Do them first.

16.3 — How to Approach the Take-Home Final Well

The capstone is not the 60-minute sprint the midterm was. It is a take-home build over a week, culminating in a 60-minute live integration session where you stand up your app, walk your architecture, and defend one hard decision. That changes the strategy completely.

Write the architecture document FIRST. Before any code. This is the single most important sentence in this chapter. The architecture doc is graded most of all (see the rubric in Project 14), and it is the artifact that makes everything after it go fast. A page. The constraints, the chosen stack with a justification per choice, the system drawing, the data design. Write it before you let the agent touch a file. If you change your mind mid-build — and you might — update the doc. The doc is the source of truth, not an afterthought you backfill at minute fifty-five.

Then build, in the order of §16.2. Data layer first (you can’t serve what you can’t store), then the API (you can’t render what you can’t fetch), then the front end (the face goes on last). Validate each seam as you cross it: curl the endpoint before you wire the front end to it. Don’t build all three layers blind and pray they connect.

Then write the agent log and the reflection. The agent-log.txt is required — every task you delegated, what the agent built, where it was wrong, where you intervened. Log it in real time, as you go. Reconstructing an agent log from memory at the end produces a worthless document and you know it. The reflection.docx answers the thesis: what the right tool turned out to be, why, and the one thing you’d architect differently. Both are graded. Budget for them. You cannot make up a missing reflection with more code.

On time and scope. The arc estimates Normal at the high end of a Coding-3 week because standing up a server, a database, and a front end from zero is genuinely more work than a single-language program. Use Appendices A–C so the setup doesn’t eat your week. Then: scope down, not up. A clean Normal-tier app you can defend cold beats a half-wired Medium-tier that breaks when the grader clicks the second button. Pick the smallest version of your idea that is genuinely full-stack and genuinely yours, ship that, and then reach for Medium and Hard if time remains. The rubric rewards a complete, defended Normal far more than an ambitious, broken Hard.

What the graders reward — in order. The architecture document, most of all: a stack chosen against named constraints, justified, and matching what you actually built. Then the working end-to-end integration — the browser really talks to the API really talks to the store. Then the agent log and reflection, read for honesty and judgment, not for prose. Then the code itself — but the code is the least of it, because the code is the part the agent helped with. You are not being graded as a typist. You are being graded as the architect.

Coach’s Note — Here is the trap, and it is the inverse of the midterm’s trap. The midterm was closed-AI; it exposed whether you had the Phase 1 skills the AI normally covers for. The capstone is open-agent; it exposes whether you have the architect skills the agent cannot provide at all. An agent will happily build you a full-stack app. It will choose a stack by vibes, denormalize a schema it shouldn’t, and ship an index it never measured. The grade — and the live defense — separates the student who directed that work from the student who merely received it. Direct it.

16.4 — The Live Integration Session

Sixty minutes, in front of a grader (or a recording, per your instructor). Here is the shape, so it holds no surprises.

• Stand it up (≈10 min). Start your backend. Start your front end. Open the browser. Show the app working end to end — create something, see it persist, reload, see it survive. If it doesn’t run on a clean checkout, fix that before anything else; a build that only runs in your exact terminal is not done.
• Walk the architecture (≈15 min). Open architecture.docx. Walk the constraints, the chosen stack, the drawing, the data design. Say the justifications out loud. This is the part the grader weights most.
• Defend the hard decision (≈15 min). If you attempted Hard tier, this is where you defend the judgment-requiring feature — the concurrency-safe operation, the measured index, the relational-vs-document call baked into the data layer. Bring your measurements. Be ready for “what would change your answer?”
• Show the agent log (≈10 min). Open agent-log.txt. Point to one task the agent nailed and one where it was wrong and you caught it. Specificity is the whole grade here.
• Reflect (≈10 min). What the right tool turned out to be. One thing you’d do differently. The honest answer to “can you stand behind every line of this?”

The questions the grader will ask are not gotchas. They are the questions a senior engineer asks a junior in a real design review: Why this database? What happens under concurrent writes? Where did the agent get this wrong? What did you measure? What would you change? If you did Steps 1–5 yourself, you have the answers. If you let the agent architect, you don’t. The session is built to tell the difference.

16.5 — Common Bugs (Full-Stack Integration Edition)

The capstone’s bugs live in the seams between the layers. These are the ones that bite during the live session.

Bug: The front end can’t reach the API — every fetch() fails with a CORS error in the browser console. Example: Front end served from http://localhost:5500, API on http://localhost:8000, no CORS headers. The browser blocks the cross-origin request. Fix: Enable CORS on the backend for your front-end origin (FastAPI’s CORSMiddleware, or set the Access-Control-Allow-Origin header in Node), or serve the static front end from the same origin as the API. Decide which in your architecture doc; don’t discover it live.

Bug: Data vanishes on restart even though you “added a database.” Example: You stood up SQLite but the API still reads from an in-memory list it never removed; the DB writes happen but nothing reads them back. Fix: Delete the in-memory store entirely. Prove persistence with the round-trip test from §16.6: create, restart the server, read it back.

Bug: SQL injection, sitting wide open, because a value got concatenated into a query string. Example: cur.execute("SELECT * FROM notes WHERE title = '" + title + "'"). Fix: Parameterize. cur.execute("SELECT * FROM notes WHERE title = ?", (title,)). This was the Week 11 lesson; the agent will sometimes regress it. Read every query the agent writes.

Bug: The agent “fixed” one endpoint and silently broke another. Example: You asked it to add validation to POST /notes; it rewrote the shared serializer and broke GET /notes. Fix: Scope every agent task to one module or one endpoint. Diff before accepting. Re-run your end-to-end validation after every agent change. This is the Coding 2 iterative-refinement discipline, and it is now your last line of defense.

Bug: A 409 Conflict (or a unique-constraint violation) crashes the server instead of returning a clean error. Example: A duplicate insert throws an unhandled IntegrityError and the process dies. Fix: Handle the violation at the API boundary and return the right status code. Exception handling at every I/O boundary — server, database, file. The boundary is the contract.

Bug: The app works perfectly for you and not for the grader, because of an absolute path, a missing seed file, or an env var only set in your shell. Example: The DB path is /Users/you/project/data.db hard-coded; the schema is never created on a fresh clone. Fix: Relative paths, a seed/migration step in the README, and a clean-checkout test before you submit. “Runs on my machine” is not a defense; the live session is on a clean checkout.

16.6 — Reps This Week

Open the exercises. This week’s reps are a full-stack dress rehearsal — a timed run through the whole architect’s method on a throwaway scope, so that on the real capstone your fingers already know the path. You will write a mini architecture doc, stand up a one-resource API against a chosen database, wire a single-page front end with fetch(), prove persistence across a restart, and write a one-paragraph agent log. Twice, with two different scopes. The second run is worth more than the first.

Do the dress rehearsal before you start the real build. The discipline of building the whole shape under a clock changes how you move when the grade is on the line.

16.7 — This Week’s Project: The Capstone

Project 14 — A Real Internet-Aware Application (FINAL) is in Project 14. It is the capstone of the book and the sequence.

You will ship a complete, small, real full-stack application of your choice from an approved list of ministry-themed scopes: a backend (Node or FastAPI) exposing a JSON API, persistence in a database you chose and justified (SQLite, Postgres, or Mongo), and a reasonable web front end that talks to your API with fetch(). Written first: a one-page architecture document with a constraint-based justification for every choice — the thesis, made concrete. Required throughout: an agent-log.txt of everything you delegated to agentic AI and where you intervened, and a reflection.docx on what the right tool turned out to be. Medium tier adds a second related resource and a joined front-end view with end-to-end validation. Hard tier adds one genuinely hard, judgment-requiring feature an agent cannot spec for you — and you defend it live.

Read Project 14 now. Read it again before you start. It is the last project in the book.

16.8 — A Theological Footnote: Workmanship

The epigraph for this chapter is Ephesians 2:10 — “For we are his workmanship, created in Christ Jesus for good works, which God prepared beforehand, that we should walk in them.” It is worth sitting with at the end of a course about building things.

The verse runs in two directions at once, and both matter for an engineer. First: you are the workmanship — God’s, the original Architect’s, made deliberately and for a purpose. Your skill at building is itself a built thing. You did not invent your own mind; you were given it, and you have spent thirty-two weeks shaping it through reps you chose to do. That is stewardship, not self-creation. Second: you are created for good works — works prepared beforehand — which means the building you do is not arbitrary. There is real work waiting for the person who can build well: tools for a neighbor, systems for a church, software that serves people who will never see your architecture doc and never need to.

Hold those together and you have the Lutheran doctrine of vocation. Your calling as an engineer is not a lesser thing than “ministry”; it is a station God uses to serve your neighbor through the ordinary excellence of your craft. The hymn suggester you build is not the Divine Service — it is a small assist for ordinary Christian life, and the course has been careful about that distinction all along. But building it well, honestly, in service to someone other than yourself, is exactly the kind of good work the verse means. You don’t have to leave the keyboard to find your vocation. The keyboard, done faithfully, is one.

So: build the capstone as workmanship. Not to prove you are talented — you are workmanship, the talent was given — but because the work is good, and good work served to a neighbor is the thing you were made for. Pair the verse with Steve Jobs’ line at the top: real artists ship. Excellence that never ships serves no one. The vocation is finished work, handed over, used. Ship it.

16.9 — Coach’s Final Word for Week 16 (and the Book)

You are at the end.

Three books. Forty-eight weeks, if you took them in sequence. C++ to Java to Python, a hand-built data structure for every shape of problem, a server in two languages, three databases, a front end, and an agent you learned to direct without losing yourself. Fourteen graded projects in this book alone. Most people who start a sequence like this don’t finish it. Of the ones who do, most can talk about software without being able to build it. You can build it. Alone. End to end. That is rare, and you should let yourself know it is rare.

A few words before you close the book.

You can now build the thing that used to take a team. This is not a motivational exaggeration; it is a literal description of what the last sixteen weeks gave you. A working server, a justified database, a usable front end, the seams between them, and an agent multiplying your output — that was a small team’s quarter, not long ago. It is now your take-home week. Sit with how much leverage that is, and how much responsibility comes attached. Leverage without judgment is just a faster way to ship the wrong thing.

The judgment is the part that lasts. The specific tools will turn over. The FastAPI version, the agent model, the Postgres release — all of it obsoletes on a timeline measured in months. What does not obsolete is the architect’s method: name the constraints, choose the tool, draw the system, justify it, direct the build, defend it. That method made today’s tools usable and it will make tomorrow’s tools usable, including tools that don’t exist yet. You did not learn a stack. You learned how to evaluate any stack. That is why this is the last course you needed us to sequence for you.

Where you go next is now yours to choose. Distributed systems, when one machine isn’t enough. Machine-learning engineering, when the model is the product. Security, because every server you build is a target and you’ve already met hash flooding and injection. Deeper algorithms, when the cost intuition you built in Phase 1 needs to go further. You do not need a course to walk you through any of those in order anymore. You have the cost intuition, the systems picture, and the agent-direction discipline to pick up a book, a paper, a codebase, and teach yourself — the way a working engineer learns everything after their last class. That independence is the real diploma. The certificate is just paper; this is the thing.

And the questions don’t end on submission day. What it means to count the cost, to keep a faithful record, to serve, to tell the truth about what you built and who built it with you, to build well rather than merely big — these were never only about programming. They are the lifelong questions of a thoughtful Christian who works, in any field, with their hands and their mind. You will be the senior engineer to someone before long. The way you direct AI, the way you correct, the way you architect and the way you credit — all of it forms a posture others will read off of you. Form it deliberately. You are workmanship, created for good works. Go do them.

Build the capstone. Stand behind it. Then close the book, and start the career it was for.

This is the end of Coding 3, and the end of the sequence. There is no Monday after this one — only the work that begins when the course ends. Go build something good.

Soli Deo gloria.

Up next: Do the dress rehearsal in the exercises. Then open Project 14 — the capstone, and the final project of the book. When you’ve shipped it and defended it, you’re done. Return to the Coding 3 home for the appendices and the road ahead.

You built it. Now go build for someone else.