«أداة برمجة AI» تشمل عدة منتجات مختلفة حقًا. فهي لا تتنافس على نفس المهمة، واختيار الفئة الخاطئة يُعد خطأً أغلى ثمنًا من اختيار المنتج الخاطئ ضمن فئة واحدة.
أربع فئات
| الفئة | أمثلة | مصممة لـ |
|---|---|---|
| الإكمال التلقائي | GitHub Copilot | إكمال السطر الذي تكتبه |
| مساعدي IDE | Claude Code، Cursor | مطور يعمل على مهمة مع إشراف مباشر |
| جلسات الوكلاء | Codex، Claude Code على الويب، وكيل برمجة GitHub Copilot، Devin | تكليف وكيل بمهمة واحدة، ثم فحص ما ينتج عنه وتوجيهه |
| أدوات النمذجة الأولية | Lovable، v0، Bolt، Replit Agent | تحويل فكرة إلى شيء يمكن رؤيته |
| تسليم المنتجات للإنتاج | Coroid | تعديل قاعدة الكود الحالية لتتوافق مع المعايير التي تحددها مرة واحدة |
النوعان الأولان يضعان النموذج بجانب المطور. تنقل جلسات الوكلاء العمل بعيدًا عن جهاز المطور، لكن الشخص لا يزال يختار كل مهمة، ويوجهها، واختبار ما ينتج عنها، ويقرر إنهائها. أما أدوات النمذجة الأولية فتبنى شيئًا جديدًا بسرعة. Coroid لا يقوم بأي من هذه الأمور: فهو ينفذ عملية حددتها مرة واحدة على كل تغيير في قاعدة كود تعمل بها بالفعل، بغض النظر عن من طلب ذلك.
أدوات نمذجة أولية
تحويل فكرة إلى شيء يمكن رؤيته
إكمال تلقائي
إكمال الجملة التي تكتبها
مساعدات IDE
مطور يعمل على مهمة ما
جلسات الوكلاء
مهمة تُسلَّم ثم تُفحص وتُتابع من قبل من بدأها.
Coroid
معيار واحد لكل تغيير، بغض النظر عن من طلبه.
الجلسة والمصنع مشكلتان مختلفتان
جلسات الوكلاء هي أقرب مقارنة، لأنها تنتهي أيضًا بطلب سحب. الفرق يكمن في ما يحمل العملية.
تعمل الجلسة تحت إشراف الشخص الذي يوجهها. يقرر أحدهم ما سيتم العمل عليه، ويكتب التعليمات، ويفتح المعاينة، ويكتشف ما هو معطوب، ويكتب التعليمات التالية، ويقرر متى ينتهي الأمر. والنتيجة تعتمد على انتباه ذلك الشخص في ذلك اليوم، ولا يمكن لأحد سوى من يستطيع القيام بكل ذلك تشغيل جلسة كهذه: وفي الواقع، مطور.
يعمل المصنع وفقًا لعملية حددتها مرة واحدة. Coroid يحتفظ بالخطوات داخل النظام — المواصفات، واختبارات ضد معايير القبول، ومراجعة، سياسات الجودة وقواعد الموافقة — وتطبيقها على كل تغيير. ولأن العملية ليست من مسؤولية طالب الطلب، يمكن لأي شخص أن يطلبها.
| جلسة الوكلاء | Coroid | |
|---|---|---|
| من يمكنه طلب العمل؟ | من يستطيع تشغيل الأداة وتقييم الاختلافات | أي شخص في الشركة، بلغة بسيطة |
| ما الذي يبدأ العملية؟ | شخص واحد، مهمة واحدة في كل مرة | قائمة انتظار واحدة تُغذى من قبل الأشخاص، أدوات تتبع المشكلات و عمليات الأتمتة |
| من يختبر النتيجة؟ | الشخص الذي بدأ العملية | وكيل اختبار جودة، ضد معايير القبول |
| ما الذي يقرر إنهاء العمل؟ | من يقرأ الاختلافات | سياسات الجودة الخاصة بك، ثم موافقة شخص |
| نفس نوع المهمة في الشهر التالي | بنفس جودة من يوجهها حينها | نفس العملية ونفس الفحوصات |
| ما الذي يتم الاحتفاظ به؟ | نسخة محفوظة | المنشأ: من طلب، ما تم اتخاذه من قرارات، كل تشغيل وكل موافقة |
الجلسات مفيدة للاستكشاف: العمل على مشكلة غير مألوفة مع وكيل، أو تغيير تريد تشكيله أثناء العمل. أما العمل الذي يجب أن يلتزم بمعايير ثابتة في كل مرة، فمرره عبر Coroid. ويتلاقى النوعان عند pull request: مع تطبيق GitHub، يمكن لـ Coroid تشغيل نفس الفحوصات والمراجعة على طلبات السحب التي يفتحها مطوريك باستخدام وكلائهم الخاصين. اطلع على مراجعة طلبات السحب.
النمذجة الأولية والإنتاج مشكلتان مختلفتان
هذا التمييز يستحق التوضيح، لأن أدوات النمذجة الأولية ممتازة ومن السهل الاعتقاد بأن نفس النهج ينطبق على عمل الإنتاج.
تُركّز النمذجة الأولية على سرعة الوصول إلى شيء مرئي. تبدأ من العدم، لا توجد بنية تحتية قائمة يجب احترامها، ولا مجموعة اختبارات يجب أن تظل تمر، ولا اتفاقيات يجب مطابقتها، ولا أحد يعتمد على النتيجة بعد. القيود ستؤخرك فقط — وبشكل صحيح، تفرض هذه الأدوات قيودًا قليلة جدًا.
أما عمل الإنتاج فهو يقوم بشكل كامل على القيود. الكود موجود بالفعل ويحتوي على قرارات متخذة مسبقًا. أشياء أخرى تعتمد عليه. هناك اختبارات يجب أن تظل تمر، واتفاقيات يجب مطابقتها، ومتطلبات أمنية وتوافقية، وعملية مراجعة يجب استيفاؤها قبل شحن أي شيء.
Coroid مبني حول هذه القيود وليس حول تجنبها:
| النمذجة الأولية | Coroid | |
|---|---|---|
| نقطة البداية | صفحة فارغة | مستودعك الحالي |
| الوجهة | نسخة تجريبية قيد التشغيل | طلب سحب من pull request على فرع ما |
| التحقق | هل يبدو ذلك صحيحًا؟ | مجموعة اختباراتك، بوابات الجودة، مستقل ضمان الجودة |
| الحوكمة | تصميم بسيط للغاية | السياسات، قواعد المراجعة، سجل التدقيق |
| مراجعة | أنت تلقي نظرة عليه | يقوم مهندسوك بمراجعة الاختلافات، تحت حماية الفرع الخاص بك |
| نجاح | الفكرة تستحق التنفيذ | التغيير آمن للدمج |
إنها تتناسق بشكل جيد
الأمر ليس اختياريًا؛ الاثنان يتناسقان معًا بطريقة واضحة:
نموذج أولي لتحديد ما يجب بناؤه. التحقق من صحة فكرة، استكشاف واجهة مستخدم، تقديم شيء ما لمسؤول قبل نهاية الأسبوع — أداة النمذجة الأولية ستتفوق على Coroid في كل هذه الحالات، ويجب عليك استخدامها.
ثم قم ببنائه في المكان الذي ستحافظ عليه. بمجرد تحديد الفكرة، ينتقل العمل إلى مجموعة الكود التي تعمل بها فعليًا، مع اتفاقياتك واختباراتك وعملية المراجعة الخاصة بك. هذه هي مهمة Coroid.
يجيب النموذج الأولي على سؤال هل يجب أن نبني هذا؟. يجيب Coroid على سؤال بناؤه بشكل صحيح في النظام الذي لدينا بالفعل.
متى لا تستخدم Coroid
الصراحة في هذا الأمر أكثر فائدة من قائمة الميزات:
- أنت تقوم بالتحقق من صحة فكرة، وليس إطلاقها. استخدم أداة نمذجة أولية. ينتج Coroid طلب سحب تمت مراجعته لمجموعة كود حقيقية، وهو عبء غير ضروري لشيء قد تتخلى عنه غدًا.
- تريد رؤية شيء مرئي في دقائق. ينتج Coroid طلبات سحب، وليس نسخًا تجريبية مباشرة.
- تريد مبرمجًا مساعدًا. إذا أردت البقاء في محررك والعمل جنبًا إلى جنب مع نموذج سطرًا بسطر، فهذا مساعد IDE. يعمل Coroid على وحدات عمل كاملة بينما تكون مشغولًا بأمور أخرى.
- تريد استكشاف مشكلة أثناء العمل. إذا تشكل التغيير أثناء عملك عليه، فقم بتوجيه جلسة الوكيل. يعمل Coroid وفقًا لمواصفات محددة ويحافظ على النتيجة متوافقة معها.
- ليس لديك مستودع بعد. يحتاج Coroid إلى مكان للعمل — انظر إلى ربط كودك.
ما ينتج عن التركيز على الإنتاج
بعض الأمور في Coroid تبدو وكأنها عبء حتى تراها كمتطلبات إنتاج:
- العمل مُحدد مسبقًا قبل بنائه، لذا هناك ما يمكن التحقق منه ضده، ويمكن لأي شخص طلبه دون معرفة كيفية بنائه.
- يتم التحقق من خلال وكيل لم يكتب الكود.
- لا يصل أي شيء إلى فرعك الافتراضي بدون pull request.
- تُطبق السياسات وبوابات الجودة في مسار التنفيذ، وليس كاقتراحات.
- يتم تسجيل كل عملية تنفيذ — التكلفة، النموذج، الخطوات والأدلة.
لا شيء من ذلك يستحق الدفع مقابل نموذج أولي مؤقت. كله يستحق الدفع مقابل نظام تعمل به شركتك.