2.1 Learning Objectives🔗

By the end of this lecture you should be able to:

1. Describe the three eras of programming practice—memorization, search, and generation—and identify what each era made cheap and what it left expensive.

2. Explain why this course is not an AI class, and state its actual thesis: when writing code becomes cheap, every other phase of software development becomes the job.

3. Name the phases of the software development life cycle and explain why undergraduate coursework has historically over-weighted exactly the phase that generative AI is automating.

4. Apply the five-year test to a piece of technical knowledge: decide whether it is a durable skill or a perishable tool detail, and justify the decision.

5. List the durable skills this course teaches—version control and collaboration, code review, testing, CI/CD, full-stack architecture, security and authorization, deployment, evaluation and monitoring—and connect each to a phase of the life cycle.

6. Complete a full-cycle micro-project in which the function body is the least graded artifact: specification, branch, tests, review, and CI carry the weight.

2.2 A Story About qsort🔗

When your instructor was an undergraduate, there was no Google and no Stack Overflow. If you wanted to sort an array in C, you either remembered the standard library or you walked to the shelf and opened the textbook. To this day he can recite that qsort lives in <stdlib.h> and takes exactly these arguments:

void qsort(void *base, size_t nitems, size_t size,
           int (*compar)(const void *, const void *));

And he can still write the ritual that every C programmer of that era had memorized—the comparator that casts two void pointers, dereferences them, and returns a sign:

#include <stdio.h>
#include <stdlib.h>

/* Comparator: cast the void pointers, dereference, compare. */
int compare_doubles(const void *a, const void *b) {
    double arg1 = *(const double *)a;
    double arg2 = *(const double *)b;

    if (arg1 < arg2) return -1;
    if (arg1 > arg2) return  1;
    return 0;
}

int main(void) {
    double data[] = {40.5, 10.15, 100.0, 90.45, 10.12, 25.7};
    int n = sizeof(data) / sizeof(data[0]);

    qsort(data, n, sizeof(double), compare_doubles);

    for (int i = 0; i < n; i++)
        printf("%.2f ", data[i]);
    printf("\n");
    return 0;
}

$ gcc sort.c -o sort && ./sort
10.12 10.15 25.70 40.50 90.45 100.00

If you can call qsort correctly without looking at an example, you are from that time.

Every generation looks back and shudders. Your instructor’s own professors told him stories of writing whole programs in assembly, and assured him he was lucky to be working in a high-level language like C. Assembly must have been truly difficult—everyone who programmed in it seems to be gone now (unless, of course, they are currently taking CMSC430).

To be fair, the programmers of that era only had to hold C and C++ in their heads—there was no Python, no TypeScript, no framework-of-the-month. The working set was small enough to memorize, so memorization was the skill.

Then the world changed. Google, online documentation, Stack Overflow, and Discord channels made all of that recall unnecessary. Nobody today remembers qsort’s argument order, and nobody needs to. We call Array.sort() or sorted(data) and do not even ask which sorting algorithm runs underneath. Many perfectly good working programmers cannot write a binary search correctly on the first try without testing a few edge cases—and it mostly does not matter, because the tools changed what the job required.

Here is the same program, one era later:

data = [40.5, 10.15, 100.0, 90.45, 10.12, 25.7]
print(sorted(data))

Fourteen lines of memorized ritual became one line you could find in thirty seconds of searching. Higher-level languages and online resources made programmers dramatically more efficient.

But be careful with the conclusion. They did not necessarily make us better programmers. Efficiency and mastery are different things: the search era removed the need to memorize, and much of the memorization skill quietly atrophied. Nothing was lost—until the day the abstraction leaked and someone needed to know why the sort was slow, or why the comparator crashed, and the person who could answer was the one who had once written it by hand.

Hold that thought. It is about to happen again, one level up.

2.3 The Third Era🔗

We are now at the beginning of another transition, and it is bigger than the last one. Generative AI can write code. Not autocomplete a variable name—write the whole function. Given a clear description and a way to check the result, a large language model produces the implementation in seconds:

Notice what just became cheap. Implementing the function body was the sacred part of software development—the part developers were proud of, the part that felt like the real work. When we learned the software development life cycle—

1. Planning and feasibility

2. Requirements analysis

3. Design

4. Development (coding)

5. Testing

6. Deployment

7. Maintenance

—the coding phase always seemed like the one that mattered. Our courses reinforced it: the typical undergraduate programming project hands you a scaffold and asks you to fill in the function body. The requirements were written for you. The design was the starter code. The tests were the autograder. Deployment was submit.cs.umd.edu (or Gradescope). Maintenance did not exist, because the project was deleted the day after the deadline. You have been trained, project after project, on exactly one slice of the life cycle.

Now read the fine print of the third era: if the requirements and the tests are well specified, an LLM can write the code for you. The slice you were trained on is the slice being automated. Industry measurements disagree on how much faster AI makes developers—some controlled studies show dramatic speedups on scoped tasks, and at least one careful 2025 study found experienced maintainers actually got slower while believing they were faster1METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” July 2025. The participants’ perception gap—believing AI sped them up roughly 20% after it had slowed them down 19%—is a theme this course returns to in the (part "Eval") lecture: measure, don’t vibe. —but no one disputes the direction. The cost of a working first draft of a function is collapsing toward zero.

And exactly as in the last transition, the value moves to what the tool does not supply. In the search era, that was knowing what to search for. In the generation era, it is everything on either side of the function body: knowing what to build, specifying it precisely, verifying what came back, integrating it, securing it, shipping it, and keeping it alive. In the life-cycle list above, that is items 1, 2, 3, 5, 6, and 7—six phases out of seven.

2.4 This Is Not an AI Class🔗

Now we can state what this course is, by first stating what it is not.

This is not an AI class. We will not survey neural architectures for their own sake. We will not chase the model that topped a leaderboard last Tuesday. We will not teach you a catalog of prompt incantations that stop working at the next model release. Shiny AI technology has a half-life measured in months: the specific tools, model names, context-window sizes, pricing tiers, and prompt tricks that are current as you read this will be museum pieces before you graduate. Teaching them as content would be malpractice.

What we teach instead are the skills you will still be using in five years—and, we believe, in ten:

• how to take a vague idea and turn it into precise requirements;

• how to design a system in layers so that its parts can change independently;

• how to use version control not as a save button but as a collaboration protocol—branches, pull requests, and history that tells the truth;

• how to review code—human-written or machine-written—and how to be reviewed;

• how to write tests that come from the specification rather than from the code, and wire them into CI/CD so they run on every change;

• how to build full-stack systems—APIs, databases, frontends—and reason about the seams between them;

• how to think about security and authorization as design constraints, not afterthoughts;

• how to deploy to the cloud and keep a service running;

• how to evaluate and monitor a system whose components are non-deterministic;

• and—running through all of it—judgment: when to trust a tool’s output, how to verify it, and when to throw it away and think.

None of those is an AI technology. Every one of them predates generative AI, and every one of them survives whatever generative AI becomes. What is new is the weighting: AI made the middle of the life cycle cheap, so the surrounding skills are no longer the supporting cast. They are the job.

2.5 The Life Cycle, Reweighted🔗

Let us make the course’s thesis concrete by walking the life cycle and asking, for each phase: what did your education emphasize, what does generative AI automate, and what does this course teach?

Read the second column top to bottom: almost everything except coding was done for you. Read the third column: coding is the phase AI handles best, precisely because it is the phase with the clearest inputs and outputs. The fourth column is the syllabus.

top3 = sorted(scores, reverse=True)[:3]

2.6 What We Will Actually Do🔗

The course is structured around building and shipping real software, with AI assistance at every stage and with the non-coding phases carrying the weight.

• Foundations first. (part "Git") as a collaboration protocol—branches, pull requests, reviews, honest history. A look inside the (part "LLM") so its failure modes stop being folklore (and (part "BuildGPT") for those who want to go all the way down). (part "Claude Code") and the discipline of directing an agent rather than typing at it.

• Full-stack construction. (part "REST APIs") and (part "FastAPI"); (part "Relational Databases"); (part "Layered Architecture") so the pieces can change independently; (part "Docker"); a (part "ReactTS") frontend. This is the “ordinary software” your AI components will live inside.

• Verification as a way of life. (part "Testing") —unit, integration, property-based—wired into CI/CD; (part "Eval") and monitoring, which do for prompts and models what pytest does for functions.

• AI as a component. Running a local LLM; (part "Vector") databases and (part "RAG"); (part "Prompting") and context management ((part "Elephant-Goldfish")); (part "MCP"); (part "ai-api"), (part "ai-frameworks"), (part "chatbot"), and (part "Agents").

• Shipping responsibly. Security and authorization ((part "RBAC-ABAC"), (part "ai-security")); (part "cloud-deploy"); and the maintenance mindset: logs, metrics, and the assumption that you will be reading this code again in a year.

Throughout, you will document your AI usage—what you asked, what you got, what was wrong with it, and what you did about it. This is not bureaucracy. The record of where the tools failed you is the raw material from which judgment is built, and judgment is the course’s real deliverable.

2.7 Project: TerpTop, the Inverted Assignment🔗

Your first project inverts the grading you are used to. You will build the top-three-scores tool from the worked example as a complete, full-cycle micro-repository—and the function body, the only part your old courses would have graded, is worth almost nothing. The specification, the tests, the branch-and-review workflow, and the CI pipeline are worth almost everything. Use an AI assistant for any part you like; you are accountable for all of it.

# TerpTop specification

`top_scores(scores, k=3)` returns the `k` highest scores,
highest first.

Decisions:
- Ties: scores are values, not students; duplicates may all
  appear (e.g. top-3 of [90, 90, 90, 80] is [90, 90, 90]).
- Fewer than k scores: return all of them, sorted descending.
  This is not an error.
- Empty input: returns []. Also not an error.
- k <= 0: raises ValueError.
- The input list is never mutated.

git init terptop && cd terptop
git add SPEC.md README.md requirements.txt
git commit -m "Spec first: requirements for top_scores"
git switch -c feature/top-scores

git add terptop.py
git commit -m "AI draft of top_scores (unverified)"

"""test_terptop.py -- contract derived from SPEC.md, not from the code."""
import pytest
from terptop import top_scores


def test_returns_k_highest_descending():
    assert top_scores([70, 95, 80, 60, 90]) == [95, 90, 80]

def test_ties_may_all_appear():
    assert top_scores([90, 90, 90, 80]) == [90, 90, 90]

def test_fewer_than_k_returns_all():
    assert top_scores([75, 60]) == [75, 60]

def test_empty_input_returns_empty():
    assert top_scores([]) == []

def test_nonpositive_k_raises():
    with pytest.raises(ValueError):
        top_scores([1, 2, 3], k=0)

def test_input_is_not_mutated():
    scores = [70, 95, 80]
    top_scores(scores)
    assert scores == [70, 95, 80]

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest -q

2.8 Rules of Engagement🔗

One principle generates every rule: you are accountable for everything you submit.

• AI use is expected. Assignments assume an assistant unless explicitly marked otherwise. A few fundamentals must be demonstrated solo, and those will be clearly labeled.

• “The AI wrote it” is never a defense. If it is in your submission, you can explain it line by line, and its bugs are your bugs.

• Disclose substantively. Where a tool contributed significantly, say so—in the README, in commit messages, in your usage log. This mirrors emerging professional practice.

• Guard the prompt. Other students’ code, private data, credentials, and materials you have no right to publish do not belong in a context window.

• Verify before you rely. Submitting unread, unverified generated output is the course’s cardinal sin—not because it is cheating, but because it is bad engineering.

2.9 Practice Exercises🔗

2.10 Summary🔗