Fourteen months. That's how long it's been since I first started experimenting with vibe coding. And the landscape has changed completely.
When I was last on Verbos in August, the conversation was "what even is this?" Now, in February 2026, the field has exploded. The question has shifted: "How do we do this together?"
This is the fourth time I've been on the show, and you can feel the difference. The industry has moved from skepticism to adoption—messier, more complex adoption. And that complexity is where the real work begins.
🎙️ Podcast Edition
This is a bonus post (post 10) in Chapter 9: "Build Over Buy." Four voices, one hour and eleven minutes, wrestling with where team-based vibe coding actually goes.
2026-02-06 · 1:10:59
Five Key Insights
1. Autonomous Agents Need Clear Constraints (3:00–9:30)
OpenClaw captured the internet's imagination by doing things AI assistants didn't do before—running autonomously on machines, making decisions, operating without constant supervision. The appeal is real. The problem is equally real: an agent with tokens and internet access can do damage if not properly sandboxed.
The point isn't to fear the agents. It's to understand what "safe autonomous" actually means. We're moving fast; security audits show we're moving too fast.
2. Team Vibe Coding Requires Different Workflows (40:50–50:40)
The mega pull request is the symptom. The real problem is that we're still treating code review as a post-hoc filter instead of an upfront collaboration.
Imagine this: Your team sits around a Kanban board. Agents pop up asking for help. Instead of individual contributors claiming tasks, two or three people gather, discuss requirements with the agent in real time, and align on direction before the agent produces code. Tests, quality gates, and digital twins validate the output. The PR becomes a formality, not a bottleneck.
That's the direction we're heading.
3. Pull Requests as We Know Them May Not Survive (48:00–53:20)
We don't review for code size anymore. We review for behavior. Did the button stay the same color? Did we break an API contract? Did the integration still work?
The metric isn't lines changed—it's whether the tests pass and the system behaves as expected. The PR description should be brief: what was the task, what process led to this design, what tests confirm it works.
4. Frontend Moves Faster Than Backend—And That's a Problem (42:50–47:50)
Frontend developers are closest to users. They hear feedback, validate ideas, iterate quickly. Backend developers live further down the stack and need more certainty before changes go live.
Vibe coding amplifies this asymmetry. You can generate a hundred UI variations. You can't generate stable APIs as easily. The solution isn't to slow down frontend—it's to build better interfaces (APIs, contracts, emulators) so agents can safely operate in both layers.
5. Junior Developers Aren't Replaced—They Learn Differently (58:30–1:04:50)
The conventional wisdom says juniors are doomed. The reality is different. Juniors today are more comfortable asking Claude or ChatGPT for help than senior engineers are. They're learning workflow instead of syntax.
What changed for me: I stopped asking juniors to bury themselves in technique. I started asking them to understand what customers actually need. The agent handles the code. Seniors handle validation. Juniors handle requirements translation. Everyone wins.
Where This Connects
- Build Over Buy — The inflection point where you stop negotiating with tools and start building your own.
- 10x Developers, 1000x Leverage — Why multipliers matter more than heroics when teams scale.
- Less Reading, More Building — How the learning path changes when iteration is free.
This episode feels like a milestone. Not because everything is solved. Because the conversation has matured. We're past "is this real?" Now we're asking "how do we do this responsibly, together, at scale?"
That's where the interesting problems live.
Poul