I am a non-coder. AI writes my code. For a long time I assumed the thing slowing me down to ship would be the building. It wasn't. The building got easy almost immediately. What actually held me back was quieter, and it took me a while to admit it: I didn't understand my own codebase.

I would have a working app sitting in front of me and not be able to tell you how it worked, or which parts mattered, or whether it was safe to put in front of a real person. It ran. I just couldn't see inside it. And you cannot ship with any confidence on top of something you can't read. So I would stall. I'd have the thing built and find a reason not to push it out, and the real reason was always the same. I didn't know what I was shipping.

That was the bottleneck the whole time. Not writing code, AI removed that overnight. Knowing my own code. I needed to actually get to know the thing I'd made.

The good tools answer a different question

There are real tools for this now. DeepWiki, from the team behind Devin, takes any repo and turns it into a documented wiki: architecture diagrams, module summaries, a chat about how it's built. If you're an engineer landing in an unfamiliar codebase, it's genuinely useful.

But it documents the code, and a documented codebase still means nothing to me. It tells me how the thing is built, the architecture, the modules, the structure, which is exactly the part I can't read and was never going to act on. What I needed was someone to tell me, in plain terms, what my app actually does and whether a change just broke it. Every tool that exists explains the code to people who can already read code. Nobody had explained it to someone who can't.

So I built it

I built the tool I needed. Not to document the code, but to stay safe inside something I couldn't read.

It takes a codebase and reads it back in plain English: not the file tree, what the app actually does, said the way a person would say it out loud - so for the first time I could describe my own product without bluffing. It watches every change as it lands and tells me, in a sentence, whether it's risky, before it ships - so I stopped flying blind and hoping. And it scores the things that were actually keeping me from launching - is it secure, will it hold up - so "is this ready" stopped being a gut feeling and became something I could check. No stack traces. No jargon. Language I can read.

The part I like most is that I don't have to remember to run it. It hooks into the thing that fires every time code gets saved, so it just happens. An agent changes something, and before that change settles, I get a plain read on what it was and whether to worry. I called it Glassbox, because the whole point was to make the box you can't see into see-through.

Here is what it looks like in practice. I pointed it at Tended, a product I built and then killed. Tended was a small app for staying on top of the things that quietly stack up in a life: bills, renewals, the commitments you mean to keep and then forget, with AI doing the chasing so you didn't have to. Instead of a file tree, Glassbox read the whole thing back to me in plain English: a calendar, email intake, manual capture, reminders, photo import, a dashboard, sign-in. Eleven things the app actually did. Six of them solid, five needing attention, and it told me which was which. I built that app and there were corners of it I'd half forgotten. Seeing it laid out in words instead of code is the first time I understood my own dead product better than I did while it was alive.

Glassbox reading Tended back to me: every capability in plain English down the left side, with the exact files each one touches and whether it is safe to edit on its own.

The real thing, pointed at Tended. The app described as eleven capabilities, not a file tree.

And when I click into one of those, it answers the question I could never answer for myself. If my AI goes and edits this, what is the blast radius. It tells me, in plain words, how far the change reaches and what it puts at risk, money, sign-in, anything that talks to the outside world, before the edit happens, not after I've shipped it and something breaks. That sentence, "if your AI edits this, here's what it can break," is the thing I always wanted and never had.

The Glassbox feature view for one capability: its risk surfaces in plain words, how confident the read is, why it is flagged, and the blast radius if my AI edits it.

Before an edit lands: what it touches, what it risks, and how sure the read is.

There's a third thing it does that, for me, matters as much as either. It scores the app on the questions that actually decide whether I can launch: is it secure, is it reliable, is it tested, is it going to hold together. Not a vanity grade. It refuses to put a single number on the whole thing, because one score on something it can only partly see would be false confidence, and it's honest about the dimensions it can't judge without running the app. For someone who can't read the code, that scorecard is the closest thing I have to an answer to the only question that matters before you ship: is this actually ready to put in front of a real person.

The Glassbox scorecard for Tended: each dimension, dependencies, maintainability, reliability, security, is measured or honestly marked as not yet measured, with no fake overall grade.

How ready is it, really. The scorecard answers the ship-or-don't question in terms a non-coder can act on.

What it gave me back

What it actually gave me back was the confidence to ship. Not because the code got better. Because I could finally see it. The difference between "I have an app" and "I understand the app I have" turns out to be the entire difference between sitting on something and putting it out.

The gap isn't that you can't code

Here is the thing I think most people in my position get wrong, and I got it wrong for months. We assume the gap is that we can't code, and that if we just learned to code we'd be fine. I don't think that's it. AI made building possible for people who can't code. It did not make understanding possible. That gap, between making a thing and understanding the thing you made, is exactly where non-coders stall out and quietly stop shipping. You feel like a fraud for not knowing your own app, so you don't ship it, and you assume the fix is to go learn to code.

The fix isn't to learn to code. The fix is to build yourself a way to see what you made, in a language you already speak.

It isn't finished. It doesn't yet show me how one change ripples across the rest of the app, because I haven't taught it which pieces are connected. The bigger projects are still being mapped. But the core works, it runs on every change, and for the first time I can open something I built and actually understand it, in plain English, without being able to read a line of the code underneath.

If you've made something with AI and you're scared to ship it because you don't really know what's inside it, that isn't a you problem. The tools that read a codebase back to you are getting good. What still isn't built for people like us is the part that watches every change and tells you, plainly, whether you just broke something. So I built that part. You can build yours, or wait for the version that gets built for all of us, because it's coming. But don't tell yourself the answer is to go learn to code. The answer is to be able to see.