Class 6: September 3, 2026 · ENTR 5000
Notes from September 3, 2026. These notes record the discussion and instructions given that day. For current requirements and due dates, use the assignment guidelines and semester schedule.
Plan the project before generating the application
The shared exercise was a wardrobe-management web app: begin locally, with a path to remote hosting later. Today’s demonstrated milestone was an architecture plan and a GitHub repository, not a finished application. Ask the coding assistant to plan the structure before writing application code, then question the plan until you understand its parts.
Git manages version history locally; GitHub hosts repositories remotely and supports collaboration. A repository contains the project’s tracked files and history. A branch lets work proceed separately before changes are reviewed and merged. These habits matter even for one human working with AI: multiple changes need to be recoverable and reconcilable. GitHub’s introduction is a reference for the distinction.
Files, folders and the terminal
The terminal and Finder are ways of working with the same filesystem. Practice locating the project deliberately rather than losing track of where an AI tool is making files.
| Command | Purpose |
|---|---|
pwd |
Print the current working directory. |
ls |
List its contents. |
cd folder |
Move into a directory. |
cd .. |
Move to the parent directory. |
mkdir folder |
Create a directory. |
Tab completion and dragging a folder path into the terminal can reduce typing errors. Begin by giving the coding tool access to the project folder you intend to use.
Read the architecture as a map
The demo distinguished the browser interface, application/server code, database, uploaded photographs and configuration. A lightweight Python-based design was chosen for the demonstration; other students’ plans differed. The proposed local database was SQLite, with a later move to a hosted database contemplated. These are design choices to understand and test, not magic interchangeable parts.
- README: a front-door explanation of the project.
- Architecture document: the decisions, components and how they fit together.
- Markdown (
.md): readable text with lightweight formatting, useful for durable project documentation. .gitignore: rules for files that should not be tracked, such as local data and uploads. Check what is actually tracked; an ignore rule does not erase earlier commits.
Ask for a short, low-jargon explanation first, then follow a specific path: “Why these tables?”, “Where does a photo live?”, or “What happens when a user records an outfit?” Save useful explanations into the project so the next session does not depend on remembering a chat.
Andrej Karpathy’s LLM Wiki idea was mentioned as a related approach to accumulating an interlinked knowledge base. It is a pattern to implement, rather than one required installed application.
Before Tuesday, September 8
- Finish authenticating your chosen local coding tool with GitHub, and have the project managed by Git locally and synced to GitHub remotely. A private repository was the suggested starting point.
- Review the generated architecture and be ready to explain the main components and show where you got to. Ask for help with unfamiliar terms rather than accepting the plan blindly.
- Improve password hygiene: use unique passwords and two-factor authentication for important accounts, and a password manager for new work. Secrets include passwords and API keys; keep them out of committed code.
- Optional: bring photographs of some of your clothes for the wardrobe exercise.
Remote deployment with Railway was planned as the next step. The recording does not establish that the application or deployment was completed today. 1Password and Apple’s Passwords app were mentioned as password-manager options.