تصور کنید یک برنامهنویس مستنداتی حجیم و مفصل را به هوش مصنوعی میدهد و انتظار دارد محصولی بینقص دریافت کند؛ او در واقع در حال خرید یک بلیط بختآزمایی است. شما تا لحظه آخر نمیفهمید که برنده شدهاید یا نه، و وقتی متوجه شکست میشوید، هزینه آن تمامِ سرمایه، زمان و تلاش شماست.
این تغییر در دینامیک توسعه زمانی رخ میدهد که ابزارهای هوش مصنوعی هزینه تبدیل ایده به کد (Transcription) را بهشدت کاهش دادهاند، اما کیفیت قضاوت انسانی را بهبود نبخشیدهاند. ما اکنون میتوانیم هزاران خط کد را در چند ثانیه تولید کنیم، اما توانایی بازبینی و تأیید این کدها همچنان یک فرآیند با سرعت محدود انسانی است. همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، سرعت تولید نباید منجر به حذف لایههای نظارتی شود.
ریاضیات شکست
مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — در مواجهه با دستورات پیچیده دچار افت دقت میشود. طبق تحلیل دقیقی که در ۷ اوت ۲۰۲۶ در وبسایت dev.to منتشر شد، احتمال موفقیت یک پروژه بزرگ تولیدشده توسط هوش مصنوعی با افزایش تعداد تصمیمات، بهشدت سقوط میکند. اگر فرض کنیم هر تصمیم بهتنهایی شانس سخاوتمندانهی ۹۰٪ برای درست بودن داشته باشد، احتمال موفقیت کل پروژه چنین است:
- ۳ تصمیم: ۷۳٪
- ۵ تصمیم: ۵۹٪
- ۱۰ تصمیم: ۳۵٪
- ۲۰ تصمیم: ۱۲٪
- ۵۰ تصمیم: ۰.۵٪
در یک مستندات جامع و بزرگ، وجود ۲۰ تا ۵۰ تصمیم بسیار رایج است. حتی اگر نرخ موفقیت هر مورد را در سطح ایدهآل ۹۵٪ در نظر بگیریم، در ۲۰ مورد تنها ۳۶٪ شانس موفقیت کلی خواهید داشت. این یعنی ۸۸٪ احتمال دارد که وقتی ۲۰ مورد درگیر هستند، حداقل یک عنصر حیاتی اشتباه باشد. چون حجم کد تولید شده برای بازبینی انسانی بسیار زیاد است، این خطاها معمولاً با ذهنیتی چون «خب، فعلاً اجرا میشود، پس به اندازه کافی خوب است» پذیرفته میشوند تا زمانی که محصول در محیط عملیاتی (Production) شکست بخورد. این چالش دقیقاً همان نقطهای است که ما در تحلیل مدیریت خروجیهای هوش مصنوعی و جایگزینی بازبینی خطبهخط با مدل مسئولیتپذیری به آن پرداختیم تا راهکارهای جایگزین برای نظارت بر کدهای حجیم بیابیم.
پارادوکس مستندات (The Spec Paradox)
نوشتن مستندات دقیقتر برای حذف ابهامات، در واقع یک تله است. نویسنده اشاره میکند که مستندات (Spec)، فشردهسازی دانش موجود است، نه ابزاری برای کشف و اکتشاف. اگر نمیدانید آیا ویژگی خاصی ممکن یا مطلوب است، هر چه بنویسید یک «آرزو» است، نه یک «الزام» فنی.
بهعنوان مثال، نقطه شروع MulmoTerminal یک آزمایش بود: آیا یک ترمینال میتواند درون مرورگر اجرا شود؟ نویسنده نمیدانست آیا قرار دادن ۹ ترمینال در کنار هم در یک تب مرورگر در عمل کاربردی است یا خیر، یا اصلاً آیا این تجربه برای کاربر خوشایند خواهد بود یا نه. وقتی چنین مجهولاتی وجود دارند، نوشتن مستندات غیرممکن است چون نمیتوان چیزی را که هنوز وجود ندارد، فشرده کرد.
وقتی مستندات را تا حدی دقیق میکنید که جای خطایی نماند، در واقع دارید پیادهسازی را روی کاغذ انجام میدهید. شما باید هر تصمیم را فهرست کنید: دکمه کجا قرار بگیرد، وقتی فشار داده شد چه اتفاقی بیفتد و اگر مقداری خالی بود چه شود. با این حال، مستندات «اجرا» نمیشوند. در عصر پیش از هوش مصنوعی، اشتباه روی کاغذ منطقی بود چون بازنویسی کد گران بود. اما اکنون بازسازی کد ارزان است و منطقیتر است که در کدِ در حال اجرا اشتباه کنید تا روی کاغذ.
متدولوژی «برشهای کوچک» (Cut Small)
برای جلوگیری از وضعیت «بزرگتر از آنکه بازبینی شود»، پیشنهاد میشود بهجای سختگیرانه کردن مستندات، پیادهسازی را محدود و متراکم کنید. هدف این است که پروژه به کوچکترین واحدهایی که نیاز به قضاوت دارند تقسیم شود، یکییکی اجرا شوند و بلافاصله مورد قضاوت قرار گیرند.
این رویکرد سه مزیت مشخص دارد:
- دقت بالاتر: قضاوت درباره یک مورد در لحظه، بسیار دقیقتر از مرور سریع ۲۰ مورد بهصورت همزمان است. وقتی به همه چیز با هم نگاه میکنید، جزئیات از بین میروند.
- توانایی تغییر مسیر (Pivot): میتوانید در مورد سوم مسیر را عوض کنید، نه بعد از مورد بیستم. اگر زود متوجه شوید مسیر اشتباه است، از هزینه «بازچیدمان» تمام چیزهایی که تا الان ساختهاید جلوگیری میکنید.
- بازخورد زودهنگام: اجرای سریع کد اجازه میدهد کاربران واقعی نقصهای هدف اصلی را پیدا کنند.
برای اینکه این فرآیند سریالی کند نشود، توصیه میشود وظایف مستقل بهصورت موازی اجرا شوند. یک برنامهنویس با مدیریت حدود ۱۰ جریان موازی هوش مصنوعی، میتواند سرعت بالا را بدون فدا کردن توان بازبینی حفظ کند. برشهای کوچک تنها زمانی کاربردی میشوند که بتوانید موازی عمل کنید؛ در غیر این صورت، تنها گزینه باقیمانده، شرطبندی روی پروژههای بزرگ است.
گلوگاه انسانی
هوش مصنوعی اهرم ما را افزایش داده است، اما اهرم یک ضریب است، نه عددی که ضرب شود. ابزار هوشمندتر شده، اما توانایی انسان در تصمیمگیری درباره درست بودن یک طراحی تغییر نکرده است. تولید متنی متقاعدکننده (Plausible prose) توسط هوش مصنوعی آسان است، اما یک نثر واقعاً عالی — یا یک طراحی فنی استوار — همچنان بسیار دشوار است.
این تغییر در حرکات اخیر صنعت دیده میشود. به گزارش منابع، مدیران ارشدی مانند Peter Bailis (که در مارس ۲۰۲۶ Workday را ترک کرد) و Bryan McCann (بنیانگذار و مدیر فنی You.com)، در سال ۲۰۲۶ نقشهای اجرایی خود را رها کرده و بهعنوان عضو کادر فنی (Individual Contributor) در نقش Member of Technical Staff در Anthropic بازگشتهاند.
نویسنده گمان میکند این مدیران، قدرت سازمانی را با نزدیکی به ابزارها معاوضه کردهاند. در گذشته، ساختن چیزی بزرگ نیازمند یک تیم و سازمان بزرگ بود. اکنون، هوش مصنوعی این ظرفیت را پر میکند. این رهبران ترجیح میدهند «تصمیمگیرنده پشت کیبورد» باشند تا اینکه هزینههای ارتباطی مدیریت تیمهای بزرگ را متحمل شوند.
خطر بازبینی توسط هوش مصنوعی
استفاده از هوش مصنوعی برای بازبینی کدهای تولیدشده توسط هوش مصنوعی، راهکار مناسبی نیست. مدلها از محدودیت پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — و فقدان قضاوت کلی درباره طراحی رنج میبرند. اگر تغییرات کد (diff) خیلی بزرگ باشد، باید تکه تکه شود و این باعث میشود باگهایی که در مرز بین دو بخش قرار دارند (جایی که A و B با هم همراستا نیستند)، دیده نشوند.
برای مثال، هوش مصنوعی ممکن است تأیید کند که هر تابع در یک فایل زیر ۶۰ خط است (پاس کردن تستهای Linting)، اما متوجه نشود که فایل به ۳۰۰۰ خط رسیده و ۱۱ وظیفه نامرتبط را در خود جای داده است. نویسنده به فایلهای CollectionView.vue (۲۹۴۵ خط، ۱۸۷ تابع) و server/index.ts (۳۰۲۰ خط، ۲۱۲ تابع) اشاره میکند. در هر دو مورد، طولانیترین توابع زیر ۸۲ خط بودند، بنابراین ماشین هرگز اعتراضی نکرد، در حالی که معماری فایلها کاملاً فروپاشیده بود.
شواهد دنیای واقعی
در ساخت MulmoTerminal، نویسنده گردش کار خود را طی ۵۳ روز (۱۴ ژوئن تا ۶ اوت ۲۰۲۶) رصد کرد. دادهها الگویی با سرعت بالا و ریسک پایین را نشان میدهد:
- تعداد کامیتها: ۳۲۳۵
- PRهای ادغامشده: ۱۱۷۰
- نسخههای منتشرشده: ۶۴ (حدود ۱.۲ مورد در روز)
- اندازه میانه PRها: ۲۸۶ خط (۵۱٪ زیر ۳۰۰ خط)
- میانگین فایلهای تغییریافته: ۷ مورد
- حل مشکلات: ۷۷٪ در ۶ ساعت و ۹۲٪ در ۲۴ ساعت بسته شدند؛ میانه زمان حل ۱.۶ ساعت بود.
این نتیجه با تبدیل «مشکلات» (Issues) به یادداشتهایی برای اصلاحات فوری بهجای مستندات بلندمدت بهدست آمد. چرخه به این صورت است: مشاهده نقص $ \rightarrow $ باز کردن Issue $ \rightarrow $ نوشتن گامها توسط هوش مصنوعی $ \rightarrow $ اصلاح گامها توسط انسان $ \rightarrow $ پیادهسازی توسط هوش مصنوعی. نویسنده ۳۵۱ فایل برنامهریزی (۱۶۶ ویژگی، ۱۳۲ اصلاح، ۳۷ پاکسازی و ۱۶ مورد دیگر) را مدیریت کرد که ۷۹٪ آنها دارای شماره Issue بودند.
محدودیتهای پیشبرنامهریزی
برخی تصمیمات را نمیتوان تا پیش از اجرای کد گرفت. نویسنده دو مثال عینی میزند که در آنها مستندات شکست میخورد:
مثال اول: هدف اشتباه
MulmoTerminal برای افزایش سقف تعداد عاملهای هوش مصنوعی که یک کاربر میتواند بهطور موازی اجرا کند، ساخته شد. اما پس از پرسش از ۴ کاربر، مشخص شد هیچکس احساس نمیکند به عاملهای بیشتری نیاز دارد. در عوض، آنها متوجه شدند که میتوانند همان تعداد را «راحتتر» مدیریت کنند. ارزش واقعی در «گم نکردن مسیر» بود، نه «بالا بردن سقف».
این کشف منجر به درک دیگری شد: اعلانها (Notifications) که قرار بود به کاربران کمک کنند عاملهای بیشتری را اجرا کنند، در واقع سقف جدیدی ایجاد کردند. چون صدای اعلان «پایان یافت» و «منتظر شماست» یکسان بود، کاربران نمیتوانستند آنها را تشخیص دهند و در نهایت خسته شده و متوقف شدند. این نمونهای عینی از مشکلی است که پیش از ساختن محصول، قابل شناسایی نیست.
مثال دوم: منطق متقاعدکننده اما غلط هوش مصنوعی
یک بار هوش مصنوعی توصیه کرد که کدهای تکراری را ادغام نکند و استدلال کرد که این تکرار «ساختاری» است و ادغام آن خوانایی را در یک فایل ۲۷۰۰ خطی کاهش میدهد. مدل از یک اصل درست استفاده کرد («یک انتزاع غلط بدتر از تکرار است»)، اما در مورد این کد خاص اشتباه میکرد. تنها با باز کردن دستی فایل مشخص شد که ادغام کد، محیط را تمیزتر میکند.
بازتعریف اندازه تیم
در عصر هوش مصنوعی، اندازه تیم باید بر اساس «میزان قضاوت مورد نیاز» تعیین شود، نه «حجم پیادهسازی». چون هوش مصنوعی بخش بزرگی از کدنویسی را بر عهده میگیرد، هزینه اصلی اضافه کردن افراد، رشد کانالهای ارتباطی است که با فرمول $n(n-1)/2$ افزایش مییابد:
- ۲ نفر: ۱ کانال
- ۴ نفر: ۶ کانال
- ۸ نفر: ۲۸ کانال
- ۱۰ نفر: ۴۵ کانال
برای محصولاتی که هنوز در حال اکتشاف هستند، قانون پیشنهادی ۱ تا ۳ نفر برای هر محصول است. این کار تضمین میکند تصمیمگیرنده پشت کیبورد بماند و فاصله بین قضاوت و کد صفر باشد. این قانون زمانی صادق است که مالک بتواند کد را لمس کند، یک نفر بتواند کل پروژه را در ذهن خود نگه دارد و هیچ صف تأییدی (Approval Queue) نداشته باشد.
این به معنای کاهش کل نیروی انسانی نیست، بلکه توزیع آنها در محصولات بیشتر است. بهجای ۸ نفر روی یک محصول، مدل پیشنهادی ۲ نفر روی ۴ محصول مختلف است. این کار تعداد ایدهها و حلقههای بازخورد را به حداکثر و هزینه هماهنگی در واحد ساخت را به حداقل میرساند.
سقف موازیسازی
حتی برای یک نفر، سقفی برای مدیریت موازی وجود دارد. محدودیتهای نویسنده چنین است:
- بازبینی و قضاوت: حدود ۱۰ مورد
- تفکر درباره طراحی: ۵ مورد
- پروژههای کمتأمل: ۳ تا ۴ پروژه
- وابستگیها و بازتولید باگها (Repros): ۱ مورد (غیرقابل موازیسازی)
وقتی بهرهوری به ۱۰۰٪ میرسد، زمانهای انتظار بهشدت افزایش مییابد. برای بالا بردن این سقف، برنامهنویس باید بخشهایی را که بدون او حرکت نمیکنند کاهش دهد؛ این کار با تصمیمگیری طراحی در ابتدا، نوشتن گامهای بازتولید باگ در اولویت اول و حذف زودهنگام وابستگیها ممکن است.
در نهایت، تنها راه ساخت یک محصول باکیفیت این است که مالک محصول، پرکاربردترین کاربر آن باشد. بدون دادههای تجربی که از استفاده روزمره میآید، هیچ اهرمی نمیتواند هدف اشتباه یک محصول را اصلاح کند. همانطور که نویسنده اشاره میکند، ابزار میتواند ۹ ترمینال را نشان دهد، اما این انسان است که بسته به اینکه در حال طراحی است یا فقط مرور میکند، سقفش روی ۵ یا ۱۰ مورد است.
گام بعدی شما
- پروژههای فعلی خود را به واحدهای کوچکتر از ۳۰۰ خط کد تقسیم کنید تا بازبینی انسانی ممکن شود.
- بهجای نوشتن مستندات جامع (Spec)، از چرخه «مشاهده $ \rightarrow $ اصلاح $ \rightarrow $ پیادهسازی» استفاده کنید.
- اگر مدیر تیم هستید، تعداد افراد در هر واحد محصول را به حداکثر ۳ نفر برسانید تا هزینه ارتباطات کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو