021-88755818
info@clounetix.com
عضویت
وروددستیارهای کدنویسی با هوش مصنوعی از شرکتهایی مثل OpenAI، Anthropic و Google حالا میتوانند ساعتها روی یک پروژه نرمافزاری کار کنند؛ برنامهی کامل بسازند، تستها را اجرا کنند و باگها را برطرف کنند، البته در حالی که یک انسان نظارت میکند و مسیر را کنترل میکند. اما این ابزارها «جادویی» نیستند و گاهی بهجای اینکه کار را سادهتر کنند، پروژه را پیچیدهتر میکنند. اگر بفهمیم این ابزارها پشت صحنه چطور کار میکنند، بهتر میتوانیم تصمیم بگیریم چه زمانی از آنها استفاده کنیم (یا اصلاً استفاده نکنیم) و چطور از اشتباهات رایج دور بمانیم.
بیایید از پایه شروع کنیم. قلب هر دستیار کدنویسی با هوش مصنوعی، یک فناوری به اسم «مدل زبانی بزرگ» یا همان LLM است. LLM در اصل یک نوع شبکه عصبی است که با حجم خیلی بزرگی از دادههای متنی آموزش دیده؛ و داخل این دادهها مقدار زیادی کد برنامهنویسی هم وجود دارد. کار اصلی این مدل، پیدا کردن الگوهاست. شما یک متن (پرامپت) میدهید، بعد مدل بر اساس الگوهای آماریای که در زمان آموزش یاد گرفته، خروجیای میسازد که از نظر خودش «ادامهی منطقی» همان الگو است.
در همین روند، مدل گاهی میتواند بین حوزهها و مفهومهای مختلف ارتباط برقرار کند و از ترکیب آنها نتیجهگیریهایی انجام بدهد. اگر این کار درست انجام شود، نتیجه میتواند یک استدلال یا حدس منطقیِ مفید باشد. اما اگر بد انجام شود، مدل ممکن است چیزهایی تولید کند که کاملاً غلط هستند ولی خیلی مطمئن و قانعکننده به نظر میرسند.
بعد از این مرحله، «مدل خام» را باز هم بهتر میکنند. این بهبود معمولاً با روشهایی مثل «فاینتیون» کردن روی نمونههای انتخابشده و باکیفیت، و همینطور «یادگیری تقویتی با بازخورد انسان» (RLHF) انجام میشود. هدف این روشها این است که مدل بهتر دستورالعملها را دنبال کند، بتواند از ابزارها استفاده کند، و خروجیهای مفیدتر و قابلاتکاتری تولید کند.
در چند سال گذشته، پژوهشگران هوش مصنوعی مدام نقاط ضعف مدلهای زبانی بزرگ (LLM) را زیر ذرهبین بردهاند و راههایی پیدا کردهاند که اثر این ضعفها را کمتر کنند یا دور بزنند. یکی از نوآوریهای نسبتاً جدید، «مدل استدلال شبیهسازیشده» است؛ مدلی که یک متنِ شبیهِ استدلال تولید میکند و بهعنوان «زمینهی اضافی» به ورودی اضافه میشود (یعنی پرامپت را بلندتر میکند). همین زمینهی بیشتر، میتواند کمک کند LLM دقیقتر هدف بگیرد و به جواب درستتری نزدیک شود. نوآوری دیگر، برنامهای به نام «Agent» یا همان «عامل/دستیار» بود که چند LLM را به هم وصل میکند تا بتوانند همزمان چند کار را جلو ببرند و خروجیها را هم ارزیابی کنند.
ساختار دستیارهای کدنویسی با هوش مصنوعی
از این زاویه، هر دستیار کدنویسی با هوش مصنوعی در اصل یک «لایهی نرمافزاری» است که با چند LLM کار میکند. معمولاً یک LLM نقش «ناظر» دارد. این مدل، درخواستها (پرامپتها) را از کاربر انسانی میخواند و میفهمد، بعد همان کارها را بین چند LLM دیگر تقسیم میکند که به صورت موازی کار میکنند. این مدلهای موازی میتوانند از ابزارهای نرمافزاری استفاده کنند تا دستورها را انجام بدهند. مدلِ ناظر همچنین میتواند کارهای زیرمجموعه را متوقف کند و نتیجهی کارهای ریزتر را بررسی کند تا ببیند پروژه در چه وضعیتی است و درست پیش میرود یا نه. در مستندات فنی Anthropic این الگو را اینطور خلاصه کردهاند: «زمینه را جمع کن، اقدام کن، کار را بررسی کن، تکرار کن.»
اگر این دستیار روی کامپیوتر خودتان و از طریق خط فرمان (CLI) اجرا شود، شما معمولاً به آن «اجازهی مشروط» میدهید که کارهایی مثل این انجام دهد: روی سیستم شما فایل بسازد یا تغییر دهد (کد یا هر فایل لازم)، چند دستور ساده برای بررسی و گشتوگذار اجرا کند (مثلاً دستور «ls» برای دیدن لیست فایلهای یک پوشه)، از وبسایتها اطلاعات بگیرد (اغلب با «curl»)، نرمافزار دانلود کند، یا فایلها را روی سرورهای راه دور آپلود کند. این روش از نظر تواناییها خیلی دستش باز است، اما همین موضوع خطرهای بالقوه هم دارد؛ پس باید با احتیاط و حسابشده از آن استفاده کرد.
اما در سمت دیگر، وقتی کاربر یک وظیفه را داخل نسخههای وب این دستیارها شروع میکند—مثل نسخههای وبِ Codex و Claude Code—سیستم یک «محیط ایزوله» (sandbox) داخل یک کانتینر ابری میسازد. این کانتینر معمولاً از قبل با مخزن کد (repository) کاربر آماده شده است. داخل همین محیط، Codex میتواند فایلها را بخواند و ویرایش کند، دستورها را اجرا کند (از جمله ابزارهای تست و لینترها)، و کد را در یک فضای جدا و کنترلشده اجرا کند. Claude Code از شرکت Anthropic هم از قابلیتهای سطح سیستمعامل استفاده میکند تا برای فایلسیستم و شبکه مرزبندی ایجاد کند؛ یعنی دستیار داخل آن مرزها آزادی عمل بیشتری دارد، ولی بیرون از آن مرزها محدود میماند.
بیشتر بخوانید: مقایسهٔ سامانههای برق پشتیبان در مراکز داده
مشکل «کانتکست» (Context)
هر مدل زبانی بزرگ (LLM) یک جور «حافظهی کوتاهمدت» دارد؛ یعنی فقط تا یک حد مشخص میتواند اطلاعات را همزمان در ذهنش نگه دارد و پردازش کند. به این محدوده میگویند «کانتکست» یا همان «بافت/زمینهی گفتگو». وقتی کانتکست پر شود، مدل کمکم بخشی از مسیر کار را از دست میدهد و انگار “یادش میرود” دقیقاً مشغول چه کاری بوده.
نکته اینجاست که هر بار شما به مدلِ ناظر (supervising model) پیام جدید میدهید، در واقع دارید به یک «پرامپتِ خیلی بزرگ» چیزی اضافه میکنید. این پرامپت بزرگ شامل کل تاریخچهی گفتگو تا همین لحظه است. علاوه بر آن، تمام کدی که تا حالا تولید شده هم داخلش هست، و حتی آن بخشهای اضافهای که مدل برای بهتر فکر کردن تولید میکند (توکنهای مربوط به استدلال).
بعد مدل باید همین پرامپتِ حجیم را دوباره بررسی کند و بر اساسش خروجی بدهد. این کار از نظر محاسباتی خیلی سنگین و پرهزینه است. چون مدل، متن را به بخشهای ریزتری به اسم «توکن» میشکند (تکههای کوچک داده/متن) و در پردازش، ارتباط توکنها را با هم میسنجد. هرچه پرامپت بزرگتر شود، حجم این بررسیها هم به شکل شدیدی بالا میرود.
تیم فنی Anthropic از کانتکست به عنوان یک «منبع محدود» یاد میکند که هرچه بیشتر بزرگ شود، فایدهاش کمتر میشود. تحقیقات هم یک پدیده را نشان دادهاند که به آن «پوسیدگی کانتکست» یا context rot میگویند: یعنی هرچه تعداد توکنها در پنجرهی کانتکست بیشتر میشود، توان مدل برای به یاد آوردن درستِ اطلاعات پایینتر میآید. هر توکن تازه، بخشی از چیزی را مصرف میکند که در مستندات به آن «بودجهی توجه» (attention budget) گفته میشود.
نتیجهی طبیعیِ این محدودیت این است که مدل نمیتواند یک کدبیس خیلی بزرگ را یکجا و کامل در یک مرحله پردازش کند. اگر شما کلی فایل بزرگ و سنگین به مدل بدهید، هر بار که پیام جدید میفرستید مدل مجبور میشود دوباره همان فایلها را مرور کند. همین باعث میشود خیلی سریع سقف توکنها یا سقف مصرف (usage limit) پر شود و هزینه و زمان هم بالا برود.
ترفندهای رایج برای دور زدن محدودیتها
برای اینکه این محدودیتها کمتر اذیت کند، سازندگان دستیارهای کدنویسی با هوش مصنوعی از چند ترفند استفاده میکنند. یکی از کارهای مهم این است که مدلها را طوری آموزش میدهند (با فاینتیون) که بخشی از کار را به ابزارهای دیگر بسپارند. یعنی بهجای اینکه کل یک فایل بزرگ یا یک تصویر را مستقیم وارد LLM کنند، مدل خودش یک ابزار کمکی مینویسد یا اجرا میکند. مثلاً یک اسکریپت پایتون میسازد تا داده را از داخل فایل یا تصویر استخراج کند، بعد فقط نتیجهی خلاصه و لازم را به مدل میدهد. این کار هم توکن کمتری مصرف میکند و هم احتمال خطا را پایین میآورد.
در مستندات Anthropic هم اشاره شده که Claude Code برای تحلیلهای سنگین روی دیتابیسهای بزرگ همین روش را به کار میگیرد: کوئریهای دقیق و هدفمند مینویسد و از دستورهای Bash مثل head و tail کمک میگیرد تا حجم زیادی از داده را بررسی کند، بدون اینکه کل داده را یکجا داخل کانتکست بیاورد.
به یک معنا، این دستیارها برنامههایی هستند که هدایت میشوند، اما تا حدی هم مستقل عمل میکنند و از ابزارها استفاده میکنند. این یک جهش بزرگ نسبت به ایدههایی است که از اوایل ۲۰۲۳ جدیتر مطرح شدند.
یکی دیگر از پیشرفتهای مهم در دنیای agentها، «مدیریت پویا و هوشمندِ کانتکست» است. شرکتها جزئیات همهی روشهایشان را کامل عمومی نمیکنند، اما مهمترین تکنیکی که میدانیم استفاده میشود این است: فشردهسازی کانتکست (context compression).
بیشتر بخوانید: روشهای خنکسازی مراکز داده
وقتی یک مدلِ کدنویسی به سقف کانتکست نزدیک میشود، سیستم میآید تاریخچهی گفتگو و کارها را فشرده میکند؛ یعنی از آن یک جمعبندی میسازد. طبیعتاً در این جمعبندی، بخشی از جزئیات از بین میرود، اما در عوض اطلاعات کلیدی میماند و طول تاریخچه کمتر میشود. در مستندات Anthropic به این کار «Compaction» میگویند و توضیح میدهند که هدفش این است که نکات مهمی مثل تصمیمهای معماری و باگهای حلنشده حفظ شود، ولی خروجیهای تکراری ابزارها و چیزهای اضافی حذف شوند.
این یعنی هر بار که فشردهسازی انجام میشود، دستیار کدنویسی با هوش مصنوعی عملاً بخش قابلتوجهی از مسیر را “یادش میرود”. اما تفاوتش با سیستمهای قدیمیتر این است که کاملاً گیج و بیخبر نمیماند. چون میتواند سریع خودش را جمعوجور کند: کدهای موجود را دوباره میخواند، یادداشتهایی را که داخل فایلها گذاشته شده بررسی میکند، لاگ تغییرات را میبیند، و از همین راه دوباره جهت را پیدا میکند و ادامه میدهد.
مستندات Anthropic پیشنهاد میکند از فایلهای CLAUDE.md استفاده کنید تا چیزهای مهم و تکرارشونده را جایی ثبت کنید؛ مثل دستورهای رایج Bash، فایلهای اصلی پروژه، توابع کمکی، قواعد سبک کدنویسی، و دستورالعملهای تست. فایل AGENTS.md هم که حالا بین چند شرکت به یک استاندارد مشترک تبدیل شده، راه خوب دیگری است برای اینکه رفتار دستیار را «بین دفعات تازهسازی کانتکست» هدایت کنید. این فایلها در عمل مثل یادداشتهای بیرونی هستند؛ کمک میکنند دستیار در کارهای طولانی و پیچیده مسیر را گم نکند و نکات کلیدی را نگه دارد—چیزهایی که وگرنه ممکن بود با محدودیت کانتکست از دست بروند.
برای کارهایی که زمانبر هستند و نیاز به ادامهدادنِ طولانی دارند، هر دو شرکت معمولاً از معماری چند-دستیار استفاده میکنند. طبق مستندات پژوهشی Anthropic، سیستم آنها از الگویی به اسم «Orchestrator–Worker» استفاده میکند. در این الگو، یک دستیار اصلی نقش هماهنگکننده را دارد و کارها را بین چند دستیار تخصصیتر تقسیم میکند تا همزمان پیش بروند. وقتی کاربر یک درخواست میدهد، دستیار اصلی اول درخواست را تحلیل میکند، یک استراتژی میچیند، و بعد چند دستیار فرعی را راه میاندازد تا هرکدام یک بخش را بررسی کنند. دستیارهای فرعی مثل «فیلترهای هوشمند» عمل میکنند: فقط اطلاعات مرتبط و بهدردبخور را برمیگردانند، نه کل جزئیات و کانتکست داخلیشان را.
البته این روش چند-دستیار، توکن را با سرعت زیادی مصرف میکند. خودِ مستندات Anthropic میگوید دستیارها معمولاً حدود ۴ برابر یک چت معمولی توکن مصرف میکنند، و سیستمهای چند-دستیار حدود ۱۵ برابر چت. بنابراین اگر بخواهیم از نظر هزینه و صرفه اقتصادی توجیه داشته باشد، باید سراغ کارهایی برویم که «ارزش خروجی» آنقدر بالا باشد که این هزینهی بیشتر را جبران کند.
بیشتر بخوانید: ۵ تکنیک طلایی بهینهسازی برق مراکز داده
بهترین روشها برای انسانها
استفاده از این دستیارها در بعضی جمعهای برنامهنویسی بحثبرانگیز است. با این حال اگر تصمیم گرفتید با کمک آنها یک پروژه را جلو ببرید، بلد بودن اصول درست توسعه نرمافزار، جلوی خیلی از دردسرهای بعدی را میگیرد. مثلاً خوب است با کنترل نسخه (Version Control) آشنا باشید، بکاپهای مرحلهبهمرحله و کوچک بگیرید، هر بار فقط یک قابلیت را اضافه کنید، و قبل از رفتن سراغ مرحلهی بعد، همان قابلیت را کامل تست کنید.
چیزی که بعضیها به آن میگویند «vibe coding» یعنی تولید کد با هوش مصنوعی بدون اینکه واقعاً بفهمید کد چه کار میکند. این کار برای محیط واقعی و عملیاتی (production) واقعاً خطرناک است. اینکه کدی را که خودتان ننوشتهاید وارد سیستم عملیاتی کنید ریسک دارد: ممکن است حفره امنیتی ایجاد کند، باگهای پنهان وارد پروژه کند، یا بدهی فنی بسازد—بدهیای که با گذشت زمان بزرگتر میشود و جمعکردنش سختتر.
پژوهشگر مستقل حوزه هوش مصنوعی، Simon Willison، اخیراً تاکید کرده که حتی اگر از دستیارهای کدنویسی با هوش مصنوعی استفاده میکنید، باز هم مسئولیت اصلی با خودِ توسعهدهنده است: باید ثابت کنید کد درست کار میکند. او گفته تقریباً هر کسی میتواند با یک پرامپت از یک مدل زبانی بخواهد یک تغییر بزرگ، مثلاً یک پچ هزار خطی، تولید کند و برای بازبینی کد بفرستد. از نگاه او، این بخش دیگر «ارزش اصلی» نیست. ارزش واقعی این است که کدی ارائه کنید که واقعاً کارکردش ثابت شده و قابل اتکاست.
بیشتر بخوانید: بزرگترین مرکز دادهٔ هوش مصنوعی با ۴۵۰هزار GPU
در واقع، برنامهریزی انسانی نقش کلیدی دارد. مستندات بهترینروشهای Claude Code یک روند مشخص را برای مسائل پیچیده پیشنهاد میکند: اول از دستیار بخواهید فایلهای مرتبط را بخواند و خیلی روشن بگویید که فعلاً هیچ کدی ننویسد. بعد از او بخواهید یک برنامهی مرحلهبهمرحله ارائه کند. مستندات هشدار میدهد اگر این مرحلهی تحقیق و برنامهریزی انجام نشود، Claude معمولاً مستقیم میپرد وسط کدنویسی.
وقتی برنامهریزی نباشد، مدلهای زبانی گاهی برای رسیدن به یک هدف کوتاهمدت، سریعترین راه را انتخاب میکنند؛ راهی که ممکن است اگر پروژه بزرگتر شد، بعداً بشکند و به دردسر بیفتد. برای همین اگر یک تصویر کلی از «معماری خوب» داشته باشید—بهخصوص برای برنامههای ماژولار که قرار است در طول زمان توسعه پیدا کنند—میتوانید بهتر دستیار را هدایت کنید تا چیزی بسازد که ماندگارتر و قابل توسعهتر باشد.
همانطور که گفتیم، این دستیارها بینقص نیستند و بعضیها ترجیح میدهند اصلاً سراغشان نروند. یک مطالعهی کنترلشده و تصادفی که توسط سازمان پژوهشی غیرانتفاعی METR در ژوئیه ۲۰۲۵ منتشر شده، نشان داده توسعهدهندههای باتجربهی متنباز وقتی از ابزارهای هوش مصنوعی استفاده کردند، در عمل ۱۹٪ زمان بیشتری برای تمام کردن کارها صرف کردند—با اینکه خودشان فکر میکردند دارند سریعتر کار میکنند. البته نویسندگان مطالعه چند نکتهی مهم هم گفتهاند: شرکتکنندهها روی کدبیسهای خودشان بسیار مسلط بودند (به طور متوسط حدود ۵ سال کار و حدود ۱۵۰۰ کامیت)، مخزنها بزرگ و بالغ بودند، و مدلهایی که استفاده شد (بیشتر Claude 3.5 و 3.7 Sonnet از طریق Cursor) بعداً با نسخههای جدیدتر و قویتر جایگزین شدند.
اینکه مدلهای جدیدتر نتیجهی متفاوتی بدهند یا نه، هنوز کاملاً روشن نیست؛ اما این مطالعه یادآوری میکند که ابزارهای کدنویسیِ هوش مصنوعی همیشه برای همه «افزایش سرعت قطعی» نمیآورند—خصوصاً برای کسانی که کدبیسشان را خیلی خوب میشناسند.
با توجه به این ریسکها، به نظر میرسد بهترین استفادهی فعلی از دستیارهای کدنویسی با هوش مصنوعی این باشد که برای دموهای اثبات مفهوم (Proof of Concept) و ابزارهای داخلی به کار بروند. چون این مدلها در عمل «اختیار واقعی» ندارند (هرچند اسمشان را agent گذاشتهاند)، انسان هم نیستند که بشود بابت خطاها ازشان پاسخگویی خواست. پس نظارت و کنترل انسانی همچنان مهمترین بخش ماجراست.