The Day the PMs Discovered Git: OOPPSS Part 2

If you read my last post, you know we’ve been trying to cure the engineering world of "vibe coding". That dangerous habit of blindly pasting AI-generated code and praying to the server gods that it compiles. Enter OOPPSS (Observation/Ownership, Phasing/Programming, Staging/Shipping), our methodology designed to treat AI like a hyper-efficient builder while humans act as the strict city architects.

We knew it worked for seasoned backend engineers. But then we thought: What if we push this framework to its absolute, chaotic limit?

So, last week, we hosted a workshop. We didn’t just invite the developers. We invited the project managers. The QA specialists. The customer success team. The customer support agents. People who know our product inside and out, but whose relationship with code usually stops at "Have you tried clearing your cache?"

The goal? See if a group of non-developers, armed only with the OOPPSS methodology and a couple of AI agents, could build production-ready features.

Spoiler alert: They didn't just build them. They practically ran circles around our sprint velocity.

Day 1: The "What" is Greater Than the "How"

Just like the framework dictates, we split the workshop into three distinct days, tackling four different challenges. Each challenge was a missing piece of a real feature in our software.

We dedicated the entirety of Day 1 to the OO: Observation and Ownership.

I didn’t show them a single line of code. Instead, I bored-err, enlightened-them with the absolute minutiae of the feature. We drowned in Figma mocks. We traced data pipelines via diagram charts. We walked through edge cases, user personas, and real-world examples.

In the old world of vibe coding, you give an AI a vague prompt like, "Make a checkout page," and then act surprised when it builds a portal to Narnia. In the OOPPSS world, the human must possess absolute, uncompromising ownership of the business logic.

By the end of Day 1, our customer support team didn't know what a syntax error was, but they knew exactly how data was supposed to flow from Point A to Point B. They owned the feature.

Day 2: Micro-Phasing (Or, Making AI Too Small to Fail)

On Day 2, we split into three groups and unleashed the PP: Phasing and Programming.

My main job here was mentoring the teams on how to slice their objectives into microscopic phases. I cannot emphasize this enough: The smaller the phase, the less room the AI has to hallucinate. If you give an AI agent a massive problem, it panics and starts making things up. If you give it a tiny, isolated problem, it executes with surgical precision.

What happened next genuinely blew my mind.

[Traditional Vibe Coding] -> Big Prompts -> Giant Context -> Hallucination City 

[OOPPSS Methodology]     -> Micro-Phases -> Isolated Context -> Zero Hallucinations

These were people who had literally never created a Pull Request in their lives. Git was a mystery; IDEs looked like the matrix. But they knew what they wanted to build. Because the goals were broken down into bite-sized phases, the AI builders had zero doubt about what to do. The process was a smooth, continuous conveyor belt of development.

By the end of the afternoon, all the teams had finished their assigned challenges. And because they had spare time, they started poaching the remaining challenges that weren't even assigned to them. They were coding. Happily. Without hallucinations.

Day 3: The City Metaphor and the 8-Day Dev

Day 3 was all about the SS: Staging and Shipping.

We gathered to review the code using our City Metaphor. We didn’t care if the AI’s internal logic looked like a bizarre futuristic skyscraper, as long as its plumbing connected perfectly to our city's main grid without leaking sewage onto the streets.

Our automated Code Reviewer AI enforced the rigid zoning laws (API boundaries and interfaces), the tests passed, and the PRs were officially merged.

When the dust settled, we decided to do some math. We calculated the velocity of what these non-developers built on Day 2.

The Verdict: The output of our non-technical workshop teams on Day 2 was equivalent to a Senior Developer working for 8 days straight.

Let that sink in.

And just to flex a little, the teams used their remaining time on Day 3 to log into Jira, hunt down a couple of actual bugs, and fix them. Customer success agents fixing production bugs. What a time to be alive.

Being Flexible (And Heading to the Beach)

Obviously, practice makes perfect. Our brilliant non-technical folks would need weeks of continuous training to independently ship features and fixes to production without a safety net. But seeing what is possible with OOPPSS is incredibly satisfying.

If engineering teams have learned anything over the last year, it's that flexibility is our greatest asset. We’ve tested the waters with so many different AI approaches over the past few months, but this hybrid model, rigid architectural boundaries paired with hyper-isolated AI execution feels like the sweet spot. We’re going to keep iterating, keeping our minds open, and seeing how far we can push this.

I am incredibly excited to write more about this. I want to dive into the exact mechanics of how we managed the sessions, the specific prompting principles we used to kill hallucinations, and the underlying architecture.

...But summer is officially here.

And if you have ever visited Sweden in the summer, you know that the entire country collectively agrees to stop working, find a lake, and soak up the three days of sunshine we get per year. The laptop is closing.

Have a great summer, everyone! I’ll see you in the autumn to break down the deep technical side of the OOPPSS methodology. 🕶️☀️