Stop building on quicksand

Hi, I'm Mike Mindel — and I first gave this talk at the AI Global Festival at the end of May 2026. Unfortunately, halfway through the recording, my phone died. So I'm re-recording it over these slides.

I've been writing software since I was eight years old. I'm fifty-two now — and the last time I wrote a line of code myself was January this year, 2026. The reason? Vibe coding.

What goes wrong with vibe coding

What is vibe coding?

So let me put a proper definition on it. Andrej Karpathy coined the term "vibe coding" back in February 2025 — "you fully give in to the vibes, and forget that the code even exists."

And here's the part people miss. The "vibe" isn't the AI. The vibe is that you stop reading what comes out. You go by feel. Does the screen look right? Does the button do the thing? If so, ship it.

That's vibe coding — building software without reading the code. It's fast. It's intoxicating — honestly, it's a bit of a drug. And here's exactly what's going wrong with it.

Building on quicksand

Vibe coding, in my humble opinion, is building on quicksand.

Day three feels like solid ground, but it isn't.

It's like breathing carbon dioxide in a sealed room — the danger is completely invisible, right up until the moment your judgement fails.

Dopamine-based engineering

I call this dopamine based engineering. And it follows the same arc no matter which tool you're using — Lovable, v0, Replit, Claude. The shape is universal.

There's the ascent. Prompt, ship, prompt, ship. Your app looks incredible — you built that in an hour? You're flying. You feel like an AI god.

Then the false summit. You're standing on top, hands on hips, mentally spending the exit. Picking out the yacht — you've probably already named it.

And then the descent. You ask it to remove a feature, and it leaves half the wiring behind. You try to close a gap between two blocks of content and it just. won't. go.

Each prompt costs more and delivers less. And that descent has a timeline.

The day-30 timeline

Watch how it unfolds.

Day one — the app runs, it feels amazing, you built that in an hour.

Day ten — something breaks. Which change caused it? No idea. Your git log just says "updates."

Day thirty — and this is the one that gets you — you're afraid to touch anything. Every fix introduces two new bugs.

Day ninety — you're rewriting from scratch, because that's genuinely faster than untangling what's there.

And that's The Scream up there — Munch, 1893 — "what is the code actually doing?!" That's not a joke. When you can't see what's being produced, it creates real, existential angst. Code you can't read. History you can't trust. An app you're scared to touch.

That feeling deserves a name.

Vibe debt compounds

Here's the name. Vibe debt.

You know technical debt — the cost of shortcuts you take now that create extra work later. Vibe debt is the same idea, but it compounds faster.

You vibe-code a feature in two hours. It works! But — the logic's duplicated in five places, there are no tests, the naming's all over the place, and nobody actually understands the flow.

Next month, a "small change" takes two days. And it breaks production.

So that's the trap, and now it's got a name. The obvious question is — what's the alternative?

What's the alternative

Agentic engineering ≠ vibe coding

The alternative is to trade instant momentum for a foundation that lasts. It's to partner with AI as an agentic engineer.

Now — I know what you're thinking. Agentic engineering sounds like vibe coding with a tie on. An orange in a necktie. Same fruit, fancier outfit.

But there's a real difference, and I'm going to earn that term over the next twelve minutes. With agentic engineering you spend a bit more time up front — structuring context, workflows, guardrails — so the agents become exponentially more useful later.

Let me make that concrete.

Three properties test

Agentic engineering is engineering done with AI agents, inside a structured workflow. And it produces software with three properties.

It's traceable — every change explains why it happened. It's reversible — any single change can be cleanly undone. And it's tied to real objectives — every change links back to the Vision.

Here's how to use this. Take any workflow and test it against the three. All three? That's agentic engineering. None of them? That's vibe coding.

And there's a bonus nobody warns you about: inside a framework, the prompts actually get simpler. The structure carries the discipline, so your prompts don't have to.

Let me show you what that trade looks like over time.

Compounding debt vs compounding returns

Same four days. Two completely different stories.

Day one — vibe coding has a running app; agentic engineering is still setting up. Vibe coding looks like it's winning — like the tortoise and the hare, the hare running off into the distance.

Day ten — vibe coding is asking "which change broke this?" Agentic engineering finds it in thirty seconds.

Day thirty — vibe coding is "I'm afraid to touch anything." Agentic engineering is confident refactoring, simple reverts.

Day ninety — vibe coding is a rewrite. Agentic engineering — the codebase is still navigable, still changeable.

And here's what you're really seeing. Vibe coding optimises for the first hour — it compounds debt. Agentic engineering optimises for the next six months — it compounds returns. You are compounding wins.

So how do we actually get there? It starts with two guardrails.

Context + intent engineering

Two guardrails. Karpathy gave us the first one — context engineering. Telling the agent what to know.

That means deciding what enters the agent's mind for the task in hand — the current task, the process, the relevant docs, the business constraints. And the key word is selective. Good context engineering does not mean "dump everything into a giant prompt."

Nate B Jones added the second one — intent engineering. Telling the agent what it wants — what good looks like. Because without intent, the agent will work perfectly... on the wrong thing.

Put them together and you get the guardrails. But the word "guardrails" matters — a lot.

Guardrails that enable flow

Guardrails, not walls.

Look at that bobsled — eighty miles an hour, an inch of ice between them and disaster. The walls of the track don't slow it down — they're the only reason it can go that fast. They keep it in flow.

That's the whole philosophy here. Discipline that enables flow, not discipline that obstructs it. Hold that thought, because it comes back to bite me later in this talk.

The walls of the track aren't slowing you down—they're the only reason you can go that fast.

So how do we add guardrails like that to an AI agent? That's where Stride comes in.

Guardrails: the Vision and planning

Stride: guardrails and flow

This is Stride.

It's Claude Code with guardrails that keep you honest. It's open source. And everything I'm about to show you — the Vision, the board, the commits — is Stride in action.

Let me walk you through it, step by step, starting with the very first thing you do.

First you create your Vision

Before you plan a single piece of work, you run /vision.

It produces a VISION.md at the root of your project — the anchor that everything else traces back to. Every issue, every commit, every PR.

And there are two ways in. There's Quick — one question, about two minutes, perfect for small projects and side-tools where a full interview would feel like overkill. And there's Deep — seven questions, about fifteen minutes, for substantial work where the act of articulating each section is itself the value.

So what does a Vision actually look like once it's written?

I have a Vision

Here it is. One file. Seven sections.

What it delivers. Who it's for. Why it exists. Why now. Success criteria. What can't change. And what it won't do.

That's it. This single file is the anchor — the thing every issue, every commit, every PR traces back to. When your agent drifts, this is what pulls it back.

Vision in place. Now let's plan some actual work.

You ask vaguely. Stride asks back.

With a Vision in place, you run /linear:plan-work for any new piece of work.

And watch what happens. You ask vaguely — "add a changelog so users see what's new." And Stride asks back. Which Vision criterion does this serve? Auto-generated or hand-written? Where does it live?

The interaction is the guardrail. That little Q&A is what turns a one-line, vague intent into a real piece of work, anchored to the Vision. Three clarifying questions cost you twenty seconds — and save you a week of building the wrong thing.

And here's what comes out the other side.

From a vague ask to real work

Same vague ask. Now a real piece of work — in under a minute.

Seven plain-English sections. And right at the top, "Why this matters" — traced to a specific line in the Vision. Just enough for someone to pick this up cold and ship it.

And notice — this issue isn't sitting in a folder somewhere. It's in flight. It's visible. It's ready for the next step. Which raises a question.

Make work visible

How can we all see what we're doing?

How can we all see what we're doing? You, your AI, your team.

The answer is: make your work visible. That issue from a moment ago doesn't live in a folder — it lives on a board.

And making work visible isn't a productivity trick — it genuinely creates better work. This mechanism is borrowed from somewhere you really wouldn't expect.

Kanban: a signboard from Toyota

Kanban. It means "signboard" in Japanese. Developed at Toyota in the 1940s by Taiichi Ohno — eighty years before we called anything "agile."

What problem did it solve? Push-based production was creating warehouses full of stock nobody needed — and bottlenecks nobody could see until the line actually stopped. Ohno realised that factories break when you push work in faster than the system can absorb it.

So he flipped it. Signal a pull, not a push. The cards told each station what to make next — and they only made that. It stops overproduction. It makes work visible. And it lets you limit how much is in flight at once.

Now watch what happens when we bring that to software.

Use Kanban for software — it works

This is the agentic-engineering win.

You can see what's planned, what's in flight, what's blocked, what's done. That's context — for you, for your AI agent, for your whole team.

And here's the bit that really matters: the board is your AI's memory across sessions. Without it, every AI session starts blind. With it, tomorrow's agent knows exactly where you left off — and the Vision every card traces back to.

And you improve flow, because you only pull work when you've got capacity. That's the most useful, most counterintuitive rule of the lot — limit work in progress, so you don't get pile-ups on the agentic highway.

Okay — you've pulled a card into Doing. You're writing code. How do we leave a trail we can actually follow?

A trail we can follow

Each footprint atomic; the trail is the history

Every change you make leaves a footprint — an atomic commit.

And the trail of those footprints is your history. You, a future developer, or the agent can walk back along it any time and tell the story of how the project got to where it is.

But that word — "atomic" — it's doing a lot of work. Let me unpack it.

átomos, the uncuttable unit

It comes to us from the Greeks, two and a half thousand years ago — átomos. Uncuttable. An indivisible unit — you can't split it any further.

Like that granite cube — every attempt to split it has failed.

Atomic commits do exactly the same thing: one purpose per commit. But — and this is the part people get wrong — being atomic isn't about being small.

Size is irrelevant. Purpose is everything.

Size is irrelevant. Purpose is everything.

A rename across thirty files? Still atomic. One file with a bug fix and an unrelated refactor jammed together? Not atomic.

Here's the test — and it comes from David Thomas, of The Pragmatic Programmer. And it's beautifully simple. Can you describe the change in one sentence, without using the word "and" to join two unrelated ideas? If yes — it's atomic. If no — split it.

And once your commits are atomic, your history starts to read very differently.

Every commit explains why, not just what

The code explains the how. The commit message explains the why.

Look at the two logs. On the left, agentic engineering — "Capture plan-work session," "Trace slides to VISION.md," "Define agentic eng." On the right, vibe coding — "updates," "fix"... and then nothing else to scroll to. Which change broke this? No idea.

Six months later, that left-hand log reads like a project narrative — a chain of decisions you can actually follow. And with Stride, those commits are written automatically, from the context of your latest change.

Now — what happens when something feels off while you're working?

Improve the system

How do we improve the system?

Here's the principle — simple, but genuinely counterintuitive. You don't have to choose between doing the work and improving how you work. You do both at once. You work on the system and in the system at the same time.

Any time something weird happens — friction — you spin up a /linear:plan-work card for it, right there and then. You carry on with what you're doing, and you pick the card up next.

The friction is the data. The fix doesn't break the flow.

And I want to tell you a story about exactly that — because I learned this one the hard way.

A confession: I built the wrong thing

This is a confession, not a triumph.

I built the Vision system into Stride. I thought it was a thing of beauty. Every project gets a full, deep Vision — gorgeous, right?

And then Andy — my brother, and a developer actually using Stride right now — pushed back. He said: "right now the system is blocking me from doing things, rather than enabling the flow." And — ouch.

I'd built the wrong thing. And I'm not going to gloss over that — the sting of it, the bruised ego of it. Because this methodology didn't come from a clean idea on a whiteboard. It came from being proven wrong by friction. Remember what I said earlier — guardrails, not walls? I'd built a wall.

So here's the move that actually matters.

The fix, captured without breaking flow

I didn't stop what I was doing.

I captured the friction as Linear cards — right there. "Right-size the Vision flow." "Let small projects skip the deep interview." Two cards. And then I kept going.

The cards live on the board. The work I was already doing carried on. That's working on the system and in the system, at the very same time. And then the next day, the agent and I picked one up together.

We updated the Vision in flight

The friction became a card. Then the agent and I updated the Vision in flight.

And this is the partnership in action. I brought the human judgement — the sense that something felt off. The agent helped refine that feeling into a checkable principle. Stride couldn't find a success criterion that matched, so I asked: can we add one?

And it suggested: "Apply guardrails, not walls. Encourage discipline but don't obstruct flow."

I said, "that's brilliant!" And Claude said, "you're right!"

The friction was the data

And the next day — the same brother who'd called it out — Andy: "Lovely — keeps the flow."

That's the whole loop, right there. The friction was the data. The fix happened while the work continued. It didn't break the flow — we just kept moving.

Friction is data. Fix without breaking flow. Keep moving.

Now — how do you know, over weeks and months, that you're still pointed the right way?

Are we still on track?

Are we still on track?

For thirty years, intelligent brains were the bottleneck — expensive, scarce, and the only thing that could hold context, reason about it, and turn it into code.

AI changes that. It's commoditised intelligence. A portable brain. And if you place that brain right at the seam where your work meets your Vision — it becomes the glue between the two. It catches the drift. It lets you sharpen the Vision, or sharpen the work, until they line up again.

The quality lives in the calibration the two of you keep finding together — turn by turn. Not set once and forgotten.

So — let's bring it home. What do you actually walk away with?

What we walk away with

Remember compounding, from the start of the talk? This is where it pays off.

Today's structure becomes tomorrow's leverage. Every Linear issue, every atomic commit, every line in your VISION.md becomes higher-leverage context over time.

That's the case for buying in now. The future pays you back. And there's a second compounding effect, one that's easy to miss.

The rising tide lifts both

Markdown improves with time. Models improve with time. The rising tide lifts both.

Structured markdown is a brilliant way for humans and agents to talk to each other. Your markdown gets sharper as you refine your Vision, your issues, your commit messages. And the models reading that markdown get sharper with every release.

They compound together. You get better at writing it; they get better at reading it. But none of this means handing the whole thing over.

The owl and the bloodhound

You leave with a partner, not a replacement.

Think of it as the owl and the bloodhound. The owl sees the whole forest from above — that's you. Judgement. Taste. Vision. Knowing what good looks like.

The bloodhound follows a scent on the ground, with precision and tireless energy — that's the AI. Speed. Stamina. Producing the artefact.

Each is useless without the other. So don't give the owl's job to the bloodhound — and don't ask the owl to track a scent. Use each for what it's brilliant at. Human beings are amazing. We're all wise. There is no need to replace yourself.

So — what should guide you, every time you sit down to build?

Tomorrow morning

Monday morning

It all comes back to one line, from The Pragmatic Programmer — David Thomas and Andrew Hunt:

"When faced with two or more alternatives that deliver roughly the same value — take the path that makes future change easier."

That's what all of this is. Structured flow. A Kanban board. Pull, not push. Limiting work in progress. A VISION.md anchoring every downstream decision. Every one of those makes the future cost of change easier — and your prompts get simpler too.

Vibe coding compounds debt — each change makes the next change harder. Agentic engineering compounds returns — each well-structured change makes the next change easier. You are compounding wins.

And the way you start is genuinely one line.

One command. Tomorrow morning.

One command. Tomorrow morning.

You see it on the screen — it's genuinely one command. There are some dependencies, and it'll talk you through them — but that's how you get going. You'll find it at getstride.dev/download-stride.

It's open source. Come and help shape it. And from the moment you install it, every next change is cheaper than the last.

Build apps that go the distance

So here's where I'll leave you. Build apps that go the distance.

If you want a hand getting started, scan that QR code, or head to getstride.dev to book a thirty-minute call with me.

My final takeaway is this. Avoid dopamine based engineering. Quit building on quicksand. Use agentic engineering to build durable products that last.

Build something that outlives the hype. Thank you — genuinely.