I hired a real engineer to review my vibecoded app, and watched her face while she read it
Paid someone to do a code review last week, first actual engineer to ever see what I'd built. Watched her scroll for a solid two minutes without saying anything. Then: "okay, so, this works, but why does this file talk to three different places to do one thing?"
I didn't have an answer. I'd asked the AI for a feature, it worked, I moved on, asked for the next feature, it worked, moved on again. Never once looked at whether feature three quietly duplicated logic from feature one. The app functioned perfectly the whole time. It just also had, apparently, three slightly different versions of the same idea living in different corners of the codebase.
What got me wasn't that it was bad, she was actually kind about it, said this is completely normal for anything built fast. What got me was realizing I'd been measuring progress purely by "does it work when I click it," and that measurement had been quietly lying to me the entire time.
I don't think the answer is doing it slower from scratch. I think it's that at some point, someone who actually reads code needs to look at the whole thing, not feature by feature.
For the non-engineers building here: have you had someone technical actually review your app yet? What did they catch that you never would have?
Replies
The cheap version of what she did is a dependency graph. Run madge over the repo, look for files pulling from three unrelated places, and that duplication shows up in about ten minutes without paying anyone. What it won't tell you is which of the three copies should survive, and that judgement is the expensive part you actually bought. The thing I'd worry about next is the bug shape: three versions of one idea means three places a bug can live, and you'll only ever fix the one you found.
@asadmalik901 madge finding the duplication is the easy 10 minutes, yeah. what actually surprised me was that it wasn't three separate bugs, it was one bug wearing three outfits, so fixing the one i found gave me false confidence the other two were fine too. that's the part i'd warn someone about before they run the tool.
@terranicgerald False confidence is the real cost there. The cheap defence is to grep the distinctive string literals out of the copy you found rather than the function name, because the AI renames functions and keeps the strings. Then delete two of the three and let it break loudly. If nothing breaks you never had three copies of one thing, you had three features that only look alike, which is a different problem.
This tracks with something I've seen a lot from the security side too: "it works when I click it" and "it's secure" are completely different axes, and AI-generated code passes the first one regardless of the second. A hardcoded API key, an unvalidated input, three different auth checks that don't actually agree with each other, all of that functions perfectly fine in the demo.
The architecture review your engineer did catches structural smells. It won't necessarily catch security ones unless she was specifically looking for that, it's a different lens, same blind spot. Vibe-coded apps that skip both are probably the riskiest of all, since nobody who built it was looking for either kind of problem. curious if anyone's had a security-specific review done, separate from the architecture one
@ayanm Two different lenses, one blind spot, that's exactly it, and probably why 'have it reviewed' feels like one checkbox when it's actually two people looking for two completely different kinds of wrong.
the two minute silent scroll is basically what "does it work" never tests for. structure only shows up when someone reads across files instead of through one feature at a time. the harder part is that fixing it after the fact means someone has to hold the whole codebase in their head, which is exactly what nobody vibe coding one feature at a time was doing along the way. what would actually change the loop is catching the duplicate at write time, before feature three ships, not after three features exist to compare against each other. most setups like this only have "did it run," nothing watching for structural drift in the moment.
@galdayan yeah, that's the actual trap. a dependency graph tells you where the copies live, not whether they've already drifted apart. the scariest version of this isn't three identical bugs, it's three copies that started identical and one got silently patched last month while you were looking at file two.
@galdayan That’s a nice distinction: “did it run” is an execution check; structural drift is a change in the shape of the product, a departure from stated client intent. Once feature B duplicates feature A, a green test can still hide a decision problem because nobody can tell which copy carries the intended user experience.
The review unit I’d want to preserve is the source/decision, the user intent, the intended behavior, and what actually shipped (not just the latest diff). It’s why we think in a loop from evidence to delivery and back to learning.
Have you found a lightweight invariant that can travel with each feature "entity" as the agent works on them, before a full-codebase review is needed?
@galdayan @jalcantara Not a clean invariant yet, closest I've got is a one-line 'intended behavior' note per feature that the agent has to restate before touching it again, cheap enough to survive, and it at least surfaces drift the moment the restated version stops matching the original.