Chapter 4: Coding the first version of our application

Introduction

The chapter introduces the need for a sound application foundation and explains how stubs let developers assemble and run an application before implementing its functionality.

• Requirements as the foundation: Explain why the application’s foundation needs to meet its requirements before further development.
  Why it matters: Getting the foundation right makes later development less difficult.
• Stubs before full functionality: Describe what a stub is and how stubs allow an application to be assembled before its parts are fully functional.
  Why it matters: Stubs let you establish a runnable application structure without implementing every feature first.

Key terms: foundation, requirements, stubbing, stub

4.1 Stubbing: Building the skeleton of your application

The section introduces stubbing as a way to build and test an application’s structure before implementing its full functionality.

• Placeholder application components: Explain that stubs are simplified placeholder code components created before full functionality, allowing developers to test an application’s overall structure and flow early.
  Why it matters: This explains why an application skeleton can be useful before its components are complete.
• Practical benefits of stubbing: Describe how stubs support early integration, parallel development, controlled testing, and faster iteration.
  Why it matters: These benefits explain why developers may stub an application instead of completing its parts one by one.

Key terms: stubbing, stubs, overall structure and flow, early integration, parallel development, testability, faster iteration, dependencies

4.1.1 A simple code example

This section shows how database stubs let an application run before its database code is ready and gives guidelines for creating stubs strategically.

• Database Stub Behavior: Explain what the example database stubs do and how they help development proceed before a real database connection exists.
  Why it matters: You can check how parts of the application work together without waiting for the database code.
• Strategic Stub Development: Describe how to build and replace stubs incrementally, including how to keep the initial skeleton useful without stubbing speculative features.
  Why it matters: A runnable skeleton lets you add real behavior a feature at a time without building placeholders you may not need.

Key terms: stub, connect_to_database(), fetch_data(), DatabaseManager, dummy values, stubbing strategically, method signatures, class structures, TODOs, YAGNI

4.2 Extracting requirements from the design

This section explains why requirements need careful interpretation when using generative AI and gives a brief process for extracting them from a design document.

• Precise requirements for AI: Explain why clear requirements matter when using generative AI to build software, and why extracting them involves more than listing features.
  Why it matters: Getting requirements right before generating code helps avoid building the wrong thing quickly.
• AI extraction prompt safeguards: Describe how to prompt an AI tool for requirements and how to check its output.
  Why it matters: A well-formatted AI response is useful for review, but it is not proof that the requirements are real.
• Requirements to stubs sequence: State the three-step process given for moving from requirements toward application stubs.
  Why it matters: The sequence links the design discussion to an initial application skeleton.

Key terms: requirements, stakeholders, generative AI, prompts, structured output, potential pitfalls, follow-up prompts, validate, hallucinate requirements, key requirements

4.2.1 Step 1: Extract the requirements using ChatGPT

This section uses ChatGPT to turn a software design document into high-level requirements, then explains why a human must validate the result.

• ChatGPT requirements extraction: Describe how the author supplies the design document to ChatGPT and asks it to identify key requirements. Explain why this can help when documents are larger or more complex.
  Why it matters: A direct question paired with the document gives you a starting list without manually extracting every item.
• High-level requirements output: Describe the kind of requirements ChatGPT returned for the HAM radio practice-test application and how useful the author found them.
  Why it matters: A structured draft helps turn a design into work that can be discussed and assigned.
• Stakeholder validation of AI output: Explain why the author recommends checking ChatGPT's proposed requirements with stakeholders before relying on them.
  Why it matters: Reviewing a plausible-looking draft early can prevent mistaken requirements from guiding later work.

Key terms: design document, requirements, ChatGPT, high-level requirements, Question Pool Database, Question Selector, stakeholders, validate, hallucinates, human reviews

4.2.2 Step 2: Gathering requirements from Gemini

The section compares Gemini’s requirements with ChatGPT’s, shows how a second AI tool can help review a design, and explains why the more detailed list was chosen for the application.

• Different model interpretations: Explain why the same design document and prompt can produce similar or substantially different requirements from ChatGPT and Gemini.
  Why it matters: Expecting both overlap and divergence makes comparisons between AI tools more useful.
• Gemini requirement categories: Describe the initial application requirements Gemini extracted and distinguish them from the future considerations it identified.
  Why it matters: Separating initial requirements from possible additions keeps the first version focused.
• Cross-tool requirements review: Justify using a second AI tool to review requirements and describe how to check AI-generated requirements against the project.
  Why it matters: Cross-checking can improve the requirements without treating agreement between AI tools as proof that a feature belongs in the project.
• Choice of working checklist: Explain why the author chose the ChatGPT-generated requirements rather than Gemini’s response as the working checklist.
  Why it matters: A concrete, reviewed checklist is more useful for building the first version than a higher-level list alone.

Key terms: generative AI, model divergence, question pool, 35-question tests, future considerations, second opinion, cross-reference, stakeholders, hallucinated features, ChatGPT-generated list

4.3 Setting up our development environment

This section sets up a project folder and terminal, then creates and activates a Python virtual environment for the application.

• Project Folder and Terminal: Describe how to prepare a dedicated project folder, open it in Visual Studio Code, and use a terminal for that folder. Explain that the terminal can be a VS Code terminal or a platform-appropriate alternative.
  Why it matters: A project folder and a terminal for that folder give you a place to carry out the setup and subsequent application work.
• Python Virtual Environment Setup: Describe creating and activating a Python virtual environment for the project and checking the prompt to confirm it is active. Distinguish the Linux/Mac and Windows activation instructions at the level given here.
  Why it matters: Checking the prompt lets you confirm the project's environment is active before continuing.

Key terms: dedicated directory, Visual Studio Code, terminal, WSL, Python virtual environment, hrpractice, activate, prompt

4.4 Flask application structure

This section uses ChatGPT to propose an organized Flask project structure, explains the roles of its main files and folders, and treats the suggestion as a starting point rather than a final design.

• Reason for organizing Flask files: Explain why a single-file Flask application may be convenient at first but becomes difficult to manage as functionality grows.
  Why it matters: It explains why the project needs a structure before more code is added.
• Suggested Flask file responsibilities: Describe how the suggested structure separates application routes, pages and assets, question-related code, tests, configuration, startup, and dependencies.
  Why it matters: These responsibilities give the reader a map of where the application's code and supporting files belong.
• AI-assisted structure decisions: Describe how the author asks ChatGPT for a structure using the existing design-document thread, then uses its suggestion as an adaptable starting point and can ask it to create the blank folders and files.
  Why it matters: AI can save setup work without taking over the developer's architectural judgment.

Key terms: Flask, single Python file, file structure, routes, templates, static, models, utils, tests, context (thread)

4.5 Stubbing out our application

The section turns design requirements into a human-reviewed application skeleton of folders, files, classes, and method stubs.

• Three-step stub generation: Trace how the author uses AI to extract requirements from the design document, turn them into user stories, and then generate feature-organized class and method stubs. Explain why doing these steps in order makes the stubs more useful.
  Why it matters: This sequence helps connect the proposed code structure to the application’s design rather than generating stubs in isolation.
• Stubs within the file structure: Describe how the author asks ChatGPT to place the proposed stubs into the previously suggested file structure, then creates folders, empty files, and placeholder methods as an initial application skeleton.
  Why it matters: The skeleton provides places for code to grow without pretending the application’s features are already implemented.
• Human judgment over AI suggestions: Explain why the author treats ChatGPT’s proposed structure as a suggestion, removes unwanted managers, and checks AI design recommendations against actual requirements and constraints.
  Why it matters: Reviewing the suggestion keeps an AI-generated skeleton aligned with the project rather than locking in unnecessary or unsuitable components.

Key terms: requirements extraction, user story creation, stub generation, features, file structure, stubs, placeholder methods, iterative development, AI limitations, critical evaluation

4.6 Running our application

The section uses GitHub Copilot chat to get a stubbed Flask application running, then emphasizes that developers must understand and evaluate AI suggestions.

• Running the Flask skeleton: Trace how the author went from an organized but unrun Flask project to a working “Hello, World!” page using Copilot chat.
  Why it matters: This turns the application skeleton into something you can run and verify before adding features.
• Developer judgment over AI suggestions: Explain why the author treats AI as a collaborator rather than a decision maker when using its code and design suggestions.
  Why it matters: AI assistance is most useful when it speeds up work without giving up your understanding or control.
• Application skeleton before features: Describe what the working Flask page demonstrates and what it does not yet represent.
  Why it matters: A small running milestone provides a foundation without being mistaken for completed functionality.

Key terms: GitHub Copilot chat, run.py, python run.py, Flask application, Hello, World!, AI as an idea generator, not a decision maker, domain knowledge, generated source code, human judgment, application skeleton

4.7 Summary