تصور کنید برنامهنویسی هستید که از Claude Code برای توسعه یک اپلیکیشن React Native استفاده میکند و متوجه میشود کد تولید شده، با وجود اینکه بدون خطا اجرا میشود، اما با معماری پروژه سازگار نیست. یافتههای او نشان میدهد که شکاف میان کد تولیدی هوش مصنوعی و کد قابل ادغام در محیط تولید (Production)، ناشی از نقص در هوش مدل نیست، بلکه یک شکست در درک زمینه (Context) است. طبق راهنمای دقیقی که در ۹ سپتامبر ۲۰۲۶ در وبسایت dev.to منتشر شد، عاملهای هوش مصنوعی بدون هدایت، معمولاً انتخابهایی «بهطور آماری متوسط» میکنند که با معماریهای خاص هر اپلیکیشن در تضاد است.
این شکستها زمانی ظاهر میشوند که عامل روشی جدید برای انجام کاری ابداع میکند که پیشتر در پروژه تعریف شده است؛ مثلاً ساخت یک Wrapper جدید برای Fetch در حالی که یک API Client موجود است، یا استفاده از وابستگیهایی (Dependencies) که پروژه ندارد و در برخی موارد، نصب آنها بدون اجازه توسعهدهنده. این توهمات (Hallucination) — یعنی وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد — شبیه دوستی است که خاطرهای را اشتباه تعریف میکند. این پدیده با یافتههای گستردهتری همسو است؛ برای مثال، پژوهش Armature با تحلیل هزاران جلسه نشان داد که عاملهای کدنویس گاهی بر اساس سوگیریهای زبانی یا ابزاری، انتخابهای غیربهینه انجام میدهند.
این چالش درست زمانی رخ میدهد که توسعهدهندگان از رابطهای سادهی چت به سمت عاملهای (Agent) خودمختار حرکت میکنند. همانطور که در تحلیل قبلی ما دربارهی اتوماسیون اجرای ابزارها در حلقه Claude Code اشاره کردیم، تمرکز اکنون از «توانایی نوشتن کد» به «توانایی پیروی از سیستم طراحی و الگوهای مدیریت وضعیت» بدون نیاز به اصلاحات مداوم انسانی تغییر کرده است. هدف نهایی، تبدیل کدی است که صرفاً «کامپایل میشود» به کدی که یک توسعهدهنده واقعاً آن را Merge میکند.
مکانیزم CLAUDE.md
مرکز این رویکرد، فایلی به نام CLAUDE.md است که به عنوان دستورالعملهای ثابت در ابتدای هر جلسه خوانده میشود. بهجای استفاده از دفترچههای راهنمای طولانی یا «رمانهای ۳۰۰ خطی» که مدل مجبور است در آنها جستجو کند، مؤثرترین فایلها کوتاه و قاطع هستند و بر دو محور تمرکز دارند: پشته تکنولوژی (Tech Stack) و مرزها.
یک فایل CLAUDE.md کارآمد، محیط را بهطور دقیق تعریف میکند؛ مثلاً مشخص میکند که پروژه از Expo با حالت Managed Workflow و TypeScript Strict Mode استفاده میکند. این فایل کتابخانههای خاصی را اجباری میکند، مانند استفاده از zustand برای مدیریت وضعیت در مسیر src/stores/ و محدود کردن تمام درخواستهای داده به یک کلاینت واحد در src/api/client.ts تا از فراخوانی مستقیم fetch توسط عامل جلوگیری شود. همچنین برای حفظ یکپارچگی رابط کاربری، استفاده از کامپوننتهای موجود در src/components/ui/ را الزامی کرده و استایلهای Inline را به نفع توکنهای تم در src/theme/ ممنوع میکند.
جزئیات پیادهسازی برای CLAUDE.md
برای بهرهبرداری حداکثری از این فایل، توسعهدهندگان باید این دستورالعملهای خاص را دنبال کنند:
- قانون «دو اصلاح»: یک خط تنها زمانی به
CLAUDE.mdاضافه میشود که توسعهدهنده مجبور شده باشد عامل را برای آن اشتباه خاص، حداقل دو بار اصلاح کند. در غیر این صورت، آن مورد نویز محسوب میشود و باعث شلوغ شدن زمینه مدل میگردد. - معیارهای خروج (Exit Criteria): فایل باید دقیقاً تعریف کند که یک تسک چه زمانی «تمام شده» است. برای مثال، باید اجباری شود که عامل دستورات
npx tsc --noEmit && npm run lint && npm testرا اجرا کرده و تمام خطاها را پیش از ارائه Diff نهایی برطرف کند. - پیشفرضهای پشته: با جایگزینی پیشفرضهای عمومی مدل با پشته واقعی پروژه (مثلاً تعیین
expo-routerبرای ناوبری مبتنی بر فایل)، توسعهدهنده دستههای کاملی از خروجیهای «صحیح اما اشتباه» را از بین میبرد.
حصارکشی لایه Native
یکی از پرخطرترین حالتهای شکست در React Native، تغییرات عامل در فایلهای Native سیستمعامل iOS یا Android است. این تغییرات «کمککننده» — مانند تغییر در Podfile، تغییرات در Gradle یا اصلاح دسترسیهای Info.plist — اغلب در بازبینیهای متمرکز بر JS دیده نمیشوند و روزها بعد به صورت خطای Build ظاهر میشوند. برای جلوگیری از این اتفاق، یک سیستم حفاظ (Guardrails) دو لایه به کار گرفته میشود:
- لایه اول: قوانین دسترسی: با استفاده از
.claude/settings.jsonدر ریشه پروژه، توسعهدهندگان میتوانند دسترسی عامل به دایرکتوریهایios/**یاandroid/**را بهطور صریح منع کنند. این شامل مسدود کردن دستورات خطرناکی مثلpod installیاnpx expo prebuildاست. این کار تضمین میکند که محدودیتها همراه با مخزن کد (Repository) منتقل شوند. در این راستا، باید توجه داشت که نبود حفاظهای سختگیرانه در تنظیمات CLAUDE.md میتواند ریسکهای امنیتی یا تخریبهای ناخواسته در دیتابیس و زیرساختها را افزایش دهد. - لایه دوم: دستورالعملهای برنامهریزی: درج یک خط در
CLAUDE.mdکه به عامل میگوید هرگز بدون اجازه فایلهایios/،android/یاapp.jsonرا تغییر ندهد. این مورد تکراری نیست؛ زیرا قوانین دسترسی «اجرا» میکنند، اما این دستور «برنامهریزی» عامل را تغییر میدهد. بدون این دستور، عامل ممکن است تغییری در لایه Native برنامهریزی کند، به دیوار دسترسی برخورد کند و سپس دچار سردرگمی شود. با وجود این دستور، عامل از همان ابتدا مسیرهای جایگزین را پیدا میکند.
برای کسانی که از Expo Managed Workflow استفاده میکنند، این حصار سادهتر است: عامل را در محیط JS نگه دارید، پیکربندی app.json را تحت کنترل انسان قرار دهید و اجازه دهید EAS لایه Native را مدیریت کند.
شکلدهی تسک و اعتبارسنجی
اندازه تسک، عامل اصلی کیفیت خروجی است. قاعده کلی این است: اگر یک Diff را نتوان در یک جمله توصیف کرد، تسک بیش از حد بزرگ است. بهجای درخواست یک «ویژگی پروفایل» کلی، کار به توالی مراحل کوچک و قابل تایید تقسیم میشود:
۱. چیدمان استاتیک: افزودن ProfileScreen در مسیر app/profile.tsx با استفاده از کامپوننتهای ui/ و دادههای سختافزاری (Hardcoded)، بدون هیچ تغییری در ناوبری.
۲. لایه منطق: افزودن هوک useProfile در src/hooks/ که دادهها را از طریق src/api/client.ts بارگذاری کند و وضعیتهای Loading و Error را مدیریت نماید.
۳. اتصال (Wiring): متصل کردن useProfile به ProfileScreen و مدیریت وضعیتها با استفاده از کامپوننتهای موجود مانند <Spinner /> و <ErrorView />.
۴. یکپارچهسازی: افزودن تب پروفایل به لایه ناوبری (Router Layout).
این روش تضمین میکند هر مرحله در کمتر از یک دقیقه قابل تایید باشد. علاوه بر این، یک مزیت ترکیبی ایجاد میکند: عامل منطق مرحله دوم را بر اساس کد واقعی تولید شده در مرحله اول مینویسد، نه بر اساس نسخهای خیالی از آن.
حلقه تست
برای جلوگیری از تحویل کدهای تستنشده، گردش کار یک حلقه بررسی ماشینی را پیش از ارائه هر Diff به انسان اجباری میکند. عامل باید موارد زیر را اجرا کند:
npx tsc --noEmit: این دستور بیشترین نقش را دارد و خطاهای ساختاری (Shape Errors) مانند Propهای اشتباه، پارامترهای نادرست ناوبری یا Selectorهای Store که بخش اشتباهی از داده را برمیگردانند، شناسایی میکند.npm run lint: برای جلوگیری از انحراف از استانداردهای کدنویسی، حذف Importهای بلااستفاده و اجرای قوانین مربوط به Hookها.npm test: حتی با پوشش تست کم، برای شناسایی رگرسیونها استفاده میشود.
از آنجا که عامل نمیتواند صفحه را «ببیند»، بازبینی انسانی محدود میشود. صحت منطق توسط ماشین چک شده و انسان فقط آنچه ماشین نمیتواند را بررسی میکند: اجرای اپلیکیشن روی یک اندازه دستگاه و تست جریان کاربر برای اطمینان از اینکه برنامه «حس درست» را منتقل میکند.
مدل ترکیبی: قالب و عامل
مرز مشخصی میان نقاط قوت و ضعف عاملهای هوش مصنوعی وجود دارد. عاملها در کارهای خاص اپلیکیشن، مانند تغییر صفحات موجود، متصل کردن جریانهای جدید به الگوهای تثبیت شده، بازنویسی (Refactor)، یکپارچهسازی SDKهای خاص یا نوشتن تستها بر اساس کد واقعی عالی هستند. اینها حوزههایی هستند که قالبهای آماده (Templates) نمیتوانند کمکی کنند.
در مقابل، عاملها در زیرساختهای استاندارد اپلیکیشن شکست میخورند. تولید جریانهای احراز هویت (Auth Flows)، صفحات Onboarding، پوسته ناوبری، اتصال به Supabase یا صفحات تنظیمات از صفر میتواند یک ساعت زمان ببرد و دو ساعت دیگر نیاز به بازبینی کدهای تکراری (Boilerplate) داشته باشد. برای این بخشها، استفاده از قالبهای آماده — مانند AppLighter — برای ایجاد اسکلت React Native + Expo + Supabase پیشنهاد میشود.
این رویکرد ترکیبی باعث میشود عملکرد عامل بهبود یابد، زیرا هوش مصنوعی میتواند از کدهای متداول و باکیفیتی که توسط قالب ارائه شده، استنباط کند. الگوی برنده این است: استفاده از قالب برای اسکلت (Skeleton) و استفاده از عامل برای هر چیزی که اپلیکیشن را منحصربهفرد میکند.
این تغییر در رویکرد، نقش بازبین انسانی را بهطور قابل توجهی محدود میکند. برای توسعهدهندگان، این بدان معناست که هدف دیگر نوشتن «پرامپتهای هوشمندانه» نیست، بلکه حذف درجات آزادی (Degrees of Freedom) است؛ یعنی نقاطی که در آن انتخابهای متوسطِ عامل با کدبیس پروژه تضاد دارد. با دویدن در یک حصار تعریفشده، عامل از یک ریسک تبدیل به ابزاری با توان عملیاتی بالا میشود که دیگر نیاز به بازنویسیهای مداوم ندارد.
گام بعدی شما
- ایجاد یک فایل
CLAUDE.mdساده و متمرکز بر «پشته تکنولوژی» و «مرزهای دسترسی» در ریشه پروژه خود. - اعمال محدودیتهای دسترسی در
.claude/settings.jsonبرای جلوگیری از تغییرات ناخواسته در لایههای Native. - تقسیم تسکهای بزرگ به زیر-تسکهایی که هر کدام در یک جمله قابل توصیف باشند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو