أصبح وكلاء البرمجة من الجودة بحيث لم يعد الجزء الغريب هو ما إذا كانوا قادرين على كتابة الكود.

فهم قادرون.

الجزء الأغرب هو ما يحدث للمطوّر عندما يفعلون ذلك.

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

هذا أمر قوي.

لكنه يخلق أيضًا نمط فشل جديدًا.

أنت تقرأ كودًا أقل.

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

لكن قراءة الكود لم تكن يومًا مجرد وسيلة لإنتاج الكود.

قراءة الكود كانت الطريقة التي تتعلّم بها قاعدة الكود.

عنق الزجاجة التالي في البرمجة الوكيلية ليس فقط نافذة سياق النموذج.

بل نافذة سياق الإنسان.

سير عمل البرمجة الجديد

سير العمل الناشئ يبدو تقريبًا هكذا:

• استخدم نموذجًا قويًا بوصفه المنسّق (orchestrator).
• استخدم نماذج أرخص أو أسرع بوصفها عمّال تنفيذ.
• دَع المنسّق يخطّط ويراجع ويعيد الهيكلة ويوجّه.
• دَع نماذج العمل تكتب معظم الكود.
• دَع الإنسان يصف النية، ويوافق على الاتجاه، ويتدخّل حين يكون الذوق مهمًا.

هذا منطقي.

نموذج العمل يستطيع توليد كثير من الكود. ويستطيع حل معظم مهام التنفيذ. ويستطيع الاستمرار مدة طويلة دون أن يعلق.

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

النتيجة سير عمل يُكتب فيه كثير من الكود دون أن يلمس الإنسان كل ملف.

هذا ليس سيئًا بالضرورة.

بل قد يكون الشكل الصحيح لتطوير البرمجيات في المستقبل.

لكنه يغيّر ما يفعله الإنسان.

لم يعد الإنسان يكتب الكود في المقام الأول.

الإنسان يوجّه النظام الذي يكتب الكود.

والتوجيه يتطلب سياقًا.

آلية الأمان القديمة

قبل الوكلاء، كان سير العمل أبطأ.

كنت تفتح الملفات. وتجد المكوّن ذا الصلة. وتقرأ الكود المحيط. وتلاحظ التسمية الغريبة. وتتعلّم أين تعيش الحالة (state). وتكتشف التجريد القديم الذي لا يحبه أحد لكن الجميع ما يزالون يعتمدون عليه.

ثم تُجري التغيير.

كانت تلك العملية تبدو غير فعّالة لأن كثيرًا منها لم يكن منتجًا بشكل مباشر.

لكن كان لها أثر جانبي مهم: كانت تحمّل قاعدة الكود في رأسك.

كنت تتعلّم:

• أين توجد الأشياء.
• ماذا تُسمّى الأشياء.
• أي المكوّنات تملك أي المسؤوليات.
• أي التجريدات حقيقية وأيها عرضية.
• أي أجزاء قاعدة الكود نظيفة.
• أي الأجزاء ملعونة.
• أي المقايضات كانت مقصودة.
• أي المقايضات مجرد ضرر تاريخي.

تلك المعرفة كانت تجعل موجّهاتك (prompts) المستقبلية أفضل قبل أن توجد الموجّهات أصلًا.

كانت تجعل طلبات السحب (pull requests) المستقبلية أفضل.

كانت تجعل حكمك على المنتج أفضل.

كانت قاعدة الكود تعلّمك بينما تعمل عليها.

نمط الفشل الجديد

مع الوكلاء، يمكن أن تصبح الحلقة:

describe intent
agent searches code
agent edits files
agent runs tests
agent summarizes changes
human skims diff
human approves

هذه الحلقة سريعة.

لكنها تزيل أيضًا كثيرًا من التعلّم العرضي.

قد تشحن الميزة دون أن تبني أبدًا نموذجًا ذهنيًا حقيقيًا للكود الذي غيّرته للتو.

في المرات القليلة الأولى، لا بأس بذلك. كان لدى النموذج سياق كافٍ. بدا الفرق (diff) معقولًا. نجحت الاختبارات. تقدّم المنتج.

ثم تستمر قاعدة الكود في التغيّر.

بعض التغييرات تجريها أنت. وبعضها الوكلاء. وبعضها أشخاص آخرون يستخدمون الوكلاء. ينمو النظام. تتحوّل التجريدات. تظهر اصطلاحات جديدة. وتتحلّل القديمة. تنتقل المكوّنات. وتنقسم المسؤوليات. وتهاجر الحالة من طبقة إلى أخرى.

أنت ما تزال تعرف المنتج.

لكنك تعرف أقل فأقل عن كيفية تمثيل المنتج في الكود.

في النهاية، المشكلة ليست أن الوكيل لا يستطيع كتابة الكود.

المشكلة أنك لا تعرف ماذا تطلب.

جودة الموجّهات تتحلّل مع تحلّل سياق الإنسان

الموجّهات الجيدة ليست كلمات سحرية.

الموجّهات الجيدة سياق مضغوط.

الموجّه الضعيف يقول:

Make the sidebar work with team workspaces.

والموجّه الأقوى يقول:

The sidebar is currently user-scoped, but navigation needs to become workspace-scoped.

Keep the Sidebar component presentational.
Move workspace resolution into the navigation provider.
Preserve the command palette behavior.
Do not duplicate route filtering logic.
Update the empty state for users with access to multiple workspaces.

الموجّه الثاني ليس أفضل لأنه أطول.

بل هو أفضل لأن الإنسان يفهم قاعدة الكود.

فهو يعرف أين ينبغي أن تعيش المسؤولية. ويعرف أي تجريد يجب ألا يُكرَّر. ويعرف أي ميزة مجاورة تعتمد على الحالة نفسها. ويعرف النية القديمة والنية الجديدة.

هذا هو الجزء الذي لا يزيله الوكلاء.

إنهم يجعلون تنفيذ اتجاه ما أسهل.

لكنهم لا يزيلون الحاجة إلى اختيار الاتجاه.

إذا فقد الإنسان الخريطة، ساء التوجيه.

وعندما يسوء التوجيه، يسوء المنتج في النهاية أيضًا.

المشكلة تنتقل

كثير من البنية التحتية للوكلاء تركّز على منح النموذج مزيدًا من السياق.

هذا مفيد.

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

لكن هناك مشكلة سياق أخرى.

الإنسان أيضًا يحتاج إلى سياق.

ليس كل تفصيلة. ولا كل سطر. ولا كل دالة مساعدة.

لكن ما يكفي لاتخاذ قرارات جيدة.

ما يكفي لمعرفة:

• ما شكل هذه الميزة؟
• ما الذي يملك هذه الحالة؟
• ما الذي يحاول هذا المكوّن أن يكونه؟
• أي الأجزاء موروثة (legacy)؟
• أي التجريدات حاملة للأثقال؟
• أي الأسماء مهمة؟
• أي القرارات ما تزال صالحة؟
• أي القرارات اتُّخذت لمتطلبات لم تعد موجودة؟

الوكيل يحتاج إلى السياق ليتصرّف.

والإنسان يحتاج إلى السياق ليحكم.

وهذان منتجان مختلفان.

الطبقة المفقودة هي تعلّم قاعدة الكود

الأداة المفقودة ليست مجرد بحث أفضل في الكود.

وليست مجرد توثيق أفضل.

إنها معلّم لقاعدة الكود.

شيء يعلّم الإنسان باستمرار كيف يعمل النظام.

ليس بشكل مجرّد.

وليس على هيئة README عملاق يتعفّن ببطء.

بل كطبقة شرح حيّة ملحقة بقاعدة الكود.

معلّم قاعدة الكود الجيد ينبغي أن يجيب عن أسئلة مثل:

• ما المفاهيم الرئيسية في هذه المنطقة؟
• من أين تأتي هذه الواجهة؟
• أي مكوّن يملك هذا السلوك؟
• لماذا هذا التدفق مقسّم عبر هذه الملفات؟
• ما الذي تغيّر مؤخرًا؟
• ما الاتجاه المقصود؟
• ما الذي لا ينبغي أن ألمسه باستخفاف؟
• ما التصميم القديم الذي نحاول الهجرة بعيدًا عنه؟

هذا ليس فقط لتأهيل المهندسين الجدد.

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

كلما كتب الوكيل كودًا أكثر، ازدادت أهمية هذا الأمر.

توثيق للإنسان، لا للوكيل

هناك إغراء بحل هذه المشكلة عبر حشو مزيد من التوثيق في سياق الوكيل.

هذا يساعد الوكيل.

لكنه لا يساعد الإنسان بشكل كامل.

الإنسان لا يحتاج إلى تفريغ سياق متضخم قبل كل مهمة. الإنسان يحتاج إلى خريطة قابلة للتصفح.

طبقة تعلّم قاعدة الكود المفيدة ينبغي أن تُحسَّن من أجل الكشف التدريجي (progressive disclosure).

ابدأ من المستوى العالي:

• ما هذه الميزة؟
• ما المفاهيم الأساسية؟
• ما التدفقات الرئيسية؟

ثم دَع الإنسان يتعمّق:

• أي الملفات تنفّذ هذا؟
• أي المكوّنات مشاركة؟
• أي الخدمات تُستدعى؟
• أين تعيش الحالة؟
• ما الحالات الحدّية؟

ثم انزل أعمق فقط عند الحاجة:

• لماذا توجد هذه الدالة؟
• ما الافتراضات التي تفترضها؟
• ما الذي ينكسر إذا غيّرتها؟

في معظم الأحيان، لا يحتاج الإنسان إلى المستوى الأدنى.

بل يحتاج إلى المستوى الذي فوق الكود.

يحتاج إلى النوايا.

شجرة المعرفة

أحد الأشكال العملية هو شجرة من ملفات Markdown.

ليست وثيقة واحدة عملاقة.

وليست ملفات README مبعثرة.

بل شجرة معرفة منظّمة.

على سبيل المثال:

/codebase
  /map.md
  /glossary.md
  /features
    /workspace-navigation
      overview.md
      concepts.md
      ui.md
      state.md
      backend.md
      decisions.md
      debts.md
      files.md
    /billing-settings
      overview.md
      concepts.md
      ui.md
      provider-integrations.md
      decisions.md
      debts.md
      files.md
  /components
    /app-shell.md
    /command-palette.md
    /data-table.md
  /changes
    /2026-07-08-workspace-navigation.md
    /2026-07-02-billing-provider-refactor.md

ينبغي أن تكون قمة الشجرة قابلة للقراءة في دقيقة.

وينبغي أن تشير كل صفحة إلى صفحات أعمق.

وينبغي أن تشرح كل صفحة أعمق شيئًا واحدًا بوضوح.

الهدف ليس توثيق كل سطر من الكود.

الهدف هو الحفاظ على الخريطة التي اعتاد الإنسان بناءها يدويًا بقراءة الكود.

فضّل النوايا على الملخصات

التوثيق المولّد الرديء يبدو هكذا:

This file exports a React component called Sidebar.
It imports useWorkspace, Link, cn, and NavigationItem.
It renders a list of navigation items.

هذا صحيح تقنيًا.

لكنه أيضًا عديم الفائدة في معظمه.

الكود يقول ذلك بالفعل.

التوثيق المفيد يشرح النية:

Sidebar is intentionally presentational.

It receives the resolved navigation model from WorkspaceNavigationProvider
and should not decide which workspace is active.

This keeps route ownership in one place and prevents the command palette,
sidebar, and mobile nav from each implementing their own filtering logic.

هذه هي المعرفة التي يحتاجها الإنسان.

ليس فقط ما يفعله الكود.

بل لماذا الكود مصاغ على هذا الشكل.

اجعل الواجهة تشرح الكود

بالنسبة لمهندسي المنتج، يبدأ كثير من تعلّم قاعدة الكود من الواجهة.

ترى زرًا.

فتريد أن تعرف أين يعيش.

ترى صفحة.

فتريد أن تعرف أي المكوّنات تؤلّفها.

ترى سلوكًا غريبًا.

فتريد أن تعرف أي انتقال حالة سبّبه.

معلّم قاعدة الكود ينبغي أن يربط الواجهة بالكود.

على سبيل المثال، تخيّل طبقة تطوير (development overlay) تتيح لك فحص صفحة ورؤية:

Page
  WorkspaceSettingsPage
  app/workspaces/[workspaceId]/settings/page.tsx

Sections
  WorkspaceMembersPanel
  WorkspaceBillingPanel
  WorkspaceDangerZone

Data
  getWorkspaceSettings()
  getWorkspaceMembers()
  getBillingSubscription()

State ownership
  Server state: workspace settings
  Client state: pending invite modal
  URL state: selected settings tab

هذا النوع من الأدوات يغيّر طريقة كتابتك للموجّهات.

فبدلًا من أن تقول:

Change the settings page so members are easier to invite.

يمكنك أن تقول:

In WorkspaceSettingsPage, update WorkspaceMembersPanel so the invite flow is primary.

Keep pending invite modal state local to the members panel.
Do not move billing logic.
Preserve the selected settings tab in the URL.

الموجّه الثاني ليس فقط أكثر تحديدًا.

بل هو مثبَّت في قاعدة الكود.

تتبّع القرارات، لا الملفات فقط

معظم معرفة قاعدة الكود ليست معرفة بالملفات.

بل معرفة بالقرارات.

الأسئلة المهمة عادة هي:

• لماذا هذه الحالة هنا؟
• لماذا هذه الميزة مقسّمة هنا؟
• لماذا تملك هذه الخدمة هذه العملية؟
• لماذا لا نستخدم المكوّن المشترك؟
• لماذا ما يزال هذا مكرَّرًا؟

يستطيع الوكلاء غالبًا استنتاج هذه الإجابات من الكود، لكن الاستنتاج ليس هو المعرفة.

إذا كان القرار مهمًا، فاكتبه.

ملاحظة القرار يمكن أن تكون صغيرة:

# Decision: Workspace Navigation Owns Route Filtering

Date: 2026-07-08

Workspace navigation owns route filtering because the sidebar,
mobile navigation, and command palette all need the same visibility rules.

Do not duplicate filtering in individual components.

If workspace roles become more complex, extend the navigation model instead
of adding per-component permission checks.

هذه ليست بيروقراطية.

هذه بنية تحتية للتوجيه.

في المرة التالية التي يطلب فيها إنسان من وكيل تغيير التنقّل، يستطيع الإنسان استعادة النية بسرعة والانطلاق منها في موجّهه.

احتفظ بسجل للدَّين

يستطيع الوكلاء الالتفاف حول الدَّين التقني بفعالية كبيرة.

أحيانًا بفعالية زائدة.

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

الدَّين ينبغي أن يكون جزءًا من طبقة التعلّم.

ليس بوصفه عارًا.

بل بوصفه بيانات خريطة.

على سبيل المثال:

# Known Debt: Billing Settings

- Billing provider logic is still partially mixed into the UI layer.
- Subscription status names are provider-shaped, not domain-shaped.
- There are two sources of truth for trial expiration.
- The current migration direction is to introduce BillingAccount as the domain object.

هذا يساعد الإنسان على التوجيه.

الموجّه الضعيف يقول:

Add support for annual plans.

والموجّه الأقوى يقول:

Add support for annual plans, but do not deepen the provider-shaped status model.

Use this as a step toward BillingAccount becoming the domain object.
Avoid adding new subscription status branching inside the UI components.

هذا الموجّه لا يكون ممكنًا إلا إذا كان الإنسان يعرف الدَّين.

الوكيل ينبغي أن يحدّث المعلّم

طبقة التعلّم لا يمكن أن تعتمد على بشر يكتبون وثائق مثالية بعد كل تغيير.

هذا سيفشل.

ينبغي أن يحدّث الوكيل معلّم قاعدة الكود بوصفه جزءًا من حلقة التطوير.

بعد كل تغيير ذي معنى، ينبغي أن ينتج الوكيل فرق معرفة (knowledge diff):

• نظرة عامة محدّثة على الميزة
• مكوّنات متأثرة محدّثة
• ملاحظة قرار جديدة مضافة
• دَين معروف جديد مضاف
• نية قديمة موسومة بأنها مهجورة
• ملفات متغيّرة مربوطة

ينبغي أن يتضمن طلب السحب الكود والشرح معًا.

ليس مقالة عملاقة.

بل تحديثًا صغيرًا منظّمًا للخريطة.

على سبيل المثال:

# Change: Workspace-Scoped Navigation

Changed
- Navigation is now resolved per workspace.
- Sidebar remains presentational.
- Command palette now consumes the same navigation model.

Why
- Users can belong to multiple workspaces.
- Navigation visibility depends on workspace role.

Do not
- Add workspace filtering inside individual nav components.
- Duplicate role checks in the command palette.

Files
- app/workspaces/[workspaceId]/layout.tsx
- components/navigation/sidebar.tsx
- components/navigation/command-palette.tsx
- lib/navigation/workspace-navigation.ts

هذا يجعل عمل الوكيل مقروءًا للإنسان لاحقًا.

كما يجعل كتابة الموجّهات المستقبلية أفضل.

المراجعة تتغيّر

مراجعة الكود تتغيّر أيضًا.

في سير العمل القديم، كانت المراجعة تدور في معظمها حول الفرق (diff).

مع الوكلاء، يجب أن تشمل المراجعة طبقة المعرفة.

في التغييرات ذات المعنى، ينبغي أن يسأل المراجع:

• هل طابق تغيير الكود المعمارية المقصودة؟
• هل أنشأ الوكيل تجريدًا جديدًا أم عمّق تجريدًا قديمًا؟
• هل أُعيدت تسمية أي مفهوم؟
• هل انتقلت ملكية الحالة؟
• هل حُدّثت شجرة التوثيق؟
• هل تغيّر سجل القرارات؟
• هل تغيّر الدَّين المعروف؟
• هل سيعرف إنسان في المستقبل كيف يكتب موجّهات حول هذه المنطقة؟

هذا السؤال الأخير مهم.

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

الأمر لا يتعلق بعدم قراءة أي كود

الهدف ليس التوقف عن قراءة الكود كليًا.

هذا وهم.

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

الهدف مختلف.

اقرأ الكود عندما يكون الكود هو المستوى الصحيح من التفصيل.

لا تُجبر البشر على إعادة اكتشاف المعمارية كلها من الملفات الخام في كل مرة يحتاجون فيها إلى اتخاذ قرار منتج.

الخريطة لا تحل محل الأرض.

لكن بلا خريطة، تبدأ كل رحلة من الصفر.

عقد عملي لمعلّم قاعدة الكود

لكل ميزة مهمة، استهدف مجموعة صغيرة من الوثائق الحيّة.

على مستوى الميزة

اشرح:

• ماذا تفعل الميزة.
• تدفقات المستخدم الرئيسية.
• مفاهيم المجال الأساسية.
• نية المنتج الحالية.
• نقاط الدخول الرئيسية.
• الملفات المهمة.
• الحالات الحدّية المعروفة.

تجنّب:

• تكرار بنية الكود الواضحة.
• سرد كل import.
• كتابة نثر مولَّد لا يقول شيئًا.
• خلط النوايا القديمة بالنوايا الحالية.

على مستوى المكوّن

اشرح:

• ما الذي يملكه المكوّن.
• ما الذي يجب ألا يملكه المكوّن.
• أي الخصائص (props) مفاهيم مجال.
• أي الحالة محلية.
• أي الحالة تأتي من URL أو الخادم أو المزوّد (provider).
• أي المكوّنات الأخرى تعتمد على النموذج نفسه.

تجنّب:

• معاملة كل مكوّن بالتساوي.
• توثيق المكوّنات العرضية (presentational) التافهة.
• وصف JSX سطرًا سطرًا.

على مستوى القرار

اشرح:

• ما القرار الذي اتُّخذ.
• لماذا اتُّخذ.
• أي البدائل رُفضت.
• ما الذي سيجعل القرار غير صالح.
• أين نُفِّذ القرار.

تجنّب:

• تحويل ملاحظات القرارات إلى محاضر اجتماعات.
• الاحتفاظ بقرارات لم تعد صحيحة.
• إخفاء اللايقين.

على مستوى الدَّين

اشرح:

• ما هو الشيء الغريب.
• لماذا يوجد.
• ما الذي لا ينبغي البناء فوقه.
• في أي اتجاه ينبغي أن يتحرك الكود.
• أي تغيير مستقبلي سيسدّده.

تجنّب:

• الشكاوى المبهمة.
• إلقاء اللوم.
• قوائم أمنيات عملاقة لإعادة الهيكلة.
• ملاحظات دَين بلا قيمة توجيهية.

على مستوى التغيير

اشرح:

• ما الذي تغيّر.
• لماذا تغيّر.
• أي النوايا تغيّرت.
• أي الملفات مهمة.
• أي الموجّهات ستكون أفضل في المرة القادمة.
• أي الوثائق حُدّثت.

تجنّب:

• ضوضاء ملخصات الالتزامات (commits).
• شروحات من نوع “تم تحديث الكود”.
• الملخصات المولَّدة المتقادمة.

قائمة تحقق لقواعد كود وكيلية جاهزة للبشر

قبل الاعتماد بكثافة على الوكلاء في قاعدة كود، اسأل:

• هل يستطيع مطوّر فهم النظام على المستوى الأعلى دون قراءة كل ملف؟
• هل يوجد مسرد لمفاهيم المجال؟
• هل يستطيع مطوّر ربط عنصر واجهة مرئي بمكوّنه؟
• هل يستطيع مطوّر إيجاد المكان الذي تُملَك فيه الحالة؟
• هل يستطيع مطوّر رؤية أي التجريدات مقصودة؟
• هل يستطيع مطوّر رؤية أي التجريدات موروثة؟
• هل القرارات المهمة مكتوبة؟
• هل الديون المعروفة مكتوبة كملاحظات توجيه؟
• هل يحدّث الوكيل التوثيق بعد التغييرات ذات المعنى؟
• هل تُراجَع تغييرات التوثيق مع تغييرات الكود؟
• هل يستطيع الإنسان استعادة سياق كافٍ بسرعة لكتابة موجّه جيد؟
• هل يستطيع الإنسان معرفة متى يتحرك الوكيل في الاتجاه الخاطئ؟
• هل طبقة المعرفة منظّمة حسب الميزة والمفهوم والنية؟
• هل التفاصيل منخفضة المستوى متاحة دون تضخيم المستوى الأعلى؟
• هل سيعرف مطوّر جديد ما الذي لا يُلمَس باستخفاف؟
• هل ستفهم نسخة مستقبلية منك لماذا هذا الكود مصاغ على هذا الشكل؟

الهدف ليس تغطية التوثيق.

الهدف هو جودة التوجيه.

المقايضة

البرمجة الوكيلية تخلق مقايضة حقيقية.

إذا قرأت كل سطر، تخلّيت عن كثير من السرعة التي يوفّرها الوكلاء.

وإذا لم تقرأ شيئًا تقريبًا، فقدت ببطء القدرة على التوجيه.

الجواب ليس العودة إلى البرمجة اليدوية.

والجواب ليس الثقة العمياء بالوكيل أيضًا.

الجواب هو طبقة تعلّم لقاعدة الكود:

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

هذا يمنح الإنسان سياقًا كافيًا لتوجيه النظام دون إجباره على إعادة بناء النظام يدويًا من الصفر.

التحوّل

كان تطوير البرمجيات يعلّم المطوّر بجعل المطوّر يكتب الكود.

البرمجة الوكيلية تكسر هذا الوضع الافتراضي.

يمكن الآن كتابة الكود دون أن يتعلّم الإنسان كله.

هذه هي الفرصة.

وهي أيضًا الخطر.

مطوّر المستقبل ليس مجرد كاتب موجّهات. مطوّر المستقبل وصيّ على النوايا. هو من يقرّر ماذا ينبغي أن يصبح النظام، وأي التجريدات ينبغي أن تبقى، وأي الديون ينبغي أن تُسدَّد، وفي أي اتجاه ينبغي أن يتحرك الوكلاء.

لكنك لا تستطيع أن تكون وصيًا على ما لا تفهمه.

تعلّم قاعدة الكود ليس مسرحية توثيق.

إنه الطريقة التي تُبقي بها الإنسان في الحلقة دون إجباره على قراءة كل سطر.

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

وكيلك يمكن أن يمتلك نافذة سياق أكبر.

لكن منتجك ما يزال يعتمد على نافذة الإنسان.