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?

What's the process to secure a vibe-coded app to make sure you haven't done anything silly like left your API tokens exposed in the browser or accessible via the DevTools console? Or to prevent cross site scripting attacks, or ensure forms only accept sanitized inputs that can't be used to manipulate the database. Or that your user authentication is safe and secure and no one is going to be able to login to someone else's account.

Do you hire an actual programmer or are there tools that can do it and get you to a pretty good state?

I ve been noticing something interesting while working with AI tools.

Give two engineers the same task and the same AI, and the results can be completely different.

Not because one is better overall, but because of how they prompt.

Some are very structured and clear, others are vague, and the output reflects that.

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 spent a long time thinking at the code level.

Take an issue. Write code. Open a PR. Smoke test it. Fix CI. Debug. Review. Merge.

When I started using agents, I carried that same workflow across:

Take issue X. Refine it first. Follow the acceptance criteria. Implement it. Review the output. Smoke test it. Rebase it for human review.

I ve been testing the 'Free Tier' limits of the 2026 AI landscape. While everyone swears by Claude 3.7 or GPT-5.2, I m trying to find the 'Golden Ratio' for makers on a zero-budget.

My current findings for the Office Bee MVP:

• The Brain: Gemini 3.1 Pro (via AI Studio) seems to have the highest 'Reasoning-per-Dollar' (free) for deep R&D.

• The Frontend: v0 (Free Tier) for shadcn/ui components.

• The Glue: Bolt.new for the initial scaffold.

The Challenge: Most 'free' models hallucinate complex state management in full-stack architectures.

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 review a lot of apps built with Cursor / Lovable / v0 / Bolt, and the same

handful of security holes show up almost every time. None of it is the

builder's fault it's just what the tools leave behind. Sharing the pattern in

case it saves someone a bad week.

I'm a UX designer by trade, and as a designer I always had some fun ideas to build but never the tools to do so other then some concept design. But recently I had this Idea again from a while back and just build it.

It ook me over 2 months and had to learn a lot of code and documentation myself to tell the damn AI's what to do.

It's a weird feeling of feeling powerful and helpless at the same time haha.

I noticed a pattern with AI coding agents that bothered me more than the actual code quality.

I'd ask for a small change.