The Cure for the Vibe Coding Hangover

[upbeat music]

Inspiration strikes. You've got an idea, and you know exactly how you're going to build it.

You fire up your favorite AI coding agent, you jam in those prompts, and then you hand it over.

Hey, look at him go. He's done it. That is to say, you've done it. The app works. This is what ten-X engineering really feels like. You're a genius, a rebel in the AI revolution.

But then Monday rolls around. You want to add a feature, or you want to change the way that it works, and you realize that you don't understand it, you can't maintain it, and you have to throw most or all of it away.

Vibe coding is the low-spec, zero-planning approach to AI-accelerated development that feels productive but results in brittle, unmaintainable demo-ware. The hangover is the resulting despair when you try to build maintainable, understandable software this way.

Don't worry, though, there is a cure, and it's the framework for building with AI coding agents that we're going to discuss today.

So you'll enjoy this talk if you value programming as a daily learning experience. If you want to understand and own the software that you write using AI coding agents just as you do all of the other software that you write.

If you want to be the boss of the coding agents and not their confused intern. If working with agents makes you feel like a prompt jockey these days and no longer an AI engineer.

If you're sick of throwing away code, burning time and tokens. Or if you want to use coding agents to build production applications that do real work.

On the other hand... [laughing] It's not for you, Jen. [laughing]

It's not for you, Jen. [laughing] It's not for you, Jen.

This talk is not for you if programming is a job and not a craft that you're refining and that works for you. If you're satisfied just having AI do it for you without needing to understand how or why.

Or if vibe coding gets you what you need and that's good enough. And these statements aren't a judgment. They're just very different paths than what we're taking today.

I'm Corey. I run an AI native holding company where we're actively buying and building businesses in the technology, investments, and education verticals. I've been feverishly building AI coding agents since two thousand and twenty-two.

I love and am passionate about all things technology. I am a massive coffee nerd. In fact, catch me in the hallway track and ask me about the Ethiopian Yirgacheffe from Misty Valley that I've been obsessively roasting lately.

And I'm a pickleball fanatic. I'm playing in a tournament tomorrow, in fact.

So let's talk about the framework in overview. The framework's comprised of three pillars. There are the principles which are the philosophy underpinning all of it.

There is the process which is the workflow for actually getting software built using AI. And then there are tools which are accelerators or enablers of the process but also reflect our principles.

So you may ask, what can you build with the framework? And the answer is really anything. The framework's adaptive to all types of software, but here are a few examples of working software in the wild right now that's been built with this approach. [clears throat]

Uh, specialized litigation support applications for law firms,

real-time appliance monitoring packages for cooking, digital publishing systems for dynamic content replatforming, and on and on and on and on. The point is that these aren't toys.

These are real software applications that do real work every day. And critically, they're evolved and maintained by AI engineers who apply this framework.

So let's make a start and get into the principles. Principles broadly map across three categories. Sort of general principles that apply overarchingly, and then principles that skew more towards the planning phase of the process, and principles that skew more towards the implementation phase of the process.

Ten in all, [clears throat] so let's talk about each of them. Our first overall principle is that AI engineering is accelerated learning. And what were the problems that this came from?

Well, treating AI coding agents as pure productivity tools just to crank out code faster. Using AI to generate software and not learning anything from the process. And then six months later being no better as engineers, having plateaued.

Or worse, becoming dependent on AI for so many things, debugging, modifications, architectural decisions. That's the opposite of AI augmentation. That's AI dependency. So the big idea here is that the framework is not just about building faster, it's about learning as we go.

Every step in the framework creates specific learning opportunities so that you're not just shipping software, you're building yourself. The software is valuable, but the engineer that you become is exponentially more valuable.

And that's why we say always be learning. Or you may say A always B be L learning. Always be learning.

Our next general principle is that you are the architect and the agent is the implementer.

Treating AI agents as replacements for architectural thinking rather than implementers of your decisions when they're well specified is a big problem. So the primary idea here is keep the architect and implementer boundary crystal clear.

You own the thinking, and that means architecture and interfaces, the intent of the system, the structure, [clears throat]

design decisions and the associated trade-offs. And then the agent handles the doing. That's implementation, typing code, following patterns, implementing the tests that you specify and banging out boilerplate. That's why we say delegate the doing and not the thinking.

Our third general principle is a little bit counterintuitive, but it's slow down and iterate in order to go fast.

The problem is the starting over cycle. Without deliberate iteration on validated work, you end up repeatedly starting from scratch. And so three months in, you've had multiple abandoned attempts instead of consistently improving on one single system.

So the big idea here is that deliberate iteration enables compounding returns on both understanding and on productivity. And so yeah, week one feels slow, but week two builds momentum and then week three is dramatically faster.

We say compound progress, accelerate velocity. So the first of our planning related principles is that specification is far greater than prompt engineering.

Prompt engineering treats AI interactions as an optimization problem rather than a communication problem. Trying to find magic words that produce the right output rather than clearly defining what right means.

So the big idea here is that specifications are very different than prompts in the classic sense. Specifications are structured, precise definitions of requirements of behavior, interfaces and acceptance criteria.

Writing specifications forces architectural thinking. You must understand the problem completely and then define interfaces precisely and anticipate edge cases.

In turn, specifications provide clear, unambiguous direction. The agent implements what you specified and not what it interprets from conversational prompts.

We say write the blueprint, not the prompt.

Our next planning related principle is define done before implementing.

Starting implementation without executable tests and observable success criteria means that agents lack clear completion criteria and immediate feedback. They can't self-validate, they can't self-correct, and they don't know when they're done, at least not in consistence with your specifications.

And so the big idea here is defining done before implementation keeps you thinking deeply about requirements, and then it enables the agent to work autonomously. By defining tests up front, we give agents clear stop conditions that then enable them to get immediate feedback during implementation and self-correct wherever

necessary. We'll talk more about multi-sensory validation later, but we enable agents to observe through visual, like what renders, sensors, auditory sensors like what they can hear through logs and errors, and tactile sensors, meaning how they interact with the system.

Tests verify correctness of spec-- of implementation, whilst sensors reveal the actual behavior of the software as it's being implemented. And so done means that a feature is done when its tests pass and when the sensors come back validating that everything's working as expected.

We say specify success, then build. Feature atomicity is our next principle.

Writing non-atomic features means leaving the decomposition work for implementation time, which forces agents to make architectural decisions on the fly. The primary idea here is that feature atomicity forces us to completely decompose each feature during specification, and then in turn enable the agents to implement

within a manageable scope. Features in this sense become implementation work units. They're atomic, irreducible tasks that are ready for an agent to execute completely. Keep features as small as possible to make agent implementation as successful as possible.

We say reduce until irreducible So the last of our planning related principles is dependency driven development.

Implementing without explicit dependency analysis means treating all features as independent, when in fact we know that they form an interconnected graph. So the big idea here is that dependency driven development forces you to understand how features relate and how they integrate, and then in turn, that ensures that agents never implement features that depend on incomplete work.

We say schedule implementation by dependencies. And so now onto our implementation related principles. We start with implement one atomic feature at a time.

Working on multiple features treats implementation as parallel streams of work that can be context switched freely. But we know that implementation quality is contingent on sustained focus, complete context, and very tight feedback loops.

Jumping between features fragments our focus. So the big idea here is that agents implement one single feature that's been defined atomically as previous. You study it and understand it.

You validate that it works, you commit it as a checkpoint, and then you move on to the next feature. This rhythm creates both momentum and also deepening understanding. We stop juggling multiple features simultaneously.

We implement features sequentially with complete focus, studying each implementation to maintain understanding, and then commit each of them as a checkpoint to build both working software and engineering knowledge.

We say complete one, commit one, continue. Our next implementation related principle is context engineering and management.

Treating context as something that just happens automatically rather than something you actively engineer is a big problem. You let conversation history passively accumulate instead of curating actively what really matters for context.

And then if you don't build context resilience, state will not persist eventually, and we lose resilience and continuity to that matter. So the primary idea here is do not rely on conversational state persisting.

Capture architectural decisions in persistent documents like specifications, plans, and design documents, and we'll talk about what those mean here in the process section, and then build context from these artifacts, not from your memory.

We say curate context, don't accumulate it. And our last principle is make it work, make it right, make it fast. And this is borrowed from the annals of software engineering.

But treating all three phases of this as equal from the start or trying to achieve them all simultaneously is a big problem. The framework focuses on getting to make it work, working software that can be shipped and used, and then only after real usage reveals what matters do we selectively invest in make it right and make it

fast. So the big idea here is stop pursuing elegance and performance upfront, explicitly direct the agents to make it work, and we'll talk about how to define that. But we want simple functional implementation that passes tests and enables us to ship quickly and then let real usage reveal what deserves further investment.

We say burn-- [chuckles] Sorry. We say build, learn, improve. So there we have them, our ten principles.

The philosophy that makes the framework work. Now let's check back in with our hungover vibe coder as he's been exposed to the principles of the framework.

Yeah. Mind sufficiently blown yet? Well, stick with us, mate. It gets even better.

All right, now let's transition to process. The process is where we put all of the principles to work. You can think about this as principles in action. The framework process has two distinct phases.

There's the planning phase, where you do all of the architectural thinking to define what to build, and then the implementation phase, where the agent executes your specifications with both your oversight and validation.

Planning produces the artifacts that enable autonomous agent implementation. Implementation then uses those artifacts to build working software feature by feature. All right, on to the planning phase.

Planning is where you complete your architectural thinking. You transform a vague project idea into atomic, sequenced, fully specified features ready for implementation. This is purely your work, architectural decisions, decomposition, specification writing, dependency analysis.

The agent can assist as a thinking partner, but you make every decision.

The five planning steps are sequential and build on each other. Vision, features, specification, dependencies, plan.

You'll notice that this is a highly iterative process of extracting and refining thinking into tangible artifacts that can be used to build software with the agent. The inputs and outputs of each step in the planning phase are templates and completed templates, respectively.

Heaps of work has been done in advance to create well-thought, well-structured templates to both guide thinking and capture the results.

So the first step of planning is vision capture, and the purpose of this step is to transform your vague project idea into a complete, structured master project specification that articulates the problem, the users, functionality, scope and workflows.

So the problem that this step in the planning phase solves is that your initial project idea exists only in your head, usually, and it's incomplete. When we start, this is typically the case.

You have some general sense of the problem and an approach, but details are fuzzy, implicit assumptions are unexamined, and critical aspects are uninformed. So without structured exploration and refinement, you can't communicate your thinking, you can't articulate requirements clearly, and you can't create a shared foundation that agents can build upon.

You need to examine and refine your thinking before you can decompose it into features or architecture. And so what we're going to do here is think out loud with an agent, optionally, but strongly recommended, to refine and capture your vision through five sections.

Project purpose. So we clarify the pro-- the problem that you're solving, who experiences it, and the core value that your software delivers. Essential functionality. Identify the three to five fundamental workflows that solve the problem.

Scope boundaries. Make explicit decisions, and we call these now, not next. So now, as in must have it for the make it work version, not meaning it's out of scope and next meaning future enhancements.

Then technical context. Answer basic questions like where does it run? How do users interact? What systems does it connect to? And then lastly, workflow details. So for each of those three to five core workflows, document the goal, document the high level steps for each of the w-- of the workflows and then the expected outcome.

And we iterate through these sections until your vision is clear and complete. Working with an agent here is really great because it can help surface gaps, suggest edge cases and probe assumptions, but critically, you make all decisions about the vision.

The primary output of this step is the master project specification. This is a structured artifact that captures your complete vision for the software in its make it work version.

This becomes the foundation for extracting features in planning step two. And as we go through every step in the process, you can see down here on the bottom left corner which of the principles are applied in that step.

We won't talk through each of the principles, but this demonstrates the cohesiveness of the framework.

All right. Step two in planning is feature identification and categorization. And the purpose of this step is to systematically extract all units of functionality from your master project specification and then organize them into a categorized feature inventory.

The problem that this solves is you don't jump directly from high level vision to detailed feature specifications. That's too big of a leap. Your master project specification captures what the software does at a high level, but you need an intermediate step that progressively refines this thinking into concrete, manageable units of functionality.

Without systematic extraction and categorization, you're trying to specify features without a complete inventory of what needs to be built, and you can't see natural groupings and relationships. You lack the structured artifact that's needed for the next refinement step, and you're forced to hold all functionality in your head rather than externalizing it for analysis.

The input to this step is the master project specification from the previous step. And so what we're going to do here is systematically analyze the master project specification to extract all units of functionality and then categorize them.

So work through the master project specification step by step or section by section rather with targeted extraction questions. So it's like for project purpose, what foundational capabilities does this system need?

For essential functionality, what discrete capabilities are required for each of the workflows? For scope boundaries, what infrastructure is needed to make the make it work version work now? For technical context, what platform integration and interface features are needed?

For each of the key workflows, what handles input? What processing occurs? What output is there? Which errors should we anticipate, and how do we feed back? And then cross-cutting needs across all of this, what security, logging, configuration and testing features span the entire system?

We're gonna document each feature source for traceability, and that's where it came from in the master project specification.

Next, we build the raw feature list. So we capture every capability that you identify, but we're not gonna organize these just yet. Just ensure that we have comprehensive extraction.

We wanna challenge completeness with questions like what handles errors or what validates input, what provides feedback?

Next, we move on to analyzing those features. So we analyze the entire feature list to start identifying natural groupings. Based on your features and your project type, you identify it's not a hard rule, but three to seven categories that kind of reflect how your specific software is structured.

And then we move on to categorization. Determine the categories. We assign each feature to its best fit category, and then we create a unique feature ID, like for example, Core zero zero one or API one zero one.

These categories emerge from analyzing your actual features and not from predetermined category templates. [clears throat] And then lastly, we estimate feature complexity, and this is just an initial estimate of how complex each extracted feature is.

Is it easy? Is it medium? Is it hard? So the output from this step is the feature inventory. It's a complete categorized list of all discrete units of functionality.

Each feature includes a unique ID, a description, a complexity estimate, and we're able to trace it back to its source section in the MPS.

Step three is iterative specification development. [clears throat] The purpose of this step is to transform each feature from your feature inventory into a complete atomic implementation ready specification that defines exactly what needs to be built, how it will be validated, and what it depends on.

The problem that this critical step solves is you can't jump directly from a feature inventory to feature implementation. That's again, too big of a leap. So your feature inventory lists discrete capabilities, but each feature still needs to be fully specified before a coding agent can implement it.

Without iterative features, [clears throat] sorry, without iterative specification development, you're giving coding agents high level descriptions and hoping that they infer details correctly. You can't validate that features are truly atomic until you try to specify them.

You have no systematic way to identify dependencies.

You lack the implementation blueprints that enable autonomous agent work, and ultimately, you're relying on prompt engineering instead of comprehensive specifications.

The input to this step is the feature inventory from the previous step. And so what we're going to do here is collaborate with an agent to transform each feature using a three-level refinement pattern.

So first we draft a user story in the typical user story fashion. As a user type, I want to perform some action so that I can obtain some benefit.

This captures who needs this, what they're doing, and why it matters.

Next, we def-- determine our implementation contracts, [clears throat] and these exist in three iterative levels of refinement. So we start at level one in plain English. Just describe what the feature does in natural language.

Walk through what happens, what it receives, what it does, and what it produces. We then take that [clears throat] and refine it further to level two, to logic flow. Kind of the input logic output.

We translate the description into structured pseudocode with clear input, step-by-step logic, and then defined output. And this really forces clarity about what comes in, what happens, and what goes out.

And then we refine further to level three, which is formal interfaces. And here's where we define and formalize contracts with exact signatures, data structures, and API specifications. We define exact input types, return types, and errors for each component.

Next, we move on to specifying validation contracts.

And again, we do this in three levels. Level one is once again plain English. So we describe the scenarios, identify all situations that need validation, happy path, error cases, edge cases, security properties.

We then refine that to level two, which is our test logic, and we use given when then structure for that. So we translate each scenario into structured verification logic with setup, trigger, and expected outcomes.

We further then refine that to our third level, which is once or analogous to the previous step, formal test definition. And so this is where we define exact test interfaces with setup, inputs, precise assertions, and any teardown.

And at this point, we need to validate the atomicity of the feature. We need to make sure that the feature can be implemented in a single focus session and that it is truly one atomic feature.

We've defined feature atomicity previously, but if this feels at this point like the specification is scattered or it defines or describes multiple capabilities, we're going to split the feature into multiple features and then repeat the process.

Then lastly, after we've de-- uh, determined that the feature is atomic, we're going to identify dependencies, and this is now where we really determine what other features must exist before this one can be implemented.

We document explicit binary dependencies, meaning this either depends on another feature or it doesn't. There's no partial dependency.

The output for this step in the process is a complete atomic feature specification for every single feature in the feature inventory. And that spec defines the user story, the technical blueprint, which again is comprised of those three levels, the validation strategy and its three levels, all of the dependencies, and any implementation

notes. Step four in the planning process is dependency analysis. And so here the purpose is to transform our complete set of feature specifications into a validated dependency matrix that will then define the exact order in which features can be implemented.

This eliminates circular dependencies and reveals very natural phases of implementation.

The problem that this step in the process solves is severalfold, but your feature specifications contain accurate dependency declarations, but these dependencies are scattered across individual documents. So you've got a local picture, like feature X depends on feature Y, but we don't have the global picture yet.

And without this global view synthesized into a dependency matrix, you can't see the complete dependency graph, detect circular dependencies that span multiple features, identify the natural implementation phases where groups of features can be built together, or determine which features must be implemented first versus which can wait.

So the input to this step is the feature specifications, or sorry, are the feature specifications with dependency declarations that have come out of the prior step.

So what we're gonna do here is synthesize scattered dependency declarations into one unified matrix, and then we're going to validate it. So we start by extracting the matrix. Here we gather all dependencies from individual feature specifications into a visual grid.

So each row is a feature and each column is also a feature. And then we go row by row and mark an X where a row feature depends on a column feature.

Next, we generate a graph. So we create a visual diagram using Graphviz or Mermaid or you pick it, from the matrix showing features as nodes and dependencies as edges.

The graph makes circular dependencies immediately visible as closed loops and reveals the natural layered structure of the dependencies of the application.

Next, we validate and clean. So we apply the binary dependency test to every marked dependency and that goes something like, does the row feature require the column feature's specific output, configuration, or functionality to work?

If yes, then yes, it's a dependency. If no,

then remove it. And we track changes in the matrix. And so, like, it may be a technical dependency. Th-this, this step helps us clarify things like maybe coordination only or tool sharing, right?

Like not true hard formal dependencies. And then we go to the next step, we, we regenerate the graph, right? We're gonna kind of iterate this way. And last, we detect cycles.

So we're gonna visually inspect the graph, and the agent can help us here with this too, uh, for circular dependencies. And if we find them, we apply resolution strategies across one of four, but really three steps.

First, we try dependency elimination, meaning let's go back and reexamine it with the binary test. If that doesn't work, then we try revised specifications. So let's revise the interfaces.

We can rethink contracts so features don't need each other's output. Thirdly, we try feature splitting, and so that's trying to fe-- split it down again. May-- This feature may not be atomic.

And then as a last resort, and this is where it gets messy, the consolidation is like the last resort strategy here, but we're not gonna touch too much on that today.

And then we iterate. After each cycle, we update the matrix, we regenerate the graph, and we ch-- recheck for cyclical dependencies until zero remain. The outputs for this step are twofold.

We have a validated dependency matrix, which is again our visual grid that shows complete dependency graph with all circular dependencies resolved, all dependencies validated as technically necessary, and clear implementation layers defined.

And then we have the dependency graph, which is a visual diagram showing features as nodes and dependencies as edges, making structure and layers immediately visible.

The fifth and final step of the planning phase is implementation plan development. The purpose is to transform your validated dependency matrix into a comprehensive phase organized implementation roadmap that sequences features into dependency layers, identifies parallel development opportunities, defines phase completion criteria, and establishes the validation strategies that enable

the implementation loop. The problems that this step solves are that without a comprehensive implementation plan, you face implementation chaos. Despite having complete specifications and a validated dependency matrix, you can't answer which features should be implemented first and in what order.

Which can be developed in parallel. Now we won't talk about that at all today, but it is a feasible accelerator. How do you validate that a group of features works together before moving forward?

And when is it safe to begin implementing features that depend on earlier work?

The input to this step is the validated dependency matrix and dependency graph from step four. And so what we're going to do here is transform the dependency matrix into an executable implementation strategy.

And that begins with us organizing the phases of implementation via a topical-- topological sort. So we organize features into implementation phases based on their depth in the dependency map.

Features with no dependencies become phase one. Features depending only on phase one become phase two. And we continue this pattern creating phases where each phase depends only on previous phases.

We then verify that no features within the same phase depend on each other. And lastly, we identify the critical path, which is the longest dependency chain.

Next, it comes parallel analysis, but we're going to skip that for today.

Next is validation strategy planning. So for each phase, we define binary success criteria, what tests must pass, what integration points must work, how you'll verify that features work together.

And then we establish feedback loops that enable autonomous agent refinement and binary progress tracking, right? Is a feature implemented or is it not? There is no twenty percent implementation tracking.

Think through what could go wrong when features combine, and what validation provides confidence for dependent features in later phases. And then last, we move on to implementation sequencing. This is where we define the complete execution strategy.

So we have phase gates, meaning how is it we determine we're ready and completely implemented a, a given phase and ready to move on to the next one? We have task assignment guidance for the agents.

How-- We need to tell them how it is they're going to select the next feature to work on. In the event that they get blocked, we have blocker management process, where we explain how it is that they handle and resolve these blockers.

And last, we have progress tracking mechanisms that we define. These are at the feature level, at the phase level, and also monitoring the critical path. The output of this phase, or sorry, this step is the implementation plan, and that's a comprehensive phased, organized execution strategy that sequences all features into dependency layers, identifies parallel development opportunities, develops binary

validation gates for each phase, and provides the guidance needed for autonomous agent implementation sessions.

All right. And with that, we're now ready to talk about the implementation loop.

Implementation is where your planning artifacts guide the transformation of specifications into working, tested software. Unlike planning, which is linear and proceeds through five distinct steps, implementation is a tight, rapid loop executed repeatedly for each atomic feature.

Before we get too far into that, though, we need to understand and unpack the multi-sensory feedback loop. This is a really key idea in the framework.

The agent implements code and then it executes it while gathering feedback through these digital senses. The visual sense, and you can think about that as what renders.

The auditory sense, what the system reports, and the tactile sense, how interactions respond. This sensory feedback provides rich diagnostic information about what's actually happening in the application. The agent runs formal tests to validate against acceptance criteria, but by correlating sensory feedback with test results, the agent both understands what failed

from the tests and why it failed from the senses. This loop continues until all acceptance criteria pass and all senses report clean execution.

So step one in the implementation loop is context assembly.

And the purpose here is to transform planning artifacts into a curated context package that enables autonomous feature implementation with a single coding session for the agent. The problem that this solves is that you have atomic features fully specified and sequenced, but you can't just throw everything at the agent and hope it figures out what to do.

Without systematic context assembly, you're dumping entire planning documents into agent sessions, which wastes context window on irrelevant information. This results typically in the agent making decisions without critical context and without you, or less, less frequently, stopping and asking for guidance.

And ultimately, the-- this turns what should be relatively autonomous implementation sessions into a constant back and forth. It wastes context window, and it results in validation gaps. So the input to context assembly is the implementation plan.

Again, only sections that are relevant for the specific atomic feature that's going to be implemented, the feature specification

and all of the referenced dependencies that are specified in that sp-- that specification.

And what we're gonna do here is curate the exact information that's needed for this one atomic feature through four steps. We start with feature specification assembly, and this is where we include the complete feature specification.

And you'll recall that that's the user story, the technical contracts, acceptance criteria, and we at reference using the, that at symbol, right, all dependencies. This is the primary blueprint that the agent will follow.

Our next step is dependency context gathering. So we follow all of the at references in our feature specification, and each at reference points to a defendent-- a dependency feature specification and the actual implemented code.

And that's critical to note because per the framework definition, all dependencies must be implemented previously. So this is both specification and code. We pull these in so that the agent understands exactly what it needs to integrate with.

Next, we move on to implementation guidance, and this is where we extract relevant sections from the implementation plan. So we don't just dump the whole implementation plan in. The agent needs to know things like what phase is this feature in?

What are the phase completion criteria? What's the validation strategy for this phase? We just bring in the sections that contextualize this feature's implementation and its validation. And then last, we enable sensory capabilities.

So we read the feature's acceptance criteria to identify which digital senses are required.

Visual validation language like sees, displays, renders, that requires the visual sense tools. Logging or error language requires auditory sense tools. Interaction language like clicks, submits, completes requires tactile sense tools.

So we're going to at reference the appropriate tool usage guides that we've written, by the way, and we'll talk about this in the tool section, but once per tool so that it's reusable across all features so that the agent knows how to gather the required sensory feedback.

The output from this step is the curated context package. And this is a focused assembly of exactly what the agent needs. The feature specification, dependency code, the-- for any and all features that, uh, this feature integrates with,

relevant implementation guidance, and sensory tool instructions for validation.

And now we're finally here. And note that this is the only one step in this entire framework that is the AI writes code. But now we get to the implementation loop, which is the last step of implementation, and the purpose is to transform an atomic feature specification into working tested code.

This solves a specific set of problems. Without structured implementation, agents will either write all code before testing anything, and that accumulates problems that compound, or they write and test ad hoc without systematic feedback, and that makes refinement a bit of a guessing game.

The write everything then test approach fails because problems accumulate undetected, and you're ultimately debugging multiple interconnected issues at once. The ad hoc approach fails because without comprehensive sensory feedback, you miss problems that tests don't catch.

Tests pass, for example, but the UI doesn't render correctly, or the workflow completes, but errors fill the logs. The feature, quote, works, but user interactions are broken.

So this step solves all these problems through a single multisensory implementation loop. Because features are atomic, the complete informa- implementation fits in one context window. The agent maintains full understanding from start to finish.

There's no context loss, no reconstruction, and no grid-- degraded fidelity. The input to the implementation loop is the context package that was assembled previously. And so what we're going to do here is execute the tight multisensory feedback loop, which starts by writing code.

The agent implements the code following the feature specifications technical contracts.

It translates all three levels of contracts into working code, ensuring interfaces, inputs, outputs, and error handling match the specification exactly. Then we move on to execute and sense. This is where we get comprehensive digital feedback.

The agent immediately executes the code that's been written and gathers comprehensive sensory feedback through the three digital senses based on acceptance criteria requirements. And we've talked about the visual, auditory, and tactile senses that are at, at play there.

The agent captures rich diagnostic information about what's actually happening during execution and then moves on to test and validate. And this is where the agent runs all test scenarios from the validation contract section of the specification, and tests provide binary pass-fail spec, uh, signals against the specifications requirements.

So now we take the output of the last two steps of the loop, and we correlate them all. So the agent correlates signals across all active senses and all of the test results.

Multiple senses reporting the same issue confirms a diagnosis. Conflicting signals behind senses may reveal hidden complexity. But this integrated analysis reveals both what failed from the tests and why it failed from sensory feedback, which enables targeted refinement by the agent.

Mm, we loop and loop and loop until the feature is complete. And the feature is complete if all tests pass and all sensors report clean execution. So there's no errors in logs, there are no UI rendering issues, interactions work properly.

At that point, the feature is complete. Otherwise, the agent refines based on the diagnostic information that's been gathered and loops through the loop again.

When we determine that these convergence criteria are met,

then the feature is complete, and the agent creates an atomic Git commit containing only this feature's changes with a structured commit message including feature ID, specification summary, validation confirmation, and implementation notes.

And at that point, the feature is fully complete, and the code base is ready for the next feature. So the output here is we finally got there. We've got a fully working, tested feature that's passed all acceptance criteria, all tests, and has been validated by all three digital senses, and the feature is ready for integration into the

broader code base. So let's check back in with our vibe coding dev and see how he's faring now that he's been exposed to both the principles and the process of the framework.

Well, it seems that we've even roused the tiger's attention and astonishment here. Minds have been blown. Minds have been expanded. Well, we're rounding the corner now. Let's move into tools.

The framework requires four foundational capabilities that enable work done via the process.

So let's talk about the coding environment. The coding environment is a complete development workspace that supports two fundamentally different types of work that are happening simultaneously: your architectural thinking and planning, and the agent's autonomous cape-- uh, implementation and testing.

And so there are four core components of the coding environment. The first is an AI coding agent, obviously. Next is an execution sandbox, and this is a safe, isolated environment where all agent written code executes and tests are run.

Autonomous implementation requires the freedom to experiment, iterate, and occasionally break things, and the sandbox provides complete development capabilities in a disposable risk-free environment with easy reset and no consequences for failure.

Next, we need an IDE or a text editor, if you must, and I'm going to avoid the holy wars of IDE versus text editor here. You pick the one that suits you.

And last is voice input, and this is the rapid capture system that converts speech to text at thinking speed. Planning work involves externalizing architectural thinking, and that's often incomplete, exploratory, and iterative.

Voice input removes the typing bottleneck, letting you think out loud and capture ideas much faster than typing. I really can't oversell just how massively impactful a good voice input tool is in applying the framework.

Next, we have the multisensory feedback system. This is a comprehensive validation infrastructure that gives agents the ability to observe their implementations through three complementary digital senses. Those being visual, auditory, and tactile.

And it enables autonomous refinement through an analogous breadth of observation that humans use during development. The core components here are visual sense tools, which enable direct observation of what was produced and what exists.

They capture UI rendering, like screenshots or layout and styling, system state, so database contents, configuration, session data, and code structure, which is the actual implementation. Visual observation catches problems that logs and tests miss, broken rendering, incorrect state, and structural issues.

Auditory sense tools. These tools monitor what the system reports. They capture logs, and that's the system narrating its oper-operations, if you will. Errors and warning, and that's problems the system detects.

And API responses, so inter-system communications. And critically, stack traces, like detailed failure information. This diagnostic information explains why things fail, not just that they failed. And lastly, tactile senses.

These tools enable active interaction testing. They simulate and execute user workflows, so that's completing tasks end to end. API interactions, think request response cycles. Performance validation, like response times and resource usage, security checks, and integration testing.

These interactions reveal whether software behaves correctly under actual use, not just in isolated test scenarios.

Next, we talk about context engineering and assembly tools, and this is a systematic approach to assembling focused, complete context packages for AI agents through deliberate cross-references, think declarative linking, slash commands for process automation, templates for structural predictability, and markdown documentation for efficient possible documents.

So let's talk about the cross-referencing system here. This is a declarative linking mechanism that allows documents to explicitly reference other documents or code files or sections that enables automatic context assembly by following these dependency chains.

Most good coding agents will understand and follow these. Then we talk slash commands or whatever the equivalent is in your selected coding agent environment. But these are process automation mechanisms that trigger multi-step framework workflows through a single invocation.

And it's so useful for things like context assembly, for instantiating a template, for implementing sessions, uh, for...

Sorry, for, uh, implementation session initialization. And then the template system, and these are the structured document templates for every single framework artifact, master spe-- project specification, the feature specification, dependency matrix, implementation plan, implementation record.

And these ensure consistent format and completeness. Without templates, you reinvent specification structure every time, and starting from scratch is exhausting. And lastly, Markdown documentation format. We all know what it is, uh, but agents are so literate in it that it's vital to have tooling that rapidly converts inputs to Markdown.

Basically, anything that you want to communicate to an agent should be instantly convertible to Markdown in the tool chain.

Lastly, version control and progress tracking. This is a dual mechanism system that uses, I'm just going to say it, Git for implementation history. Through atomic feature commits and secondly, the implementation plan for feature completion tracking.

These work together to provide complete project provenance and current state visibility. And I will say that this is the simplest form of project tracking. It can get certainly more complex and integrated with other systems than this.

But, uh, for version control, Git or the equivalent, I think that goes without saying, it's like saving progress in a video game. It's obvious and essential. And then the implementation plan with progress tracking, we take that same planning artifact created from a template earlier, and we use it for feature tracking-- oh, sorry, for progress tracking.

So Git will show us what changed and when, but it doesn't show us the project state, and the implementation plan fills that gap. It's a planning artifact that also serves as the progress tracker.

So here's a quick look at my tool stack. I won't spend time talking through it in detail, but, uh, catch me in the hallway, and I'm happy to go through it. [outro music]

All right. Well, if you've enjoyed this talk, and you want the slides from it and other resources, including the soundtrack, I built a site just for this talk. So check it out at vibecodinghangover.com. [outro music]