AI helped me ship faster. Then I forgot what my product actually does.

"Comprehension debt" is honestly the part that stuck with me.

The product is interesting, but the idea itself immediately made sense.

One thing I've been learning while building Ashive is that it's surprisingly hard to tell whether something is a real problem or just a problem you've personally experienced enough times that it feels universal.

Out of curiosity, before building Stewie Reflect, did you see any evidence that other builders were feeling this pain too, or did you build it first and then start validating afterward?

The question you ended with is the right one. The comprehension debt pain is real — but "vibe coders who shipped with AI" is too broad to convert. The $19 unlocks will come from one specific moment: a founder about to touch billing or auth who is scared of what the AI actually wrote in there. That's a very different person from someone who just thinks it sounds useful. Worth figuring out where those people are signalling that fear before optimising anything else.

This is real, and I think there are two debts that get blended together: comprehension debt after shipping and budget/context debt while shipping.

I'm working on TokenBar, so I keep seeing the second one: people only notice AI sprawl after an agent has already burned through a huge context window or made a bunch of decisions they did not really inspect.

For Stewie, the sharpest positioning might be the moment right before a risky change: "before you touch billing, auth, limits, or upgrade logic, generate the manual and find the behaviors you can actually prove." That feels more urgent than general AI-built product anxiety, because it attaches to a scary task founders already avoid.

Comprehension debt is a sharp name for something that predates AI: the day you hire your second engineer you stop being able to explain half your own product, and AI just collapsed that from years to weeks. The reconstructed manual helps, but the durable fix is writing intended behavior down as a contract before you ship, not after. I have watched this exact gap surface in M&A diligence, where a founder who can't explain why their product behaves a certain way loses leverage fast.

This resonates. The part that feels most real to me is not just forgetting the code, but forgetting the operational rule the code encoded.

Billing, limits, upgrade timing, retries, edge cases — those are product promises disguised as implementation details. AI can generate the implementation faster, but it usually does not force you to name the promise clearly.

I think a useful habit is to capture a tiny "behavior contract" before or right after shipping: input, expected behavior, exception, and why that choice was made. Even 5 lines would prevent a lot of future archaeology.

Your manual framing makes sense because it is closer to product memory than documentation.

"Comprehension debt" is a really good name for this. I think a lot of us have felt the technical-debt-vs-comprehension-debt split without having an actual phrase for it. Technical debt you can point at and say "yeah that's gross, I'll fix it later." This feels much worse because the code looks fine, passes review, works etc... you just can't reconstruct the reasoning anymore.

Comprehension debt is a pretty good name for it. What I keep noticing is that writing docs, comments, and commit messages is the first line of defense against it, but the switch from building to writing is brutal. You finish a feature, you know exactly why you made every decision, and then you've gotta type it all out before the context slips away. I built DictaFlow (dictaflow.io) partly because of that, hold a hotkey, say what you meant, release, and the explanation lands in your code or doc without breaking your flow. The typing bottleneck is real when you're trying to keep context at AI speed.

This definitely resonates — “comprehension debt” is real, especially with AI-assisted builds. You can ship fast, but your mental model lags behind what the system actually does.

The billing example is a perfect one — those edge-case decisions (upgrades, limits, timing) are exactly where things break later because they’re hard to reconstruct.

I like the framing of a “manual” vs docs. The trust layer (what behavior is actually supported vs assumed) feels like the most valuable part here.

I’d say this isn’t just founder anxiety — it shows up anytime you revisit older parts of the product and hesitate because you’re not sure what you’ll find.

For me, it’s usually auth flows or edge-case logic I avoid touching for that exact reason.

"Comprehension debt" is a great way to describe it.

AI has made building faster, but I've noticed the bottleneck shifting from implementation to understanding. A feature can work perfectly and still become expensive if nobody remembers why it behaves the way it does.

We've run into similar situations on AI-assisted projects at IT Path Solutions. The teams that scale best aren't necessarily the ones shipping the fastest, they're the ones preserving context and decisions as they build.

Also cognitive load is a new bottle-neck that hits hard. Especially founders can with AI to even more at the same time, all over the place. Keeping focus and deliver value is the skill to master.

Comprehension debt is exactly the right name for it and I haven't seen anyone describe it this clearly before. Technical debt is visible. You can see the messy code, the missing tests, the quick fix that became permanent. Comprehension debt is invisible until it bites you. You don't know you have it until you sit down to make a change and realise you can't confidently explain what the system is doing or why it was built that way. The problem with AI-assisted development is that execution velocity separates from understanding velocity permanently. The code ships faster than your mental model can absorb it. And then six features later, you have a product that works but that nobody, including the person who built it, fully owns. The only real answer is to capture intent at the point of decision, not reconstruct it from code after the fact. What was the requirement? What constraint shaped the implementation? Why was this approach chosen over the obvious alternative? That has to live somewhere outside the code itself, because the code only tells you what was built, not what was meant. The manual framing for your product is a good instinct, it's organised around behaviour, not files. What's the hardest type of product decision to represent in the format you've built?

'Comprehension debt' is exactly the right name for this. The gap between what your product does and what you can actually prove it does is a completely different problem from messy code — and it's one most tools don't address. The billing example is perfect: that's not a code question at all, it's a product contract question, and the repo quietly assumes you remember what you decided. I've hit this building in the AI app space — the more AI helps you ship, the faster the reasoning behind decisions dissolves. Curious whether the manual format helps most at the 'why did I build it this way' layer or more at the 'what does it actually do' layer — those feel like different problems to me.

What I found interesting wasn't the idea of comprehension debt itself.

It was the moment where a very personal frustration turned into a product.

Those sometimes become great companies.

Other times they stay extremely real problems that mostly matter to the person who experienced them.

Figuring out which side you're on feels like the harder question here.