خمسة قرارات هندسية يجب اتخاذها قبل توليد الكود بالذكاء الاصطناعي

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

البرمجة بالانطباع مقابل العمل الهندسي

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

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

بالنسبة لنموذج أولي (prototype)، قد يكفي التحقق البصري. أما بالنسبة لخدمة تضم مستخدمين فعليين، فإن طلب «أضف ميزة أخرى» يُعدِّل بالفعل نظامًا عاملًا، ولا تنحصر تكلفته في زمن التوليد.

خمسة قرارات قبل السطر الأول من الكود

1. التكاملات: تحديد حدود العقد الخارجي

في منتج قائم ومُستخدَم، يتجلى هذا غالبًا في ثلاث خدمات منفصلة: الخدمة A تستقبل البيانات من المزوّد، والخدمة B تُنفّذ قاعدة العمل، والخدمة C تعرض النتيجة. فإذا تسرّبت الصيغة الخارجية إلى الأجزاء الثلاثة جميعها، فإن ظهور مزوّد جديد يعني تعديل A و B و C في الوقت نفسه. وإذا كانت الخدمة A تحوّل البيانات إلى عقد داخلي، فإن مزوّدًا جديدًا يعني فقط محوّلًا (adapter) جديدًا، دون أن تتغيّر B أو C.

مثال: كتالوج ألعاب من مصدرين. يصف المصدر الأول اللعبة بصيغة `{id, name}`، ويصفها المصدر الثاني بصيغة `{code, title}`. النهج الخاطئ هو أن يعرف المستهلكون الصيغتين معًا ويختاروا الحقل حسب نوع المصدر. فكل مزوّد جديد يضيف فرعًا جديدًا في كل دالة، وبعد سنة لن يستطيع أحد تحديد عدد المواضع التي يجب تعديلها. أما النهج الصحيح، فهو أن تُحوِّل المحوّلات البيانات إلى عقد مشترك `{key, title}`، بحيث لا يعرف المستهلكون شيئًا عن المزوّد. ولا يتطلب ربط مصدر جديد إعادة فحص النظام بأكمله (regression).

2. المنصة متعددة العلامات التجارية: تحديد حدود التغاير

كانت كل علامة تجارية على المنصة منتجًا مستقلًا، لا نسخة من قالب بشعار مختلف. وكان لكل منها ترخيصها وأسواقها وفرق منتجها وجداول إصداراتها الخاصة. كان مطلوبًا تطوير جميعها على قاعدة كود واحدة، مع الحفاظ على الاختلافات الحقيقية. بدا النموذج الأولي كافيًا: سمة (theme) أساسية، تُعاد تعريفها لعلامة تجارية معيّنة. لكن إعادة التعريف تجاوزت نطاق الألوان. فقد كانت المهمة الواحدة تُحلّ بطرق مختلفة في مواضع متعددة، وتراكمت الخصوصيات المحلية، وفقد التنسيق تماسكه العام. لذلك تعيّن الانتقال إلى وظائف SCSS المساعدة (mixins) التي تُحلّ مساراتها في سياق العلامة التجارية أثناء البناء (build). وقد ثبت أن هذا الانتقال، بالنسبة لمنتجات قائمة فعليًا، كان أكثر تكلفة من اختيار النموذج المناسب منذ البداية مباشرة.

3–5. العمليات التنافسية، البنية الطوبولوجية، وضمانات التسليم

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

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