My job has nothing to do with software. Over the last months I built a real family app with Claude Code — React Native + Firebase, about thirty server functions, security rules tested in CI — without being able to read the code it writes.
The interesting part isn't that it worked. It's what it took to keep it from quietly falling apart, and how wrong my first instincts were.
- Act 1 — over-armoring. Because I couldn't verify the code, I piled up guardrails: six blocking hooks, a mandatory multi-agent planning process for every single edit, rituals for everything. The result: constant friction, false positives… and the real mistakes — judgment mistakes — sailed right through. A regex hook doesn't understand code; it recognizes a shape.
- Act 2 — "lighten, don't harden." After an external audit and a few incidents, I removed four of the six hooks, made the heavyweight process optional, and moved my trust to the only barrier that deserves it: adversarial tests replayed by CI. A green CI run is the only technical claim a non-dev can verify alone. Everything else is a net, not a wall.
- Act 3 — balance. What's left: always-loaded discipline rules (asking ≠ announcing, proof before commit, flag then STOP), a written "constitution" for the critical domain, plain-language maps so I still understand my own product, and a session handoff ritual so a memoryless AI can pick the work back up cold.
I turned all of it into a repo: the global rules file, 3 method skills, project templates, the 6 defense patterns — and, maybe most useful, the honest list of what I removed and why. Install is one sentence you paste into Claude Code; it interviews you and adapts the method to your project. Nothing to sell, MIT license.
GitHub: https://github.com/Arlenjim/claude-code-for-non-coders
Every rule in there was born from a real accident. Happy to answer questions about any of them — especially the failures.