‏مهندسی context: مرزِ مهندس و vibecoder

مقاله با نقل‌قولی از توبی لوتکه، مدیرعامل Shopify، شروع می‌شه: context engineering یعنی «هنرِ فراهم کردن همهٔ context لازم تا مسئله واقعاً برای LLM قابل حل باشه». نویسنده می‌گه کسی که بدون هیچ context پروژه یه prompt می‌پرونه سمت agent، مدل بدتری نداره؛ همون مدل داره با دست خالی تلاش می‌کنه. نتیجه‌ش می‌شه اسم‌گذاری ناهمگون، هِلپری که سه فایل اون‌طرف‌تر از قبل وجود داشته، و یه فرضِ معماری که دو refactor پیش غلط شده بود.

به گفتهٔ نویسنده، Anthropic و LangChain و تیم Manus هر سه به یه نتیجهٔ مشترک رسیدن: بیشتر شکست‌های agent تو محیط واقعی از context میاد، نه از مدل. خودش بر پایهٔ کار Drew Breunig چهار حالت خرابی رو این‌طور اسم می‌ذاره:

• Burst: همه‌چی از اول ریخته می‌شه تو context، پس اون یه فاکت مهم زیر چهل تا بی‌ربط گم می‌شه و agent همه رو تقریباً هم‌وزن می‌بینه.
• Poisoning: یه جزئیات غلط یا توهمی اول سشن، مثل متدی که وجود نداره، تا آخر سشن فاکت حساب می‌شه.
• Noise: همه‌چی مرتبطه، فقط زیاده؛ نسبت سیگنال به متن می‌ریزه و agent نمی‌فهمه الان کدومش مهمه.
• Conflict: system prompt یه چیز می‌گه و rules file پروژه چیز دیگه، و agent هر بار بی‌صدا حدس می‌زنه کدوم برنده‌ست.

برای نشون دادن حالت درست، نویسنده CLAUDE.md پکیج لاراولی خودش Truss رو می‌ذاره وسط: ۵۲ خط، شاملِ استک، دستورها و یه فهرست کوتاه از قاعده‌هایی که هیچ‌وقت نباید بشکنن، مثل «هیچ داده‌ای بیرون نمی‌ره، فقط ساختار». بقیه‌ش یه پرش اون‌طرف‌تر تو docs/ می‌مونه و رزیدنتِ context نیست:

## Pointers

- Architecture and domain model: `docs/DESIGN.md`
- Phased build plan: `docs/INSTRUCTIONS.md`
- Decision log: `docs/DECISIONS.md`
- Path-scoped rules: `.claude/rules/`

فایل‌های .claude/rules/ هم واقعی‌ان و فقط وقتی لود می‌شن که Claude به مسیر مربوطه دست بزنه؛ مثلاً introspection.md به src/Introspection/** اسکوپ شده و release.md به CHANGELOG.md. نکتهٔ نویسنده اینه که این فایل کوچیکه چون باید بتونی auditش کنی. یه CLAUDE.md سیصدخطی که ماه‌هاست کسی نخونده دیگه context engineering نیست، شده باستان‌شناسی context، و هر سشن این خودِ agent ـه که بد و بی‌دقت توش حفاری می‌کنه.

سه تا چک پیشنهاد می‌ده، به ترتیب هزینه. اول بودجهٔ خطی: یه مرحلهٔ CI که اگه CLAUDE.md از یه حدی رد شد بیلد رو بشکنه، و سقف پیشنهادی خودش ۱۲۰ خطه. دوم چکِ drift، که بیشتر از همه بهش اعتماد داره: همون‌طور که truss:export --check خروجی تازه رو بایت‌به‌بایت با فایل کامیت‌شده مقایسه می‌کنه، یه هوک هم می‌تونه همهٔ مسیرهایی که CLAUDE.md به‌شون اشاره کرده رو دنبال کنه و گم‌شده یا کهنه‌ها رو علامت بزنه.

سوم تست‌های golden-task: چند prompt ثابت مثل «یه artisan command جدید اضافه کن» که قبل از release اجرا می‌شن تا تغییری که تنهایی منطقی به نظر می‌رسه ولی دو فایل اون‌طرف‌تر چیزی رو می‌شکنه لو بره. جمع‌بندی نویسنده اینه که این‌ها همون linting و drift detection و regression testing هستن، چون فایل context هم تو هر چیزی جز syntax highlighting کده. می‌گه وقتی یه اپ vibe-coded ناهمگون و با اعتماد غلط به نظر می‌رسه، سؤال درست این نیست که کدوم مدل ساختش، اینه که اجازه داشته چی رو ببینه.

نکات کلیدی:

• چهار حالت خراب شدن context به روایت نویسنده: Burst، Poisoning، Noise و Conflict.
• CLAUDE.md پروژهٔ Truss فقط ۵۲ خطه و بقیهٔ جزئیات با pointer تو docs/ نگه داشته می‌شه.
• فایل‌های .claude/rules/ به مسیر اسکوپ شدن و فقط با دست زدن به اون مسیر لود می‌شن، نه همیشه.
• سقف پیشنهادیِ نویسنده برای CLAUDE.md تو CI، ۱۲۰ خطه (خودِ Truss فعلاً اینو اجبار نمی‌کنه).
• truss:export --check خروجی تازه رو با فایل کامیت‌شده مقایسه می‌کنه و اگه فرق داشتن با کد غیرصفر بیرون میاد.