Beyond Vibe Coding — Vol. 1

AI Made Coding Cheaper. Specification Became the Moat.

I built IFRS-OneQ, a multilingual IFRS education app, on a Surface Go2

A 2020 model. 8GB RAM. An SD card for extra storage. Total AI spend to launch: $20 a month. One tool. Cursor. Everything else — Gemini, GPT, Claude — was free.

While the internet was busy debating M3 Max vs. M4, optimal VRAM, and which local LLM benchmark ran fastest — I shipped an app to the Google Play Store.

On that same machine, I also wrote a newsletter that reaches subscribers in 34 countries, and built a company from scratch.

The bottleneck was never the machine. It was never the model. It was never the budget.

AI made coding cheaper. It did not make product building cheap.

What I Actually Did

Let me be precise: I did not "vibe code."

I wrote user stories. I defined acceptance criteria. I ran product reviews. I treated my AI tools like a development team — and myself like the product owner.

But here's the part people usually skip over: I didn't use one AI. I used a team of AIs. Each with a different role, matched to what that model actually does well.

Gemini handled research. Deep knowledge retrieval, domain verification, technical context. When I needed to confirm how a standard worked or cross-check an edge case, Gemini was the right tool — broad knowledge, reliably thorough. Free tier. Sufficient.

GPT handled the surface layer. Marketing images, SEO copy, launch assets. Creative output where polish matters more than depth. Free tier. Sufficient.

Claude acted as the technical reviewer — someone who understands the code, but whose job is to evaluate, not to build. Neutral, no agenda, no cheerleading. Free tier. Sufficient.

Cursor handled implementation. $20 a month. The only tool I paid for.

The workflow was closer to a sprint cycle than a prompt session. Before Cursor wrote a single line of code, it had to explain the plan — what it was going to build, how, and why. Claude reviewed that plan. It usually caught one of three things: hidden complexity, vague acceptance criteria, or scope drift. Then I made the call: approve, revise, or reject.

I didn't design this workflow deliberately. It just felt natural — because separating builder from reviewer is Product Management. I've been doing it with humans for 20 years. When AI tools became capable enough, I applied the same discipline. The instinct to assign roles, to not let the builder also be the reviewer, to require a plan before execution — that came from two decades of product and audit work, not from reading about AI workflows.

That is not prompting.

That is product management — applied to an AI team.

But I should be honest about something: it wasn't clean. The machine crashed. A lot. And how I worked through those crashes taught me something about AI development that no amount of spec writing could have.

More on that in Vol. 2. For now — the philosophy.

The Wrong Competition

Most of the AI development conversation is still focused on the wrong layer.

Which model. Which prompt structure. Which machine. How much VRAM. Whether to run local or in the cloud.

These are real questions. They are just not the first question.

The first question is: what are you building, and do you understand the problem deeply enough to specify it well?

That is the real bottleneck. Not coding. Not prompting. Specification.

Because "what to build" is not an information problem. It is a judgment problem. And judgment only becomes useful when it can be turned into specification.

That is where most AI-first product conversations quietly break down.

AI Can Retrieve Patterns. It Cannot Retrieve Pain.

AI has access to public information. Public information is mostly success.

Launches. Feature pages. Case studies. Best practices. Product teardown threads. The polished version of what worked.

What it rarely sees is failure.

The features that benchmarked well but solved nothing. The products that looked right but felt wrong. The workflows users abandoned without ever filing a ticket. The assumptions that seemed obvious until they hit production.

That knowledge rarely gets published. It lives in operators' heads. In edge cases. In scars. In the quiet reasons experienced people don't trust certain workflows, even when the UI looks correct.

Which means AI can retrieve patterns. It cannot retrieve pain.

And product specification is mostly the work of translating pain into structure.

Building from public information alone produces a product that looks like every other successful product — because that's all the model has ever seen. Competent execution of someone else's already-validated idea.

That is not a product. That is a benchmark.

I've spent two decades in accounting, audit, and financial product management. I know exactly where IFRS practitioners lose confidence. I know which concepts the textbooks explain poorly. I know the moment a junior accountant hits a wall — because I've been that person, and I've watched hundreds of others hit the same wall.

No prompt retrieves that. No benchmark captures it.

That is the moat.

Not writing code. Not generating UI. Not prompting faster.

Knowing where reality breaks — and being able to write that down clearly enough for a machine to build against it.

Why Domain Expertise Matters More Now, Not Less

This is the shift that gets missed in the excitement around AI development tools.

AI does not eliminate expertise. It raises the market value of expertise that can be specified.

For most of software history, domain experts needed engineers to realize their ideas. That translation layer was expensive, slow, and lossy. Context leaked. Edge cases disappeared. Ambiguity got implemented as false certainty.

AI compresses that gap.

But compression only helps if the person holding the problem can specify it. The advantage doesn't go to the person with the best prompt. It goes to the person who understands the problem well enough to define what "done" actually means.

The accountant who can turn accounting judgment into acceptance criteria. The logistics manager who can turn operational edge cases into product rules.

These people don't need to win the model benchmark competition. They don't need the M4. They need to bring what AI cannot replace: years of exposure to a specific problem, and the ability to write down what they know.

The more AI handles implementation — the more valuable deep domain knowledge becomes.

Not less. More.

One More Thing Before Vol. 2

I said the bottleneck was never the machine.

That is true at the level of philosophy. At the level of practice, the machine pushed back — hard. And working through that taught me something I didn't expect: that the habits I'd built over 20 years in audit and product management weren't just useful for writing specifications. They were useful for debugging. For questioning AI outputs. For knowing when to push back and when to trust.

Vol. 2 is about the crashes. What caused them, how I worked through them, and why a weak machine might be the best teacher you can have.

The Proof

Here is what that machine built — while I was working full-time.

IFRS-OneQ — a multilingual IFRS education app, now live on Google Play and Web.

IFRS Deep Dive — a newsletter with subscribers in 30+ countries across 6 continents.

IFRS-LABO — the company behind both, built from scratch.

One Surface Go2. One SD card. $20 a month.

The bottleneck was never the machine.