وقتی مشتری خودش با Claude Code کد میزند: راهنمای بقا برای فریلنسرها
نویسنده: آرش لطیفی — موسس The DevArt
یک ترد ۶۳ امتیازی در Hacker News: مشتری با Claude Code دست به کدبیس فریلنسر زد و پروژه یک‌ساله را گرفت. چه اتفاقی افتاد، توسعهدهندهها چه پیشنهادی دادند و از الان چطور قراردادت را ببندی.
TL;DR — ابزارهای کدنویسی AI مثل Claude Code اینقدر ساده شدهاند که مشتریها خودشان دست به کدبیس پروژه میزنند؛ یک ترد داغ Hacker News نشان میدهد این دیگر سناریوی فرضی نیست. راهحل، بحث درباره AI نیست — قرارداد، سطح دسترسی و مرزبندی مالکیت کد است.
ماجرا از زبان خود توسعهدهنده
اوایل اکتبر ۲۰۲۶ یک سوال در Hacker News مطرح شد: «Ask HN: مشتری توسعه را با vibe coding دست گرفت. چه کار کنم؟» — ۶۳ امتیاز و دهها کامنت. (news.ycombinator.com/item?id=47599303)
خلاصه ماجرا که نویسنده ترد (کاربر piscator) تعریف کرد:
- یک سال روی یک اپلیکیشن مارکتپلیس برای مشتری کار کرده بود: فرانت فروشگاه، اتصال به تامینکنندهها، درگاه پرداخت، مدیریت محصول و همگامسازی موجودی.
- از ابتدای سال خودش با Claude Code فیچر پیاده میکرد، ولی همیشه خودش طراحی میکرد و خروجی را اصلاح میکرد.
- مشتری روی پروژههای کوچک و سادهی خودش با Claude Code کار کرد، بعد آمد سراغ همان پروژه اصلی — و شروع کرد به بازنویسی بخشهای بزرگی از کدبیس در همان یک آخر هفته.
نتیجه؟ به گفته خودش، کدهای طراحی شده با دقت جایگزین یا دور ریخته شدند و او احساس کرد پروژهاش از او گرفته شده. این تنها مورد هم نبود: در کامنتها حداقل دو توسعهدهنده دیگر گفتند دقیقا همین برایشان اتفاق افتاده — یکی از مشتریهایش بعدا دیتابیس production را حذف کرد.
چرا این دیگر یک اتفاق نادر نیست
سه سال پیش «مشتری که خودش کد بنویسد» عملا ممکن نبود. الان با Claude Code یا ابزارهای مشابه، یک مدیر فروشگاه غیرفنی میتواند بنشیند، چند پرامپت بزند و تغییرات واقعی در ریپو اعمال کند. بلاک کردنش هم ممکن نیست — نمیآییم به کسی بگوییم از ابزار بهتر استفاده نکند.
نکتهای که کامنتها خوب نشان دادند: مشکل فنی نیست، قراردادی است. توسعهدهندهای که یک سال روی پروژه کار کرده، هیچ چیز مکتوبی ندارد که بگوید چه کسی حق تغییر مستقیم روی کدبیس اصلی دارد و مسئولیت باگهای ناشی از تغییرات مشتری با کیست.
توسعهدهندههای HN چه پیشنهاد دادند؟
از بین کامنتهای اصلی ترد، این پنج مورد بیشترین تکرار را داشت:
| پیشنهاد | منطق پشت آن | |---|---| | دسترسی push بده، تغییرات فقط با Pull Request | اگر مشتری دسترسی مستقیم به برنچ اصلی ندارد، هر تغییرش از فیلتر بازبینی تو میگذرد | | مرز و تعهدات را مکتوب کن | اگر پروژه به خاطر تغییرات مشتری شکست خورد، مقصر تو شناخته نمیشوی | | نرخ را برای کار «نگهبانی و رفع باگ» بازتعریف کن | یک کامنتر توصیه کرد حداقل نرخ را دو برابر کند، چون قرار است کد دیگران را اصلاح کنی | | اگر ارزشها فرق دارد، برو سراغ پروژه بعدی | چند نفر گفتند بعد از دو تجربه مشابه، همکاری با این نوع مشتری را کلا قطع کردند | | مالکیت ذهنی پروژه را رها کن | پیشنهاد یک کاربر برای حفظ سلامت روان وقتی کدبیس دستخوش میشود |
نکته مهم کامنت rwg1138: «وقتی خراب شود (و خراب میشود)، تو را مقصر میکنند، نه کد vibe coding را.» یعنی خطر فقط از دست دادن کار نیست؛ افتادن مسئولیت شکست روی دوش توست.
چکلیست: قبل از شروع پروژه بعدی
- [ ] در قرارداد بنویس تغییرات کدبیس فقط از طریق Pull Request انجام میشود و بازبینی با توسعهدهنده است.
- [ ] سطح دسترسی گیت را از همان روز اول محدود کن — مشتری دسترسی
readیا PR بدهد، نهpushمستقیم بهmain. - [ ] بندی برای «تغییرات خارج از بازبینی» بگذار: هر تغییری که از فرآیند عبور نکند، خارج از گارانتی و ضمانت رفع باگ توست.
- [ ] نرخ نگهداری را جدا از نرخ توسعه تعریف کن — اصلاح کد AI-تولید مشتری، کار جدید است و قیمت جدید دارد.
- [ ] یک بند صریح درباره استفاده از ابزارهای AI اضافه کن: چه کسی مجاز است از آنها استفاده کند و ریسک و مسئولیت کد تولیدشده با کیست.
- [ ] بکاپ و دسترسی دیتابیس production را فقط نزد خودت نگه دار — همان مورد «مشتری دیتابیس را حذف کرد» اتفاقی نبود که بخواهی تکرارش کنی.
اگر الان وسط همین وضعیتی چه کنی؟
ترتیب پیشنهادی بر اساس همان ترد:
- اول مکالمه، نه گیت. مثل
piscatorمحافظت از برنچ را بدون هماهنگی انجام نده — او خودش گفت پشیمان شد چون شبیه جاسوسی از مشتری شد. صادقانه بگو بازبینی تغییرات برای پایداری پروژه لازم است. - بازبینی را lightweight کن. نگرانی او این بود که بازبینی کد slop از بازبینی کد یک توسعهدهنده واقعی سختتر است. راهحل: PRهای کوچک بخواه و بازبینی را در همان نرخ ساعتانه لحاظ کن.
- خط قرمزت را بشناس. اگر مشتری انتظار کیفیت و پایداری دارد ولی فرآیند بازبینی را قبول ندارد، این mismatch ارزشی است — کامنتر
ghm2196دقیقا همین را توصیه اصلی کرد: قبل از تصمیم به جدایی، هزینهماندن را سنجیده در نظر بگیر.
سوالات پرتکرار
Q: چطور به مشتری بگویم حق ندارد مستقیم به کد دست بزند بدون اینکه ناراحت شود؟
به جای «نمیتوانی»، فرآیند را عادی معرفی کن: «تیمهای حرفهای هم همه کارشان از طریق PR میگذرد، چون هر تغییر مستقیم ریسک outage دارد.» اینجا بحث اعتماد شخصی نیست؛ استاندارد فرآیند توسعه است. اگر مقاومت کرد، همان مثال حذف دیتابیس production را از ترد HN تعریف کن — اتفاق واقعی است و اثر خوبی دارد.
Q: آیا عرفان نرخ بهخاطر کد AI منصفانه است؟
از دید اقتصادی بله — کار جدیدی اضافه شده: خواندن، فهمیدن و اصلاح کدی که کسی دیگر (انسان یا مدل) تولید کرده. چند کامنتر در همان ترد همین را دلیل پیشنهاد نرخ بالاتر دانستند. مهم است این را در فاز قرارداد مشخص کنی، نه بعد از مواجهه با اولین PR مشتری.
Q: با مشتری غیرفنی که فقط میخواهد سریع پیش برود چه کنم؟
برایش مسیر دو لایه بساز: تغییرات کوچک محتوایی (متن، رنگ، محصول) از طریق پنل مدیریت یا CMS که خودش بتواند انجام دهد، و هر تغییر کد از طریق تو. این هم سرعت مشتری را حفظ میکند هم کدبیس را.