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 10x 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 wear. 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,

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 2022.

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 yoga chef from Misty Valley that I've been obsessively roasting lately. And I'm a pickle ball 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.

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. 10 in all. So let's talk about each of them.

Our first overall principle is that AI engineering is accelerated learning. 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 6 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 larning always be learning.

Our next general principle is that you are the architect and the agent is the implement. 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 implement boundary crystal clear. You own the thinking and that means architecture and interfaces, the intent of the system, the structure, design decisions and the associated tradeoffs. And then the agent handles the doing. That's implementation, typing code, following patterns, implementing the tests that you specify, 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 3 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 multiensory validation later. But we enable agents to observe through visual like what renders senses, auditory senses like what they can hear through logs and errors and tactile senses 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 it 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 dependencydriven 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 dependencydriven development forces you to understand how features relate and how they integrate and then in turn that he ensures that agents never implement features that depend on incomplete work. We say schedule implementation by dependencies.

So the big idea here is that dependencydriven development forces you to understand how features relate and how they integrate and then in turn that he ensures that agents never implement features that depend on incomplete work. We say schedule implementation by dependencies.

And so now on to 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 sorry we say build, learn, improve.

So there we have them. our 10 principles, the philosophy that makes the framework work. Now, let's check back in with our hung over 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 ststructured 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 highle steps for each of the 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. And 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 highle 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 refineses 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.

H 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 going to 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 going to organize these just yet. Just ensure that we have comprehensive extraction. We want to 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 001 or API 101. These categories emerge from analyzing your actual features and not from predetermined category templates.

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. 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, sorry, without iterative specification development, you're giving coding agents highle 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, 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 and refine it further to level two to logic flow. Kind of the input, logic, output. We translate the description into structured pseudo code 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 tear down.

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 focused 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 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. that 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 going to 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 graph viz 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 mark dependency and that goes something like does the row feature require the column features 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. 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 going to kind of iterate this way.

And last, we detect cycles. So we're going to 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 specification. 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 try and fe split it down again. May this feature may not be atomic. And then it's a last resort. And this is where it gets messy. The consolidation is like the last resort strategy here. But we're not going to touch too much on that today. And then we iterate after each cycle. We update the matrix. We regenerate the graph. And we 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 road map 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 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 2. 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 20% 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 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 multiensory 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 sensors. This loop continues until all acceptance criteria pass and all sensors 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 though, 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 that specification.

And what we're going to 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 depend 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 features implementation and its validation.

And then last we enable sensory capabilities. So we read the features acceptance criteria to identify which digital sensors 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 multiensory implementation loop because features are atomic. The complete imple implementation fits in one context window. The agent maintains full understanding from start to finish. There's no context loss, no reconstruction, and no 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 multiensory 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 sensors based on acceptance criteria requirements. And we've talked about the visual, auditory, and tactile senses that are 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 specification's 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 sensors and all of the test results. Multiple sensors reporting the same issue confirms a diagnosis. Conflicting signals behind sensors 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.

And 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 blogs, there are no UI rendering issues, interactions work properly. At that point, the feature is complete. Otherwise, the agent refineses 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 features changes with a structured commit message including feature ID, specification summary, validation confirmation, and implementation nodes. And at that point, the feature is fully complete and the codebase is ready for the next feature.

So the output here is we've 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 sensors and the feature is ready for integration into the broader codebase.

So, let's check back in with our Vibe coding dev and see how he's fairing 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 agents autonomous cap 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 multiensory feedback system. This is a comprehensive validation infrastructure that gives agents the ability to observe their implementations through three complimentary digital sensors. 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 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.

And lastly, tactile sensors. 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 passable 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 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 provenence 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.

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.