«الفايب كودينغ» بلا نفايات عصبية: كيف سرّع فريق targetai التطوير 12 ضعفًا

«الفايب كودينغ» لا يعني أن تترك الذكاء الاصطناعي يكتب الشيفرة كلها ثم تضغط زر «النشر». إنه القدرة على التعامل مع النماذج اللغوية بوصفها مطورًا مبتدئًا (junior) سريعًا جدًا لكنه يهلوس أحيانًا: تطرح عليه الأسئلة الصحيحة، وتتحقق من مخرجاته، وتحتفظ في ذهنك بالرؤية المعمارية للمشروع. أمضى فريق targetai عدة أشهر في إتقان هذا التوازن على مشاريع حقيقية، وسجّل النتيجة: تسارع بمقدار 8–12 ضعفًا دون خسارة في الجودة، بشرط أن يتم كل شيء على الوجه الصحيح.

أدخل أندريه كارباثي مصطلح «الفايب كودينغ» إلى التداول في مطلع عام 2025. الفكرة بسيطة: بدلًا من كتابة كل سطر يدويًا، يصف المطور نيّته بلغة طبيعية، وتتولى أداة LLM، مثل Cursor وGitHub Copilot وClaude Code وCline، توليد التنفيذ. وتزداد سرعة التكرار (iterations) أضعافًا: يمكن إنجاز أول نموذج أولي عامل خلال ساعات بدلًا من أسابيع.

لكن المشكلة أن انتشار هذا النهج جاء معه وجهه المظلم: «النفايات العصبية». وهي شيفرة تبدو مقنعة وتُترجَم بنجاح وتجتاز الاختبارات الأساسية، لكنها تتحول بعد ثلاثة أشهر إلى كتلة فوضوية يتعذّر صيانتها، إذ لا يفهم أحد في الفريق لماذا كُتب جزء معيّن منها بهذه الطريقة. فالـLLM لا يشرح قراراته المعمارية، بل يتخذها فحسب.

طرح مهندسو targetai على أنفسهم سؤالًا: هل يمكن تنظيم العمل مع LLM بحيث نحصل على السرعة دون تراكم الدين التقني؟ جوابهم: نعم، لكن ذلك يتطلب ممارسات محددة.

الأولى: يعمل LLM بأفضل صورة في المهام ذات السياق المحدود بدقة. فبدلًا من «نفّذ ميزة المصادقة»، يُطلب منه «نفّذ الدالة validateToken في الملف auth/utils.ts، بحيث تستقبل سلسلة JWT وتُعيد userId، أو null إذا كان الرمز غير صالح».

الثانية: لا يجوز تفويض مراجعة الشيفرة (code review) إلى النموذج نفسه. فالمطلوب إنسان يفهم ما يراجعه بالضبط، ولماذا تُعدّ شيفرة معيّنة سيئة، لا مجرد كيف تبدو.

الثالثة: تُتخذ القرارات المعمارية قبل أن يبدأ الذكاء الاصطناعي بتوليد التنفيذ. فالذكاء الاصطناعي منفّذ، لا مصمّم.

أما أرقام التجارب فهي: انخفضت دورة تطوير الوظائف الجديدة بمقدار 8–12 ضعفًا، من عدة أيام إلى عدة ساعات. وقلّ عدد التكرارات قبل النشر. والأهم من ذلك، أن مستوى الحوادث بعد النشر في بيئة الإنتاج لم يرتفع. وهذا ردّ على أكثر المخاوف شيوعًا: أن التسارع بالذكاء الاصطناعي يعني حتمًا زيادة عدد الأخطاء في بيئة الإنتاج. ومع المنهجية الصحيحة، لا يعني ذلك. ولا يوجد في targetai منصب مستقل لمهندس ذكاء اصطناعي (AI-engineer) أو مهندس تعليمات (prompt engineer): فقد توصّل الفريق إلى هذه الممارسات تدريجيًا، عبر الأخطاء والتكرارات.

عمليًا، يبدو النهج على النحو التالي. يستخدم كل مطوّر LLM بوصفه شريكًا شخصيًا في البرمجة الثنائية، لكن بقواعد صارمة. لا نسخ لشيفرة مولَّدة دون قراءتها سطرًا سطرًا. ولا طلبات مبهمة: ثلاثة تعليمات (prompts) دقيقة أفضل من تعليمة واحدة فضفاضة. وتُكتب الاختبارات قبل توليد التنفيذ، وهذا يستبعد فورًا الحلول غير العاملة منذ مرحلة صياغة التعليمات. وتُحفظ وثائق قاعدة الشيفرة الداخلية بصيغة مقروءة آليًا وتُحمَّل في السياق تلقائيًا، وهو ما يرفع دقة التوليد بصورة ملحوظة في المهام الخاصة بمجال العمل.

لقد تجاوز «الفايب كودينغ» بوصفه ممارسة دورة الضجيج الإعلامي، وبات يتحول إلى مهارة هندسية أساسية، مثل القدرة على قراءة stack trace أو كتابة pull request واضح. لم يعد السؤال هل نستخدم النماذج اللغوية في التطوير، بل إلى أي مدى نستخدمها بوعي. وتُظهر تجربة targetai أنه، مع مسارات عمل مبنية بشكل صحيح، لا يحلّ مساعد الذكاء الاصطناعي محل المهندس، بل يضاعف إنتاجيته أضعافًا. وثمن هذه المضاعفة هو الانضباط والتفكير النقدي والاستعداد لعدم الوثوق بشيفرة جميلة لمجرد أنها كُتبت بسرعة.