لسنوات، كان الذكاء الاصطناعي يجلس بجانبك في المحرر ويتوقع ما سيأتي بعد ذلك. كنت تكتب سطرًا؛ فيقترح السطر التالي. كنت لا تزال تملك البنية التحتية، وتصحيح الأخطاء، والقواعد البرمجية. هذا الترتيب قد انتهى.
نحن ننتقل إلى "التطوير القائم على النوايا" (Intent-Driven Development). ستتوقف عن كتابة الحلقات (loops) والجمل الشرطية (conditionals). بدلاً من ذلك، ستصف النتيجة التي تريدها. يستوعب الوكيل (agent) هذا الهدف، ويخطط للخطوات، ويكتب الكود، ويشغل الاختبارات، ويصلح أخطاءه بنفسه قبل أن ترى النتيجة حتى. لم تعد لوحة المفاتيح هي الأداة الأساسية، بل التفكير الواضح.
نهاية البرمجة سطرًا بسطر
كانت سير العمل القديمة تجبرك على ترجمة كل نية إلى لغة محددة يفهمها المترجم (compiler). كنت تحمل متطلبات العمل في رأسك، ثم تقوم يدويًا بتفكيكها إلى دوال (functions)، واستيرادات (imports)، ومعالجة أخطاء، وحالات اختبار. "التطوير القائم على النوايا" يقلص طبقة الترجمة هذه.
لنفترض أنك بحاجة إلى دمج Stripe webhook. سابقًا، كنت ستكتب معالج المسار (route handler)، وتحلل الحمولة (payload)، وتتحقق من التوقيع، وتحدث قاعدة البيانات داخل عملية (transaction)، وتضع بريد الإيصال في قائمة الانتظار. الآن تصف المتطلب: "تحقق من Stripe webhook الوارد، وسجل الحدث بشكل متماثل (idempotently)، وقم بتشغيل تدفق الإيصال. تراجع عن العملية إذا فشلت عملية الكتابة في قاعدة البيانات". يكتب الوكيل المعالج، ويختار استراتيجية التحليل، وينظم منطق إعادة المحاولة (retry logic)، وينشئ الاختبارات. يتحول دورك من مؤلف إلى مخرج.
هذا لا يعمل إلا لأن الوكيل لا يتوقف عند مرحلة التوليد، بل يدخل في حلقة (loop).
داخل حلقة الوكيل (Agent Loop)
لم يعد العمل الأساسي هو الكتابة البشرية أو تصحيح الأخطاء يدويًا. بل هو دورة ضيقة بين التوليد والتحقق. ينتج الوكيل الكود، وينفذه مقابل مجموعة الاختبارات الخاصة بك، ويقرأ المخرجات، ويصلح الإخفاقات بنفسه. استيراد مفقود، عدم تطابق في الأنواع (type mismatch)، فشل في التأكيد (assertion) — يرى الوكيل تتبع المكدس (stack trace)، ويعدل الملف، ويعيد تشغيل المجموعة. أنت لست جزءًا من هذه الحلقة؛ فالدورة تسير بسرعة الآلة.
تتدخل عندما تنكسر الحلقة نفسها. ربما لا يستطيع الوكيل حل تعارض بين تبعيتين (dependencies)، أو يستمر في توليد كود يجتاز اختبارات الوحدة (unit tests) ولكنه ينتهك قاعدة عمل رفيعة المستوى. هذه الحدود هي المكان الذي لا تزال فيه الأحكام البشرية مهمة.
وظيفتك الحقيقية: مصمم قيود وصائد حالات استثنائية
إذا كانت الآلة تكتب الدوال، فماذا يتبقى لك؟ شيئان، وهما أصعب من كتابة القواعد البرمجية.
أولاً، تكتب القيود التي تبقي الوكيل على المسار الصحيح. يمتلك الوكيل معرفة واسعة ولكن ليس لديه فهم لبيئتك الخاصة. يجب أن تخبره: "استخدم فقط واجهة برمجة تطبيقات الفواتير الداخلية (internal billing API)، ولا تسجل أبدًا رموز البطاقات الخام (raw card tokens)، وحافظ على زمن استجابة أقل من مائتي مللي ثانية". هذه الحدود ليست مجرد أوامر (prompts) عابرة، بل هي مواصفات تحدد النجاح أو الفشل.
ثانيًا، تلتقط الـ 10% من الحالات التي يفشل فيها الوكيل. يتعامل الوكلاء مع المسارات الشائعة بشكل جيد، لكنهم يتعثرون في حالات السباق (race conditions) الدقيقة، وحالات المنطق التجاري الغامضة، والافتراضات الأمنية المضمنة في بيانات تدريبهم. تكمن ميزتك في رصد السباق بين معالج الـ webhook ومهمة الـ cron الخاصة باسترداد الأموال، أو إدراك أن منطق إعادة المحاولة المولد قد يؤدي إلى تكرار الرسوم. الآلة تحل المشكلة القياسية، وأنت تلتقط الاستثناء الخطير.
استبدل مراجعة الكود بإطار تحقق (Verification Harness)
عندما يتمكن الوكيل من إنتاج خمسين ملفًا بين عشية وضحاها، لا يمكنك مراجعتها عبر تصفح الفروقات (diffs) لترى ما إذا كانت "تبدو صحيحة". الحجم يجعل الفحص البشري مستحيلاً. أنت بحاجة إلى إطار تحقق (harness) يلتقط الأخطاء قبل أن يصل الكود إليك.
يعتمد هذا الإطار على ثلاث ركائز:
التنفيذ المستدام (Durable execution). غالبًا ما تستغرق مهام الوكيل وقتًا أطول من مهلة طلب واحد. إذا فشلت خطوة بسبب انقطاع مؤقت في الشبكة، يقوم الإطار بالإيقاف المؤقت، وإعادة المحاولة، والاستئناف دون إفساد الحالة (state). العمل يصمد أمام الانقطاع.
المخرجات المهيكلة (Structured outputs). بدلاً من الأمل في أن يعيد الوكيل ملف تهيئة (configuration file) جيد التنسيق، أنت تفرض العقد (contract) مسبقًا. أدوات مثل JSON Schema تتحقق من المخرجات فورًا. إذا أغفل الوكيل حقلًا مطلوبًا أو استخدم نوع بيانات خاطئًا، يرفضه الإطار قبل أن يلمس الكود مستودعك (repository).
الحواجز الوقائية الديناميكية (Dynamic guardrails). لا ينبغي أن يتمتع الوكيل بحرية مطلقة لقراءة الأسرار أو الكتابة في قواعد بيانات الإنتاج. يتحكم الإطار في الأذونات ديناميكيًا، حيث يضع الوكيل في بيئة معزولة (sandboxing) بحيث لا يمكنه لمس سوى قواعد بيانات الاختبار المخصصة ونقاط النهاية (endpoints) الداخلية. أنت لا تراجع كل سطر، بل تدقق في السياج المحيط بالوكيل.
عندما يعمل الكود ولكن يفشل المنتج
إليك المفارقة: إطار الاختبار يكتشف الكود السيئ، لكنه لا يستطيع اكتشاف النية السيئة.
إذا كانت مواصفاتك تقول: "أرسل بريداً إلكترونياً ترحيبياً لكل مستخدم جديد"، فسيقوم الوكيل بكتابة كود نظيف ومختبر يرسل ذلك البريد. لكنه لن يدرك أنك كنت تقصد: "أرسل البريد الترحيبي فقط إذا قام المستخدم بتأكيد عنوانه، واشترك في التسويق، وسجل خلال ساعات العمل في منطقته الزمنية المحلية". الكود سيكون خالياً من العيوب تقنياً، ولكنه خطير تجارياً.
الخطر الحقيقي في "التطوير القائم على النية" (Intent-Driven Development) هو المواصفات الغامضة. فالنية غير الواضحة تنتج برمجيات تحل المشكلة الخاطئة بأناقة نموذجية. لهذا السبب، يجب أن تتعامل مع مواصفاتك كأصول حقيقية؛ قم بإدارة إصداراتها، وراجعها مع أصحاب المصلحة، وتحقق من صحتها مقابل سير العمل الفعلي قبل أن يبدأ الوكيل في البناء. إن الأمر (prompt) المكتوب على عجل في صندوق الدردشة ليس مواصفات، بل هو مصدر خطر.
الحكم الهندسي ينتقل إلى مرحلة أبكر
الحكم الهندسي لا يختفي، بل ينتقل إلى مستوى أعلى.
لم تعد تستهلك طاقتك الذهنية في كيفية تكرار خريطة أو هيكلة تسلسل الفئات (class hierarchy). بل أصبحت تستهلكها في تحديد ما يجب أن يفعله النظام عند الفشل، وما هي البيانات التي يجب ألا يكشفها أبداً، وما هي الثوابت (invariants) التي يجب أن تظل قائمة عبر الخدمات الموزعة. إن حرفة البرمجة تتحول لتصبح حرفة صياغة المتطلبات.
هذا يعني أن مواصفاتك تحتاج إلى نفس الصرامة التي كنت تطبقها سابقاً على الكود الخاص بك. حدد قيودك بدقة، وعرّف أنماط الفشل بوضوح، واذكر قواعد العمل بوضوح كما كنت تعرّف أنواع البيانات (types) سابقاً. سيتولى الوكيل عملية التنفيذ، لكن يجب عليك ضمان أن هذا التنفيذ يستحق البناء.
انقل معيار الجودة الخاص بك من "طلب السحب" (pull request) إلى "الأمر" (prompt). ابنِ إطار الاختبار أولاً، ثم اكتب المواصفات ثانياً. بعد ذلك، اترك الآلة تتعامل مع بناء الجملة (syntax) بينما تركز أنت على ما إذا كانت المشكلة محددة بشكل صحيح والحدود مرسومة بأمان.
إذا كنت ترغب في استكشاف الأفكار الكامنة وراء هذا التحول بعمق أكبر، فإن المناقشة الأصلية حول "التطوير القائم على النية" متاحة هنا. وللمشاركة في المحادثات المستمرة حول الهندسة القائمة على الذكاء الاصطناعي (AI-native engineering)، يمكنك أيضاً الانضمام إلى مجتمع GyaanSetu.