Claude کامپایلر نیست، چیز بهتریه
هوش مصنوعیخلاصهٔ کاملتر
نویسنده اوایل ۲۰۲۵ مطلبی نوشته بود با عنوان «آیا Claude یه کامپایلره؟» و اون موقع جوابش این بود که نمیدونم. حالا میگه جواب «نه» ـه، چون اصلاً خطای دستهبندیه: مدل از کامپایلر بهتره. برای باز کردن این حرف، از یه تصویر کلیشهای از ساخت نرمافزار شروع میکنه؛ لایههایی که هر کدوم مشخصات بیشتری اضافه میکنن و جزئیات «غیرلازم» رو قایم میکنن: چشمانداز به استراتژی، برنامهٔ محصول به برنامهٔ کد، و کد به باینری.
نکتهٔ کلیدی اینه که هر پله پر از تصمیمگیریه؛ دقیقتر کردن مشخصات یعنی همین. کامپایلر هم که پله آخره، کلی تصمیم میگیره: inlining، تخصیص رجیستر، اینکه هشدار بده یا برنامه رو کلاً رد کنه. کامپایلر خوب و قابلاعتماد، مهندس رو از این تصمیمها خلاص میکنه — بیشتر مهندسها اصلاً نمیدونن کامپایلر چطور کار میکنه و لازم هم ندارن بدونن.
در مدل ذهنی سال ۲۰۲۵، ایجنت کدنویسی مثل یه لایهٔ جدید بین مهندس و کامپایلر مینشست و زبان طبیعی رو به کد «کامپایل» میکرد. ولی نویسنده میگه این تصویر لایهای اصلاً درست نیست: انتزاعها نشت میکنن و لایهها به هم میسابن. کار کردن بین لایهها ارزش زیادی داره و «همدلی مکانیکی» مهمه.
مثال تاریخیاش ساخت ساختمان امپایر استیت در کمتر از یک ساله: برای تصمیم دربارهٔ پوشش فولادی نما، جلسهای گذاشتن با حضور مالک و معمار و سازنده و پیمانکارهای نورد و فلزکارهایی که قرار بود بسازن و نصب کنن و بازرسها. نویسنده میگه این حرف بدیهی به نظر میرسه، ولی در عمل مدام توش شکست میخوریم — هم از سر ندونستنِ اینکه چی رو باید پرسید، هم بیاعتنایی، هم بار ارتباطی و سازمانی. لایهها بیدلیل نیومدن؛ پنهانسازی اطلاعات همونیه که مقیاس سازمانی رو ممکن میکنه.
برتری Claude به نظر او همینه: میتونه عمودی تو کل استک حرکت کنه، از استراتژی و محصول و معماری تا کد و کد ماشین. هنوز تو هیچکدوم از این کارها بهاندازهٔ یه متخصص باتجربه نیست، ولی همهشون رو انجام میده، بدون اینکه لازم باشه جلسه بذاره یا اجازه بگیره.
مثال عملیاش سرویس DNS شرکت exe.dev ـه. VMهاشون اینقدر سریع بالا میان که حتی با ساخت زودهنگام رکورد، کاربر باید منتظر انتشار DNS میموند، پس سرور DNS خودشون رو نوشتن. بعد که برای تأخیر کمتر ریجن اضافه کردن، DNS دوباره گلوگاه شد چون همهچی از اورگان سرو میشد و هر دیپلوی هم قطعی کوچیک میساخت. راهحل: یه سرور DNS توزیعشدهٔ جغرافیایی ولی کاملاً سازگار. تصمیمهای کلان — سرور نسبتاً عمومی با تنظیمات اختصاصی، مدل hub-and-spoke، تکثیر append-only و ماندگاری در لبه — رو حضوری گرفتن.
بقیهٔ کار با ایجنتها جلو رفته: اول تحقیق دربارهٔ طراحیهای استاندارد، تاریخچهٔ ضعفهای امنیتی DNS، گزینههای متنباز و حالتهای خرابی؛ بعد چند حلقهٔ ایجنت همزمان که کل سیستم رو با تست و بازبینی خصمانه ساختن. نویسنده میگه تکاندهنده بود که ایجنتها چقدر تصمیم مهم رو بدون پرسیدن و هر کدوم جور دیگهای گرفتن — مثلاً rollback دیتابیس که قرارداد append-only رو میشکنه. راهحل نهایی یه فیلد «timeline» تصادفی برای هر ردیف بود که اگه موقع سینک نخوند، یعنی باید از نو سینک کرد.
او کل فرایند «تحلیل تفاضلی مشخصات» رو دو بار دیگه تکرار کرده تا به سندی از جنس «بافت زخم» برسه که برای هدایت ایجنت کافی باشه. کل ماجرا حدود یک هفته وقت گرفته و به گفتهٔ خودش مقدار ناچیزی از کد رو خونده — ولی جلوی تیم به همهٔ سؤالها با اطمینان جواب داد و یک ماه بعد صفر حادثهٔ DNS داشتن. نتیجهگیریاش اینه که این vibe-coding نیست؛ Claude اینجا یه منبع یکپارچهٔ عمودی بوده، یه «چند-کامپایلر» — و در آیندهٔ نزدیک، vibe-engineering فقط اسمش میشه مهندسی.
نکات کلیدی:
- مقایسهٔ مدل با کامپایلر غلطه، چون کامپایلر فقط یک لایهست و مدل تو همهٔ لایهها کار میکنه
- ارزش اصلی، شتاب دادن به تصمیمگیری آدم در سطوح مختلفه، نه واگذار کردن تصمیمها
- ایجنتهای موازی تصمیمهای مهم رو بیسروصدا و متفاوت میگیرن؛ مقایسهٔ پیادهسازیها اون اختلافها رو رو میکنه
- خروجی ماندگار پروژه، یه سند کوتاه از تصمیمهای مهم در همهٔ لایههاست که از تغییر کد جون سالم به در میبره
- ایجنت مجوز رها کردن فهم لایههای پایین نیست؛ لایههایی میمونن که فهم اضافه میکنن، نه صرفاً راحتی
