مؤسس GitHub السابق حصل على 17 مليون دولار من a16z، ليكون بمثابة Git في عصر الوكيل

مقالة من كتابة: ليو

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

هذه هي الأسباب التي جعلت خبر حصول GitButler على تمويل بقيمة 17 مليون دولار في الجولة الأولى من التمويل تجعلني أتوقف وأفكر بجدية. هذه الجولة بقيادة a16z، وتابعتها Fly Ventures و A Capital. والأكثر إثارة للاهتمام، أن المدير التنفيذي لـ GitButler، سكوت تشاكون، هو أحد مؤسسي GitHub، وهو من كتب ذلك الكتاب الذي قرأه تقريباً كل مطور: “Pro Git”. شخص حقق نجاحاً هائلاً في مجال التحكم في الإصدارات، لماذا يعود إلى مسار ريادة الأعمال ليعيد التفكير في مشكلة تبدو قد حُلت بالفعل؟ يقول في الإعلان بشكل مباشر: “نحن لا نبني نسخة أفضل من Git، نحن نبني البنية التحتية للجيل القادم من طرق بناء البرمجيات.” وراء هذه العبارة يكمن فهم عميق لمستقبل تطوير البرمجيات.

مأزق Git على مدى 20 عاماً: أداة صُممت لقوائم البريد

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

ثم حدث ما نعرفه جميعاً. مطور يُدعى Pasquy كتب بعض سكربتات بيرل، ولفّف بها واجهة موحدة للأوامر، وهي ما نستخدمه الآن كـ CLI. أصبحت هذه السكربتات شائعة، وفي النهاية تم دمجها في نواة Git، وأطلق عليها اسم “طبقة الخزف” (porcelain). المثير أن هذه الأوامر لم تتغير كثيراً منذ 2005 و2006. كانت مكتوبة في البداية بلغة بيرل، ثم أُعيدت كتابتها بلغة C، لكن المنطق الأساسي وواجهة المستخدم بقيت تقريباً كما هي. يقول سكوت إنه عندما كتب الطبعة الأولى من “Pro Git” في 2009، كانت تلك الأوامر لا تزال قابلة للاستخدام بشكل كامل.

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

وماذا عن الآن؟ لدينا التكامل المستمر، والنشر المستمر، وفرق موزعة تتعاون في الوقت الحقيقي، وأدوات مراجعة الكود، وسلاسل اختبار ونشر آلية. والأهم، أن هناك وكلاء ذكاء اصطناعي يكتبون الكود على نطاق واسع. يذكر سكوت ملاحظة أثارت إعجابي: نحن الآن نعلم مجموعة من وكلاء الذكاء الاصطناعي باستخدام أداة صُممت لقوائم البريد. هذا التباين، يشبه أن تسير سيارة تيسلا على طريق مخصص للخيول.

فلسفة يونكس في تصميم Git تطرح مشكلة أخرى: فهي تحاول أن تخدم واجهة واحدة كل من الحاسوب والبشر. إذا نفذت الأمر “git branch”، بشكل افتراضي ستحصل على قائمة الفروع فقط، بدون واجهة مستخدم. السبب هو أن Git يحتاج لضمان أن يكون مخرجه قابلاً للقراءة للبشر، ويمكن تحليله بواسطة برامج أخرى. هذا التوازن يؤدي إلى نتيجة: Git ليس ودوداً للبشر، وليس محسنًا للبرامج أيضاً. على الرغم من أن بعض الأوامر توفر خيار “–porcelain” لإخراج تنسيق يمكن للآلات قراءته، إلا أن هذا ليس المعيار، والعديد من الأوامر لا توفره على الإطلاق.

تحديات عصر وكلاء الذكاء الاصطناعي: مجلد عمل واحد لم يعد كافياً

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

الحل التقليدي هو استخدام “worktree”، أي إنشاء نسخ متعددة من المستودع لكل مهمة متوازية. لكن هذا يخلق مشكلة جديدة: إذا كان لديك خمسة وكلاء يعملون في آنٍ واحد، فستحتاج إلى خمسة نسخ كاملة من مجلد العمل. على الرغم من أن Git قام بتحسينات على مستوى التخزين، إلا أن ذلك لا يزال يتطلب نسخ ملفات كثيرة واستهلاك مساحة تخزين كبيرة. والأهم، أن هذه الوكلاء معزولون تماماً، ولا يرون ما يفعله الآخرون إلا بعد أن ينتهوا ويحاولوا الدمج، وعندها تظهر الصراعات. وحل تلك الصراعات يكون مكلفاً جداً.

الحل الذي يقترحه GitButler هو الفروع المتوازية (parallel branches). وهو تصميم أذهلني. الفروع المتوازية تشبه الفروع العادية، لكن يمكنك فتح عدة منها في آنٍ واحد. يمكنك الاستفادة من مزايا worktree (العزل المنطقي)، دون الحاجة لنسخ جميع الملفات. جميع الوكلاء يعملون في نفس مجلد العمل، لكن تعديلاتهم تُنسب إلى فروع افتراضية مختلفة. يصف سكوت في المقابلة مشهدًا مثيرًا: أن يشتغل وكيلان في وقت واحد، وكل واحد يريد تعديل نفس الملف، لكن التعديلات غير متوافقة. النتيجة؟ يقوم أحد الوكلاء تلقائياً بتكديس فرعه فوق فرع الوكيل الآخر، ثم يواصل العمل، ويقدم التعديلات على تكديسه الخاص. هذا المعالجة الذكية للصراعات، في تدفق العمل التقليدي، يكاد يكون مستحيلاً.

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

إعادة تصميم واجهة المستخدم: للبشر، للوكلاء، للسكربتات

أطلقت GitButler أداة CLI حديثة أثارت اهتمامي بشكل كبير. ليست مجرد غلاف لGit، بل تفكير جذري في كيفية تصميم أدوات سطر الأوامر. يذكر سكوت ملاحظة مثيرة: أن حوالي 80% من المطورين لا زالوا يستخدمون أدوات سطر الأوامر للتعامل مع Git، رغم وجود أدوات رسومية كثيرة. السبب بسيط — معظم أدوات GUI لـ Git مجرد تغليف لأوامر Git، دون إضافة وظائف، بل تجعل العمليات أبطأ. إذا كنت تعرف الأمر الذي تريد تنفيذه، فإن كتابة الأمر مباشرة أسرع.

لكن CLI الخاص بـ GitButler يختلف. يوفر أوضاع إخراج مختلفة حسب السيناريو. إذا نفذت الأمر مباشرة، يعطيك إخراجاً محسناً وسهل القراءة للبشر، مع تنبيهات واقتراحات. وإذا أضفت “–json”، فإنه يعطيك بيانات منظمة بصيغة JSON، لسهولة تحليلها برمجياً. حتى أنهم يفكرون في إضافة “–markdown”، لتخصيص إخراج الوكيل، لأن صيغة markdown أسهل في الإدراج في سياق الوكيل.

الأكثر إثارة، أنهم يراقبون سلوك الوكلاء ويستخدمونه لتحسين التصميم. يكتشفون أن، على الرغم من وجود خيار “–json”، أن الوكلاء يفضلون استخدام الإخراج المقروء للبشر، ثم يمررونه عبر أنابيب مثل jq أو يكتبون سكربتات بايثون لاستخراج المعلومات. اكتشاف آخر هو أن الوكلاء بعد أي أمر تعديل، يراجعون الحالة فوراً باستخدام “git status”. لذلك أضاف فريق GitButler خيار “–status-after” في جميع الأوامر التعديلية، بحيث يعرض الحالة مباشرة بعد التنفيذ. هذا التصميم يتعارض مع الفلسفة التقليدية لنظام يونكس، وهو غير مناسب للسكربتات، لكنه مثالي للوكلاء.

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

التغير الجوهري في تطوير البرمجيات: من كتابة الكود إلى كتابة المواصفات

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

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

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

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

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

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

PR و Issue: نمط التعاون الذي لم يتغير منذ 20 عاماً ويحتاج إلى تطور

آلية طلبات السحب (Pull Request) على GitHub أصبحت معياراً للتعاون المفتوح، لكن سكوت يرى أن هناك مشكلة جوهرية فيها. PR تعتمد على الفروع، وليست على التصحيحات المباشرة. هذا يؤدي إلى الكثير من “الرسائل غير المهمة” — مثل “أصلحت خطأ صغير” أو “نسيت إضافة ملف كذا”. في نمط PR، المهم هو الفرع ككل، وليس كل تعديل على حدة. لذلك، لا يهتم الناس عادة بجودة رسائل الالتزام، وغالباً ما تُفقد بعد الدمج.

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

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

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

تأملاتي حول هذه الثورة

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

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

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

أعتقد أن قيمة GitButler ليست فقط في وظائفه المحددة، بل في طريقة تفكيره. هم يشككون في الافتراضات التي اعتدنا عليها: لماذا نعمل على فرع واحد فقط؟ لماذا يجب أن تكون الالتزامات خطية؟ لماذا يجب أن يستخدم الوكيل والبشر نفس الواجهة؟ لماذا يجب أن يكون التعاون عبر PR و Issue؟ التفكير من المبادئ الأساسية هو ما نحتاجه أكثر في زمن التغير السريع هذا.

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

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

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