Building Blind
What I learned when I stopped directing AI and started reading what it built.
There’s a version of working with AI that feels like leverage and is actually debt. You get the output. You ship it. You move on. The system works, until it doesn’t — and when it breaks, you have no idea where to look.
I built an entire SaaS product this way for the first two weeks. Flask backend, Tailwind frontend, Stripe billing, Supabase database, streaming AI responses, a multi-agent team working in parallel. It all worked. I had almost no idea why.
The Practice
The fix wasn’t to slow down or stop using AI. It was to add a parallel practice: a 16-week code literacy plan, 20–30 minutes a day. Not writing code — reading it. The method was deliberate: open a real file from the codebase, find patterns before looking anything up, ask for options and tradeoffs rather than answers. The AI didn’t give a course link. It built a structured plan calibrated to my actual schedule and goals.
The goal wasn’t fluency in the traditional sense. It was decision-making capacity. To understand enough of what Claude Code had built that I could evaluate it, not just ship it. Every session was 20–30 minutes, built around a specific file or concept, ending with one question answered and one new one opened.
The goal wasn’t to become a developer. It was to build enough fluency to know when to trust the output and when to push back — and to stop being the bottleneck who doesn’t know what questions to ask.
What I didn’t expect was how quickly the sessions would start finding real things — not hypothetical vulnerabilities or abstract design concerns, but actual bugs, actual security gaps, actual product decisions I’d been sleepwalking through.
What the Sessions Actually Found
Day 1. The exercise was simple: find every word that repeats three or more times in a file, without looking anything up. Pattern recognition before expertise. By the end of the session I had a vocabulary for what I was looking at — and I’d spotted a hardcoded SECRET_KEY default sitting in the config, exactly the kind of thing that ships quietly to production and becomes a real security vulnerability. Not because I’m a developer. Because I finally slowed down and looked.
Day 3. I spent the first 20 minutes trying to find the right folder — wrong drive, wrong syntax, a folder name with a space in it that broke everything. The AI corrected each mistake and explained exactly why it happened. The patience of a good tutor: not just the fix, but the reason. By the end I had a complete folder map of the codebase. I’d also discovered my Chrome browser history was sitting inside the project directory, about to be uploaded to GitHub.
Day 4 was the philosophical pivot. I found the line that runs Liz, the AI advisor built into the product: import anthropic. That’s it. One line. That’s the line that calls the AI. Liz isn’t the intelligence — she’s the persona, the logic, the prompts. The thinking comes from an API my product depends on but doesn’t control. That used to sound like a fragility. Now it sounds like every good business: build on the best available foundation and focus your energy on what only you can build. The UX. The workflow. The constraints you design into the persona. The moat isn’t the model.
Day 6. I was tracing how a nav button connects through HTML, CSS, and Python — one layer at a time, following the path. One layer led to another and I ended up in the route that handles what users see when they first land on the app. Logged-out users were hitting the dashboard — not a landing page, the dashboard, just empty. I didn’t write a single line of code to find it. I wrote up the fix for the dev agent: remove the dashboard from the public whitelist, add a landing route, hook up the onboarding check. Clean handoff, specific, no ambiguity. A week earlier I couldn’t have told you what a route was.
What Changes
The real shift isn’t technical. It’s epistemic. When you can read the code, you stop taking the AI’s word for it. You ask better questions. You catch the critical bugs before they ship. You understand that storage is a design constraint — Railway’s ephemeral filesystem means uploaded resumes get wiped on redeploy, and that’s a UX decision about what happens to a user’s data. You understand that memory is a design constraint — SSE streaming keeps connections open, and that affects load time and server costs. You understand that safety is a design constraint — a hardcoded SECRET_KEY default isn’t a dev oversight, it’s a product risk.
These aren’t engineering concerns that happen to affect design. They’re design constraints dressed in engineering vocabulary. The practice of reading code is, at its core, the practice of expanding your vocabulary for describing what a system actually does. And the more precisely you can describe what a system is doing, the better your product decisions get.
The sessions also taught me something about what a good AI advisor actually does. It doesn’t overwhelm you with what it knows. It gives you exactly the right next step. Every session ended with a specific question answered and a new one opened — which is how real learning compounds. That’s the same thing I want Liz to do for job seekers. Not more information. The right information, in the right order, for where you actually are.
Closing the Gap
AI tools have made it possible to build things above your skill level. That’s genuinely new. The question is what you do with that gap — whether you let it stay a gap, or whether you build across it.
The 16 weeks isn’t about becoming a developer. It’s about becoming the kind of designer who can tell the difference between “this works” and “this is right” — and who has enough context to know when to trust the AI and when to say: show me the code.