SE and What AI Changes
COSC 40943 · Senior Design · Week 1
COSC 40943 · Senior Design · Week 1
What should software engineering become when AI is a permanent member of every development team?
Everything for the next fifteen weeks is an attempt to answer that on a real project, for a real client, with your name on it.
Hands up: who used a coding agent this summer?
Who interned?
And the one I actually want: what is one thing you do not like about working with an agent?
That is the prerequisite, not the course.
Programming
Producing code that works.
Software engineering
Everything that makes it the right code, keeps it right as it changes, and lets six people who do not share a brain build it together.
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
IEEE Standard 610.12
The word was coined at a NATO conference in 1968, on purpose, because projects were failing and nobody could say why.
flowchart LR A[Vision] --> B[Requirements] B --> C[Architecture] C --> D[Design] D --> E[Code] E --> F[Test] F --> G[Release] G --> H[Maintain] H --> B
One box of eight. Agents are strongest at that one. You are accountable for the loop.
Fix all three and quality is the only thing left to spend.
"It needs to be fast" is a wish. "A dashboard page returns in under 400 ms at the ninetieth percentile with 200 concurrent users" is a requirement.
You are about to graduate into this. Pretending otherwise would waste your semester.
AI is part of this. It is not most of it.
Those junior jobs were how people became senior. Nobody owns the problem of replacing them.
SWE-bench: a real GitHub issue, a real repository, and a patch that has to pass the project's own tests. Verified is the 500-problem subset screened by hand in 2024.
The benchmark is nearly saturated. That is the news, and we now have to go looking for tasks that are hard.
METR measures how long a task is, in human terms, and asks whether an agent can finish it.
Under four minutes of human work
Agents succeed on nearly all of it.
Over four hours of human work
Agents succeed on under ten percent.
Task length is the single strongest predictor of failure. Everything this course teaches lives on the right-hand side.
Will software engineers be replaced by AI?
Say what you actually think. I am not grading this.
Kent Beck created Extreme Programming and popularized test-driven development. He wrote this the first day he used a language model:
The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x.
The 10%, in his own words afterward:
This is the four-hour column. Beck said it two years before anyone measured it.
You will not be replaced by AI. You will be replaced by someone who can use AI.
It multiplies whatever judgment you feed it.
Zero multiplied is still zero.
A wrong premise in, and the wrong thing arrives complete, tested, documented, and spread through the codebase.
Worse than nothing, because undoing it now costs more than building it did.
Execution is abundant. Judgment is scarce. Agency is the differentiator.
Knowing what good looks like without needing a rubric.
Taste is what lets you reject work. Without it you approve whatever arrives.
AI makes it easy to look competent without being competent.
Polished output. Shallow thinking. Confidence growing faster than competence.
Not one of them is typing.
Postings in 2026 list AI-assisted development as a requirement, not a perk.
"Familiar with AI coding tools" is now the same kind of line "familiar with version control" was in 2010.
flowchart TD C["Executive chef: you"] --> M["The menu: spec and design"] M --> S1[Saucier] M --> S2[Poissonnier] M --> S3[Pâtissier] S1 --> P["The pass"] S2 --> P S3 --> P P --> V["Service"]
Nothing leaves the kitchen without crossing the pass. The pass is code review, and you are standing at it.
An agent can write it. You are the one who signs it.
The explanation test: if you cannot explain it, you did not review it, you forwarded it.
Six students. A real client. An agent on the team from day one.
Watch what happens to them, and hold one question: which of it would a better programmer have fixed?
| The autopsy said | You have a name for it now |
|---|---|
| Nobody wrote down what "done" meant. The client was there once. Features nobody asked for. | A requirement is agreed and verifiable. Anything else is a wish. |
| No plan, so nothing could be behind. One person's absence stopped it. Quality is what got spent. | Fix all three corners and quality is the only thing left to spend. |
| Six branches, one integration. Nobody read anyone else's code. "Almost done" was never checked. | Nothing leaves the kitchen without crossing the pass, and you sign what leaves. |
| Every one of them arrived sooner and bigger. | The amplifier does not check whether the premise was right. |
Not one of the nine is a programming mistake, and every one of them has a name you learned this hour.
Friday is not optional, the MVP is not optional, and "the agent wrote it" is not a defense.
flowchart LR
A[Business need] -->|human| B[Requirements]
B -->|agent drafts, human approves| C[Design of record]
C -->|agent| D[Code]
D -->|agent| E[Tests]
E -->|human| F{Is this the right thing?}
F -->|no| BThe agent is fluent on every arrow. It has no opinion whatsoever about the diamond.
| Stays human | Goes to the agent |
|---|---|
| Requirements quality, scope, vocabulary | Use case to design-of-record |
| Business constraints, domain knowledge | Approved design to code and tests |
| Quality attributes, "good enough" | Cross-document consistency checks |
| Decisions that are hard to reverse | Mechanical transformations |
| "Is this even a good idea?" | Drafting, refactoring, explaining code |
If guessing it wrong would violate a requirement, the human pins it. Otherwise the agent derives it.
Both extremes are wrong answers. Delegate everything and you build the wrong product at speed. Keep everything human and you throw away the one advance that makes the rigor affordable.
Call out a task from your project. We place it on the boundary together, and you defend the placement.
A programmer's spouse says: "Go to the store. Get a loaf of bread. If they have eggs, get a dozen."
He comes home with twelve loaves of bread.
Before
A vague requirement met a developer who asked a question, or built it slowly enough that someone noticed.
Now
A vague requirement meets something that never asks, never stalls, and produces two thousand confident lines before lunch.
The gap in a specification does not disappear when you hand it to an agent. It gets filled, silently, by something with no stake in the outcome.
You: Peer evaluations submitted after midnight save with the wrong week number. Find it.
Agent: Found it, the week is resolved from the server's local date. I can fix that. This class also has no tests and mixes date logic with persistence. Refactor it first?
You: Sure, that sounds cleaner.
Agent: Done, date logic extracted. While I was in there, the repository runs an N+1 query on every submission. Add a caching layer?
You: Go ahead.
Agent: Cache added, with eviction. This needs per-environment configuration. Set up the profiles?
You: Yes.
Agent: Profiles added. Note that Docker Compose does not pass the new variables yet...
Forty minutes. Six hundred lines. Three new abstractions. Evaluations after midnight still save the wrong week.
| Automation bias | Agenda capture | |
|---|---|---|
| What happens | You accept output you did not verify | You work competently on what does not matter yet |
| The tell | You cannot explain a line you shipped | You have stopped asking questions of your own |
| The move | Verify against the spec, not the code | Kill the session, do not redirect it |
Twenty minutes, an unfamiliar problem, a defensible rough judgment.
Fixed order. Prompting the agent first destroys the exercise, because you cannot un-see its answer.
TCU Facilities wants a page showing students which campus lots have open spaces right now. Eleven lots, about 7,000 permit holders. Every lot already has entry and exit gates that count vehicles for the parking office, and those counts land as a CSV on a Facilities file share every fifteen minutes. There is no budget for sensors and the gates cannot be changed. They want it live before spring registration, and a Dean has already promised it in a newsletter.
Five minutes. Alone, silently. No agent, no neighbor, no phone. Six lines: shape, hard part, bottleneck, stack, three kill risks, verdict.
Shape: a batch data pipeline with a thin read-only page on top, not a real-time system. Eleven rows of state, 7,000 read-mostly users.
The hard part: the gate counts are not occupancy, and the error compounds. Tailgating, motorcycles, propped gates, exits with no matching entry. And "right now" is a fiction: the freshest data is fifteen minutes stale, at exactly the hour it matters.
Bottleneck: trust, not throughput. One morning of "40 open" at a full lot ends adoption.
Stack: Spring Boot, Postgres, a small Vue page, Azure. Anything fancier solves a problem this system does not have.
Kill risks: data access never lands · a wrong number under a Dean's promise · scope creep.
Verdict: feasible, under-scoped if you count only the software. Cut "now" first: say "as of 8:45am, roughly 40 spaces (estimated)".
Thirty seconds, and it found the hard part.
Risk bingo
"Scope creep." "Technical debt." "Integration issues."
Nouns. Unfalsifiable. Zero points.
A mechanism
"The client's volunteer list is a shared spreadsheet, so two people editing it on Saturday silently overwrite each other."
Specific. Testable. Points.
These slides are the fast version.
The SE and What AI Changes module has the full argument, the reading list, and the discussion questions.