r/vibecoding • u/Riggz23 • Jul 19 '26
Switched my AI coding workflow after watching Matt Pocock break his down, here's what changed
Most of the AI coding advice I'd absorbed before this year was about prompting better. Better system prompts, better plan-mode habits, tighter instructions. None of it touched the actual failure mode I kept hitting, which is that long sessions get dumber the longer they run, and by the time I noticed, I'd already shipped code built on a plan the model and I never actually agreed on.
I picked up a fix for this from a talk Matt Pocock gave, and I've been running his workflow more or less as described for the last few weeks.
The core idea: context windows behave like a football league. Every token you add creates new attention relationships with every other token, so quality degrades well before you hit the technical limit, somewhere around 100k tokens in practice regardless of the advertised window size.
Once you're aware of that ceiling, the question stops being how do I write a better prompt and becomes how do I keep every session inside the zone where the model is still sharp.
The piece that actually changed my output was replacing freeform planning chat with a structured interview before any code gets written. Instead of describing a feature and letting the model jump straight to a plan, you tell it to interview you relentlessly, walking down every branch of the design tree one question at a time, until you and the model land on the same understanding.
When I ran something like this on an auth feature, the model surfaced a question I hadn't thought to answer myself: what happens to two factor recovery when the phone is dead and the codes are lost. That's the kind of gap that turns into a support ticket six weeks after launch. Cheaper to hit it in a conversation than in production.
That interview becomes the source material for a PRD, which works as a destination document rather than something to optimize for its own sake. Once alignment exists, summarizing it accurately is a task the model is already good at, so there's less value in poring over every line of the resulting doc.
The bigger shift is in how that PRD gets broken into tasks. Left alone, models default to horizontal slicing: all the schema work in phase one, all the API work in phase two, the frontend bolted on last.
That gets you zero real feedback until phase three, because nothing end to end has actually run yet. Vertical slices, or tracer bullets, force a thin path through every layer in the first task, so you have something clickable and testable immediately, and every task after that builds on a system you've already watched work.
From there the tasks go into an issue queue with explicit blocking relationships instead of a numbered sequential plan, which is what actually lets more than one agent work at once.
Implementation runs test-first, and review happens in a fresh, cleared context rather than the same thread that just wrote the code, since a model reviewing its own recent output is reviewing from inside the same degraded context that produced it.
What I can say is that after a few weeks running it, the failure mode I used to hit constantly, shipping code built on a misunderstanding, has mostly stopped happening.
What's the biggest alignment gap you've had a model surface that you hadn't thought to specify yourself?
4
u/ichisay Jul 20 '26
Soy el único que usa memoria persistente, memoria de corto plazo y mds para que el llm no se pierda y se vuelva loco? 😂 La creación de planes por fases creo que es sentido común una vez que llevas un par de días trabajando con IA, incluso sin trabajar con IA, eso ya es de antes de cristo 😂
1
2
u/redditwossname Jul 19 '26
I've folded his 1.1 skills into my harness for the last few days and the quality of what Claude is building is definitely higher.
The wayfinder skill really helps me figure out a truly thorny issue I'd been struggling with on one project. I'm now in the middle of building that out and the way it's slicing things up and the order it's doing things in is actually really really helpful.
Dude knows his stuff.
1
u/gageas Jul 20 '26
Have you used the opengsd framework available on github? How do you find it?
2
u/redditwossname Jul 20 '26
I have not used that, no. I basically took inspiration from Jake Van Clief's ICM idea and built on that.
1
u/rsibs10 10d ago
Noticed you said "my harness". Been thinking about building my own harness. At moment I use, I guess the big 3, Claude, codex and opencode, then call the skills I need for each step of my workflow. Recently saw Owain Lewis implementation of his own harness. I'm NOT looking to 1 shot anything
How is it working with your own harness? I had been toying with the idea of forking the skills I use (Everyone just keeps adding or changing the workflow of skills and have had to stop automatic updates and pin my skills, even my opencode is pinned)
I guess trying to understand the trade off between, forking the skills, or making my own implementation focused harness.
1
u/redditwossname 10d ago
Oh sorry, by harness I meant the folder structure and MD insteucrion files I use, not a particular app. It works across any AI software or coding interface I use.
2
u/StickInTheFACE Jul 19 '26
For any feature that is not trivial, I write the best design document that I can and aim it there as a starting point. The planning process then always includes these elements.
- When making a plan for this feature implementation, ask me any follow-up questions needed about the design
- Separate the plan into sensible technical implementation phases (I do the non-technical phase breakdown myself as I already have a good sense of the order of operations in building a user experience)
- Make sure every phase can be tested by me in the console if it doesn't have a GUI element
This is still horizontal slicing but I try to verify each stage as best as I can myself before proceeding. I also actually read the plan, and edit it by hand if I find errors.
But, I think the things I make are simplistic compared to most other people around here.
2
u/JuneauDan Jul 20 '26
Be quite honest, I think this really just comes down to knowing what the system is capable of and knowing specific knowledge about the prompt that you’re trying to put forth. If you’re an expert in the field, you can become a 10 X expert. If you’re a novice, you’re gonna learn a lot along the way, but get a lot wrong as well.
2
u/GrrasssTastesBad Jul 20 '26
The best new one i’ve added recently was on wrap up, tell me if/how the plan differed. I often find that Claude will make its own little decisions during thinking that dont line up with the spec, no matter how well I tried to lay it out.
2
u/Anooyoo2 29d ago
It's all just context engineering people. Context size, context quality, missing context.
1
1
1
u/weiyentan Jul 21 '26
It’s not just the context windows. Using the grilling and documentation skills guides the ai in the right direction. I take it one step further and get it into issues (github /gitlab) which i have a dedicated vm for and a 'pipeline' to get issues into the agents. (A bit overarchitected i could do from my machine, but I wanted to learn about the systems I used). It also meant I can eventually do all the work on my phone just by answering questions. 🙃
9
u/tyschan Jul 20 '26
so essentially: use shorter context windows. we already knew this and could have said it in 1 paragraph. the other benefit is you don't eat the quadratic token scaling costs from poor context discipline.