Five minutes into my vibe coding talk, I asked the room for a definition. Someone said, "a toxic manager with AI." Honestly, that was better than half the definitions on the internet.
Other answers followed. Describe the requirement in plain English. Start with a concrete plan. Use your idea and imagination even if you have never written code. All correct, but the "toxic manager" answer stayed with me because it described the real failure mode. You keep demanding changes from a system that is slowly losing context, then get angry when it forgets what you said twenty minutes ago.
The barrier to making software has collapsed, which is great. You can now begin with zero code and zero revenue. The only upgrade is that you can also be broke because the agent ate your entire token budget before the product found its first user.
That is where the talk moved away from vibe coding and into the part I actually care about: building a system around the model that can reason, act, remember, and check its own work.
the brain and body distinction
I drew a simple separation on the screen. The model is the brain. The coding agent, CLI, editor, tool layer, memory, and orchestration around it form the body. I call that body the harness.
This sounds like terminology until two products use the same model and give completely different results. The difference is usually not hidden intelligence. One harness loaded the right files, exposed the right tools, kept the context clean, and checked the output. The other one arrived carrying six old conversations, fifteen tool schemas, a novel-sized system prompt, and enough logs to recreate the Industrial Revolution.
We spend most of our time comparing brains because model benchmarks are easy to screenshot. But the body decides what the brain can see and what it can do. A smaller model inside a disciplined harness can beat a stronger model inside a cluttered one on the task that actually matters.
more context is not always more intelligence
During the talk I used a hundred-page analogy. Suppose you read a hundred pages today. Tomorrow, do you remember every sentence? Of course not. You remember the important decisions, a few examples, and the general shape of the argument.
An agent session has the same problem, except we often treat its context window like a storage cupboard. Tool outputs go in. Failed attempts go in. Entire files get loaded because one function looked suspicious. Then we add a long instruction telling the model to pay attention to the important parts, which is a little like fixing a messy desk by placing a note on it that says "be organized."
The model technically has more information, but the useful signal is now fighting everything else for attention. This is the dumb-zone feeling people notice in long sessions. The model was sharp at the beginning, then somewhere around the tenth correction it started agreeing with everything and following nothing.
I wrote about the same problem from a production angle in Everything I Got Wrong About AI Coding Agents. The short version is that context is not free intelligence. It is a budget, and every tool definition, instruction, file, and previous answer spends some of it.
compacting helps, but it is also a tiny case of alzheimer's
Someone in the room asked about /compact. The command takes a long conversation, summarizes it, and starts a smaller context from that summary. Useful, right? Yes, but the summary cannot preserve every decision and edge case. My extremely scientific description during the talk was that compacting has a small Alzheimer's problem.
The way I handle this is with a production action log. It is not a dump of the chat. It is a small persistent file that records what changed, why it changed, what was verified, what remains uncertain, and what the next phase needs to know.
The conversation can disappear after compaction. The project state cannot. This difference sounds basic, but chat history and memory get treated as the same thing in a lot of agent setups. Chat history is everything that happened. Memory is the tiny set of facts that must survive.
one phase at a time
Then I asked the room how they would prompt an agent to build a to-do app. The first answer was basically, "make a to-do app." Fair enough. The interesting part began when I added authentication, profiles, deployment, validation, and a few other things to the same requirement.
Models love taking shortcuts through big prompts. If I give one agent six features at once, it tends to produce six shallow features and call the project complete. Authentication gets a login form. Security gets a sentence in the README. Validation means the build command returned zero. Wonderful, until someone sends a request the UI was not designed to send.
So I split work into phases. Each phase has an input, one objective, and an observable outcome. The output of phase one becomes the input to phase two, then phase three, like a chain where every link has to hold before the next one is added.
phase 1 output -> phase 2 input -> phase 3 input -> validation
Authentication becomes one phase. The outcome is not "authentication code exists." The outcome is that valid users can sign in, invalid sessions are rejected, the important abuse cases have been tested, and the behaviour survives in the deployed environment.
Planning and execution also need different behaviour. During planning I tell the agent not to assume, to inspect the environment, and to ask as many questions as necessary. During execution the decisions are already made, so it should stop reopening architecture and work until the agreed validation passes. Mixing those modes is how you get an agent that starts coding too early and starts philosophizing too late.
the loop is only real when validation is real
The board eventually became a set of inner and outer loops. The inner loop plans a phase, executes it, validates the result, and repairs failures. The outer loop watches the actual goal. If the inner loop stops without meeting it, the outer loop starts another attempt with the failure state preserved.
plan -> execute -> validate -> repair -> validate again
The validation layer is the part people skip because generation is more fun to demo. For a website, I give the agent a browser so it can inspect the rendered page and click the controls. For an Android app, it needs screenshots and a way to tap through the interface. For an API, it needs real requests against the environment where the code runs. A green unit test is evidence, but it is not the same thing as seeing the user's path work.
This is how the workflow becomes autonomous without becoming reckless. I can attach a trigger to a Jira ticket, let a cheap model decide whether the task is routine or risky, and start the loop for routine work. The large model does the reasoning-heavy parts. The harness handles context, tools, retries, and state. Human review stays where the blast radius demands it.
The same restraint applies to tools. If a task can be done reliably with an existing CLI, I do not automatically load a large tool protocol into every session. A tool should earn the context it consumes. Installing everything because it might be useful later is how the agent begins every task already carrying luggage.
the strange part came at the end
Near the end of the talk, I switched from agent systems to a more basic question: what does a language model actually know?
We talk to it through sentences, so the natural mental picture is a giant hidden library. Ask a question, the model finds the correct paragraph, and then reads it back in its own voice. That picture is comforting and mostly wrong. The learned representation is closer to geometry. Words and concepts become high-dimensional vectors, and relationships appear as distance and direction inside that space.
Agent lands near ideas such as agency and intelligence. Code drifts toward debugging and backend. Nobody created those folders by hand. The neighbourhoods come from patterns learned by the embedding model.
Humans cannot look around in 3,072 dimensions, so I projected a small vocabulary into three and made it walkable.
Search for a word and teleport to it. The named points are real embedding vectors, and the neighbour score shown under each word is calculated in the original high-dimensional space. The coloured particles make the regions readable at human scale; they are visual scaffolding around the real word positions, not invented extra words. The fullscreen button is there because this thing makes much more sense when the article gets out of the way for a minute.
for the nerds who want the receipts
The map contains 199 words. Each word starts as a vector with 3,072 values:
word -> [v1, v2, v3, ... v3072]
I normalize those vectors and calculate exact cosine similarity for the nearest neighbours:
cosine(x, y) = dot(x, y) / (norm(x) * norm(y))
The three-dimensional position comes from PaCMAP, which tries to preserve local neighbourhoods without completely destroying the larger shape. That projection has a trustworthiness-at-10 score of 0.812 on this vocabulary. Good enough to explore, nowhere near good enough to pretend the 3D picture is the model's literal internal layout.
That distinction matters. Cosine neighbours come from the original 3,072-dimensional vectors. The lines, map position, and visible clusters come from the compressed projection. If the picture and the cosine score disagree, trust the cosine score. A projection is a view of the data, not the data itself.
what I actually took away from the talk
I started the session with vibe coding because that is the phrase everyone recognizes. By the end, the code generation itself felt like the least interesting piece. The useful work was choosing what enters context, deciding what must survive compaction, breaking one vague goal into phases, and building a validation layer that can observe reality instead of trusting the agent's confidence.
The vector map closed the loop for me. A prompt is not a command inserted into an empty machine. It changes a computation already shaped by learned geometry, the current context, available tools, previous outputs, and the harness wrapped around all of it. Better prompting helps, but better system design lasts longer.
The model is the brain. The harness is the body. The loop is the work. If the loop is weak, a better brain simply makes expensive mistakes faster.