ثمانية مستويات للهندسة الذكية

المؤلف: بسميس إيلداث

الترجمة:宝玉

قدرة الذكاء الاصطناعي على البرمجة تتجاوز قدرتنا على السيطرة عليها. لهذا السبب، كل تلك الجهود المبذولة لتحسين نتائج SWE-bench لا تتماشى حقًا مع مؤشرات الإنتاجية التي يهتم بها قادة الهندسة. فريق أنثروبيك أطلق Cowork خلال 10 أيام، بينما فريق آخر يستخدم نفس النموذج لكنه لم يتمكن حتى من إنشاء نموذج إثبات المفهوم — الفرق هو أن أحد الفرق قد سد الفجوة بين القدرة والتطبيق، والآخر لم يفعل.

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

سبب آخر يجب أن تهتم به هو تأثير التعاون الجماعي. إنتاجك يعتمد أكثر مما تتصور على مستوى زملائك. افترض أنك محترف في المستوى 7، وفي الليل، الذكاء الاصطناعي في الخلفية يساعدك على تقديم عدة طلبات سحب (PR). لكن إذا كان مستودع الكود الخاص بك يحتاج إلى موافقة زميل لدمجه، وكان هذا الزميل لا يزال في المستوى 2 ويقوم بمراجعة يدوية، فإنتاجيتك ستتوقف. لذلك، مساعدة زملائك على الترقية مفيد لك أيضًا.

من خلال التفاعل مع العديد من الفرق والأفراد حول ممارسات استخدام الذكاء الاصطناعي في البرمجة، إليك مسار التقدم عبر المستويات (ترتيبه ليس صارمًا دائمًا):

مستويات هندسة الذكاء الاصطناعي الثمانية

المستويان 1 و2: إكمال تلقائي باستخدام Tab وبيئة تطوير ذكية

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

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

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

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

المستوى 3: هندسة السياق

الآن نصل إلى الجزء الممتع. هندسة السياق (Context Engineering) أصبحت كلمة رائجة في 2025، لأنها تعتمد على أن النموذج يمكنه الآن اتباع عدد معقول من التعليمات بشكل موثوق، مع سياق مناسب. السياق المزدحم أو غير الكافي يضر على حد سواء، لذا العمل الأساسي هو زيادة كثافة المعلومات لكل رمز (token). “كل رمز يجب أن يقاتل من أجل مكانه في التعليمات” — هذا كان المبدأ آنذاك.

نفس المعلومات، مع رموز أقل — الكثافة المعلوماتية هي الملك (المصدر: humanlayer/12-factor-agents).

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

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

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

• استهلاك الرموز بكميات كبيرة. بروتوكولات سياق النموذج (MCP) وادخال الصور تستهلك الرموز بسرعة، مما يجعلك تدخل في حالة “تخزين مضغوط” قبل المتوقع في Claude Code.

• الذكاء الاصطناعي المدمج مع عشرات الأدوات، يستهلك النموذج رموزًا أكثر في تحليل تعريف الأدوات من العمل الفعلي.

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

المستوى 4: الهندسة المركبة (Compounding Engineering)

تحسين هندسة السياق يركز على الجلسة الحالية، بينما الهندسة المركبة (كما اقترح كيران كلاسين) تهتم بجلسات لاحقة. هذا المفهوم كان نقطة تحول لي وللكثيرين — أدركنا أن “البرمجة بالمشاعر” ليست مجرد نماذج أولية.

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

الدورة المركبة: التخطيط، التفويض، التقييم، التثبيت — كل دورة تجعل التالية أفضل.

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

الناس الذين يمارسون الهندسة المركبة يكونون حساسين جدًا للسياق المقدم للنموذج. عندما يخطئ النموذج، رد فعلهم الطبيعي هو التفكير في نقص السياق، بدلًا من لوم النموذج. هذا الحدس هو الذي يجعل المستويات 5 إلى 8 ممكنة.

المستوى 5: MCP والمهارات

المستويان 3 و4 يعالجان مشكلة السياق. المستوى 5 يعالج مشكلة القدرة. MCP والمهارات المخصصة تتيح لنموذجك الوصول إلى قواعد البيانات، API، خطوط CI، أنظمة التصميم، أدوات الاختبار مثل Playwright، وأدوات الإشعارات مثل Slack. النموذج لم يعد يقتصر على التفكير في مستودع الكود — بل يمكنه الآن أن يتصرف مباشرة.

هناك الكثير من المصادر الممتازة عن MCP والمهارات، لذا لن أكررها هنا. لكن، كمثال، لدينا فريق يشارك مهارة مراجعة PR، ويعملون على تحسينها معًا (لا تزال قيد التطوير). المهارة تعتمد على تشغيل نماذج فرعية بناءً على نوع PR، مثل فاحص أمان تكامل مع قاعدة البيانات، أو محلل تعقيد يحدد التكرار أو الإفراط في الهندسة، أو فاحص صحة التعليمات لضمان التوافق مع معايير الفريق. كما تدير أدوات مثل linter وRuff.

لماذا نستثمر كثيرًا في مهارة المراجعة؟ لأنه عندما يبدأ النموذج في إنتاج PR بكميات كبيرة، فإن المراجعة اليدوية تصبح عنق زجاجة، وليست معيار الجودة. Latent Space قدم حجة مقنعة: مراجعة الكود التقليدية ماتت. الحل هو المراجعة الآلية، المتسقة، المدفوعة بالمهارات.

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

عندما يبدأ فريق من عدة أشخاص في بناء مهارات مماثلة، من المفيد دمجها في سجل مشترك. شركة Block (تحية لها) أنشأت سوق مهارات داخلي، يضم أكثر من 100 مهارة، ويقدم حزم مهارات مخصصة للأدوار والفرق. المهارات والكود يُعاملون على قدم المساواة: طلبات السحب، المراجعة، التاريخ الإصدار.

اتجاه آخر مهم هو أن نماذج اللغة تتجه أكثر لاستخدام أدوات CLI بدلاً من MCP (ويبدو أن كل شركة تطلق أدواتها الخاصة: Google Workspace CLI، وBraintrust على وشك إصدار واحد). السبب هو كفاءة الرموز. خوادم MCP تكرر إدراج تعريف الأدوات في كل جولة، بغض النظر عن استخدام النموذج لها. أما CLI، فهي تنفذ أوامر محددة، ويُدرج المخرجات ذات الصلة فقط في نافذة السياق. أنا أستخدم بشكل كبير agent-browser بدلًا من Playwright MCP، لهذا السبب.

قبل أن نتابع، أوقف قليلاً. المستويان 3 إلى 5 يشكلان أساس كل شيء لاحق. النموذج قوي جدًا في بعض الأمور، وضعيف جدًا في أخرى، ويجب أن تتعلم كيف تتعرف على هذه الحدود، قبل أن تضيف مزيدًا من الأتمتة. إذا كان السياق فوضويًا، والتعليمات غير كاملة أو غير دقيقة، ووصف الأدوات غامض، فإن المستويات 6 إلى 8 ستزيد من تفاقم المشاكل.

المستوى 6: هندسة harness

المرحلة الحقيقية لانطلاق الصاروخ.

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

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

فريق Codex من OpenAI دمج أدوات Chrome DevTools، أدوات المراقبة، والتنقل عبر المتصفح في بيئة التشغيل، مما سمح له بالتقاط لقطات شاشة، قيادة عمليات الواجهة، استعلام السجلات، والتحقق من الإصلاحات. بمجرد إعطاءه تعليمات، يمكنه استنساخ الأخطاء، تسجيل فيديو، وتنفيذ الإصلاحات. ثم يتحكم في التطبيق للتحقق، يرسل PR، يرد على ملاحظات المراجعة، ويقوم بالدمج — كل ذلك مع تدخل بشري محدود. الذكاء الاصطناعي لا يكتب فقط الكود، بل يرى نتائج التغييرات، ويكرر التحسين — تمامًا مثل الإنسان.

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

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

مبدآن يعززان هذا المفهوم:

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

• القيود أفضل من الأوامر. التلميحات خطوة بخطوة (“أولاً افعل A، ثم B، ثم C”) أصبحت قديمة. من خبرتي، تحديد الحدود أكثر فاعلية من قوائم المهام، لأن النموذج يركز على القائمة ويتجاهل ما هو خارجها. التلميح الأفضل هو: “هذه النتيجة التي أريدها، استمر في العمل حتى تتأكد من نجاحها عبر جميع الاختبارات.”

نصف هندسة harness هو ضمان أن الذكاء الاصطناعي يمكنه التنقل بحرية في مستودع الكود دون اعتمادك المباشر. طريقة OpenAI هي: إبقاء ملف AGENTS.md في حدود 100 سطر، كفهرس يشير إلى مستندات أخرى، وتضمين تحديثاتها في عمليات CI، بدلاً من الاعتماد على تحديثات مؤقتة قد تتوقف بسرعة.

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

تنبيه: للأشخاص في المستويين 1 إلى 6، قد تبدو هذه الأفكار خيالية — لا بأس، احفظها للمستقبل، وارجع إليها لاحقًا.

المستوى 7: الذكاء الاصطناعي الخلفي (Backend AI Agents)

ملاحظة: نمط التخطيط يتلاشى.

Boris Cherny، مبتكر Claude Code، يقول إن 80% من المهام تبدأ بنمط التخطيط. لكن مع إصدار نماذج جديدة، تزداد نسبة النجاح بعد التخطيط مرة واحدة. أعتقد أننا نقترب من نقطة حرجة: أن نمط التخطيط كخطوة تدخل يدوي ستختفي تدريجيًا. ليس لأنه غير مهم، بل لأن النماذج أصبحت ذكية بما يكفي لتخطيط نفسها. لكن، بشرط أن تكون قد أتممت المستويات 3 إلى 6 بشكل جيد. إذا كانت السياقات نظيفة، والقيود واضحة، والأدوات موصوفة بشكل كامل، والدورات مغلقة، فالنموذج يمكنه التخطيط بشكل موثوق دون مراجعة منك. وإذا لم تكن قد أتممت ذلك، فستظل تراقب.

بوضوح، التخطيط كعملية عامة لن تختفي، بل ستتغير. للمبتدئين، لا يزال هو المدخل الصحيح (كما في المستويين 1 و2). لكن للمستوى 7، التخطيط أصبح أكثر استكشافًا: استكشاف مستودع الكود، عمل نماذج أولية في worktree، فهم حلول المشكلة. والأهم، أن الذكاء الاصطناعي الخلفي هو الذي يفتح هذا الباب. إذا استطاع الذكاء الاصطناعي أن يضع خطة موثوقة وينفذها بدون توقيع منك، فسيعمل بشكل غير متزامن أثناء انشغالك بأشياء أخرى. هذا تحول رئيسي — من “أنا أتنقل بين علامات تبويب” إلى “هناك عمل يتقدم بدون أن أكون موجودًا”.

طريقة Ralph هي نمط شائع: دورة ذكاء اصطناعي مستقل، يعيد تشغيل CLI البرمجي حتى تكتمل جميع متطلبات المنتج. لكن، تشغيل دورة Ralph بشكل جيد ليس سهلاً، وأي وصف غير دقيق أو غير كامل في المستندات سيعود عليك بنتائج عكسية. هو نوع من “أطلقه وابتعد”.

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

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

Dispatch يعمل محليًا، وهو مثالي لبيئات التطوير السريع حيث تريد رد فعل سريع، وتصحيح أسهل، وبدون تكلفة بنية تحتية. أما أداة Inspect من Ramp فهي مخصصة للعمل طويل الأمد، حيث كل جلسة ذكاء اصطناعي تُشغل في بيئة سحابية معزولة، مع بيئة تطوير كاملة. إذا اكتشف فريقك خطأ في الواجهة، يعلنه في Slack، وInspect يتولى الأمر عندما تغلق اللابتوب، ويعالج المشكلة. التحدي هو التعقيد التشغيلي (البنية التحتية، اللقطات، الأمان)، لكنك تحصل على حجم وقابلية إعادة الإنتاج لا يمكن أن توفرها الذكاء الاصطناعي المحلي. أنصح باستخدام الاثنين معًا (ذكاء اصطناعي محلي وسحابي).

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

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

كما أن الذكاء الاصطناعي الخلفي يفتح الباب لدمج CI وAI. بمجرد أن يمكنه العمل بدون تدخل، يمكنه أن يُطلق من البنية التحتية الحالية. روبوت المستندات، مثلاً، يعيد إنشاء المستندات بعد كل دمج، ويقدم PR لتحديث CLAUDE.md (نستخدمه، ويوفر وقتًا كبيرًا). روبوت المراجعة الأمنية يفحص PR ويقدم إصلاحات. روبوت إدارة الاعتمادات لا يكتفي بالإشارة للمشاكل، بل يرفع الحزم ويشغل اختبارات. كل ذلك مع سياق جيد، وقواعد متراكمة، وأدوات قوية، ودورات تغذية راجعة تلقائية — كلها تعمل بشكل مستقل.

المستوى 8: فريق الذكاء الاصطناعي المستقل

حتى الآن، لا أحد يسيطر تمامًا على هذا المستوى، رغم أن بعضهم يقترب. هو الطموح الأقصى.

في المستوى 7، لديك تنسيق مركزي عبر نماذج اللغة. في المستوى 8، تزيل هذا القيد. الذكاء الاصطناعي يتواصل مباشرة مع بعضه البعض — يتولى المهام، يشارك الاكتشافات، يحدد الاعتمادات، يحل النزاعات — كل ذلك بدون وسيط مركزي.

ميزة مبكرة: خاصية Agent Teams من Claude Code، حيث تعمل عدة نماذج بشكل متوازي على نفس المستودع، وتتواصل مباشرة. شركة أنثروبيك أنشأت 16 نموذجًا متوازيًا لبناء مترجم لينكس من الصفر. Cursor أطلقت مئات من الوكلاء المستمرين لأسابيع لبناء متصفح من الصفر، ونقل الكود من Solid إلى React.

لكن، عند التدقيق، تظهر مشاكل. عندما يكتشفون عدم وجود هيكل هرمي، يتردد الوكلاء، ويبدأون بالدوران بلا تقدم. أنثروبيك، على سبيل المثال، اضطروا لإضافة خطوط أنابيب CI لمنع التراجع. الجميع يتفق على أن تنسيق الوكلاء المتعددين هو مشكلة صعبة، ولم يُجدَ حل مثالي بعد.

بصراحة، أعتقد أن النماذج ليست جاهزة بعد لمثل هذا المستوى من الاستقلالية في معظم المهام. حتى لو كانت ذكية، فهي لا تزال بطيئة جدًا، وتستهلك الكثير من الرموز، وغير اقتصادية (رغم أنها مثيرة للإعجاب، إلا أنها ليست ناضجة بعد). بالنسبة لمعظم أعمالنا اليومية، المستوى 7 هو المفتاح الحقيقي. من غير المستبعد أن يصبح المستوى 8 هو المعيار، لكن الآن، أركز على المستوى 7 (إلا إذا كنت من Cursor — فالتجاوز هو هدفك).

المستوى ?:

السؤال الحتمي: “ماذا بعد؟”

بمجرد أن تتقن تنسيق فرق الوكلاء بشكل سلس، لن يكون هناك سبب لوقف التفاعل عند النص فقط. التفاعل الصوتي مع الصوت، أو التفاعل الحواري مع الذكاء الاصطناعي — مثل Claude Code الحواري — هو التطور الطبيعي التالي. تخيل أن تشرح بصوت عالٍ التغييرات التي تريدها، ثم تراقبها تحدث أمامك.

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

إذن، في أي مستوى أنت؟ وما الذي تفعله للوصول إلى المستوى التالي؟

في أي مستوى أنت؟

كيف تبدأ عادة مهمة برمجية باستخدام الذكاء الاصطناعي؟