Artëm بنى Stopilot: المحرر الذي يرفض كتابة الكود

بنى آرتيم Stopilot في نهاية الأسبوع — محرر أكواد يرفض العمل. على أي استفسار، يجيب: "أولاً، اصغ المهمة بكلمات بشرية". في غضون 8 أشهر، وصل المشروع إلى 1.29 مليون روبل شهرياً.

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

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

كيف يعمل Stopilot

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

• توقف الرغبة الفورية في كتابة الأكواد مباشرة
• تفرض صياغة المتطلبات بكلمات بشرية
• تقدم الحل فقط بعد ذلك
• تُباع لشركات لديها فرق تطوير كبيرة

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

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

ماذا يعني هذا

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