وایبکدر در برابر مهندس نرمافزار
خلاصهٔ کاملتر
نویسنده بیش از یه دهه پیش مقالهای نوشته بود به اسم «Java Developer در برابر Software Engineer» و حالا همون الگو رو سراغ AI میبره. به گفتهٔ اون یه الگوی قدیمی همیشه تکرار میشه: یه ابزار قدرتمند میشه، آدما هویتشون رو دورش میپیچن و بعد کل حرفه به همون ابزار تقلیل پیدا میکنه. اون تأکید میکنه AI صرفاً یه زبان یا فریمورک دیگه نیست چون اقتصاد نوشتن نرمافزار رو عوض میکنه، ولی این الگو همچنان برقراره. سؤال دیگه این نیست که AI میتونه کد بنویسه یا نه؛ میتونه و هر روزم بهتر میشه. سؤال اینه که چه کاری از این فرایند درمیاد و وقتی وارد یه کدبیس واقعی با کاربر، داده، الزامات compliance و آدمایی که باید نگهداریش کنن میشه چی پیش میاد.
معیار اشتباه. نویسنده میگه خیلیها سرعت رفتن از ایده تا اپ رو نشون میدن، که فقط برای تست یه ایده ارزش داره. ولی توی یه تیم، یکی باید ریویو کنه، یکی باید بفهمه نیت پشت کد چی بوده، یکی باید تصمیم بگیره فلان dependency جاش اونجاست یا نه، یکی باید rollback و runbook بنویسه و به page جواب بده. هیچکدوم اینا بخشی از یه پروژهٔ اسباببازی نیست. برای همین اون معیار درست رو «time to safe merge» میذاره: اگه AI تولید کد رو ارزونتر کنه ولی merge امن رو گرونتر، تیم اونقدر که فکر میکنه سود نکرده.
خروجی، پیشرفت نیست. به گفتهٔ نویسنده کد کمکگرفته از AI باید بهتر باشه، نه بزرگتر. اگه ابزار بذاره بیشتر تولید کنی، آدم باید بیشتر محدودش کنه، وگرنه کار رو فقط هل دادی پاییندست که نگهداری بشه دردسر یه نفر دیگه. کد AI باید همون سطح کد دستی رو رعایت کنه: باریک باشه، یه دلیل برای وجود داشته باشه، نصف فایل رو بیخودی reformat نکنه و بدون توضیح package اضافه نکنه. اگه نویسنده نتونه توضیح بده چرا هر فایلِ معنادار عوض شده، کد آمادهٔ ریویو نیست.
AI نمیتونه تقصیر رو گردن بگیره. نویسنده میگه ریویو کردن کد تولیدشده با کد عادی فرق داره. وقتی یه آدم کد مینویسه، یه رد تصمیم هست؛ میتونی بپرسی چرا اون abstraction، چرا اون package. ولی با کد AI بعضی از اون تصمیمها اصلاً تصمیم نیستن، completion هستن. اگه نویسنده خروجی تولیدشده رو به کار «صاحبدار» تبدیل نکرده باشه، ریویوئر داره دو تا کار میکنه: هم ریویو هم بازسازیِ نویسندگی. مالکیت تفاوت سومه: وایبکدر میگه «مدل تولیدش کرد»، مهندس میگه «من صاحبشم».
context فقط فایل نیست. مدل میتونه کلی کد بخونه، ولی این به این معنی نیست که سیستم رو میفهمه. خیلی از context مهندسی جای دیگهست: توی incidentها، migrationهای قدیمی، رفتار مشتری، قواعد تیم، الزامات امنیتی و compliance و تصمیمهای عجیب گذشته. نویسنده میگه «فقط بگو کل چیزو درست کن» یه عادت بده، چون مدل توی context window کار میکنه و هرچی تسک بزرگتر باشه راحتتر محلی بهینه میکنه و سراسری چیزی رو خراب میکنه. الگوی بهتر اینه که قبل از درخواست کد، فضای تصمیم رو کم کنی؛ یه prompt خوب معمولاً نشونهٔ اینه که خود مهندس از قبل مرز کارو فهمیده. تفاوت چهارم همینه: وایبکدر به مدل یه هدف میده، مهندس یه تسک محدودشده.
جای وایبکدینگ، نه همهجا. نویسنده به مصاحبهای از Andrew Kelley (سازندهٔ Zig) اشاره میکنه که مشارکتهای AI رو توی پروژه ممنوع کرده و آشغال خونده، چون maintainerها PRهای بزرگ AI با تغییرات نامربوط و dependencyهای عجیب میبینن که فرستندهشون نمیتونه توضیحشون بده. ولی به گفتهٔ نویسنده این یه حکم علیه AI نیست، بلکه نتیجهٔ وایبکدینگه وقتی سمت اشتباه یه خط میافته. اون اینو ممنوع نمیکنه، «جانمایی»ش میکنه: تفاوت پنجم همین خط discovery در برابر delivery هست. توی discovery میشه آشفتگی رو تحمل کرد چون هدف یادگیریه، ولی delivery که هدفش یه نتیجهٔ واقعی کسبوکاره، آشفتگیِ بیتوضیح رو تحمل نمیکنه.
نویسنده در آخر به «مسئلهٔ کارآموزی» میرسه: مهندسهای جونیور باید از AI استفاده کنن، ولی اگه ازش برای فرار از فهمیدن سیستم استفاده کنن، بیشتر تحویل میدن ولی کمتر یاد میگیرن که معاملهٔ بدیه. سالهای اول مهندسی جاییه که آدم مدل ذهنی میسازه و باید توی سر خودش بسازتش، نه اینکه از ماشین قرض بگیره. به گفتهٔ اون کار فقط کد نیست؛ کار قضاوته، و قضاوت از طریق تماس با سیستم و آدما ساخته میشه. یه آدم باید توی discovery وایبکد کنه و برای delivery سوییچ کنه به حالت مهندسی؛ مهارت اینه که بدونی توی کدوم حالتی.
نکات کلیدی:
- فرق وایبکدر و مهندس نرمافزار توی ابزار نیست، توی محدودهٔ مسئولیته
- معیار درست برای کد AI «زمان تا merge امن»ـه، نه سرعت رسیدن به دمو
- کد AI باید بهتر باشه نه بزرگتر، و نویسنده باید مالکیتش رو بپذیره و توضیحش بده
- بیشتر context مهندسی توی incident، convention و قواعد امنیتیه، نه فقط فایلها
- تسک محدودشده به مدل بهتر از آزادی کامله؛ prompt خوب نشونهٔ فهمیدن مرزه
- وایبکدینگ جای discovery خوبه، delivery به نظم مهندسی نیاز داره




