مقدمة
لم يعد استخدام الذكاء الاصطناعي في البرمجة مجرد تجربة جانبية أو وسيلة لكتابة كود أسرع. بالنسبة لي، أصبح الذكاء الاصطناعي جزءًا من طريقة العمل نفسها، لكن ليس بالشكل التقليدي الذي يعتمد على أداة واحدة تطلب منها بناء النظام بالكامل من البداية للنهاية.
أنا أتعامل مع الذكاء الاصطناعي كفريق عمل، وليس كأداة واحدة تقوم بكل شيء. الفكرة الأساسية عندي هي توزيع الأدوار بين أكثر من نموذج أو مساعد ذكي، بحيث أستفيد من قوة كل واحد في المكان المناسب، وأقلل استهلاك التوكينز، وأحافظ في نفس الوقت على جودة المشروع واستمرارية السياق.
لماذا لا أعتمد على AI واحد فقط؟
في المشاريع الكبيرة، الاعتماد على ذكاء اصطناعي واحد للتخطيط والتنفيذ والمراجعة داخل محادثة طويلة غالبًا يؤدي إلى مشاكل كثيرة. المحادثة تكبر، السياق يتداخل، القرارات القديمة تختلط بالتعديلات الجديدة، والتوكينز تُستهلك بسرعة في تفاصيل تنفيذية كان ممكن فصلها.
لذلك أفضل أن أتعامل مع الذكاء الاصطناعي كأنه خط إنتاج برمجي. هناك جهة تخطط، وجهة تنفذ، وجهة تراجع وتصلح. وبهذا الشكل لا يكون التنفيذ عشوائيًا، ولا يبدأ كل AI من الصفر في كل مرة.
البداية: فهم المنتج قبل كتابة الكود
أول خطوة عندي ليست كتابة الكود، بل شرح فكرة السيستم أو الموقع بشكل واضح. أبدأ بتحديد الهدف التجاري من المشروع، من هم المستخدمون، ما المشكلة التي يحلها النظام، وما القيمة التي يقدمها.
هذا الجزء مهم جدًا، لأن الذكاء الاصطناعي إذا لم يفهم المنتج سيقترح حلولًا عامة. أما عندما تكون الصورة واضحة من البداية، تصبح القرارات التقنية مرتبطة بالواقع الفعلي للمشروع، وليس بمجرد قوالب جاهزة.
فحص المشروع الحالي قبل اقتراح التنفيذ
بعد شرح الفكرة، لا أطلب من Codex أن يبدأ التنفيذ مباشرة. أول طلب يكون دائمًا أن يفحص المشروع الحالي كما هو. يقرأ الملفات، قاعدة البيانات، التوثيق، المسارات، التقنيات المستخدمة، وطريقة تنظيم الكود.
الهدف هنا أن تكون الخطة مبنية على الواقع، لا على افتراضات عامة. كثير من الأخطاء تحدث لأن الـAI يقترح حلًا جيدًا نظريًا، لكنه لا يناسب بنية المشروع الحالية أو يتعارض مع ملفات موجودة بالفعل.
استخدام Codex كـ Software Architect
بعد الفحص، أتعامل مع Codex كمهندس برمجيات أو Software Architect. دوره في هذه المرحلة ليس كتابة كمية كبيرة من الكود، بل تحليل المتطلبات واتخاذ قرارات صحيحة.
أطلب منه أن يحلل المطلوب، يقترح المعمارية المناسبة، يحدد الموديولات، يوضح العلاقات بينها، يرتب الأولويات والاعتماديات، ويكتشف المخاطر أو التعارضات قبل أن يبدأ أي تنفيذ.
هذه المرحلة تقلل كثيرًا من المشاكل لاحقًا، لأن الأخطاء المعمارية تكون مكلفة جدًا إذا تم اكتشافها بعد كتابة جزء كبير من الكود.
تقسيم المشروع إلى أجزاء صغيرة
بدل تنفيذ المشروع كله مرة واحدة، أقوم بتقسيمه إلى أجزاء صغيرة وواضحة. كل جزء يكون له هدف محدد، ملفات متوقعة، شروط قبول، واختبارات أو أوامر تحقق مطلوبة.
هذا التقسيم يجعل كل مهمة قابلة للمراجعة والقياس. إذا فشل جزء، يكون من السهل معرفة مكان المشكلة وإصلاحها، بدل أن يتحول المشروع إلى كتلة كبيرة من التغييرات غير المفهومة.
كتابة Prompt تنفيذي دقيق
بعد تحديد الجزء المطلوب، أطلب من Codex كتابة Prompt تنفيذي كامل للمرحلة الحالية. هذا البرومبت غالبًا يكون باللغة الإنجليزية وجاهزًا للنسخ واللصق في AI آخر.
البرومبت لا يكون مجرد وصف عام، بل يحتوي على حالة المشروع الحالية، الملفات والمسارات المرتبطة، القيود المعمارية، قواعد البزنس، الحالات الطرفية، متطلبات الأمان والصلاحيات، الاختبارات وأوامر التحقق، والأشياء الممنوع تغييرها خارج نطاق المهمة.
بهذا الشكل، لا أترك الـAI المنفذ يقرر كل شيء من جديد. هو يستلم مهمة واضحة، بحدود واضحة، وهدف واضح.
AI للتنفيذ وCodex للتخطيط والمراجعة
بعد تجهيز البرومبت، أرسله إلى AI آخر ليقوم بكتابة الكود. هنا يكون دور الـAI الثاني هو التنفيذ فقط، بينما يظل Codex هو المخطط والمراجع وحافظ السياق.
هذه النقطة مهمة جدًا في تقليل استهلاك التوكينز. الجزء الأكثر استهلاكًا غالبًا هو كتابة كمية كبيرة من الكود، لذلك أعطيه إلى AI منفذ، بينما أحتفظ بـCodex للمهام التي تحتاج فهمًا عميقًا للمشروع واتخاذ قرارات دقيقة.
بعد التنفيذ: المراجعة ليست قائمة ملاحظات فقط
عندما ينتهي التنفيذ، لا أتعامل مع النتيجة باعتبارها النسخة النهائية. أول تنفيذ بالنسبة لي هو مسودة عملية تحتاج إلى مراجعة وتقوية.
أرجع إلى Codex بملخص التنفيذ أو بالتغييرات الفعلية، وأطلب منه أن يراجع ويصلح المشاكل. المراجعة عندي لا تعني مجرد Code Review أو قائمة ملاحظات، بل مراجعة عملية تشمل فحص الكود الحقيقي، مقارنة التنفيذ بالبرومبت والخطة، اكتشاف الأخطاء والثغرات، مراجعة الصلاحيات وعزل البيانات، مراجعة قاعدة البيانات والعلاقات، التأكد من صحة قواعد البزنس، فحص الحالات الطرفية، وتشغيل الاختبارات المتاحة.
إذا كانت هناك مشكلة يمكن إصلاحها مباشرة، أطلب منه إصلاحها وليس فقط الإشارة إليها.
تتبع المشكلة من المصدر الحقيقي
عند ظهور خطأ، لا أعتمد على رسالة الخطأ فقط. أطلب من Codex تتبع المسار الحقيقي داخل المشروع: من الواجهة أو الـRoute، إلى الـController أو الـAction أو الـService، ثم إلى قاعدة البيانات والاختبارات.
هذه الطريقة تساعد على فهم السبب الحقيقي للمشكلة، وليس علاج العرض الظاهر فقط. أحيانًا يكون الخطأ في الواجهة، وأحيانًا في الصلاحيات، وأحيانًا في استعلام قاعدة البيانات أو في افتراض خاطئ داخل قواعد البزنس.
بناء البرومبت التالي على الحالة الفعلية
بعد نجاح الجزء الحالي، لا أعود إلى الخطة القديمة كما هي. أطلب من Codex كتابة برومبت الجزء التالي بناءً على الحالة الفعلية للمشروع بعد التنفيذ والمراجعة.
هذا يجعل كل مرحلة مرتبطة بما تم إنجازه فعلًا، وليس بما كان متوقعًا في بداية المشروع. ومع الوقت، يتحول المشروع إلى سلسلة خطوات واضحة: تخطيط، برومبت تنفيذي، تنفيذ بواسطة AI آخر، مراجعة وإصلاح بواسطة Codex، تحقق واختبارات، ثم برومبت للجزء التالي.
تثبيت قواعد عامة من بداية المشروع
لكي لا أكرر نفس التعليمات في كل مرة، أثبت قواعد عامة للمشروع من البداية. هذه القواعد تشمل التقنيات والإصدارات المطلوبة، أسلوب تنظيم الكود، مكان قواعد البزنس، معايير الأمان والصلاحيات، قواعد الواجهة وتجربة المستخدم، اللغة واتجاه التصميم، متطلبات الاختبارات، منع استخدام APIs قديمة، وعدم تعديل أي جزء خارج نطاق المهمة.
كما أؤكد دائمًا على الحفاظ على السلوك الحالي للمشروع، إلا إذا طلبت تغييره صراحة. هذه القاعدة تمنع كثيرًا من التغييرات الجانبية التي قد تبدو صغيرة لكنها تكسر أجزاء أخرى من النظام.
ترتيب التنفيذ في المشاريع الكبيرة
في المشاريع الكبيرة، أفضل أن يبدأ التنفيذ من الأساسيات. أبدأ بتحليل المنتج والمتطلبات، ثم تصميم قاعدة البيانات، ثم المستخدمين والصلاحيات، ثم الـBackend وقواعد البزنس، وبعد ذلك لوحة الإدارة والعمليات الداخلية، ثم التقارير، وتأتي الواجهات العامة في مرحلة لاحقة.
هذا الترتيب يجعل النظام يبنى على أساس قوي. الواجهة مهمة، لكنها لا يجب أن تسبق فهم البيانات والصلاحيات وقواعد العمل الأساسية.
ما المشاكل التي تكشفها دورة المراجعة؟
دورة المراجعة بعد التنفيذ تكشف مشاكل كثيرة لا تظهر من أول نظرة. مثلًا قد يكون التنفيذ شكله صحيحًا لكنه يخالف قواعد البزنس، أو تكون الصلاحيات مطبقة في الواجهة فقط، أو تكون الاستعلامات لا تعزل بيانات المؤسسات بشكل صحيح.
كذلك قد تظهر تغييرات جانبية خارج نطاق المهمة، أو كود يعمل في الحالة المثالية فقط، أو اختبارات ناقصة، أو استخدام APIs قديمة، أو اختلاف بين التنفيذ وبنية المشروع الحالية.
لهذا لا أتعامل مع أول نتيجة من الذكاء الاصطناعي كنسخة نهائية. الجودة تأتي من الدورة الكاملة: تنفيذ، مراجعة، إصلاح، تحقق.
أهمية وجود مصدر حقيقة داخل المشروع
من أهم القواعد التي أحافظ عليها وجود مصدر حقيقة داخل المشروع. هذا قد يكون ملفات توثيق، مخطط قاعدة بيانات، خطة موديولات، أو سجل بالقرارات المهمة.
لكن التوثيق لا يتم تحديثه قبل التأكد من التنفيذ. الأفضل أن يتم تحديث التوثيق بعد نجاح الكود ومراجعته، حتى لا يصبح المشروع مبنيًا على وثائق جميلة لكنها لا تعبر عن الواقع.
فوائد هذا الوورك فلو
هذا الأسلوب يمنحني أربع فوائد أساسية. أولًا، جودة أعلى بسبب الفصل بين التخطيط والتنفيذ والمراجعة. ثانيًا، استهلاك أقل للتوكينز لأن المهام الثقيلة يتم توزيعها بذكاء. ثالثًا، سهولة استبدال الـAI المنفذ بدون فقد سياق المشروع. رابعًا، إمكانية بناء نظام كبير خطوة بخطوة بدون أن تتحول المحادثة إلى تعليمات ضخمة ومتشابكة.
الميزة الأكبر أن كل AI يعمل في دوره. Codex لا يُستهلك في كتابة كل تفاصيل الكود، والـAI المنفذ لا يقرر معمارية المشروع من الصفر، وأنا أبقى مسؤولًا عن توجيه الدورة واتخاذ القرار النهائي.
الخلاصة
أنا لا أطلب من الذكاء الاصطناعي ببساطة: ابني لي سيستم. هذه الطريقة غالبًا تؤدي إلى نتائج عشوائية أو صعبة الصيانة.
بدلًا من ذلك، أبني خط إنتاج برمجي يعتمد على توزيع الأدوار: مهندس يخطط، منفذ يكتب الكود، ومراجع يختبر ويصلح. وبين كل مرحلة وأخرى يوجد تحقق وتوثيق وتحديث للحالة الفعلية للمشروع.
بهذا الشكل يصبح الذكاء الاصطناعي شريكًا حقيقيًا في بناء البرمجيات، وليس مجرد أداة تكتب كودًا بسرعة. السر ليس في استخدام AI واحد قوي، بل في تصميم وورك فلو ذكي يجعل كل أداة تعمل في المكان المناسب.