The Cure for the Vibe Coding Hangover — Corey J. Gallon, Rexmore

Channel: aiDotEngineer

Published at: 2025-11-24

YouTube video id: JsKTQbT58BY

Source: https://www.youtube.com/watch?v=JsKTQbT58BY

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.
[music] 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,
on the other hand,
>> it's not for you, Jen.
>> It's not for you, JEN. [laughter]
>> 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 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. 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. 10
in all. So [clears throat] 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,
[clears throat]
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
[snorts]
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.
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
[clears throat] 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.
[clears throat and cough] 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 [sighs] 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 [clears throat] 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 and cough]
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
[clears throat] 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 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 [clears throat] 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 top
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 [sighs]
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.
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 warnings, that's
problems the system detects and API
responses so interystem communications
and critically stack traces like
detailed failure information. This
diagnostic information explains why
things fail, not just that they failed.
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.
>> [music]
[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.
[music]
[music]
>> [music]