بصفته مدير مشاريع أدوات المطورين في جوجل، يرى رايان سالفا عن كثب كيف تُغير أدوات الذكاء الاصطناعي عالم البرمجة. بعد عمله في GitHub ومايكروسوفت، أصبح الآن مسؤولاً عن أدوات مثل Gemini CLI و Gemini Code Assist، دافعًا المطورين نحو عالم جديد من البرمجة الوكيلة.
أصدر فريقه يوم الثلاثاء بحثًا جديدًا من طرف ثالث يوضح كيف يستخدم المطورون أدوات الذكاء الاصطناعي بالفعل ومقدار التقدم الذي لا يزال يتعين إحرازه. جلست مع سالفا للحديث عن التقرير وتجربته الشخصية مع أدوات البرمجة بالذكاء الاصطناعي.
تم تحرير هذه المقابلة للاختصار والوضوح.
تُجري جوجل كل عام مسحًا لاتجاهات المطورين لكن تقرير هذا العام يركز حقًا على أدوات الذكاء الاصطناعي، وتحديدًا مدى استعداد المطورين للتبني الوكيلي في نهجهم للبرمجة. هل كان هناك أي شيء في البحث فاجأك؟
كان أحد النتائج المثيرة للاهتمام حقًا هو التاريخ المتوسط الذي بدأ فيه المطورون استخدام أدوات الذكاء الاصطناعي. وجدوا أنه كان أبريل 2024، وهو ما يتوافق بدقة مع إطلاق Claude 3 و Gemini 2.5. هذه هي حقًا فجر نماذج التفكير أو الاستدلال، وفي نفس الوقت تقريبًا، أصبحنا أفضل بكثير في استدعاء الأدوات.
بالنسبة لمهام البرمجة، تحتاج حقًا إلى القدرة على الاستفادة من المعلومات الخارجية لحل المشكلات، لذلك قد تحتاج إلى البحث (grep)، وقد تحتاج إلى تجميع الكود. إذا تم تجميع الكود، فقد ترغب في تشغيل اختبار الوحدة هذا، واختبار التكامل ذاك. أعتقد أن استدعاء الأدوات هو حقًا الجزء المهم الذي منح النماذج القدرة على التصحيح الذاتي أثناء تقدمها.
كيف تستخدم أدوات البرمجة بالذكاء الاصطناعي شخصيًا؟
معظم أعمالي البرمجية هذه الأيام هي لمشاريع هواية، وأقضي معظم وقتي في استخدام أدوات تعتمد على سطر الأوامر. وهذا يشمل Gemini CLI. ثم هناك القليل من Claude Code، والقليل من Codex. ولا تستخدم أبدًا أداة تعتمد على الطرفية بمفردها، لذلك أنا متنوع جدًا فيما يتعلق ببيئات التطوير المتكاملة (IDEs) التي أستخدمها. أستخدم Zed. أستخدم VS Code. أستخدم Cursor. أستخدم Windsurf، جميعها، لأنني مهتم فقط برؤية كيف يعمل العالم وكيف تتطور الصناعة.
على الصعيد المهني، يميل مديرو المنتجات إلى قضاء وقتهم في المستندات، لذا فإن أول شيء هو استخدام الذكاء الاصطناعي لمساعدتي في كتابة وثائق المواصفات والمتطلبات.
أنا فضولي لمعرفة كيف يعمل ذلك. أنت تستخدم Gemini CLI لبناء Gemini CLI، لكنني أتخيل أنه لا يعمل من تلقاء نفسه.
عادةً ما تبدأ مهمة التطوير كمشكلة، ربما تكون مشكلة في GitHub أبلغ عنها شخص ما بوجود خطأ. غالبًا، إذا كنت صريحًا حقًا، تكون مشكلة غير محددة بشكل كافٍ. لذلك سأستخدم Gemini CLI لإنشاء وثيقة متطلبات أكثر قوة بتنسيق Markdown. سينتج عن ذلك عادةً حوالي 100 سطر من المواصفات التقنية إلى حد ما، ولكنها أيضًا موجهة نحو النتائج. ثم سأستخدم Gemini CLI لكتابة الكود بناءً على تلك المواصفات والتفضيلات العامة في وثائق الفريق.
عبر فريق الهندسة، لدينا عدة طبقات مختلفة من القواعد ووثائق Markdown التي تستهلكها النماذج، والتي تحدد طريقة عملنا: إليك كيفية إجراء الاختبار، وكيفية إدارة التبعيات، وما إلى ذلك. لذلك عندما ينتج الكود، فإنه يعمل أيضًا بناءً على تلك الوثائق.
وبينما يقوم Gemini CLI بعملية استكشاف الأخطاء وإصلاحها، سأجعله يحدث وثيقة متطلباتي قائلاً: "لقد أصلحت هذه الخطوة. الآن أنا أنتقل إلى الخطوة التالية"، وهكذا. كل واحدة من هذه الخطوات تنشئ التزامها الخاص وطلب السحب في المستودع، لذلك يمكنني دائمًا التراجع أو الإلغاء.
أود أن أقول إن حوالي 70% إلى 80% من عملي هو أنا أعمل في الطرفية باستخدام اللغة الطبيعية، محاولًا استخدام Gemini CLI لصياغة المتطلبات، ثم السماح لـ Gemini CLI بكتابة معظم الكود لي، والذي سأقوم بعد ذلك بمراجعته وقراءته باستخدام أي بيئة تطوير متكاملة أستخدمها. ولكن في الغالب، أستخدم بيئة التطوير المتكاملة كمكان لقراءة الكود، بدلاً من كتابته.
هل تعتقد أن هناك مستقبلًا للكود الخام للكمبيوتر؟ أم أننا سننقل كل شيء إلى نوافذ الطرفية؟
لمدة ثلاثة عقود، كانت بيئة التطوير المتكاملة (IDE) هي المكان الذي نذهب إليه للقيام بكل شيء في تطوير البرمجيات. كان لديك بيئة التطوير المتكاملة، وكان لديك المتصفح، وكانت لديك نافذة الطرفية.
