When Your Client Starts Vibe Coding Their Own Changes: A Freelancer's Survival Guide

TL;DR — AI coding tools like Claude Code have made it easy enough for clients to edit your codebase themselves, and a hot Hacker News thread shows this is no longer hypothetical. The fix isn't arguing about AI — it's contracts, access levels, and code ownership boundaries.

What actually happened

In early October 2026, a question on Hacker News went viral: "Ask HN: Client took over development by vibe coding. What to do?" — 63 points and dozens of comments. (news.ycombinator.com/item?id=47599303)

The poster (piscator) described this situation:

• He had spent a year building a marketplace web app for a client: shop frontend, supplier integrations, payment platforms, product management, stock syncing.
• He'd been using Claude Code himself since the start of the year, but always designed the implementation himself and corrected the bot's output.
• The client started with their own small side projects using Claude Code, then moved to the main project — and over one weekend restructured large parts of the codebase.

His words: carefully designed things were restructured, replaced, or thrown away quickly and carelessly. He wasn't alone — at least two other developers in the comments reported the same thing happened to them, and one added that a client subsequently deleted their production database.

Why this is no longer a rare event

Three years ago, "the client writes code themselves" was practically impossible. Today a non-technical shop owner can sit down, write a few prompts, and push real changes to your repo. You can't — and shouldn't — tell anyone which tools to use.

The comments made the key point clear: this is not a technical problem, it's a contractual one. A developer who worked on a project for a year has nothing in writing saying who may make direct changes to the codebase and who is responsible for bugs introduced by the client's edits.

What HN developers recommended

The five most repeated suggestions from the thread:

| Suggestion | Why it works | |---|---| | Keep push access; changes only via Pull Request | If the client can't push to main directly, every change passes through your review | | Put boundaries and obligations in writing | If the project fails due to their changes, you're not saddled with the blame | | Reprice for "guardrails and bug-fixing" work | One commenter suggested at least 2x the rate, since you'll be babysitting and fixing slop | | Walk away if values don't match | Several developers cut ties after two similar experiences — one client deleted a production database | | Mentally cede ownership of the code | One user's strategy for staying sane when a meticulously designed codebase gets remodeled over a weekend |

The sharpest warning came from commenter rwg1138: "When it fails (and it will), they will blame you for the failure, not the vibe coded slop." The risk isn't just losing the project — it's inheriting the blame for its failure.

Checklist: before your next project starts

• [ ] Contract states all codebase changes go through Pull Request, with review by you.
• [ ] Git access is limited from day one — the client gets read / PR rights, not direct push to main.
• [ ] Add an "out-of-process changes" clause: anything merged without review falls outside your warranty and bug-fix guarantee.
• [ ] Price maintenance separately from development — fixing AI-generated client code is new work with new pricing.
• [ ] Add an explicit AI clause: who may use AI coding tools, and who owns the risk of generated code.
• [ ] Keep production database access and backups exclusively on your side.

If you're in this situation right now

A suggested order, based on the thread:

1. Conversation first, git settings second. piscator himself regretted protecting branches without talking first — it felt like surveillance to the client. Be honest: review exists for project stability.
2. Make review lightweight. His fear was that reviewing slop is harder than reviewing a real developer's code. Solution: request small PRs and bill review time at your hourly rate.
3. Know your red line. If the client expects quality and stability but rejects any review process, that's a values mismatch — commenter ghm2196 framed it exactly that way: weigh the cost of staying before deciding to leave.

FAQ

Q: How do I tell a client they can't touch the code directly without sounding defensive?

Don't frame it as "you can't" — frame it as standard process: "professional teams route everything through PRs because any direct change risks an outage." It's not about personal trust; it's the industry standard. If they push back, the production-database deletion from the HN thread is a real story worth mentioning.

Q: Is charging more because of AI-generated code fair?

Economically, yes — a new kind of work has appeared: reading, understanding, and fixing code someone else (human or model) wrote. Several commenters in the thread used exactly this argument for raising rates. Just make it explicit at contract time, not after the first surprise PR.

Q: What about a non-technical client who just wants to move fast?

Give them two layers: content changes (text, colors, products) through an admin panel or CMS they own, and all code changes through you. That preserves their speed while keeping the codebase safe.

Sources

• Ask HN: Client took over development by vibe coding. What to do?
• Ask HN: Coding Agents killed my identity. How do you feel?
• Next.js Security Update October 14, 2026