The two unchanging principles of vibe coding
Principle 1. The author has the attitude of a PM.
Principle 2. Treat the agent like a colleague, not a tool.
Over the past two years of doing vibe coding, countless models and methodologies have appeared. From prompt engineering, for example, all the way to the recent harness engineering, the trend has shifted pretty quickly. Various skills and ways of collaborating keep emerging along with it.
But if you step back and look at all these changes, you see they’re ultimately an extension of what people have always done for projects. The harness engineering that’s been getting attention recently is, at its core, a methodology of how to communicate with the agent. The form has been changing all along, and it will keep changing.
So I tried to define ‘Principle 1’ like this. The author should have the ‘PM’s attitude.’
The PM has to understand and respect not only the existing team members but also any newly joining members and the temperaments and communication styles of the people in each part. Team members changing mid-project is common too. Sometimes more capable people come in, sometimes not.
Personally I’m using Claude Code and OpenAI Codex together, and even between the two, all kinds of features and methodologies keep getting added. It feels a lot like team members changing or being added in the middle of a project.
In real life, the important thing in such moments is the unshakable backbone. Continuously updated planning documents and a DevOps structure. Vibe coding is no different. In the end it’s just a matter of continuous management.
If you want to run things the way you do in the real world, you arrive at ‘Principle 2’: ‘treat the agent like a colleague, not a tool.’ If you don’t separate collaborating with an agent from collaborating with a person and treat them in the same register, in fact not much really changes. Or rather, “even if it does change, it’s not a big problem.”
In real life too, swapping out a team member doesn’t completely flip your project management style. Because the project has to keep going. This perspective doesn’t apply only to vibe coding.
Bonus.
I sometimes hear people say “the agent is too dumb.” But most of the time it’s closer to nonsense.
Even just a year ago, agents like Claude and Codex already, on average, possessed deeper and broader expertise than people in many cases. The problem isn’t performance, it’s communication.
This is a familiar scene in real life too. It’s not so different from the situation where an unprepared PM feels “I just can’t communicate” with a competent team member. Lately, in certain fields, team members who are more specialized than the PM are increasingly common. Because collaborators’ relearning speed can’t keep up with the speed at which new technologies and productivity tools appear. Maybe it’s a very natural flow. Of course, there are also hierarchical organizations where the PM “teaches” like a mentor passing down knowledge (run!!). But in an organization where HR works properly, you don’t make someone a PM based on tenure, age, or degree alone. (Of course such places exist too… again, run!!)
In that sense, if you’re an individual doing vibe coding, I recommend treating the agent as a colleague rather than a tool, and running that process with the attitude of a PM.
Concrete methods.
For ‘recent trends’ like tech trends or keywords, just check them lightly through YouTube or social media; for ‘learning and self-development,’ I recommend reading books on PM and PO topics, or building experience through side projects. In particular, a half-and-half mix of human collaboration and agent collaboration works well.
