تصور کنید برنامهنویسی را فراموش کنید و فقط روی «چیستی» و «چرایی» سیستم تمرکز کنید، در حالی که کدنویسی به یک جزئیات فنیِ سطح پایین تبدیل شده است. اگر هنوز برای ساخت ویژگیهای جدید به زنجیرهای از پرامپتهای طولانی تکیه میکنید، احتمالاً در حال تولید بدهی فنی هستید که هیچکس نمیتواند آن را بازرسی کند.
کارسون گراس (Carson Gross)، استاد دانشگاه ایالت مونتانا و مشاور توسعه، استدلال میکند که در عصر کدنویسی عاملمحور (Agentic) — یعنی سیستمی که در آن هوش مصنوعی بهطور مستقل برنامهریزی و اجرا میکند — منبع حقیقت در پروژهها در حال ناپدید شدن در فضای سیاه لاگهای چت است. طبق اعلام گراس، مارکداون دیگر صرفاً ابزاری برای مستندسازی نیست، بلکه در حال تبدیل شدن به خودِ کد منبع است.
گراس نقش آکادمیک خود را با مشاوره ترکیب میکند تا مهارتهایش را بهروز نگه دارد و جدیدترین ایدههای توسعه نرمافزار را به دانشجویانش بیاموزد. او پیش از این در مقالاتی چون «بله، و...» (Yes, and...)، «کد ارزانتر است» (Code is Cheap(er))، «دانشگاه در عصر هوش مصنوعی» و «کار با هوش مصنوعی: یک مثال عینی»، این تغییر پارادایم را بررسی کرده است.
این تغییر در حالی رخ میدهد که سازمانها پذیرش عاملهای هوش مصنوعی (AI Agents) — شبیه دستیارهای هوشمندی که میتوانند ابزارها را مدیریت کنند و هدف را دنبال کنند — را برای تولید نرمافزار تسریع کردهاند. این روند تکامل ابزارها را به سمتی میبرد که ساختارهای اجرایی پیچیدهتری مانند ارکستراسیون چند-عاملی در ابزارهایی مثل Claude Code جایگزین چتهای ساده شوند. بهطور سنتی، برنامهنویسان ابتدا کد مینوشتند و سپس مستندات را آماده میکردند. اما امروز بسیاری از توسعهدهندگان از رشتهای از پرامپتها برای ساخت ویژگیها استفاده میکنند و کد تولیدشده تنها رکورد باقیمانده از منطق سیستم است. این وضعیت شکاف خطرناکی ایجاد میکند؛ جایی که دلیل وجود یک ویژگی (the why) فقط در یک جلسه چت زودگذر یا رشتهپیامهای پراکنده در اسلک (Slack) موجود است.
استعاره کامپایلر
همانطور که در تحلیلهای قبلی ما درباره امنیت مدلهای بازمتن اشاره کردیم، فقدان یک منبع حقیقتِ قابل بازرسی، ریسکهای عملیاتی را افزایش میدهد. گراس به این باور اشاره میکند — که هارتلی برودی (Hartley Brody) نیز در مقاله «مارکداون کد منبع جدید است» بر آن تأکید کرده — که مدلهای زبانی بزرگ (LLM) در واقع مانند کامپایلرهایی عمل میکنند که مشخصات سطح بالا را به پیادهسازی سطح پایین تبدیل میکنند. در این دیدگاه، کد تولیدشده توسط عامل، شبیه به کد ماشین است؛ جزئیاتی که توسعهدهنده نیازی به بررسی دقیق آن ندارد.
با این حال، گراس به یک نقص حیاتی در این مقایسه اشاره میکند: کامپایلرهای سنتی کد منبع اصلی را حفظ میکنند، اما گردشکارهای LLM اغلب پرامپتها را دور میاندازند. امروزه، کد تولیدشده نزدیکترین چیزی است که به «حقیقت زمینی» (Ground Truth) داریم، در حالی که نیت واقعی توسعهدهنده در ابزارهایی مثل Linear، رشتههای اسلک یا ویکیها پراکنده شده است.
برای حل این مشکل، گراس استانداردی جدید پیشنهاد میدهد: انتقال مشخصات مارکداون مستقیماً به دایرکتوری منبع. او پیشنهاد میکند پوشهای به نام /src/md ایجاد شود تا رفتار مورد انتظار سیستم در آن ذخیره و تحت کنترل نسخه (Version Control) قرار گیرد. این کار تضمین میکند که جلسات پرامپت در نهایت به مارکداونهای ماندگار تبدیل شوند، نه اینکه به صورت موقت باقی بمانند.
چارچوب /src/md
بر اساس مقالهای که در ۲۱ سپتامبر ۲۰۲۶ منتشر شد، این دایرکتوری باید شامل اسنادی باشد که از مستندات طراحی کلی، جزئیتر و از کد، کلیتر هستند. مارکداون برای این کار ایدهآل است چون متن ساده است — که آن را قابل Diff (مقایسه تغییرات)، قابل Grep (جستجوی متنی) و قابل بررسی در Pull Requestها میکند — و هم انسانها و هم LLMها بهطور بومی آن را میخوانند و مینویسند.
این پوشه شامل موارد زیر خواهد بود:
- تصمیمات معماری و منطق سطح منبع.
- طراحی دادههای سطح پایین و توصیفات API.
- مشخصات مبتنی بر نیت (Intent-based) که عاملها میتوانند مستقیماً بخوانند.
- محدودیتهای فنی که به یک مشخصه (Specification) نزدیکترند تا یک سند طراحی مدیریتی سنتی.
گراس اشاره میکند که برخی توسعهدهندگان در حال حاضر از فایلهایی مانند AGENTS.md یا TASK.md و یا برنامههایی در مسیرهای .scratch/research/ و .scratch/plan/ (مانند روش برودی) یا دایرکتوریهای /tmp استفاده میکنند. هدف این است که این یادداشتهای زودگذر به یک دایرکتوری رسمی /src/md ارتقا یابند.
قرارداد پیشنهادی دایرکتوری
گراس ساختار پیشنهادی خاصی را برای حفظ این نظم معرفی میکند. او اشاره میکند که اگرچه این یک ایده جدید است که هنوز در حال بررسی آن است، اما نقطه شروع مناسبی برای یک استاندارد فراهم میکند:
README.md: فهرستی از تمام فایلهای مارکداون و نقطه ورود اصلی برای عاملهای هوش مصنوعی.TODO.md: لیستی از کارهای باقیمانده (TODOs) کلی که برای آن ماژول خاص باز هستند.OVERVIEW.md: نمای کلی فنی از هدف و کاربرد ماژول.features/FEATURE_1.md: مجموعهای از اسناد مربوط به ویژگیهای خاص.data/DATAMODEL_1.md: توصیف مدلهای داده در داخل ماژول.api/API_1.md: توصیف APIهایی که ماژول ارائه میدهد.infrastructure/INFRASTRUCTURE_1.md: توصیف زیرساختهای مورد استفاده توسط ماژول.
او تصریح میکند که دایرکتوریهای features، data، api و infrastructure همگی اختیاری هستند. هدف اصلی این است که مستندات در محورهای مختلف تقسیم شوند تا بهترین توصیف عملی از رفتار ماژول مستقیماً در پوشه /src/md ثبت شود.
موضعیت و حقیقت
با قرار دادن مارکداون در /src، توسعهدهندگان به «موضعیتی» (Locality) میرسند؛ یعنی منطق توضیحدهنده کد، دقیقاً در کنار خودِ کد قرار میگیرد. این کار «مشخصات در فاصله» (Specification at a distance) را از بین میبرد؛ وضعیتی که در آن دلیل یک ویژگی در یک تیکت جیرا (Jira)، صفحه نوشن (Notion) یا ویکی کانفلوئنس (Confluence) دفن شده است.
این رویکرد اجازه میدهد تفکیک روشنی بین انواع مستندات ایجاد شود. اسناد طراحی سطح بالا و مسائل فرآیند-محور (که نیاز به گردشکار حل مسئله دارند) همچنان میتوانند در ویکیهای خارجی باشند. اما رفتار مورد انتظارِ هسته و استاتیک سیستم مستقیماً در دایرکتوری منبع ثبت میشود و به عاملها اجازه میدهد بدون جستجو در جاهای دیگر، زمینه (Context) لازم را به دست آورند.
نقش تستها
این رویکرد نقش تستهای خودکار را نیز تغییر میدهد. در حالی که برخی استدلال میکنند تستها همان مشخصات جدید هستند، گراس معتقد است آنها مکانیسم خوبی برای تعامل انسان و عامل نیستند زیرا:
- آنها شامل تشریفات (Ceremony) زیادی هستند و اغلب آنچه واقعاً تست میشود را میپوشانند.
- معمولاً برای اینکه انسانها بهراحتی یک سیستم را درک کنند، بیش از حد سطح پایین (Low-level) هستند.
- نمیتوانند بهطور طبیعی توضیحات سطح بالا، مانند نمودارهای Mermaid، را در خود جای دهند.
در عوض، او تقسیم کار جدیدی پیشنهاد میکند: مارکداون در /src بهعنوان مشخصه (Specification-ish) عمل کند و تستها در /test (یا هر جای دیگر) از روی آن مارکداون مشتق شوند تا تأیید خودکاری از صحت کد ارائه دهند. بهجای تولید کد و تست از طریق پرامپتها، توسعهدهنده روی مارکداون در /src کار میکند و کد و تستها از آنجا مشتق میشوند.
نقش انسان در چرخه
نکته کلیدی این است که محتوای /src/md باید عمدتاً توسط انسان نوشته و مدیریت شود. گراس استدلال میکند که نباید از عاملها برای تولید محتوای زیاد در این دایرکتوری استفاده کرد. انسانها باید «بودجه پیچیدگی» (Complexity Budget) مارکداون را مدیریت کنند تا اسناد تمیز، بهخوبی فاکتور شده و در سطح انتزاع درستی باقی بمانند.
توسعهدهندگان به مهارت جدیدی نیاز دارند: همگامسازی (Synchronizing). وقتی برنامهنویس تغییری کاهشی یا محدودکننده در کد تولیدشده توسط AI ایجاد میکند، آن تغییرات باید بهصورت دستی به مارکداون بازگردانده شوند تا منبع حقیقت حفظ شود.
این گذار بازتابدهنده یک تغییر گستردهتر در ارزشهاست. وقتی هزینه تولید کد خام به سمت صفر میل میکند، ارزش به «نیت» (Intent) منتقل میشود؛ اینکه سیستم چه میکند، چرا این کار را میکند و چه کارهایی را نباید انجام دهد. این اتکای شدید به ابزارهای تولید کد، نگرانیهایی را برانگیخته است که آیا دستیارهای کدنویسی ممکن است مانع از شکلگیری تفکر سیستمی در برنامهنویسان تازهکار شوند. برای کسانی که در حال حاضر به زنجیرههای طولانی پرامپت تکیه میکنند، ریسک ایجاد بدهی فنی است که قابل بازرسی نیست. انتقال به مدل «اول مارکداون»، اجازه میدهد Pull Requestها بهجای نحو (Syntax)، روی منطق تمرکز کنند و قابل Diff، Grep و بررسی باشند. گراس در نهایت نتیجه میگیرد که اگرچه LLMها در واقع کامپایلر نیستند، اما ما باید با مارکداون مانند کد منبع رفتار کنیم، زیرا نیت واقعی سیستم اکنون در آنجا جای دارد.
گام بعدی شما
- در پروژه بعدی خود، پوشه
/src/mdرا ایجاد کنید و سعی کنید منطق پیچیده را بهجای پرامپت، در فایلهای.mdبنویسید. - برای هر ویژگی جدید، ابتدا یک فایل در
features/ایجاد کنید و سپس از عامل هوش مصنوعی بخواهید کد را بر اساس آن فایل تولید کند. - بررسی کنید کدام بخش از منطق سیستم شما در حال حاضر فقط در تاریخچه چتهای AI یا تیکتهای مدیریتی موجود است و آنها را به کد منبع منتقل کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو