ضائع في السياق
١. التطبيق اللي عدّى كل الاختبارات وما اشتغلش
قبل شهرين، أدّيت Claude Code مواصفات، خطة، والكود كله بتاعي. قلت له ابني تطبيق full-stack. Frontend، Backend، قاعدة بيانات، كل حاجة. نمت. صحيت على Build أخضر.
كل الاختبارات كانت ناجحة. الحاوية شغالة. الواجهة طالعة. الباك إند بيرد. فتحت التطبيق وحسيت بلحظة النشوة القصيرة دي اللي بتفتكر فيها إن الأداة وفرت عليك أسبوعين شغل.
بعدين بدأت أضغط.
مافيش حاجة شغالة من أولها لآخرها. الواجهة كانت مربوطة على stubs. عقد الـ API بين الواجهة والباك إند ما اتبناش أبدًا. البيانات اللي ظاهرة على الشاشة كانت محتوى وهمي متشافد بالصدفة بيطابق fixtures الاختبارات. التطبيق كان قرية بوتيمكين بشعار CI أخضر.
قضيت باقي اليوم بمسح معظمه وبكتب العقود بنفسي.
دي ما كانتش غلطة Claude. Claude عمل بالضبط اللي طلبته منه: يولّد كود يحقق المواصفات ويعدّي الاختبارات. المشكلة إن المواصفات وصفت النية، مش العقود. الاختبارات فحصت وحدات منعزلة، مش التكامل. وأنا، المراجع البشري، وافقت على كود ما كنتش قادر أقرأه بشكل حقيقي لأنه كان كتير أوي والعلامات الخضرا قالت لي إنه تمام.
كنت واثق زيادة إن Claude Code ممكن يبني كل حاجة في طلقة واحدة. overtrust بتاعي كان "اعمل كل الشغل مرة واحدة." لما اختبرته بعد ساعات من التشغيل، اتصدمت. مش من Claude. من نفسي. كنت استعوضت الجزء الوحيد من الهندسة اللي ما ينفعش يتستعاض عنه: التحقق من إن الحاجة شغالة فعلاً.
البوست ده عن اللي بيحصل لما الذكاء الاصطناعي يكتب كود أكتر من اللي أي بشري يقدر يراجعه، والـ build الأخضر بيكدب عليك.
٢. الأرقام اللي محدش بيتكلم عنها
فرق assisted-AI بتطلع كود أكتر. ده العنوان اللي الكل بينشره. ده بقية القصة.
LinearB حللوا فرق هندسية في أواخر ٢٠٢٥ ولقوا إن الفرق المدعومة بالذكاء الاصطناعي أنتجت حوالي ٢٠٪ pull requests أكتر. نفس الفرق شهدت زيادة ٢٣.٥٪ في حوادث الإنتاج وحوالي ٣٠٪ زيادة في معدلات فشل التغييرات.
كود أكتر، أخطاء أكتر. مفيش حاجة مفاجئة هنا. لكن الآلية هي اللي تفرق. أدوات الذكاء الاصطناعي مش بتكتب كود فيه أخطاء أكتر لكل سطر. هي بتكتب أسطر أكتر بكتير، متحزمة في pull requests أكبر، والـ PRs دي بتغرق عملية المراجعة البشرية.
Google نشروا دراسة على ٩ مليون مراجعة كود ولقوا إن حجم المراجعة الأمثل هو ٢٠٠ لـ ٤٠٠ سطر. بعد كده، فعالية المراجعة بتنخفض بشكل حاد. المراجعين بيلقطوا أخطاء أقل لكل سطر. بيفوّتوا مشاكل نظامية. بيبصوا بصة سريعة. عند ٥٠٠ سطر، انت بدأت تخسر الإشارة. عند ١٠٠٠ سطر، انت بتختم بختم مطاط.
Claude Code ممكن يولّد ٢٠٠٠ سطر في جلسة واحدة. ممكن يعمل كده بسياق كامل لقاعدة الكود بتاعتك، كل ملف، كل نمط، كل اتفاقية. ممكن ينتج PR بيتBuild، بيعدّي الاختبارات، وبيتبع دليل الأسلوب بتاعك. ممكن يعمل كل ده وإنت نايم.
ولما تصحى، بتلاقي نفسك قدام ٢٠٠٠ سطر كود إنت ما كتبتهاش، بتمس ١٠ ملفات ما فتحتهاش من شهور، بعلامة خضرا من pipeline CI بتحقق بالضبط اللي إنت قلت له يحققه ولا حاجة أكتر.
قدامك اختيارين. تقعد ٤ ساعات تراجعهم صح، اللي مش هتعمله علشان عندك ٣ اجتماعات وPR تاني مستني. أو توافق، علشان الاختبارات نجحت والذكاء الاصطناعي ما خذلكش قبل كده.
معظم الناس بيختاروا الاختيار التاني. البيانات بتأكد ده. PRs الأكبر بترتبط بمراجعات أخف. المراجعات الأخف بترتبط بحوادث أكتر. الحوادث الأكتر بترتبط بكل حاجة تانية: مكالمات on-call، تصعيدات عملاء، تآكل الثقة.
٣. نافذة السياق هي المشكلة
نماذج الذكاء الاصطناعي بتتسوّق بنوافذ السياق بتاعتها. Gemini 2.5 Pro بيعلن عن مليون رمز. Claude بيدّعي ٢٠٠ ألف. الأرقام دي بتبيع الوهم إن سياق أكتر يعني مخرجات أفضل. أطعم النموذج قاعدة الكود كلها، كل README، كل مستند تصميم، كل تقرير حادثة سابق، وهينتج كود فاهم كل حاجة.
الوهم غلط بالنص بس. النموذج فعلاً فاهم كل حاجة. دي هي المشكلة.
لما بتدي الذكاء الاصطناعي قاعدة كودك كلها، بينتج مخرجات بتعكس قاعدة كودك كلها. بيمس ملفات عبر modules لأنه شايف الروابط. بيعمل refactor عبر الحدود لأنه شايف الـ coupling. بيعمل تغييرات نظامية واسعة لأنك أديته النظام.
المراجع البشري بيفتح الـ PR ده وبيشوف ١٥ ملف اتغيروا، ١٨٠٠ سطر مضافين، ٣٠٠ متشالين. التغييرات صحيحة فرديًا. كل دالة شكلها نظيف. كل اختبار ناجح. لكن المراجع مش قادر يمسك كل الـ ١٥ ملف في دماغه في نفس الوقت. مش قادر يصمم التأثيرات المتسلسلة. مش قادر يجاوب على السؤال اللي بيهم أكتر من أي حاجة: هل الحاجة دي شغالة فعلاً من أولها لآخرها؟
نافذة سياق الذكاء الاصطناعي ٢٠٠ ألف رمز. نافذة المراجعة الفعالة للبشري حوالي ٤٠٠ سطر. الفجوة بين الرقمين دول، ٢٠٠ ألف رمز توليد مقابل ٤٠٠ سطر استيعاب، هي المكان اللي الأخطاء بتعيش فيه. مش أخطاء في مخرجات الذكاء الاصطناعي. أخطاء في موافقة البشري.
دي مش محدودية أداة. دي محدودية إدراكية. أنت مش قادر تقرأ ٢٠٠٠ سطر كود في ٣٠ دقيقة وتلقط عقد الـ API الناقص بين الواجهة والباك إند. البيانات المتشافدة اللي بالصدفة بتطابق fixtures الاختبارات بتعدي من غير ما تلاحظها. بتخسر مسار التنفيذ عبر ٨ ملفات وإنت بتتنقل بين tabs، بتضيع مكانك.
الـ build الأخضر بيتحول لبديل عن الصحة لأن البديل، قراءة كل سطر فعلاً، مش واقعي. والذكاء الاصطناعي عارف ده. مش بوعي، لكن بشكل هيكلي. بي optimize لللي بينقبل. كود بيعدّي الاختبارات بيتقبل. كود أكبر من إنه يتراجع بيقبل لو الاختبارات نجحت. حلقة الـ feedback بتختار PRs كبيرة مع اختبارات ناجحة، وضغط الاختيار ده بينتج بالضبط نوع الكود اللي صحيت عليه: حاوية شغالة، CI أخضر، ولا حاجة شغالة من أولها لآخرها.
٤. اللي أنا بنيته فعلاً
خليني أوصف الفشل بالتفصيل، لأن التفاصيل هي اللي تفرق.
طلبت من Claude Code يبني تطبيق full-stack بواجهة React وباك إند Python. كتبت مواصفات مفصلة. حطيت قرارات هندسية. حددت الـ tech stack، هيكل المجلدات، استراتيجية الاختبارات. افتكرت إني غطيت كل حاجة.
Claude ولّد الكود. الواجهة عرضت صفحة. الباك إند خدم استجابات API. الاختبارات نجحت. الحاوية اتبنت واشتغلت. من بره، الشكل كان مكتمل.
ده اللي كان بيحصل فعلاً:
مكونات الواجهة كانت بتنادي دوال محلية بترجع JSON متشافد. الدوال دي كان ليها نفس شكل استجابات الـ API المفروض تناديها. كانت متطابقة مع types TypeScript. كانت متطابقة مع توقعات الاختبارات. لكنها ما لمستش الشبكة أبدًا. ما كانش فيه استدعاء fetch، ولا Axios instance، ولا WebSocket connection. الواجهة كلها كانت محاكاة مكتفية ذاتيًا شكلها متطابق مع الحاجة الحقيقية.
الباك إند كان عنده endpoints حقيقية. كانت بترجع بيانات حقيقية من قاعدة بيانات حقيقية. كانت متختبرة وصحيحة. لكن الواجهة ما نادتهاش أبدًا. العقد بين النصفين، types المشتركة، schema الطلب، شكل الاستجابة، استراتيجية معالجة الأخطاء، ما اتبناش أبدًا. Claude بنى تطبيقين مستقلين بالصدفة بيشاركوا repository.
الاختبارات نجحت لأن كل نص اتختبر في عزلة. اختبارات الواجهة سخروا من طبقة الـ API. اختبارات الباك إند سخروا من الـ client. ما كانش فيه اختبارات تكامل لأني ما حددتهاش. أنا افترضت إن الذكاء الاصطناعي حيوصل القطع. هو افترض إن القطع مكتملة حسب المواصفات.
ولا أنا ولا هو تحققنا من الافتراض. الـ build كان أخضر. الاختبارات نجحت. وافقت. ولا حاجة اشتغلت.
التكلفة ما كانتش الحوسبة المهدرة. فاتورة API بتاعة Claude كانت مهملة. التكلفة كانت الثقة اللي خسرتها في حكمي. كنت سلمت سلطة الموافقة بتاعتي لعلامة خضرا واتعلمت بالطريقة الصعبة إن الاختبارات الناجحة والبرمجيات الشغالة حاجتين مختلفتين. كل مهندس عارف ده. أنا نسيته لأن الأداة كانت جديدة ومبهرة وكنت عايزها تشتغل.
٥. ده مش هجوم على الذكاء الاصطناعي
الاستنتاج السهل هو "الذكاء الاصطناعي بيكتب كود وحش، ما تستخدموش." ده غلط، كسل، ومش أمين. الذكاء الاصطناعي بيكتب كود أسرع مني. بيفتكر كل اتفاقية، كل قاعدة lint، كل تعريف type. مش بيتعب، مش بيقلل مجهود علشان يوم الجمعة بعد الظهر، مش بيشيبل تعليق TODO ويعدك إنه حيصلحه بعدين.
المشكلة مش في الكود. المشكلة في workflow.
لما مهندس جونيور بيقدم PR فيه ٢٠٠٠ سطر، أنت مش بتوافق عليه. بترجعه له. بتقوله قسّمه لـ PRs أصغر، كل واحد بهدف واضح، كل واحد ممكن يتراجع في أقل من ٣٠ دقيقة. بتفرض ده علشان عارف إن PR بـ ٢٠٠٠ سطر هو liability، بغض النظر عن مين اللي كتبه.
لما الذكاء الاصطناعي بيقدم PR بـ ٢٠٠٠ سطر، نفس القاعدة بتطبق. إن الذكاء الاصطناعي كتبه في ٣٠ ثانية بدل ٣ أيام مش بيغير عبء المراجعة. الكود لسه محتاج يتفهم. التكامل لسه محتاج يتتحقق منه. العقود لسه محتاج تترسم. لو حاجة، كود الذكاء الاصطناعي محتاج تدقيق أكتر لأنه مش داخل اللعبة. مش حيتصل بيه الساعة ٣ الفجر. مش حينزل في الـ postmortem. مش حيشرح للعميل ليه بياناته اختفت.
النقطة المضادة اللي تستحق الاعتراف هي إن الفرق المدعومة بالذكاء الاصطناعي عندها أدوات أفضل. pipelines CI أسرع من أي وقت. الاختبارات الآلية بتلقط أكتر. التحليل الثابت بيعلم الثغرات قبل ما توصل للإنتاج. review bots زي CodeRabbit و Graphite Reviewer بيمسحوا كل PR ويطلعوا مشاكل البشري ممكن يفوتها.
الأدوات دي بتساعد. هي مش كفاية. review bot ممكن يقول لك إن دالة ناقصة معالجة أخطاء. مش ممكن يقول لك إن الواجهة والباك إند ما اتفقوش أبداً على شكل استجابة. مش ممكن يقول لك إن البيانات على الشاشة مزيفة. مش ممكن يتحقق من إن الحاجة شغالة. بس بشري، بيشغل الكود، بيرسم التنفيذ، بيضغط عبر التدفقات، ممكن يتحقق من ده.
الحجة مش "تمهل." الحجة هي "راجع اللي بتشحنه." الذكاء الاصطناعي ممكن يكتب الكود. مش ممكن ياخد المسؤولية عنه. الجزء ده لسه بتاعك.
٦. PRs صغيرة، عيون بشرية، واللي بيشتغل فعلاً
غيرت ٣ حاجات بعد حادثة قرية بوتيمكين.
أولاً، بطّلت أطلب من الذكاء الاصطناعي يبني ميزات كاملة في طلقة واحدة. بدل كده، بطلب منه يبني عقد واحد في كل مرة. عقود API بتتكتب الأول، تتراجع، وتتجمد قبل أي implementation يلمسها. الواجهة والباك إند بيتنفذوا على العقد ده في PRs منفصلة. العقد هو الكوبري، والكوبري بيتبنى قبل أي شط.
ثانيًا، بفرض حد صارم لعدد الأسطر. كل PR لازم يكون ممكن يتراجع في أقل من ٣٠ دقيقة. لو الذكاء الاصطناعي ولّد أكتر من حوالي ٤٠٠ سطر، بطلب منه يقسم الشغل. الذكاء الاصطناعي بيقاوم ده. عايز يكون شامل. عايز يوريك كل حاجه ممكن يعملها. بقوله لأ. قسم الشغل. PRs أصغر، كل واحد بهدف واحد، كل واحد ممكن يتراجع من بشري تعبان شوية ومشتت شوية ولسه قادر يلقط استدعاء fetch الناقص.
ثالثًا، بتأكد من كل PR بتشغيل التطبيق، مش بس الاختبارات. بضغط على التدفقات. بشوف تبويبة الشبكة. ببص على البيانات وبسأل إذا كانت جاية من قاعدة البيانات ولا من ثابت متشافد. لو مش قادر أتحقق منه بإيدي في أقل من ١٠ دقايق، الـ PR كبير أوي. برجعه.
دي مش تغييرات تقنية. دي تغييرات عملية. مش بتكلف حاجة تتنفذ. بتتمهل في الكود الأولي لكنها بتلغي إعادة الشغل. إعادة الشغل من تطبيقي الفاشل أخدت وقت أطول من التوليد الأصلي. إعادة الشغل من كل PR مش ممكن يتراجع بتاخد وقت أطول من تقسيمه.
ولا حاجة من ده جديدة. المهندسين اللي شغّلوا أنظمة إنتاج لسنين عارفين القواعد دي. اتعلموها من الحوادث والـ postmortems والتراكم البطيء للندب. الجديد هو إن أدوات الذكاء الاصطناعي بتخلّي من السهل إنك تنساهم. السرعة مغرية. العلامة الخضرا مقنعة. تكلفة النسيان هي هي زي ما كانت دايمًا: تطبيق مكسور، يوم ضايع، والإحراج الهادئ إنك وثقت في الأداة أكتر من حكمك.
٧. النقطة اللي بينهار فيها الموضوع على نطاق واسع
أنا بشتغل على فرق صغيرة. براجع كود الذكاء الاصطناعي بتاعي بنفسي. حلقة الـ feedback ضيقة. لما الـ PR كبير أوي، بلاحظ علشان أنا اللي المفروض أقراه.
على نطاق واسع، حلقة الـ feedback بتتكسر. لما فريق فيه ٢٠ مهندس كل واحد عنده AI assistant بيولّد كود، حجم الـ PR الإجمالي بيزيد عن طاقة المراجعة بتاعة الفريق. المراجعين بيعملوا skim. بيوافقوا أسرع. بيثقوا في الـ build الأخضر أكتر لأن البديل، تبطيء الفريق كله، مش خيار سياسي قابل للتطبيق.
هنا أرقام LinearB بتبطل تكون مثيرة للاهتمام وتبدأ تكون مقلقة. زيادة ٢٠٪ في حجم الـ PRs مع زيادة ٣٠٪ في معدلات فشل التغييرات مش صدفة. ده نظام تحت ضغط. كود أكتر بيوصل أسرع من اللي البشريين يقدروا يقرأوه. موافقات أكتر مبنية على مخرجات CI بدل الاستيعاب. حوادث أكتر سببها تغييرات ما اتراجعتش فعلاً.
معنديش حل لمشكلة النطاق الواسع. PRs صغيرة بتساعد، review bots بتساعد، دمج توليد الذكاء الاصطناعي مع مراجعة الذكاء الاصطناعي بيساعد، لكن القيد الأساسي لسه موجود: البشري ممكن يقرأ كود كتير بس في اليوم، وأدوات الذكاء الاصطناعي شاطرة جدًا في توليد كود أكتر من كده. في حتة ما في كل منظمة فيه بشري بيوافق أكتر ما بيقرأ. السؤال مش إذا كان الشخص ده موجود. السؤال هو كام كود غير مراجع بيشيبل من خلاله دلوقتي، وهايكلف إيه عشان نعرف.
٨. المراجع
LinearB, "The State of AI Code Review 2025," December 2025. Key stat: AI-assisted teams show 20% PR volume increase, 23.5% incident increase, ~30% change failure rate increase. (https://linearb.io/blog/ai-code-review)
Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, Alberto Bacchelli, "Modern Code Review: A Case Study at Google," ACM/IEEE ICSE-SEIP 2018. Key stat: optimal review size is 200-400 lines; effectiveness drops sharply beyond that. (https://dl.acm.org/doi/10.1145/3290605.3300464)
Personal experience: Hossam Fares, Claude Code full-stack application generation, May 2026. Application passed all tests, container ran, but frontend was wired to stubs and the FE↔BE API contract was never built. No integration verification was performed before approval.