كاتب على Habr يحاكي «أونيغين» ساخرًا: عن أخطاء الوكيل يُسأل الإنسان

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

ما الذي أُعلن تحديدًا

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

معلومات عن المادة:

• الصيغة: مقال لأحد الكتّاب، في قسم AI في Habr
• تاريخ النشر: 10 أكتوبر 2026
• الصورة المحورية: المهندسة تاتيانا ومبرمج الـ vibe coding يفغيني
• الأطروحة الرئيسية: مسؤولية النتيجة لا تنتقل إلى الوكيل
• المنهج: الإشكالية والقيم والمعاني أولًا، ثم التفاصيل
• ما لا يتضمنه التمهيد: أدوات أو قياسات أو ممارسات محددة

لماذا تمسّ الأطروحة وترًا حساسًا

اقترح أندريه كارباثي مصطلح «vibe coding» في مطلع 2025. وصف به أسلوبًا يقبل فيه المطوّر تعديلات الوكيل دون أن يقرأها بتمعّن. هذا مقبول في النماذج الأولية ومشاريع نهاية الأسبوع. أما في بيئة الإنتاج، فيعني أن الشيفرة تدخل النظام دون أن يكون هناك شخص يفهمها.

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

نقاط القوة والضعف في الإطار المختار

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

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

ماذا يمكن للفريق أن يفعل بهذا

هذه ليست نصائح الكاتب، بل استنتاجاتنا من الأطروحة المعلنة. ويمكن تطبيقها منذ الآن:

• عيّنوا مالكًا لكل تغيير ينفذه الوكيل. يجب أن يكون شخصًا محددًا، لا «الفريق».
• اعتمدوا قاعدة: لا أدمج ما لا أستطيع شرحه بكلماتي.
• اكتبوا الاختبارات ومعايير القبول قبل تشغيل الوكيل. عندها تستند المراجعة إلى مواصفات، لا إلى انطباع بأن الشيفرة تبدو معقولة.
• احفظوا المهمة والـ prompts الأساسية إلى جانب الـ commit. بعد ستة أشهر سيساعدكم ذلك على فهم سبب خروج الشيفرة بهذا الشكل تحديدًا.
• افصلوا بين أنماط العمل. يمكن إنجاز النموذج الأولي بأسلوب «vibe»، أما شيفرة الإنتاج فلا بد من مراجعتها.

يستحق النص الكامل على Habr القراءة لمعرفة ما يحوّل إليه الكاتب القيم والمعاني. فإن تبيّن أن وراءها ممارسات محددة، فسنكون أمام مادة مفيدة. وإن لم يكن، فلن يبقى سوى محاكاة ساخرة جميلة تنطوي على ملاحظة صائبة.