The Trap of Vibe Coding
It is tempting to treat vibe coding as the solution to everything. You just tell the AI to go. Make it faster. Make it better. Make it vibe. You don't look at the code, you don't review the PR. You just want the result.
However, if I don't understand what the agent is doing, if I lack visibility into its thinking, I am simply shooting myself in the foot. To actually ship reliable software, we have to stop looking for a tool that does the work for us, and start looking for a tool that thinks with us.
Conceptualizing Problem Solving as Decision Trees
I think of problem-solving as a decision tree:
- There is a root problem.
- There are many branches (paths) you can take.
- Only a few branches lead to the correct destination (working, scalable code).
If I start down a wrong path and the AI keeps saying, "Yes, gooood, great idea, let's do that," I am going to end up way off, far away from the solution in fact. I need friction. I need the agent to stop me at the first node and ask, "Are you sure about this abstraction? It might break X."
If the AI challenges me, I can backtrack. I can prune the bad branch early and move to a different path. We iterate until we hit the right solution. That is the only way to navigate the tree effectively.
Proposed Framework: High-Thought Planning, Low-Thought Execution
To solve this, I’ve structured my workflow into two distinct phases based on "thinking" cost. By the way, at this point in time, I'm using Opencode + Codex (GPT-5.3-Codex is amazing).
Phase 1: The Planning Mode (High Thinking) First, I turn the model’s thinking parameter to High or xHigh and set the agent to "plan" mode. I am not asking for code yet. I am asking for advice on Abstractions, System Design, Data Flow, Test specs, etc. I need to be super clear about the problem before I can even think about the solution. Sometimes I already have a design doc or spec. But this step is still useful in helping to challenge my thinking.
Everything must be exact before a single line of implementation is written. I supervise this heavily. I ask it to plan, I critique the plan, and I force it to critique me.
Phase 2: The Execution Mode (Medium/Low Thinking) Once the blueprint is solid, super clear, no ambiguity, only then do I switch to execution. At this point, the model doesn't need to be a genius. It just needs to follow instructions. I set the thinking to Medium or Low and let it execute the plan. Also, low thinking is much faster and costs less. Here, models like GPT-Codex which are finetuned for agentic tool calling and execution really shine.
Tab, Tab... Crash
In the early days of Copilot, the workflow was:
Suggestion pops up -> TAB -> Suggestion pops up -> TAB -> Suggestion pops up -> TAB.
And then you run the app, and it crashes. The code is broken and we start from scratch.
Agentic coding has the exact same risk profile. If we treat it like a "Tab" button that writes entire files instead of lines, we will end up in the same broken place, just faster. The thoughts of the agent need to be audited, and need to be visible to us. Instead of digging into the thought traces, we can crystallize the thinking through the planning mode as highlighted before.
Slowing Down. to Speed Up
I see it all the time on X (Twitter): "Ship faster. Move faster. Just build it."
I get that anxiety too. Time feels compressed right now. With AI advancing so fast, there’s this restless energy making us feel like we have to sprint constantly. But I can say from personal experience: getting stuck in the vibe trap actually slows you down. I've been there too many times to count.
I’ve found that taking a step back and moving a little slower leads to way better outcomes. It’s definitely better for the codebase. And most importantly, it’s better for my brain, too. We can outsource the typing, but we can't outsource the "understanding" part of engineering.