✦ Awesome Arabic AI

← العودة للرئيسية

👨‍💻 سير عمل المطور مع الذكاء الاصطناعي

هذه الصفحة تحتوي على سير عمل عملية للمطورين — ليست مجرد برومبتات، بل أنظمة خطوة بخطوة لاستخدام الذكاء الاصطناعي في مهام التطوير الفعلية.

💡 ملاحظة اللغة: مهام البرمجة تعطي نتائج أفضل عادةً بالإنجليزية. البرومبتات في هذه الصفحة مكتوبة بالإنجليزية عمداً — أضف التوجيه بالعربية فوقها إذا أردت.

سير عمل ١: تشخيص خطأ مع الذكاء الاصطناعي

الهدف: تحديد سبب الخطأ، فهم الجذر، واقتراح إصلاح مع شرح المقايضات.

متى تستخدمه:

  • عندما تكون رسالة الخطأ غير واضحة
  • عندما جربت أكثر من حل ولم ينجح أي منها
  • عندما تريد فهم لماذا الخطأ حدث لا فقط كيف تصلحه

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

الخطوات:

  1. لا تلصق الكود كله — حدد الجزء المشكل فقط (مع السياق الكافي)
  2. أضف رسالة الخطأ الكاملة
  3. اشرح ما كنت تتوقعه مقابل ما حدث
  4. اطلب تشخيصاً أولاً، ثم حلاً
Prompt 
I'm getting the following error in my [language/framework] code:

Error:
[paste the full error message]

Relevant code:
```
[paste the relevant section only]
```

Context:
- What I expected: [describe expected behavior]
- What happened instead: [describe actual behavior]
- What I already tried: [list attempts, or "nothing yet"]

Please:
1. Diagnose what's causing this error
2. Explain why it's happening (not just what)
3. Suggest a fix with a brief explanation of the tradeoffs if there are multiple approaches

علامات الناتج الجيد:

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

أخطاء شائعة:

  • لصق ١٠٠٠ سطر كود وكتابة "فيه خطأ أين هو؟" — يعطيك ناتجاً ضعيفاً
  • عدم ذكر ما جربت — النموذج قد يقترح نفس الحلول الفاشلة
  • تطبيق الحل دون فهمه — ستقع في نفس الخطأ مستقبلاً

كيف تحسن النتيجة؟ بعد الحل الأول، اطلب: "ما الاختبارات أو الحالات الحدّية التي قد تكسر هذا الإصلاح؟" ثم اختبرها فعلياً قبل اعتماد الحل.

سير عمل ٢: كتابة ميزة جديدة

الهدف: كتابة كود لميزة محددة مع ضمان التوافق مع البنية القائمة والمعايير المتفق عليها.

متى تستخدمه:

  • عند كتابة ميزة من الصفر وتريد سرعة مع جودة
  • عندما تعمل في تقنية تعرفها لكن تريد الكود الأسرع
  • عندما تريد مقارنة تصميمات مختلفة قبل الالتزام بأحدها

الأدوات/النموذج المناسب: نموذج جيّد في توليد الكود المنضبط بالقيود. إذا كانت الميزة حساسة، اطلب الخطة من نموذج أول، والتنفيذ من نموذج ثانٍ للمقارنة.

الخطوات:

  1. صف الميزة بوضوح — المدخلات والمخرجات والحالات الخاصة
  2. أعطِ مثالاً على الاستخدام المتوقع
  3. حدد القيود التقنية (الإطار، الإصدار، أسلوب الكود)
  4. اطلب خطة قبل الكود إذا كانت الميزة معقدة
Prompt 
I need to implement the following feature in [language/framework version]:

Feature description:
- What it does: [clear one-paragraph description]
- Input: [what it receives]
- Output: [what it should return or do]
- Edge cases to handle: [list them]

Expected usage example:
```
[show a simple call example or use case]
```

Technical constraints:
- [e.g., must be async / must not use external libraries / must follow existing naming conventions]
- Existing code style: [e.g., we use arrow functions, no classes]

Please:
1. Propose the implementation approach in 2–3 sentences before writing code
2. Write the implementation
3. Add inline comments only where the logic isn't obvious
4. Point out any assumption you made

علامات الناتج الجيد:

  • الكود يعمل عند تشغيله (اختبره دائماً)
  • الكود يعالج الحالات الخاصة التي ذكرتها
  • التعليقات تشرح لماذا لا ماذا
  • النموذج ذكر افتراضاته بوضوح

أخطاء شائعة:

  • طلب ميزة كاملة دفعة واحدة — ابدأ بالهيكل ثم أضف التفاصيل
  • عدم ذكر قيود التقنية — قد تحصل على كود يكسر الأنماط القائمة
  • الثقة الكاملة دون اختبار — الكود الذي يبدو صحيحاً قد يفشل في الحالات الخاصة

كيف تحسن النتيجة؟ اطلب نسخة ثانية من نفس الحل بأسلوب مختلف (مثلاً functional vs class-based) ثم اختر الأنسب لبنية المشروع الحالية.

سير عمل ٣: كتابة وصف Pull Request

الهدف: تحويل التغييرات التقنية إلى وصف واضح يساعد المراجعين ويوثّق قرارات التصميم.

متى تستخدمه:

  • بعد الانتهاء من ميزة أو إصلاح وقبل رفع الـ PR
  • عندما تكون التغييرات معقدة وتحتاج شرحاً للفريق

الأدوات/النموذج المناسب: نموذج يبرع في التلخيص التقني المنظّم. يمكنك تزويده بـ diff مختصر أو نقاط التغيير الأساسية بدل كامل السجل.

الخطوات:

  1. الصق الـ diff أو وصف التغييرات
  2. اشرح السياق والسبب
  3. اطلب وصفاً منظماً وليس ملخصاً فقط
Prompt 
Write a pull request description for the following changes:

Summary of what changed:
[describe what you modified, added, or removed]

Why this change was made:
[the problem this solves or the requirement it fulfills]

Related ticket/issue: [link or "none"]

Technical notes (optional):
[any non-obvious design decisions, tradeoffs, or things reviewers should pay attention to]

Format the PR description with these sections:
- **Summary** (2–3 sentences)
- **What changed** (bullet list)
- **Why** (the motivation)
- **How to test** (specific steps for the reviewer)
- **Notes** (anything reviewers should know, or "none")

علامات الناتج الجيد:

  • المراجع يفهم لماذا التغيير حدث بدون سؤال
  • خطوات الاختبار قابلة للتنفيذ
  • القرارات التصميمية غير الواضحة موثّقة

أخطاء شائعة:

  • وصف PR يكرر الـ diff بدون ذكر الدافع
  • خطوات اختبار عامة غير قابلة للتنفيذ
  • نسيان توثيق المقايضات أو المخاطر

كيف تحسن النتيجة؟ اطلب من النموذج مراجعة الوصف بنظرة مراجع: "ما السؤال الذي سيطرحه المراجع بعد قراءة هذا الوصف؟" ثم أضف الإجابة داخل الـ PR.

← Back to Home

👨‍💻 Developer AI Workflows

This page contains practical workflows for developers — not just prompts, but step-by-step systems for using AI in real development tasks.

💡 Language note: Coding tasks typically produce better results in English. The prompts on this page are intentionally in English.

Workflow 1: Debugging with AI

Goal: Identify the root cause of an error, understand why it's happening, and get a fix with tradeoffs explained.

When to use:

  • When the error message isn't clear
  • When you've tried multiple solutions and none worked
  • When you want to understand why the error happened, not just how to fix it

Tools/model type: A model strong in technical reasoning and error interpretation. In most cases, use English for debugging prompts to increase diagnostic precision.

Steps:

  1. Don't paste all your code — identify the problematic section with enough context
  2. Include the complete error message
  3. Explain what you expected vs. what happened
  4. Ask for a diagnosis first, then a solution
Prompt 
I'm getting the following error in my [language/framework] code:

Error:
[paste the full error message]

Relevant code:
```
[paste the relevant section only]
```

Context:
- What I expected: [describe expected behavior]
- What happened instead: [describe actual behavior]
- What I already tried: [list attempts, or "nothing yet"]

Please:
1. Diagnose what's causing this error
2. Explain why it's happening (not just what)
3. Suggest a fix with a brief explanation of the tradeoffs if there are multiple approaches

Signs of good output:

  • The explanation starts with "The root cause is..." not "The fix is..."
  • The fix is understandable — not blind copy-paste
  • If there are multiple approaches, it clarifies when to use each

Common mistakes:

  • Pasting 1000 lines and writing "there's a bug somewhere" — gives weak output
  • Not mentioning what you already tried — the model may suggest the same failed solutions
  • Applying the fix without understanding it — you'll hit the same error again

How to refine the result: After the first fix, ask: "What edge cases or tests could break this patch?" and validate those cases before merging.

Workflow 2: Writing a new feature

Goal: Write code for a specific feature while ensuring compatibility with the existing architecture and agreed standards.

When to use:

  • When writing a feature from scratch and you want speed with quality
  • When you know the technology but want faster code
  • When you want to compare design approaches before committing

Tools/model type: A model that handles constrained code generation well. For critical features, generate plan and implementation in separate passes (or models) to reduce blind spots.

Steps:

  1. Describe the feature clearly — inputs, outputs, and edge cases
  2. Provide an example of the expected usage
  3. Specify technical constraints (framework, version, code style)
  4. Request a plan before code for complex features
Prompt 
I need to implement the following feature in [language/framework version]:

Feature description:
- What it does: [clear one-paragraph description]
- Input: [what it receives]
- Output: [what it should return or do]
- Edge cases to handle: [list them]

Expected usage example:
```
[show a simple call example or use case]
```

Technical constraints:
- [e.g., must be async / must not use external libraries / must follow existing naming conventions]
- Existing code style: [e.g., we use arrow functions, no classes]

Please:
1. Propose the implementation approach in 2–3 sentences before writing code
2. Write the implementation
3. Add inline comments only where the logic isn't obvious
4. Point out any assumption you made

Signs of good output:

  • Code works when you run it (always test)
  • Handles the edge cases you specified
  • Comments explain why, not what
  • Assumptions are clearly stated

Common mistakes:

  • Requesting full implementation in one shot with no staged validation
  • Missing framework/version constraints
  • Trusting generated code without execution tests

How to refine the result: Ask for a second variant using a different design style (for example functional vs class-based), then select what fits your current codebase conventions.

Workflow 3: Writing a pull request description

Goal: Turn technical changes into a clear description that helps reviewers and documents design decisions.

When to use:

  • After completing a feature or fix, before opening the PR
  • When changes are complex and need explanation for the team

Tools/model type: A model good at structured technical summarization. Feed it concise change notes or selected diff sections, not raw unrelated file history.

Steps:

  1. Provide a concise change summary and motivation
  2. List non-obvious design decisions and tradeoffs
  3. Request executable reviewer test steps
  4. Review the draft for missing context before posting
Prompt 
Write a pull request description for the following changes:

Summary of what changed:
[describe what you modified, added, or removed]

Why this change was made:
[the problem this solves or the requirement it fulfills]

Related ticket/issue: [link or "none"]

Technical notes (optional):
[any non-obvious design decisions, tradeoffs, or things reviewers should pay attention to]

Format the PR description with these sections:
- **Summary** (2–3 sentences)
- **What changed** (bullet list)
- **Why** (the motivation)
- **How to test** (specific steps for the reviewer)
- **Notes** (anything reviewers should know, or "none")

Signs of good output:

  • Reviewers understand why the change was made without asking
  • Testing steps are executable
  • Non-obvious design decisions are documented

Common mistakes:

  • Repeating the diff without motivation
  • Providing vague test instructions
  • Skipping known tradeoffs and risks

How to refine the result: Ask the model to critique the PR description from a reviewer perspective: "What would still be unclear?" then patch those gaps.