Vibe coding lets you spin up functional tools fast but tracking down sudden bugs can be a total nightmare.
When an agent updates a file and breaks a working feature finding the root cause usually wastes more time than writing the code from scratch.
I'm trying to figure out a lightweight testing workflow like basic test cases or background eval scripts that keeps things reliable without slowing down the build speed.
If you build apps using AI coding assistants how do you handle testing and error tracking when a feature stops working?
We built 111 one click apps for Arteza in about six weeks, mostly by describing each one and shipping whatever came back that ran. Felt incredible at the time. Then I pulled the usage. 9 of them cover roughly 80 percent of runs, and around 40 have never been opened by anyone outside the team.
The build time wasn't the cost. That was cheap, that's the whole point of working this way. The cost is that every one of those 111 is a surface that can break, and I now have a settings page nobody can scan and a support inbox where I often can't tell which app someone means. Cheap to write, expensive to own.
Claude Code is amazing. Agentic workflows just... work - at least better than last years options for vibe coding. Things I've learned: - .md files are a must - architecture and context - log history after every pass - Short passes with initial creation, full pass with design is fine - Fable is a hog. - use ChatGPT or Gemini for UI/UX and design prompting, but not before you get Claude to chop down your architecture first to hand off. - /clear What other things do you use to ensure Claude is productive and doesn't break with a long term project?
I've shipped work where 90%+ of the code came from prompting an agent, with me mostly reviewing, testing, and directing the architecture. Never explicitly disclosed that to the client, they just know it got done fast, works well, and stayed in budget.
Is that dishonest, or is it no different from using a framework, a library, or a junior dev and not itemizing every line's origin? Nobody used to ask what percentage of a website a developer typed themselves versus copied from Stack Overflow or scaffolded with a generator.
But this feels different somehow, maybe because the speed and volume are so much higher, or because "AI-written" still carries a stigma that "used a library" doesn't.
Where's your personal line? Do you disclose upfront, stay quiet unless asked, or does it depend entirely on who's paying and what they'd actually do with that information?
After using a lot of AI-generated code lately, I've found myself spending a lot of hours on checking and repairing a lot of easy-to-spot security flaws. That being said, AI generally sucks at actually implementing secure code (or architectures), as well as recommending what to do to make your app more secure (sometimes even decently secure).
Have you had this problem as well? If yes, how do you tackle it?
We shipped a render queue in about four hours with Claude Code. It worked fine. Three weeks later renders started failing at roughly 1 in 40, and it took three days to find, because the retry was firing against a stale job id. I had approved that diff twice without reading past the function signature.
That isn't an AI problem. It's that approving generated code feels like reading it, and it isn't. When I write something badly I remember roughly where the bad part is. When I approve something badly I remember nothing at all, so debugging starts from zero.
What I do now is type out anything touching money, queues or user data by hand, even when the agent drafted it first. Everything else gets generated and I accept I'll debug it blind. It's about 15% of the codebase and it's the only 15% I can reason about at 2am.
Where do you draw that line, or do you not draw one?
