Claude Code السلسلة التعليمية 3: لماذا تم توفير الطرفية فقط؟

1.3 لماذا كتابة الكود في الطرفية؟

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

الوقت الفعلي الذي تقضيه في "التفكير بكيفية الإصلاح" قد يكون أقل من النصف. النصف الآخر هو عمل آلي: البحث عن الملفات، تعديل المراجع، انتظار الترجمة، النقر بالفأرة.

وضع الذكاء الاصطناعي في الطرفية يهدف أولاً إلى تقليل هذا العمل الآلي.

الطرفية هي أقرب مكان للكود

قد تستخدم VS Code أو JetBrains أو Vim. بغض النظر عن اختيارك، لا يمكنك تجنب الطرفية أثناء كتابة الكود. تشغيل npm test، git log، grep، make build — هذه العمليات تتم طبيعياً في سطر الأوامر.

إذا كان مساعدك AI موجوداً في نفس الطرفية، تصبح الأمور أسهل. لست بحاجة لنسخ محتوى الملفات ولصقها في نافذة الدردشة، ولا لوصف "هناك كلاس اسمه UserService في ملف src/services/user.ts في السطر 42...". Claude Code يقف في جذر المشروع، وسيرى بنفسه.

هذه ضربة قاضية في السياق. عندما تطلب من Claude Code "أعد هيكلة معالجة الأخطاء في وحدة تسجيل الدخول"، سيقرأ فعلياً ملف auth/login.ts و errors.ts، ويجد جميع الأماكن التي تستدعيها، ويعدلها مباشرة. لا حاجة لوسيط نقل.

تحررك من دور "المشغل"

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

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

لماذا ليس إضافة محرر؟

قد تسأل: لماذا لا نستخدم إضافة AI مباشرة في المحرر؟

إضافات المحرر مفيدة بالتأكيد، والعديد من الفرق تستخدمها. لكن Claude Code في الطرفية له مزايا يصعب استبدالها بالإضافات:

1. لا قيود المحرر. تستخدم VS Code اليوم، وغداً تتحول إلى Neovim، أو حتى على خادم بعيد بدون واجهة رسومية، Claude Code يعمل. لا علاقة له بأداتك المختارة.
2. يمكنه فعل أشياء "خارجة". في الطرفية، يمكنه تنفيذ أي أمر شيل. هذا يعني حدود قدرته أوسع بكثير — يمكنه تشغيل حاوية Docker للتحقق من ترحيل قاعدة البيانات، سحب فرع بعيد وفحص التعارضات، تشغيل اختبارات e2e تلقائياً بعد تعديل الكود. هذه الأمور، إضافات المحرر عادة لا تجرؤ على فعلها، أو لا تستطيع أبداً.
3. معالجة دفعية وأتمتة. يمكنك وضع Claude Code في سكريبت، ليعالج عشرات المستودعات، ينتج توثيقاً بشكل دفعي، يعالج Issues تلقائياً. هنا لم يعد "مساعداً"، بل حلقة في خط الإنتاج.

مثال صغير من تجربتي

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

بدلاً من ذلك، شغلت Claude Code في دليل المشروع وقلت له: "رحّل هذا المشروع تدريجياً إلى الوضع الصارم لـ TypeScript، عدّل بضعة ملفات في كل مرة، وبعد كل دفعة شغّل tsc --noEmit، وإذا حدث خطأ أصلحه بنفسك حتى ينجح."

في النصف ساعة التالية، كنت أفعل شيئاً واحداً فقط: أتفرج على الفروق التي يعدلها، وأومئ برأسي أو أهزّه. أحياناً أقول له "لا تستخدم any هنا، عرّف interface"، فيستمر في العمل. أخيراً، نجح التجميع، وكان أسرع بعدة مرات مما توقعت.

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

باختصار، الطرفية أعطت AI أيدياً وأرجلاً

وضع AI في الطرفية يمنحه القدرة على التنفيذ، وليس فقط الاقتراح.

يجعل مستودع الكود الخاص بك ليس مجرد نصوص يمكن قراءتها، بل بيئة حقيقية يمكن لـ AI "لمسها" وتعديلها والتحقق منها. هذه قفزة هائلة.

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