Everyone is talking about "Vibe Coding" right now. The idea is that you can just "vibe" your way to a finished app without really knowing how to code.
The reality is, if that's all you do, you just "vibe" yourself into a corner.
To build something that actually works in production, you can't just be a prompter. You have to be an Orchestrator. The way I work now feels less like writing code and more like chairing a meeting with a high-performance team.
Here is how I use my "Plain Logic" playbook to keep that team in line.
Building the Committee
I don't just open a chat and start typing. I set up distinct personas to handle different parts of the job.
- The Architect: Designs the flow and the logic.
- The Product Designer: Focuses on the user experience and the "why."
- The Builder: Handles the grunt work of writing the syntax.
My role isn't to do their jobs for them. My role is to make them talk to each other.
The Coaching Approach
Effective leadership isn't about assuming you know everything, but it's also not about blindly delegating. It's about listening.
When I start a feature, I ask the Architect for a blueprint. Then, I don't just accept it. I paste that blueprint to the Builder and ask for a critique: "Be honest. What will this break? Is this too complex?"
I listen to them argue. The Architect wants a perfect, abstract system. The Builder complains it's too hard to implement or prone to errors. Just like in a real design meeting, I let them debate the trade-offs.
I need to hear each persona out to understand the risks. Then, as the Orchestrator, I make the final call. I determine the next step based on the information I've collected from my "team."
The "Reality Gap"
Even with a good team, you need supervision. AI suffers from "Contextual Blindness."
On a recent full-stack build, the Builder insisted the code was perfect. And logically, it was. But the live site was failing because of a configuration mismatch in the cloud environment that the AI simply couldn't see.
I had to step in. The AI writes the syntax, but I manage the reality. Things like server configurations, security permissions, and environment variables are human territory. I never assume the AI knows what is happening outside the chat window.
The "Hostile Auditor"
One of my core rules is Trust but Verify.
AI tends to be a "Yes Man." If I ask if the code is secure, it may say "Absolutely!" To get around this, I bring in another persona: the Hostile Auditor.
After the Builder finishes a task, I don't just sign off. I tell the Auditor: "Review the code. Find three ways to break it."
It usually finds holes immediately. I treat the AI like a keen junior engineer—endless energy, but it needs a steady hand on the wheel to ensure quality.
The Bottom Line on Responsibility
It is worth noting that the responsibility ultimately relies solely on me. I want to emphasise that I don't "trust" any of these personas—especially around security.
I use my own experience and expertise to verify their work. If I encounter a decision or a line of code I don't understand, I don't just ship it. I pause and up-skill until I do. I have to know that the decision is the best one, not just the fastest one.
Why It Matters
Here is the thing: Effective AI development isn't really about technical expertise. It's about human skills.
It is about coaching, leadership, and problem-solving. It's about having the "soft skills" to manage a team, spot friction, and guide a group toward a clear outcome.
Many of you already have these skills from leading people, working in the trades, or managing projects. It's just a matter of developing familiarity with a new application of those skills.
Jasper Irvine
Founder, Plain Logic