الذكاء الاصطناعي يبرمج كعبقري. ويصمم المعماريات كسمكة ذهبية.

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

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

البنية

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

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

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

# Example: What a strong, constrained knowledge base looks like
/antigravity-base
├── apps
│   ├── web        (Astro 4 + Tailwind v4)
│   └── studio     (Sanity CMS)
├── packages
│   ├── ui         (Strict design tokens - AI CANNOT hallucinate)
│   ├── config     (Shared ESLint/TS - strict boundaries)
│   └── core       (Business logic boundaries)
├── knowledge      (Deep context and architectural decisions)
│   └── routing-rules.md
└── turbo.json     (Build constraints)

البناء

عندما بنيت gekro.com لم أبدأ بموجّه فارغ وأمل ساذج في النجاح من المحاولة الأولى. بدأت ببنية معمارية صارمة. وعلى مر الوقت بنيت قوالب “Antigravity” الخاصة بي، وهي قابلة لإعادة الاستخدام بدرجة كبيرة وتساعدني على تقييد الذكاء الاصطناعي بصرامة لإطلاق أي مشروع معقد بسرعة كبيرة. ينبغي أن تكون نقطة انطلاق كل مشروع جاد أساسًا عميق الجذور مبنيًا على رؤيتك الحالية والبعيدة. على المطورين أن يبدؤوا بصياغة قوالب لقواعد معارفهم الخاصة لفرض القيود.

# Initializing the environment from the core template
# Replace with your own base template repo
git clone https://github.com/your-org/your-base my-new-project
cd my-new-project
pnpm install

# Enforcing strict boundaries before AI touches anything
pnpm turbo run typecheck lint

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

// Conceptual representation - actual rules live in your workspace system prompt / .cursorrules
// packages/config/base-agent-rules.ts
export const AgentConstraints = {
  allowAny: false,
  styling: "Tailwind v4 utility classes exclusively",
  state: "No local state for global data - use centralized store",
  components: "Astro islands for interactivity only",
  imports: "Use alias @repo/ui, never relative paths",
  knowledge: "Always refer to /knowledge/routing-rules.md before creating new endpoints"
} as const;

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

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

إن ضرر تجاهل هذا الانضباط ملموس بشدة. هذا هو الفرق الدقيق بين مكوّن مُهلوَس وآخر مقيَّد:

// What AI hallucinates without constraints:
import { Button } from '../../components/ui/Button'  
import { Card } from '../../../shared/Card'
import { theme } from './localTheme'  // invented, doesn't exist

// What AI generates with a constrained template:
import { Button, Card } from '@repo/ui'
import { tokens } from '@repo/config/tokens'

ذلك الفرق الواحد ينقل الحجة كلها دون كلمة شرح.

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

مثلًا، إن رسم خريطة صريحة للمواضع التي يجب أن يوجّه إليها الوكيل المنطق يضمن الامتثال المعماري:

# Agent Prompt: Organization Enforcement
"Generate the new 'Analytics' feature. Follow the established file organization:
- Place all UI components strictly in `packages/ui/src/analytics/`
- Place all business state logic in `packages/core/stores/analytics.ts`
- Do NOT generate local component state. Review the `/knowledge/routing-rules.md` file first and automatically enforce these routing rules."

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

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

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

# Agent Prompt: Test Suite Mandate
"Whenever you create or modify a component, you MUST simultaneously generate/update the exact corresponding `vitest` suite in the `packages/core/tests/` directory to cover the failure cases. Do not ask for permission, just include the test in the PR."

المفاضلات

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

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

إلى أين يتجه هذا

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

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