تصميم البرمجيات بالذكاء الاصطناعي أولاً من المبادئ الأولية: دليل الممارس
تبنّت معظم الفرق الذكاء الاصطناعي دون مراجعة افتراض واحد تحته، ولهذا صار الناتج أسرع وصارت الأنظمة أسوأ.
إليك السؤال الذي لم تقله معظم فرق الهندسة بصوت عالٍ بعد: إذا كان النموذج يستطيع كتابة الشفرة، فبماذا يُفترض أن نكون بارعين الآن بالضبط؟
الأجوبة التي أسمعها دفاعية في معظمها. هندسة التوجيهات. ومراجعة ناتج الذكاء الاصطناعي. ومعرفة أي أداة تمدّ يدك إليها. كلها مهارات حقيقية، وكلها لاحقة للتحول الفعلي، ولا شيء منها يفسّر ما أراه في الممارسة دائماً: فرق تبنّت الأدوات نفسها في الربع نفسه بالنماذج نفسها، وانتهت في أماكن مختلفة تماماً. مجموعة تطلق أسرع والبرمجية تصمد. والأخرى تطلق أسرع وتنفق الربع التالي في معرفة ما كسرته.
الأدوات نفسها. ونتائج معاكسة. وذلك الفرق ليس عن النموذج.
المكبّر الذي لم يحسبه أحد
وضع تقرير DORA لعام 2025 عن حال تطوير البرمجيات المدعوم بالذكاء الاصطناعي أرقاماً لهذا. فتسعون بالمئة من العاملين في التقنية يستخدمون الذكاء الاصطناعي في العمل الآن، وأكثر من ثمانين بالمئة يعتقدون أنه رفع إنتاجيتهم. وكلا الأمرين غير مفاجئ. والنتيجة المهمة هي الثالثة: ارتفاع استخدام الذكاء الاصطناعي مرتبط بارتفاع معدل تسليم البرمجيات وارتفاع عدم استقرار التسليم، في الوقت نفسه.
اقرأ هذا مرة أخرى، فهذه هي الحجة كلها. لقد جعلت الأداة الفرق أسرع في الإطلاق وأسوأ في إبقاء الأمور تعمل. لا هذا أو ذاك. الاثنان.
وصياغة DORA أن الذكاء الاصطناعي مكبّر: يضخّم أي ممارسة يهبط عليها. فالأنظمة القوية تصبح أقوى. والأنظمة الضعيفة تصبح أسرع في ضعفها.
أي أن السؤال المثير لم يكن قط «كيف نتبنّى الذكاء الاصطناعي». كان «ماذا يكبّر الذكاء الاصطناعي فينا». والإجابة عليه تطلب الرجوع أبعد من أي قرار عن أداة.
استدل من المشكلة لا من الأداة
التفكير من المبادئ الأولية من العبارات التي كُرِّرت حتى فقدت معناها، فلأكن محدداً في ما أعنيه به وما لا أعنيه.
الاستدلال بالتناظر هو ما بدا عليه معظم تبنّي الذكاء الاصطناعي. كان لدينا مسار عمل تطوير. وجاءت قدرة جديدة. فسألنا أين تستقر القدرة في المسار، وأضفناها في نقطة أقل مقاومة، عادة كتابة الشفرة، وأبقينا كل شيء آخر كما هو. الاجتماعات الواقفة والتذاكر ودورات العمل والمراجعة، كلها محفوظة. عُومل المسار كمعطى وضُبطت الأداة عليه.
والاستدلال من المبادئ الأولية يطرح سؤالاً أصعب. جرّد العملية إلى ما هو صحيح فعلاً وفيزيائياً عن بناء البرمجيات. ثم اسأل أي تلك الحقائق غيّرها النموذج وأيها لم يلمسها. وأعد البناء من الباقي.
افعل هذا بصدق فستجد أن الذكاء الاصطناعي غيّر شيئاً واحداً بالضبط، وهو ليس الشيء الذي كانت هذه الفئة تبيعه.
تكلفة إنتاج الشفرة هبطت إلى ما يقارب الصفر. وتكلفة تقرير ما ينبغي أن تكون الشفرة لم تتحرك.
وكل ما هو مفيد ينبع من عدم التناظر هذا. وأدناه أربع نتائج أريد أن يستطيع أي ممارس ذكرها من الذاكرة.
الأولى: نموذج البيانات هو المنتج
الشاشة أكثر جزء تقلباً في أي تطبيق وأكثر مكان يغري بالبدء منه، لأنه الجزء الذي ترى. وهي أيضاً الجزء الذي ينبغي أن يكون التخلص منه أرخص شيء.
ونموذج البيانات عكس ذلك. يقرر ما تستطيع استعلامه، وما تستطيع فهرسته، وما تستطيع تغييره لاحقاً بلا ترحيل يخيف الجميع. وكل قدرة لاحقة مقيَّدة بخيارات اتُّخذت، أو ارتُجلت، في تلك الطبقة.
وحين كانت الشفرة مكلفة، كان هذا الترتيب يفرض نفسه. فلم يكتب أحد مئة شاشة يدوياً مقابل مخطط لم يفكر فيه، لأن كتابة مئة شاشة يدوياً استغرقت ربع سنة. وقد أزال التوليد ذلك الباب الطبيعي. فتستطيع الآن إنتاج واجهة كاملة مقابل نموذج بيانات لم يراجعه إنسان قط، وستبدو مكتملة.
فعلى الترتيب أن يصبح مقصوداً. النموذج أولاً، ثم العقد، ثم الواجهة. لا لأنه تقليدي، بل لأنه الترتيب الوحيد الذي تُتخذ فيه القرارات المكلفة وتغييرها ما زال رخيصاً.
الثانية: القرار المؤجَّل يُتخذ مع ذلك
هذه التي يقلل الممارسون من شأنها.
كل قرار لا تتخذه صراحةً يُتخذ مع ذلك. يتخذه المُولِّد، في لحظة التوليد، من سياق لا يتضمن شركتك ولا سطح امتثالك ولا تاريخ ترحيلاتك ولا خططك للربع القادم. والنموذج لا يمتنع عن القرار. يختار شيئاً معقولاً ويمضي.
ما يستطيع مستخدم بعضوية ملغاة رؤيته بعد؟ وما يحدث حين يعدّل شخصان السجل نفسه؟ وهل عنوان البريد فريد، وفريد داخل ماذا؟ لم يوجّه أحد بهذه الأسئلة فلم يجب أحد، ومع ذلك يملك التطبيق جواباً للثلاثة، مُختاراً بالاستنباط، قابلاً للاكتشاف فقط بالاصطدام به في الإنتاج.
وهذه هي الآلية خلف ما سماه البنّاؤون مشكلة السبعين بالمئة. فالتقدم يتوقف لا لأن العمل الباقي صعب، بل لأنه محجوز بقرارات اتُّخذت بصمت قبل مئات الأجيال ولم تعد قابلة للتغيير دون تفكيك الكل.
والممارسة التي تصلح هذا لها اسم الآن: التطوير الموجَّه بالمواصفات. اكتب المتطلبات والقيود ومعايير النجاح أولاً. وتعامل مع تلك الوثيقة كمصدر الصحة. ودع الوكيل يبني مقابلها. أطلقت GitHub منتج Spec Kit، وأطلقت AWS منتج Kiro، والتقارب ليس مصادفة.
الثالثة: حين يكون التوليد مجانياً، على القيود أن تُكتَب
عشرات السنين، كانت الصحة محمولة جزئياً بتكلفة كتابة الشفرة. فالمهندس الذي ينفّذ قاعدة كان عليه حفظ القاعدة في ذهنه. وكانت المعرفة الضمنية في رأس بشري مكاناً مقبولاً لتخزين قيد، لأن إنساناً كان دائماً في الحلقة.
وذلك المكان لم يبقَ صالحاً. فإذا لم يكن القيد معبَّراً عنه في مكان مقروء آلياً (قيد مخطط، أو نوع، أو قاعدة تحقق، أو اختبار، أو سطر صريح في مواصفة)، فهو غير موجود بحسب المُولِّد. إنه موجود في ذاكرة من هو على وشك أن يُفاجأ فقط.
وهذا هو الجوهر العملي للتصميم بالذكاء الاصطناعي أولاً، وهو غير براق. ادفع الثوابت إلى الطبقة التي تستطيع فرضها. «غير فارغ» و«فريد» في قاعدة البيانات لا في معالج نموذج. والأنواع عند الحدود لا في تعليق شفرة. والتخويل كسياسة يقيّمها النظام لا كشرط تذكّر أحدهم كتابته في نقطة وصول.
وكل قيد تُخرِجه إلى الخارج قرار لم يبقَ للنموذج أن يخطئ فيه.
الرابعة: أنت تبني الآن لمستخدمين من نوعين
الأخيرة هي الأحدث، والتي لم تستوعبها معظم الفرق إطلاقاً.
لتطبيقك الآن نوعان من المستخدمين. أحدهما شخص ينظر إلى شاشة. والآخر وكيل يستدعي واجهة برمجة، لا يرى واجهتك قط ولا يقنعه تصميم جيد. فإذا كانت قدرة موجودة في واجهة مستخدمك وغير موجودة في واجهة برمجتك، فهي بحسب اقتصاد الوكلاء غير موجودة.
ولهذا نتيجة تصميمية: التكافؤ ليس إضافة لطيفة. فأي شيء يستطيع إنسان فعله عبر الواجهة ينبغي أن يكون قابلاً للوصول عبر سطح معرَّف وموثَّق وقابل للاكتشاف. وهذا أيضاً سبب كون GraphQL أنسب من REST لاستخدام الوكلاء: فالمخطط الذي يصف نفسه شيء تستطيع آلة استكشافه دون أن يكتب إنسان ملاحظات تكامل أولاً.
ابنِ للوكيل فتصبح الواجهة البشرية أبسط كأثر جانبي. وابنِ للإنسان وحده فستجد نفسك تضيف واجهة برمجة لاحقاً تحت ضغط موعد، وهو أسوأ وقت ممكن لتصميم واحدة.
كيف يبدو تجاوز هذا في البيانات
حلّلت GitClear 623 مليون تغيير في الشفرة من 2023 إلى 2026، وصورة قابلية الصيانة متسقة مع كل ما سبق.
فمقابل خط أساس 2023، كتل الشفرة المكرَّرة أعلى 81 بالمئة. والنسخ واللصق داخل الدفعة نفسها ارتفع من 9.4 بالمئة في 2022 إلى 15.7 بالمئة في النصف الأول من 2026. والبنى التي تحجب الأخطاء أعلى 47 بالمئة. وفي الوقت نفسه، استدعاءات الدوال بين الملفات، وهي أوضح إشارة متاحة لإعادة استخدام الشفرة، أدنى 35 بالمئة، ونشاط تنظيم الشفرة انهار من 21 بالمئة من التغييرات في 2022 إلى 3.8 بالمئة حتى الآن في 2026.
فالمهندسون الآن أكثر احتمالاً بنحو خمس مرات لنسخ الشفرة ولصقها من تنظيمها. وفي 2022 كانت هذه النسبة تعمل في الاتجاه الآخر.
ولا شيء من ذلك مشكلة جودة نموذج. فالتكرار بدل إعادة الاستخدام، ومعالجة أخطاء تبتلع بدل أن تُبرز، وتنظيم شفرة يكفّ عن الحدوث: هذه ما تحصل عليه حين يكون التوليد رخيصاً والبنية ليست عمل أحد صراحةً. والناتج معقول محلياً وغير متسق عالمياً، وهو بالضبط شكل العطل الذي لا يستطيع مسار عمل يبدأ من الشاشة كشفه.
كيف تعمل بهذه الطريقة، بدءاً من هذا الأسبوع
لا شيء من هذا يطلب إعادة تنظيم. يطلب تغيير ترتيب أربع أو خمس عادات.
- اكتب نموذج البيانات قبل الشاشة الأولى. الكيانات والعلاقات والتعدد وما يجعل صفاً فريداً وما يتسلسل عند الحذف. والساعة هنا أكثر ساعة رفعاً في المشروع، وهي الساعة التي تدعوك الأدوات فعلياً إلى تجاوزها.
- اجعل المواصفة هي الناتج الذي تراجعه، لا فرق الشفرة. فإذا كانت المواصفة صحيحة والتوليد مخلصاً لها، فمراجعة آلاف الأسطر من الشفرة المُولَّدة مسرح. راجع الوثيقة التي أنتجتها. وتجادل في المواصفة والجدال ما زال رخيصاً.
- أخرِج كل قيد تستطيع تسميته. قبل التوليد، اسرد القواعد التي لا يجوز خرقها وضع كل واحدة في مكان يفرضها النظام. وأي شيء يبقى في المحادثة سيُخرَق في النهاية بواسطة شيء لم ينضم إلى المحادثة قط.
- صمّم واجهة البرمجة كسطح المنتج. ثم تعامل مع الواجهة البشرية كأحد مستخدميها. وهذا خيار ترتيب أكثر من كونه خياراً هندسياً، وتأخير ترتيبه هو ما يجعله مكلفاً.
- قِس عدم الاستقرار لا المعدل فقط. فنتيجة DORA أن السرعة والهشاشة ارتفعتا معاً، فقياس السرعة وحدها سيعرض لك النصف الجيد من اتجاهك. ومعدل فشل التغيير وزمن الاستعادة هما الرقمان الذي يخبرانك إن كان المكبّر يعمل لصالحك.
ما تكلفة هذا
أريد أن أكون صريحاً في المبادلة لا أن أتظاهر بعدم وجودها.
العمل بهذه الطريقة أبطأ في الأسبوع الأول من مشروع وأسرع بشكل ملموس في كل أسبوع بعده. وهذه تكلفة حقيقية تُدفَع مقدماً، في اللحظة التي يبدو فيها الزخم أثمن ما يكون وينشر فيها منافس شيئاً مرئياً. وستكون هناك دورات عمل يبدو فيها الفريق الذي تجاوز كل هذا فائزاً.
وهو ليس مجانياً في الانضباط أيضاً. فكتابة القيود أقل متعة من مشاهدة واجهة تظهر. ومراجعة مواصفة أقل إشباعاً من مراجعة شفرة. وهذه العادات تتعفّن تحت ضغط المواعيد، وهو الضغط نفسه الذي يجعلها مهمة.
وبعضه لا ينطبق فعلاً. فإذا كنت تختبر فكرة نهاية هذا الأسبوع وتنوي التخلص من النتيجة، فتخلّص منها: لا شيء من أعلاه يستحق الفعل لبرمجية عمرها يومان. والحجة هنا عن التطبيقات التي تعيش أطول من عرضها.
الجزء الذي لم يكن قابلاً للأتمتة قط
بعض الأدوار المبنية حول إنتاج الشفرة سيتقلص. وبعضها سيزول. والتظاهر بغير ذلك لا يساعد أحداً على الاستعداد، ومن يقول لك إن كل وظيفة هندسية آمنة لا يقدّم لك خدمة.
لكن انظر ما فعله عدم التناظر فعلاً. لقد أتمت التعبير عن القرارات وترك القرارات نفسها بلا مساس. ماذا يُبنى. وما لا يُبنى. وأي الثوابت تسري. وما لا يجوز للنظام فعله أبداً. وأين تقع الحدود ومن يُسمح له بعبورها.
ذلك العمل كان دائماً الجزء الصعب. كان فقط مخفياً تحت جهد الطباعة، الطباعة التي كانت مكلفة بما يكفي لتبدو كأنها العمل.
الطباعة لم تكن العمل قط.
قراءات ذات صلة
الممارسة بعمق: التطوير الموجَّه بالمواصفات. وإذا كنت تختار أداة: أفضل مُولِّدات التطبيقات بالذكاء الاصطناعي في 2026.
الأسئلة الشائعة
ماذا يعني «تصميم البرمجيات بالذكاء الاصطناعي أولاً»؟ تصميم تطبيق حول افتراض أن معظم الشفرة سيُولَّد لا يُكتَب يدوياً، وأن بعض المستخدمين سيكونون وكلاء لا بشراً. وعملياً يعني أن نموذج البيانات والقيود وعقد واجهة البرمجة تُعرَّف صراحةً مقدماً، لأنها القرارات التي لا يستطيع التوليد اتخاذها عنك.
كيف يختلف التصميم بالذكاء الاصطناعي أولاً عن مجرد استخدام أدوات الشفرة بالذكاء الاصطناعي؟ استخدام أدوات الذكاء الاصطناعي يضيف قدرة إلى مسار عمل لم يتغيّر. أما التصميم بالذكاء الاصطناعي أولاً فيغيّر ترتيب عمليات المسار: النموذج والعقد قبل الواجهة، والمواصفة كناتج يُراجَع، والقيود مدفوعة إلى طبقات تفرضها. وقد وجد بحث DORA لعام 2025 أن تبنّي الذكاء الاصطناعي رفع المعدل وعدم الاستقرار معاً، وهو ما يحدث حين تتغيّر الأداة ولا تتغيّر الممارسة.
ما المبادئ الأولية لتصميم البرمجيات في عصر الذكاء الاصطناعي؟ أربعة تصمد: نموذج البيانات هو المنتج والشاشة عرض له؛ وأي قرار لا تتخذه صراحةً يتخذه المُولِّد ضمناً؛ وعلى القيود أن تسكن في مكان يمكن فرضه آلياً لا في رأس أحد؛ وتطبيقك يخدم الآن واجهة بشرية وواجهة برمجة موجَّهة للوكلاء معاً، وهما تحتاجان تكافؤاً.
هل يبطّئ التصميم بهذه الطريقة الفرق؟ ينقل العمل إلى المقدمة بدل إضافته. فالقرارات المجموعة في نموذج بيانات ومواصفة قرارات يتخذها أحد على أي حال: إما بوعي في البداية وإما ضمناً بنموذج يحدس لاحقاً. والطريق الثاني هو من حيث تأتي التصحيحات، والتصحيحات ليست أسرع.
هل التطوير الموجَّه بالمواصفات هو نفسه التصميم بالذكاء الاصطناعي أولاً؟ التطوير الموجَّه بالمواصفات هو الممارسة؛ والتصميم بالذكاء الاصطناعي أولاً هو المجموعة الأوسع من النتائج البنيوية. فالأول يغطي كتابة المواصفة والتوليد مقابلها. والثاني يغطي أيضاً ترتيب نمذجة البيانات، وأين تُفرَض القيود، والتصميم لمستخدمين وكلاء إلى جانب مستخدمين بشر.
متى يكون تجاوز كل هذا مقبولاً؟ النماذج الأولية والعروض والأعمال الداخلية لمرة واحدة وأي شيء تخطط للتخلص منه. فهذا العبء يستحق الحمل فقط للبرمجيات التي عليها النجاة من مستخدمين حقيقيين وبيانات حقيقية والتغيّر مع الزمن.
