حالة البرمجة بمساعدة الذكاء الاصطناعي في 2026: الاتجاهات والأدوات وما هو قادم

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

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

التبني تجاوز مرحلة الفجوة

أبرز تغيير بين 2024 و2026 هو عمق التبني، وليس مجرد اتساعه. أظهرت الدراسات المبكرة أن حوالي 40-50% من المطورين جربوا أداة برمجة بالذكاء الاصطناعي. بحلول أوائل 2026، تجاوز هذا الرقم 80%، والاستخدام اليومي النشط بين المطورين المحترفين يتجاوز 70%. هذه ليست تجارب ترفيهية — المطورون يستخدمون الذكاء الاصطناعي لكتابة كود إنتاجي، وتصحيح مشاكل معقدة، وإعادة هيكلة أنظمة قديمة، وتوليد مجموعات اختبار.

حدث التحول لثلاثة أسباب. أولاً، تحسنت الموثوقية بشكل كبير. النماذج التي تقوم عليها أدوات مثل Claude Opus 3.5 وGPT-5 وGemini 2.5 Pro تنتج كوداً صحيحاً وأصيلاً بشكل أكثر اتساقاً بكثير من سابقاتها. عصر "البرمجة بالمزاج" في 2024 — حيث كنت تقبل ما يخرجه الذكاء الاصطناعي وتأمل — أفسح المجال لنموذج تفاعل أكثر توقعاً وهندسية. ثانياً، أصبحت الأدوات مدمجة بعمق في المحررات والطرفيات بدلاً من العيش في نوافد محادثة منفصلة. عندما يكون الذكاء الاصطناعي على بعد ضغطة مفتاح داخل بيئة التطوير الفعلية، تستخدمه أكثر، وتستخدمه لمهام أصغر وأكثر تواتراً. ثالثاً، بدأت الفرق في مشاركة مكتبات الأوامر وتكوينات الوكلاء وأنماط سير العمل، مما خفض منحنى التعلم بشكل كبير.

يبلغ GitHub Copilot الآن عن أكثر من 5 ملايين مشترك مدفوع. استحوذ Cursor على ما يقدر بـ 15-20% من سوق VS Code، حيث يستشهد العديد من المطورين به كمحررهم الأساسي. Claude Code، الذي أُطلق في منتصف 2025، أعاد تعريف ما يمكن لأداة طرفية قائمة على الذكاء الاصطناعي فعله وسرعان ما أصبح الخيار الافتراضي لأعمال الخلفية والبنية التحتية. نما Gemini Code Assist بسرعة في نظام Google Workspace، خاصة بين المؤسسات التي تستخدم بالفعل Cloud Code وFirebase.

لكن الاتجاه الأكثر إثارة للاهتمام ليس الحصة السوقية — بل كيف تتقارب الأدوات بينما تتمايز في نفس الوقت. تقدم كل أداة رئيسية الآن إمكانيات وكيلة، ودعم MCP، وتحرير متعدد الملفات. يتحول التمايز نحو عمق التكامل، وقابلية توسيع البروتوكول، وأتمتة سير العمل، وليس جودة توليد الكود الأساسية.

مشهد الأدوات في 2026: أربع ركائز

Claude Code — الوكيل الأصلي للطرفية

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

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

# Typical Claude Code session — implementing a new API endpoint
$ claude

> Add a rate-limited POST endpoint to the payments router

# Claude Code discovers the router pattern, reads existing endpoints,
# checks the database schema, generates the implementation, runs tests:

✓ Read src/routes/payments.ts (existing pattern)
✓ Read prisma/schema.prisma (rate_limit_config table)
✓ Generated src/middleware/rateLimit.ts (token bucket algorithm)
✓ Updated src/routes/payments.ts (new POST /payments/charge)
✓ Added tests in tests/routes/payments.test.ts
✓ Ran test suite — 47 passed, 0 failed
✓ Lint — clean

Review the diff with `claude diff` or approve with `claude apply`.

للنهج الأصلي للطرفية ميزة أخرى: فهو يعمل بدون واجهة رسومية في خطوط CI/CD. تستخدم الفرق الآن Claude Code في GitHub Actions لإصلاح أخطاء المدقق تلقائياً، وتوليد سجلات التغييرات، وحتى كتابة مسودات أولية لملاحظات الإصدار. نفس الواجهة التي تعمل تفاعلياً على جهاز المطور تعمل أيضاً بشكل مؤتمت في خط أنابيب.

Cursor — القوة المحررة الأصيلة لـ IDE

تطور Cursor بقوة خلال 2025. ميزة Composer الخاصة به، التي تسمح بتحرير متعدد الملفات من أمر واحد، أصبحت المعيار الذهبي للتفاعلات القائمة على IDE. عامل التمايز الرئيسي هو الفهرسة العميقة: يبني Cursor فهرساً متجهاً لقاعدة الكود بالكامل، لذلك عندما تطلب منه "تحديث مكون ملف المستخدم ليتوافق مع نظام التصميم الجديد"، فهو يعرف بالفعل أين توجد رموز نظام التصميم، وأي المكونات تستخدمها، وكيف يبدو نمط الترحيل.

وضع الوكيل في Cursor يستحق ذكراً خاصاً. على عكس نموذج الإكمال المضمن، يمكن لوضع الوكيل تخطيط تغيير متعدد الخطوات بشكل مستقل، وتنفيذه عبر الملفات، وتشغيل الاختبارات، والتكرار على حالات الفشل. المطور يشرف بدلاً من أن يدقق. لأعمال الواجهة الأمامية — مكونات React، إعادة هيكلة CSS، توليد عميل API — أصبح وضع الوكيل سير العمل الأساسي للعديد من المطورين.

GitHub Copilot — المعيار المؤسسي

استغرق Copilot وقتاً أطول لشحن الإمكانيات الوكيلة، ولكن بحلول أوائل 2026، قام كل من Copilot Workspace وCopilot Agent بسد معظم فجوة الميزات. ميزة Copilot هي التوزيع: فهو يأتي مع كل حساب GitHub Enterprise، ويتكامل مع Actions وطلبات السحب وسير عمل مراجعة الكود بشكل أصلي. إذا كان فريقك يعيش في GitHub، فإن احتكاك تبني Copilot يقترب من الصفر.

الميزة الأكثر استخفافاً في Copilot هي تكامل طلبات السحب. عندما يفتح مطور طلب سحب، يقوم Copilot تلقائياً بتوليد ملخص، وتسليط الضوء على المشكلات المحتملة، واقتراح مجالات تركيز المراجع. لا يتعلق الأمر باستبدال المراجعة البشرية — بل بجعل المراجعة البشرية أكثر كفاءة من خلال التعامل مع الأجزاء الميكانيكية. الفرق التي تبنت هذا النهج تبلغ عن تقليل وقت مراجعة طلبات السحب بنسبة 30-40% تقريباً.

Gemini Code Assist — لعبة النظام البيئي

نما Gemini Code Assist بثبات من خلال التركيز على أنظمة Google Cloud وAndroid. تكامله العميق مع Cloud Code وFirebase وGoogle Workspace يمنحه خندقاً في تلك البيئات. الميزة البارزة هي الإكمال المدرك للسياق عبر خدمات Google Cloud: عندما تكتب كوداً يتفاعل مع Cloud Run أو Firestore أو BigQuery، يفهم Gemini سطح API ويولد استخداماً صحيحاً وأصيلاً.

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

طبقة البروتوكول: MCP وWebMCP

أهم تطور في البنية التحتية خلال الـ 18 شهراً الماضية ليس أداة أو نموذجاً — بل هو بروتوكول سياق النموذج (MCP). MCP هو معيار مفتوح يحدد كيف تتصل أدوات الذكاء الاصطناعي بمصادر البيانات والخدمات الخارجية. فكر فيه كـ USB-C للذكاء الاصطناعي: بروتوكول واحد يسمح لأي عميل متوافق مع MCP بالاتصال بأي خادم متوافق مع MCP، بغض النظر عن البائع.

قبل MCP، كان لكل أداة ذكاء اصطناعي نظام إضافات خاص بها، وAPI تكامل خاص بها، وطريقتها الخاصة في الوصول إلى الملفات وقواعد البيانات وواجهات API. كان على بناة الأدوات كتابة N تكامل لمصادر بيانات N. قلب MCP هذا: خادم واحد لكل مصدر بيانات، بروتوكول عميل واحد لكل أداة، وكلها تعمل معاً. كانت النتيجة انفجاراً في خوادم MCP المجتمعية لقواعد البيانات (PostgreSQL، SQLite، Redis)، والمنصات السحابية (AWS، GCP، Cloudflare)، وأدوات التطوير (GitHub، Linear، Sentry)، وحتى تطبيقات المستهلك (Notion، Gmail، Slack).

إعداد MCP نموذجي يبدو كالتالي:

// ~/.claude/mcp-servers.json — the MCP server registry
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost:5432/myapp"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "linear": {
      "command": "npx",
      "args": ["-y", "@raycast/mcp-linear"]
    }
  }
}

مع هذا الإعداد، يمكن للمطور أن يطلب من Claude Code "اعثر على جميع المشكلات المفتوحة في Linear الموسومة بـ 'خلل'، وتحقق مما إذا تم إصلاح أي منها في آخر ثلاث عمليات دفع، وانشر ملخصاً في قناة فريقنا على Slack." تقوم أداة الذكاء الاصطناعي بالتنسيق عبر خوادم MCP — Linear للمشكلات، GitHub لعمليات الدفع، Slack للرسائل — دون أن يغير المطور سياقه أو يكتب كود لصق. هذا ليس عرضاً توضيحياً. الفرق تستخدم سير العمل هذه في الإنتاج كل يوم.

WebMCP، الذي أُعلن عنه في أواخر 2025، يوسع بروتوكول MCP إلى سياقات المتصفح. بدلاً من أن ترى أداة الذكاء الاصطناعي قاعدة الكود فقط، يمكنها رؤية والتفاعل مع تطبيقات الويب: لوحات المعلومات، مواقع التوثيق، أدوات التصميم في Figma، لوحات المشاريع. مطور يقوم بتصحيح مشكلة إنتاجية يمكنه أن يطلب من الذكاء الاصطناعي فتح لوحة معلومات Datadog، والعثور على ارتفاع الأخطاء، والتحقق من السجلات المرتبطة، وربطها بالنشر الأخير — كل ذلك من خلال واجهة MCP نفسها. WebMCP يحول المتصفح بأكمله إلى مساحة عمل يمكن للذكاء الاصطناعي الوصول إليها.

MCP هو أهم مشروع بنية تحتية للذكاء الاصطناعي لم يسمع به معظم المطورين. إنه يفعل لأدوات الذكاء الاصطناعي ما فعله HTTP لخدمات الويب — يوفر واجهة عالمية تفصل العملاء عن الخوادم وتمكن نظاماً بيئياً لا يمكن لأي بائع واحد بناؤه بمفرده.

كيف تغيرت سير عمل التطوير فعلياً

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

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

• المرحلة 1 — الاستكشاف: تصف الهدف، ويستكشف الذكاء الاصطناعي قاعدة الكود لفهم السياق ذي الصلة — الأنماط الموجودة، نماذج البيانات، التكوين، الاختبارات. أنت لا تخبر الذكاء الاصطناعي أين يبحث؛ هو يكتشف ذلك من فهرس قاعدة الكود أو شجرة الملفات. هذه المرحلة تنتج خطة تراجعها قبل كتابة أي كود.
• المرحلة 2 — التوليد: بمجرد الموافقة على الخطة، يولد الذكاء الاصطناعي التنفيذ. اعتماداً على الأداة وتعقيد المهمة، قد يكون هذا تغيير ملف واحد أو ميزة متعددة الملفات تمتد لعشرات الملفات. يدير الذكاء الاصطناعي البناء والاختبارات تلقائياً، مصلحاً أي مشاكل يمكنه حلها.
• المرحلة 3 — التحسين: تراجع الفرق، وتترك تعليقات على أسطر محددة، ويتكرر الذكاء الاصطناعي. هذه هي أهم مرحلة — المطورون الذين يتخطونها يحصلون على أدنى جودة نتائج. الفرق بين مطور جيد بمساعدة الذكاء الاصطناعي ومطور عظيم هو مدى فعالية تحسينهم، وليس مدى فعالية أوامرهم في المحاولة الأولى.

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

تأمل دورة طلب سحب نموذجية في 2026:

# Developer workflow — adding a feature with AI

# Step 1: Explore
$ claude "Add CSV export to the analytics dashboard. Use the same
  pattern as the PDF export in reports.ts, but for CSV output."

# Claude produces a plan:
#   - Create src/services/csvExporter.ts
#   - Create src/routes/analytics/export.ts (new endpoint)
#   - Add tests in tests/routes/analytics/export.test.ts
#   - Update src/routes/analytics/index.ts (register router)

# Step 2: Generate (after plan approval)
$ claude apply
# Claude writes all files, runs tests, fixes 2 failing assertions

# Step 3: Refine
$ claude diff | less
# Developer spots missing edge case (empty dataset)
$ claude "Handle the case where the dataset is empty — return
  a CSV with just headers and a message row"

# Step 4: Ship
$ git add -A && git commit -m "feat: add CSV export to analytics
  dashboard" --author="Claude Code <ai@example.com>"

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

انتقلت التوثيقات من مهمة مكروهة إلى أثر مؤتمت. كل أداة برمجة ذكاء اصطناعي رئيسية يمكنها توليد وتحديث التوثيقات من تغييرات الكود. عندما ينفذ المطور ميزة، يمكن للذكاء الاصطناعي إنتاج أو تحديث توثيقات API، والتعليقات المضمنة، وأقسام README، وإدخالات سجل التغييرات. الفرق التي تتبنى هذا النمط تبلغ عن تحسن تغطية التوثيقات من حوالي 30% إلى أكثر من 90% لأن تكلفة كتابة التوثيقات انخفضت إلى الصفر تقريباً.

ما يجب على المطورين تعلمه بعد ذلك

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

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

ليست أي من هذه المهارات جديدة. المطورون الكبار احتاجوها دائماً. ما تغير هو أنها لم تعد اختيارية. مطور مبتدئ لا يستطيع تقييم مخرجات الذكاء الاصطناعي، أو تصميم سير العمل، أو المراجعة من أجل الأمن لن يصبح مطوراً كبيراً بكتابة المزيد من الكود — لأن كتابة الكود أصبحت مؤتمتة بشكل متزايد. طريق الأقدمية الآن يمر عبر الحكم والتصميم والتقييم، وليس عبر عدد أسطر الكود المكتوبة.

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

ما هو قادم

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

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

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