Vibecode It. Then Save It.

Anyone can build an app now just by describing it. Owning the code is what separates a tool you can trust from technical debt you can't see. This week: your first GitHub repo — before your next prototype ships.

Somebody at your company shipped an app this month without writing a line of code — a pricing calculator for the website, a browser extension that cleans up a report. That's vibecoding, and it's genuinely useful. Here's the part nobody mentions: the code lives wherever the tool left it. When the app breaks — or starts to matter — there's nothing to review, fix, or hand off.

I'll own this one myself. I've been coding more this year than in the past decade, and the wall I kept hitting wasn't building — it was keeping. I could make something genuinely interesting in an evening, but I had no record of the ideas or the process behind it, so improving it later was archaeology. Now every project starts with a GitHub repo before anything else. It's not hard — and when I do get stuck on a step, I have Claude or Codex walk me through it, using computer use to click through the setup with me. The payoff: I have the code I wrote, and when I want it better, I can improve it — or rather, have my agents improve it. It works.

The gap between building and keeping is the defining risk of AI-built software. Veracode tested code from more than 100 AI models and found 45 percent of samples introduced known security vulnerabilities. GitClear's analysis of 8.1 million pull requests shows technical debt rising 30 to 41 percent after teams adopt AI coding tools — the same $1.52 trillion problem last week's Deep Dive unpacked. And researchers scanning publicly available AI-built apps found thousands of security flaws and exposed secrets. None of it is fixable if you can't see the code.

One repo per app. A GitHub account is free, and every serious vibecoding tool can connect to one. In Lovable, open your project settings and connect GitHub — every change syncs automatically from then on. In Replit, link a repo from the workspace and push whenever the app works. If you're building with a coding agent on your own machine, ask it to create the repo and commit for you — it knows how. Then add a README with three sentences: what the app does, where it runs, and what accounts or data it touches. That's the whole standard. Version history is your undo button, and the README is the note your future self will thank you for.

Two honest reasons. First, the builders make shipping one click, so saving feels redundant — the platform is the backup, right up until an export limit, a pricing change, or a shutdown proves it isn't. Second, non-developers assume repos are for programmers. They're not — a repo is a filing cabinet with a memory, and the numbers say you'll need it: GitClear found code duplication running at four times historical rates in AI-assisted codebases. Quality problems in vibe-coded apps aren't rare events. They're the default trajectory — and the fix starts with being able to look at the code at all.

Block 30 minutes. Create a GitHub account, make one repo, and connect it from the tool you're already building in — Lovable and Replit both do this from a settings screen. Commit the current version of your app, working or not, and write the three-sentence README. The failure mode if you skip it: the Friday afternoon your calculator breaks — or your extension starts mishandling data — and there's no history, no copy, and no way for anyone to help you except rebuilding from memory. Thirty minutes now beats that Friday every time.