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.

I do frontend for a living, and lately i can tell almost instantly when an app was vibe-coded. same component library, same gradient cards, same spacing that's slightly off everywhere.

the code works, it just all converges on one generic look.

vibe coding killed the barrier to building, which is great. but it also killed the friction that used to make products look different from each other. the models learned from the same patterns, so everyone lands in the same place.

I am building Rewire, a trading-psychology drill app, and the build is one person plus a set of AI agents with defined roles: a frontend one, a backend one, a QA one that walks the whole user journey, a perf one, and a few for marketing research and drafting.

What I spend my time on: writing the trading logic, designing the scenarios, and making the judgement calls about what a disciplined trader actually does in a given spot. The agents turn that into working code, tests, and a changelog, usually by the afternoon. I review every scenario and every deploy.

What changed for me: a build day used to end with a plan for tomorrow. Now it ends with something shipped. The tradeoff is that the agents are literal, so the specs have to be tight or you get exactly the wrong thing built well.

Two things I am still working out:

Someone on another thread described a test he uses. Revert the fix, leave the test in place, and see whether the test still passes. If it does, the test was asserting something unrelated to the bug it claimed to cover.
Good idea, so I pointed it at all eleven gates in my own pipeline. Introduce exactly the defect each one claims to catch, confirm that specific check goes red, revert.
First run: four caught, three apparently broken. Second run, after I aimed the mutations properly: all three still green. I was about a paragraph into writing up which of my own checks were dead. Then I looked at the script.
I was filtering its output with grep -iE 'FAIL' piped into grep -vE '^\s+'. Every line my gate prints starts with two spaces. So the second filter was discarding exactly the lines the first one had just found. The variable holding the failures could never be anything but empty.
I had written a detector that could not report a failure, in the middle of an exercise about finding things that cannot report failures. Third attempt, with one change at the top: before trusting any result, run the detector against a state I already know is broken, and abort if it comes back green. That step found nothing on the third run because by then the script was correct. It would have caught the second run instantly.
All eleven gates hold, for the record. The only dead check found that evening was the one I wrote to find dead checks.
The rule I'm keeping: breaking your check on purpose isn't enough. Break the thing that reads your check as well. Anything that reports on a system is part of the system.

I use AI for a lot of things now, especially when I m building something on my own.

But I noticed there are still some things I just prefer doing myself.

For me, one of them is figuring out the initial UX and structure. If I ask AI too early, I sometimes end up thinking around what it suggested instead of exploring the problem myself.

So lately I ve been trying to think through the first direction on my own, then bring AI in.

I just finished my first cloud project using Claude Code and I ran five different agents:

a PM

a QA

a Designer

It s the third week of working on my little side project, SimploMail.com, and to speed things up I ve been doing a lot of vibe coding. It s been fun, but a few things became obvious pretty quickly.
I stopped using the auto model setting in the IDE. When it silently switches models, the quality drops fast. I can feel when the agent all of a sudden looses its intelligence . So now I just pick one model I trust and stick with it.
I also try to keep each AI session focused on one small task. One feature, one change. After it writes the code, I go through everything myself. I check for hard coded config, make sure it didn't quietly delete a unit test to make something compile, and etc. Sometimes it does update unit test just to make it pass .
And I never commit without reviewing. The AI is helpful, but it can also remove something important without telling you. I've seen it happen enough times now .

One thing I underestimated with AI coding:

i just draw a box and write make app and boom agent writes perfect code

me and my team:

1. spends 4 hours debugging a webhook that randomly fails in prod

2. fights over whether a boolean flag should be is_active or active

3. merges a PR that touches 182 files because Typescript

4. writes actual logic that vibe agents refuse to touch

Setting IDEs aside for this one - Cursor, Windsurf, VS Code + Copilot live in a different conversation. I'm specifically curious about CLI-and-agent territory.

A year ago the answer for most of us was straightforward: open Claude Code or Codex, talk to it, ship code. That CLI was the entry point.