آرتيوم يبتكر Stopilot: محرر أكواد يرفض كتابة الكود

أنشأ آرتيوم Stopilot خلال عطلة نهاية أسبوع واحدة. وهو محرر أكواد يرفض العمل: يرد على أي أمر نصي (prompt) بعبارة «صِغ المهمة أولًا بكلمات بشرية». وبعد 8 أشهر، بلغت إيرادات المشروع 1,29 مليون روبل شهريًا.

لماذا أصبح Cursor مشكلة

تبدو القصة المعتادة عن أدوات الذكاء الاصطناعي على النحو التالي: يفتح المطوّر Cursor، ويبني منتج SaaS خلال عطلة نهاية الأسبوع، وينشر لقطة شاشة للإيرادات الشهرية المتكررة (MRR)، ثم يشرح أن الأهم هو اختبار الفرضيات بسرعة دون تفكير مطوّل.

لكن آرتيوم لاحظ أمرًا مختلفًا. فقد حلّ Cursor مشكلة سرعة كتابة الكود، لكنه خلق مشكلة جديدة: يُكتب الكود بوتيرة أسرع مما يستطيع المطوّرون فهمه. فيحصل المطوّر على كود مولَّد ولا يعرف كيف يصونه أو يوسّع نطاقه.

كيف يعمل Stopilot

الفكرة الأساسية بسيطة. لا يولّد المحرر أي كود إلى أن يشرح المطوّر المهمة في فقرة واحدة. وهو ليس بديلًا عن Cursor، بل أداة مكمِّلة للفرق التي أرهقها تراكم الكود الذي لا يفهمه أحد. فالأداة تُلزم المطوّر بأن يفكر أولًا ثم يكتب الكود.

• يكبح الدافع إلى كتابة الكود فورًا
• يُلزم بصياغة المتطلبات بكلمات بشرية
• لا يقترح الحل إلا بعد ذلك
• بِيع لشركات لديها فرق تطوير كبيرة

الأشهر الثمانية الأولى

بنى آرتيوم النسخة الأولية من المنتج (MVP) خلال عطلة نهاية أسبوع. وبعد 8 أشهر، بلغت إيرادات Stopilot 1,29 مليون روبل شهريًا. ويشتري المنتج فرق وشركات وظّفت عددًا كبيرًا من المطوّرين بعد موجة أدوات الذكاء الاصطناعي، وتدير اليوم كمًّا هائلًا من الكود المولَّد الذي لا يقدر أحد على صيانته. والمسألة هنا لا تتعلق بنمو سريع، بل بعملية تطوير سليمة.

ماذا يعني ذلك

لا ينبغي أن تكتب كل أدوات الذكاء الاصطناعي الكود تلقائيًا. ففي أحيان كثيرة يجب أن يساعد الذكاء الاصطناعي المطوّر على فهم المهمة، لا أن يستولي عليها. وقد أظهر Stopilot أن هناك طلبًا على نقد وتيرة الكود المولَّد، وأن هذا الطلب أكبر مما كان يُعتقد.