I m not a coder. I build things by describing what I want to an AI and seeing what comes back. It s the most empowering thing I ve tried, but it has one problem: I can t tell if what I got is actually right.
A few weeks ago I had AI build a simple expense tracker. It looked perfect and worked on the first try. A week later I noticed the monthly total was off, because it had been counting one category twice. Nothing looked broken, so I almost never caught it.
It made me wonder if non-coders are trusting results too easily just because the screen looks right.
How do you check what AI builds when you can t read the code? Do you test with fake data, ask the AI to explain itself, or just hope for the best? And has a perfect build ever turned out to be quietly wrong for you?
Noticed lately that most of my prompts to Claude Code or Cursor aren't new instructions, they're me re-stating stuff that was true 20 messages ago and got lost: which file owns this logic, why we chose this pattern over the obvious one, what NOT to touch. Feels like half my typing is context restoration, not task description.
Curious how others handle this. Do you keep a running "state of the project" doc you paste in, rely on the agent's own memory/context features, or just accept the repeated overhead as the cost of doing business? What's actually cut it down for you, if anything has?
I've noticed this exact same drift when building apps with AI lately.
The landing page looks gorgeous because you spent time prompting it right, but by the time you're deep into page three buttons start changing shapes, fonts look slightly off, and margins get all over the place. I tried dropping a tiny style guide into the project instructions, but the AI still slips up if a prompt gets too long.
For those building fast with AI, do you use a strict component library from the start, or just keep rewriting CSS rules as you go?
Run into an issue recently where AI wrote bad logic for a discount feature, but generated passing tests for it anyway because the model made the same wrong assumption in both places.
Now I review test files first to verify the assumptions before looking at the implementation.
Saved me a ton of review time this past week.
What workflow tweaks have helped you review model generated code faster?
Code refactoring tools are amazing until they are too confident. I had an LLM clean up an unused configuration variable across a repository and it assured me every single reference was gone.
Turns out it completely ignored a dynamic string interpolation in an old logging script because it wasn't a direct match.
The app ran fine for a week until that specific error log finally triggered and crashed the background worker. Now I don't trust any automated cleanup without running a strict global search first.
What's the sneakiest bug an AI tool ever slipped past your tests?
Stack settled into this after breaking it a few times:
Cursor for IDE work. Claude Code for longer agentic runs when I trust the spec. Codex for boring tickets while I'm in meetings. v0 when a client needs a UI mock in 10 minutes.
The thing that actually changed how I use all of it: stopped treating them as interchangeable and just routing by task type. Refactors go to Cursor. Full feature from a spec goes to Claude Code. Tedious backlog stuff goes to Codex.
if i use claude or codex, i constantly am screen capping to show bad padding / alignment / whatever. is there a defacto way to let claude or codex tool call to see the browser or render a page for themselves?
On client projects I use AI for a lot of the routine work: boilerplate, error log reading, first drafts of code. I review and test everything before it goes live, but I have not settled on how much to say about it.
Some clients like hearing it because the work is faster. Others read it as less effort, even when the result is the same or better. Staying silent feels wrong to me, but a long disclosure feels like an excuse.
I ve been building more with AI lately, and I ve realised I am comfortable letting it write a lot of the code, but much less comfortable letting it decide the rules the product runs on. If I already know how something should behave, I usually define that first. What inputs are valid, what should happen, what should never happen, edge cases, fallback behaviour. AI can help me build it, but I don t want an important product rule to exist only because the model happened to infer it correctly in that conversation. The line gets blurry pretty quickly though.
I am fine giving AI much more freedom with something like UI implementation. Billing feels very different. So do permissions, data deletion, security checks, or anything where one slightly different interpretation can have an actual consequence. And once you start defining enough rules yourself, I am not even sure where vibe coding ends and AI-assisted development begins.
For people shipping real products this way, what do you still let the AI decide?
And what have you decided should always be deterministic, no matter how good the model gets?
