Notable verbatim quotes

⚠️ All quotes preserved verbatim from a heavily speech-to-text-garbled source. Bracketed clarifications added only where essential.

On why vibe coding breaks down

• agents-incorrect-with-confidence — "you will never say that agents. Will be constantly incorrect. So they confuse exactly the wrong thing. It would be very confident." (Section 1)
• review-erases-speed — "This is where my coding kind of hits the wall. Is unless you're spending a lot of time with the input outputs. Which then. Way slowly down anyway. So you move all that benefit. Speed." (Section 1)

On the spec as contract

• spec-as-contract — "the spec is more about you're planning out the work that needs to be done. You're setting up that contract between human and AI to develop new way which is safe and reproducible." (Section 2)
• reproducible-outcome — "this eventually again called outcome. It'll be exactly the same over time. You can get the same outcome. Whereas with bipoding, yeah," (Section 2)

On the AI-engineering shift

• unit-of-work-shifts — "It changes the unit work from rain code [writing code] to client intent. So you're telling the AI what intention is you're not telling it what you necessarily want to look like." (Section 3)
• influencer-to-orchestrator — "You're moving from being an influencer to orchestrate maintenance. So you still understand code, but actually you want to get out of the way of the AI agent" (Section 3)

On verification

• crisp-verify — "we have this crisper verify. We trust it can come up with the right output and spectralized. But we verified that the RP lines. Because like I said, AIs can be completely correct." (Section 4)
• layered-verification — "You can have like layers and layers of verification starting from deterministic aids that a interviewer sat on top of each other. And at that point you don't have to review any more line by line." (Section 4)

On guardrails

• strong-batteries — "So we try to start tooling on top. So that our agent has very strong batteries." (Section 5)

On Spec Kit specifically

• four-phases-and-lightweight — "for stages, four artifacts we're going to be using Spekit. It's a lighter weight framework. Some of the frameworks which are b matched [BMAD] will take days or even weeks to figure out how to use it properly." (Section 6)
• what-is-done — "So what has done? What's good enough? Because it's very easy to just specify the range of code frame." (Section 6)

On model selection

• strong-then-small — "use a very powerful model initially like the office [opus] lab model and that is slightly smaller model like sonnet or something like on those lines for the actual implementation." (Section 11)
• intelligence-up-front — "it seems a little bit more counterintuitive but the moment where you need more let's call it intelligence like however you want to call it. Is the first part not the final one." (Section 11)

On problem-space vs solution-space

• problem-vs-solution — "we try as much as we can to keep the spec in the problem space not the solution space. So in spec is defining the what and then the implementation plan should find the how" (Section 12)

On requirements & EARS

• ears-format — "I usually use this format write requirements. Which is basically a template that you can use to say when this happens I want that" (Section 15)
• ask-me-questions — "ask me as many questions as you can. To understand better the requirements to surface edge cases to like help me think about things that I did the ticket" (Section 15)
• two-criteria-too-few — "imagine if you go on jira… you have to implement the story and this story has two acceptance criteria which are. The user has to log in. It doesn't have to break. How do you implement that?" (Section 15)

On spec slicing

• thin-slice — "ideally a spec should be like if thin slice of your system and it should both contain functional requirement and non-functional requirement of that thin slice" (Section 18)

On living specs

• two-types-of-specs — "there are like two types of space the spikes that you create and you maintain which is more similar to living documentation. And the [specs] you use to help your thinking" (Section 14)
• ten-percent-worth-keeping — "in one of my projects I should have something about something like 200 demeterrated spectrum. I think only like 10% of it is worth like taking over." (Section 14)

On adversarial review

• fresh-context-adversarial — "we start from a new content window that's important we start from a new context window and we say you have to run an adversarial… you have to find inconsistencies find blind spots missing edge cases" (Section 23)