الفيديو الأصلي: The End of Coding: Andrej Karpathy on Agents, AutoResearch, and the Loopy Era of AI
رابط الفيديو：https://www.youtube.com/watch?v=kwSVtQ7dziU
ملاحظة: فيما يلي نسخة مترجمة إلى العربية بعد إعادة ترتيبها حسب المتحدث. لضمان سهولة القراءة، حُذفت فقط كمية صغيرة من حروف الحشو غير ذات المعنى، ودُمجت المقاطعات القصيرة جدًا في المداخلة المجاورة؛ مع الحفاظ الكامل على المحتوى الأساسي، والتركيز على فصل كلام المُحاوِر عن كلام Andrej Karpathy.
مقتطف من المقدمة
Andrej Karpathy：
“الآن لم تعد عبارة «كتابة الكود» دقيقة جدًا. الأدق أن أقول: أقضي يوميًا 16 ساعة في التعبير عن نواياي لوكلائي (agents) لكي تحدث الأشياء.”
Andrej Karpathy：
“كيف لا أكتفي بفتح جلسة واحدة على Claude Code أو Codex، أو إطار عمل لوكلاء آخر، بل أفتح عدة جلسات في الوقت نفسه؟ كيف أفعل ذلك بالشكل الصحيح؟ الآن أصبح الوكيل (agent) نفسه تقريبًا افتراضًا افتراضيًا، كما أن كيانات مثل Claude باتت أقرب فأقرب إلى كونها افتراضًا افتراضيًا. يمكنك امتلاك عدة منها في الوقت نفسه، وتوجيه الأوامر لها، والاستمرار في تحسين تلك الأوامر. لذلك يصبح الأمر شديد الإدمان: يكاد يبدو وكأنه يتفرّع بلا نهاية، وفي الوقت نفسه يبدو كل شيء وكأنه «مسألة مهارة (skill issue)».”
النص
المُضيف：
مرحبًا بكم مجددًا في No Priors. نستضيف اليوم Andrej Karpathy لنتحدث عن وكلاء كتابة الكود، والهندسة ومستقبل أبحاث الذكاء الاصطناعي، وكيف يمكن لمزيد من الناس المشاركة في البحث، وما الذي يحدث في الروبوتات، وكيف سيمتد الوكلاء أكثر إلى العالم الواقعي، وما شكل التعليم في العصر القادم.
خلال الأشهر القليلة الماضية، كان مجال الذكاء الاصطناعي مثيرًا للغاية. أتذكر مرة دخلتُ المكتب وكنتَ في حالة اندماج كامل. سألتك: ماذا تفعل؟ فقلت إنك تحتاج أن «تكتب الكود» 16 ساعة يوميًا — لكن حتى كلمة «كتابة الكود» لم تعد دقيقة، بل الأمر أشبه بإصدار الأوامر باستمرار للوكلاء. ماذا حدث بالضبط؟ ما الذي تشعر به؟
Andrej Karpathy：
أنا كثيرًا ما أكون في حالة «نشوة الذكاء الاصطناعي» (AI high)، وهذه الحالة مستمرة منذ فترة طويلة. لأن سقف القدرة الفردية انفتح فجأة بشكل كبير. في الماضي كان عنق الزجاجة هو سرعة الكتابة، وسرعة التنفيذ، وكم الأشياء التي تستطيع فعلها بالتوازي؛ لكن قرب ديسمبر من العام الماضي، بدا الأمر وكأن شيئًا ما انقلب فجأة إلى مستوى آخر.
سابقًا كان الأمر تقريبًا 80% أكتب بنفسي و20% أوكله إلى الوكيل؛ ثم أصبح تدريجيًا 20/80؛ والآن صار أكثر تطرفًا من ذلك. منذ ديسمبر، ربما لم أعد أكتب بيدي إلا بضعة أسطر كود. هذا تغيير ضخم جدًا.
وأعتقد أن الناس العاديين لم يدركوا بعد مدى درامية هذا التحول. يمكنك اليوم أن تجد أي مهندس برمجيات جالسًا في مكتبه؛ سير عمله الافتراضي مقارنة بالعام الماضي لم يعد الشيء نفسه. لذلك أستمر في التجربة: هل يمكنني ألا أفتح فقط Claude Code أو Codex؟ هل يمكنني فتح عدد كبير في الوقت نفسه؟ كيف أُجدولها؟ كيف أجعل هذا أكثر منهجية؟
أرى على Twitter الكثير من الناس يبنون أشياء جديدة، ويبدو كل ذلك منطقيًا. ينتابني قلق شديد: إن لم أكن في المقدمة، سأشعر بعدم الارتياح جدًا. لأن هذه المساحة من حيث المبدأ لم تُستكشف بعد إلى نهايتها.
المُضيف：
إن كنتَ أنت متوترًا، فنحن الباقون أولى بالتوتر. فريق تعاونّا معه لم يعد فيه مهندسون يكتبون الكود يدويًا. الجميع يرتدي ميكروفونًا ويتحدث بهدوء إلى وكلائه طوال الوقت. كنتُ أظنهم مجانين، والآن أصبحتُ أفكر: آه، لقد دخلتُم هذه الحالة مبكرًا فقط.
برأيك، ما هو عنق الزجاجة الحقيقي الذي يحدّ قدرتك على الاستكشاف أو إنجاز المشاريع الآن؟
Andrej Karpathy：
في كثير من الأحيان لا يكون القيد «عدم وجود القدرة»، بل «أنك لا تستخدمها جيدًا بما يكفي». إذا لم يعمل شيء ما، فغالبًا لا تكون ردة فعلي الأولى «النموذج ضعيف»، بل: هل كانت تعليماتي غير جيدة بما يكفي؟ هل لم أوصل نظام الذاكرة جيدًا؟ هل لم أُجزّئ المهمة بما يكفي من الوضوح؟ هل لم أُحسن التوازي في العملية ككل؟
بعبارة أخرى، الكثير من المشاكل تبدو أقرب إلى كونها مسألة مهارة (skill issue) لا مسألة قدرات (capability issue).
تبدأ بالتفكير في مستودع البرمجيات بطريقة كلية. سابقًا تفكر «اكتب سطرًا» أو «نفّذ دالة»؛ الآن تفكر: «أعطِ هذه الميزة الجديدة للوكيل A»، «وأعطِ ميزة أخرى غير متعارضة للوكيل B»، «ودع وكيلًا ثالثًا يجري بحثًا أو يخرج أول خطة تنفيذ». ثم تتحرك كمدير مشروع عام بين المستودعات والفروع والمهام: تراجع، تدمج، وتعيد الإسناد.
Peter Steinberger يفعله بشكل متطرف جدًا. لديه صورة شهيرة أمامه صف شاشات، وعلى كل منها عدد من مثيلات Codex. قد يحتاج كل وكيل إلى العمل 20 دقيقة، لكنه يفتح عددًا كبيرًا في الوقت نفسه، ويتنقل بين مستودعات مختلفة، ويوزع عليهم العمل بلا توقف.
وبالتالي تتكوّن لديك «ذاكرة عضلية» جديدة: حين يكون وكيل ما يعمل، لم تعد ردة فعلك «انتظر حتى ينتهي»، بل «لماذا لا أفتح عدة آخرين؟» إذا كان لديك حصة رموز (tokens) لم تُستهلك، أو اشتراك لم يُستغل، أو قدرة حوسبة لم تُستخدم، فهذا يعني أن عنق الزجاجة هو أنت داخل هذا النظام.
المُضيف：
أي أن عنق الزجاجة في الماضي لكثير من مهام الهندسة كان «نقص القدرة الحاسوبية»؛ والآن صار فجأة «أنا نفسي أصبحت عنق الزجاجة».
Andrej Karpathy：
نعم، وهذا أيضًا سبب كون الأمر مُدمنًا جدًا.
حين كنتُ أدرس الدكتوراه، إذا لم تكن وحدات GPU تعمل بأقصى طاقتها، تشعر بالقلق: هناك قدرة حوسبة موجودة لكنك لا تستغلها. الآن انتقل هذا الإحساس إلى معدل تدفق الرموز (token throughput). إذا بلغت حصة Codex حدها، تفكر هل يجب أن تنتقل إلى Claude أو أدوات أخرى. يصبح السؤال الجوهري: كم من تدفق الرموز (tokens) أستطيع تحويله إلى نتائج فعّالة فعلًا؟
هذه مهارة جديدة جدًا، وهي فعلًا تفتح باستمرار حدودًا أعلى.
المُضيف：
إذا نظرنا للأمام سنة أو سنتين، كيف سيبدو هذا الإتقان (mastery)؟
Andrej Karpathy：
أعتقد أن الجميع بات يفترض وجود «وكيل واحد» افتراضيًا، والخطوة التالية طبيعيًا هي «كومة تعاون متعددة الوكلاء (multi-agent stack)». الجميع يستكشف: كيف تُشكّل عدة وكلاء فريقًا؟ كيف نُقسّم العمل بشكل معقول؟ كيف ندير الحالة والذاكرة؟
اتجاه آخر يهمني جدًا هو نظام وكلاء خلفي أكثر دوامًا وأقرب إلى العمل الدائم. كنتُ أستخدم تعبير claw لوصفه. الفكرة ليست أنك تفتح جلسة واحدة معه؛ بل إنه يعمل باستمرار داخل صندوق رمل (sandbox) خاص به، ينجز لك الأمور، مع ثبات أعلى وذاكرة أكثر تعقيدًا، لا مجرد ذاكرة مضغوطة عندما يوشك السياق على الامتلاء.
عندما تُبنى هذه الأنظمة، سترفع «دوامية» الوكيل إلى مستوى آخر.
المُضيف：
برأيك ما الأهم: تكامل الأدوات، أم ذاكرة أقوى ودوام أطول؟
Andrej Karpathy：
أرى أن كليهما مهم، وهما يعززان بعضهما بعضًا.
المميز جدًا في ما فعله Peter أنه لم يُحسّن شيئًا واحدًا فقط، بل ابتكر في طبقات عديدة في الوقت نفسه — الشخصية، والذاكرة، والتنسيق (orchestration)، وتكامل الأدوات، وسير العمل — يدفع الجميع معًا.
مثلًا، أصبحتُ أعتقد أكثر فأكثر أن «الشخصية» مهمة جدًا. شخصية Claude جيدة؛ تشعر وكأنه زميل يريد التعاون فعلًا؛ بينما وكيل البرمجة في Codex أكثر جفافًا وبرودة، أقرب إلى: «أنجزتُها لك، لكنني لا أهتم كثيرًا بما تبنيه أصلًا». أما ChatGPT فغالبًا أكثر تفاؤلًا، وأسهل في مجاراتك.
هذا الاختلاف ليس تجميليًا؛ إنه يؤثر مباشرة في تجربة التعاون. بل أشعر أحيانًا بشيء غريب: إذا مدحني Claude، أشعر أنني أريد فعلًا «استحقاق هذا المديح». إذا أعطيته فكرة نصف ناضجة، لا تكون ردود فعله كبيرة؛ لكن إذا كنتُ أنا نفسي مقتنعًا أن الفكرة جيدة فعلًا، يبدو أن تغذيته الراجعة تكون أقوى أيضًا. تريد أن تكسب اعترافه — قد يبدو هذا سخيفًا — لكنه يدل على أن طبقة الشخصية ليست هامشية، بل جزء من تجربة المنتج.
المُضيف：
بعيدًا عن هندسة البرمجيات، هل استخدمتَ هذه الأشياء فعليًا لعمل شيء ممتع؟
Andrej Karpathy：
نعم. في يناير هذا العام صنعتُ وكيلًا خلفيًا منزليًا، اسمه جنّي الأعمال المنزلية Dobby. هو عمليًا يتولى مراقبة البيت كله بدلًا مني.
أول شيء فعلته أنني طلبتُ منه أن يعثر على كل أنظمة المنزل الذكي الفرعية داخل الشبكة المحلية. فقام فعلًا بمسح عناوين IP، وعثر على Sonos، ثم اكتشف أن بعض الواجهات شبه غير محمية، فذهب يبحث بنفسه، ويقوم بهندسة عكسية لـ API، ثم عاد ليسألني إن كنتُ أريد التجربة. قلت له: شغّل أغنية في غرفة المكتب. فشغّل الموسيقى فعلًا. بثلاثة مطالبات (prompts) فقط.
بعد ذلك تولّى الإضاءة، وHVAC، والستائر، والمسبح، والجاكوزي، ونظام الأمن. لدي أيضًا كاميرا مواجهة للباب الخارجي؛ في المقدمة توجد مرحلة كشف تغيّر (change detection)، ثم تُرسل اللقطة إلى نموذج رؤية لتحليلها، وبعدها يرسل لي رسالة عبر WhatsApp مع صورة عند الباب، ويقول: توقفت للتو شاحنة FedEx عند الباب، ربما لديك طرد.
الإحساس هنا غريب جدًا وجديد جدًا: Dobby كأنه يحرس البيت بدلًا مني.
سابقًا كنتُ مضطرًا لاستخدام ستة تطبيقات مختلفة تمامًا للتحكم بهذه الأنظمة؛ الآن بالكاد أستخدمها. Dobby يتحكم بكل شيء باللغة الطبيعية. حتى لو لم أدفع هذا النمط إلى حدّه الأقصى بعد، فهو بالفعل مفيد جدًا وملهم جدًا.
المُضيف：
هل هذا يعني أن ما يريده الناس حقًا ليس بالضرورة هذه البرمجيات بحد ذاتها، بل وجود يستطيع تشغيل البرمجيات نيابة عنهم؟ لأن تعلم واجهة جديدة (UI) هو تكلفة أصلًا.
Andrej Karpathy：
إلى حد ما، نعم.
تصوّر الناس العاديين للذكاء الاصطناعي ليس «مولّد رموز (tokens) خام لـ LLM». بالنسبة لمعظم الناس، الذكاء الاصطناعي المتخيَّل أقرب إلى كيان له هوية وذاكرة، يمكنك أن تخبره بالأمور، فيتذكرها، ويواصل معالجة المشاكل نيابة عنك — كأنه كيان مختبئ خلف WhatsApp.
من هذه الزاوية، طبقة تجربة المستخدم في كثير من البرمجيات اليوم ربما لا ينبغي أن توجد أصلًا. كثير من التطبيقات في النهاية قد يجب أن تتدهور إلى مجموعة نقاط نهاية API (API endpoints) يستدعيها الوكيل، ويقوم الوكيل بلصقها كطبقة «غراء ذكي».
مثلًا، جهاز المشي الخاص بي لديه بالطبع تطبيق مرافق. لكنني لا أريد فتح صفحة أو تطبيق والضغط على أزرار كثيرة؛ ما أريد قوله حقًا هو: «سجّل لي كم مرة فعلتُ تمارين الكارديو هذا الأسبوع».
لذا أعتقد أن كثيرًا من الصناعات ستحتاج في النهاية لإعادة تهيئة: العملاء لن يكونوا بشرًا فقط، بل أيضًا وكلاء يتصرفون نيابة عن البشر. في المستقبل، ستصبح أدوات كثيرة أقرب إلى agent-first لا UI-first.
المُضيف：
إذًا لماذا لم تُوصل ذلك أكثر بالبريد والتقويم وغيرها من الأنظمة الأكثر مركزية؟
Andrej Karpathy：
جزء لأنني أنا نفسي أتشتت، وجزء لأنني ما زلتُ حذرًا جدًا بشأن هذا.
مثل البريد والتقويم وصلاحيات الحياة الرقمية كلها — إذا سلّمتها بالكامل، تصبح مسائل الأمان والخصوصية جدية جدًا. هذه الأنظمة قوية، لكن حوافها ما زالت خشنة، لذلك لا أريد أن أسلم منظومة حياتي الرقمية كاملة دون تحفظ.
المُضيف：
لننتقل إلى AutoResearch. عندما تذكر هذا المصطلح، ما الدافع الحقيقي وراءه؟
Andrej Karpathy：
الدافع الأهم هو: إخراج نفسي من عنق الزجاجة.
إذا كنتَ ما زلتَ داخل الحلقة (loop)، تراقب النتائج باستمرار ثم تقرر الخطوة التالية، فالنظام يتعطل عندك. في هذه المرحلة، اسم اللعبة هو الرفع (leverage) — توسيع الرافعة الخاصة بك. أريد أن أستثمر فقط كمية صغيرة جدًا من الرموز (tokens) بشكل متقطع، بينما يجري الكثير من العمل باستمرار باسمي.
لذلك AutoResearch بالنسبة لي ليس كلمة دعائية، بل اختبار حدّي: كيف أجعل المزيد من الوكلاء يعملون لمدة أطول، ويفعلون أكثر، دون أن أشارك طوال الوقت؟
لم تكن لدي توقعات قوية بأنه سيعمل فورًا. لكنني أجريت تجارب على ملعب GPT-2 الصغير الذي أعرفه عن ظهر قلب، وهو فعلًا استخرج لي أشياء لم أرها سابقًا — مثل تفاعلات معينة بين اضمحلال الأوزان (weight decay) والهايبر بارامترز (hyperparameters). كنت أظن أنني ضبطت ذلك المستودع بإحكام شديد، لكنه ما زال وجد بعض المكاسب.
هذا جعلني أدرك أن «التحسين الذاتي التكراري» (recursive self-improvement) ليس لعبة. مختبرات الطليعة بالطبع تتجه إلى هذا أيضًا. يمكنك أولًا إجراء الكثير من الاستكشاف على نماذج صغيرة، ثم تعميم النتائج إلى نماذج أكبر.
المُضيف：
أي أن سير البحث نفسه يجب أن يُعاد كتابته. لا ينبغي للباحث أن يستمر في القيام بكل هذا يدويًا.
Andrej Karpathy：
أعتقد ذلك. يمكن للبشر بالطبع أن يساهموا بالأفكار، لكن كثيرًا من التنفيذ، والبحث، والتجريب والخطأ، وعمليات التقييم ينبغي أن تكون مؤتمتة أصلًا.
بل يمكنك فهم منظمة بحثية على أنها مجموعة ملفات Markdown: تُعرّف كل الأدوار والعمليات والواجهات وكيفية التعاون وكيف تُعقد الاجتماعات وكيف تُختار المواضيع وكيف تُدمج النتائج. ما إن تُكتب «طريقة التنظيم» هذه ككود، يمكنك تحسينها، ومقارنتها، وتطويرها تطوريًا.
أحب جدًا فكرة: أن يكتب كثير من الناس نسخًا مختلفة من program MD، ثم تحت نفس ميزانية العتاد، ترى من يجلب تحسينًا أكبر. ثم تُغذي هذه النتائج للنموذج ليكتب نسخة أفضل تالية.
لذا تبدو العملية الآن كأنها تُرفع طبقة بعد طبقة: أولًا LLM، ثم وكيل، ثم متعدد الوكلاء، ثم تحسين التعليمات، ثم التحسين الفوقي (meta-optimization) لـ «التنظيم نفسه» و«program MD نفسه». ولأنها تتصاعد طبقة بعد طبقة بهذه الطريقة، تبدو وكأنها تتفرع بلا نهاية تقريبًا.
المُضيف：
لكن هذا على الأرجح لا ينطبق بالتساوي على كل المهام. أي أنواع المهام أنسب لـ AutoResearch؟
Andrej Karpathy：
الشرط الأهم هو أن تملك مؤشرات موضوعية واضحة يمكن تقييمها.
مثلًا، إذا أردت جعل نواة CUDA kernel أو جزء من كود النموذج أكثر كفاءة، فهذا مناسب جدًا. لأن الهدف واضح للغاية: السلوك نفسه، لكن أسرع، وأوفر، وأفضل.
لكن بمجرد أن لا تكون للمهمة معايير تقييم واضحة، ومؤتمتة، وقليلة الالتباس، يصبح من الصعب أتمتتها بالكامل. ليس لأن الوكيل لا يستطيع، بل لأنك لا تستطيع التحقق مما إذا كان ما فعله «أفضل» فعلًا.
كذلك، رغم أن نماذج اليوم قوية جدًا، إلا أن حوافها ما زالت خشنة. كثيرًا ما أشعر أنني أتحدث من جهة مع طالب دكتوراه بارع جدًا، ومن جهة أخرى كأنني أتحدث مع طفل في العاشرة. تشعر بالقوة، وتشعر كثيرًا بذلك التفاوت الغريب.
أحيانًا يهدر كمية هائلة من الحوسبة على مشكلة تراها أنت واضحة لدرجة لا تحتمل. هذا التعرّج (jaggedness) غريب جدًا. لدى البشر بالطبع نقاط ضعف، لكن نقاط الضعف المسنّنة في النماذج أكثر تطرفًا وأكثر قفزًا.
المُضيف：
هل يعني ذلك أن القدرة على الكود وبين «الذكاء» بمعناه الأوسع لا يتعممان معًا بنفس القوة التي يتخيلها كثيرون؟
Andrej Karpathy：
أعتقد أن هناك بالفعل نوعًا من فك الارتباط.
مثال نموذجي جدًا: النكات. اليوم إذا طلبت من أكثر النماذج تقدمًا أن تحكي نكتة، فغالبًا ستعطيك نكاتًا قديمة متداولة منذ سنوات كثيرة. مثل: “لماذا لا يثق العلماء بالذرات؟ لأنها تختلق كل شيء (make everything up).”
هذا يوضح شيئًا: في المجالات التي يغطيها مكافأة RL، والقابلة للتحقق، والقابلة للتحسين، سيكون التقدم سريعًا جدًا؛ لكن في المناطق التي لم تُحسّن خصيصًا، ولا توجد إشارة مكافأة واضحة لها، لن تصبح أقوى تلقائيًا وبنفس التزامن.
لذا لا أؤمن بأن «إذا صار الكود أقوى فكل القدرات الأخرى ستقوى مجانًا معه». قد يحدث بعض التعميم، لكنه ليس خطيًا ولا سلسًا إلى تلك الدرجة.
المُضيف：
هل يعني ذلك أيضًا أنه في المستقبل لن يكون لدينا نموذج واحد شامل، بل المزيد من «التمايز النوعي»؟
**Andrej Karpathy：