إذا كنت تعيش بالفعل داخل Claude Code، فأنت تعرف الأمور الواضحة (النسخة الأصلية من الطرف، حلقة ضيقة، مشاهدة تشغيلها، سجلات grep، تحديث، إعادة تشغيل، التزام). إليك السؤال الأكثر إثارة للاهتمام: لماذا يشعر أن Codex يحاول اللحاق بالركب، دون أن يكتفي باستنساخ أجواء وكيل الطرفية التفاعلي؟ الكودكس يعتمد على التفويض أولا، وليس البرمجة الزوجية أولا. القوة الخارقة لكلود كود هي حلقة التحكم التفاعلية الضيقة: أنت والعميل تشاركان قمرة قيادة واحدة. إنه قابل للمشاهدة. تتدخل في منتصف الرحلة. تتوجه قبل أن يحرق الزمن في طريق سيء. هو في الأساس وكيل كامتداد لقوقعتك. رهان كودكس مختلف: وكيل كزميل موازي يعمل على جهاز الكمبيوتر الخاص به هذا الإطار يوحي بمجموعة من نتائج المنتج التي يسهل تفويتها إذا قارنت فقط مخرجات النموذج: 1) عدم التزامن كميزة (وليس أثرا جانبيا) كودكس مصمم لتسليم مهمة، ثم القيام بشيء آخر، ثم العودة إلى قطعة أثرية قابلة للمراجعة مركز الجاذبية يصبح PRs/تفاضل. لهذا السبب ترى عبارات مثل "تفويض"، "عقلية الوفرة"، "صف مجموعة من المهام". سير العمل هو: إنشاء N وظيفة، ثم مراجعة/دمج. 2) العزل والصندوق الرملي ليسا فقط بنية تحتية، بل تجربة مستخدم. كل مهمة تعمل في بيئة معزولة خاصة بها تغير نموذج الثقة: يمكن للوكيل إجراء الاختبارات، تعديل الملفات، توليد الالتزامات دون تلوث مساحة العمل المحلية لديك. تحصل على حدود أمان (وغالبا شروط محافظة) تجعل من السهل أن تترك الأمر يفعل ما يبدو. 3) قابلية الدمج هي المقياس المستهدف الفعلي. يشعر كود بالراحة لأن الحلقة تتقارب. بينما كودكس يحسن صراحة ليعود بشيء يمكنك دمجه. لذا يصبح شكل المقارنة أوضح: كود كلود = الأفضل عندما تحتاج المهمة إلى استدعاءات حكم في منتصف الطريق، والمقاطعات السريعة، والتوجيه البشري. إنها "حلقة قمرة القيادة الضيقة". كودكس = أفضل وقت يمكن فيه تفويض المهمة، وموازاتها، وإعادتها كقطع أثرية قابلة للدمج. إنه "زميل عمل لديه مساحة عمل خاصة به". الحدود الأعمق ليست جودة الإكمال التلقائي. إنها حلقات تحكم شاملة مع التحقق: السياق -خطة > -> التعديلات -تنفيذ > -> التحقق -> القطعة القابلة للمراجعة والخندق الحقيقي يبنى عند التحقق والطعم: - هل يجري الاختبارات الصحيحة؟ - هل يفسر فشل CI بشكل صحيح؟ - هل تنتج فروقات صغيرة تتناسب مع تعبيرات مستودعتك؟ - هل يعيد شيئا يمكنك دمجه بشكل موثوق بدون رعاية أطفال؟ توقعي أننا سنتقارب في سير عمل هجين: حلقة كود تفاعلية من كلود للعمل الغامض + وظائف الكودكس المتوازية المجمعة في صندوق الرمل لمعدل النقل. الفائز هو من يبني أفضل راوتر عبر تلك الأوضاع ويجعل التفويض يبدو موثوقا مثل حالة git.

لعبة Tinker من Thinking Machines وهي GA هي واحدة من أولى الإطلاقات منذ فترة التي تشعر فعلا وكأنها تدريب كمنتج. معظم واجهات برمجة التطبيقات المستضافة (بما في ذلك أسلوب OpenAI) رائعة عندما كل ما تحتاجه هو تجربة SFT نظيفة، لكن بمجرد أن تريد القيام بأي شيء حتى بسيط: مناهج مخصصة، تقييم عبر الإنترنت، تدريبات بعد المكافآت على شكل مكافأة، حلقات شبيهة بالتعلم الواقعي، حيل غريبة في التجميع/التعبئة: تصل إلى السقف بسرعة وتنتهي بإعادة بناء نصف مجموعة تدريب. Tinker يقلب ذلك أساسا: يعطيك واجهة برمجة تطبيقات تدريب مع عناصر أساسية منخفضة المستوى (عينة / forward_backward / optim_step / save_state)، بحيث تكتب الحلقة التي تريدها فعلا، وهم يتولون الأجزاء التي تتحول عادة إلى شهر من العمل في البنية التحتية (الجدولة، التكبير، الإعاقات، استعادة الفشل، لماذا توقفت هذه الوظيفة عند 93٪). كما أنها تعتمد على LoRA أولا، وهو بالضبط الإعداد الافتراضي المناسب للتخصيص: تقوم بالتكرار بسرعة أكبر، وتبقى التكاليف متوازنة، ويمكنك الاحتفاظ بعدة نسخ دون تكرار نقاط تفتيش ضخمة، ويصبح التقديم أكثر عملية بكثير. وأحب أيضا أن القصة ليست غامضة: يمكن ل LoRA حقا أن تضاهي الضبط الدقيق الكامل في العديد من مجموعات البيانات بعد التدريب عندما تضبط بشكل صحيح، لكن إذا كنت تحاول حشر تحول سلوكي كبير في محول صغير (أو أن مجموعة بياناتك تفوق السعة الفعالة للمحول بشكل كبير)، ستشعر بذلك العنق الزجاجي ولن يختفي فجأة. العيب الحقيقي الوحيد الذي أراه هو أرضية النماذج الصغيرة: إذا كان هدفك هو SLMs ذات الحافة الصغيرة، فغالبا هذه ليست الأداة. مع ذلك، أنا متحمس لذلك. لا أستطيع الانتظار لرؤية ما سيبنيه الناس.

بعد ثلاث سنوات في CRV، أنضم إلى فريق مؤسس سترايكر فينتشر بارتنرز، حيث أقود استثمارات الشركة في مجال الذكاء الاصطناعي. شكرا @BusinessInsider على تغطية الانتقال.