البرمجة بالذكاء الاصطناعي: دور الوكلاء وحدود التفويض

بالنسبة إلى قائد الفريق الهندسي، نقطة البداية العملية هي مهمة محددة النطاق على فرع معزول، بمعايير قبول صريحة، وفحوص آلية، ومراجع محدد بالاسم. وسّع استقلالية الوكيل حين تنتج هذه العملية تغييرات يمكنك قبولها بثقة.

جرى التحقق من سلوك الأدوات الوارد أدناه بالرجوع إلى وثائق مطوّريها المنشورة على الويب في 24 أكتوبر 2026. أما قواعد التفويض ومثال تصدير الفواتير فهي تحليل تحريري، وليست نتائج تجربة عملية للمنتجات.

ما دور الوكلاء في البرمجة بالذكاء الاصطناعي؟

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

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

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

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

بماذا يختلف وكيل البرمجة عن الإكمال التلقائي والدردشة؟

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

الواجهة ليست ما يعرّف الوكيل. يمكن أن يعمل داخل نافذة دردشة أو داخل الطرفية. ما ينبغي النظر إليه هو الأدوات المتاحة، ودورة الاستفادة من النتائج، والصلاحيات الممنوحة للجلسة.

ما الفرق بين البرمجة الوكيلة وVibe Coding؟

تصف البرمجة الوكيلة طريقة عمل الأداة. أما Vibe Coding فيصف عادةً أسلوب عمل يوجّه فيه الشخص البرمجيات المولّدة أساسًا عبر التعليمات النصية والسلوك الذي يلاحظه، وأحيانًا مع قدر محدود من فحص التنفيذ. يتداخل المصطلحان عمليًا، لكن كلًا منهما يجيب عن سؤال مختلف.

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

ما الذي تستطيع أدوات البرمجة الوكيلة إنجازه؟

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

Claude Code

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

العائق العملي هنا هو السياق الناقص أو المنسي. توضّح Anthropic أن نافذة السياق محدودة، وأن السياق يُضغط خلال الجلسات الطويلة. احتفظ بالقيود الدائمة في تعليمات المشروع، واجعل كل تغيير محددًا؛ فالمحادثة الطويلة ليست بديلًا جيدًا لمعيار قبول واضح. يشرح دليلنا عن أفضل ممارسات Claude Code هذا الأسلوب بمزيد من التفصيل.

OpenAI Codex

يوفّر OpenAI Codex، وكيل البرمجة من OpenAI، واجهة سطر أوامر (CLI) تستطيع فحص المستودع، والتخطيط لتغيير، وتعديل الملفات، وتشغيل أوامر التطوير المحلية. كما يوفّر مسارًا مخصصًا لمراجعة تغييرات لم تُسجّل بعد في commit، أو لمراجعة commit، أو للمقارنة مع فرع أساس. وثائق Codex CLI.

العائق العملي هنا هو بيئة التنفيذ. فالفحص الذي يحتاج إلى خدمة غير متاحة أو اتصال بالشبكة تحظره البيئة لا يستطيع تقديم الدليل الذي كنت تنتظره. سجّل أن هذا الفحص لم يُتحقق منه، ثم أعد تنفيذه في البيئة المناسبة. تتناول مقارنة Codex وClaude Code اختيار المنتج؛ أما إعدادات الصلاحيات فتستحق قرارًا مستقلًا.

Cursor Agent

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

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

وكيل البرمجة في GitHub Copilot

يستطيع وكيل البرمجة في GitHub Copilot، الذي تسمّيه الوثائق الحالية Copilot cloud agent، استكشاف المستودع والتخطيط للتغييرات وتعديل الملفات وتشغيل الاختبارات وأدوات الفحص الساكن في بيئة سحابية مؤقتة. ويمكنه إعداد الفروع وعمليات commit وطلبات الدمج. ويختلف ذلك عن تلقي اقتراحات داخل بيئة تطوير متكاملة (IDE)، أو مطالبة Copilot بمراجعة طلب دمج قائم. Copilot على GitHub.com.

العائق العملي هنا هو تسليم العمل للمراجعة. تحذّر GitHub من أن التغييرات المولّدة قد تكون غير دقيقة أو غير آمنة، وأنها تتطلب مراجعة واختبارًا. انتهاء الجلسة يعني وجود عمل ينبغي تقييمه، ولا يعني أن معايير القبول قد تحققت. إرشادات GitHub للاستخدام المسؤول.

لتفاصيل الباقات، راجع صفحات أسعار Claude Code، وأسعار Codex، وأسعار Cursor، وأسعار GitHub Copilot.

سير عمل البرمجة الوكيلة يبدأ بمواصفات قابلة للاختبار

المواصفات المفيدة توضّح للوكيل ما يجب أن يبقى صحيحًا، إلى جانب ما يجب تغييره. عبارة «أضف تصديرًا بصيغة CSV» تترك قرارات حاسمة بلا حسم. فقد ينشئ الوكيل تنزيلًا يعمل، لكنه يطبّق قواعد وصول خاطئة.

لنفترض وجود منتج للفوترة تستخدمه مؤسسات عميلة منفصلة، وأنك تريد تمكين مسؤول الحساب من تصدير الفواتير. ينبغي أن يحدد وصف المهمة المفيد ما يلي:

• النتيجة المطلوبة: يستطيع المسؤول المخوّل تنزيل الفواتير الظاهرة وفق عوامل التصفية الحالية.
• قاعدة الوصول: لا يجوز لأي مؤسسة الحصول على فواتير مؤسسة أخرى، حتى من خلال طلب جرى التلاعب به.
• السلوك الواجب الحفاظ عليه: تظل صلاحيات الفواتير وآلية تصفيتها الحاليتان المرجع المعتمد.
• النطاق: إعادة استخدام أنماط التحقق من الصلاحيات والتصدير الموجودة، وتجنّب إعادة هيكلة أو إضافة اعتماديات لا صلة لها بالمهمة.
• أدلة التحقق: عرض حالات السماح والرفض، ومحاولة وصول إلى بيانات مؤسسة أخرى، ونتيجة فارغة، والفحوص الحالية ذات الصلة.
• شرط التوقف: طلب قرار إذا كانت سياسة الوصول غامضة، أو إذا استلزم الإصلاح تغيير السلوك المشترك للتحقق من الصلاحيات.

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

توصي وثائق أفضل الممارسات من Anthropic بتزويد الوكيل بطريقة للتحقق من عمله. ويؤكد Armin Ronacher، في توصياته المستندة إلى الممارسة، أهمية الأدوات السريعة والمفهومة والسجلات المفيدة. والدرس العملي هو جعل الإخفاقات قابلة للرصد: رسالة واضحة عن فشل التحقق من الصلاحيات تساعد الوكيل على تصحيح عمله، بينما لا يمنحه الأمر العالق توجيهًا يُذكر.

الصلاحيات والعزل يضبطان حدودًا مختلفة

تحدد الصلاحيات الإجراءات المسموح بها، ويحدّ العزل من مدى تأثيرها، وتضبط قواعد الفروع والمراجعة قبول العمل. اضبط هذه الجوانب كلها. فتعليمة تقول «لا تلمس بيئة الإنتاج» لا تُغني عن حجب الوصول إليها.

تحدد سياسة الموافقة الإجراءات التي تحتاج إلى إذن. أما البيئة المعزولة (sandbox) فتفرض حدودًا للتنفيذ على موارد مثل الملفات القابلة للكتابة والوصول الصادر إلى الشبكة. ولا يقيّم أي منهما ما إذا كان تصدير الفواتير يلتزم بقواعد عمل منتجك.

تحقّق من الإعدادات الفعلية لكل أداة

في Claude Code، توثّق Anthropic عزل نظام الملفات والشبكة للأوامر المشغّلة داخل البيئة المعزولة، بما يشمل عملياتها الفرعية. وتوثّق أيضًا آلية لإعادة المحاولة خارج العزل. راجع مسار الخروج هذا، والأوامر المستثناة، وما يحدث عند تعذّر بدء العزل، قبل اعتبار هذه الحدود إلزامية. فتقييد الكتابة لا يعني تلقائيًا تعذّر قراءة الملفات الحساسة. العزل في Claude Code.

في Codex CLI، يتيح workspace-write مع سياسة الموافقة on-request العمل داخل مساحة العمل، بينما يكون وصول الأوامر إلى الشبكة معطّلًا افتراضيًا ما لم يُفعّل. سياسة الموافقة ووضع العزل إعدادان منفصلان: تعطيل طلبات الموافقة لا يزيل العزل بحد ذاته. كذلك، لا تتحكم سياسة شبكة الأوامر وحدها في البحث المستضاف على الويب، أو التطبيقات، أو اتصالات MCP التي تصل الوكيل بأدوات وخدمات خارجية. راجع مسارات الوصول هذه كلًا على حدة. الموافقات والأمان في Codex.

في Cursor Agent، تتطلب أوامر الطرفية موافقة افتراضيًا، بينما تُوصف أوضاع التشغيل القابلة للضبط، Run Modes، بأنها ضوابط تبذل أفضل جهد ممكن، وليست حدودًا أمنية صارمة. يهم هذا الفرق إذا كنت تنوي ترك الأوامر تعمل دون إشراف. وضع في الحسبان أيضًا التحذير السابق بشأن إعادة التحميل التلقائي، إلى جانب التنفيذ عبر الطرفية. أمان Cursor Agent.

في GitHub Copilot cloud agent، توثّق GitHub صلاحيات مقيّدة للفروع تمنع الدفع المباشر إلى الفرع الافتراضي. وتوثّق أيضًا جدار حماية افتراضيًا، واشتراط موافقة مستخدم يملك صلاحية الكتابة قبل تشغيل مسارات Actions التي تطلقها طلبات الدمج الخاصة بالوكيل. لا تُمرّر إلى الوكيل أسرار Actions العامة على مستوى المستودع والمؤسسة؛ أما الأسرار المضافة خصيصًا إلى بيئة copilot فتُمرّر إليه. راجع ما تضعه فيها. الضمانات الموثقة لدى GitHub.

اجعل حدود الوصول مناسبة للمهمة

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

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

مراجعة العمل: افحص التغييرات وأدلة صحتها

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

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

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

من نسخة عمل للمستودع تحتوي على تغييرات لم تُسجّل في commit، تتيح أوامر Git التالية فحصًا أساسيًا:

git status --short
git diff --stat
git diff --check
git diff
git diff --cached

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

يتضمن التسليم المفيد الأوامر المنفّذة بدقة، ونتائجها، والمخرجات ذات الصلة التي تبيّن النجاح أو الفشل، وأي فحص تعذّر تشغيله. قول «الاختبارات ناجحة» دون تحديدها يترك المراجع يخمّن مدى التغطية. وفشل إعداد البيئة عائق أمام جمع الدليل، وليس دليلًا على أن الشيفرة تعمل.

يدعو Drew Breunig إلى اختبار سلوك المنتج، وتوثيق المقصود منه، وتطوير المواصفات مع التنفيذ في مقاله 10 دروس في البرمجة الوكيلة. وعند تطبيق ذلك هنا، يكون الفحص الذي ينبغي الحفاظ عليه هو التأكد من أن العميل لا يستطيع تصدير فواتير عميل آخر. أما الدالة المساعدة المستخدمة لفرض هذه القاعدة فيمكن أن تتغيّر.

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

من يمكنه توسيع التفويض، ومن الأفضل أن يتريّث؟

وسّع التفويض عندما تكون للمهمة نتيجة نجاح واضحة، ويمكن احتواء أخطائها، وتظل مراجعتها قابلة للإدارة. ما يلي سياسة هندسية مقترحة، وليس ضمانًا لقدرات أي منتج من جهة مورّدة.

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

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

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

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

أين تتعثر البرمجة الوكيلة، وما الذي يُبالغ في تقديره؟

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

يفرض السياق حدًا آخر. فقد يرى الوكيل الدالة المعنية، لكنه لا يدرك سبب وجود قيد غير مألوف. دوّن القرارات المؤثرة بالقرب من موضع العمل، وحدّد المواصفات المعتمدة، واطلب إظهار مواطن عدم اليقين. تشرح وثائق Anthropic كيفية إدارة السياق المحدود في الجلسات الطويلة؛ فلا تفترض أن تعليمة مبكرة في المحادثة ستظل حاضرة بالوضوح نفسه طوال تغيير كبير. كيف يعمل Claude Code.

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

أما الإخفاق الأوسع فهو قبول تعقيد لم يكن أحد ينوي صيانته. فأي طبقة تجريد أو اعتمادية أو مهمة تعمل في الخلفية تضيفها تصبح مسؤوليتك التشغيلية، حتى لو كان توليدها سهلًا. اسأل ما إذا كان التغيير يحل المهمة بقدر مناسب من المكونات الجديدة.

ما الذي لا تثبته اختبارات الأداء المعيارية للبرمجة الوكيلة؟

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

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

وسّع التفويض عندما يصبح تسليم العمل المقبول أسهل، دون زيادة غير مقبولة في عبء المراجعة أو العيوب. وإذا أصبح إنتاج التعديلات أسرع بينما صار فهمها أصعب، فقلّص النطاق وحسّن أدلة التحقق.

أسئلة شائعة

خطوة عملية لبداية الأسبوع

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

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

للحصول على ملاحظات عملية عن البناء بالذكاء الاصطناعي، اشترك في النشرة البريدية.