Beyond Vibe Coding — Vol. 2 Disciplining Vibe Coding: An Auditor's Approach
In Vol. 1, I mentioned that I built IFRS-OneQ on a Surface Go2. 8GB RAM. $20/month. One paid tool.
What I didn't mention: it crashed. A lot.
This is the part I left out of Vol. 1. But it turned out to be the most important part. If you have started building something with AI, you will likely hit the same walls. Here is what I learned from each one.
First Crash: Storage
I started the way most people do. I had a clear image of what I wanted to build, so I just started — project files, AI context, data, everything on the C drive. Pure vibe.
I had a feeling it wouldn't last. Within a few days, it froze.
After some investigation — asking both AI tools and checking the system state — the answer was straightforward: storage shortage. The Surface Go2 was not designed to carry that much locally.
The fix was obvious. Move everything to the SD card.
Simple tasks started running again. Then it froze again.
Second Crash: Memory — and a Deeper Lesson
The SD card solved the storage problem. It did not solve the processing load.
Even with more space, the AI kept stalling on certain tasks. So I started tracking what the AI was reading, and why it was freezing.
The problem was not the code.
The problem was what I was handing the AI.
I was feeding the AI hundreds of IFRS practice questions — large, dense, highly structured exam content. But the AI did not need to read the content of those questions to write application logic. It needed the schema, the rules, the behavior. Not the dataset itself.
When you hand an AI a full dataset, it tries to understand and optimize for the content. Processing load spikes. And then something worse happens.
The AI starts making judgment calls that should be yours.
When I handed over everything — including decisions about what mattered, what to emphasize, how to structure the content — the AI began researching complex patterns, weighing priorities, and sometimes making the wrong call. Then it would try to fix its own mistakes, consuming even more processing.
The results were telling. Sometimes the AI would quietly "summarize" carefully constructed question data. A dataset of 100 questions would silently become 95. Features I had built would be mysteriously disabled. Multilingual support — which was non-negotiable for IFRS-OneQ — kept getting broken every time I added something new.
This was the deeper lesson.
The moment you hand the AI not just a task, but the responsibility to decide what matters — it conflates structural understanding with domain judgment. And it either freezes, or produces something that ignores your intent entirely.
A higher-spec machine might have powered through the freeze. But the result would have been a product built on someone else's priorities — or no one's.
The constraint forced me to be precise about what the AI actually needed.
It is not about what you feed the AI. It is about what you don't.
Not just data. Judgment. Responsibility. Authority over what the product becomes.
I removed the question content entirely from the AI's context. The freezing largely stopped.
Third Crash: Old Memory
One more problem emerged as development progressed.
Performance started degrading again — not because the AI was reading too much new information, but because it was carrying too much old information.
Old outputs. Old logic. Old relationships between parts of the codebase that no longer reflected where the code actually stood.
The tool was not overloaded with new input. It was overloaded with stale context.
Think of it like a phone that slows down when the cache fills up. An AI carrying old relationships starts taking longer to make new decisions.
The fix was to reset Cursor's Codebase Index — deleting it and resyncing from scratch. The Index is how Cursor embeds and understands your codebase. Over time, as code changes accumulate, those embeddings carry stale relationships: associations from earlier logic that no longer reflects reality.
After the reset, performance noticeably improved.
To be clear: I don't know if this applies to other AI tools — the tools keep evolving and I can't guarantee it reproduces today. But the principle felt clear:
Don't let the AI remember too much. Old context is noise. Reset the Index.
Debugging Like an Auditor
There is one more habit worth naming, because it shaped how I worked through every one of these crashes.
When something broke, I did not paste the error into the AI and do what it said.
I asked why.
If the explanation didn't make sense — if I couldn't follow the reasoning, or something felt off — I pushed back. Why is that the cause? Why does that fix it? What assumptions are you making?
This instinct came from my time at an audit firm. I had a manager with a particular habit. I would give an explanation. He would say: "I see. And why?" I would answer again. He would say: "Okay. And why?"
It never stopped at the first answer. The point was not to find the answer. The point was to reach the truth beneath the answer. In audit, surface-level understanding is not enough. You are accountable for the reasoning, not just the conclusion.
I applied the same discipline to AI.
For error diagnosis, logs went in as raw text — lightweight, unambiguous, precise. For visual errors, Gemini handled image input well and was more generous with volume at the time, though that may have changed.
But the core habit was consistent: receive the answer, then ask why.
Most AI responses are correct at the surface. The ones that aren't tend to sound just as confident as the ones that are. The only way to tell the difference is to keep asking until you hit something you can verify — or until the reasoning breaks down.
That is not skepticism for its own sake.
It is audit thinking applied to a development workflow. Don't accept the answer. Understand it.
What the Crashes Actually Taught Me
All three crashes pointed to the same discipline:
Be deliberate about what information the AI holds at any given moment — and equally deliberate about what authority you do not hand over.
A high-spec machine might have let me be lazy. I could have fed the AI everything and let processing power compensate for poor information design. It probably would have produced something functional.
But functional is not the same as intentional. The product that comes out of undisciplined AI input reflects no one's priorities clearly — not yours, not your users'. It becomes something that roughly resembles what you wanted, built on a foundation no one thought carefully about.
The Surface Go2 did not allow that.
What That Machine Built
Here is what that Surface Go2 produced — while I was working full-time.
IFRS-OneQ — 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.
Vol. 3 moves from design discipline to economic discipline. Building got cheaper. Maintaining did not. The question nobody asks before they build — and why it has shaped every major shift in enterprise software history.