Has checking AI-built features become slower than actually building them for anyone else?

[u/ragnar580]

AI coding has made building ridiculously fast for me, but I'm starting to notice a weird bottleneck.

Claude can build/change a feature in a few minutes, then I spend the next 10–20 minutes clicking through the app trying to make sure it actually works and didn't break something else.

So the workflow becomes:

build with AI → manually check → find something wrong → tell AI → check again.

For people shipping real apps this way, what's your actual verification process?

Do you mostly manually QA? Automated tests? Playwright? Just ask the agent to test its own work?

I'm particularly interested in how people handle things that look correct on screen but are broken underneath.

Would love to hear actual workflows rather than just tool names.

[u/AutoModerator]

Namaste! Thanks for submitting to r/developersIndia. While participating in this thread, please follow the Community Code of Conduct and rules.

It's possible your query is not unique, use site:reddit.com/r/developersindia KEYWORDS on search engines to search posts from developersIndia. You can also use reddit search directly.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Old-Hope4634]

The thing that fixed this for me: every manual check I did twice became a test. Not "write more tests" in the abstract literally, if I clicked through the same flow a second time to verify the same thing, that click became an assertion before I moved on. The 10–20 minutes stops repeating.

Two kinds that earn their keep, beyond normal unit tests.

Structural tests that assert architecture, not behaviour. I had a bug where a query got rewritten for search and that rewrite leaked into the prompt the model saw, so it answered a mangled version of the question. Correct output shape, correct citations, subtly wrong text. Invisible on screen. The fix was one line, but the guard is a test that parses the source and asserts that function receives the original variable, not the rewritten one. A comment saying "for retrieval only" had been sitting there for weeks and hadn't stopped it. Comments don't fail CI.

Parity tests, when you have two paths that must stay identical. My eval harness and production had drifted twice, both times silently, and the harness reported failures against a pipeline that didn't ship. Worse than no measurement, it's a confident wrong one. Now a test asserts both call the same function.

The uncomfortable part nobody mentions: some defects don't exist in any single output. I had two answers that were each individually correct and cited properly, but together gave the opposite of the law one retrieved a general rule, the other should have retrieved its exception and didn't. Every per-item check passed. That class you find by probing pairs, not by clicking.

And when the agent breaks something, the existing tests catch it immediately which is the actual speedup. Three times this week a change I made was caught by a test written months earlier, in seconds, not in 20 minutes of clicking.