The agent did exactly what I asked. That was the first issue.
It wrote the function, wired the test, updated the README, and left a commit behind. The code ran. I was delighted for roughly twelve hours, which is the half-life of delight in this line of work. The next morning I opened the repo and could not answer a simple question: what changed yesterday, and why. The commit said “updates.” The reasoning lived in a chat window I had already closed. The context that made the change sensible was gone, and the code that remained looked confident in a way I no longer was.
This is vibe coding. It works. It works right up until you try to trust it twice.
It worked. I just could not trust it twice.
The honest version of the problem is not that the AI was wrong. Most of the time it was right. The problem was that the system around it leaned on three things that do not survive contact with a second session: my memory, my goodwill, and a suspiciously optimistic checklist that existed only in my head.
A single good output is a demo. A thing you can rely on tomorrow is different. Tomorrow you have forgotten the prompt, the agent has no memory of the decision, and the commit history is a filing cabinet where every folder is labelled “stuff.” The speed was real. The trust was not.
Speed you cannot trust is just a faster way to get somewhere you did not mean to go.
I tried to fix the wrong thing
My first instinct was the obvious one: better prompts. Longer system messages. More context pasted in. A tidier way of asking. If the output was good but unaccountable, surely a sharper instruction would fix it.
It did not. Sharper prompts produced sharper outputs and exactly the same problem the next morning. I was tuning the thing that was already working. The prompt was never the weak point.
The tell was a small, recurring, slightly humiliating moment. I would sit down, look at yesterday’s work, and have to reverse-engineer my own intent from the diff. Reading a diff to recover a decision is like reading tea leaves that you, personally, arranged the day before and then forgot the meaning of.
The validation made it worse, in the way that only useful things can. The checks passed. But they passed because they checked that the code was shaped correctly, not that it did what I meant. Structure is easy to verify. Intent is the part that goes missing, and intent was exactly what I had failed to write down.
The fix was a boundary, not a prompt
The fix was not a cleverer prompt. It was a boundary.
I stopped treating each agent run as a one-off conversation and started treating it as a step in a loop with a contract. The interesting part, it turned out, was never the prompt. It was the boundary around the prompt: what goes in, what must come out, what is written down, and what happens to the result. Once the same shape repeated a few times, I gave it a name and stopped improvising it.
The shape is deliberately unglamorous, and it is borrowed almost wholesale from DevOps, because DevOps already solved “many hands, one system, keep it auditable” a decade ago. It just had not been pointed at a laptop with several artificial interns in it.
The loop that makes it engineering
Here is the loop, applied to my own work first and then to almost everything else.
- Observe the repeated pain. The same friction shows up across sessions. Notice it instead of re-suffering it.
- Name the pattern. Give the pain a shape so you can talk about it. “I cannot reconstruct yesterday’s intent” becomes a thing, not a mood.
- Automate or template it. A script, a template, a checklist, a documented step. Something a future session inherits for free.
- Make it a gremlin. Turn the step into a bounded, named workflow with inputs, outputs, forbidden actions, and a stop condition. A role you can name is a role you can trust.
- Document it. A decision record, a session log, a walkthrough. The reasoning travels with the work, not in your head.
- Feed it back into the factory. The control becomes the default, so the next project starts further ahead than the last one did.
None of these steps is clever. That is the point. The cleverness was already in the model. What was missing was the boring machinery that turns a clever output into something a tired human can trust at nine the next morning.
This is a lab result, not a law. It is one person’s loop, run across a handful of projects over a few intense weeks. It has not been promoted from “this worked for me” to “this is a standard,” and the distance between those two is where most honest engineering actually lives.
I also want to be careful about the word “engineering.” Adding process to AI-assisted work does not automatically make it engineering, any more than a checklist makes you a pilot. The loop earns the name only because each step is inspectable: you can point at the script, the contract, the decision record, and the commit, and a stranger can follow the reasoning. The day you cannot do that, you are back to vibes with better grammar.
Vibe coding is not the enemy. It is a fast, cheap first draft of an idea. The mistake is shipping the draft and your trust in the same motion.
The move from vibe coding to agentic engineering is not a tool you install or a prompt you perfect. It is the moment you stop asking “how do I get a better answer” and start asking “what boundary makes this answer safe to rely on tomorrow.” The first question has a thousand clever solutions. The second one has a loop.
What Next
Building the Factory While Standing Inside It
Once the loop existed, I pointed it at the factory itself. Over one weekend, the scaffolding workflow built its own children.