الذكاء الاصطناعي هو مُضاعف، وليس اتجاهًا.كاتب المقال، المصدر: InfoQ
جعلك الذكاء الاصطناعي تكتب الكود أسرع بعشر مرات، ثم ماذا؟ كود أكثر يعني وقت تجميع أطول، واختبارات أثقل، ومراجعات كود مزدحمة، ومكتبة كود لا يستطيع أحد فهمها. البرمجيات هي ديون، وكلما كتبت أسرع، زادت ديونك.
تحذير مهندس البرمجيات الرئيسي في جوجل، آدم بيندر، واضح جدًا: الطريقة التي تبني بها البرمجيات اليوم لا تعمل إطلاقًا بسرعة 10 أضعاف. لكن الفائزين الحقيقيين في عصر الذكاء الاصطناعي ليسوا الفرق الأكثر إنتاجية، بل تلك التي تمتلك أساسيات أقوى. لأن الذكاء الاصطناعي يُضخم فقط، ولا يحدد الاتجاه.
في كلمة رئيسية خلال Google I/O 2026، طرح آدم بندر سؤالًا لم يفكر فيه معظم الناس بعد: ما الذي سينهار أولاً في نظامنا المطورين عندما تدفع الذكاء الاصطناعي سرعة إنتاج الكود إلى ما وراء قدرة عمليات الهندسة الحالية على التحمل؟ وقد ربط كلمته بأفكار باستخدام مفهوم ربما لم تسمع به من قبل: علم البيئة البرمجية، وهو دراسة شاملة للنظام الاجتماعي-التقني الذي ينتج البرمجيات. بمعنى آخر، لا يكفي أن تنظر إلى التكنولوجيا فقط، بل يجب أن تنظر إلى الناس، والثقافة، والقواعد غير المكتوبة داخل المنظمات. بناءً على فيديو هذه الكلمة، قامت InfoQ بتنظيم المحتوى.
النقاط الأساسية هي كالتالي:
- الذكاء الاصطناعي لا يحل أي مشكلة نيابةً عنك. إذا كانت ممارساتك جيدة، فإنه يُضخمها. لكن إذا لم تكن جيدة، فإنه يخلق المزيد من المشاكل.
- أن يكون الجميع مُنشئين أمر رائع، حتى تضطر إلى صيانة كل ما أنشأه الجميع.
- الممارسات الهندسية ليست مقدسة وغير قابلة للمس. الممارسات تتغير، أما المبادئ فهي المهمة.
- كمهندس برمجيات في الخطوط الأمامية، أنت في قلب اللحظة الحاسمة التي تحدد مسار هندسة البرمجيات. من الأدوات إلى سير العمل، ومن الممارسات الهندسية إلى الثقافة الهندسية، إذا استطعت رؤية النظام الذي يعمل، فستجد نقطة الرفع.
ما هو "النظام"
عملك في عام 2026 مختلف تمامًا عما تخيلته في عام 2020. إذا حاولت أن تشرح لي ما يحدث اليوم كما لو كنت أتحدث إلى نسخة عام 2020 منك، فلن تصدقني. التغييرات كثيرة جدًا، أكثر مما يمكن للمرء أن يتحمله. لا أستطيع التنبؤ بالمستقبل، لكنني أؤمن أنه إذا درسنا بعناية نظام البرمجيات الحالي، فبعض الإجابات أقرب مما نتخيل.
سأتحدث معك اليوم عن كلمة واحدة: علم البيئة البرمجية (Software Ecology). قد يبدو وكأنني اخترعتها للصعود إلى المنصة، لكنه ليس كذلك، بل هو مصطلح رسمي. قبل أن أقدم التعريف، أريد أن أُمهّد ببعض الخلفية، ونستعرض قليلاً التفكير النظامي.
النظام هو مجموعة من العناصر المترابطة التي تعمل وفق مجموعة من القواعد لتشكيل كيان موحد. يبدو هذا مجردًا، لكنك لست غريبًا عن الأنظمة. على سبيل المثال، مكيف الهواء: مُثبّت حرارة يعرف درجة الحرارة المستهدفة، ونظام تدفئة وتبريد يُسخّن أو يبرّد، وغرفة، وعندما تصل درجة الحرارة إلى المستوى المناسب، يتوقف الإشارة — هذا نظام.
إذا كنت مهندس برمجيات، فأنت تقضي يومك بالتعامل مع الأنظمة، وتصمم الأنظمة وتبنيها وتوظفها، وفي هذه العملية تتعلم شيئًا واحدًا تقريبًا: كل شيء مرتبط.
بعد ذلك، نأتي إلى النظام البيئي، وهو نظام خاص. التعريف طويل قليلاً، لكنه مهم: النظام البيئي هو شبكة ديناميكية من الجهات الفاعلة المترابطة التي تتطور مع بيئتها، ويتميز بسلوك ناشئ واستقلالية لامركزية. ببساطة، النظام البيئي معقد، وعناصره مترابطة بعمق، وكل عنصر له استقلاليته الخاصة، ويمكنه اتخاذ قرارات وتنفيذ إجراءات. وأهم نقطة على الإطلاق: البيئة جزء من النظام، ولا يمكنك فصلهما.
النظام البيئي هو أيضًا نظام متكيف معقد يمكنه النمو والتغير والتطور مع مرور الوقت. كما أن لديها خاصية تُسمى "الخصائص الناشئة" (Emergent Property)، وهي أشياء لا يمكنك رؤيتها من خلال مراقبة أي مكون منفرد، بل فقط عندما يتم تجميع النظام ككل، تظهر السلوكيات من داخله. إن هذا التغيير المستمر والتعلم المستمر بالإضافة إلى الخصائص الناشئة يجعل من الصعب جدًا فهم ما يحدث بالضبط داخل النظام البيئي.
عندما نتحدث عن النظام البيئي، فإن ما يخطر ببالك على الأرجح هو الجبال والأنهار وصوت الطيور ورائحة الزهور. لكن بيئة المطورين الداخلية هي أيضًا نظام بيئي: تحتوي على مجموعة متنوعة من الأدوات والخدمات، وأشخاصًا يحملون أفكارهم وطلباتهم الخاصة، وقيودًا عمل. وهي نظام خاص: نظام اجتماعي تقني، أي نظام مكون من البشر والتكنولوجيا معًا. الأنظمة الاجتماعية التقنية معقدة جدًا، لأنك تبدأ بكل تلك التقنيات، ثم تضيف البشر إليها.
من المحتمل أنك واجهت بالفعل ذكاء أنظمة اجتماعية تقنية دون أن تدرك ذلك. هل تعرف قانون كونواي: التقنية التي تبنيها المنظمة تعكس هيكل التواصل الداخلي لها. ببساطة، إذا كان لديك أربعة فرق تعمل على نفس المُجمّع، فستحصل على مُجمّع من أربع مراحل، وهكذا تسير الأمور. الملاحظة الأساسية لقانون كونواي هي أن طريقة بنائنا للتكنولوجيا لا يمكن فصلها عن هيكل المنظمة التي بنتها، فالمنظمة تُشكّل ما يتم بناؤه في النهاية.
لكن ليس فقط الهيكل التنظيمي هو الذي يؤثر على نظام المطورين، بل القيم والثقافة أيضًا لها تأثير عميق. النظام البيئي الذي تبنيه هو ما تشجعه المنظمة، وثقافتك الهندسية تخلق البيئة المحيطة بنظام المطورين. بمجرد أن تفهم أنظمة التكنولوجيا الاجتماعية، سترى هذه الأنظمة في كل زاوية من زوايا تطوير البرمجيات: البنية، ثقافة مراجعة الحوادث، مراجعة الكود، سياسات الأمان، في كل مكان. ما نبنيه، وكيف نختار بناءه، يعكس ما نقدّره. إذا كنا حريصين بما يكفي، يمكننا استخدام هذا الفهم لتعزيز قيمنا وغرسها في ما نبنيه.
الآن يمكنني أن أقدم لك تعريفًا صحيحًا: علم البيئة البرمجية هو دراسة شاملة للنظام البيئي الاجتماعي التقني الذي ينتج البرمجيات. إذا كانت الأمثلة السابقة تبدو مجردة بعض الشيء، فلا بأس، دعنا الآن ننظر إلى حالة واقعية.
بيئة مطوري Google
أنا أتحدث عن Google ليس لأنني أعمل هناك وأريد أن أُمدحه، بل لأنه أكثر بيئات المطورين التي أعرفها جيدًا. هدفي ليس أن أقول لكم يجب أن تقتفوا خطى Google، فهذا لن يكون مفيدًا لكم. أنتم شركات مختلفة، وفي مراحل مختلفة، وتعانون من توازنات مختلفة. العديد من الخيارات التي اتخذتها Google كانت استجابة لاحتياجات محددة كان لدينا عند بناء بيئتنا في ذلك الوقت.
قبل سنوات، كتبنا كتابًا داخليًا يُسمى "كتاب الفلامينغو". يتناول نصف الكتاب التحكم في الإصدارات والاختبارات، لكن الجزء الأول بأكمله يركز على ثقافة الهندسة. سأل الكثير من الناس لماذا خُصص هذا القدر الكبير من المساحة للثقافة، لأنك لا يمكنك فهم أسباب اختيارنا التقنيّة إذا لم تفهم ثقافة Google، فهذه الأمور مترابطة.
لدى جوجل عدة سمات ثقافية فريدة. نحن موجهون بعمق نحو الهندسة، ويكون المهندسون دائمًا حاضرين عند اتخاذ القرارات المهمة؛ نحن نولي أهمية كبيرة للشفافية، ونحاول جعل جميع الوثائق والكود متاحة للجميع قدر الإمكان؛ نحن نشجع المساعدة المتبادلة، ففي الواقع، عند التحدث مع أي شخص غادر جوجل، فإن مساعدة الزملاء ستكون أول ما يذكرونه؛ نحن نعتبر مراجعة الكود فرصة للتوجيه، وليست تصحيح امتحان؛ نحن نولي أهمية كبيرة للمعايير الموحدة؛ نحن نؤمن بالتحسين المستمر؛ نحن نشجع مراجعة الحوادث دون لوم؛ ونحن نؤمن بأن الاستدامة أهم من البطولة، وأن الأتمتة أفضل من العمل اليدوي. بالطبع، لا نحقق دائمًا كل هذه المثل العليا، لكنها الاتجاه الذي نسعى إليه ثقافيًا.
من الناحية التقنية؟ مستودع كود موحد، حيث يوجد تقريبًا كل الكود في مستودع واحد؛ تطوير مبني على الفرع الرئيسي، حيث يتم دمج كل تغيير مباشرة في الفرع الرئيسي؛ عند بناء ملف ثنائي، يتم بناء تقريبًا كل سطر من الكود من المصدر؛ سلسلة أدوات بناء موحدة يستخدمها الجميع؛ منصة أتمتة اختبار عالمية، حيث يتم تشغيل جميع الاختبارات من مكان واحد، بملايين الاختبارات يوميًا؛ إشارة "أخضر نهائي" عالمية، يمكنني من خلال موقع داخلي بسيط أن أخبرك بحالة أي بناء؛ بيئة حسابية موحدة، لذا فإن القول "يعمل على جهازي" أصبح مستحيلًا تقريبًا؛ إطارات مطورين موحدة بشكل عالٍ وعدد قليل من لغات البرمجة الأساسية.
هذا المزيج من الثقافة والتكنولوجيا هو ما شكّل جوجل كما هي اليوم، ولا يمكنك فهم نصفها فقط وتجاهل النصف الآخر.
مشاركة المصير
إذا كان عليّ اختيار مبدأ يوجهنا باستمرار، فسأختار "القدر المشترك". وهو يصف درجة الارتباط الوثيق بين نظام بيئي ومكوناته؛ ففي نظام بيئي ذي درجة عالية من القدر المشترك، يمكن لمكون واحد أن يؤثر على جميع المكونات الأخرى. في النظام البيئي للمطورين، القدر المشترك هو خيار تقني واجتماعي على حد سواء. لا يمكنك تحقيق القدر المشترك فقط من خلال جعل الجميع يستخدمون نفس التقنية؛ بل تحتاج أيضًا إلى إنشاء عقد اجتماعي حول كيفية إدارة هذه التقنيات.
في جوجل، يبدأ مصيرنا المشترك بمستودع كود موحد. كل سطر من كود الشركة، باستثناء بعض الاستثناءات القليلة مثل Android وChrome، موجود في مستودع مشترك. يتم تقديم جميع التغييرات إلى الفرع الرئيسي، دون فروع أو إصدارات، وكل شيء في مكان واحد. هذا المصير المشترك يمكّننا من تطبيق تصحيح أمان في ملف واحد، ثم نعرف أن كل تطبيق في الشركة سيتم إصلاحه خلال أسبوع. إصلاح مليار سطر من برامج التطبيقات والأنظمة بعشرة أسطر من الكود، يشبه قدرة خارقة.
لكن مشاركة المصير ليست دائمًا أمرًا جيدًا، بل هي خيار. هناك أماكن لا يناسب فيها مشاركة المصير، مثل بيئة الإنتاج، حيث لا نريد أبدًا أن يُعطل خدمة واحدة جميع الخدمات الأخرى، أو أن يُصاب تجمع واحد منطقة بأكملها. لذا بذلنا جهدًا كبيرًا لتجنب مشاركة المصير الخطرة التي تؤدي إلى أعطال متسلسلة. مشاركة المصير هي توازن، ويجب عليك إيجاد المكان الصحيح للوضع، ثم التأكد من أنها تعمل لصالحك.
تغييرات واسعة النطاق
إحدى الخصائص الناشئة الأكثر إثارة في بيئة مشاركة المصير هي التغييرات الواسعة النطاق. لاحظ هذا: قبل ظهور الذكاء الاصطناعي مباشرة، كانت أدوات Google الداخلية تتيح لمطور واحد تعديل ملايين الأسطر من الكود، ملايين الأسطر التي لن يقرأها أبداً، ولن ينظر إليها مجدداً، وربما لا يعرف عنها شيئاً على الإطلاق. لقد بنينا الأدوات التي جعلت كل هذا ممكناً تلقائياً، وهكذا هو الحال اليوم، ونحن نفعل ذلك على الأقل منذ خمسة عشر عاماً.
هذا النوع من القدرة يسمح لنا بالتطور المستمر لمستودع الكود الأحادي، وتحديث اللغات والإطارات، ومنع البيئة الداخلية من أن تصبح جامدة. لا مبالغة في القول إنه بدون التغييرات الكبيرة، لما كنا لنكون Google كما نحن اليوم. زملاؤنا الذين يعملون على هذه الأدوات يقومون بعمل بطولي خلف الكواليس، يمكّن الشركة من التقدم بالسرعة المطلوبة.
لكن الجوهر هو أنه لا يمكنك فهمه حقًا دون فهم المكونات الثقافية والتقنية التي تجعل التغييرات الواسعة النطاق ممكنة. ما الذي تحتاجه؟ ثقافة اختبار شائعة، حيث يكتب الجميع اختبارات. منصة اختبار موحدة، تعرف أين تحصل على النتائج. أدوات بناء مشتركة، بحيث يكون بناؤك مثل بنائي. مكتبات معيارية، بحيث عند استبدال مكوناتك، لا تنتقل من مكان لآخر للبحث عن الإصدار الذي يعمل معك ولا يعمل معي. مراجعة كود معيارية، وشفافية مستودع الكود نفسه، حتى تعرف أي كود يحتاج إلى تعديل. التغييرات الواسعة النطاق هي التعبير النهائي لمفهوم "الأتمتة أفضل من العمل اليدوي" لدى جوجل، وهي ممكنة فقط عندما تعمل جميع أجزاء النظام البيئي معًا. لا يمكنك الإشارة إلى جزء واحد في بيئة المطورين وقول: هذا هو السبب، بل إن جميع الأجزاء المتصلة معًا هي السبب.
نظامك البيئي، توازناتك
تتمتع كل بيئة مطورين بهذه الخصائص الناشئة. فهي عادةً ما تكون تلك الأشياء التي تجعلك تشعر أن مكان عملك له طابع خاص، لأنها ناتجة عن سلسلة من الخيارات التي اتخذتها.
أنتجت بيئة المطورين الخاصة بجوجل مجموعة فريدة من التوازنات التي تخدم أهدافنا التقنية والتجارية. ولكن مثل كل بيئة، لا يمكنها التميز في جميع المهام. نحن نختار تحسين الحجم الهائل والأمان والأداء، حتى لو كان ذلك يعني أحيانًا التضحية بإنتاجية المطورين، ونحن مستعدون لاتخاذ هذا التوازن. ستبدو بيئة شركة ناشئة مكونة من خمسة أشخاص مختلفة تمامًا، حيث تكون السرعة والمرونة هما الأهم.
النظام البيئي الذي يقع معظمكم فيه يتراوح بين خمسة أشخاص ومائتي ألف شخص. التنازلات التي عليكم إجراؤها تستحق الاهتمام الكبير، لأنه عندما تفحصون هذه التنازلات، يمكنكون البدء في فهم قيم المنظمة: ما الذي تهتم به حقًا، وليس ما تقول إنها تهتم به، بل ما تكشفه الخيارات التي تلاحظونها فعليًا. عندما تفهمون هذه القيم، يمكنكون البدء في تشكيل التغيير الذي يتكشف.
وقت الضغط 10 أضعاف: كل عقدة تحت الضغط
حان الوقت للحديث عن الفيل الذي يأكل التوكنات في الغرفة: كيف يبدو نظام بيئي للمطورين يركز على الذكاء الاصطناعي أولاً؟
من الجيد بالطبع بناء نظام بيئي جديد من الصفر، لكن لا أحد منكم يملك هذا الترف. يجب عليكم الاستمرار في توصيل البرمجيات بينما تستبدلون تقريبًا كل جزء منها. الشركة تعتمد عليكم للاستمرار في خلق القيمة، مع ضمان عدم حدوث أي مشكلات.
إذًا، اسأل نفسك سؤالاً: كم تعرف عن نظام المطورين الخاص بك اليوم؟ هل يمكنك رسمه بالكامل؟ هل تعرف أين تقع جميع المكونات، ليس فقط التقنية بل أيضًا الاجتماعية؟ هل يمكنك سرد مكونات نظامك؟ كم يفهم الآخرون في منظمتك؟ ما هي نقاط قوته وضعفه؟ أين تكمن العقبات؟ أين تكون القيود وأين تكون الحرية؟ ما هي خياراتك المتاحة؟ ما أنواع الخصائص الناشئة التي رأيتها؟ ربما الأهم من ذلك: إذا اضطر نظامك فجأة إلى معالجة 10 إلى 15 ضعف كمية الكود خلال الثمانية عشر شهرًا القادمة، هل تعرف ما الذي سيُنهار أولًا؟
تتعرض كل نظام بيئي للمطورين على وجه الأرض لتحول جذري، وقد لا يصل هذا التحول بعد إلى كل زاوية من زوايا موقعك، لكنه قادم، وستضطر كل نظام بيئي للمطورين إلى مواجهة لحظة الـ10 أضعاف. هذه حقبة لا تُصدق، لكنها أيضًا مربكة إلى حد كبير. ستُعاد توازنات التنازلات التي طورناها عمداً على مدار خمسة وعشرين عاماً مضت.
إن تسريع إنشاء الكود بمقدار 10 مرات وتسريع التطوير الهندسي بمقدار 10 مرات، هما أمرين مختلفين. في جوجل، نقول غالبًا إن الهندسة هي تكامل البرمجة مع مرور الوقت. لكن المشكلة أننا نُسرّع بشكل كبير قسم البرمجة، ونُسرّع تشغيل آلة الكود. لذا يجب أن نجد طرقًا لتنفيذ الهندسة بشكل فعّال حول هذه الآلة، حتى نتمكن حقًا من تسليم النتائج للعملاء. لا أحد يعرف إلى أين يمكن أن تصل هذه الموجة من زيادة الإنتاجية، لكن هناك أمر واحد مؤكد: نحن نبدأ من هنا ونتحرك للأعلى.
المشكلة أن الطريقة التي نبني بها ونسلم بها البرمجيات اليوم لا تعمل بسرعة 10 مرات أو 100 مرة، فشيء ما يجب أن يتغير.
لنبدأ بمشاهدة نسخة مبسطة من خريطة نظام المطورين. في عالم يزداد فيه النشاط 10 مرات، ما الذي يجب أن يتغير؟
إدخال الكود
اكتب الشيفرة المصدرية. إذا كتب الجميع الشيفرة بسرعة أكبر بكثير، فسيزداد حجم الشيفرة بشكل كبير، وهذا ليس أمرًا جيدًا. قال جيف أتود: "البرمجيات هي مسؤولية". لذا، 10 أضعاف الشيفرة تعني 10 أضعاف المسؤولية. ولا يمكنك ببساطة توزيع كمية من الرموز على الجميع ثم تقول "حظًا سعيدًا". أتمنى أن تستثمر بعد التدريب: أتعلم أين توجد وثائق ممارسات الهندسة الخاصة بك؟ أتعلم كيف تطورها؟ بعد ذلك، يمكنك التفكير في الأمر.
بناء النظام. مزيد من الكود ونظام أكبر يعني وقت تجميع أطول. أنا متأكد أن أحدًا في شركتك لا يشكو حاليًا من بطء التجميع. لكن تخيل ماذا سيحدث، سيصبح أبطأ. وإذا كان العامل يدير كمية كبيرة من العمل، فسيزداد عدد مرات التجميع بشكل كبير. التجميع ليس مجانيًا، سواء من حيث الوقت أو الموارد الحسابية. ربما لم تلاحظ قط كم من الوقت تقضيه في التجميع، لكن بحجم 10 أضعاف، ستلاحظه بالتأكيد.
تصميم الكود. هل لديك مهارات مناسبة مبنية على وكلاء لتشجيع التفكيك؟ هل لديك إطار خادم مناسب لضمان دمج سريع وآمن لقدرات متنوعة؟ هل تعرف كم عدد طرق النشر المختلفة لتطبيقات الويب في شركتك؟ كم عدد إطارات الخادم المختلفة التي تعمل حاليًا؟ كيف تدير إعادة استخدام المكونات في الكود الذي يكتبه الوكلاء؟ ربما أنت تراهن على أن هذا غير مهم. لكن إذا أنتج الوكلاء كودًا سهل الكتابة لكنه صعب الصيانة، فلا تتفاجأ، فهذا هو المستوى القياسي الحالي. الوكلاء ممتازون في كتابة الكود، لكنهم لا يفكرون دائمًا على المدى الطويل. أنا متأكد أن هذا الكود لن يُعاد هيكلته بشكل جيد. لا بأس، سنحل هذه المسألة لاحقًا. لكن الحقيقة هي أن الوكلاء يقومون بعمل كبير لنا، وعلينا كل يوم إيجاد طرق أكثر كفاءة لتطبيق هذه القدرات.
في مرحلة ما، قد تصبح هذه الوظائف المبنية على الوكلاء كبيرة جدًا لدرجة أن ملفاتك الثنائية لا يمكن ترجمتها. أو كبيرة جدًا لدرجة أنه لا يمكن رفعها إلى الهاتف مرة أخرى. هل سألت نفسك هذا السؤال: ما هو أكبر ملف ثنائي يمكنك ترجمته؟ لا أعرف الإجابة، لكنني أعلم أنه في Google، نحن نصل إلى الحدود، وهناك أماكن حيث أصبحت الملفات الثنائية كبيرة جدًا لدرجة أنها لا يمكن ترجمتها، وأنا أؤمن أننا سنحل هذه المشكلة. لكن الحقيقة هي أن الحجم الكبير له تأثيرات متسلسلة، وتأثيرات الحجم موجودة في كل مكان.
ربما أنت تستخدم بنية تقنية للخدمات الدقيقة، وتقول في نفسك: خدماتي صغيرة جدًا، لماذا أقلق؟ لكن لدي سؤال: هل أنت مستعد لعشرة أضعاف حركة المرور على الشبكة، وعشرة أضعاف عدد الخدمات، وعشرة أضعاف كمية الاتصال؟ لا أحد يمكنه التهرب من ذلك، فتأثير الحجم موجود في كل مكان.
مراجعة الكود. افترض أنك لا تستطيع تجميع كل هذا الكود بشكل موثوق، كيف ستكون عملية مراجعة الكود الخاصة بك؟ الجميع قلقون من مراجعة الكود، ولديهم أسباب وجيهة. نحن نضع ضغطًا هائلاً على هذه العملية البشرية جدًا، وفي كثير من الحالات تتحول إلى عقدة، والأشخاص لا يحبون أن يكونوا عقدة. عندما تضغط عليهم، يصبح سلوكهم غريبًا. عشرة أضعاف كمية الكود، إما أن تحصل على عشرة أضعاف حجم التغييرات، أو عشرة أضعاف عدد التغييرات. هل يستطيع مسؤولك التقني الحفاظ على سرعة المراجعة المطلوبة؟ معظم المسؤولين التقنيين لا يستطيعون مراجعة كمية كود يومية تنتجها خمسة مطورين بقدرة 10 أضعاف.
لذلك، لتجنب أن يصبحوا عقبة، سيبدأون بإعادة ترتيب العمليات، واللجوء إلى طرق مختصرة، للتأكد من عدم عرقلة أي شخص، لأن لا أحد يريد أن يكون عقبة. ربما يمكنك حل جزء من المشكلة باستخدام الذكاء الاصطناعي، من خلال نشر الذكاء الاصطناعي لتحسين مراجعة الكود. لكن هذا يحل فقط جزءًا من المشكلة، لأنك إذا لم يعد أعضاء فريقك يكتبون الكود، فإن اللحظة الوحيدة التي يواجهون فيها الكود هي أثناء المراجعة، وإذا لم يكن التركيز أثناء المراجعة كافيًا، فمن يتابع تطور قاعدة الكود؟ لا أحد. بسرعة، ستتحول قاعدة كودك إلى فوضى لا يستطيع أحد فهمها.
اقتصادية الرمز. الرموز مكلفة، وبعضكم يعرف ذلك بالفعل. على نطاق واسع، الرمز هو تكلفة فعلية يجب أخذها في الاعتبار. ماذا يحدث إذا بدأ كل شخص في الشركة باستخدام رموز بمضاعف 10 أو 100؟ ماذا لو أنفقت ميزانيتك الشهرية بأكملها عن طريق الخطأ في يوم واحد؟ إذا اضطررت إلى تحديد أولويات مكان إنفاق الرموز، هل تعرف أين يجب أن تستثمر أولًا؟ هل لديك حتى رؤية واضحة لمكان ذهاب الرموز؟
في مجرد أول عدة عقد في هذا النظام البسيط، لقد اكتشفنا بالفعل مشكلات. ومن الواضح جدًا أن هناك بعض التأثيرات الثانوية المعقّدة.
الاختبار والتحكم في الإصدارات
هل رأيت من قبل كم من الموارد الحسابية تستهلكها بنية تحتية الاختبار الخاصة بك؟ في جوجل، لم أكن راضيًا أبدًا عن سرعة اختباراتي.
يجب اختبار كل تغيير يتم إدخاله في التحكم بالإصدار. لكن بالإضافة إلى ذلك، يحب الوكلاء تشغيل الاختبارات لأنها تخبرهم مدى جودة أدائهم. لذا يولد الوكلاء عبء عمل إضافي، مما يزيد من كمية العمل الذي يجب عليّ إنجازه. إذًا، مع عشرة أضعاف عدد التحديثات بالإضافة إلى جميع المهام التي يقوم بها الوكيل، كم من موارد الحوسبة للاختبارات تستهلكها الآن؟
في الواقع، قد تكون الحالة أسوأ. ما نلاحظه في Google هو أنه مع نمو قاعدة الكود، ينمو رسم التبعيات بشكل تربيعي، وليس خطيًا. لذا، إذا زاد حجم قاعدة الكود عشر مرات، فقد تحتاج إلى تشغيل 100 أو حتى 1000 مرة عدد الاختبارات، وليس فقط 10 مرات. سيكون هذا تحديًا مثيرًا جدًا، وسيتحول في مرحلة ما إلى بند في ميزانيتك. إذا لم تكن قلقًا الآن بشأن تكلفة موارد الحوسبة للاختبارات، فهذا يثير قلقي أكثر، لأنه يعني أنك ربما لا تملك اختبارات كافية على الإطلاق، وأن الوكلاء يتجولون في قاعدة كودك دون أي شبكة أمان.
بافتراض أن التجميع والاختبار تم حلهما، دعنا ننظر إلى نظام التحكم بالإصدارات. معظم أنظمة التحكم بالإصدارات الشائعة ليست مُحسّنة للأداء، بل مُحسّنة للاتساق والترتيب. هذا هو عملها الأساسي: الحفاظ على سجل كامل، وليس السرعة الفائقة. كم مرة يمكن لنموذج التحكم بالإصدارات الخاص بك أن يعالج عمليات تقديم في الدقيقة؟ أضمن لك أن العدد أقل مما تتخيل. إنه لا يمكنه التوسع ليصل إلى السرعة التي تحتاجها بعشر مرات. متى كانت آخر مرة فكّرت فيها في أداء نظام التحكم بالإصدارات؟ إذا لم تكن تعمل على تطوير Git، فربما لم تفكر فيه قط. بصراحة، الوصول إلى مرحلة مناقشة أداء نظام التحكم بالإصدارات يعني أن شيئًا ما قد انحرف بشكل خطير. نحن في أعمق مستويات تجربة المطور، لكن هذا هو نتيجة التغييرات النظامية: إنها تصل إلى كل زاوية في نظامك وتقول: "يا، هل تنتبه؟ لأن شيئًا لم تتوقعه قد جاء."
لأولئك الذين يخططون لحل مشكلات التحكم بالإصدارات باستخدام العديد من المستودعات الصغيرة، اسأل أي شخص مرّ بآلاف المستودعات الصغيرة، فأنا أضمن أن ذلك يُشكّل مجموعة جديدة كاملة من التحديات، ولا يمكن للذكاء الاصطناعي بالضرورة جعل هذه المشكلات أسهل.
قائمة المفاجآت
حتى الآن، كنا ننظر فقط إلى عقد الكفاءة التي يسهل اكتشافها نسبيًا، وهي تلك التي تأخذ رقمًا وتساويه بعشرة ثم تسأل إن كان سيصبح أفضل أو أسوأ، وهناك العديد من التحديات غير المتوقعة.
تحقق من الاستراتيجية. إن تحققك اليوم يعتمد بشكل أساسي على العديد من اختبارات الوحدة وبعض اختبارات التكامل. لكن في عالم يحتوي على 10 أضعاف الكود و10 أضعاف الخدمات، ستتحول اختبارات التكامل إلى الجزء الأهم في استراتيجية الجودة. كم منكم راضٍ عن خطة اختبار التكامل الحالية؟ أنا أيضًا لست راضيًا. اختبارات التكامل صعبة جدًا، ولا أمتلك حاليًا الأدوات التي تمكنني من إجراء اختبارات التكامل بالطريقة التي أريدها.
مشكلة التقاء القيم المنطقية. اليوم، عند نشر برنامجك، تطلب أن تمر جميع الاختبارات، وأن تصبح جميع القيم المنطقية خضراء، وفقط عندما يكون كل شيء على ما يرام، تقوم بالنشر—وهذا منطقي. لكن ماذا يحدث عندما تمتلك مليون اختبار، وموثوقية البنية التحتية الأساسية لتشغيل مليون اختبار نفسها موضع شك؟ قد يصبح من المستحيل تحقيق شرط أن تكون جميع القيم المنطقية صحيحة لنشر البرنامج. ستحتاج إلى استراتيجية جديدة، على الأرجح قائمة على الأساليب الإحصائية، لتحديد أي الاختبارات الصحيحة يجب تشغيلها، لأنك لا تستطيع تشغيل جميع الاختبارات.
تغيير كبير جدًا. من المثير حقًا أن تعيد هندسة كل شيء واستبدال اللغة والإطار. لكن هل لديك سير عمل وعقد اجتماعي يدعمان الناس في إدارة تعارضات الدمج التي تصل إلى عشرات الآلاف أو مئات الآلاف أو حتى الملايين من الأسطر؟ على الأرجح لا. إذا كان كل شخص في الشركة قادرًا على إجراء تغييرات كبيرة جدًا، فسنحتاج إلى استراتيجيات جديدة لسير العمل.
حرب التحرير بواسطة الوكلاء. قام وكيل بإجراء تعديل، ثم جاء وكيل آخر وقال: لا، أنا لا أحب ذلك، سأقوم بإجراء تعديل مختلف. يبدو الأمر مضحكًا، حتى تدرك أنك تدفع رسوم رموز لطرفين.
الإيقاع الإصداري. كم مرة تُصدر للعملاء يوميًا؟ يوميًا؟ هذا جيد جدًا. إذا لم تكن كذلك، فهناك مشكلة: ستحصل على أكثر من 10 أضعاف البرمجيات، ويجب وضع كل هذه البرمجيات في مكان ما. إذا لم تكن تُصدر يوميًا، فستصبح التغييرات كبيرة جدًا في كل مرة. وأصدقائي من فريق SRE سيقولون لك إن التغييرات الكبيرة جدًا مخيفة. لا تفعل ذلك. لكن يجب نشر الكود ليُنتج قيمة، لذا قد تحاول نشره بشكل أكثر تكرارًا، وهذا جيد، وسيشعر أصدقاء DORA بالارتياح. لكن عند نقطة ما، ستنخفض العوائد، ونشر كل ثانية على الأرجح لن يمنحك الكثير من القيمة. سيستمر الكود في النمو، وستحتاج إلى فهم أين تضعه دون خلق مخاطر إضافية.
API داخلي. كنت أقول دائمًا لأصدقائي الذين يعملون معي: فجأة، أصبحت جميع واجهات برمجة التطبيقات الخاصة بك عامة. لن يتشاور العامل معك، بل سيجد الواجهة وستُستدعى مباشرة. سيستخدم أي شيء يمكنه الوصول إليه، وأضمن لك ذلك. إذا لم تقم من قبل بتعزيز واجهاتك وبياناتك الداخلية كما تفعل مع واجهات برمجة التطبيقات العامة، فسيجد العامل أشياء لم تكن ترغب في أن يجدها.
مفارقة جيفونز. قال جيفونز إن المورد كلما أصبح أرخص وأكثر كفاءة، استخدمناه أكثر. إن الانفجار في رموز التوكن هو مثال حي. نحن نضعها في كل مكان، وهذا يغير طريقة عملنا وطريقة تفكيرنا في العمل. نحن نضع سعرًا على قوى الإنتاج الخفية التي كانت موجودة سابقًا، وما الذي سيحدث لذلك على سلوكنا؟ لا أعرف بعد.
الرجوع للخلف. أتعرف لماذا يعد الرجوع للخلف قابلاً للتطبيق اليوم بشكل أساسي؟ لأنك تنشر البرمجيات بسرعة أبطأ قليلاً من الوقت الذي تحتاجه لاكتشاف المشكلات في بيئة الإنتاج. إذا كنت تستطيع النشر بسرعة شديدة جدًا، لدرجة أنك لا تستطيع اكتشاف أي مشكلات على الإطلاق، فكيف سيكون موقفك عند الرجوع للخلف؟ سيتعين على كل عملية رجوع للخلف التعامل مع عدة تغييرات متضاربة متراكمة فوق بعضها البعض. لذا فإن النشر الأسرع وحده لا يكفي؛ يجب أن تفكر في النظام بأكمله، بما في ذلك الرجوع للخلف كصمام أمان مهم. بالمناسبة، عليك أن تكون حذرًا بشأن مكان وضع محرك الرموز. إذا كانت عملية الرجوع للخلف تعتمد على عامل لديه سعة كافية، وكان شخص ما من قبل قد استنفد ميزانية الرموز الخاصة بذلك العامل، مما جعلك غير قادر الآن على الرجوع للخلف، فهذا على الأرجح ليس شيئًا جيدًا.
كل شخص هو مُنشئ. ربما فكّرت في إنشاء بديل لـ "vibe code" لاستبدال الأداة التي لا تحبها في الشركة. الآن، اضرب هذا بجميع الأشخاص والأدوات في الشركة. ماذا يحدث للنسيج الاجتماعي للشركة عندما يستخدم الجميع أدوات مختلفة تمامًا؟ إذا كنت محظوظًا وتمتلك قاعدة بيانات موحدة تدخل فيها جميع البيانات إلى مكان واحد، فهذا جيد. لكن إن لم تكن كذلك؟ أن يكون كل شخص مُنشئًا رائع، حتى تضطر إلى صيانة كل شيء قام الجميع ببنائه.
دورة تدريبية مكثفة في القيادة التقنية. يستغرق الأمر وقتًا طويلاً لتصبح قائدًا تقنيًا لأنك يجب أن تكتسب حدسًا وحكمًا وقدرات مهنية تساعدك على اتخاذ القرارات، لأن أخطاءك عندما تقود فريقًا لها آثار أوسع بكثير مقارنةً بارتكابها أنت وحدك. ما الذي يمكن أن يخطئ عندما يدخل خريج جديد بيئة يمكنه فيها استدعاء خمسين وكيلًا، لكنه يفتقر إلى أي حدس أو حكم؟ كيف يمكنني تعليم عشر سنوات من الخبرة في ستة أشهر؟ لا أعرف.
الانتباه البشري هو أثمن مورد نمتلكه. الآن، هناك ضجيج كبير جدًا، والعديد من الوكلاء والأشياء تتنافس على انتباهنا، وعلينا أن نجد طرقًا لإدارته. في الماضي، كنا نستفيد من حقيقة أن قدرتنا على إحداث مشاكل لم تكن تتجاوز قدرتنا على تخصيص الانتباه، لكن الوضع لم يعد كذلك الآن.
هذا يبدو كثيرًا، وذلك لأن كل شيء مرتبط في نظام واحد. لا يمكنك حل أي من التحديات التي ذكرتها للتو من خلال النظر إلى عقدة واحدة فقط في النظام، بل يجب أن تنظر إلى النظام بأكمله.
للتكيّف مع تطوير القائم على الوكلاء، يجب على الجميع أن يبدأوا في تعلم التفكير المستمر بطريقة منهجية. عندما تفكر في النظام، هذه هي الأمور التي يجب أن تركز عليها: كيف تصبح الأشياء أكبر، التأثيرات التي تتغير مع الوقت، اتجاه تدفق العلاقة السببية، أي العقد تتحدث مع جميع الجيران، كيف يبدو النشوء، وما هي الأشياء التي تظهر من لا يُعرف أين. ماذا عن آليات التحفيز؟ بما في ذلك الآليات الاجتماعية والتكنولوجية، والسعة، ودورات التغذية الراجعة، والعقدة، فهذه هي أدوات تحليل النظام.
يبدو معقدًا، لكنك تحتاج حقًا إلى سؤالين فقط: لماذا (Why؟)، وماذا لو (What if؟). لماذا لدينا عدد قليل جدًا من اختبارات التكامل؟ ماذا لو كان لدينا المزيد من اختبارات التكامل مقارنة باختبارات الوحدة؟ لماذا نستخدم هذه اللغات المحددة؟ ماذا لو كتب الذكاء الاصطناعي كل الكود؟
"لماذا" هو الحفرة التي تستخدمها للوصول إلى جوهر النظام وفهم كيفية عمله. أنتم جميعًا ممتازون في طرح سؤال "لماذا"، لكن "ماذا لو" هو الجزء الأصعب. "ماذا لو" قد يكون مخيفًا، خاصة إذا طالبك بالتخلّي عن الممارسات التي كنت تعتقد أنها مصممة بشكل ممتاز. ماذا لو لم نختبر؟ ماذا لو لم نكتب أي اختبارات على الإطلاق؟ لا تذهب بعيدًا جدًا. لكن إذا سمحت لذلك بالحدوث، فإن "ماذا لو" يمكن أن يكون مثيرًا جدًا أيضًا.
الذكاء الاصطناعي هو مُضاعف، وليس اتجاهًا
الذكاء الاصطناعي هو مُضاعف. هذه الفكرة مستوحاة من أصدقائي في DORA، الذين اكتشفوا في تقريرهم عن تطوير الذكاء الاصطناعي العام الماضي وجود علاقة بين الفرق التي فهمت الأمور حقًا: فقد فهموا كيفية جعل الذكاء الاصطناعي مُضاعفًا.
يمكن للذكاء الاصطناعي أن يمنحك المزيد: المزيد من الاختبارات، المزيد من الوثائق، المزيد من الكود، لكن أيضًا المزيد من الفوضى. التكبير هو في السعة، وليس في الاتجاه. الذكاء الاصطناعي لا يهتم بأين ذهبت تلك الأشياء، إنه فقط يمنحك المزيد. ما اكتشفته DORA حقًا هو أن الفرق التي تمتلك أساسيات قوية تستطيع توجيه تأثير التكبير نحو اتجاهات مفيدة.
هذا يطرح السؤال: كيف تشعر بأساسياتك؟ ما ثقافة اتخاذ القرار في شركتك؟ ما الذي يمكنك فعله لتحسينها؟ ما استراتيجية التقنية؟ هل هناك من يهتم بإنتاجية المطورين؟ كيف يتعاون أعضاء المنظمة اليوم؟ ما حالة الأمان؟ ما صحة الكود، ونظافة الإصدارات، والموثوقية؟ لا يحل الذكاء الاصطناعي تلقائيًا أي مشكلة لك. إذا كانت ممارساتك جيدة، فإنه يعززها. لكن إذا لم تكن جيدة، فسيخلق فقط مزيدًا من المتاعب.
لكن حتى مع وجود أساسيات قوية، فإننا على وشك خوض رحلة حقيقية. أعتقد أنه بحلول عام 2030، سيبدو نظام المطورين الذي نملكه اليوم بالنسبة لنا كما كان بعيدًا جدًا في عام 2001. في عام 2001، كنا لا نزال نُصدر البرمجيات عبر أقراص CD-ROM، وفي عام 2030 قد نكون قد ابتعدنا بهذا المقدار.
بينما تواصلون ترسيخ أساسياتكم، دعوني أقدم لكم أربع نقاط يمكنكم التفكير فيها أثناء الطريق.
أولاً، سعة البنية التحتية. إذا لم تكن تعرف كم الموارد المتاحة لديك، فلا يمكنك نشر الذكاء الاصطناعي أو موارد الحوسبة، فأنت بحاجة إلى طريقة جيدة لتتبع هذه الأمور.
ثانيًا، تحقق من الاستراتيجية. لا يمكنك ولا ينبغي لك نشر برنامج لم يتم التحقق منه. لكن استراتيجيات التحقق تتغير، وقد حان الوقت لتحديد ذلك بوضوح. ستكون اختبارات التكامل سلاحك الأهم، وقد لا تمتلك أدوات مناسبة بعد.
ثالثًا، العزل. ستتلقى الكثير من التعليمات البرمجية المستخدمة لأغراض مختلفة، بعضها لأغراض لم تُستخدم فيها البرمجة من قبل. هذا أمر مقبول، لكنك لا تريد أن تدخل برامج تجريبية ممتعة إلى بيئة الإنتاج. اجعل الأشياء الممتعة لا تؤثر على الأشياء التي تدر الأرباح.
رابعًا، التجريد. نبني التجريد لمنع المطورين من اتخاذ خيارات سيئة، وهذا هو السبب في وجود المكتبات والإطارات. لا أحد يكتب خادم ويب من الصفر. جعل الوكلاء يتخذون قرارات كثيرة سيؤدي إلى نفس النتائج، لذا تحتاج إلى تجريدات جيدة يلتزم بها الوكلاء. لا تمنحهم خيارات سيئة.
يجب عليك أيضًا قبول شيء واحد: الممارسات الهندسية ليست مقدسة وغير قابلة للمس. الممارسات تتغير، أما المبادئ فهي ما يهم حقًا. هذا يبدو سهلًا لكنه صعب التنفيذ؛ فإذا لم تفكر قط في سبب قيام فريقك باختبار البرمجيات بهذه الطريقة، أو سبب عمل عملية الإصدار بهذه الطريقة، فلن تتمكن من تطويرها. فهم المبادئ هو ما يمنحك القوة والثقة لعبور هذه اللحظة التي تضاعف الأداء عشر مرات.
الآن هو عصر مثير لمهندسي البرمجيات. كل بعد من أبعاد عملنا يُعاد تعريفه؛ نحن بحاجة أكثر من أي وقت مضى إلى التفكير الإبداعي؛ نحن بحاجة إلى مهارات للتعامل مع قضايا مثل إدارة السياق، اقتصاد التوكنات، وانحراف النموذج؛ نحن بحاجة إلى الإبداع؛ لا يمكننا أن نكون مهووسين بفرصة تحسين كل شيء، بل يجب تشجيع الاستكشاف.
هناك مشكلة تجعلني لا أستطيع النوم، ولا يمكن حلها فقط من خلال التحسين: مع نمو قاعدة الكود، كيف نحافظ على السيطرة المعرفية عليها؟ السيطرة المعرفية تعني قدرة الإنسان على الاستدلال على ما أمامه. لقد خسرنا هذه الحرب منذ ما لا يقل عن خمسة عشر عامًا، فأنظمةنا الأكبر تجاوزت منذ زمن طويل أي حجم يمكن لأي شخص واحد أن يفكر فيه. إذا لم تكن تصدق، قم بتجربة: اطلب من كل شخص في فريقك رسم مخطط هندسي للنظام، وانظر إلى كم عدد الإصدارات المختلفة التي ستحصل عليها.
أنظمة البرمجيات الخاصة بنا كثيرة جدًا وهشة، حيث يمكن لسطر واحد من الكود السيئ أو علامة تكوين خاطئة أن تدمر نظامًا يحتوي على ملايين الأسطر، وهذا الهشاشة يجبرك على التفكير مرتين قبل إجراء أي تغيير. لكن لدي فكرة مثيرة جدًا حول الذكاء الاصطناعي: مساحة معمارية مستمرة التحديث وشبه تفاعلية يمكنني طرح الأسئلة عليها. ماذا سيحدث إذا نقلنا السعة هنا إلى الساحل الشرقي؟ ماذا إذا ارتفع نمو المستخدمين فجأة بنسبة 40٪؟ بالنسبة لأي نظام متوسط الحجم اليوم، فإن القيام بذلك عمليًا مستحيل تقريبًا بسبب كثرة المتغيرات. لكن الذكاء الاصطناعي يمكنه فهم مجموعات بيانات ضخمة جدًا، لذا أعتقد أن هناك شيئًا يمكن استغلاله هنا.
أحب هذا السؤال لأننا لا نركز فقط على جعل آلات الكود تدور أسرع، بل نسأل: كيف يمكننا تعميق فهمنا لما بنيناه بالفعل؟
تحدث التغييرات بسرعة كبيرة، أسرع مما مر به معظمكم. أحد أهم الأشياء التي يمكنكم فعلها الآن هو مساعدة أولئك الذين يعانون، وتقديم يد العون لمن لم يفهموا بعد. نحن جميعًا نتقدم بسرعات مختلفة، ونواجه هذا التغيير بطرق مختلفة. من السهل أن تشعر أنك تتخلف.
المهندسون ذوو الخبرة، توجهوا ليكونوا موجهين. ابحثوا عن الأشخاص الذين علقوا وساعدوهم. إذا كنت قد فهمت بالفعل سير عمل تطوير الذكاء الاصطناعي، فشاركه مع الآخرين؛ إنه ليس سرًا ثمينًا. مسؤولو التقنية، يجب أن تشاركوا بنشاط لمساعدة توجيه اتجاه هندسة البرمجيات في شركتكم. إذا كنتم تهتمون بجودة البرمجيات أو تصميمها، فعليكم أن تستخدموا أصواتكم للدفاع عنها. أنتم من يجب أن يفعلوا هذه الأمور، وربما لن يفعلها مديروكم.
إذا تخيلنا نظام المطورين كنظام بيئي حي، فقد اعتدنا جميعًا على مراقبة كل ورقة على كل فرع، ورعاية كل شجرة كأنها كائن حي خاص. لكن بعد وقت قصير، لن نكون مسؤولين عن شجرة واحدة، بل عن غابة بأكملها. ولا يمكنك إدارة غابة من خلال مراقبة شجرة واحدة، بل يجب أن تنظر إلى الغابة كنظام بيئي لإدارتها.
التغيير النظامي له طبيعة خاصة: فهو يحدث في كل مكان وفي كل شيء في آنٍ واحد، بحجم يُشعرك أنك لا تستطيع الإمساك بأي شيء. في هذه اللحظة، قد تشعر أن لا شيء يمكنه أن يثبتك في موجة التغيير التي تتدفق أسبوعيًا. لكن كما اكتشفنا للتو، في نظام ما، كل شيء مترابط، ويمكن للإجراءات الصغيرة أن تُحدث عواقب كبيرة.
مهما بدا الأمر من الخارج، فإن التحول إلى الذكاء الاصطناعي ليس مجالًا حكرًا على قادة الشركات. كمهندس برمجيات في الخطوط الأمامية، أنت في قلب هذه اللحظة الحاسمة التي ستقرر مسار هندسة البرمجيات. من الأدوات إلى سير العمل، ومن الممارسات الهندسية إلى الثقافة الهندسية، إذا استطعت فهم الأنظمة التي تعمل، فستتمكن من إيجاد نقاط رفع. لديك من الاستقلالية أكثر مما تظن، فاستخدم هذه الاستقلالية لإنشاء مستقبل لمنظمتك، فريقك، ونفسك.