Definition of Done - why it exists
In Scrum we have a Definition of Done. Sounds bureaucratic. In practice it's something very simple: an agreement between people about what the word "finished" means.
Without a DoD, everyone has their own definition of done.
For one person "ready" means: works on my laptop. For another: passed tests. For a third: it's in production with monitoring. For the client: it solves my problem.
Those four definitions can differ drastically. And they do, more often than we'd like to admit.
I worked with a team that closed sprints with a green board for half a year. All stories "done." Everything worked at the demo. Then the client came and asked about one specific system behavior. Silence. "That's on the to-do list." "But it was in scope." "Well... if you look at it that way..."
DoD isn't bureaucracy. DoD is the answer to the question: what does it actually mean when I say "I did it"?
DoD for prompts - what it looks like in practice
Vibe coding has a problem that not many people are naming out loud yet: the default DoD is "it works." Starts up, displays something on screen, doesn't crash immediately.
That's a very low bar.
Karpathy himself says it - vibe coding works great for prototypes, exploration, one-off tools. But what happens when the prototype goes to production? And it always does. It always goes.
A proposal that's been stuck in my head: DoD in the prompt. Not as a separate document. As part of the task description.
What does that look like in practice?
Instead of: "Build me a user login component"
You write: "Build me a user login component. Quality requirements: unit tests covering at least 80% of the code, zero known vulnerabilities (OWASP Top 10), documentation for all public functions, code ready for human review."
Still vibe. Just with a spine.
DoD checklist for a prompt - the minimum worth covering:
- Unit tests (with a defined coverage level)
- Security scan (e.g., no hardcoded credentials, SQL injection, XSS)
- Documentation - at minimum a basic comment on every public function
- Error handling - what happens when something goes wrong
- Code review - even if just "check whether this is readable by a human"
Is this still "vibe"? Yes. Just vibe with a backbone.
Vibe coding + Agile - evolution, not the end
I sometimes hear: "Agile doesn't make sense if AI codes by itself." Or: "Scrum is unnecessary when everything can be done in a minute."
That's thinking with tools, not problems.
Agile isn't about how fast you write code. It's about how you deliver value under uncertainty. How you learn faster than the client changes their mind. How you maintain quality while everything around you is moving.
AI accelerates code writing. The catch: quality, purpose, business context, and the definition of "done" - those are still human questions.
DoD doesn't disappear when AI codes. DoD becomes more important. Because AI generates very fast and very much. And if you don't know what "done" means - very fast you'll have very much bad code.
My answer to "vibe coding + Agile = what?" is simple: it's a new tool in an old process. Just like IDEs appeared once. Then automated tests. Then CI/CD. Every tool changed the rhythm of work - but none of them relieved the team of thinking about quality.
Vibe coding doesn't either. It just makes it more visible when someone isn't thinking.
Intuition needs a frame
There's a paradox in vibe coding that fascinates me.
"Vibe" is intuition, mood, feeling. Something elusive. And that's beautiful during exploration. You want to build something quickly, test a hypothesis, see if an idea makes sense.
But intuition without a quality frame is a bit like jazz without knowing your scales. You can. Some people even claim it's more interesting that way. But a good jazz musician knows the theory - and breaks it consciously. Not because they don't know it.
Vibe coding without DoD isn't creative freedom. It's technical debt packaged attractively.
I fell into this trap myself. Prototype in forty minutes. Amazement. A week later: "Is this secure?" I didn't know. I had to start over. This time with a list of quality requirements in the first prompt.
Faster? Paradoxically, yes.
A question to close with
Your team has a DoD. Great. But does that DoD say anything about AI-generated code?
Who in your Definition of Done is responsible for the quality of something nobody fully wrote - and nobody fully understands? And more broadly - who should be defining DoD for AI-generated code? The developer? The tech lead? Someone from security? That's not a rhetorical question. It's a decision worth making before the prototype hits production - not after.
If you haven't talked about this with your team yet - maybe now's a good time to start. Before the next forty-minute prototype lands in production.