Vibe Coding: When the Machine Writes Back: Part V — No Instructions Included
What happens when you don’t wait to be ready
Before We Continue
Everything so far might sound more intentional than it actually was. It wasn’t. This wasn’t a system, a workflow, or something refined through best practices. It was a first impression—raw, unoptimized, and deliberately unprepared. That turns out to matter more than anything else.
Flying Blind (On Purpose)
There’s a temptation to rewrite this as something more structured than it was—to imply a method. There wasn’t one. No YouTube deep dives, no prep phase, no “best way” to do any of it. That wasn’t an oversight—it was intentional. If this only works when you prepare perfectly, then it doesn’t really change anything. What matters is that it worked anyway.
Not the Optimal Path (And That’s the Point)
There are already people building with AI in far more structured ways—multi-agent systems, coordinated “teams,” emerging frameworks. I didn’t do any of that. I used my own baseline knowledge, Claude as a thinking partner, and Claude Code as an execution layer. That’s it. No orchestration, no optimization—and it still worked. Which raises the real question: if this is what happens at the low end of the curve, what happens when people get good at it?
The Parts AI Didn’t Fix
For all the focus on AI writing code, the friction that remained was revealing. The App Store is still a maze—privacy policies, terms of service, content declarations, age ratings, screenshots, compliance layers. I had been through it before, which helped, but it’s still a trudge. AI made it easier to fill in the blanks and translate intent into the required language, but it didn’t remove the process.
Where the Real World Pushed Back
There were also edges where the abstraction gave way to reality. Shakebugs needed a backend fix before the “contact developer” feature would work. iPad screenshots exposed a layout issue I hadn’t considered. For privacy, I used BlurData (to anonymize App Store screenshots), which had its own issues that required back-and-forth with the developer. This wasn’t a closed system—it was a chain of systems, each with its own constraints. AI didn’t eliminate that. It just helped me move through it faster.
The One Time It Slipped
There was one moment where Claude Code stalled—looping on a problem, trying variations, not quite landing the fix. For the only time in the entire process, I stepped in. Not to write code, but to notice. A lowercase “l” where an uppercase “L” belonged. I asked: shouldn’t this be LogLevelDebug instead of logLevelDebug? That was it. I didn’t change a line myself. I just pointed at the mismatch. It corrected, and everything moved again.
The Crash That Made It Better
There was one real crash—the multithreaded issue inside the Swift package. That wasn’t a failure of the app so much as a limitation of the underlying library. Fixing it required changes to the package itself, adding proper thread handling. That moment didn’t break the system—it strengthened it. The result was a more robust package than what I started with, not just a working workaround.
The Part That’s Easy to Miss
What stands out most isn’t what broke—it’s what didn’t. No hangs, no cascading failures, no instability inside the app itself. For something involving networking, cryptography, UI, and external integrations, that’s unusual. There were bugs and iterations, but the system held. The process felt… smooth. Almost eerily so.
What This Actually Was
It’s easy to frame this as success. It’s more accurate to call it a first pass—unoptimized, unstructured, and done without preparation. And it still produced something real. That’s the signal. Not that everything worked perfectly—but that it worked at all under those conditions.
🌱 Seed Thought: You don’t have to take the optimal path anymore. You just have to start—and stay in it long enough to reach the other side.
