Since agents will happily rebuild anything you ask in minutes, "I'm afraid to touch this" stops meaning what it used to. But I don't think the fear goes away, it just moves.
I keep a section in my CLAUDE.md that isn't architecture notes, it's just "already tried this, here's why it didn't work." Without it the agent will quietly rebuild the same mistake in 3 months, because it has no memory of the first time and the code looks perfectly reasonable on its own.
I've been talking to dozens of PMs over the last few weeks who prototype with Lovable, Bolt, Figma Make, V0, etc. Same frustrations keep surfacing.
Output looks a bit generic: looks like a demo, not your actual product
Context loss: explain your product in ChatGPT/Claude, then re-explain in Lovable, then again somewhere else
No edge case thinking: AI executes prompts literally, doesn't challenge or expand on them
The core issue I keep seeing: these tools are interface builders. They're great when you already know exactly what to build. But the hard part, thinking through the flows, the states, the edge cases, where users will actually get stuck, that's still entirely on you.
When I first started vibe coding, my instinct was to build broad all-in-one workspaces, but the AI agents kept drowning in context bloat and users got tired of prompt engineering their way through a generic interface. Once I pivoted to building hyper-specific micro-tools, such as single-purpose AI code helpers, dedicated document-parsing file tools, and simple automation utilities, the entire build process changed. The spec files stayed clean, Claude and Cursor stopped hallucinating, and the final products solved an exact problem right out of the box. Has anyone else shifted their vibe coding strategy away from big multi-feature apps toward single-workflow micro-tools?
Vibe coding is amazing for getting from idea to working demo fast.
But I think there is a tricky moment after the demo starts feeling real.
The UI works. The auth flow seems fine. Maybe payments, webhooks, user data, background jobs, or database rules start getting added. At that point, the question changes from can AI build this? to can I safely maintain and trust this?
I feel a lot of projects get stuck in the middle too useful to throw away, but not reviewed enough to feel production-ready.
I recently built a browser-based tool that extracts text from screenshots using Tesseract.js, with all processing happening 100% client-side. No files get uploaded to a server, which makes it useful for sensitive content like code snippets, error logs, or internal screenshots.
I wanted to share the technical approach and a few lessons learned, and I'd love your feedback on how you'd improve it.
Stopped writing code the old way a while back. Not because I'm lazy, the bottleneck was never the typing.
Here's how I actually work now when building something like a data pipeline:
I don't start with code. I describe the input, the expected output, the constraints. Claude lays out the file structure and flow first. That alone saves me from building the wrong thing entirely.
Then I go piece by piece. One function, read it, test it, confirm the logic, move on. Bugs surface immediately instead of stacking up into that "it all worked separately but now nothing does" moment.
Spent this week manually writing real content (facts, examples, categories) for 840+ programmatically-thin pages on a site of mine, after Google rejected AdSense twice for "low value content." Could've had an agent generate placeholder-style facts fast, but the whole point was making each page genuinely worth a visit, not just technically non-empty. Where's the line for you between "AI wrote this and it's fine" and "this needs an actual human judgment call"? Curious how others are drawing that line, especially on content-heavy or programmatic-SEO sites.
I'm asking because I honestly don't know if this is just my perspective as a software engineer.
I've tried several AI app builders, and while they've improved a lot, I still find myself hitting the same walls. They often feel rigid, expensive as projects grow, and I rarely feel confident I could build and maintain a production-grade application with them alone.