Video Summary - 제2강 프로그램 개발

Main Ideas, Concepts, and Lessons

1) Purpose of the Lecture (Lecture 2)

Lecture 2 continues from Lecture 1, which covered:

Terminal and CLI (command-line interface) concepts.

Lecture 2 focuses on what it takes to develop programs in practice, including:

The components involved in building software
How to specify a program so an AI agent can implement it

Practical exercise: Build a very simple to-do list management program using an AI agent (via “Vive coding” / agent-assisted coding).

2) Start from the User Problem (“What”), Not Tools (“How”)

User problem definition: The real inconvenience a user experiences and the change they want.

Common mistake: Choosing technology first (e.g., frameworks, languages) and focusing on how to implement rather than the original problem.

Key lesson—before coding, verify:

Who wants what changes
Why it’s needed
How it will be used

Warning about AI automation: AI can generate automated solutions, but sometimes the underlying “problem” wasn’t truly necessary. The “right first step” is identifying the truly necessary problems.

3) Requirements as “Promises” That Can Be Verified

Requirements are described as:

A set of promises written as verifiable statements describing what the program must do.

Requirements should not be vague:

“It would be nice” is not actionable.
Instead, specify testable/checked behavior.

Include “bad/unusual situations”:

For example, in a to-do app:

Reject adding a task with a blank title
Reject completing/deleting a task using a non-existent ID (e.g., task 7 when only 1–3 exist)

Important balance:

Don’t embed overly rigid implementation details inside requirements.
Focus on what behavior is needed; decide how later.

4) Features and Completion Conditions (Criteria for “Done”)

A feature is typically the “function” the program provides to users.

For each feature, define:

Function specification
Completion conditions (criteria for correctness)

Example (“Add” feature):

When adding an item, the task’s content and number appear in the list
The task remains after restarting the program (persistence via storage)

Manual testing of these conditions is painful—this leads into automated testing.

5) Testing and Test-Driven Development (TDD / TD)

Testing uses tests to:

Develop, improve, repair, and verify behavior.

Why automate tests? After modifications, rerun automated tests; if all pass, the feature still works.

Relationship to specs: A test can act like a specification for:

What a function is
What its completion conditions are

Preferred order: Write tests before implementation so code is built to satisfy them. (Referenced as TD in subtitles; aligns with TDD.)

6) Data, State, and State Machines (FSM)

High-level behavior model:

Input → Processing → Output

State is the “current values” that influence the next decision/output.

Core claim: Output depends on:

the input AND the current state

Example: to-do list

After adding “clean,” output might show only item 1.
After later adding “eat,” output changes because the state (list contents) changed.

State machine framing: With input + state, the program produces output, possibly updating state.

Persistence:

Persistent state (saved data) remains even after the process ends.
Example: saving the to-do list to a file so tasks remain after restarting.

7) Program Components: Program/Software, Source Code, Runtime Environment

“Program” (narrow sense): Instructions a computer executes (eventually compiled into 0s and 1s for the CPU).
“Software” (broader packaged thing): Includes program + related data/config + documentation (and possibly source code).
Source code: Human-readable text (e.g., .py) defining functions and behavior.
Runtime/execution environment: Everything needed to execute, including:
- Operating system (Windows/Ubuntu/etc.)
- Language runtime/interpreter (e.g., Python installed version)
Libraries: Reusable code (e.g., a standard math library).
Dependencies: What the program requires to run (e.g., OS/environment + Python version + required libraries). Provided as a written requirement like: “runs on X, requires Python Y, and libraries A/B…”

8) Data Formats (JSON) and Schemas

Tasks must be stored using some data format.

Example: JSON

Structured as text with curly braces and key-value pairs.

Schema

Rules describing fields and allowed value types, e.g.:
- Age must be a number
- Name must be text of a certain length

Applied to to-do data:

Ensure each stored item has consistent fields (e.g., title, ID, completion status)
Ensures consistent data management across saved data

9) Program Flow and CLI Structure (Command/Subcommand)

A CLI program runs based on commands, typically with subcommands:

add
list
delete
complete

Example described behavior:

Run app with subcommands:
- add <title>
- list
- complete <id>
- delete <id>

For add, the flow includes:

Check the current list
Determine the next ID
Add the task
Save tasks in a JSON file

10) Memory vs Files (Persistence) and Why RAM Is Used

Memory (RAM):
- Fast but volatile: disappears when the program ends.
Files (hard disk/SSD storage):
- Persistent: survive termination and even power-off.

Performance reason:

Loading/modifying huge data directly on disk is slow.

Typical workflow:

Load file into memory
Modify in memory
Write back to file (overwrite/update)

11) Unique IDs, Next-ID State, and Deletion Behavior

Why unique IDs matter:

Even if titles match, tasks are distinct—IDs distinguish them.

ID state management:

Maintain a “next ID” as state.
When adding:
- assign next ID → create task
- update next ID for the next add

Deletion nuance:

Deleting tasks may create gaps in IDs.
Common/simple pattern:
- Do not recycle deleted IDs; keep increasing to avoid complex free-list recycling.

Advanced recycling (mentioned):

A more complex “VEC pattern” approach to fill gaps, described as cumbersome.

12) Error Handling: Invalid Inputs and Corrupted Data

Here, error means:

Any unexpected input/situation outside the normal valid range.

Good requirements/program:

Detect invalid cases and respond gracefully (don’t crash).

Examples:

Divide-by-zero analogy: reject invalid operation
To-do app invalid operations:
- Blank title
- Title too long
- Complete/delete non-existent ID
Corrupted file scenario:
- If JSON is corrupted and unreadable, the program may need to stop because recovery may be impossible.

Practical Exercise / Methodology (Agent-Assisted Development)

Tools / Environment Setup

Use WSL (Windows Subsystem for Linux) for terminal practice:
- Install WSL if needed
- Enter WSL via terminal
- Check Python availability (e.g., run python / python3 version check)
Use an AI coding agent
- Not a simple chatbot; it can:
  - Use a computer/browser
  - Create/delete files
  - Write source code
Agent used:
- Open Code (with an underlying model connected separately)

Agent Connection Steps (Open Code)

Install Open Code in WSL
Open Open Code from the terminal within the project folder
Connect Open Code to an LLM:
- Obtain an API key (described as a link containing a complex key)
- Use Open Code UI to connect to OpenAI
- Choose a model (example referenced in subtitles: GPT 5.6)

Prompting Methodology for Producing the Program

Key instruction: The prompt must include everything needed for the agent to build the program correctly, because the agent needs:

environment details
program structure requirements
feature definitions
constraints/limitations
error-handling behavior

Prompt content checklist:

Tell the agent/developer role your environment:
- OS
- Python version
- current working directory/folder
- execution context details
Provide a clear program specification:
- Purpose: a CLI to-do list manager
- Required functions/features:
  - add (add task by title, assign ID, persist)
  - list (show current tasks)
  - complete (mark task done by ID)
  - delete (remove task by ID)
- Persistence: save tasks in JSON
Add constraints:
- No installing extra libraries (unless allowed)
- Avoid external networks (stay within CLI environment)
Provide testing/verification instructions:
- Require correct handling for errors such as:
  - blank titles
  - invalid IDs (e.g., completing/deleting task number 999)

Execution Workflow for the Agent-Generated Result

After the agent finishes generating code:
- Exit Open Code (command mentioned: slashExe)
Inspect generated files:
- Use terminal ls
- Check README for documentation
- Confirm code files exist (e.g., todo.py) and JSON storage files
Run and manually verify using CLI:
- Invoke the generated Python program
- Test command sequence:
  - list (should show “nothing” initially)
  - add (add tasks like “equipment inspection”)
  - list (verify numbering/placement)
  - complete (verify completion behavior)
  - delete (verify removal)
  - list again (confirm current state)
Verify error handling:
- Blank title → proper error message
- Invalid IDs (complete/delete) → proper rejection/response

Conclusion (Lesson Wrap-Up)

The lecture concluded after:

Explaining required program components, from:
- problem → requirements → functions → completion conditions → testing → state/data → persistence
Demonstrating how to generate and verify a simple program using an AI agent in a terminal/WSL setup.

Speakers / Sources Featured

Seol Jin-seok (speaker/lecturer)
OpenAI (source of the LLM used for the agent connection)
Open Code (AI coding agent used in the practical exercise)
GPT-5.6 (example model referenced for the LLM connection)
WSL (Windows Subsystem for Linux) (execution environment referenced)
JSON / JavaScript Object Notation (data format referenced)

제2강 프로그램 개발

Key takeaways