تصور کنید تنها یک سند راهنمای ورود به پروژه (Onboarding) برای ۴۰ توسعهدهنده نوشته شده است؛ این سند دقیقاً همان لحظهای میپاشد که سعی کند همزمان هم یک راهنمای مفید باشد و هم یک کتاب قانون سختگیرانه. به نقل از کارل-هینز رایشل در ژوئن ۲۰۲۶، ادغام این دو کارکرد باعث ایجاد سیستمی میشود که در آن تازهواردها قوانین را نادیده میگیرند و متخصصان احساس خفقان میکنند. این یک تقابل بنیادی میان «اصطکاک برای کاربران حرفهای» و «نردههای ایمنی برای تازهواردها» است.
این اصطکاک دقیقاً زمانی رخ میدهد که تیمها استفاده از عاملها (Agents) را مقیاس میکنند. بسیاری از تیمها با «برنامهنویسی سهگانه» — یعنی دو توسعهدهنده و یک عامل — شروع میکنند تا تسکها را پیش ببرند و تسلط مشترک بر ابزار را ایجاد کنند. این روند اتکای شدید به هوش مصنوعی در تولید کد را به نمایش میگذارد؛ مشابه آنچه در گزارشهای اخیر درباره تسلط عاملهای هوش مصنوعی بر بخش بزرگی از کدهای تولیدی Anthropic مشاهده شده است. این ساختار گذاری زمانی مفید است که ریسک تغییرات گسترده در کد توسط عامل همچنان بالا باشد. اما این ساختار در مواجهه با ۴۰ توسعهدهنده دوام نمیآورد. در مقیاس تیم، شما نمیتوانید ساختار سهگانه را تا ابد حفظ کنید و نباید بخواهید چنین کاری کنید. واقعیت این است که برخی توسعهدهندگان بهتازگی با کدنویسی عاملمحور (Agentic) آشنا شدهاند، در حالی که برخی دیگر ماههاست که بهصورت انفرادی از مهارتهای پیشرفته و سامانههای چندعاملی استفاده میکنند.
غریزهی بسیاری از تیمها این است که همهچیز را در یک منبع واحد نظمی — مانند فایلهای CLAUDE.md یا copilot-instructions.md یا مجموعهای از قوانین مشترک — بنویسند. این اسناد معمولاً دستور میدهند که توسعهدهنده پیش از تغییر کد برنامهریزی کند، از دست زدن به فایلهای خارج از محدوده تسک اجتناب کند و دلیل تصمیماتش را پیش از اقدام توضیح دهد. نتیجه این است که تازهواردها به این سند نیاز دارند اما بهندرت آن را میبینند، در حالی که متخصصان پس از یک بار خواندن دقیق، بلافاصله میخواهند محدودیتها را کنار بزنند. این موضوع ناشی از کمصبر بودن نیست، بلکه نتیجهٔ این است که از یک سند خواستهایم دو شغل متفاوت را انجام دهد که اصلاً با هم سازگار نیستند.
در ادامه پوششهای قبلی ما دربارهی «مشکل مایل آخر» و اینکه چگونه توسعه هدایتشده توسط ادیتور (EDD) این چرخه را میبندد (هرچند تنها نیمی از آن را)، باید گفت مسئله اصلی یک «خطای مقولهای» است. تیمها اغلب ابزارهایی که «آنچه فرد میداند» را تغییر میدهند با ابزارهایی که «آنچه فرد میتواند انجام دهد» را تغییر میدهند، اشتباه میگیرند.
پذیرشگر در برابر گیت کنترل
رایشل برای تبیین تفاوت ابزارهای آگاهی و حاکمیت از دو استعاره استفاده میکند تا نشان دهد چگونه آگاهی و حاکمیت از یکدیگر متمایز میشوند:
- پذیرشگر (ابزارهای آگاهی): ابزارهایی مانند هشدارهای Linter، نظرات بازبینی هوش مصنوعی یا پیشنهادی برای درگیر کردن یک تیم دیگر. این ابزارها مشکل را شناسایی و اعلام میکنند. با این حال، آنها تنها در صورتی اثر دارند که فرد در طرف دریافتکننده بخواهد به آنها عمل کند. یک توصیه درست که هیچ قدرت اجباری پشت آن نیست، همچنان فقط یک توصیه است. اگر توسعهدهندهای با وجود پرچم هشدار بازبینی هوش مصنوعی، یک تغییر ریسکپذیر در رابط (Interface) را ادغام (Merge) کند، پذیرشگر شکست خورده است چون او صرفاً یک ابزار آگاهی بود.
- گیت کنترل (ابزارهای حاکمیت): موانع ساختاری مانند حفاظت از شاخهها (Branch Protection)، بازبینهای اجباری و گیتهای ادغام که بهسادگی باز نمیشوند. این ابزارها مذاکره نمیکنند. این همان مکانیزمی است که تغییر میدهد توسعهدهنده «چه کاری میتواند» انجام دهد.
نوشتن الزام برنامهریزی در یک سند مشترک، شبیه استخدام یک پذیرشگر است در حالی که شما در واقع به یک گیت کنترل نیاز داشتید. برای توسعهدهندهای که دو هفته است کدنویسی عاملمحور را شروع کرده، پرامپت برنامهریزی یک نرده ایمنی ضروری است. اما برای یک متخصص که این مراحل را بهطور خودکار درونی کرده و چندین مهارت پیشرفته دارد، همین دستورالعمل مانند پذیرشگری است که بدون هیچ دلیل مرتبط با ریسک واقعی، جلوی کسی را میگیرد که تمام مجوزهای لازم را دارد.
برعکس، اگر نردههای ایمنی برای کارکنان ارشد اختیاری شود، حاکمیت برای همه به «صرفاً آگاهی» تبدیل میشود. لحظهای که ارشدترین فرد اتاق تصمیم بگیرد قانون امروز اجرا نشود، گیت کنترل عملاً برای کل تیم حذف شده است.
پیادهسازی دو لایه کنترل
راهکار پیشنهادی، جداسازی کامل این دو لایه است تا بهجای ترکیب در یک فایل، کاملاً متمایز شوند. این اصلاح از همان منطق گیتهای ادغام پیروی میکند: آگاهی و حاکمیت را به عنوان دو لایهی مجزا نگه دارید، نه دو پاراگراف در یک فایل.
لایه حاکمیت باید کوچک، وابسته به مخزن (Repository) و برای همه یکسان باشد. این لایه بر اساس «شعاع تخریب» تنظیم میشود، نه سطح مهارت انسان. چون توانایی یک عامل در ایجاد تخریب گسترده، به دلیل تجربه داشتن توسعهدهنده کاهش نمییابد، محدودیتهای ساختاری زیر غیرقابل مذاکره هستند:
- ممنوعیت کامل Push مستقیم به شاخههای محافظتشده.
- عدم اجازه تغییرات خارج از محدوده اعلامشده برای تسک.
- بازبینی اجباری انسانی پیش از هرگونه ادغام.
این لایه از طریق سیستم کنترل نسخه، گیتهای CI/CD و فایلهای CODEOWNERS اجرا میشود. این لایه فارغ از اینکه روی ماشین چه کسی اجرا شود، همراه با مخزن جابهجا میشود. این لایه بهصورت ساختاری تحمیل میشود، نه اینکه صرفاً در یک پرامپت درخواست شود. این امر تضمین میکند که یک توسعهدهنده ارشد نتواند قوانین را «نادیده بگیرد»، همانطور که یک تازهوارد نمیتواند؛ سیستم درباره شعاع تخریب است، نه اعتماد.
لایه داربست (Scaffolding) شخصی است و طراحی شده تا با گذشت زمان کوچک شود. این همان لایه «پذیرشگر» است که هدف آن فراهم کردن شکلی از قضاوت خارجی است که توسعهدهنده هنوز آن را درونی نکرده است. این لایه شامل موارد زیر است:
- الزام به برنامهریزی صریح پیش از هر تغییر.
- استقرار ساختار سهگانه (حضور یک نفر دوم در چرخه).
- توضیحات مفصل در هر مرحله از فرآیند.
این یک قانون پروژه نیست، بلکه یک پروفایل شخصی کدنویسی است. این همان پذیرشگری است که برای کسی که در حال ساختن قدرت قضاوت است، بهطور عمدی صدایش بلند است و برای کسی که آن را اثبات کرده، آرام شده است. وقتی قضاوت توسعهدهنده درونی شد، داربست کار خود را انجام داده و کنار میرود. این یک «استثنا» نیست، بلکه موفقیت داربست در بینیاز کردن کاربر است.
آستانههای دادهمحور و مالکیت
برای جلوگیری از اینکه این لایهها 임اری یا صرفاً بر اساس سابقه شغلی و مدت حضور در شرکت به نظر برسند، رایشل پیشنهاد میکند دادهها تعیینکننده آستانه باشند. این کار از طریق دو ورودی متمایز انجام میشود:
- تاریخچه جفتشدگی (Coupling History): استفاده از تاریخچه واقعی Commitها برای تعیین ریسک. اگر فایلی سابقه تغییر همزمان با کدهایی را دارد که تیمهای متعدد به آنها وابسته هستند، تغییر آن یک رویداد پرخطر است. این روش از جفتشدگی تغییراتِ مشتق شده از تاریخچه واقعی استفاده میکند، نه یک نظر ایستا درباره اینکه کدام فایلها «مهم» هستند.
- کارنامه توسعهدهنده: عملکرد واقعی توسعهدهنده در طول جلسات — یعنی عدم تخطی از محدوده، قضاوت درست در زمان بازبینی و تسلط اثبات شده — است که داربست او را کوچک میکند، نه عنوان شغلیاش.
این یعنی یک تازهوارد که یک تابع کمکی ایزوله را ویرایش میکند، شاید فارغ از ردهبندیاش به داربست کامل نیاز نداشته باشد. در مقابل، یک متخصص که یک رابط شدیداً جفتشده را تغییر میدهد، نباید صرفاً بهدلیل ارشد بودن بدون اصطکاک عبور کند. گیت در هر دو جهت صادق میماند چون دو سوال متفاوت میپرسد: «چه کسی تغییر را ایجاد میکند؟» و «این تغییر واقعاً چه ریسکی دارد؟». تنها یکی از این سوالات درباره شخص است و دیگری درباره کد.
پاسخگویی به عنوان آخرین گیت
یک راه برای دور زدن تقریباً کامل مشکل لایهبندی، تمرکز بر «مالکیت» است. اصل اساسی این است که عبارت «هوش مصنوعی این کار را کرد» دفاعی برای یک باگ نیست، همانطور که «Linter خطا نداد» هرگز نبود. توسعهدهندهای که درخواست ادغام (PR) میدهد، مالک تمام تغییرات موجود در Diff است.
یک آزمون ساده برای مالکیت واقعی وجود دارد: آیا توسعهدهنده میتواند در حین بازبینی توضیح دهد تغییر چه کاری انجام میدهد و چرا — بدون اینکه به توضیحات خودِ عامل متکی شود؟ اگر نتواند، کد ادغام نمیشود. این قضاوتی درباره صلاحیت کلی او نیست، بلکه تایید میکند که نقش «ویراستار» توصیف شده در EDD واقعاً برای این تغییر خاص اعمال شده است و صرفاً مهر تأیید زده نشده است.
این روش کار میکند چون نیازی به دستهبندی پیشفرض هیچکس ندارد. این همان قانون برای استخدام جدید و متخصص ده ساله است که پس از انجام تغییر اعمال میشود. در ترکیب با حفاظت از شاخهها که نیاز به تأیید دارد، این یک گیت کنترل به معنای واقعی کلمه است؛ در اینجا «قابلیت توضیح» شرط عبور تغییر است، نه یک پیشنهاد.
ابزار «حالت ایمن» (Safer Mode)
برای پر کردن شکاف بین حاکمیت سخت و داربست شخصی، این چارچوب «حالت ایمن» را معرفی میکند. این یک مهارت یا پرچم (Flag) است که عامل را به محدوده اعلامشده بهطور صریح محدود میکند و او را مجبور میکند پیش از دست زدن به هر چیز مجاور، اجازه بگیرد.
برخلاف ردهای که هنگام ورود به پروژه اختصاص داده میشود و مانند یک وضعیت یا برچسب عمل میکند، «حالت ایمن» ابزاری است که برای هر تسک فراخوانی میشود. این بازتعریف حیاتی است:
- وضعیت (Status): برچسبی که هنگام ورود اختصاص مییابد و شخص را تعریف میکند.
- ابزار (Tool): حالتی که توسعهدهنده برای یک بعدازظهر خاص انتخاب میکند چون تغییر مورد نظر، بخشی از کد را لمس میکند که با آن آشنا نیست.
توسعهدهندگان ارشد باید زمانی که در مناطق ناشناخته کدنویسی میکنند، به سراغ این ابزار بروند. گیت توضیحپذیری در پایان، این انتخاب را consequential (دارای پیامد) میکند: اگر توسعهدهندهای در یک تغییر ناشناخته از «حالت ایمن» استفاده نکند، شکاف در درک او در مرحله بازبینی لو میرود، نه سه هفته بعد در محیط عملیاتی.
البته هنوز کسی باید تعریف کند که «حالت ایمن» دقیقاً چه چیزهایی را محدود میکند و کدام ریسکهای جفتشدگی باعث بازبینیهای سختتر میشود. با این حال، تغییر در اینکه چه کسی تصمیم میگیرد چه زمانی از این ابزارها استفاده کند، فرآیند را از یک «وضعیت تحمیلی» به یک «ابزار انتخابی» تبدیل میکند.
الگوی حاکمیت و آگاهی در هر دو مورد گیت ادغام و سند ورود به پروژه یکسان است: ابزارهای آگاهی و ابزارهای حاکمیت مشکلات متفاوتی را حل میکنند. ابزاری که برای یکی ساخته شده، وقتی بخواهد کار دیگری را انجام دهد شکست میخورد، و اغلب این شکست را اعلام نمیکند. راهکار این است که حاکمیت را کوچک، جهانی و غیرقابل مذاکره نگه داریم — متمرکز بر مالکیت و توضیحپذیری — در حالی که اجازه دهیم آگاهی و داربستها ابزارهای شخصی باشند که توسعهدهنده بر اساس تسک پیشرو انتخاب میکند.
گام بعدی شما
- تفکیک سریع فایلهای
.mdراهنمای پروژه به دو بخش: «قوانین سخت سیستم» و «پیشنهادهای شخصی برای یادگیری». - پیادهسازی گیتهای CI/CD که اجازه تغییر در فایلهای حساس (High Coupling) را بدون بازبینی دو نفره نمیدهند.
- تمرین «توضیح بدون هوش مصنوعی» در جلسات Code Review برای اطمینان از مالکیت واقعی کد.
اما تأمین سختافزاری برای اجرای این عاملها در مقیاس بزرگ، چالشهای متفاوتی دارد — به تحلیل ما درباره بهینهسازی هزینه استنتاج در سازمانها مراجعه کنید.
گفتگو