افهم، صمّم، راجِع: كيف نتعامل مع الشيفرة المولَّدة بالذكاء الاصطناعي

حلّل تقرير 2026 Software Engineering Benchmarks Report (opens in new tab) الصادر عن LinearB ما مجموعه 8.1 مليون طلب سحب من 4,800 فريق. طلبات السحب التي أُنتجت بالذكاء الاصطناعي دُمجت خلال 30 يومًا في 32.7٪ من الحالات. أما طلبات السحب المكتوبة دون مساعدة: 84.4٪.

هذا لا يعني أن الذكاء الاصطناعي يكتب شيفرة سيئة. بل يعني أن ثلثي التغييرات التي أنتجها الذكاء الاصطناعي لم تصل إلى قاعدة الشيفرة خلال شهر من فتحها. في مكانٍ ما بين الفتح والدمج، حُكم على تلك التغييرات بأنها غير صحيحة، أو غير مكتملة، أو غير مفهومة، أو غير مرغوب فيها، أو أنها لم تحظَ أصلًا بالاهتمام اللازم للحكم عليها. ذلك الحكم هو العمل الآن.

جعل الوكلاء كتابة الشيفرة رخيصة. لكنهم لم يجعلوا معرفة ما يجب كتابته رخيصة، ولم يجعلوا التيقّن من صحته رخيصًا. إن كنت تشتري برمجيات مخصّصة، فالأمران الثاني والثالث هما ما تدفع ثمنه. وتتناول هذه التدوينة كيف نقوم بهما.

العمل لم يتقلّص، بل انتقل

لا تزال أكثر تجربة يُستشهد بها في هذه المسألة هي التجربة العشوائية المضبوطة التي أجرتها METR عام 2025 (opens in new tab). عمل ستة عشر مطورًا متمرّسًا في المصادر المفتوحة على 246 مشكلة حقيقية في مستودعات كبيرة يعرفونها جيدًا. وحين سُمح لهم باستخدام أدوات الذكاء الاصطناعي، استغرقوا وقتًا أطول بنسبة 19٪. قبل الدراسة توقّعوا تسريعًا بنسبة 24٪؛ وبعدها ظلّوا يعتقدون أنهم كانوا أسرع بنحو 20٪.

كثيرًا ما تُرفع هذه النتيجة شعارًا: "الذكاء الاصطناعي يجعل المطورين أبطأ". هذا هو الدرس الخطأ، وMETR نفسها تقول ذلك: يصرّح الباحثون بأنهم لا يدّعون أن الذكاء الاصطناعي يعجز عن تسريع معظم المطورين، ومتابعتهم في فبراير 2026 (opens in new tab) تشير إلى تسريع لدى المشاركين العائدين (يُقدَّر بـ18٪، بفاصل ثقة يمتد من أسرع بـ38٪ إلى أبطأ بـ9٪). وتصف METR أيضًا تلك البيانات الأحدث بأنها غير موثوقة، ويعود ذلك جزئيًا إلى أن كثيرًا من المطورين لم يعودوا يريدون العمل دون ذكاء اصطناعي على الإطلاق، وقال ما بين 30 و50٪ من المشاركين إنهم حجبوا بعض المهام لأنهم لم يرغبوا في إنجازها دون ذكاء اصطناعي.

الدرس الذي نستخلصه أضيق وأكثر فائدة. من العوامل التي تذكرها METR لتفسير تباطؤ 2025 أن أداء الذكاء الاصطناعي أسوأ نسبيًا في البيئات ذات معايير الجودة المرتفعة جدًا والكثير من المتطلبات الضمنية: التوثيق، وتغطية الاختبارات، والأعراف التي لم يدوّنها أحد. وهذا وصف دقيق لبرمجيات الأعمال التي يجب أن تعمل خمسة عشر عامًا. لم يكن عنق الزجاجة يومًا هو الكتابة على لوحة المفاتيح، بل كان تلك الأمور الضمنية، والوكلاء لا يعرفونها ما لم يخبرهم بها أحد.

لذا لم تصغر مهمة المطوّر، بل تركّزت في ثلاثة مواضع:

افهم المشكلة جيدًا بما يكفي ليصبح الضمني صريحًا.
صمّم البنية المعمارية، ودوّنها، كي يعمل الوكيل ضمن حواجز حماية متّفق عليها.
راجِع النتيجة بعين ناقدة، بما يكفي ليتمكّن مهندسٌ من تحمّل مسؤولية كل سطر فيها.

أما إنتاج الشيفرة بين هذه المراحل فهو حيث يساعد الوكلاء فعلًا. ويتناول باقي هذه التدوينة الأفعال الثلاثة بالترتيب.

افهم: الوكلاء يضخّمون كل ما تعطيهم إياه

لخّص فريق DORA في Google أبحاثه لعام 2025 حول التطوير المدعوم بالذكاء الاصطناعي (opens in new tab) في جملة واحدة: الدور الأساسي للذكاء الاصطناعي هو دور المُضخِّم، إذ يُكبّر نقاط القوة والضعف القائمة لدى المؤسسة. والنتيجة التي نراها الأهم تقع في نموذج قدرات الذكاء الاصطناعي من DORA (opens in new tab): التركيز على المستخدم يُضخّم الأثر الإيجابي للذكاء الاصطناعي في أداء الفريق، ومن دون هذا التركيز قد يكون لتبنّي الذكاء الاصطناعي أثر سلبي. وبتعبير DORA، قد تكون الفرق ببساطة تتحرك بسرعة في الاتجاه الخطأ.

وهذا يطابق الطريقة التي يفشل بها الوكلاء عمليًا. نادرًا ما يفشلون بإنتاج شيفرة لا تجتاز الترجمة (compile). بل يفشلون بإنتاج شيفرة واثقة، حسنة البنية، جيدة الاختبار، لكنها تحلّ مشكلة مختلفة قليلًا. وجد استطلاع Stack Overflow Developer Survey 2025 (opens in new tab) أن الإحباط الأول من أدوات الذكاء الاصطناعي، الذي ذكره 66٪ من المشاركين، هو "حلول صحيحة تقريبًا، لكن ليس تمامًا". والصحيح تقريبًا هو أغلى أنواع الخطأ، لأنه يجتاز النظرة العابرة.

تخيّل شركة بيع بالجملة تطلب "تذكيرات دفع تلقائية". الوكيل الذي يتلقّى هذه الجملة سيُنتج مُجدوِلًا نظيفًا، وقالب بريد إلكتروني، ومجموعة اختبارات، وكل ذلك في فترة بعد ظهر واحدة. ما لن يعرفه: أن كبار العملاء المرتبطين بعقود إطارية يجب ألا يتلقّوا تذكيرًا آليًا أبدًا، وأن خصم الدفع المبكر (Skonto) يُغيّر تاريخ الاستحقاق، وأن الدفعات الجزئية شائعة، وأن مراحل المطالبة بالسداد يجب أن تطابق ما يقوم به قسم المحاسبة يدويًا بالفعل. لا شيء من ذلك موجود في التذكرة. وكله موجود في أذهان الأشخاص الذين يؤدّون العمل اليوم.

المطوّر الذي يكتب ذلك يدويًا كان سيصطدم بهذه الأسئلة في منتصف الطريق ويذهب ليسأل. أما الوكيل فيملأ الفجوة بافتراض يبدو معقولًا ويواصل. التوليد السريع يُزيل الاحتكاك الذي كان يكشف سوء الفهم.

لهذا نعتقد أن فهم المشكلة صار الآن النشاط الهندسي الأعلى أثرًا، لا إجراءً شكليًا يسبق البيع. وبشكل ملموس، القاعدة الجيدة هي: قبل توليد أي تنفيذ، ينبغي أن يكون المهندس قادرًا على ذكر الحالات الحدّية والاستثناءات وقواعد "هذا يجب ألا يحدث أبدًا" بمفردات العميل نفسه. إن لم يستطع المهندس ذلك، فالوكيل حتمًا لن يستطيع، والشيفرة التي ستعود ستُجسّد تخمينًا.

صمّم: القرارات المكتوبة هي حواجز الحماية للوكيل

قاعدتنا الصارمة الأولى: قرارات البنية المعمارية تُدوَّن ويُتّفق عليها مع العميل قبل أن يولّد الوكلاء شيفرة التنفيذ. نموذج البيانات، وحدود الوحدات، ونقاط التكامل، وأين تُحفظ الحالة، وكيف تظهر الأخطاء، وأي التبعيات نقبل. وثائق قصيرة، بلغة واضحة، يعتمدها الأشخاص الذين سيعيشون مع النظام.

هناك سببان، وواحد منهما فقط يتعلق بالوكيل.

السبب الواضح: القرار المكتوب سياقٌ يستطيع الوكيل استخدامه. تُدرج DORA "البيانات الداخلية المتاحة للذكاء الاصطناعي" ضمن قدراتها السبع. والوكيل الذي يستطيع أن يقرأ "الفواتير غير قابلة للتعديل بعد إصدارها؛ والتصحيحات تكون مستندات جديدة" سيتخذ خيارات خاطئة أقل من وكيل عليه أن يستنتج ذلك من قاعدة الشيفرة.

السبب الأقل وضوحًا أهم: القرار المكتوب هو المعيار الذي تُقاس به المراجعة. الوكلاء لا يتّبعون التعليمات بشكل موثوق، مهما كُتبت بعناية. وفي تقييمها العملي لأدوات التطوير المدفوع بالمواصفات (spec-driven development) (opens in new tab) على martinfowler.com، ترصد Birgitta Böckeler هذا بالضبط: كثيرًا ما رأت الوكيل في النهاية لا يتّبع كل التعليمات، ومن ذلك حالة تجاهل فيها ملاحظات تصف أصنافًا (classes) موجودة وكرّرها. فالمواصفة إذن ليست ضمانة، بل هي ما تقيس المخرجات عليه. من دون قرار مكتوب، لا يستطيع المراجع إلا أن يسأل "هل يبدو هذا معقولًا؟". ومعه، يستطيع أن يسأل "هل يفعل هذا ما اتفقنا عليه؟"، وهو سؤال أدقّ بكثير.

كم ينبغي أن نكتب

تُسمّي مقالة Böckeler أيضًا الفشل على الجانب الآخر: إصلاح خطأ صغير حوّلته إحدى الأدوات إلى أربع قصص مستخدم بستة عشر معيار قبول، أي مطرقة ثقيلة لكسر جوزة، وأكوام من ملفات markdown المتكررة كانت مراجعتها أصعب من مراجعة الشيفرة نفسها. ونتفق معها في أن الإفراط في التوصيف مشكلة حقيقية.

رأينا أن القرارات ينبغي أن تُكتب عند المستوى الذي يكون فيه التراجع عن الخيار الخاطئ مكلفًا: نموذج البيانات، والحدود، والتكاملات، والأمن وحماية البيانات. لا نكتب مواصفة لكل زر. تميّز Böckeler بين "spec-first" (المواصفة أولًا، وتُرمى بعد إنجاز الميزة) و"spec-anchored" (المواصفة مرساةً، تُحفظ وتتطوّر مع الشيفرة). بالنسبة للبنية المعمارية، نرى أن الخيار الثاني هو الوحيد الذي يمكن الدفاع عنه. نظامٌ لشركة Mittelstand سيعيش أطول من المهندسين الذين بنوه، والشخص التالي يحتاج إلى معرفة لماذا وُضعت الحدود حيث هي، لا أين هي فقط.

ولأن العميل يعتمد هذه القرارات، فهو جزء من حواجز الحماية. وهذا مقصود. إذا اقترح وكيل تغييرًا يتجاوز حدًا متفقًا عليه، فهذا ليس تعليقًا في مراجعة الشيفرة، بل حديث مع العميل.

راجِع: قواعدنا قبل دمج أي شيء

هذا هو الجزء الذي تُحيل إليه صفحة كيف نعمل، لذا سنكون محدّدين. قاعدتنا الأساسية سهلة الصياغة:

مهندسٌ يراجع كل سطر ويفهمه ويتحمّل مسؤوليته قبل دمجه. ليس الوكيل، ولا "الفريق"، ولا بوت. مهندس محدّد بالاسم، يستطيع شرح أي سطر في التغيير إذا سُئل.

طرح Addy Osmani الحجة نفسها في Own the Outer Loop (opens in new tab): يستطيع الوكلاء تشغيل الحلقة الداخلية من التقصّي والتنفيذ والتحقق، لكن البشر يملكون الحدود وبوابات الجودة والحكم النهائي، لأن أحدًا يجب أن يكون قادرًا على شرح ما تغيّر، ولماذا كان آمنًا، وما الذي يحدث إن كان مخطئًا. نتفق تمامًا. المساءلة التي لا يمكن تفويضها لأداة يجب أن تقع على شخص، وهذا الشخص يحتاج إلى فهم ما يوقّع عليه.

أربعة أمور معيارية في كل تغيير، لا إضافات اختيارية:

الاختبارات. تصل الشيفرة المولَّدة دون سجلّ سابق. الاختبارات هي وسيلتنا لنمنحها سجلًا، ووسيلة المهندس التالي لمعرفة ما يُفترض بالشيفرة أن تفعله.
TypeScript بأنواع صارمة. الأنواع مواصفةٌ يتحقق منها المُترجِم في كل عملية بناء. ومع إنتاج الوكلاء للشيفرة بكميات كبيرة، فإن قيدًا تفرضه الآلة مجانًا هو أرخص مراجعة سنحصل عليها على الإطلاق.
بوابات الجودة (quality gates). فحص الأنواع والتدقيق الآلي (linting) ومجموعة الاختبارات وبناء نسخة الإنتاج تعمل تلقائيًا على كل تغيير، والتغيير الذي يفشل في أيٍّ منها لا يُدمَج. البوابات لا تحلّ محل المراجع، بل تضمن أن ينصرف انتباهه إلى الأسئلة التي لا تستطيع الآلة الإجابة عنها.
توثيق يتغيّر مع الشيفرة. حين يغيّر تعديلٌ سلوكًا أو واجهةً أو إعداداتٍ أو قرارًا في البنية المعمارية، يُحدَّث التوثيق الذي يصفه في التغيير نفسه، لا "لاحقًا". التوثيق القديم يضلّل المهندس التالي، ويضلّل الوكيل التالي أيضًا، لأن الوكلاء يقرؤونه بوصفه سياقًا.

ما نرفضه، ولماذا

هذه أسبابنا الثابتة لإعادة أي تغيير. لا يتعلق أي منها بما إذا كانت الشيفرة قد كتبها إنسان أو وكيل؛ فهي تنطبق على الاثنين. كل ما في الأمر أن الوكلاء يقعون فيها أكثر.

شيفرة لا يستطيع أحد في الفريق شرحها. إن لم يستطع المراجع شرحها، فلن يستطيع أحد صيانتها. هذه قاعدة تحمّل المسؤولية مطبّقة حرفيًا. تدوينتنا عن دَين الفهم تشرح لماذا تصل هذه الفاتورة في السنة الثانية لا في الأسبوع الأول.
تغييرات تنحرف عن البنية المعمارية المتفق عليها. جدول قاعدة بيانات جديد لم يناقشه أحد، أو منطق في الطبقة الخطأ، أو طريق مختصر يخترق حدود وحدة. قد تعمل الشيفرة، لكنها تخرق اتفاقًا مع العميل.
شيفرة بلا اختبارات. لا استثناءات بحجة "إنها مجرد شيفرة ربط". شيفرة الربط هي حيث تفشل التكاملات.
فروقات (diffs) ضخمة لا يمكن مراجعتها. تغيير من ألفي سطر لا يُراجَع، بل يُتصفَّح على عجل. نموذج القدرات من DORA يخصّ العمل على دفعات صغيرة بالذكر باعتباره فعّالًا بشكل خاص مع الذكاء الاصطناعي. نقسّم التغييرات الكبيرة قبل المراجعة، لا بعدها.
دوال مساعدة مكرّرة بدل توسيع الموجودة. يحب الوكلاء كتابة formatDate جديدة بدل العثور على تلك الموجودة. وكل نسخة مكرّرة هي عدم اتساق مؤجَّل.
أخطاء تُبتلع بصمت. كتلة catch فارغة أو مسار بديل يُخفي فشلًا، هكذا ينتهي نظامٌ إلى نتائج خاطئة دون أن يلاحظ أحد. الأخطاء إما تُعالَج عن قصد أو تُظهَر.
تغييرات تترك التوثيق خلفها. إن صارت الشيفرة تفعل شيئًا لا يصفه التوثيق، فالتوثيق خاطئ، والتوثيق الخاطئ أسوأ من غيابه. يعود التغيير حتى يتطابق الاثنان.
تبعيات جديدة لم يخترها أحد. كل حزمة قرارٌ يخص سلسلة التوريد والترخيص والصيانة. وكيلٌ يضيف حزمة لأنها كانت مريحة ليس قرارًا.

لبيانات الحوادث التي تقف خلف هذا الانضباط (معيار Cortex 2026) ولمزيد من تقنيات المراجعة، اطّلع على تدوينتنا السابقة عن انضباط المراجعة.

المقايضات بصراحة

هذه الطريقة في العمل أبطأ لكل طلب سحب من قبول ما يُنتجه الوكيل. ولن نتظاهر بغير ذلك.

تُظهر بيانات القطاع أين تقع الكلفة. في بيانات LinearB، انتظرت طلبات السحب التي أنتجها وكلاء الذكاء الاصطناعي 17.6 ساعة للمراجعة عند المئين 75، مقابل 3.4 ساعات للعمل المُنجز دون مساعدة. المراجعة صارت الآن القيد، والجهة التي تراجع بجدية ستشعر بهذا القيد أكثر، لا أقل. ويضيف استطلاع Stack Overflow (opens in new tab) الجانب الآخر: قال 45.2٪ من المطورين إن تصحيح الشيفرة المولَّدة بالذكاء الاصطناعي يستغرق وقتًا أطول. الوقت الموفَّر في التوليد يُستردّ جزئيًا في التحقق. والفرق التي تتخطّى التحقق ليست أسرع؛ إنها أجّلت الدفع فحسب.

في الوقت نفسه، نرى أنه من غير الصادق التعامل مع الوكلاء كموضة عابرة. تحديث METR لعام 2026 فوضوي، لكن سبب فوضويته كاشف: المطورون باتوا يرفضون بشكل متزايد العمل دون ذكاء اصطناعي. ورأينا أن الوكلاء يساعدون فعلًا في:

الشيفرة المتكررة (boilerplate) والهياكل الأولية داخل بنية قائمة أصلًا،
توليد حالات الاختبار، وخاصة الحالات الحدّية المملّة التي يتخطّاها الإنسان،
إعادة الهيكلة والترحيل الروتينيين وفق قواعد واضحة لما قبل وما بعد،
قراءة شيفرة غير مألوفة وتلخيصها كنقطة انطلاق لإنسان،
رسم مسودة سريعة لنهجين أو ثلاثة بديلة كي يختار المهندس بينها.

لاحظ النمط. الوكلاء في أقوى حالاتهم حيث يكون القرار قد اتُّخذ بالفعل والعمل تنفيذ. وفي أضعفها تمامًا حيث تعيش الأفعال الثلاثة.

ما يكلّفه هذا العميل هو وقت في البداية: ورش عمل لاستخراج القواعد الضمنية، وقرارات للقراءة والاعتماد، ووقت مراجعة يظهر في الخطة. وما يشتريه هو قاعدة شيفرة لكل سطر فيها مالك يستطيع شرحه، وبنية معمارية موثّقة لأنه كان لا بد من الاتفاق عليها، وتوثيق ما زال مطابقًا للشيفرة، وفريق تالٍ، منّا أو من غيرنا، يستطيع تسلّمها. لبرمجيات تُدير عملًا تجاريًا لعقد من الزمن، نرى أن هذه هي المقايضة المعقولة الوحيدة.

ما الذي تسأل عنه أي مورّد برمجيات

إن كنت تشتري برمجيات مخصّصة في 2026، فافترض أن المورّد يستخدم وكلاء الذكاء الاصطناعي. ليس هذا هو السؤال. الأسئلة هي:

من يملك كل سطر؟ اسأل ما إذا كان مهندسٌ محدّد بالاسم يراجع كل تغيير ويستطيع شرحه قبل دمجه. واسأل ماذا يحدث حين لا يستطيع.
أين دُوِّنت قرارات البنية المعمارية؟ اطلب رؤيتها. واسأل ما إذا كنت ستعتمدها قبل بدء التنفيذ.
كيف تكشفون القواعد التي لم يدوّنها أحد؟ أنصت لذكر ورش العمل وقوائم الحالات الحدّية وأسئلة المجال، لا لعبارة "أرسلوا لنا المتطلبات" فقط.
هل الاختبارات والأنواع الصارمة وبوابات الجودة الآلية معيار أساسي أم إضافات؟ إن كانت تُسعَّر كإضافة، فستُسقَط تحت ضغط المواعيد.
هل يُحدَّث التوثيق مع كل تغيير، أم يُكتب مرة واحدة عند التسليم؟ التوثيق المكتوب في النهاية يصف النظام كما يتذكّره أحدهم، لا كما هو فعلًا.
ماذا ترفضون؟ المورّد الذي لا يملك إجابة هنا لا يملك معيار مراجعة؛ بل يملك زر دمج.
ما حجم التغيير المعتاد؟ الزيادات الصغيرة القابلة للمراجعة علامة انضباط. والدفعات الأسبوعية العملاقة علامة على أن أحدًا لم يقرأها.
هل يستطيع فريق آخر تسلّم هذه الشيفرة؟ الإجابة الصادقة تعتمد كليًا على الأسئلة السبعة السابقة.

لا يذكر أيٌّ من هذه الأسئلة الذكاء الاصطناعي، وهذا هو المقصود. الأدوات تغيّرت، أما ما يجعل البرمجيات جديرة بالثقة فلم يتغيّر: شخصٌ فهم المشكلة، وشخصٌ صمّمها عن قصد، وشخصٌ مستعد لوضع اسمه على النتيجة.

افهم، صمّم، راجِع: كيف نتعامل مع الشيفرة المولَّدة بالذكاء الاصطناعي

العمل لم يتقلّص، بل انتقل

افهم: الوكلاء يضخّمون كل ما تعطيهم إياه

صمّم: القرارات المكتوبة هي حواجز الحماية للوكيل

كم ينبغي أن نكتب

راجِع: قواعدنا قبل دمج أي شيء

ما نرفضه، ولماذا

المقايضات بصراحة

ما الذي تسأل عنه أي مورّد برمجيات

قراءات إضافية

مقالة عشوائية، مرّة في الأسبوع.

مقالات ذات صلة

مشكلة الـ23.5٪: لماذا تُنتج طلبات السحب المدعومة بالذكاء الاصطناعي حوادث أكثر

دَين الفهم هو ضريبة الذكاء الاصطناعي الحقيقية

تشغيل منتج على Cloudflare Edge: ما كسبناه، وما تنازلنا عنه