DEV Community: redoCebiv

I tested every 'understand your code' tool. None of them solved the real problem.

redoCebiv — Fri, 27 Mar 2026 12:53:44 +0000

What I felt using

In my last post, I talked about the moment vibe coding stops feeling magic — when you open the project to change one thing and realize you can't find anything. (last post: https://dev.to/redo_c_ebiv/i-built-a-saas-in-a-weekend-heres-what-broke-first-1me1)

After that, I did what any reasonable person would do. I went looking for tools that could help me understand what the AI had built. I tested everything I could find. Enterprise tools. Free extensions. ChatGPT. The works.

Here's what I found — and what nobody's building yet.

Section 1: The tools that exist (and who they're actually for)

I started with the big names.

Sourcegraph Cody — indexes your entire repo and lets you ask questions about it. Genuinely impressive. Requires IDE integration and setup. Built for enterprise teams.
Greptile — raised $180M. Builds a code graph and does autonomous investigation. Requires GitHub/GitLab integration. Also enterprise-first.
Swimm — auto-generates documentation that stays in sync with your code. Has COBOL support, which tells you something about who they're building for.
CodeSee — creates visual maps of your codebase. Great for dependency visualization.

These are genuinely impressive tools. They're also built for professional developers working in teams. IDE integration required. GitHub/GitLab setup required. Enterprise pricing.

If you're a vibe coder who built something with Cursor last weekend, this is like being handed the keys to a Formula 1 car when you just learned to ride a bike.

Then there's the accessible stuff:

Denigma — paste code, get a plain English explanation. Nice, but it works snippet by snippet. You still have to find the snippet.
CodeVisualizer (VS Code extension) — generates flowcharts from functions. Requires VS Code.
ChatGPT/Claude — can explain code if you paste it in. The most accessible option.

Section 2: The hidden assumption every tool makes

Every single tool I tested — every one — assumes you know what to ask.

Cody waits for your question. ChatGPT waits for your paste. Cursor's codebase understanding kicks in when you type a query.

But here's the thing about being a vibe coder who just hit the "I can't navigate my own project" wall: you don't know what to ask. You don't even know what you don't know.

I tried asking ChatGPT: "explain this project."

It said: "This is a Next.js application with Prisma ORM and Auth.js for authentication."

Yeah. I know that. That's like asking someone to explain your house and they say "it has walls."

What I actually needed: "This app has 7 features. The login flow touches these 3 files. The task creation goes through this path. If you want to change the dashboard layout, start here."

Feature-level understanding. Not file-level. Not line-level. Feature-level.

Nobody offers this.

Section 3: The real competition — and why it's not what you think

The biggest potential competitor isn't a startup. It's Cursor and Claude Code themselves.

They already understand your project. If Cursor added a "show me all features in this project" button tomorrow, the game changes.

But right now, they don't have it. Their codebase understanding is powerful but reactive — it answers questions. It doesn't proactively map your project for you.

The second biggest competitor is just... asking the AI to explain things one file at a time. It works. It's slow. It's like exploring a city by asking for directions at every single intersection instead of looking at a map first.

Section 4: The gap — and what I'm building to fill it

After testing everything, the pattern became clear.

The entire "understand your code" space is built around one assumption: the user is a developer (or at least developer-adjacent) who can formulate technical questions.

Vibe coders can't. Not yet. They need a different entry point.

That's why I'm building redoCebiv (read it backwards — it's "vibeCoder").

You upload a ZIP of your project. The AI analyzes it and extracts a list of features — not files, not functions, but things like "user logs in," "task gets added," "notification is sent." You pick one, and it shows you which files are involved and how the flow works. In plain language.

No questions needed. The tool does the asking for you.

It supports Next.js, Vue, Flutter, Swift, Rails, and more. Currently in beta prep.

Section 5: Even if you never use redoCebiv

The pattern matters more than the tool.

Before you modify anything in a vibe-coded project, map it first. Start from features, not files.

You can do a rough version of this manually: ask your AI "list every user-facing feature in this project, and for each one, list the files involved." It won't be as clean as a dedicated tool, but it's better than opening files at random.

Karpathy himself moved on from "vibe coding" to "agentic engineering" in early 2026 — the idea that AI leverage shouldn't come at the cost of quality and understanding. The industry is heading this way. Understanding what you shipped is becoming the skill, not shipping itself.

Closing

Vibe coding gave us the ability to build. The next phase is the ability to own what we built.

The best vibe coders of 2026 won't be the fastest shippers — they'll be the ones who understand what they shipped.

If you've hit the wall I described in Part 1, and you want a tool that meets you where you are — the waitlist is open.

I'm building redoCebiv to make this easier — pick a feature like "user logs in" or "task gets added," and it shows you which files are involved and how the flow works. Waitlist open if you're curious.

Why I stopped asking AI to fix my code and started asking it to explain it

redoCebiv — Tue, 24 Mar 2026 13:45:55 +0000

I knew the tips. Inspect element, global search, pages vs. components. It all worked. But something still felt off — like I was navigating the app without ever actually understanding it.

The moment I realized what was wrong: I'd fixed the same pricing card three times in two weeks, and each time I had to start from scratch. I wasn't learning anything. I was just outsourcing to AIs.

The loop I was stuck in

Something breaks. I paste the error into Cursor. It fixes it. Two days later, something else breaks — sometimes the same thing. I paste it again. It fixes it again.

On paper, the problem gets solved every time. But I started noticing that I couldn't explain any of the fixes. Not even vaguely. I had no idea why the pricing card kept breaking, what connected it to the layout file that kept changing, or whether the "fix" was actually making the architecture worse each time.

I was getting things done without gaining any experience. The AI was learning my codebase, in a sense — responding to it, navigating it — and I was just watching. That felt wrong. Not morally wrong, just fragile. Like the whole thing depended on me always having access to this tool and never needing to think for myself.

I started wondering: is the AI helping me build, or is it replacing the part of building where I actually learn something?

The shift: ask it to explain, not fix

The turning point was small. I had a bug — the footer was overlapping the content on mobile. Normally I would have said "fix the footer overlap on mobile." This time, mostly out of frustration, I typed: "Why is the footer overlapping the content on mobile? Don't fix it. Just explain what's happening."

And the explanation was genuinely useful. It told me the footer had position: fixed but the main content didn't have enough bottom padding to account for it. It told me which file set the footer's position and which file controlled the content area's spacing. It told me these were two separate concerns that could be fixed independently.

I made the change myself. It took maybe two minutes. And for the first time, I felt like I understood a piece of my own app.

I didn't need to understand everything. I just needed enough orientation to know what I was doing and why. Not mastery — just direction. That was enough to make the whole thing feel less scary.

What I actually ask now

My prompts look completely different these days. Here are the ones I use most:

"What does this file do, and what other files depend on it?"

"If I change the padding in this component, what other pages will be affected?"

"Why is this component re-rendering every time I navigate? Walk me through the data flow."

"I want to move the testimonials section above the pricing section on the landing page. What files are involved, what's the safest way to do it, and what could go wrong?"

"Are there any other approaches? What are the tradeoffs?"

That last one is key. I ask it constantly. The AI's first answer is usually fine, but it tends to give you the most straightforward solution, not necessarily the best one. Pushing back — "is there another way?", "what are you not considering?", "did you think about edge cases?" — gets you a much more complete picture.

Whether the AI acts as a teacher or a vending machine depends entirely on how you talk to it. Same tool, completely different outcomes.

This still doesn't scale

Here's the honest part: even with better prompts, there are real limits.

Every explanation costs tokens. A detailed "walk me through" answer can eat through a meaningful chunk of your daily cap if you're on a free or mid-tier plan. I've hit that wall mid-afternoon more than once.

And the bigger issue: the AI can explain one file at a time, but it can't really show you the whole picture. When I ask about one component, I get a great answer about that component. But I can't see how it connects to the five other things that depend on it without asking five more questions. There's no bird's-eye view. No map.

That's the thing that pushed me to start building redoCebiv. I wanted to be able to pick a use case — "user logs in," "task gets added" — and immediately see which files are involved and how the flow works, without asking the AI five questions first. Not a replacement for AI tools, but the context layer they're missing.

First I built it for myself, but my friend told me she had the same issue.
So I started to think there are more around us having the same desire to understand the process, and at the same time, I wanted to share my app to them.

If that sounds like a problem you have, the waitlist is open.

Wrapping up the series

Three posts. The fear of touching your own app. The tricks that help you navigate it. The shift from asking the AI to fix things to asking it to teach you.

None of this requires you to become a developer. You don't need to understand every line. You just need a map — something that gives you enough orientation to move with confidence instead of fear.

I'm curious what your experience has been. If you're working inside an AI-generated codebase, what's your process? What do you do when you're stuck? Drop a comment — I'd genuinely like to know.

redoCebiv — understand your app feature by feature, not file by file. Waitlist open.

What Vibe-coded apps actually look like inside...

redoCebiv — Sat, 21 Mar 2026 14:26:23 +0000

Last time I wrote about the moment it got scary — the moment I realized I'd built something I couldn't navigate. This time, I want to talk about what actually works when you need to find and change things.
I know most of you know these, but these actions were my motivation to actually take my app back to myself.

Right-click is your best friend

Open your app in the browser. Find the thing you want to change — the button, the text, the card, whatever. Right-click it and hit "Inspect" (or "Inspect Element" depending on your browser).

A panel opens with a bunch of highlighted code. Ignore most of it. What you're looking for are recognizable words — the actual text on the button, a class name that sounds descriptive like pricing-card or hero-section, anything that connects what you see on screen to something searchable.

Copy one of those words. You just found your clue.

Now search your project

Open your project in VS Code or whatever editor you're using. Hit Cmd+Shift+F on Mac or Ctrl+Shift+F on Windows. Paste what you copied.

You'll get a short list of files that contain that word. Usually two or three. One of them is the file you're looking for.

That's genuinely the whole method. Search for what you can see. I still do this daily, and I've been doing this for a while now. It's not a beginner shortcut — it's just how people find things in codebases.

I used to feel embarrassed about this. Like a "real" developer would just know which file to open. But from what I can tell, most developers spend a decent chunk of their day searching through their own projects. Nobody memorizes the whole tree. The codebase is too large, the context switches too often. Global search is the universal coping mechanism.

The only mental model you need

Most AI-generated apps have two kinds of files that matter in your day-to-day editing. Pages and components (talking about web apps, not ios or android apps).

Pages are tied to URLs. If your app has a /pricing page, there's probably a file called pricing.tsx or a page.tsx inside a /pricing folder. Change that file, and you change that one page.

Components are reusable pieces — a navbar, a footer, a card that shows up in multiple places. They usually live in a /components folder. Change a component, and it changes everywhere that component appears. Knowing just this one distinction saves you from a lot of "wait, why did that change over there too?" moments.

You don't need to understand anything else about the architecture. Seriously. Pages and components. That's your map.

Ask your AI better questions

When you do go back to your AI tool for help, the quality of your prompt makes a massive difference. Instead of "fix the pricing page," try something like:

"Which file in my project controls the pricing section that users see at /pricing? Give me the file path and explain what each part does in simple terms."

Specificity is everything. Tell it what you see, where you see it, what you want to change. The less it has to guess, the less likely it is to edit the wrong file or create some weird duplicate.

Here are two more prompts I use constantly:

"I want to change the call-to-action button text on the landing page from 'Get Started' to 'Try Free.' Which file should I edit, and are there any other files that reference this button?"

"I changed something in components/PricingCard.tsx and now the layout looks broken on the /dashboard page. Can you explain the relationship between these two files and what might have gone wrong?"

The pattern is always the same: say exactly what you see, say exactly where you see it, ask for the connection between files. The AI becomes dramatically more useful when you stop treating it like a fix-it button and start treating it like someone who knows the codebase better than you do.

One thing worth knowing: these detailed prompts eat through tokens faster than short ones. If you're on a usage-capped plan, it adds up. I've found it's worth it — one good prompt that gets it right costs less overall than five vague ones that each make things worse.

What this still doesn't solve

These tricks work. I use them all the time. But here's the thing — every single change starts with the same detective routine. Right-click, inspect, search, cross-reference. It's not hard, but it's tedious, and it adds friction to what should be quick edits.

I started wanting something that skips the detective work entirely. Pick a feature — "user logs in," "payment goes through" — and just see which files are involved, without having to hunt for them first.

Next time, I want to talk about a shift that changed my relationship with AI tools more than any tip or trick: I stopped asking the AI to fix things and started asking it to explain things.

*Building redoCebiv to make this easier — understand your app feature by feature, not file by file. Waitlist open.

I built a SaaS in a weekend. Here's what broke first.

redoCebiv — Thu, 19 Mar 2026 15:17:08 +0000

I remember the first time I wanted to change something small in an app I'd built with AI. I think it was a button color. Maybe the font on a heading. Something that should have taken thirty seconds.

I spent two hours.

Not because the change was hard. Because I couldn't find the right file. I had a folder full of stuff with names like layout.tsx and globals.css and page.tsx nested three levels deep, and I had no idea which one controlled the thing I was looking at in my browser. It felt like trying to find a light switch in someone else's house, in the dark, while wearing oven mitts.

If you've built something with Cursor, v0, Lovable, or any AI coding tool and then hit this exact wall — yeah. I get it. That frustration is real, and it doesn't mean you're doing anything wrong.

What I expected vs. what actually happened

I built a small internal tool — a lightweight business OS for a co-founded startup. Deal tracking, task management, AI-assisted drafts. Used Cursor with Claude under the hood. The stack was Next.js, Prisma, Auth.js. I didn't pick any of that. The mighty AI did.

And honestly, watching it come together was a rush. I'd type a sentence describing what I wanted, and ten seconds later there'd be a working component on screen. A pricing table. A dashboard layout. A sign-up flow. I felt like I'd unlocked a cheat code. I texted a friend "I just built a SaaS" at 11pm on a Saturday with zero irony.

Then Sunday morning, I wanted to change the heading on the landing page. "Transform Your Workflow" — it was generic, and I had something better in mind.

I opened the project. 165 files. Folders inside folders. I clicked page.tsx. Wrong one — that was the dashboard. Tried layout.tsx. That seemed to wrap everything but didn't have the text I was looking for. Opened globals.css hoping for a clue. Nothing useful.

I found the right file eventually. It was inside app/(marketing)/page.tsx, which makes sense in hindsight but made zero sense to me at the time. By then I'd opened and closed probably fifteen files, and each one made me a little less confident that I should be touching anything at all.

The problem wasn't skill

AI tools are incredible at generating working code. They're just not great at leaving you a map of what they built. You end up with an app that runs, but the internal structure is a mystery — and the moment you want to change anything, you realize you're navigating without street signs.

This isn't a knowledge gap you need to fill by learning to code. It's more like needing to learn how to orient yourself inside a project. Think of it less like "I need to become a developer" and more like "I need to know which drawer the forks are in."

The scary part wasn't that I couldn't read code. It was that I had no visibility:

Which file controls which part of the screen?
If I change this, what else breaks?
If I break it, can I undo it?

Zero visibility. That's what made it feel risky.

When I asked the AI to fix it, something else broke

So I did what anyone would do. I went back to Cursor and told it: "Change the hero heading to 'Ship Faster, Together'."

It changed the heading. It also edited a shared component that was used in three other places. The navbar started showing the wrong title. A card on the pricing page duplicated itself somehow. I still don't fully understand how that happened.

I asked it to fix the navbar. It created a second navbar component instead of editing the existing one. Now I had two, and the app was rendering both of them on mobile.

Ended up finding the AI hardcoded that fix, which is not sustainable.

"Build" and "maintain" are different skills

I built the app in twenty minutes. Then I spent fifteen minutes on forensic work just to move one section.

That gap — between building and maintaining — is the thing that actually trips people up. The AI tools that helped you create your app weren't really designed to help you understand what they created, or to make ongoing changes feel easy.

Building is instant now (That's literally what "generative" AI means). That part is solved, or close to it. But living inside what you built — understanding the shape of it, knowing where to go when something needs to change — that hasn't caught up. The tools that create the app don't stick around to help you take care of it.

I think this is the gap that nobody's really talking about. Not "can AI write code" but "can you maintain what AI wrote." The answer, right now, is "barely."

In the next post, I'll show what's actually inside one of these AI-generated apps — and the one trick that makes finding any file take about thirty seconds.