جيريمي فريمان، المؤسس المشارك والمدير التقني لشركة Allstacks – سلسلة المقابلات

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

Allstacks هي منصة ذكاء هندسة برمجيات وإدارة تدفق القيمة التي تساعد المنظمات على تحسين قابلية التنبؤ وكفاءة تطوير البرمجيات. تدمج المنصة بيانات من أدوات تستخدم في جميع مراحل دورة حياة تطوير البرمجيات، بما في ذلك أنظمة إدارة المشاريع ومراقبة المصدر ونظم النشر، ثم تطبيق الذكاء الاصطناعي والتعلم الآلي لتحديد المخاطر والتنبؤ بنتائج التسليم وإظهار رؤى قابلة للتنفيذ. من خلال تقديم رؤية للمسؤولين الهندسيين والمنتجين حول صحة المشروع وأداء الفريق و اتجاهات التطوير، تمكن Allstacks المنظمات من اتخاذ قرارات أكثر информية وتقليل عدم اليقين في التسليم وتحسين انسجام الجهود الهندسية مع الأهداف التجارية. تم تصميم تكنولوجيا الشركة لمساعدة الشركات على التحرك بعيدًا عن التخطيط القائم على الحدس من خلال الاستفادة من البيانات التشغيلية في الوقت الفعلي لتحسين أداء تسليم البرمجيات والتنفيذ الاستراتيجي.

لقد قمت برحلة فريدة من نوعها من قيادة فرق البحث والهندسة التي تطبق التعلم الآلي على بيانات تطوير البرمجيات إلى تأسيس شركة Allstacks في عام 2017. ما هي الفجوات أو المشاكل المتكررة التي لاحظتها في النهاية دفعتك إلى بناء الشركة؟

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

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

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

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

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

ما يساعد هو البدء بالمشكلة التي ترى بالفعل، وليس المقياس الذي تريد تحسينه. إذا كنت تسأل “لماذا يبدو أننا نسلّم أقل من العام الماضي”، هذا هو النقطة الانطلاق الصحيحة. من هناك، أعتقد أنك تحتاج إلى ثلاثة أنواع من المقاييس: أولًا، كيف تعرف أن المشكلة حقيقية (ربما عدد Pull Requests لكل مطور مع مرور الوقت)؛ ثانيًا، ما التغييرات التي تقوم بها وكيف تتبعها على طول الطريق (ربما اعتماد محقق Pull Request مدفوع بالذكاء الاصطناعي إذا كان ذلك هو التدخل الخاص بك)؛ وثالثًا، كم هو هذا المشكلة هامًا للأعمال. قد يكون انطباعك صحيحًا أنك تسلّم 20٪ أقل من الكود، ولكن القصة الحقيقية قد تكون أن الاختبار يأخذ الآن ثلاث مرات أطول. تحتاج إلى جميع ثلاثة العدسات لتعرف ما إذا كنت تحل المشكلة الصحيحة.

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

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

هذا المنظور مفيد بالفعل. إنه يسياقل ما نقوم به جميعًا في هذه الصناعة، ويجعل الكثير من المناقشات التكنولوجية تعود إلى مكانها. الأعمال لا ت cared ما إذا كنت تستخدم Python أو Go. إن إنفاق الدورات على إعادة الكتابة هذا ليس حيث العائد الحقيقي.

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

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

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

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

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

الtemptation الآن هو تجاوز كل ذلك. لكن الوكلاء والقفازات ليسوا جاهزين لجميع دورة حياة التطوير البرمجي بعد. السرعة حقيقية. بوابات مراقبة الجودة التي كانت تحدث في جميع الخطوات البطيئة السابقة لم يتم استبدالها. هذا هو الفجوة.

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

الناس نضجوا على هذا الموضوع بشكل كبير منذ بدأنا Allstacks. التقييم انتقل إلى أشياء تهم حقًا، والإطارات أصبحت أكثر تعقيدًا. الذكاء الاصطناعي يقلب كل ذلك.

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

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

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

منصة Allstacks تصل بين البيانات من أدوات مثل أنظمة إدارة المشاريع ومراقبة المصدر. ما مدى أهمية توحيد هذه المصادر البيانية المتجزئة، وماذا يحدث عندما تفشل المنظمات في القيام بذلك؟

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

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

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

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

بصورةironic، إنه لا يختلف كثيرًا عن أن تكون مستعدًا لإحضار فئة من المبتدئين الصيفيين. تحتاج إلى مجموعات اختبار آلية صلبة، وثائق جيدة، وخط أنابيب CI/CD ناضج، والحدود التي تضعها عندما تضيف مطورًا موثوقًا به جديدًا إلى الفريق.

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

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

لقد شددت على أهمية محاذاة عمل الهندسة مع نتائج الأعمال. كيف يمكن للمنظمات جسر هذه الفجوة بطريقة عملية ويمكن قياسها؟

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

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

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

مع خلفيتك في الهندسة اليدوية والتكنولوجيا وتعليم تطوير الويب، كيف ترى دور المطورين يتطور مع اتخاذ الذكاء الاصطناعي لمزيد من عبء البرمجة؟

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

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

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

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

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

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

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

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

شكرًا على المقابلة الرائعة، القراء الذين يرغبون في التعلم أكثر يجب أن يزوروا Allstacks.