Module Check: Building Real Applications
This module covered the full arc of building a real application with AI assistance: from the structure of the build loop at scale, through multi-file prompting and interface design, to data modeling, safe iteration, version control, refactoring discipline, and the long-game challenge of keeping the AI on track. This lesson tests whether you have internalized these ideas at the level of understanding — not just recognition — and asks you to synthesize them in a capstone task.
Flashcards — click each card to reveal the answer
A developer builds the back-end and front-end of a new feature simultaneously, without writing an interface specification. Both components appear to work individually. What is the most predictable failure mode?
After a productive AI session, a developer does not write a session summary and does not update the project brief. What is the most direct consequence in the next session?
A function has grown to 80 lines and performs validation, database insertion, response formatting, and email notification. What refactoring signal does this represent, and what is the appropriate action?
A developer wants to try a risky architectural change but is worried it may break the application. What is the correct version control practice before attempting this change?
You asked the AI to add a filter parameter to an existing route. The AI added the filter correctly but also renamed several variables for 'clarity' and added a try/catch block that was not there before. Which of these unrequested changes is most likely to be harmful?
A project has reached a state where every new feature requires touching eight different files, and AI outputs consistently require significant manual correction. What does this indicate, and what is the appropriate response?
Every technique in this module is an instance of the same underlying discipline: making implicit things explicit. Implicit interfaces become integration failures. Implicit context becomes AI drift. Implicit changes become undetected regressions. Implicit history becomes irrecoverable state. The developer who builds real applications successfully is the one who systematically externalizes — into specifications, briefs, diffs, commit messages, and correction prompts — the knowledge that would otherwise exist only in their head and disappear the moment they close the laptop.
Module Synthesis: Postmortem Analysis
- Below is a description of a failed AI-assisted project. Read it and produce a structured postmortem — a document that identifies every failure, traces it to the technique from this module that would have prevented it, and prescribes the specific corrective practice.
- Project description: A team of two students spent three weeks building a task-management application. They used an AI assistant throughout. In week one, they built the back-end quickly and were pleased with the speed. In week two, they started the front-end without writing interface specifications, connecting it to the back-end as they went. Several fields had different names on the two sides and had to be fixed repeatedly. By week three, the AI was generating code that used different naming conventions than the code written in week one, because no project brief existed. They tried to add a filter feature but the AI rewrote large sections of three files while adding it, introducing a regression in the delete feature. They had no version control, so they could not revert. They spent two days manually reconstructing the previous state. The project was never completed.
- Your postmortem must:
- 1. Identify at least five distinct failures (one sentence each describing what went wrong).
- 2. For each failure, name the specific technique from this module that would have prevented it.
- 3. For each failure, write a one-sentence prescriptive rule — a practice they should follow in their next project.
- 4. Conclude with a one-paragraph reflection on which single practice, if adopted first, would have had the greatest positive cascading effect on the other failures, and why.