Lecture 3: Vibe or Spec
Effective AI use in applied machine-learning projects
Outline
A. from vibe to spec
B. why vibe
C. why spec
D. writing (or vibing) a spec
vibe coding
spec-driven development
both ends got popular in 2025
same arc
anigans: my (very virtuous) horcrux
This bio and this diagram were what i started with as the "system design"
private, secure distillation of my knowledge
🧑💻
👩💻
👨💻
🔁
🔁
logistics
notation, formatting
data analysis
anigans self-portrait of its origin
\left\{
\begin{array}{l}
\\
\\
\end{array}
\right.
the harness (we will talk more about this in week 5)
I then got lured by
Gradually, I realized:
1. anigans did not need what either could do -- both were overkill.
2. Neither runtime helped anigans do what I wanted her to do. Both were overkill and not enough at once.
3. I also don't understand these runtimes well enough to trust that I can extend anigans to more use cases.
a novelty, not so reliable (during my use). sometimes anigans did not answer, sometimes an upgrade required tedious patching, sometimes the whole system went offline without notice...
Now, just specs + scripts on bare metal
The spec came last
A doc or a spec is important, but it need not reproduce the chronological order in which decisions were made.
For anigans, one requirement was clear from the start, that it could only ever be staff-facing.
The rest I could not have written upfront. It ran in the real order: vibe, learn from failure, write lessons into specs, then vibe again where it helps.
Aside: you asked about agentic AI tooling
my repo has breadcrumbs
15min AMA
we will do another one in lecture 4 (after we think more about our project and what use case and need we may have)
Outline
A. from vibe to spec
B. why vibe
C. why spec
D. writing (or vibing) a spec
Describe roughly, accept quickly, iterate by feel.
Write down what the thing must do before any code, then test the code to it.
Neither end is wrong:
- A script that makes an expected animation clearly belongs near vibe.
- A system other people depend on clearly belongs near spec (eventually).
What is wrong, to me: defaulting to one end for everything without reflection.
vibe coding
spec-driven development
Picking the point on the spectrum, per step in the project, is the important judgment call.
Both ends are actually almost as old as computer science
Two steps are “all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it.”
“the waterfall paper” says build it twice
“I believe in this concept, but the implementation described above is risky and invites failure.”
Its fix adds a pilot run first, “Do it twice.”
Sometimes the biggest risk is building the wrong thing
When you don’t yet know what would be useful, try a rough version. Use what you learn to decide what to specify.
When the risk is getting known behavior wrong, state that behavior and check it.
Requirements come from iteratively trying versions
Vibe coders find requirements in the output
Vibe makes each version cheaper to build and try.
The discovery still comes from trying them.
🙋 Which one of these live streamers would you want to be?
What else would you want to know before casting your vote?
Outline
A. from vibe to spec
B. why vibe
C. why spec
D. writing (or vibing) a spec
ad (and graffiti) as seen on an MBTA train, 09/2026
I'd say "Vibe code without the fundamentals"
the same paper from before that studied vibe-code live streamers
It costs time and accuracy to "refine" the spec while prompting
the same instructions, given at once, versus one piece per turn. agents get lost in the back-and-forth (as humans do)
Models guess the format and miss the corner case
Stating requirements does not guarantee that the model follows them. Adding more instructions can make some harder to follow.
Implementing a change and choosing the change are different tasks
The instruction matters.
My view: of the shortcuts for judging a stranger's repo, the spec may be the last one standing
i used to rely on small things like a clean .gitignore as a (pretty reliable) shortcut.
now, clean .gitignore doesn't mean much... (meanwhile, some AI-code-critique papers' own repos don't ignore `.DS_Store` ... ... 🫠)
A signal separates people only while it is costly to fake.
Outline
A. from vibe to spec
B. why vibe
C. why spec
D. writing (or vibing) a spec
Spec-first no longer needs to be faked
an agent can now turn "something" into code.
that "something" becomes the main place our intent enters the system.
if we're casual about that "something", the agent can fill the gap with just the most statistically typical intent -- average coder behavior.
might as well inject that "something" as a spec instead of a careless prompt.
note: spec well is not easy, and human review throughout
an agent can even draft the spec -- when it's that easy to spec, what excuse is there not to?
Prompting advice already asks for a spec
Refine the goal until each part is concrete enough to act on
The bold boxes mark those concrete goals.
Each can be assigned to one agent.
Specify who does what, and what they act on
not just for multi-agent systems.
each box can also just be one function that does one thing, and does that one thing well.
good old divide-and-conquer and modularization
e.g., this skill's vague goal: keep me informed and help me navigate the field.
Choose one part of the goal to specify
Keeps me informed and helps me find my way through the field.
-
Notice new sources. An LLM screens the feed and the venues.
-
Judge each source. I decide, with the LLM’s triage as a draft.
-
Keep decisions findable. The LLM files each call, and a script commits the shortlist.
What would count as doing this part well?
A spec can describe research, evaluation, or code.
Spell out the behavior that would be costly to get wrong.
identify ambiguity and clarify
e.g. For [1, 2, 2, 3, 4, 4, 5], what should we return?
Keep one of each → [1, 2, 3, 4, 5]
Remove all occurrences of repeated values → [1, 3, 5]
For our feed, does "new" mean unread or published since the last sweep?
Ask the agent to surface missing decisions
“Without explicit prompting, models almost never interact, even for severely underspecified inputs.”
Try: “Before writing code, list the decisions this spec leaves open, and ask me about the ones that change behavior.” Then write the answers into the spec.
Make requirements checkable, and choose tests that catch plausible gaps
“Fast” needs a workload and a time limit.
When the feed is unavailable, the sweep shall report the failure and write no list.
Screen unread entries.
Old + unread → screen.
Recent + already read → skip.
Give examples when words are insufficient
Give examples when definitions may really be impossible
Readers should agree on which outcomes the spec allows
-
Give a partner the spec and a concrete case. Ask which outcomes it allows and which it rules out.
-
Clarify disagreements about what is allowed. Several outputs may satisfy the same spec.
-
Lab 3 practices this with a partner.
Check the result against both the spec and the goal
Build one increment and try it.
If the result misses the goal, ask what needs to change.
-
The code breaks a promise. Fix the code.
-
The spec misses the goal. Revise the requirement.
-
Use reveals a new need. Decide if to add it.
6.S950 - Agency with AI (Fall 26) - Lecture 3: Vibe or Spec
By Shen Shen
6.S950 - Agency with AI (Fall 26) - Lecture 3: Vibe or Spec
Agency with AI, Lecture 3: Vibe or Spec
