تصور کنید برنامه‌نویسی را به جای نوشتن خط به خط کد، به یک گفتگوی دوستانه تبدیل کنید که در آن فقط می‌گویید «چه می‌خواهید» و جادو اتفاق می‌افتد. این لذتِ کدنویسی با پرامپت‌های خالی، درست مثل رانندگی با یک ماشین تک‌پدالی است؛ برای مسافت‌های کوتاه هیجان‌انگیز است، اما در سفرهای طولانی شما را به بن‌بست می‌کشاند. در حالی که ابزارهایی مثل Claude Code و Codex مفهوم Vibe Coding (کدنویسی بر اساس حس) را رایج کردند، این رویکرد اغلب بافت سیستماتیک و اتصالات پیچیده‌ای که برای نگهداری نرم‌افزارهای بزرگ در طول زمان لازم است را نادیده می‌گیرد.
مهندسی نرم‌افزار سال‌ها بر این اصل استوار بود که مسیر درست باید آسان و مسیر غلط سخت باشد. سادگی، هدف نهایی بود که باید برای رسیدن به آن تلاش کرد؛ فلسفه‌ای که در کتاب‌های کلاسیک طراحی، با تصویری از یک قوری قهوه خطرناک روی جلد، بازتاب یافته است. نویسنده این تحلیل، توسعه‌دهنده‌ای است که به صورت خودآموز کدنویسی را در زمانی یاد گرفت که «یاد گرفتن کدنویسی» یک عبارت رایج بود. او مسیر شغلی خود را بر پایه عشق به ساخت رابط‌های کاربری (UI) و محصولات بنا کرد و اصول پایه تجربه کاربری (UX) و طراحی محصول را در هر پروژه ادغام نمود.
با ظهور مدل‌های زبانی بزرگ (LLM) و عامل‌ها (Agents) به عنوان پارادایم غالب، صنعت به سمت رابط‌های زبان طبیعی و صوتی رفت که وعده می‌دادند تمام مشکلات را صرفاً با «فهمیدن» خواسته کاربر حل کنند. حالا ما می‌توانیم پیچیده‌ترین کارهای زندگی، مثل رزرو رستوران، را با صحبت کردن با یک ربات در همان زمانی انجام دهیم که قبلاً به صورت دستی وقت می‌گرفت. بلندپروازانه‌تر از آن، این ایده که یک بوم خالی وجود داشته باشد و کامپیوتر بتواند به تنهایی قصد ما را درک کند، به نظر می‌رسید تمام مشکلات توسعه نرم‌افزار را حل می‌کند. این تکیه بر توانایی‌های استدلالی مدل‌ها در حوزه‌های تخصصی، یادآور دستاوردها و چالش‌های GPT-4o در تشخیص‌های پزشکی است که نشان می‌دهد مدل‌ها در عین دقت بالا، همچنان در برخی جنبه‌های کاربردی با محدودیت‌هایی روبرو هستند.
اصطکاک در مقیاس بزرگ
این سادگی ظاهری، پیچیدگی خطرناکی را در پسِ خود پنهان می‌کند که بعد از انتشار نسخه‌ی اول ظاهر می‌شود. به نقل از گزارشی مفصل در dev.to که در ۱۶ اکتبر ۲۰۲۶ منتشر شد، سخت‌ترین بخش توسعه نرم‌افزار، نوشتن کد اولیه نیست، بلکه همراستا نگه داشتن تیم‌های پراکنده است.
در شرکت‌های بزرگ و از نظر جغرافیایی پراکنده، اصطکاک واقعی زمانی رخ می‌دهد که جلسات هفتگی تمام می‌شوند. وقتی قراردادهای نانوشته تغییر می‌کنند، سرویس‌ها از کار می‌افتند. این مشکل هماهنگی انسانی، دقیقاً مشابه چالشی است که کاربران در کدنویسی عامل‌محور (Agentic) با آن روبرو هستند: عامل‌ها (Agents) — مثل دستیارهای هوشمندی که می‌توانند ابزارها را اجرا کنند — زمینه (Context) را فراموش می‌کنند، اشتباهات را تکرار می‌کنند و تصویر کلی پروژه را از دست می‌دهند. دانش در سیستم وجود دارد، اما به نفر بعدی — یا عامل بعدی — که به آن نیاز دارد، نمی‌رسد.
شکست پرامپت‌های خالی
ابزارهای مدرن خط فرمان (CLI) با پنهان کردن پیچیدگی‌ها در پشت یک ترمینال، پذیرش گسترده‌ای پیدا کرده‌اند. نویسنده اشاره می‌کند که Claude Code و Codex احتمالاً موفق‌ترین محصولات CLI از زمان عصر DOS هستند. شما می‌توانید به ابزار بگویید تقریباً هر چیزی بسازد، اما این تجربه «ماشین تک‌پدالی» ایجاد می‌کند؛ برای کارهای کوچک عالی است، اما وقتی پروژه به استدلال معماری عمیق نیاز دارد، شکست می‌خورد.
وقتی برنامه‌نویسی در جریان Vibe Coding از یک عامل می‌خواهد «یک دکمه را حذف کند»، دکمه به سادگی غیب می‌شود. اما عامل متوجه نمی‌شود که آن دکمه یک نیاز خاص — مثلاً اجازه دادن به کاربران برای آرشیو کردن گفتگوها — را برآورده می‌کرد. نتیجه یک شکست خاموش است که برنامه‌نویس خیلی دیر متوجه آن می‌شود. این همان نقطه محدودیت سادگی است؛ در حالی که یک ماشین تک‌پدالی برای یک مسافت کوتاه هیجان‌انگیز است، اما برای یک سفر طولانی ناکافی است.
معرفی درخت ویژگی (Feature Tree)
برای مقابله با این وضعیت، پلتفرم Hey Hey رویکردی ساختاریافته را معرفی کرده است. در اینجا کاربر به جای شروع از مخزن کد (Repository)، از یک «ویژگی» (Feature) شروع می‌کند. این سیستم، «مسیر سخت» — یعنی تیم‌های شلوغ با مستندات نامنظم — را به عنوان فرآیندی می‌بیند که می‌توان آن را از طریق هوش مصنوعی آسان کرد. اگر تغییری یا یک ویژگی جدید روی تیم دیگری اثر بگذارد، سیستم با بررسی اینکه آیا سیستم A با سیستم B ارتباط دارد یا خیر، آن را شناسایی می‌کند.
- درخت ویژگی: ساختاری سلسله‌مراتبی است که بر اساس علاقه مهندسان به انتزاع‌ها و درخت‌ها بنا شده است. شکل کلی محصول در راس درخت قرار دارد، در حالی که جزئیات ریز و دقیق در سطوح پایین‌تر جای می‌گیرند. این ساختار به توسعه‌دهندگان اجازه می‌دهد درباره روابط سلسله‌مراتبی استدلال کنند.
- عناصر یکپارچه: هر ویژگی، خانه‌ای برای طراحی‌های خاص، مدل‌های اولیه (Mockups)، نمودارها و وظایف پیاده‌سازی است. این امر تضمین می‌کند که نفر بعدی بتواند کار را در بستر آنچه قرار است به دست آید، پیدا کند.
- نقاط ورود زمینه‌ای: هر عنصر — از جمله مستندات طراحی، نیازمندی‌ها، تصمیمات فنی و حتی تایپ‌های سفارشی (Custom Types) — به عنوان نقطه ورود برای عامل عمل می‌کند تا تحقیق کند یا تغییرات را پیشنهاد دهد.
با اجبار عامل به فعالیت در این سیستم، ابزار تضمین می‌کند که AI دقیقاً می‌داند یک تکه کد کجا پیاده شده و چگونه به بقیه طراحی متصل است. عامل‌ها حتی می‌توانند پیشنهاد دهند که کارهای جدید باید در کجا قرار گیرند. عامل دیگر حدس نمی‌زند؛ بلکه قبل از پیشنهاد هر تغییر، به نیازمندی‌های تأیید شده مراجعه می‌کند. اگر کاربر درباره یک مدل بصری (Mockup) بپرسد، عامل پروژه را چک می‌کند، شکاف‌هایی که کاربر ذکر نکرده را شناسایی می‌کند و پیش‌نویس تغییر را برای تأیید می‌فرستد.
حاکمیت عامل‌ها و بازبینی
در گردش کار Hey Hey، عامل‌ها به عنوان بافت متصل بین انتزاع‌های ناقص (Leaky Abstractions) عمل می‌کنند. آن‌ها فقط کد نمی‌نویسند، بلکه مستندات مختلف پروژه را با هم صادق و همراستا نگه می‌دارند. به تنهایی، عناصر می‌توانند بیش از حد سخت‌گیرانه یا بیش از حد مبهم باشند، اما عامل‌ها لینک‌ها را دنبال می‌کنند تا ببینند یک تغییر در واقع چه بخش‌هایی را لمس می‌کند.
عامل‌ها متوجه می‌شوند کجا برنامه‌نویس چیزی را تکامل داده، با مستندات موجود تضاد ایجاد کرده، چیزی را اضافه کرده یا بخشی از مشخصات فنی را بی‌صدا حذف کرده است. آن‌ها پیشنهاد می‌دهند که چه چیزی کم است، مثلاً یک نیازمندی جدید، یک قرارداد (Contract) بین دو بخش، یا وظیفه خاصی که یک ویژگی را پیاده‌سازی می‌کند.
اگر برنامه‌نویسی یک تغییر کوچک در رابط کاربری پیشنهاد دهد، عامل ابتدا نیازمندی تأیید شده‌ای که ممکن است این تغییر آن را نقض کند، وظیفه‌ای که در حال ساخت آن است و هرگونه شکاف در دسترسی‌پذیری (Accessibility) که برنامه‌نویس در نظر نگرفته بود را شناسایی می‌کند. این اتفاق، نقش انسان را از «کدنویس» به «طراح سیستم» تغییر می‌دهد که روی قصد، سلیقه و تصویر کلی تمرکز می‌کند.
این فرآیند بر یک سیستم پیشنهادی (Proposal System) استوار است. هر به‌روزرسانی — چه تغییر در مدل بصری باشد و چه یک سند طراحی جدید — باید تأیید شود. عامل‌ها تاریخچه را حفظ می‌کنند و به انسان یادآوری می‌کنند که چرا تصمیمات خاصی ماه‌ها پیش گرفته شده است. این کار به طور موثری مشکل «فراموشی» را که در جلسات طولانی‌مدت با عامل‌ها رایج است، حل می‌کند. در واقع، عامل‌ها به ندرت فراموش می‌کنند؛ بلکه به کاربر یادآوری می‌کنند که او چه چیزی را فراموش کرده است.
هزینه زمینه (Context)
حفظ این سطح از آگاهی سیستماتیک، هزینه توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — بالایی دارد. توسعه‌دهنده هزینه‌ها را به سه دسته تقسیم می‌کند: پول، زمان و استرس. او معتقد است استرس مهم‌ترین معیار است. هدف از استفاده از عامل‌ها، آسان‌تر کردن زندگی است، بنابراین بهتر است توکن‌ها صرف جست‌وجو و تحلیل شوند تا صرف پیاده‌سازی محض.
با وجود نیاز به محاسبات بالا، سیستم با استفاده از پلن‌های API خود کاربر، بهینه شده است. برای مثال، نویسنده این گردش کار را با یک پلن ۱۰۰ دلاری Anthropic و یک پلن ۲۰ دلاری Codex مدیریت می‌کند و اشاره می‌کند که شروع با زمینه درست، زندگی عامل را آسان‌تر کرده و توکن‌های هدر رفته را کاهش می‌دهد.
موازنه انسانی
این سخت‌گیری، هزینه روان‌شناختی دارد. توسعه‌دهنده اعتراف می‌کند که از نظر سینتکس خام، نسبت به سال گذشته «کدنویس بدتری» شده است. اما او استدلال می‌کند که این یک موازنه لازم برای تمرکز بر تفکر سیستمی و طراحی است.
در نهایت، هدف این است که کاربر بتواند روی «چه چیزی» می‌خواهد بسازد فکر کند، بدون اینکه مجبور باشد روابط وابستگی (Depends on) را به صورت دستی تنظیم کند. پلتفرم با شفاف کردن پیامدهای هر تغییر، سعی می‌کند جلوی کلیک‌های بی‌فکر روی دکمه Accept را بگیرد که اغلب در توسعه‌های کمک‌گرفته از AI دیده می‌شود. چالش اصلی در ایجاد تعادل بین یک فرآیند سخت‌گیرانه و نیاز به سرعت است، تا تضمین شود که «مسیر آسان» همان «مسیر درست» است.
دسترسی و پیاده‌سازی
پلتفرم Hey Hey در حال حاضر در نسخه بتا در آدرس heyhey.dev در دسترس است. استفاده از آن رایگان است (تا جایی که ظرفیت اجازه دهد)، اما کاربران باید API Key خود را داشته باشند. معماری آن برای حریم خصوصی و کنترل محلی طراحی شده است:
- اجرای محلی: یک CLI کوچک، جلسات Claude Code یا Codex را روی ماشین کاربر اجرا می‌کند و مستقیماً با مخزن محلی (Local Repo) کار می‌کند.
- ذخیره‌سازی سروری: فقط پیام‌های گفتگو در سرور ذخیره می‌شوند تا تیم‌ها و سایر عامل‌ها ببینند چه بحث‌هایی صورت گرفته و چه تصمیماتی گرفته شده است.
- وارد کردن پروژه‌های قدیمی: برای کدهای موجود، Hey Hey مخزن را وارد کرده و عامل‌ها پیش‌نویس درخت ویژگی را می‌سازند. چون AI می‌داند چه چیزی ساخته شده اما نمی‌داند «چرا»، کاربر باید در ابتدا جزئیاتی را پر کند تا عامل‌ها دست به حدس زدن نزنند. این یک معامله است: کمی هزینه در ابتدا بپردازید تا عامل‌ها دیگر حدس نزنند.
گام بعدی شما
- اگر از ابزارهای AI برای کدنویسی استفاده می‌کنید، سعی کنید به جای پرامپت‌های کلی، ابتدا یک سند نیازمندی‌های ساده (Requirements Doc) بنویسید و آن را به مدل بدهید.
- پلتفرم Hey Hey را برای پروژه‌های کوچک خود تست کنید تا تفاوت بین کدنویسی مبتنی بر حس و کدنویسی ساختاریافته را تجربه کنید.
- در مستندات خود، روابط وابستگی بین ویژگی‌ها را به صورت صریح بنویسید تا احتمال توهم مدل در تغییرات بزرگ کاهش یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو