سير عمل Greenfield في Claude Code: من مستودع فارغ إلى الشريحة الأولى

ما الذي تحاول تجنبه عند البدء من مشروع جديد (greenfield)

البدء من مستودع فارغ يبدو وكأنه حرية، لكنه غالبًا ما يتحول إلى زحام فوضوي: ملفات مولّدة بكثرة، بناء نصف عامل، ولا مكان واضح لوضع التغيير التالي. الهدف من سير عمل Claude Code للبدء من الصفر هو تجنّب فوضى الأسبوع الأول تلك.

بعض الإخفاقات تتكرر دائمًا:

• شيفرة “تعمل على جهازي” لأن الإعداد يعيش في ذاكرة شخص ما وليس في سكربتات.
• هيكل مجلدات يعكس ترتيب الإنشاء بدلًا من الطريقة التي يجب أن ينمو بها التطبيق.
• حلقة حيث كل طلب جديد يعيد كتابة اختيارات سابقة، فلا شيء يستقر.

القرارات المبكرة تُصبح مؤلمة لعكسها لأن كل شيء يبنى فوقها. بنية مربكة تستمر في التعزيز. بنية بناء يدوية تتحول إلى عشر إعدادات مختلفة. إذا لم تؤمّن أمر تطوير بسيط مبكرًا، لن تستطيع التمييز إن التغيير كسر التطبيق أم كسر البيئة فقط.

عند قول هذا المقال "تطبيق يعمل"، نعني شيئًا محددًا: أمر واحد يشغّل المشروع، يطبع مخرجات متوقعة، ويفشل بصوت واضح عندما ينقص شيء. يجب أن تكون قادرًا على حذف التثبيت المحلي، استنساخ المستودع، تشغيل ذلك الأمر، ورؤية نفس النتيجة.

"الشريحة العمودية" هي أصغر ميزة من طرف إلى طرف تثبت أن التطبيق حقيقي. ليست مجرد نموذج واجهة مستخدم. ليست جدول قاعدة بيانات لوحده. إنها مسار رفيع عبر كامل النظام، مثل صفحة مع نموذج، نقطة نهاية API واحدة تحفظ بيانات، كتابة وقراءة من قاعدة بيانات، ونتيجة مرئية تظهر مرة أخرى على الصفحة.

إذا استطعتم تشغيل التطبيق بأمر واحد وشحن شريحة عمودية واحدة، فأنتم تملكون قاعدة يمكن التكرار عليها دون تخمين.

قرّر الشريحة الأولى قبل أن تولّد أي شيء

شريحة أولى واضحة تحافظ على النظام في المستودع وتركيز الطلبات. هذه اللحظة لتقرر ما تريد عرضه من طرف إلى طرف، وليس ما تأمل أن يصبح عليه المنتج الكامل.

اختر أصغر قصة مستخدم تثبت أن التطبيق يعمل على طول المسار. شريحة جيدة تمس الواجهة والبيانات وعملًا واحدًا حقيقيًا. مثال: "كمستخدم، أستطيع إضافة مهمة ورؤيتها تظهر في القائمة بعد التحديث." إنها صغيرة، لكنها تجبرك على التعامل مع التوجيه، التحقق من الصحة، التخزين، وشاشة أساسية.

اختر منصة هدف واحدة للأسبوع الأول والتزم بها. إذا بدأت بالويب، اعمل ويب فقط. لا تضف شاشات موبايل "لمجرد الاحتمال". حتى لو خططت لاستخدام منصة مثل Koder.ai لاحقًا، ستحقق نتائج أفضل إذا بقيت الشريحة الأولى ضمن مسار واحد (React web، أو Go API، أو Flutter).

عرّف ما يعنيه "مكتمل للأسبوع الأول" بمصطلحات بسيطة:

• يعمل محليًا من استنساخ جديد بأمر واحد
• ميزة واحدة عاملة يمكنك الانتقال عبرها من طرف إلى طرف
• الأخطاء تظهر برسالة مفهومة للإنسان (ليس تتبّع مكدس)
• البيانات تحفظ في مكان بسيط (حتى قاعدة بيانات محلية)

ثم اكتب ثلاث لا-أهداف تحمي النطاق. مثال: لا مصادقة، لا نظام سمات، لا مهام خلفية.

بمجرد تدوين تلك القرارات، يمكن أن يكون طلب التوليد صارمًا: بنتَ فقط ما يدعم الشريحة، واترك الباقي كـ TODO.

بعض القرارات المسبقة التي توفر إعادة عمل

قبل أن تطلب من Claude توليد أي شيء، ثبّت عددًا من الافتراضات الافتراضية. تبدو صغيرة، لكنها تمنع فوضى "إعادة تسمية كل شيء لاحقًا".

أولًا، قرّر شكل التطبيق. إذا كنت تحتاج فعلاً لواجهة متصفح وخدمة خلفية، ابدأ بجزئين واضحين (frontend + API) ومكان مشترك للعقود (أنواع API أو مخطط بسيط). إذا كان التطبيق يمكن أن يكون تطبيق ويب مُخدّم من جهة واحدة، احتفظ بكود واحد لتبسيط التطوير المحلي.

بعدها، اتفق على قواعد التهيئة. استخدم ملف env محليًا، ابقِه خارج git، وارتكب قالبًا بدلًا منه (مثل .env.example) مع قيم افتراضية وتعليقات قصيرة. هذا يبسط الانضمام ويقلل تسرب الأسرار.

اختر منافذ تطوير افتراضية وثبّتها. المنافذ تنتهي في السكربتات والوثائق ورسائل الخطأ، لذا تغييرها لاحقًا مزعج. افعل الشيء نفسه للأسماء: يجب أن تتبع المجلدات والخدمات والحزم تقليدًا واحدًا. الاتساق أهم من "التقليد المثالي".

مجموعة قرارات مبدئية بسيطة:

• شكل التطبيق: تطبيق واحد أم frontend + API
• التهيئة: .env محليًا، و.env.example مُرتكب
• منافذ: واحد للويب، واحد للـ API، واحد للقاعدة (إن لزم)
• الأسماء: نمط تسمية واحد للمجلدات، أسماء خدمات متناسقة
• الأسرار: لا تُرتكب أبدًا، ودوّرها إن انكشفت

مثال: تختار web على المنفذ 3000 وapi على المنفذ 8080. قالب env الخاص بك يتضمن API_URL=http://localhost:8080 وDATABASE_URL=.... عندما يولّد Claude السكربتات والوثائق لاحقًا، كل شيء سيثبت بدلًا من الانجراف.

كيف تطلب من Claude Code أن يبقى منظمًا

ابدأ بطلب هيكل قابل للتشغيل، لا "التطبيق الكامل". أسرع طريق لمخرجات فوضوية هو طلب ميزات قبل أن يكون لديك مكان لوضعها.

كن صريحًا بشأن البنية. اطلب مخطط مجلدات مع تعليقات قصيرة تشرح ما ينتمي إلى أين، وما لا ينتمي. هذا يجبر اتخاذ القرارات مبكرًا بدلًا من تشتت الملفات أثناء التوليد.

طريقة بسيطة للإبقاء على الانضباط هي وضع قواعد في الطلب:

• ولّد أصغر هيكل قابل للتشغيل أولًا (صفحة تحية، نقطة صحة، أو شاشة واحدة).
• اقترح هيكل مجلدات وشرح كل مجلد بجملة واحدة.
• أضف سكربتات تعمل على جهاز جديد (install، dev، test، build) واذكر المتطلبات المسبقة.
• احتفظ بالتغييرات في كتلة بمقدار طلب سحب واحدة واذكر بالضبط الملفات التي ستُنشأ أو تُعدّل.
• توقف بعد إنشاء الهيكل وأخبرني كيف أشغله.

ها هو طلب يمكنك إعادة استخدامه وتعديله:

You are working in an empty repo. Create a minimal runnable skeleton.

Constraints:
- Keep it small: no real features yet.
- Propose a clear folder structure and add brief comments in each folder’s README.
- Add scripts for: setup, dev, test, build. They must work on a fresh machine.
- Tell me exactly how to run it, and what output I should see.
- After generating, stop and wait for my “ran it” confirmation.

Output:
1) File tree
2) Key files (only)
3) Run instructions

ثم أبقِ الحلقة ضيقة. لا تطلب خمس تغييرات مرة واحدة. ولّد تغييرًا صغيرًا، شغّله، ألصق الخطأ بالضبط (أو النجاح)، ثم اطلب إصلاحًا بسيطًا. إيقاع التوليد-التشغيل-التعديل هذا يحافظ على قابلية التنبؤ بالمشروع ويجعل من الصعب أن تنحرف البنية.

خطوة بخطوة: من مستودع فارغ إلى هيكل قابل للتشغيل

ابدأ بوعد واحد: أي أحد يمكنه استنساخ المستودع وتشغيل أمر واحد لرؤية شيء يعمل. هذا يمنحك قاعدة مستقرة قبل أن تطلب من الذكاء الاصطناعي إضافة ميزات حقيقية.

أنشئ المستودع واكتب README صغيرًا بينما كل شيء لا يزال طازجًا. اجعله عمليًا: المتطلبات المسبقة، أمر التطوير الواحد، وكيفية تشغيل الاختبارات (حتى لو كانت الاختبارات فارغة الآن).

بعد ذلك، اختر تخطيطًا علويًا يتوافق مع شكل التطبيق الذي اخترته.

إذا كنت تبني قطعًا قابلة للنشر متعددة (مثلاً، frontend + API)، فإن تخطيط workspace يمكن أن يساعد:

/
  apps/
  packages/
  scripts/
  docs/
  README.md

إذا كنت تبني تطبيقًا واحدًا، أبقِ الأمور أبسط وتجنب مستويات إضافية حتى تحتاجها.

الآن أضف الحواجز الدنيا حتى يبقى الكود متسقًا. اختر مُنَسّقًا واحدًا وlinter واحدًا، اقبل الإعدادات الافتراضية، وأضف ملف إعداد واحد لكلٍ منهما. الهدف هو فروق نظيفة، ليس قواعد مثالية في اليوم الأول.

اجعل تجربة المطور متوقعة بأمر واحد يعمل دائمًا من جذر المستودع. هنا شكل بسيط:

{
  "scripts": {
    "dev": "echo \"start dev server here\"",
    "build": "echo \"build here\"",
    "test": "echo \"tests here\"",
    "lint": "echo \"lint here\""
  }
}

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

هيكل مجلد يمكنك الاحتفاظ به مع نمو التطبيق

هيكل Greenfield الجيد يفعل شيئين: يساعدك على إيجاد الكود بسرعة، ويعطي Claude مساحة أقل لاختراع أنماط جديدة في كل مرة تطلب فيها تغييرًا. الهدف ليس الكمال. إنه الاستقرار.

إذا كنت تعمل داخل تطبيق واحد (أو داخل مجلد apps/<name>/)، فإن تخطيطًا داخليًا بسيطًا عادة ما يصمد جيدًا:

• src/ شيفرة التطبيق (الميزات، الأجزاء المشتركة، نقاط الدخول)
• config/ التهيئة غير السرية
• tests/ اختبارات عالية المستوى تُقرأ كسلوك المستخدم
• scripts/ سكربتات مساعدة (إعداد التطوير، إعادة تعيين قاعدة البيانات، مهام الإصدار)
• docs/ ملاحظات قصيرة وقوائم تحقق تُحافظ عليها بالفعل

داخل src/، فصل كود الميزة عن الكود المشترك بناءً على أنماط التغيير. كود الميزة يتغير كثيرًا ويجب أن يعيش قريبًا من بعضه. الكود المشترك يجب أن يكون مملًا وقابلًا لإعادة الاستخدام.

قاعدة عملية: ضع شاشات الواجهة، المعالجات، والمنطق الخاص بالميزة تحت src/features/<featureName>/.... ضع أشياء مثل التسجيل، عملاء API، مكونات نظام التصميم، والمرافق العامة تحت src/shared/.... إذا كان مساعد ما يفهم فقط في ميزة واحدة، احتفظ به داخل تلك الميزة حتى تظهر حالة استخدام ثانية حقيقية. انقله لاحقًا عند الحاجة.

أسماء المجلدات يجب أن تصف الغرض، لا التكنولوجيا. "features" و"shared" تبقيان معنيتين مع تغيير الستاك. تجنّب أسماء مثل "misc" أو "new".

اجعل docs/ صغيرة. بداية جيدة هي docs/checklists.md ببضع أسطر: كيف تشغّل، كيف تختبر، كيف تضيف مجلد ميزة جديد، وما يعنيه "مكتمل".

سكربتات بناء تجعل المشروع متوقعًا

يبدو المستودع حقيقيًا عندما يستطيع أي شخص تشغيل نفس الأوامر والحصول على نفس النتيجة. السكربتات هي حواجز: تقلل التخمين، تحافظ على صغر التغييرات، وتجعل من الواضح متى كسر شيء ما.

ابدأ بمجموعة صغيرة من الأوامر واجعلها مملة. إذا انضم شخص جديد (أو عدت بعد أسبوعين)، لا ينبغي أن يحتاج لعلامات خاصة أو خطوات مخفية.

إليك خط قاعدي بسيط يمكنك تكييفه مع أي ستاك:

{
  "scripts": {
    "dev": "node ./scripts/dev.js",
    "build": "node ./scripts/build.js",
    "test": "node ./scripts/test.js",
    "test:quick": "node ./scripts/test.js --quick",
    "test:full": "node ./scripts/test.js --full",
    "format": "node ./scripts/format.js",
    "lint": "node ./scripts/lint.js",
    "smoke": "node ./scripts/smoke.js"
  }
}

اجعل سكربت dev هو مسار السعادة. يجب أن يشغّل التطبيق، يطبع أين يعمل، ويجعل السجلات قابلة للقراءة. إذا لم يستطع الخادم البدء، افشل بسرعة برسالة واحدة واضحة (متغير env مفقود، المنفذ مستخدم بالفعل، قاعدة البيانات غير متاحة).

يجب أن ينشئ سكربت build دائمًا دليل ناتج نظيف. احذف القديم أولًا، ثم أضف النواتج الجديدة. هذا يتجنب أخطاء غريبة بسبب ملفات البارحة.

بالنسبة للاختبارات، فصّل الفحوص السريعة عن البطيئة. الفحوص السريعة تعمل عند كل تغيير (اختبارات وحدية، فحص الأنواع). الاختبارات الكاملة تتضمن فحوص التكامل وتُشغّل قبل الدمج.

حافظ على الأسلوب متسقًا بأمر واحد. قاعدة بسيطة: التنسيق يصلح الأشياء، وlint يشتكي من الأشياء.

أخيرًا، أضف فحص دخان يتحقق من الأساسيات قبل إضاعة الوقت في تصحيح الأخطاء:

• متغيرات env المطلوبة مضبوطة (وليست فارغة)
• المنافذ المختارة حرة
• التطبيق يستطيع البدء والرد على طلب بسيط
• اتصال قاعدة البيانات يعمل (إن استُخدم)
• مخرجات البناء موجودة بعد build

بناء ميزة الشريحة العمودية الأولى

يجب أن تثبت شريحتك العمودية الأولى أن التطبيق يعمل من طرف إلى طرف، ليس فقط أن الواجهة تبدو جميلة. هذا يعني ميزة صغيرة واحدة تمس الشاشة، المنطق، ونوع من التخزين، حتى لو كان التخزين مؤقتًا.

اختر شيئًا مملًا ومفيدًا، مثل "إضافة ملاحظة" أو "إنشاء مهمة". اجعله صغيرًا بما يكفي لإنهائه في جلسة واحدة، لكن مكتملًا بحيث يمكنك النقر والتفاعل ورؤية تغيير حالة حقيقي.

شريحة جيدة لها أربعة أجزاء: مسار أو شاشة واحدة، نموذج واحد، إجراء حفظ واحد، وعرض واحد. مثال: صفحة "مهمة جديدة" بحقل عنوان، زر حفظ يدعو دالة واحدة، وقائمة تظهر المهام المحفوظة.

ابدأ بمخزن نائب لتتقدم بسرعة. مصفوفة في الذاكرة، ملف JSON محلي، أو واجهة stub بسيطة كافية. المهم إنشاء الحاجز الذي ستستبدله لاحقًا. إذا كان الكود ينادي taskRepository.save(task) اليوم، فإن استبداله بقاعدة بيانات حقيقية لاحقًا يصبح تغييرًا صغيرًا، لا إعادة كتابة.

احتفظ بالواجهة بسيطة. اجتنب نقاشات نظام التصميم، حالات الفراغ، والحركات.

فحوص القبول التي يمكنك إجراؤها في دقيقتين:

• تفتح الصفحة بدون أخطاء
• يمكنك كتابة قيمة والضغط على حفظ
• العنصر الجديد يظهر فورًا
• إعادة التحميل تُظهر السلوك المتوقع (مُستمر إذا كان التخزين حقيقيًا، أو يعاد إذا كان وهميًا)
• يتم التعامل مع الإدخال السيئ (عنوان فارغ يظهر رسالة ولا يخزن)

جعله مستقرًا بما يكفي للتكرار

بعد أن تملك هيكلًا قابلاً للتشغيل وشريحة عمودية واحدة، ينتقل الهدف: اجعل الكسر واضحًا، والإصلاح سريعًا. هنا تفشل الكثير من البدايات الجديدة، ليس لأن الميزة صعبة، بل لأن التغييرات الصغيرة تبدأ بإحداث مفاجآت.

ضع شريط استقرار صغير تلتزم به في كل مرة تضيف شريحة:

• اختبار دخان واحد يثبت أن التطبيق يقلع والمسار/الشاشة الرئيسية تُعرض
• اختبار دخان واحد يمر بالشريحة من طرف إلى طرف (حتى لو استخدم قاعدة بيانات اختبار)
• رسائل خطأ واضحة يمكن للمستخدم العادي التصرّف بناءً عليها (ليس تتبّع مكدس)
• سجلات التطوير التي تشرح ما حدث دون طباعة أسرار
• تبعيات قليلة، إصدارات مثبتة، والترقيات تتم عن قصد

مثال ملموس: شريحتك الأولى تسمح للمستخدم بإنشاء "مشروع" ورؤيته في القائمة. أضف اختبارًا يبدأ الخادم، يدعو نقطة نهاية الإنشاء، ثم يجلب القائمة ويتحقق من ظهور العنصر الجديد. إذا فشل، يجب أن يفشل بصوت عالٍ مع رسالة مفيدة واحدة، مثل "نقطة نهاية إنشاء المشروع أعادت 500"، وليس جدار من المخرجات.

في التعامل مع الأخطاء، التزم بمجموعة صغيرة من الاستجابات المتسقة. أخطاء التحقق تعيد رسالة قصيرة ("الاسم مطلوب") واسم الحقل. الأخطاء غير المتوقعة تعيد "حدث خطأ ما. حاول مرة أخرى." احفظ التفاصيل في السجلات.

السجلات مفيدة عندما تجيب عن: أي طلب، أي مستخدم (أو مجهول)، ماذا فشل، وأين. في التطوير، أضف معرف طلب وتوقيت، لكن تجنّب طباعة الرموز، كلمات السر، مفاتيح API، أو الحمولة كاملة افتراضيًا.

أضف فحص صحة صغيرًا. على الويب يمكن أن يكون endpoint /health الذي يعيد ok. على الموبايل يمكن أن يكون حالة "متصل" تتحول إلى "غير متصل" عندما لا يستطيع التطبيق الوصول للـ backend. هذه إشارة سريعة قبل أن تضيّع الوقت في تصحيح الشيء الخطأ.

مصائد شائعة عند استخدام الذكاء الاصطناعي في المشاريع الجديدة

أسرع طريقة لإهدار بداية Greenfield هي أن تطلب من النموذج التطبيق الكامل، ثم تشغّله لاحقًا فقط. التوليدات الكبيرة تخفي أخطاء صغيرة: تبعيات مفقودة، مسارات استيراد خاطئة، سكربتات تفترض أدوات غير مثبتة لديك. عامل كل مخرج كشيء يجب أن تتمكن من تشغيله خلال دقائق.

مصيدة أخرى هي تصميم البنية المثالية قبل وجود ميزة. الجدل حول أسماء المجلدات يبدو منتجًا، لكن بدون شريحة حقيقية لا تستطيع أن تعرف ما المزعج فعلاً. بنية بسيطة تدعم مسارًا عاملًا تتفوّق على بنية ذكية لم تختبرها.

انحراف الأوامر أيضًا شائع. يضيف الذكاء الاصطناعي طريقة جديدة لبدء الخادم، تضيف طريقة أخرى للاختبارات، وسرعان ما لا يعرف أحد أي أمر هو "الأمر". إذا استنساخ زميل المستودع وسأل "كيف أشغّل هذا؟" فأنت بالفعل تدفع الفائدة.

الأخطاء التي تسبب أكبر إعادة عمل:

• توليد خدمات متعددة وشاشات وتكوينات دفعة واحدة بدل بناء مسار قابل للتشغيل أولًا
• جلب المصادقة، المدفوعات، التصميم المعقد، ونموذج بيانات كامل قبل أن تعمل الميزة الأولى من طرف إلى طرف
• ترك تعليمات الإعداد في المحادثة بدلًا من سكربتات (أو README واحد)
• نسيان قالب env نظيف، فيصبح الجهاز التالي لا يستطيع البدء بدون تخمين

مثال بسيط: تولد تطبيقًا "مكتملًا" مع تسجيل دخول، سمات، وفوترة، لكن أول تشغيل يفشل لأن مفتاح سري مفقود ولا يوجد .env.example. تقضي ساعة في إصلاح الإعداد بدل أن تختبر إذا كانت الميزة مفيدة.

ابقَ صريحًا: أمر قابل للتشغيل واحد، ميزة صغيرة واحدة، قالب env واحد، ثم توسع.

قائمة سريعة قبل أن تبدأ بالتكرار

قبل أن تضيف "ميزة واحدة أخرى"، تأكد أن المشروع سهل الالتقاط غدًا (أو من قبل شخص آخر). السرعة ليست الهدف بذاتها. القابلية للتنبؤ هي.

• تشغيل بأمر واحد: مطور جديد يمكنه نسخ قالب env، ضبط القيم المطلوبة القليلة، وتشغيل التطبيق بأمر واحد. إذا احتاج خطوات إضافية (إعداد قاعدة بيانات، هجرات، بيانات تجريبية)، ضعها في سكربت.
• السكربتات تغطي الأساسيات: أوامر واضحة للتطوير، الاختبار، البناء، وفحص دخان سريع.
• بنية واضحة: التوزيع يروي قصة (كود التطبيق، التهيئة، السكربتات، الاختبارات) دون قراءة المستودع كله.
• مسار عرض الشريحة العمودية: يمكنك وصف العرض بجملة واحدة، مثل "إنشاء عنصر، رؤيته في قائمة، تحديث الصفحة، يبقى موجودًا."
• نقطة تراجع: قبل تغييرات كبيرة، لديك نقطة آمنة للعودة إليها (التزام نظيف، وسم، أو آلية لالتقاط/استرجاع).

إذا فشل أي بند، أصلحه الآن. تشديد السكربتات والتسمية رخيص عندما يكون المستودع صغيرًا.

الخطوات التالية: حوّل سير العمل إلى عادة قابلة للتكرار

لا يعود نجاح بداية Greenfield إلا إذا استطعت تكرارها. بعد أن تعمل شريحتك العمودية الأولى من طرف إلى طرف، جمد الأجزاء الجيدة في قالب صغير: نفس أنماط المجلدات، نفس أسماء السكربتات، ونفس طريقة ربط الواجهة والـ API والبيانات.

عامل الشريحة الأولى كمثال مرجعي. عندما تبدأ الشريحة #2، انسخ الشكل، لا الكود. إذا كانت الشريحة #1 تحتوي مسارًا، معالجًا، طبقة وصول بيانات، واختبارًا أساسيًا، فيجب أن تتبع الشريحة #2 نفس المسار.

اجعل التخطيط خفيفًا. ملاحظة صفحة واحدة تكفي للـ 2-3 شرائح التالية: الهدف وفعل المستخدم لكل شريحة (جملة واحدة)، البيانات المطلوبة، فحوص "الانتهاء"، وأي مخاطر يجب اختبارها مبكرًا.

ثم اجعل الصيانة عادة. مرة في الأسبوع، قم بتمرير تنظيف قصير: شدّد السكربتات، حدّث README مع أي خطوات إعداد جديدة، وجدد ملف قالب env حتى يبقى الانضمام سهلًا.

إذا فضّلت حلقة بناء بتعزيز الدردشة أولًا، Koder.ai (koder.ai) هو خيار يدعم وضع التخطيط بالإضافة إلى اللقطات وآليات التراجع، ويمكنه تصدير الشيفرة المصدرية عندما تريد نقل المشروع إلى مكان آخر.

الهدف هو سير عمل يمكنك تشغيله دون تفكير: خطّط 2-3 شرائح، ابنِ شريحة واحدة، أثبت الاستقرار، كرّر.