اگر امروز تمام منطق نرمافزار خود را بر اساس توصیفهای شفاهی به یک مدل میسپارید، احتمالاً سه ماه دیگر با کدی مواجه میشوید که هیچکس دلیل وجودش را نمیداند. Vibe Coding (کدنویسی بر اساس حس) — یا همان توصیف کلی یک ویژگی و سپردن پیادهسازی تکراری آن به هوش مصنوعی — بدون یک ساختار خارجی سختگیرانه، تنها یک فاجعهی در انتظار است. در حالی که هستهی اصلی Vibe Coding واقعی است و سرعت توسعه را بهطور چشمگیری افزایش میدهد، اما به محض اینکه بیش از یک تغییر در جریان باشد، به یک نقطه ضعف تبدیل میشود. وقتی پنج تغییر موازی داشته باشید، هیچ سوابقی از درخواستهای قبلی وجود نداشته باشد و هیچ Diff (تفاوت کد) بازبینی نشده باشد، توسعهدهندگان پس از گذشت چند ماه با این سوال مواجه میشوند که «چرا این کد به این شکل نوشته شده است؟»
به گزارش یک توسعهدهنده که سیستم معاملاتی خودکار را با Claude Code مدیریت میکند، منبع حقیقت (Source of Truth) باید از پنجرهی چت مدل به GitHub منتقل شود. در یک جلسهی استاندارد، دستورات با بستن ترمینال محو میشوند و اگر بیش از یک تغییر موازی در جریان باشد، توسعهدهنده در «هرجومرج سریع» غرق میشود، جایی که تغییرات موازی با هم برخورد میکنند و استدلالهای پشت کد در عرض چند ماه گم میشوند. همانطور که در تحلیل قبلی ما دربارهی رفع خطاهای پیکربندی Claude Code با APIهای خارجی اشاره کردیم، این رویکرد جدید مشکل «زمینه زودگذر» (Ephemeral Context) را حل میکند. نویسنده اشاره میکند که در حالی که فایلهای حافظه (که در بخش اول بررسی شد) وضعیت فعلی را نگه میدارند، برای نگه داشتن تاریخچه و سیر تکاملی پروژه، گیتهاب ضروری است.
بر اساس راهنمای فنی مفصلی که در ۱۳ جولای ۲۰۲۶ در وبسایت dev.to منتشر شد، راهکار این است که گیتهاب نه به عنوان یک مخزن ذخیرهسازی ساده، بلکه به عنوان فضای عملیاتی عامل (Agent) — یعنی برنامههایی که میتوانند بهطور مستقل ابزارها را اجرا کنند — تعریف شود. در این مدل، گیتهاب سه نقش حیاتی و متمایز بهطور همزمان ایفا میکند:
مکانیسم جریان کاری عاملمحور
- صف تسکها: ایشوهای گیتهاب به جای درخواستهای مبهم مثل «همان چیزی که بحث کردیم»، به عنوان لیست کارهای AI عمل میکنند. تسکها به صورت آیتمهای قابل ارجاع (مثلاً Issue #142) با عنوان، شرح کامل و معیارهای پذیرش صریح (Acceptance Criteria) ردیابی میشوند. در این حالت، کلود میتواند ایشوها را بخواند، روی آنها کار کند و پیشرفت خود را دوباره به این ایشوها لینک کند.
- واحد تغییر: هر تغییر مدل باید در قالب یک Pull Request (PR) — شبیه به یک پیشنویس رسمی که باید توسط مدیر تایید شود پیش از اینکه به متن اصلی اضافه شود — ارائه شود. این کار یک Diff قابل بازبینی و یک توجیه مکتوب ایجاد میکند. PR به عنوان یک چکپوینت ضروری عمل میکند که در آن یک انسان یا یک سیستم بازبینی خودکار باید پیش از ادغام کد، آن را بررسی کند؛ این همان «ترمز»ی است که کدنویسی با سرعت بالای AI را ایمن میکند.
- دفترچه ثبت تغییرات: ترکیب ایشوهای بسته شده و PRهای ادغام شده، یک سوابق تاریخی دائمی میسازد. شش ماه بعد، یک توسعهدهنده میتواند مسیر را از
git blame$\rightarrow$ PR $\rightarrow$ issue دنبال کند تا داستان کامل یک تغییر را بفهمد.
پیادهسازی از طریق CLI
برای اجرای این مدل، نویسنده استفاده از رابط خط فرمان gh را توصیه میکند. احراز هویت از طریق gh auth login انجام میگیرد که به جای نیاز کاربر به چسباندن دستی توکنها، از یک جریان OAuth مبتنی بر مرورگر استفاده میکند. این قابلیت به کلود اجازه میدهد دستوراتی مثل gh issue list (مشاهده لیست ایشوها)، gh issue view 142 (مشاهده جزئیات ایشوی ۱۴۲) و gh pr create (ایجاد PR) را مستقیماً اجرا کند. این دسترسیهای گستریده به ابزارها، یادآور تحولات اخیر در مدیریت پلاگینهاست؛ برای مثال پلتفرم Skill Hub مدیریت افزونههای Claude و Codex را به شکلی بهینه تغییر داده تا تعامل با ابزارهای AI سادهتر شود.
برای تضمین این نظم و سختگیرانه بودن فرآیند، نویسنده پیشنهاد میکند بخش ویژهای به فایل CLAUDE.md اضافه شود:
- GitHub: تمام کارها باید در قالب ایشوها ردیابی شوند.
- شماره ایشو باید حتماً در نام Branch و PR ذکر شود.
- هر تغییر باید به عنوان یک Pull Request ثبت شود؛ هیچگاه مستقیماً روی شاخه main کامیت نکنید.
- هرگز اسرار (Secrets) یا توکنها را کامیت نکنید؛ فقط از
gh auth loginیا متغیرهای محیطی (Environment Variables) استفاده کنید.
این روند یک حلقه ساختاریافته ایجاد میکند: ایده $\rightarrow$ ایشو (ثبت قصد و هدف) $\rightarrow$ شاخه (Branch) $\rightarrow$ پیادهسازی توسط Claude $\rightarrow$ PR (ارائه Diff قابل بازبینی) $\rightarrow$ بررسی (Review) $\rightarrow$ ادغام (Merge) $\rightarrow$ بستن ایشو.
مقیاسپذیری از طریق اتوماسیون
با افزایش حجم کاری، این جریان کاری به سیستمی پیچیدهتر تبدیل میشود که در آن ایشوها به عنوان «گیتهای امنیتی» و «سوئیچهای قطعکننده» (Deadman's switches) عمل میکنند.
- گیتهای آزمایشی: آزمایشهایی که نیاز به تصمیم «ادامه یا توقف» در یک تاریخ مشخص دارند، به صورت ایشوهای برچسبدار مدیریت میشوند. یک بررسی خودکار برای آن تاریخ برنامهریزی میشود تا وضعیت PASS (پذیرفته شده)، FAIL (رد شده) یا NEEDS-MORE-DATA (نیاز به داده بیشتر) را در قالب یک کامنت ارسال کند. این کار تضمین میکند که هیچ آزمایشی به دلیل فراموشی، برای همیشه در حال اجرا نماند.
- تحویل استقرار (Deploy Handoffs): از برچسب
needs-deployبرای مدیریت فاصله زمانی بین کد ادغام شده و کد فعال در محیط لایو استفاده میشود. این روند مشابه «آیین شروع جلسه» در بخش دوم است، جایی که سیستم در اولین لحظه شروع کار، ابتدا این برچسب را چک میکند تا مطمئن شود تحویل کد به محیط عملیاتی کامل شده است. - مدیریت مستقیم صف: با بهرهگیری از ابزارهای پروتکل زمینه مدل (MCP) — که در بخش چهارم بررسی شد و مانند یک مترجم استاندارد است و اجازه میدهد مدلهای مختلف به راحتی با نرمافزارهای خارجی ارتباط برقرار کنند — کلود مدیریت صف را مستقیماً بر عهده میگیرد. AI میتواند در میان جلسه، ایشوها را بخواند، روی آنها کامنت بگذارد و آنها را ببندد، و بدین ترتیب مدیریت تسکها را نه به عنوان یک کار اداری جداگانه، بلکه به عنوان بخشی از خودِ فرآیند توسعه میبیند.
نردههای ایمنی امنیتی
یک قانون غیرقابل مذاکره در این استک، ممنوعیت مطلق کامیت کردن اسرار، توکنها یا کلیدهای API است — چه در یک فایل، چه در پیکربندی و چه به صورت «موقت». از آنجایی که هوش مصنوعی سریعتر از توان بازبینی انسان کد میزند، ریسک «چسباندن کلید API در متن کد برای اینکه سریعتر کار کند» بسیار زیاد است. نشت یک توکن در یک کامیت عمومی، یک خطای بحرانی است که منجر به گزارشهای نقض امنیتی میشود.
برای جلوگیری از این مورد، نویسنده دو راهکار ارزان و ساده را توصیه میکند:
۱. نگه داشتن تمام اسرار در یک فایل .env که در .gitignore قرار دارد و توسط گیت نادیده گرفته میشود.
۲. افزودن یک بررسی پیشکامیت (Pre-commit check) برای اسکن توکنها تا هرگونه لغزشی پیش از ارسال کد به سرور (Push) شناسایی و متوقف شود.
رابطه ساختار و سرعت
این رویکرد ساختاری، رابطه بین سرعت و فرآیند را بهطور بنیادی تغییر میدهد. در حالی که توسعهدهندگان اغلب تصور میکنند فرآیندهای اداری باعث کند شدن کار میشود، در یک جریان کاری مبتنی بر AI، ساختار در واقع «پیششرطِ سرعت» است. وقتی هر تغییر از طریق یک ایشو قابل ردیابی و از طریق یک PR قابل بازگشت باشد، منطقی است که اجازه دهیم AI با حداکثر سرعت ممکن حرکت کند. بدون این تور ایمنی، توسعهدهندگان مجبورند کند حرکت کنند و همه چیز را دستی بررسی کنند که در نهایت منجر به بهرهوری کمتری میشود.
علاوه بر این، یک ایشوی خوب در گیتهاب — با توصیفی شفاف و معیارهای پذیرش صریح — پرامپتی بسیار برتر از یک پیام ساده در محیط چت است. این کار انسان را مجبور میکند قبل از اینکه کلود شروع به ساخت کند، دقیقاً تصمیم بگیرد که «کامل شدن» (Done) به چه معناست. صرف ۱۰ دقیقه زمان برای نوشتن یک ایشوی دقیق، معمولاً یک ساعت زمانِ ساخت و بازسازی ویژگیهایی که به اشتباه پیاده شدهاند را ذخیره میکند.
این مدل، AI را از یک دستیار موقت به بخشی دائمی از زیرساخت عملیاتی پروژه تبدیل میکند. با ترکیب حافظه (بخش ۱)، آیینهای شروع (بخش ۲)، دستورات سفارشی (بخش ۳)، ابزارهای MCP (بخش ۴)، جستجوی معنایی (بخش ۵) و گیتهاب به عنوان منبع حقیقت (بخش ۶)، سیستم بهرهوری خود را با کاهش «زبالههای متنی» که کلود باید بخواند و دوباره انجام دهد، به صورت ترکیبی افزایش میدهد.
برای بهینهسازی بیشتر، کاربران باید مصرف توکنها و سرعت جلسات خود را ردیابی کنند. قسمت پایانی این مجموعه، معیارهای دقیقی را ارائه خواهد داد که چگونه این استک یکپارچه، هزینههای توکن را کاهش داده و چرخههای کلی توسعه را سرعت میبخشد. همچنین تحقیقات عمیقتر در مورد RAG که در طول این مجموعه ذکر شد، به صورت متنباز از طریق RE-call در دسترس است.
گام بعدی شما
- استقرار یک فایل
CLAUDE.mdدر ریشه پروژه برای اجبار مدل به استفاده از PRها. - جایگزینی درخواستهای چت با ایجاد Issue در گیتهاب برای تعریف دقیق خروجی مورد انتظار.
- فعالسازی Secret Scanning در تنظیمات گیتهاب برای جلوگیری از نشت توکنها در سرعت بالای کدنویسی.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو