The Product Owner Who Never Opens an IDE

What happens when we structure personal projects like a company and let AI be the entire engineering team?

---

It started at a barber shop.

I was waiting for my turn, phone in hand, and I realized I could SSH into my laptop and run Claude from my terminal. I fired off a prompt. Then another. I asked Claude to spin up ngrok so I could preview the webpage, there were CORS error, so asked Claude to add exception to dev server to allow ngrok domain, all this happened — right there on my phone. By the time I sat down in the chair, I had almost completed a feature I wanted to work when I got back home.

SSH isn’t new, nobody likes to run commands from tiny screen. But SSH plus an AI that can actually write code? Forget about code, it can run commands on our system using our natural language. Keep in mind, our phone has mic. That’s a whole different thing entirely. It felt less like using a tool and more like sending a message to a junior developer and checking-in async whenever I could.

Which got me thinking: what if I leaned all the way into that mental model? What if I structured my side projects like a company — where I’m the product owner, and I never touch an IDE at all?

The mental model shift

Today, most developers think: I have an idea → I build it using AI — verification is implicit in the building step.

The new model could be: I have an idea → I describe it precisely → I verify it got built correctly.

Sounds like vibe-coding, right? This is different than vibe-coding; We don’t “HOPE” that AI produces the right code. We take responsibility for the correctness of the output by engineering the specification and the verification and feedback loop.

This IS engineering, but at a different layer.

These are fundamentally different ways to operate. we stop asking “how do we implement this?” and start asking “how do we describe this unambiguously?” and “how do we know if this is good?”

When AI gets output wrong, we don’t go “let me fix the code.” We go “let me improve the spec” or “let me improve the verification”, and learn what generated the wrong / right output in the first place.

What the “Company of One” actually looks like

In this model, we become three roles simultaneously.

1. Product owner — deciding what should exist, what’s the priority, what’s the user experience.
2. Tech lead ¹ — understanding systems well enough to make architectural decisions and evaluate tradeoffs.
3. QA — verifying correctness, checking edge cases, ensuring the output matches the intent.

What we don’t do: write code, debug syntax errors, look up API docs, setup build tools.

A typical “workday” might be:

Morning (10 min, from phone):

“Here’s the spec for the notification system. Users should be able to set quiet hours. Persist preferences to Postgres. Add tests. Update the API docs.”

Afternoon (5 min check-in):

“Show me the schema we chose. Walk me through the edge cases we handled.”

Evening (15 min review):

“This looks good, but the timezone handling is wrong. Here’s what I mean. Fix it and show me the test that covers this.”

How far can it go?

Let’s stress-test this model at different levels of complexity.

Level 1: Side projects and proofs of concept

This works today, and it works well. Low stakes, we’re the only user, iteration speed is priority than getting it perfect. We can go from idea to working prototype in the gaps between other things — waiting rooms, commutes, walking-our-dog-breaks.

Level 2: Real products with users

Possible, but need discipline. The spec-writing has to get little rigorous. “Make it look nice” won’t work. We need clear acceptance criteria, edge cases, error states enumerated. We become a technical writer as much as a product person. The quality of our output is bounded by the quality of our specs. We know this already, we need to internalize this, we need to get better at this.

Level 3: Complex systems, long-lived codebases

New questions emerge at this level: How do we maintain architectural coherence over time when we’re not in the code daily? How do we onboard ourself back into a codebase you’ve never manually touched? What’s the equivalent of “code smell” when we’re only reading specs and outputs?

My hypothesis: we need new artifacts. Not just code, but living architecture docs that get updated continuously. Decision logs that capture “why did we choose X over Y.” Invariants and constraints written in plain English that get checked against every change.

This level requires a manual, detailed review until we improve our meta specs to a point where we can trust them fully. In this level, there’s also a good chance we slip up, coe quality goes bad over time. We need systems in place to monitor them. But the key insight remains: we’re not managing code. we’re managing intent and constraints using, updating meta specs.

Level 4: Hybrid teams

What if our “company” has us as product owner, AI as the primary implementer, a human contractor who reviews the AI’s code, and another AI agent that runs security audits? We’re now orchestrating a hybrid team. The org chart has humans and AIs as peers. Management becomes workflow designers, perhaps new roles.

Where it might break / caveats

Taste is hard to spec. “Make it feel premium” or “the animation should feel snappy but not jarring” — these require tight iteration loops that are hard to do async. we might need to be hands-on for UX polish and brand consistency.

Debugging novel problems. When something breaks in a way that requires deep investigation — reading stack traces, forming hypotheses, instrumenting code — we either need to develop that skill or accept slower resolution. But there are ways to mitigate this: use AI-maintainable tech stack, better logs keeping AI context in mind.

Security and trust. If we never read the code, how do we know there isn’t a vulnerability? A subtle bug? Something that works but is a time bomb? We need either trust in the process, automated verification, or periodic deep audits. Or all three.

End of the day, these breaking points are not new. We struggle with them, we continue to struggle with them. The difference is the locus of control shifts from “can I implement this correctly” to “can I specify this correctly” and “can I verify this correctly”, reliably.

The shift is more and more towards process improvement, specification clarity, and verification rigor. Not deep implementation skill. This is the key.

The skills that become valuable

The values are shifting. What mattered before vs now:

Old world	New world
Faster key bindings	Describing intent in one paragraph
Mass memorizing APIs	Knowing when an API is the wrong choice
Reading stack traces	Writing the test that would’ve caught it
Spotting a missing semicolon	Spotting a missing edge case
git blame	Reading the decision log
”How do I implement this?"	"How do I know when it’s done?”

The person who can write a one-page spec that produces a correct, well-architected feature is more valuable than someone who can implement it manually, even if it takes same time. Because the former can scale their impact.

The abstraction layer view

There’s something here about leverage and abstraction.

We went from: machine code → assembly → C → Ruby → React → Svelte → “just say what we want.”

Each layer lets us think at a higher level. We didn’t become a worse programmer when we stopped writing assembly. We became a programmer who could think about bigger problems.

The “product owner who never touches an IDE” isn’t a lesser engineer. They’re operating at a higher abstraction layer. The skill moved from “can we implement this” to “can we imagine this clearly enough that it can be implemented.”

A vision

What if, in five years, opening an IDE to write code manually is like opening a hex editor today?

We can do it. Sometimes we need to. But it’s not where most of the work happens.

Speed of development ⍺ Speed of product clarity.

---

The barber-shop prototype is in progress, by the way. I wouldn’t be surprised if AI updates this post to plug the product and I don’t open VS Code for this. I love writing and I will continue to write blogs but everything tedious and uninteresting, like updating a blog post later — yeah, AI can do that.

AI-message:

---

Footnotes

1. We rarely need this in first iteration. ↩