إيه هو Kiro؟
Kiro هو بيئة برمجة قابلة للتنزيل من Amazon Web Services بتاخد التطوير بمساعدة الذكاء الاصطناعي في اتجاه معظم الأدوات من النوع ده ما جربتوش.
بدل ما معظم أدوات البرمجة بالذكاء الاصطناعي تخليك تكتب برومبت وتاخد كود فورًا، Kiro بيبدأ بعملية تخطيط الأول: بيقرأ سياق مشروعك، وبيكتب مستند متطلبات، وبيولّد تصميم تقني، وبيقسّم كل حاجة لقائمة مهام مرقمة، وبعد كده بس بيبدأ يكتب الكود.
متاح كـ IDE، وأداة سطر أوامر، وواجهة ويب (حاليًا في preview للمستخدمين المدفوعين)، وكمان تطبيق موبايل (early access على iOS)، Kiro بيقدم نفسه كأداة للمطورين اللي عايزين ناتج منظم وقابل للصيانة بدل كود سريع يخلّيهم يفكّوه من بعض بعد أسبوع.
Kiro مناسب لمين؟
- المطورين اللي اتلسعوا من كود متولد بالذكاء الاصطناعي وبيبوظ بعد أول يوم. Workflow بتاع الـ spec في Kiro بيفرض التخطيط قبل التنفيذ، وده معناه إن الكود اللي بيكتبه قابل للتتبع لحد المتطلبات الموثقة، مش متجمع على أساس تخمين.
- الفرق اللي بتتحرك ناحية workflows agentic. Agent Hooks في Kiro بيسمحولك توتوماتيكيًا بأتمتة مهام متكررة زي كتابة الاختبارات أو توليد التوثيق، وده بيتفعل تلقائيًا كل ما ملف مناسب يتغير، من غير ما تحتاج prompt متكرر.
- مطوري منظومة AWS. Kiro مبني على بنية AWS التحتية، وبيعالج البيانات عبر مناطق AWS داخل نفس الجغرافيا بتاعتك، وبيتصل طبيعيًا بخدمات AWS. لو الـ stack عندك أصلاً AWS-heavy، Kiro هيناسبك من غير أي إعدادات زيادة.
- مستخدمي VS Code اللي عايزين AI أعمق من autocomplete. Kiro IDE مبني على نفس الأساس بتاع VS Code. اختصارات الكيبورد، والإعدادات، والإضافات بينتقلوا أثناء الإعداد في دقايق.
مميزات Kiro وعيوبه
- Workflow بتاع spec بيخطط قبل كتابة أي كود
- Agent Hooks بيؤتمت المهام عند أحداث الملفات
- إضافات وإعدادات VS Code بتتimport بسلاسة
- وضع Autopilot بيبني من غير طلب موافقة كل شوية
- Steering docs بتدي Kiro سياق مشروعك
- بيدعم كذا frontier model، بما فيهم Opus 4.8
- تكامل MCP server بيربط أدوات خارجية بشكل أصلي
- محتاج تنزيل؛ مش متاح من المتصفح في الخطة المجانية
- 50 free credits بيخلصوا أسرع من المتوقع
- حصل timeout مرة واحدة خلال مرحلة تحسين المتطلبات
تفصيل التقييم
أقوى درجات Kiro بتكون في الخصائص والوظائف، حيث إن workflow المبني على الـ spec، والـ agent hooks، والتنفيذ على autopilot، بيخلوه متقدم على أي أداة برمجة بالذكاء الاصطناعي اتغطت هنا. لكنه بيخسر شوية في سهولة الوصول ونموذج الـ credits، وده محتاج اهتمام صريح قبل ما تعتمد عليه في workflow ثابت.
| الميزة | الدرجة (من 10) | ليه الدرجة دي |
|---|---|---|
| سهولة الاستخدام | 7.0 | مألوف لأي مستخدم VS Code؛ لكن شرط التنزيل وطبيعته الموجهة للمطورين بس بيخلّوه بعيد عن المستخدمين غير التقنيين |
| الخصائص والوظائف | 9.5 | Workflow spec، والـ agent hooks، وautopilot، وتكامل MCP، وsteering docs: أكمل مجموعة خصائص لأي أداة برمجة بالذكاء الاصطناعي اتراجعت هنا |
| التصميم والتخصيص | 7.0 | ثيمات داكنة وفاتحة للـ IDE؛ وتحكم قوي في بنية الكود المتولد من خلال تعديل الـ spec ومستندات التوجيه |
| القيمة مقابل السعر | 6.5 | 50 credits في الخطة المجانية اتستهلكوا 4.28 منهم في التخطيط بس، قبل ما يتكتب سطر واحد من كود التطبيق |
| الأداء والاعتمادية | 7.5 | الناتج التخطيطي كان مفصلًا ومحددًا؛ وحصل timeout واحد مؤكد بعد 7 دقائق و24 ثانية أثناء تحسين المتطلبات |
| الإجمالي | 8.2 | Workflow بتاع spec في Kiro هو أكتر نهج منظم للتطوير بمساعدة الذكاء الاصطناعي تم مراجعته لحد دلوقتي. الدرجة بتعكس التميز الحقيقي ده، لكنها بتتأثر بحدود الخطة المجانية المحدودة وفشل الاعتمادية الوحيد اللي اتسجل أثناء الاختبار. |
مميزات Kiro
- Workflow مبني على spec: متطلبات، تصميم، مهام، كود
- Agent Hooks بيؤتمتوا المهام عند أحداث الملفات
- مستندات steering بتدي العامل الذكي سياق المشروع
- وضع Autopilot بينفذ المهام من غير موافقة خطوة بخطوة
- دعم MCP server للتكامل مع أدوات خارجية
- استيراد إعدادات VS Code عند أول تشغيل
- دعم متعدد للموديلات، بما فيهم Claude Opus 4.8
مراجعتي الصريحة لـ Kiro: إيه اللي لقيته بعد ما اختبرته
معظم أدوات بناء التطبيقات بالذكاء الاصطناعي بتقع في واحدة من فئتين:
- أدوات بصرية بتولّد واجهة من وصف
- وأدوات قائمة على الشات بتكتب الكود مباشرة استجابةً لبرومبت
Kiro مش بينتمي لأي فئة من دول، وده السبب إن مراجعته لازم تكون بطريقة مختلفة.
Kiro هو IDE agentic. إنت مش بتسحب components على canvas، ومش بتاخد preview حي بعد 30 ثانية. اللي بتاخده هو بيئة تطوير محلية بتخطط للبناء قبل ما تبدأه، وبتولّد requirements، ومستند design، وقائمة مهام منظمة، والعامل الذكي بينفذهم واحد واحد.
التطبيق اللي بيطلع منه هو مشروع حقيقي على جهازك، في ملفات إنت مالكها، وبـ stack إنت محدده.
ولأختبر إذا كانت العملية دي فعلًا بتشتغل، بنيت منصة لإدارة العقارات من الصفر داخل Kiro.
البرومبت غطّى توثيق دخول الملاك والمستأجرين، وإدارة العقارات والوحدات، وتتبع عقود الإيجار، وطلبات الصيانة مع تحديثات الحالة، وتكامل Stripe للدفع، وإشعارات الإيميل، ولوحة تحكم للمالك مع تقارير. نفس البرومبت ده اتستخدم لتقييم Rork وFigma Make وUizard وRetool، وده بيسمح بمقارنة إزاي كل أداة بتتعامل مع التعقيد الحقيقي بدل مثال بسيط.
السؤال اللي المراجعة دي كانت بتحاول تجاوبه كان محدد: هل workflow بتاع spec-first في Kiro بيطلع ناتج أحسن تنظيمًا وأكثر قابلية للصيانة من الأدوات اللي بتروح للكود مباشرة؟
وده اللي لقيته.
تشغيل Kiro: تنزيل مش تبويب متصفح
كل أداة بناء تطبيقات بالذكاء الاصطناعي تانية اتراجعت جنب المقارنة دي شغالة في المتصفح. Kiro لا. علشان تبدأ لازم تروح kiro.dev، وتضغط Downloads، وتختار نظام التشغيل، وتثبت التطبيق على جهازك.
أنا كنت شغال على Pop OS، وهو توزيعة لينكس مبنية على Debian، فاخترت حزمة Debian (.deb) من القائمة المنسدلة. الموقع كمان بيقدم حزمة Universal (.tar.gz) لإعدادات لينكس التانية. مثبتات Windows وmacOS متاحة من نفس صفحة التنزيلات.
وده معناه عمليًا:
- الجلسة الأولى محتاجة تثبيت محلي، مش تبويب متصفح
- مفيش وصول من خلال الإنترنت فقط في الخطة المجانية (واجهة الويب متاحة في الخطط المدفوعة فقط، وحاليًا في preview)
- للمطورين، ده مش مشكلة
- لأي حد بيقارن Kiro مع أدوات بناء على المتصفح، احسب وقت الإعداد ده
التثبيت نفسه كان سهل. مفيش خطوات إعداد، ومفيش dependencies لازم تتحل يدويًا، والتطبيق اشتغل بسلاسة بعد تثبيت الحزمة بالطريقة المعتادة.
تسجيل الدخول بيتم في المتصفح، مش جوه التطبيق
أول ما الـ IDE يفتح لأول مرة، ما بيطلبش منك تسجل دخول من داخل نافذة التطبيق. بدل كده، بيحوّلك لصفحة في المتصفح علشان المصادقة تتم هناك.
شاشة تسجيل الدخول بتقدم أربع اختيارات:
| طريقة الدخول | مناسبة لمين |
|---|---|
| المطورين المستقلين والفريلانسرز | |
| GitHub | الاختيار الأنسب للمطورين اللي عندهم حسابات موجودة بالفعل |
| AWS Builder ID | المطورين الموجودين بالفعل داخل منظومة AWS |
| Your Organization | الفرق المؤسسية اللي بتستخدم SSO |
اختيار GitHub متوافق جدًا مع الجمهور المستهدف. معظم المطورين عندهم حساب GitHub بالفعل ويقدروا يسجلوا دخول من غير ما ينشئوا credential جديد.
في شوية حاجات مهمة تعرفها قبل ما تسجل:
- التسجيل عبر Google أو AWS Builder ID (مش AWS Identity Center) بيأهلك لـ 20$ credit بيتضاف لأول ترقية لخطة مدفوعة. دي ميزة لمرة واحدة ومهم تعرفها قبل ما تختار طريقة الدخول.
- التسجيل من خلال “Your Organization” بيعدّي عبر enterprise SSO وده مدخل للفرق اللي محتاجة إدارة هوية مركزية.
- بمجرد ما بتسجل، إنت بتوافق على AWS Customer Agreement وService Terms وPrivacy Notice وAWS Intellectual Property License. بما إن Kiro منتج من AWS، بياناتك بتتعالج عبر مناطق AWS داخل جغرافيتك.
الإعداد الأولي: 3 خطوات بياخدوا أقل من دقيقتين
بعد تسجيل الدخول، Kiro بيعمل تسلسل إعداد قصير قبل ما يفتح الـ IDE الرئيسي. الخطوات هي:
الخطوة 1: اختار الثيم. Kiro Dark أو Kiro Light. الاتنين بيعرضوا معاينة مباشرة لتظليل الكود قبل ما تؤكد.
الخطوة 2: جهّز تكامل الشِل. ده بيسمحلك تفتح أي مشروع من التيرمنال باستخدام أمر kiro command. تقدر تتخطى الخطوة دي وتظبطها بعدين.
الخطوة 3: استيراد من VS Code. Kiro بينقل Extensions بتاعت VS Code الموجودة عندك (أي حاجة متاحة على Open VSX)، والإعدادات، وkeybindings. الـ Extensions بتتحمل في الخلفية أثناء ما الإعداد بيكمل، فمفيش انتظار على شاشة تحميل.
أكتر جزء مفيد عمليًا في التسلسل ده هو استيراد VS Code. لو قضيت سنين بتخصص بيئة VS Code، الانتقال مش بيحتاج تبدأ من الصفر. الاستيراد اشتغل بسلاسة في جلستي.
اللي الإعداد الأولي ما بيقدموش هو أي مقدمة عن الخصائص الأساسية في Kiro. مش هتتشرحلك يعني إيه Specs أو Agent Hooks أو Steering Documents. إنت بتوصل للشاشة الرئيسية وتكتشف ده بنفسك. ده مقبول لجمهور مطورين عنده خبرة، لكنه معناه إن أول جلسة مع أكتر خصائص الأداة تميزًا هتحتاج استكشاف ذاتي.
جوه الـ IDE: الأربع لوحات اللي بتخلي Kiro مختلف
شكل Kiro IDE شبه VS Code لأنه مبني على نفس الأساس. مستكشف الملفات، وتبويبات المحرر، والتيرمنال، وشريط البحث، وشريط القوائم، كلهم بيشتغلوا زي المتوقع بالظبط.
اللي بيميز Kiro عن تثبيت VS Code عادي هو اللوحة اليسار المخصصة، واللي فيها أربع أقسام مش موجودين في أي إضافة لـ VS Code:
| قسم اللوحة | بيعمل إيه |
|---|---|
| Specs | إنشاء وإدارة مستندات المواصفات (متطلبات، تصميم، مهام) للبناءات المعقدة |
| Agent Hooks | إعداد مهام مؤتمتة بتتفعّل عند أحداث نظام الملفات |
| Agent Steering and Skills | تخزين مستندات إرشادية بتشكّل سلوك العامل الذكي عبر كل الجلسات |
| MCP Servers | ربط أدوات ومصادر بيانات خارجية بعامل Kiro الذكي |
اليمين من الـ IDE بيضم لوحة الشات. هنا بتتفاعل مع Kiro وبتشوف استهلاك الـ credits في الوقت الحقيقي. “Est.
Credits Used: 0.1, Elapsed time: 57s” بتتحدّث بعد كل حركة للعامل الذكي، وده معناه إنك دايمًا عارف كل مهمة بتكلف كام.
في أسفل شريط إدخال الشات، في تحكمين بيحددوا إزاي Kiro بيتصرف في كل مهمة:
- اختيار الموديل: اختار Auto (Kiro بيختار أكفأ موديل من ناحية التكلفة لكل طلب)، أو اختار موديل محدد زي Claude Sonnet 4.6 أو Claude Opus 4.8.
- مفتاح Autopilot: مع تشغيل Autopilot، Kiro بيكتب ويعدّل الملفات من غير ما يستنى موافقتك عند كل خطوة. مع إيقافه، Kiro بيقف قبل كل أمر وبيطلب منك Trust أو Reject أو Run manually.
في اختبار منصة إدارة العقارات، خليت Autopilot شغال أثناء التخطيط واستخدمت الموافقة اليدوية أثناء تنفيذ المهام علشان أقيّم كل خطوة بشكل مستقل.
الخلاصة: تخطيط الـ IDE مريح خلال دقايق لأي مستخدم VS Code. الأقسام الأربعة في اللوحة اليسار هي مكان قيمة Kiro الحقيقية، وفهم كل واحدة قبل أول جلسة هو اللي بيحدد قد إيه هتاخد من الأداة.
Steering Documents: إزاي تدي Kiro سياق قبل أول prompt
أول حاجة لازم تعملها جوه مشروع Kiro جديد مش إنك تبدأ build. أول حاجة هي توليد steering documents.
ضغطت “Generate Steering Docs” في لوحة Kiro قبل ما أبعت أي prompt. Kiro مسح مجلد المشروع الفاضي وأنشأ 3 ملفات markdown جوه .kiro/steering/:
| الملف | المحتويات |
|---|---|
| product.md | اسم المنتج، الوصف، مفاهيم المجال الأساسية، والأهداف الرئيسية |
| structure.md | التخطيط المتوقع للمجلدات ومعايير تنظيم الملفات |
| tech.md | الـ tech stack المتوقع، والأوامر الشائعة، ومعايير البرمجة |
في مشروع فاضي تمامًا، Kiro استنتج defaults منطقية: React مع TypeScript، وNext.js API routes، وPostgreSQL، وPrisma، وTailwind CSS، ومصادقة مبنية على JWT. وعلّم tech.md وstructure.md كـ placeholders لازم تتحدّث بمجرد ما الـ stack الفعلي يتأكد من خلال scaffolding.
وده مهم لأن كل حركة لاحقة للعامل الذكي بتقرا الملفات دي قبل أي حاجة. أول ما تعمل scaffolding للمشروع ويتأكد الـ stack الحقيقي، تعديل tech.md بيخلي Kiro يطبق المعايير دي تلقائيًا على كل المهام اللي بعد كده.
تقدر كمان تضيف ملفات steering من عندك لمعايير تصميم الـ API، أو التسمية، أو قواعد النشر، أو أي constraint تاني عايز العامل الذكي يعتبره ثابت.
Vibe Mode vs Spec Mode: القرار اللي بيشكّل البناء كله
لما بتفتح الشات لبناء جديد، Kiro بيعرض عليك وضعين قبل ما تكتب أي حاجة:
Vibe mode بيخليك تتكلم الأول وتبني وإنت ماشي. مفيش مستندات تخطيط، ومفيش ناتج منظم. أنسب للتجارب السريعة، أو الاستكشاف المبكر، أو المهام اللي المتطلبات لسه بتتحدد فيها.
Spec mode بيشغّل تسلسل تخطيطي قبل ما يتكتب أي كود. Kiro بيولّد requirements، ومستند design تقني، وقائمة مهام. بس بعد مراجعة وتأكيد التلاتة دول، بيبدأ يكتب الكود. أنسب للشغل الإنتاجي اللي القابلية للصيانة فيه مهمة.
اخترت Spec mode لمنصة إدارة العقارات. أول ما بعت البرومبت، Kiro سألني سؤالين متابعة قبل ما يولد أي حاجة:
- “What do you want to start with?” (Requirements، ومعلّمة كخيار موصى به، أو Technical Design)
- “Is this a new feature or a bugfix?” (Build a Feature، ومعلّمة كخيار موصى به، أو Fix a Bug)
الأسئلة دي بتحدد هيكل كل اللي هييجي بعد كده. اختيار “Requirements” معناه إن Kiro بيكتب user stories ومعايير قبول قبل ما يلمس المعمارية.
التسلسل ده بينتج artifacts تخطيطية مختلفة جذريًا عن بدء التصميم التقني الأول ثم اشتقاق المتطلبات بعده.
Workflow بتاع الـ Spec: متطلبات، تصميم، وقائمة مهام قبل أي كود
دي بقى الجزء اللي بيخلي Kiro يستاهل التقييم بجدية.
بعد ما اخترت “Requirements” و”Build a Feature”، Kiro أنشأ ملف requirements.md جوه .kiro/specs/property-management-platform/. المستند ظهر في الـ editor فورًا. قدرت أقراه وهو بيتكتب. المحتويات شملت:
Glossary: 12 مصطلح مجال متعرّفين بدقة، منهم Auth_Service وProperty_Service وLease_Service وPayment_Service وMaintenance_Service وNotification_Service وDashboard_Service، وكل واحد مربوط ب subsystem مخطط له.
وصف المنصة: اتوثق دور Landlord وTenant، وكمان tech stack المؤكد: Next.js وTypeScript وPostgreSQL وPrisma وTailwind CSS وStripe وDocker.
بعد توليد المستند الأولي، Kiro شغّل خطوة تحسين تلقائية. حلّل كل الـ 12 requirement، ووزّع detailer sub-agents بشكل متوازي على كل واحدة، وحدث requirements.md بمعايير قبول كاملة لكل requirement.
الألـ panel كانت بتتبع ده في الوقت الحقيقي: “Refining requirements 12/12.”
بعد ما المتطلبات اكتملت، ضغطت “Continue” واخترت “Generate Design and Tasks.” Kiro أنشأ design.md وtasks.md مع بعض. تقسيم المهام كان أبرز ناتج في الجلسة:
11 مجموعة مهام، 43 مهمة فرعية، بترتيب التنفيذ:
- تهيئة المشروع والبنية التحتية
- المصادقة (JWT، blacklist، middleware، pages)
- إدارة العقارات والوحدات
- إدارة المستأجرين
- إدارة عقود الإيجار، رفع المستندات، ومهمة cron
- طلبات الصيانة
- مدفوعات Stripe وwebhook
- إشعارات الإيميل
- لوحة تحكم المالك والتقارير
- مكونات الواجهة المشتركة والتخطيطات
- تحصين الـ API (rate limiting، CORS، health check، التحقق من environment)
كل مهمة فرعية كان فيها أوامر دقيقة، ومسارات ملفات، ومراجع قابلة للتتبع للمتطلبات. المهمة 1.1 مثلًا، كانت بتشير مباشرةً لـ Requirements R12 (Docker) وR10 (REST API) في وصفها. الربط بين التخطيط والتنفيذ كان صريح وقابل للتحقق طول الوقت.
Rork، بالمقارنة، بيتخطى المرحلة دي كلها وبيمشي مباشرة لتوليد واجهة مستخدم من البرومبت. الفرق في جودة الناتج واضح: قائمة المهام في Kiro محددة بما يكفي إنك تسلمها لمطور بشري ويعرف بالضبط إيه اللي لازم يتبني وبأي ترتيب.
تنفيذ المهام: إيه اللي Kiro بنّاه فعلًا
بعد ما وافقت على قائمة المهام، ضغطت “Start task” على Task 1.1: Initialize Next.js 14 project with TypeScript, Tailwind CSS, and ESLint.
Kiro حدّث حالة المهمة إلى “in progress” في tasks.md، وبعدها فوّض التنفيذ إلى spec-task-execution sub-agent. العامل الذكي راجع الـ workspace الأول، وتأكد إن الموجود بس هو مجلد spec بتاع .kiro من غير أي مشروع Next.js لسه، وبدأ يهيكل المشروع.
في أول دورة تنفيذ، شجرة الملفات اتعبّت بـ:
- package.json فيه Next.js وReact 19.2.4 وTypeScript وTailwind dependencies
- tsconfig.json وeslint.config.mjs وnext.config.ts
- src/ وpublic/ هيكل مجلدات
- AGENTS.md وCLAUDE.md، متولدين من Kiro كملفات إرشاد للعامل الذكي للمشروع
- README.md
ملف CLAUDE.md جدير بالذكر: Kiro منتج من AWS، لكنه بيشتغل على موديلات Claude من Anthropic تحت الغطاء. وجود CLAUDE.md هو الطريقة اللي عوامل Claude الذكية بتخزن بيها التوجيهات الخاصة بالمشروع. وجوده في الـ scaffold المتولد بيعكس الموديل الأساسي، حتى داخل سياق بنية AWS التحتية.
فوق في عرض قائمة المهام، زر “Run all tasks” كان هيسمح لـ Kiro بتنفيذ كل الـ 43 مهمة فرعية ورا بعض مع تشغيل Autopilot.
أنا نفذت المهام واحدة واحدة علشان أقيّم كل خطوة. لمشروع حقيقي إنت واثق من الخطة المعتمدة بتاعته، تشغيل كل المهام أوتوماتيكيًا ومراجعة الناتج عند نهاية كل مجموعة يبقى Workflow منطقي وموفر للوقت.
كل ملف Kiro ولّده أثناء التنفيذ كان ملف حقيقي على الدليل المحلي بتاع مشروعي، ومملوك وقابل للتعديل من أول ثانية. وده فرق مهم عن أدوات البناء المعتمدة على المتصفح زي Figma Make أو Uizard، حيث الناتج بيكون يا إما أصل تصميم أو تطبيق مستضاف إنت ما بتتحكمش فيه محليًا.
الـ Timeout في الدقيقة السابعة: معناه إيه بالنسبة للاعتمادية
عايز أكون واضح في النقطة دي لأنها حصلت أثناء أهم جزء في الاختبار.
بعد ما Kiro فرّغ الـ 12 requirement وحفِظ التعديلات على requirements.md، العامل الذكي حصل له timeout. رسالة الخطأ في لوحة الشات كانت:
“The request timed out. Please try again. (Conversation ID: 29d25548-c3ce-414c-8f57-702124c7fec6). Elapsed time: 7m 24s.”
ده حصل عند الانتقال من مرحلة المتطلبات لمرحلة توليد التصميم. الشغل اللي اتعمل قبل الـ timeout اتسجل. ولا requirement ضاعت.
بعد ما اعترفت بالخطأ، ضغطت “Continue” واخترت “Generate Design and Tasks.” Kiro تعافى من غير ما يكرر خطوة المتطلبات، وطلع المستندين بشكل نظيف، وكمل بشكل طبيعي لباقي الجلسة.
السياق المهم هنا:
- الـ timeout حصل على prompt معقد بيغطي 12 منطقة متطلبات مختلفة مع تشغيل refinement متوازي.
- الـ tasks البسيطة غالبًا مش هتاخد وقت طويل كده.
- Kiro حاليًا في preview، والاعتمادية عند الحافة القصوى للمهام المعقدة من الخصائص المعروفة للأدوات في المرحلة دي.
- التعافي كان نظيف. نظام الـ checkpoint حفظ كل الشغل المكتمل والخطوة التالية اشتغلت فورًا.
لكن برضه، بعد سبع دقايق من أكتر ميزة مميزة في الأداة، إنك تقابل timeout دي تجربة فشل حقيقية. لو شغال تحت ضغط وقت، أداة بتقف وتحتاج retry يدوي هتبقى مزعجة حتى لو التعافي سلس.
Agent Hooks: أتمتة بتشتغل من غير ما حد يطلبها
Agent Hooks ما بتظهرش في أي أداة برمجة بالذكاء الاصطناعي تانية اتراجعت جنب المقارنة دي، واستاهلوا اهتمام مخصوص لأنهم بيمثلوا طريقة تفكير مختلفة في المساعدة بالذكاء الاصطناعي.
الـ Hook هو مهمة بتشتغل تلقائيًا لما يحصل event في نظام الملفات. إنت بتوصف السلوك بلغة طبيعية، Kiro بيحوّله لlistener للأحداث، ومن ساعتها السلوك ده بيشتغل في الخلفية كل ما شرط التفعيل يتحقق. من غير أمر يتنفذ، ومن غير تذكير تعمله.
أمثلة على الحاجات اللي الـ Hooks يقدروا يعملوها:
- عند حفظ ملف: يولّد اختبارات أساسية لأي component ملوش test file
- عند حفظ ملف: يشغّل تنظيف الكود أو فحوصات التنسيق
- عند إنشاء ملف: يولّد توثيق تلقائي للدوال الجديدة
- عند تغيير string constant: يحدّث ملفات الترجمة من غير تدخل يدوي
الـ hook بيتخزن داخل .kiro/hooks/ كملف قابل للتعديل. لو عايز تغيّر شرط التفعيل أو التعليمات، بتعدّل الملف مباشرة. الإعداد شفاف وقابل للتحكم بالإصدارات جنب باقي المشروع.
مثال الاختبار عند الحفظ هو الأكثر عملية بشكل مباشر: المطورين دايمًا بيأجلوا كتابة الاختبارات لآخر السبرنت، وhook يضيف اختبارات أساسية بهدوء كل ما component يتفظ يتشال القرار ده من الأساس. الاختبارات بتظهر في شجرة الملفات بعد الحفظ اللي بعده من غير أي خطوة منك.
استهلاك الـ Credit: إيه اللي الخطة المجانية بتديهولك فعلًا
نموذج الـ credits هو أكتر منطقة Kiro محتاج فيها قراءة دقيقة قبل ما تعتمد على workflow.
الخطة المجانية بتديك 50 credit. وده اللي استهلكه session واحدة لمنصة إدارة العقارات: 4.28 credit للتخطيط بس، وده شمل requirements، ومستند التصميم، وقائمة الـ 43 مهمة كاملة، قبل ما يتكتب سطر واحد من كود التطبيق.
بالوتيرة دي:
| السيناريو | التغطية المتوقعة في الخطة المجانية |
|---|---|
| جلسات التخطيط فقط (من غير تنفيذ كود) | حوالي 11 جلسة |
| التخطيط مع تنفيذ جزئي للمهام | من 3 إلى 5 جلسات |
| تنفيذ كامل من الـ spec للكود في مشروع معقد | مشروع كامل واحد بحد أقصى |
آليات مهمة لازم تفهمها قبل ما تسجل:
- الـ credits ما بتترحّلش للشهر اللي بعده. أي حاجة فاضلة في آخر شهر الفوترة بتضيع.
- الفوترة الإضافية معطلة افتراضيًا في كل الخطط المدفوعة. لازم تفعلها في Settings قبل ما توصل للحد، وإلا Kiro بيوقف الشغل في نص المهمة.
- اختيار الموديل بيأثر على معدل الاستهلاك. تشغيل نفس المهمة عبر Claude Sonnet 4.6 بيكلّف 1.3 مرة أكتر من Auto mode. موديلات Opus بتكلف أكتر كمان.
- مستخدمو الخطة المجانية بياخدوا Claude Sonnet 4.5 ومجموعة open weight models تشمل Qwen3 Coder Next وDeepSeek v3.2 وMiniMax 2.1. المستخدمون المدفوعون بيفتح لهم Claude Sonnet 4.6 وClaude Opus 4.6 وClaude Opus 4.8.
- استهلاك الـ credit ظاهر في لوحة الشات بعد كل حركة للعامل الذكي وبيتحدث في لوحة الاشتراك كل 5 دقايق.
متعقب الـ credits في الوقت الحقيقي (“Est. Credits Used: 0.1, Elapsed time: 57s” بعد كل مهمة) هو ميزة شفافية مفيش أداة مشابهة بتقدمها حاليًا. إنت عارف بالضبط كل مهمة بتكلف كام وهي شغالة، وده بيساعدك تقرر تستخدم Auto mode ولا موديل محدد لمهمة معينة.
أسعار وخطط Kiro
Kiro بيشتغل بنظام credit-based مع 5 مستويات، من خطة مجانية بحصة شهرية ثابتة لحد خطة عالية السعة مصممة للاستخدام المهني اليومي.
كل الخطط المدفوعة بتشمل الوصول للموديلات المميزة، وخيار تفعيل pay-per-use overage، وكامل مجموعة خصائص Kiro، بما فيها specs، وhooks، وautopilot، ووصول CLI.
حاجات لازم تعرفها قبل ما تختار خطة:
- الخطة المجانية بتدي حصة شهرية ثابتة من الـ credits من غير ما تحتاج بطاقة ائتمان. هي ما بتخلصش، لكن جلسة spec معقدة واحدة هتأكل جزء ملحوظ منها.
- أول مرة ترقي من المجاني لأي خطة مدفوعة باستخدام Google أو AWS Builder ID (مش AWS Identity Center)، بتحصل على 20$ credit بيتطبّق على تكلفة الاشتراك. الميزة دي لمرة واحدة.
- Kiro بيفوّت في أول يوم من كل شهر ميلادي. الترقية في نص الشهر معناها تدفع رسوم محسوبة نسبيًا لكن تكسب فورًا الحد الكامل من الـ credits بتاع خطتك الجديدة.
- الفوترة الإضافية متاحة في كل الخطط المدفوعة بسعر ثابت لكل credit إضافي، لكنها مقفولة افتراضيًا. فعّلها في Settings قبل ما توصل للحد، وإلا Kiro هيوقف شغلك لما الـ credits تخلص.
- الـ credits غير المستخدمة ما بتترحّلش للشهر التالي.
- كل مطور محتاج اشتراك منفصل. مفيش خيار seat مشترك للفريق حاليًا. خصائص فواتير الفرق مكتوب إنها coming soon.
- سياسة Kiro القياسية هي عدم وجود refunds للإلغاء في نص الشهر. الوصول بيستمر لحد نهاية دورة الفوترة. الـ refunds بتتدرس حالة بحالة لأخطاء الفوترة فقط.
- بطاقات الائتمان هي وسيلة الدفع الوحيدة المقبولة.
- تسعير GovCloud (US) أعلى بحوالي 20% من التسعير القياسي، والخطة المجانية غير متاحة في البيئة دي. الوصول لـ GovCloud محتاج خطة مدفوعة ومصادقة مؤسسية عبر AWS IAM Identity Center.
- واجهة الويب حاليًا في preview ومتوفرّة للمستخدمين المدفوعين فقط. الـ credits بتتستهلك بنفس المعدل سواء اشتغلت في الـ IDE أو CLI أو الويب.
أي خطة تناسب أي نوع من المستخدمين: الخطة المجانية كافية لتقييم حقيقي. لكن لو هتشتغل على مشاريع فعلية، يبقى الخطة المدفوعة ضرورية علشان ما تخلصش عليك في نص الجلسة. الخطط الأعلى بتناسب المطورين اللي بيشغلوا كذا session spec كاملة في الأسبوع أو بيشتغلوا على كذا مشروع معقد في نفس الوقت.
بدائل Kiro
أقرب منافس لـ Kiro هو Cursor، وهو editor للبرمجة مدعوم بالذكاء الاصطناعي ومبني أيضًا على أسس VS Code وبيستهدف المطورين اللي عايزين AI متكامل بعمق في بيئة التطوير بتاعتهم.
الفرق الأساسي هو فلسفة workflow. Cursor معمول علشان يسرّع اللي إنت بتعمله أصلًا: إنت بتكتب الكود، وCursor بيساعد.
Kiro معمول علشان يمسك مرحلة التخطيط الأول: العامل الذكي بيحدد إيه اللي لازم يتبني قبل ما يكتب أي جزء منه. لو أكبر مشكلة عندك هي بطء التنقل بين شات ذكاء اصطناعي ومحررك، Cursor بيحل ده بشكل مباشر أكتر. لو مشكلتك هي كود مولد بالذكاء الاصطناعي من غير بنية أو صعب صيانته، Kiro وworkflow بتاع spec بتاعه هو الرد الأنسب.
| الميزة | Kiro | Cursor |
|---|---|---|
| سهولة الاستخدام | مألوف لمستخدمي VS Code؛ وworkflow spec بيضيف منحنى تعلم | مألوف لمستخدمي VS Code؛ واحتكاكه أثناء الإعداد أقل |
| الأفضل لـ | بناء منظم قائم على الـ spec لمشاريع إنتاجية | تعديل سريع بمساعدة AI ومهام agent داخل قواعد كود موجودة |
| الـ Backend والبيانات | بيبني مشاريع محلية حقيقية مع تحكم كامل في الـ stack | بيعدل وبيوسّع ملفات المشروع الموجودة مع تحكم كامل في الـ stack |
| مرونة التصميم | مفيش visual builder؛ بيطلع كود حقيقي مملوك محليًا | مفيش visual builder؛ بيطلع كود حقيقي مملوك محليًا |
| نموذج التسعير | credit-based؛ 50 free credits؛ وكل الاستخدام بيتسحب من حصة credits شهرية | credit-based من يونيو 2025؛ Auto mode غير محدود؛ واختيار الموديلات المميزة بيتسحب من حصة credits شهرية |
الحكم النهائي: هل Kiro يستاهل؟
Kiro بيميز نفسه إنه بيحط التخطيط قبل البرمجة. Workflow بتاع specifications، وsteering documents، وتقسيم المهام بيدّوا codebase أكثر تنظيمًا وقابلية للصيانة من أدوات AI اللي بتدخل على التنفيذ مباشرة. ميزة Agent Hooks كمان من أبرز النقاط، لأنها بتخلي الأتمتة تشتغل بعد أول prompt وما تتوقفش عنده.
العيوب هي منحنى التعلم والتسعير. الخطة المجانية محدودة جدًا للمشاريع الكبيرة، والمطورين لازم يكونوا مرتاحين وهم شغالين في IDE. أثناء الاختبار واجهت timeout كمان، رغم إن Kiro تعافى من غير ما يفقد أي تقدم.
لو إنت مطور بتبني software إنتاجي، Kiro من أقوى أدوات البرمجة بالذكاء الاصطناعي المتاحة حاليًا. لكن لو بتدور على simple no-code app builder، فهو مش الاختيار المناسب.
