Artëm بنى Stopilot: المحرر الذي يرفض كتابة الكود
بنى Artëm Stopilot، وهو محرر أكواد يرفض كتابة الكود حتى يصوغ المطور المهمة بكلمات بشرية. هذا رد على مشكلة: Cursor يكتب بسرعة كبيرة، والمطورون لا يستطيعون مواكبت
بنى آرتيم Stopilot في نهاية الأسبوع — محرر أكواد يرفض العمل. على أي استفسار، يجيب: "أولاً، اصغ المهمة بكلمات بشرية". في غضون 8 أشهر، وصل المشروع إلى 1.29 مليون روبل شهرياً.
لماذا أصبح Cursor مشكلة
القصة المعتادة حول أدوات الذكاء الاصطناعي تبدو هكذا: يفتح المطور Cursor، ويبني SaaS في نهاية الأسبوع، وينشر لقطة شاشة لإيرادات البيع المتكررة، ويشرح أن الشيء الأساسي هو التحقق السريع من الفرضيات دون التفكير. لكن آرتيم لاحظ شيئاً مختلفاً. حل Cursor مشكلة سرعة كتابة الأكواد، لكنه خلق مشكلة جديدة: يتم كتابة الأكواد أسرع مما يمكن فهمها. يحصل المطور على أكواد مُنتجة ولا يعرف كيفية صيانتها أو توسيع نطاقها.
كيف يعمل Stopilot
الفكرة الأساسية بسيطة جداً. لا يُنتج المحرر أكواداً حتى يشرح المطور المهمة في فقرة واحدة. إنه ليس بديلاً عن Cursor، بل هو مكمّل للفرق التي سئمت من جبال من الأكواد غير المفهومة. تفرض الأداة على المطور أن يفكر أولاً، ثم يكود.
- توقف الرغبة الفورية في كتابة الأكواد مباشرة
- تفرض صياغة المتطلبات بكلمات بشرية
- تقدم الحل فقط بعد ذلك
- تُباع لشركات لديها فرق تطوير كبيرة
الأشهر الثمانية الأولى
بنى آرتيم النموذج الأولي في نهاية الأسبوع. في غضون 8 أشهر، وصل Stopilot إلى 1.29 مليون روبل شهرياً. يبيع للفرق التي استأجرت عدداً كبيراً من المطورين بعد موجة أدوات الذكاء الاصطناعي وتدير الآن كميات ضخمة من الأكواد المُنتجة التي لا يستطيع أحد صيانتها. لا يتعلق الأمر بالنمو السريع، بل بعملية تطوير صحية.
ماذا يعني هذا
ليست جميع أدوات الذكاء الاصطناعي مطلوبة لكتابة أكواد تلقائياً. أحياناً، يجب أن يساعد الذكاء الاصطناعي المطور على فهم المهمة بدلاً من أن يتولاها. أثبت Stopilot أن هناك طلباً على انتقاد وتيرة الأكواد المُنتجة — وهو أكبر مما كان متوقعاً.