لم يكن مستودعك يومًا القصة كاملة

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

لكن ما لا يمكنك عادةً إعادة بنائه هو الحوار الذي جعل تلك الأسطر ضرورية.

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

يتفوّق Git في حفظ تاريخ الكود. لكنه لا يحفظ النية إلا عندما يدوّنها الفريق عمدًا ويُبقيها مرتبطة بالتنفيذ.

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

المشكلة ليست أن الكود مضلّل. بل إن الكود يجيب عن سؤال أضيق.

خمس طبقات من الحقيقة الهندسية

تعتمد معظم التغييرات البرمجية ذات المعنى على خمس طبقات مختلفة من الأدلة.

1. النية — ما النتيجة التي يطلبها المستخدم أو العميل أو النشاط التجاري؟ قد يوجد ذلك في مواصفة، أو تذكرة، أو محادثة دعم، أو ملاحظة اجتماع.
2. القيود — ما الذي يجب ألا يتعطل؟ غالبًا ما تقع وعود التوافق، والحدود الأمنية، واللوائح، والعقود، والميزانيات، والمواعيد النهائية خارج المستودع.
3. التنفيذ — كيف يعمل النظام اليوم؟ يوفّر الكود، والاختبارات، والمخططات، والاعتماديات، وإعدادات النشر هذه الطبقة.
4. أدلة وقت التشغيل — ما الذي يحدث في النظام الحقيقي؟ يمكن للسجلات، والتتبعات، والمقاييس، وبيانات الإنتاج، وتقارير الحوادث أن تناقض افتراضات تبدو معقولة في الكود.
5. سجل القرارات — لماذا اختير النهج الحالي؟ تحمل طلبات السحب، ونقاشات التصميم، والبدائل المرفوضة، والحوادث السابقة الإجابة.

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

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

قد يظل التصحيح الصحيح محليًا هو التغيير الخطأ.

ما الذي لا يستطيع المستودع الإجابة عنه بمفرده

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

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

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

حذف التعقيد أمر ذو قيمة. أما حذف التاريخ المتنكر في هيئة تعقيد فمكلف.

قد يؤدي المزيد من السياق أيضًا إلى إجابة خاطئة

الحل البديهي هو تزويد الذكاء الاصطناعي بمزيد من المواد: المستودع بأكمله، وكل التذاكر، وكل المستندات، وكل الرسائل، وكل السجلات.

هذا يوفّر الوصول، لا الفهم.

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

لذلك يحتاج نظام السياق الجاد إلى ما هو أكثر من الاسترجاع. إنه يحتاج إلى طريقة للتفكير في:

• المرجعية: أي مصدر يُسمح له بتحديد المتطلب؟
• الحداثة: أي المعلومات هي الحالية، وما الذي تم الاستعاضة عنه؟
• المنشأ: من أين جاء كل ادعاء أو قيد أو استنتاج؟
• العلاقات: أي مشكلة، وإصدار، وعميل، ومجموعة بيانات، ومسار كود تنتمي معًا؟
• الأذونات: أي المصادر يجوز استخدامها لهذه المهمة وعرضها لهذا الشخص؟

السياق ليس كومة من الرموز. إنه رسم بياني له زمن ومرجعية وحدود.

ينبغي أن يؤدي المزيد من السياق إلى مزيد من الأدلة، لا إلى مزيد من الثقة من دون أدلة.

وحدة العمل الحقيقية هي التغيير

تُنظَّم المحررات وأدوات البرمجة حول الملفات لأن الملفات هي ما نعدّله. أما الفرق الهندسية فتُنظَّم حول التغييرات.

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

ينبغي لنظام ذكاء اصطناعي يعمل على برمجيات حقيقية أن يتبع دورة الحياة تلك.

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

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

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

هذا هو الفرق بين أداة يمكنها تعديل مستودع، ونظام يمكنه المشاركة في العمل الهندسي.

ينبغي للذكاء الاصطناعي أن يقلّل إعادة البناء، لا أن يلغي الحكم

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

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

هذه القدرات لا تلغي الحكم الهندسي. بل تجعل هذا الحكم أكثر استنارة.

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

المعيار ليس: «هل يمكنه توليد شيفرة؟»

المعيار هو: «هل يمكنه أن يشرح لماذا هذا هو التغيير الصحيح الآن؟»

من الوعي بالمستودع إلى الوعي بالعمل

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

الخطوة التالية هي الوعي بالعمل المحيط بالمستودع.

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

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

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

القصة الكاملة تغيّر ما يُبنى

عند الاكتفاء بالشيفرة فقط، يكون السؤال الطبيعي هو:

ما التغيير الذي يناسب هذا النظام؟

أما مع السياق الأوسع، فيصبح السؤال:

ما التغيير الذي يناسب هذا النظام، وهذا المتطلب، وهذا التاريخ، وهذه اللحظة؟

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

لم يكن مستودعك يومًا القصة كاملة.

تكمن الفرصة في بناء أنظمة تستطيع قراءة بقية هذه القصة — وأن تُظهر كيف توصلت إلى ذلك.