Your AI starts every project sharp and ends it sloppy. By hour three of a long session, it's contradicting decisions it made earlier; by hour five, it's confidently breaking working code. The model didn't get worse. The context did. Researchers call this "context rot": the steady degradation of output quality as a conversation grows, even when the context window is technically nowhere near full. The instinct to fix it by using a million-token model is wrong; bigger context windows degrade catastrophically and silently, with the model still answering confidently while averaging across so much noise that the signal is gone. Three patterns cause it: decision drift (old decisions become buried and lose salience), goal blur (the original goal gets diluted by recent tangents), and stale assumptions (the model's mental model of your codebase doesn't update when you change files). Four fixes compound: re-anchor explicitly every 30-60 minutes, end conversations earlier instead of treating length as a virtue, externalize memory into files the model reads each session, and trim aggressively. The reframe that helps most: context is not memory. It's a noisy room. The longer it goes, the harder it is to hear the original goal. Start treating context as a limited resource you spend deliberately, and the rot stops.
You start a coding session with Claude. The first hour is brilliant. The model understands your intent, picks up your patterns, makes good suggestions, catches things you would have missed. You ship more in one hour than you would have in three on your own.
By hour three, something has changed. The model is making suggestions that contradict decisions it agreed to two hours ago. It's proposing patterns you explicitly rejected at the start. It's quietly re-introducing complexity you spent an hour stripping out.
By hour five, it's confidently breaking working code. It removes an import that was load-bearing. It suggests an architectural change that violates a constraint you explained at the start of the session. It cites assumptions you never gave it. The model's tone is the same (calm, helpful, confident), but its output has decayed.
The model didn't get worse. The context did. Researchers started calling this "context rot": the steady degradation of output quality as a conversation grows, even when the model technically still has room in its context window. It's not a hallucination problem in the traditional sense; the model isn't making up facts. It's an averaging problem. When the context grows large enough, the model's attention spreads across too much material, and the recent and the old get blurred into a kind of confident mush.
Once you've recognized this pattern, you can't unsee it. Every long AI session you ever had (every project that started promising and ended with you frustrated, blaming "the model getting dumb") was context rot.
The instinct is reasonable: if the problem is that the model is losing things in a busy context, just use the model with the biggest window. One million tokens! Why would you ever need to manage context if the window is so vast that nothing falls out of it?
That intuition is wrong, and it's wrong in a way that's actively harmful.
Bigger context windows don't degrade gracefully. They degrade catastrophically and silently. The model still answers, and answers confidently, but it's averaging across so much noise that the signal is gone. You get plausible-sounding code that violates constraints you established two hours ago. You get suggestions that contradict each other within the same response. You get explanations of "what we decided" that are reasonable-sounding but factually wrong about your actual decisions.
The silent part is the dangerous part. A model with a small context window gives you an error or a clearly confused response when it runs out of room. A model with a huge context window gives you a smooth wrong answer. The wrongness is hidden inside fluent prose, which is exactly the failure mode hardest to catch in code review.
This is the counter-intuitive lesson: more context is often worse than less context. Precision beats volume. The right answer is not "feed the model everything"; it's "feed the model exactly what it needs to answer this specific question." Curation, not capacity.
Three patterns I see over and over, in my own work and in the work of every developer I've talked to who works heavily with AI:
1. Decision drift. Early in the session you decide "we're using React Router, not Next.js." Two hours later, mid-task, the model proposes a Next.js pattern. Not because it forgot, the decision is still technically in the context window. It's because the original decision is buried under thousands of tokens of code, discussion, and tangents. It's still in context, but it's no longer salient. The model's attention has shifted to the recent material, and the foundational constraints have dimmed into background noise.
Decision drift gets worse with every decision you add. A session with 20 important decisions made over five hours becomes nearly impossible to keep coherent because the model can no longer tell which decisions are still active and which were superseded.
2. Goal blur. You started the session with "build the auth flow." An hour in, you noticed a button alignment issue and asked the model to fix it. Then you got into the weeds of CSS specificity. Then you fixed three related styling bugs. Then you went back to auth, but the model has lost the thread. Is it still trying to ship the auth flow, or is it trying to perfect this section's CSS? Without an explicit re-anchor, it defaults to whatever's most recent, which is the styling work, not the original goal.
Goal blur is what makes long sessions feel productive in the moment and unproductive in retrospect. You did a lot. You shipped less than you thought, because the AI was helping you with whatever was directly in front of you, not with what you actually came to accomplish.
3. Stale assumptions. Early in the session, the model formed a mental model of your codebase based on what it read and what you told it. You've since changed three files. The model is still reasoning against the old version because it hasn't been told to re-read. Its mental model of the codebase is now several edits behind reality, which produces suggestions that look right in theory and break in practice.
Stale assumptions are especially insidious because they correlate with confident-sounding output. The model is reasoning carefully from a model of your codebase. It's just the wrong model.
Four things I do that compound over time. None of them is a silver bullet alone, but together they make long sessions tractable and short sessions much sharper.
1. Re-anchor explicitly. Every 30 to 60 minutes, paste back the core context: "We're building X. Stack is Y. Key decisions so far: A, B, C. Current task: D. What's blocking us is E." Treat the model like a person who just walked into the meeting and needs to be brought up to speed. The re-anchor flushes the noise out of the salience layer and makes the original goal and decisions live again.
I usually keep a short "re-anchor template" in my notes that I paste with minor edits. The exact wording matters less than the act of doing it on a fixed cadence. Even when it feels unnecessary, do it. The 90 seconds you spend re-anchoring saves 30 minutes of subtle wrong-answer debugging later.
2. End conversations earlier. Long conversations are not a virtue. There is no medal for a four-hour AI session. When a major chunk of work is done, start a new chat. Carry forward only the artifacts that matter (file paths, key decisions, the next concrete task) and skip the entire chat history. The new conversation will be sharper than the old one would have been at the same point.
The hardest part of this rule is psychological. It feels wasteful to abandon a conversation that "knows" the project. But the conversation doesn't actually know the project: the codebase does, the decision log does, the CLAUDE.md file does. The conversation just has the noise. Letting it go and starting clean is almost always the right move.
3. Externalize memory. The single highest-leverage thing you can do is move decisions and context out of chat history and into files the model reads at the start of each session. CLAUDE.md files at every level of your codebase. A decisions log that captures every meaningful technical choice. A plan document for the current sprint or project. Anything that lives outside the conversation can survive across conversations.
The discipline this requires (writing things down instead of relying on the model to remember them) pays off everywhere. Even when AI gets dramatically better at context retention, the externalized memory is still valuable for human collaborators, for your future self, and as documentation.
4. Trim aggressively. If a 50-message debugging thread ended in a one-line fix, don't keep the 50 messages around. Summarize the fix in a sentence, paste that sentence as a new message, and let the rest decay out of the conversation. Most chat interfaces will keep all 50 messages in context regardless of how irrelevant they are; you have to actively manage this.
The same applies in Claude Code: when you've solved something hard, write down what you solved and how, then start a fresh session rather than letting the entire debugging trail bloat the next task's context.
I used to think of a conversation as a person remembering more as it grew. The longer the conversation, the more the model knew, the smarter its answers should be. This is wrong, and it's exactly the wrong framing to act on.
The accurate model is: a conversation is a noisy room. The longer it goes, the harder it is to hear the original goal. Adding more context is like adding more people to the room. Sometimes a new person brings exactly the insight you need; usually they just make the room louder. The question isn't "how do I add the right thing?" It's "how do I keep the room quiet enough that the model can still hear the original goal?"
Once I started treating context as a limited resource I had to spend deliberately, the rot stopped. Not because the model got better, but because I stopped feeding it noise. Every message I add to a conversation has a cost. Every file I attach has a cost. Every "explore this" tangent has a cost. The benefit has to justify the noise, and most of the time, it doesn't.
This isn't a constraint on what AI can do; it's a constraint on how to use it well. The same shift in mindset that makes humans more focused (single-tasking, removing distractions, explicit prioritization) makes AI sessions more focused too.
Next time you feel the AI getting dumber mid-session, don't switch models or restart. Instead, paste this back to it:
Re-anchor check: what is the goal of this conversation, what have we decided so far, and what's the next concrete step?
If its answer surprises you (if it gets the goal subtly wrong, omits a decision you remember establishing, or names a "next step" that doesn't match what you thought you were working on), that's context rot. The conversation has drifted, and continuing it will only produce more wrong-answer-with-fluent-prose responses.
When the test fails, the right move is almost always to start a fresh conversation with a curated handoff: the file paths that matter, the decisions that survived, the next concrete task, and nothing else. The new conversation will be sharper than continuing the old one would be.
Context rot used to be a niche problem. AI sessions were short, the model was used for one-shot tasks, and the longest conversation you'd have with it was maybe twenty messages. Decision drift had no time to accumulate. Goal blur didn't happen because there was rarely a goal in the first place.
Then agentic workflows became real. Claude Code, autonomous agents, multi-hour sessions, projects that span days. Suddenly people are running AI sessions that are 200 messages deep, 50,000 tokens in, with a dozen decisions stacked on top of each other. Context rot went from a curiosity to the single biggest determinant of AI productivity.
The developers who get the most out of AI in 2026 are the ones who treat context management as a first-class skill: as important as prompt engineering, as important as choosing the right model. The ones who don't end up confused about why their AI sessions feel productive in the moment but produce sloppier work than they expected.
The discipline I recommend, in order of leverage:
None of this is glamorous. All of it works. And once you internalize that context is a resource you spend, not a pile that grows, the entire AI workflow gets more reliable.
الذكاء الاصطناعيّ يبدأ كلّ مشروع حادّاً وينهيه مرتبكاً. بحلول الساعة الثالثة من جلسة طويلة، يناقض قرارات اتّخذها سابقاً؛ بحلول الخامسة، يكسر بثقة كوداً يعمل. النموذج لم يسُؤ. السياق ساء. الباحثون يسمّون هذا "تعفّن السياق": التدهور التدريجيّ في جودة المخرَجات مع نموّ المحادثة، حتى حين تكون نافذة السياق نظرياً ليست ممتلئة. الحدس بإصلاحه باستخدام نموذج المليون توكن خطأ؛ نوافذ السياق الأكبر تتدهور كارثياً وبصمت، والنموذج يستمرّ بالإجابة بثقة بينما يتوسّط عبر ضوضاء كثيرة فتختفي الإشارة. ثلاثة أنماط تسبّبه: انحراف القرارات (القرارات القديمة تُدفَن وتفقد بروزها)، ضبابيّة الهدف (الهدف الأصليّ يتمدّد بتفرّعات حديثة)، والافتراضات القديمة (النموذج الذهنيّ للنموذج عن مستودعك لا يُحدَّث حين تغيّر الملفّات). أربعة إصلاحات تتراكم: أعِد التثبيت صراحة كلّ 30 إلى 60 دقيقة، أنهِ المحادثات مبكّراً بدل اعتبار الطول فضيلة، أخرِج الذاكرة في ملفّات يقرأها النموذج كلّ جلسة، واقصّ بشدّة. إعادة الصياغة الأكثر نفعاً: السياق ليس ذاكرة، بل غرفة صاخبة. كلّما طالت، صعب سماع الهدف الأصليّ. ابدأ التعامل مع السياق كمورد محدود تنفقه بقصد، ويتوقّف التعفّن.
تبدأ جلسة برمجة مع Claude. الساعة الأولى رائعة. النموذج يفهم نيّتك، يلتقط أنماطك، يقدّم اقتراحات جيّدة، يلتقط أشياء كنت ستفوّتها. تشحن في ساعة أكثر ممّا كنت ستشحن في ثلاث وحدك.
بحلول الساعة الثالثة، شيء تغيّر. النموذج يقدّم اقتراحات تناقض قرارات وافق عليها قبل ساعتين. يقترح أنماطاً رفضتها صراحة في البداية. يعيد بهدوء إدخال تعقيد قضيت ساعة في تجريده.
بحلول الخامسة، يكسر بثقة كوداً يعمل. يحذف Import كان حاملاً للوزن. يقترح تغييراً معمارياً يخالف قيداً شرحته في بداية الجلسة. يستشهد بافتراضات لم تعطه إيّاها. نبرة النموذج نفسها (هادئة، مساعدة، واثقة) لكن مخرَجاته تدهورت.
النموذج لم يسُؤ. السياق ساء. الباحثون بدأوا يسمّون هذا "تعفّن السياق": التدهور التدريجيّ في جودة المخرَجات مع نموّ المحادثة، حتى حين يبقى للنموذج تقنياً متّسع في نافذة سياقه. ليست مشكلة هلوسة بالمعنى التقليديّ؛ النموذج لا يخترع حقائق. هي مشكلة توسّط. حين ينمو السياق كفاية، ينتشر انتباه النموذج عبر مادّة كثيرة جدّاً، فينخلط الحديث الحديث والقديم في ضباب واثق.
ما إن تتعرّف على النمط لن تستطيع نسيانه. كلّ جلسة AI طويلة عشتها (كلّ مشروع بدأ واعداً وانتهى بإحباطك، وأنت تلوم "النموذج صار غبياً") كان تعفّن سياق.
الحدس معقول: لو المشكلة أن النموذج يفقد أشياء في سياق مزدحم، استخدم النموذج بأكبر نافذة. مليون توكن! لماذا قد تحتاج إدارة السياق إن كانت النافذة شاسعة بما لا يخرج منها شيء؟
ذلك الحدس خاطئ، وخطؤه فعّال الضرر.
نوافذ السياق الأكبر لا تتدهور بسلاسة. تتدهور كارثياً وبصمت. النموذج يستمرّ بالإجابة (وبثقة) لكنّه يتوسّط عبر ضوضاء كثيرة فتختفي الإشارة. تحصل على كود معقول الشكل يخالف قيوداً وضعتها قبل ساعتين. تحصل على اقتراحات تناقض بعضها في نفس الردّ. تحصل على شروحات "لما قرّرناه" تبدو معقولة لكنّها خاطئة عن قراراتك الفعليّة.
الجزء الصامت هو الخطير. النموذج بنافذة سياق صغيرة يعطيك خطأ أو ردّاً واضح الارتباك حين تنفد منه المساحة. النموذج بنافذة ضخمة يعطيك إجابة خاطئة سلسة. الخطأ مخبّأ داخل نثر فصيح، وهذا بالضبط وضع الفشل الأصعب التقاطاً في مراجعة كود.
الدرس عكس الحدس: سياق أكثر غالباً أسوأ من سياق أقلّ. الدقّة تهزم الكمّ. الجواب الصحيح ليس "أطعم النموذج كلّ شيء"؛ هو "أطعم النموذج بالضبط ما يحتاج للإجابة على هذا السؤال المحدّد". تنقية لا سعة.
ثلاثة أنماط أراها مراراً، في عملي وفي عمل كلّ مطوّر تحدّثت إليه ممّن يعملون بكثافة مع الذكاء الاصطناعيّ:
1. انحراف القرارات. في البداية تقرّر "نستخدم React Router لا Next.js". بعد ساعتين، يقترح النموذج نمطاً من Next.js. ليس لأنّه نسي, القرار ما زال تقنياً في نافذة السياق. بل لأنّ القرار الأصليّ مدفون تحت آلاف التوكنز من الكود والنقاش والتفرّعات. هو في السياق، لكنّه لم يعد بارزاً. انتباه النموذج انتقل إلى المادّة الحديثة، والقيود الأساسيّة خفتت إلى ضوضاء خلفيّة.
انحراف القرارات يسوء مع كلّ قرار تضيفه. جلسة بعشرين قراراً مهمّاً اتُّخذ على مدى خمس ساعات تصبح شبه مستحيلة الإبقاء متماسكة لأن النموذج لم يعد يميّز أيّ القرارات ما زالت فاعلة وأيّها استُبدلت.
2. ضبابيّة الهدف. بدأت الجلسة بـ "ابنِ تدفّق المصادقة". بعد ساعة، لاحظت مشكلة محاذاة زرّ وطلبت من النموذج إصلاحها. ثم دخلت في تفاصيل خصوصيّة CSS. ثم أصلحت ثلاثة أخطاء تصميم مرتبطة. ثم عدت إلى المصادقة, لكنّ النموذج فقد الخيط. هل ما زال يحاول شحن تدفّق المصادقة، أم يصقل CSS هذا القسم؟ بلا إعادة تثبيت صريحة، يتّبع الأحدث، وهو عمل التصميم لا الهدف الأصليّ.
ضبابيّة الهدف هي ما يجعل الجلسات الطويلة تشعر منتجة في اللحظة وغير منتجة بأثر رجعيّ. فعلت كثيراً. شحنت أقلّ مما ظننت، لأن الذكاء الاصطناعيّ كان يساعدك على ما أمامك مباشرة لا على ما جئت لإنجازه فعلاً.
3. افتراضات قديمة. في بداية الجلسة، كوّن النموذج صورة ذهنيّة عن مستودعك بناءً على ما قرأ وما قلت له. منذ ذلك غيّرت ثلاثة ملفّات. النموذج ما زال يستدلّ على النسخة القديمة لأنّك لم تطلب منه إعادة القراءة. صورته الذهنيّة لمستودعك صارت متخلّفة بعدّة تعديلات عن الواقع، ما يُنتج اقتراحات تبدو صحيحة نظرياً وتنكسر عملياً.
الافتراضات القديمة خبيثة خصوصاً لأنها ترتبط بمخرَجات تبدو واثقة. النموذج يستدلّ بعناية من نموذج لمستودعك: هو فقط النموذج الخاطئ.
أربعة أمور أفعلها تتراكم مع الوقت. لا أحدها رصاصة فضّيّة وحده، لكنّها مجتمعة تجعل الجلسات الطويلة محتملة والجلسات القصيرة أحدّ بكثير.
1. أعِد التثبيت صراحة. كلّ 30 إلى 60 دقيقة، الصق السياق الجوهريّ: "نبني X. الستاك Y. القرارات حتى الآن: A، B، C. المهمّة الحاليّة: D. ما يعطّلنا E". عامل النموذج كشخص دخل الاجتماع للتوّ ويحتاج إحاطة سريعة. إعادة التثبيت تطرد الضوضاء من طبقة البروز وتُحيي الهدف الأصليّ والقرارات.
عادة أحتفظ بقالب "إعادة تثبيت" قصير في ملاحظاتي ألصقه مع تعديلات بسيطة. الصياغة الدقيقة أهمّ من فعل الأمر على إيقاع ثابت. حتى حين يبدو غير ضروريّ، افعله. الـ 90 ثانية التي تنفقها في إعادة التثبيت توفّر 30 دقيقة من تصحيح أخطاء جواب خاطئ خفيف لاحقاً.
2. أنهِ المحادثات مبكّراً. المحادثات الطويلة ليست فضيلة. لا ميداليّة لجلسة AI أربع ساعات. عند إنجاز كتلة كبيرة، ابدأ محادثة جديدة. انقل فقط المُنتَجات التي تهمّ (مسارات ملفّات، قرارات أساسيّة، المهمّة الملموسة التالية) وتخطَّ سجلّ المحادثة كلّه. المحادثة الجديدة ستكون أحدّ مما كانت ستكون عليه القديمة عند النقطة نفسها.
الجزء الأصعب في هذه القاعدة نفسيّ. يبدو إهداراً ترك محادثة "تعرف" المشروع. لكنّ المحادثة لا تعرف المشروع فعلاً: المستودع يعرفه، سجلّ القرارات يعرفه، ملفّ CLAUDE.md يعرفه. المحادثة لديها الضوضاء فقط. تركها والبدء نظيفاً تقريباً دائماً التحرّك الصحيح.
3. أخرِج الذاكرة خارجاً. أعلى أمر رافعة تستطيع فعله هو نقل القرارات والسياق من سجلّ المحادثة إلى ملفّات يقرأها النموذج في بداية كلّ جلسة. ملفّات CLAUDE.md في كلّ مستوى من مستودعك. سجلّ قرارات يلتقط كلّ اختيار تقنيّ معتبر. وثيقة خطّة للسبرنت أو المشروع الحاليّ. أيّ شيء يعيش خارج المحادثة يستطيع النجاة عبر المحادثات.
الانضباط الذي يتطلّبه هذا (كتابة الأشياء بدل الاعتماد على النموذج لتذكّرها) يُؤتي ثماره في كلّ مكان. حتى حين يتحسّن الذكاء الاصطناعيّ كثيراً في حفظ السياق، الذاكرة المخرَجة ما زالت قيّمة للمتعاونين البشريّين، ولنفسك المستقبليّ، وكتوثيق.
4. اقصّ بشدّة. لو انتهى خيط تصحيح أخطاء من 50 رسالة بإصلاح سطر واحد، لا تبقِ الـ 50 رسالة. لخّص الإصلاح في جملة، الصق تلك الجملة كرسالة جديدة، ودع الباقي يتلاشى من المحادثة. معظم واجهات الدردشة تبقي كلّ الـ 50 رسالة في السياق بصرف النظر عن مدى عدم صلتها؛ عليك إدارة هذا بنشاط.
نفس الأمر في Claude Code: حين تحلّ شيئاً صعباً، اكتب ما حللتَه وكيف، ثم ابدأ جلسة جديدة بدل ترك مسار التصحيح كلّه يفخّم سياق المهمّة التالية.
كنت أتخيّل المحادثة كشخص يتذكّر أكثر كلّما طالت. كلّما طالت المحادثة، كلّما عرف النموذج أكثر، كلّما كانت إجاباته أذكى. هذا خاطئ، وهو بالضبط الإطار الخطأ للعمل به.
النموذج الأدقّ: المحادثة غرفة صاخبة. كلّما طالت، صعب سماع الهدف الأصليّ. إضافة سياق أكثر كإضافة أشخاص أكثر إلى الغرفة. أحياناً يجلب شخص جديد بالضبط الرؤية التي تحتاج؛ عادة يجعل الغرفة أكثر ضجيجاً. السؤال ليس "كيف أضيف الشيء الصحيح؟"، بل هو "كيف أبقي الغرفة هادئة بما يكفي ليبقى النموذج قادراً على سماع الهدف الأصليّ؟"
حين بدأت التعامل مع السياق كـ مورد محدود يجب إنفاقه بقصد، توقّف التعفّن. لا لأنّ النموذج تحسّن، بل لأنّني توقّفت عن إطعامه ضوضاء. كلّ رسالة أضيفها لمحادثة لها كلفة. كلّ ملفّ أرفقه له كلفة. كلّ تفرّع "استكشف هذا" له كلفة. الفائدة عليها تبرير الضوضاء، وغالباً لا تبرّرها.
هذا ليس قيداً على ما يستطيع الذكاء الاصطناعيّ فعله؛ هو قيد على كيف نستخدمه جيّداً. نفس التحوّل الذهنيّ الذي يجعل البشر أكثر تركيزاً (العمل على مهمّة واحدة، إزالة المشتّتات، تحديد الأولويّات صراحة) يجعل جلسات الذكاء الاصطناعيّ أكثر تركيزاً أيضاً.
في المرّة القادمة التي تشعر فيها أن الذكاء الاصطناعيّ يصبح أغبى منتصف الجلسة، لا تبدّل النماذج ولا تعد التشغيل. الصق إليه هذا:
فحص إعادة التثبيت: ما هدف المحادثة، ما الذي قرّرناه حتى الآن، وما الخطوة الملموسة التالية؟
لو فاجأك جوابه (لو أخطأ الهدف بدقّة، أو أغفل قراراً تذكره، أو سمّى "خطوة تالية" لا تطابق ما ظننت أنّك تعمل عليه)، هذا تعفّن سياق. المحادثة انحرفت، ومواصلتها لن تنتج إلّا مزيداً من ردود الجواب الخاطئ بنثر فصيح.
حين يفشل الاختبار، التحرّك الصحيح تقريباً دائماً البدء بمحادثة جديدة بانتقال نظيف: مسارات الملفّات التي تهمّ، القرارات التي نجت، المهمّة الملموسة التالية، ولا شيء آخر. المحادثة الجديدة ستكون أحدّ من مواصلة القديمة.
تعفّن السياق كان مشكلة هامشيّة. جلسات AI كانت قصيرة، النموذج يُستخدم لمهام دفعة واحدة، وأطول محادثة قد تخوضها كانت ربّما عشرين رسالة. انحراف القرارات لم يكن لديه وقت للتراكم. ضبابيّة الهدف لم تحدث لأنّه نادراً ما كان هناك هدف أصلاً.
ثم صارت سير العمل الوكيليّة حقيقيّة. Claude Code، وكلاء مستقلّون، جلسات متعدّدة الساعات، مشاريع تمتدّ أياماً. فجأة الناس يشغّلون جلسات AI عمقها 200 رسالة، 50,000 توكن، بدزينة قرارات مكدَّسة فوق بعضها. تعفّن السياق انتقل من فضول إلى أكبر محدّد منفرد لإنتاجيّة الذكاء الاصطناعيّ.
المطوّرون الذين يستخرجون الأكثر من الذكاء الاصطناعيّ في 2026 هم من يعاملون إدارة السياق كمهارة من الدرجة الأولى: بأهميّة هندسة البرومت، بأهميّة اختيار النموذج الصحيح. الذين لا يفعلون ينتهون مرتبكين عن لماذا تشعر جلسات AI عندهم منتجة في اللحظة لكن تنتج عملاً أكثر فوضى ممّا توقّعوا.
الانضباط الذي أوصي به، مرتَّباً بالرافعة:
لا شيء من هذا برّاق. كلّ شيء منه يعمل. وما إن تستوعب أن السياق مورد تنفقه لا كومة تنمو، يصبح سير العمل كلّه أكثر موثوقيّة.