العام الماضي، شحنا منصة بقيمة $2 مليون. فريق الهندسة بالكامل؟ معماري واحد وClauде Code. بلا فريق خارجي. بلا جيش من المقاولين. فقط شخص واحد يعرف ما يريد بناءه، مقترن بذكاء اصطناعي يستطيع فعلاً كتابة كود الإنتاج.

لا أكتب هذا لتضخيم الذكاء الاصطناعي. لقد أحترقت من دورة الضجيج عدة مرات. أكتب هذا لأن ما حدث في هذا المشروع غيّر بشكل أساسي كيف أفكر في تكوين الفريق وتقدير المشروع وما هو ممكن فعلاً عند دمج المعرفة المعمارية العميقة مع التطوير بمساعدة الذكاء الاصطناعي. الأرقام لا تكذب — حققنا نقاط محطات كنت ستستغرق فريق تقليدي من 6-8 مهندسين حوالي 18 شهرًا، وقمنا بذلك في أقل من 5 أشهر.

دعني أشرح لك بالضبط كيف.

جدول المحتويات

المشروع: ما الذي كنا نبنيه فعلاً

لا أستطيع تسمية العميل — منطقة العقد السري — لكن يمكنني وصف المنصة. إنها منتج SaaS موجه للشركات في قطاع الخدمات اللوجستية. هندسة معمارية متعددة المستأجرين. لوحات تتبع فوري. التحكم بالوصول القائم على الأدوار المعقد الذي يمتد عبر المنظمات والفرق والمستخدمين الفرديين. التكامل مع 14 واجهة برمجية للجهات الخارجية (شركات الشحن، معالجات الدفع، قواعد بيانات الجمارك). بوابة موجهة للعملاء ونظام إدارة داخلي.

نوع المشروع الذي في إعداد وكالة نموذجي، ستقوم به فريق يضم قائد تقني و2-3 مطورين أقدمين وعدد من المستويات الوسيطة وشخص DevOps مخصص وربما مهندس QA. كان التقدير الأصلي للعميل من وكالة أخرى هو $3.2M على 20 شهرًا مع فريق من 9 أشخاص.

اقترحنا $2M و5 أشهر ومعماري واحد. اعتقدوا أننا مجانين. بصراحة؟ أنا أيضًا، قليلاً.

لماذا معماري واحد بدلاً من فريق كامل

إليك الشيء المضاد للحدس حول الفرق الصغيرة: التكلفة العلائقية على مشروع من 9 أشخاص ضخمة جداً. كتب Fred Brooks عن هذا في 1975 وما زال صحيحاً. مع 9 مهندسين، لديك 36 قناة اتصال محتملة. الاجتماعات تتضاعف. تضاربات الدمج تصبح طقس يومي. شخص ما دائماً عالق ينتظر مراجعة طلب سحب من شخص آخر.

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

لكن شخص واحد يستطيع فقط الكتابة بسرعة معينة. يستطيع شخص واحد فقط الاحتفاظ بالعديد من الملفات في الذاكرة العاملة. يتعب شخص واحد في الساعة 6 مساءً ويرتكب أخطاء بحلول الساعة 8 مساءً.

هنا يأتي دور Claude Code. ليس كبديل للمعماري، بل كمضاعف قوة. المعماري يتخذ كل قرار. Claude Code ينفذ بسرعة ستتطلب 4-5 مطورين بخلاف ذلك.

دور المعماري

معماري الحالة لدينا — دعنا نناديه Marcus — لديه 15 سنة من الخبرة. لقد بنى أنظمة بهذا الحجم من قبل. وظيفته في هذا المشروع كانت:

  • قرارات تصميم النظام والهندسة المعمارية
  • تحديد حدود الوحدة ومعاقد البيانات
  • كتابة كود المسار الحرج (المصادقة، معالجة الدفع، تنسيق خط أنابيب البيانات)
  • مراجعة وصقل كل شيء أنتجه Claude Code
  • هندسة البنية التحتية والنشر
  • المراجعات الأمنية

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

كيف يندمج Claude Code فعلاً في سير عمل حقيقي

دعني أكون محددًا بشأن ما معنى "استخدام Claude Code" فعلاً على أساس يومي، لأن المواد التسويقية لا تلتقط الواقع.

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

  1. مسؤولية الوحدة والحدود
  2. نماذج البيانات مع أنواع الحقول الدقيقة والعلاقات
  3. معاقد الواجهة البرمجية (نقاط النهاية، أشكال الطلب/الاستجابة)
  4. قواعد العمل وحالات الحافة
  5. توقعات معالجة الأخطاء
  6. وحدات موجودة التي تحتاج إلى التكامل معها

ثم يطعمها إلى Claude Code في أجزاء. بدت جلسة نموذجية مثل هذا:

# كان Marcus يعمل في دليل المشروع مع Claude Code CLI
# أولاً، وضع السياق
claude "قراءة /src/modules/shipment/ و /src/lib/database/schema.ts.
أحتاج إليك لفهم الأنماط الموجودة قبل أن نبني وحدة الفواتير."

# ثم، تعليمات البناء الفعلية مع الملخص المعماري
claude "بناء وحدة الفواتير باتباع الملخص المعماري في
/docs/briefs/invoicing.md. اتبع الأنماط نفسها تماماً مثل وحدة الشحنات
لطبقة الخدمة وطبقة المستودع ومعالجات المسارات. استخدم مجموعة
معالجة الأخطاء الموجودة. اكتب اختبارات لكل منطق العمل
في طبقة الخدمة."

ثم ينتج Claude Code الوحدة — عادة ما يكون 15-30 ملف بما في ذلك الأنواع والمخططات والخدمات والمستودعات ومعالجات الطرق والوسيط والاختبارات. كان Marcus سيراجع الإخراج ويصحح الأخطاء ويكرر. استغرقت الدورة بالكاملة لوحدة متوسطة التعقيد حوالي 2-3 ساعات بدلاً من 2-3 أيام التي ستستغرقها مطور أقدم.

حلقة التكرار

إليك ما لا يخبرك به أحد عن التطوير بمساعدة الذكاء الاصطناعي: الإخراج الأول نادراً ما يكون جاهزاً للإنتاج. إنه ربما 70-80% في المكان. لكن ذلك الـ 20-30% المتبقي هو حيث تأتي خبرة المعماري.

طور Marcus إيقاعاً:

  1. توليد — ينتج Claude Code التنفيذ الأولي
  2. مراجعة — يقرأ Marcus كل ملف، ويحدد المشاكل
  3. تحسين — تصحيحات محددة مرجعية إلى Claude Code
  4. تعزيز — يتعامل Marcus يدويًا مع الأقسام الحرجة أمنياً
  5. اختبار — قم بتشغيل الاختبارات المولدة وأضف حالات حافة التي فاتت Claude

عادة ما مرت هذه الحلقة عبر 2-3 دورات لكل وحدة. بحلول الشهر الثالث من المشروع، كان Claude Code ينتج كود المسار الأول الذي كان أقرب إلى 85-90% جاهز للإنتاج، لأن قاعدة الكود كان لديها أنماط كافية لاتباعها.

المكدس التقني وقرارات الهندسة المعمارية

اخترنا المكدس بعناية لتعظيم إنتاجية التطوير بمساعدة الذكاء الاصطناعي:

  • Next.js 14 (App Router) — لبوابة العملاء ولوحة التحكم الإدارية
  • Node.js مع Fastify — لطبقة الواجهة البرمجية (منفصلة عن Next.js)
  • PostgreSQL — قاعدة البيانات الأساسية
  • Redis — التخزين المؤقت وإدارة الجلسات والنشر/الاشتراك في الوقت الفعلي
  • Drizzle ORM — الوصول الآمن إلى قاعدة البيانات من حيث النوع
  • Turborepo — إدارة monorepo
  • Vercel — نشر الواجهة الأمامية
  • AWS (ECS Fargate) — طبقة الواجهة البرمجية والعمليات الخلفية

اخترنا Next.js على وجه التحديد لأن الأنماط راسخة جيداً وClauDE Code لديه بيانات تدريب عميقة على اتفاقيات App Router. هذا يهم أكثر مما يعتقد الناس. لو اخترنا شيئاً غريباً مثل backend مستند إلى Rust مع HTMX، لكان جودة إخراج الذكاء الاصطناعي انخفضت بشكل كبير. يمكنك معرفة المزيد حول كيف نقترب من تطوير Next.js على نطاق واسع.

كان Drizzle ORM خياراً متعمداً على Prisma لهذا المشروع. ينتج Claude Code مخططات Drizzle أفضل لأنها مجرد TypeScript — لا لغة DSL مخصصة للخطأ فيها. بالإضافة إلى ذلك، قصة الترحيل أبسط عندما تولد الكثير من تغييرات المخطط بسرعة.

// مثال: أنتج Claude Code هذا مخطط الفاتورة
// في المسار الأول مع الحد الأدنى من التصحيحات المطلوبة
import { pgTable, uuid, varchar, decimal, timestamp, pgEnum } from 'drizzle-orm/pg-core';
import { relations } from 'drizzle-orm';
import { shipments } from './shipments';
import { organizations } from './organizations';

export const invoiceStatusEnum = pgEnum('invoice_status', [
  'draft', 'pending', 'sent', 'paid', 'overdue', 'cancelled', 'refunded'
]);

export const invoices = pgTable('invoices', {
  id: uuid('id').primaryKey().defaultRandom(),
  organizationId: uuid('organization_id').notNull().references(() => organizations.id),
  shipmentId: uuid('shipment_id').references(() => shipments.id),
  invoiceNumber: varchar('invoice_number', { length: 50 }).notNull().unique(),
  status: invoiceStatusEnum('status').notNull().default('draft'),
  subtotal: decimal('subtotal', { precision: 12, scale: 2 }).notNull(),
  taxAmount: decimal('tax_amount', { precision: 12, scale: 2 }).notNull().default('0'),
  totalAmount: decimal('total_amount', { precision: 12, scale: 2 }).notNull(),
  currency: varchar('currency', { length: 3 }).notNull().default('USD'),
  dueDate: timestamp('due_date', { withTimezone: true }).notNull(),
  paidAt: timestamp('paid_at', { withTimezone: true }),
  createdAt: timestamp('created_at', { withTimezone: true }).notNull().defaultNow(),
  updatedAt: timestamp('updated_at', { withTimezone: true }).notNull().defaultNow(),
});

export const invoiceRelations = relations(invoices, ({ one, many }) => ({
  organization: one(organizations, {
    fields: [invoices.organizationId],
    references: [organizations.id],
  }),
  shipment: one(shipments, {
    fields: [invoices.shipmentId],
    references: [shipments.id],
  }),
  lineItems: many(invoiceLineItems),
}));

ما الذي أداه Claude Code بشكل جيد

دعنا نكون محددين. إليك حيث سرّع Claude Code التطوير فعلاً:

الاستنسل وعمليات CRUD

هذا هو الواضح. توليد نقاط نهاية REST ومخططات التحقق من الطلب (استخدمنا Zod) ومسلسلات الاستجابة وطرق الخدمة الأساسية — قام Claude Code بإخراجها في دقائق. عبر المشروع، نقدر أن كانت هناك تقريباً 180 نقطة نهاية API. ربما 140 منها كانت عمليات CRUD القياسية أو عمليات الاستعلام التي أنتجها Claude Code مع الحد الأدنى من المراجعة.

توليد الاختبار

كتب Claude Code تقريباً 2400 اختبار عبر المشروع. هل كانت جميعها مثالية؟ رقم. حوالي 15% احتاجت إلى إعادة عمل كبيرة. لكن وجود 85% من مجموعة الاختبار الخاصة بك مولدة وعاملة هو توفير وقت ضخم. ركز Marcus طاقة الاختبار على الاختبارات المتكاملة وحالات الحافة المحتوية التي لم يستطع Claude Code توقعها.

تطوير مكون الواجهة الرسومية

كانت بوابة العملاء تحتوي على حوالي 60 عرض صفحة فريد. لكل واحد، قدم Marcus مرجع تصميم Figma ومعاقد الواجهة البرمجية، وأنتج Claude Code مكونات React والخطافات لجلب البيانات (استخدمنا TanStack Query) ومعالجة النماذج مع React Hook Form + Zod وحالات التحميل/الخطأ. كان الإخراج متسقاً جيداً — ربما 75% دقيق بكسل على الجيل الأول.

ترحيلات قاعدة البيانات وتطور المخطط

عند تطور المتطلبات (وهم يفعلون دائماً)، عالج Claude Code ترحيلات المخطط بسلاسة. وصف التغيير الذي تحتاجه وينتج ملف الترحيل وتحديث المخطط وتحديث الاستعلامات المتأثرة وتعديل أنواع TypeScript. ما كان سيكون جلسة إعادة تصميم حذرة مدتها 45 دقيقة أصبح دورة مراجعة والموافقة لمدة 10 دقائق.

توثيق

أنتج Claude Code توثيق الواجهة البرمجية والتعليقات في الكود والملفات التمهيدية والوثائق حتى لمجموعات العمليات. كان Marcus سيراجع ويضبط، لكن إخراج الأساس كان مفيداً بصدق. انتهى بنا الحال مع توثيق أفضل من 90% من المشاريع التي رأيتها، ببساطة لأن تكلفة توليده كانت منخفضة جداً.

حيث فشل Claude Code وما فعلناه حيال ذلك

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

منطق العمل المعقد مع تبعيات متعددة

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

كتب Marcus هذه الوحدة باليد. استغرق حوالي أسبوعين. هذا بالضبط نوع العمل الذي يبرر وجود معماري أقدم بدلاً من محاولة الذكاء الاصطناعي طريقك من خلال كل شيء.

الكود حرج أمنياً

لم نثق بـ Claude Code مع تدفقات المصادقة أو معالجة الدفع أو التشفير بدون مراجعة سطر تلو سطر. والحمد لله — كانت تولد أحياناً التحقق من JWT الذي كان صحيحاً من الناحية الفنية لكن فاتت حالات حافة مثل انحراف ساعة انتهاء الرمز، أو لم تعقّم الإدخالات بشكل صحيح قبل استعلامات قاعدة البيانات على الرغم من استخدام ORM.

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

الاتساق المعماري طويل المدى

بحلول الشهر الثالث، كانت قاعدة الكود كبيرة بما يكفي بحيث أن Claude Code قد ينسى أحياناً الأنماط المنشأة مسبقاً، حتى مع توفير السياق. قد تستخدم نهج معالجة خطأ مختلفة في وحدة واحدة مقابل أخرى. كان على Marcus أن يكون يقظاً بشأن التقاط هذه التناقضات.

خففنا هذا بالحفاظ على وثيقة "الاتفاقيات" الحية التي تم تضمينها في كل جلسة Claude Code. فكر فيها كدليل نمط، ولكن للأنماط المعمارية.

تحسين الأداء

ينتج Claude Code كود يعمل لكنه لا ينتج دائماً كود سريع. استعلامات قاعدة البيانات التي تقوم بجلب N+1. مكونات React التي تعاد رسمها بشكل غير ضروري. نقاط نهاية API التي تحمل أكثر من البيانات المطلوبة.

قضى Marcus حوالي 20% من وقت المراجعة على تحسين الأداء. ليس أمراً محبطاً، لكنه شيء يجب الميزانية له.

الاقتصاديات: تفصيل التكاليف والعائد على الاستثمار

إليك الجزء الذي يريد الجميع رؤيته. أرقام حقيقية.

فئة التكلفة فريق تقليدي (تقدير) التسريع بالذكاء الاصطناعي (الفعلية)
رواتب الهندسة (18 شهر / 5 أشهر) $1,890,000 $175,000
Claude Code API / الاشتراك $0 $12,400
البنية التحتية (dev/staging) $48,000 $8,200
إدارة المشروع $216,000 $0*
QA / الاختبار $180,000 $22,000**
التصميم (متعاقد) $120,000 $95,000
DevOps / إعداد البنية التحتية $96,000 $35,000
الإجمالي $2,550,000 $347,600

أدار Marcus نفسه باستخدام Linear لتتبع المهام. لا PM overhead.

*عاقد متخصص QA للـ 6 أسابيع الأخيرة.

تنقسم تكاليف Claude Code إلى حوالي $2500/شهر. هذا هو الخطة القصوى ($100/شهر للاشتراك) بالإضافة إلى تكاليف API للجلسات الممتدة. بعض الأيام كان Marcus سيحترق 150-200 دولار في استدعاءات API أثناء جلسات الإنشاء الثقيل. معظم الأيام كانت 40-80 دولار.

تم فواتير المشروع بـ $2 مليون. كانت تكلفة التسليم الإجمالية أقل من $350 ألف. سأترك لك أن تفعل حساب الهامش.

مقارنة السرعة

محطة الجدول الزمني التقليدي جدول زمني مُسرّع بالذكاء الاصطناعي
الهندسة المعمارية والتصميم 6 أسابيع 3 أسابيع
النظام الأساسي الأساسي (المصادقة والوحدة المتعددة والواجهة البرمجية الأساسية) 10 أسابيع 3 أسابيع
تطوير الميزات (جميع الوحدات) 32 أسبوعاً 10 أسابيع
التكاملات (14 واجهة برمجية تابعة) 12 أسبوعاً 4 أسابيع
الاختبار والتأكد من الجودة 8 أسابيع 3 أسابيع
النشر والتعزيز 4 أسابيع أسبوعين
الإجمالي 72 أسبوعاً 25 أسبوعاً

دروس للفرق التي تفكر في التطوير المُسرّع بالذكاء الاصطناعي

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

لا تزال بحاجة إلى معماري أقدم. ربما أكثر من أي وقت مضى.

الذكاء الاصطناعي لا يلغي الحاجة للخبرة — إنه يضاعف أيًا من الخبرة (أو نقصها) التي تأتي به. مطور مبتدئ يستخدم Claude Code سيشحن كود جودة مبتدئ أسرع. معماري أقدم يستخدم Claude Code سيشحن كود جودة أقدم بسرعة لم تكن ممكنة من قبل.

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

اتفاقية على التكوين في كل مكان

كلما كانت الأنماط قابلة للتنبؤ في قاعدة الكود الخاصة بك، كلما أداء الذكاء الاصطناعي بشكل أفضل. استخدمنا بنية الملف ذاتها واتفاقيات التسمية وتنظيم الكود في كل وحدة. دفع هذا التناسق توزيعات ضخمة حيث تعلم Claude Code لمطابقة الأنماط الموجودة.

إذا كنت تعمل مع هندسة معمارية headless CMS، فإن وجود اتفاقيات صارمة لأنواع المحتوى ومسارات API وهياكل المكونات يجعل كود الذكاء الاصطناعي المولد موثوق به بشكل كبير.

الاستثمار في الملخصات المعمارية

ترتبط جودة إخراج Claude Code بشكل مباشر بجودة الملخصات المعمارية لـ Marcus. التعليمات الغامضة أنتجت كود غامض. الملخصات المفصلة مع نماذج البيانات الصريحة وقواعد العمل ومتطلبات التكامل أنتجت كود قريب من الإنتاج.

نقدر أن Marcus قضى حوالي 30% من وقته في كتابة ملخصات معمارية ومراجعة الإخراج، و70% من الوقت الذي كان فريق تقليدي قد أنفقه على التنفيذ الفعلي تم التعامل معه بواسطة Claude Code.

التطوير المُسرّع بالذكاء الاصطناعي يغير نماذج التسعير

إذا كنت وكالة، هذه هي محادثة غير مريحة. عندما يستطيع معماري واحد تسليم ما كان سيتطلب فريق 8، كيف تسعر؟ نحن نؤمن بالتسعير القائم على القيمة — يدفع العميل للنتيجة، وليس للساعات. المنصة تستحق $2 مليون بصرف النظر عما إذا كان الأمر استغرق شخص واحد أو 10 لبنائها.

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

ليس كل مشروع يناسب هذا النموذج

عمل هذا لأن:

  • كانت المتطلبات محددة بوضوح (اللوجستيات مجال ناضج)
  • كان لدينا معماري أقدم متاح فعلاً
  • كان المكدس التقني سائداً (بيانات تدريب ذكاء اصطناعي رائعة)
  • ثقة العميل بنا لتسليم بدون مراقبة دقيقة لحجم الفريق

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

للمشاريع المبنية بأطر مثل Astro حيث النظام البيئي أحدث وبيانات تدريب الذكاء الاصطناعي أرق، سترى تسريع أقل من أدوات الذكاء الاصطناعي مقارنة بمشاريع React/Next.js.

أسئلة شائعة

كم يكلف Claude Code فعلاً شهرياً للاستخدام الثقيل في التطوير؟

في هذا المشروع، تعاملنا مع متوسط $2500/شهر كلياً. اشتراك Claude Max هو $100/شهر (أو $200/شهر للمستوى الأعلى في أوائل 2025)، وتكاليف API لجلسات Claude Code الموكلة تتراكم اعتماداً على مقدار الكود الذي تولده. الأيام الثقيلة وصلت إلى 150-200 دولار في تكاليف API. أيام مراجعة وتحسين خفيفة كانت 40-80 دولار. قدمت Anthropic أيضاً خطة Max بـ $200/شهر التي تتضمن استخدام كبير يمكن أن يقلل التكاليف المتغيرة.

هل يستطيع مطور مبتدئ استخدام Claude Code بنفس الطريقة؟

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

ماذا عن جودة الكود — هل كود الذكاء الاصطناعي المولد قابل للصيانة؟

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

هل هذا النهج يعمل للمشاريع الثقيلة على الواجهة الأمامية؟

نعم مع تحفظات. Claude Code ممتاز في توليد مكونات React ومعالجة النماذج وخطافات جلب البيانات وكود إدارة الحالة. إنه أقل موثوقية في إنتاج تخطيطات CSS دقيقة بكسل من التصاميم — ستحتاج إلى دورات تكرار أكثر للصقل البصري. وجدنا أنها كانت حوالي 75% دقيقة على جيل أول لـ UI مقارنة بـ 85-90% للكود الخلفي.

كيف تتعامل مع مراجعة الكود عندما يكون هناك مطور واحد فقط؟

راجع Marcus كل سطر من كود الذكاء الاصطناعي المولد نفسه. أحضرنا أيضاً متخصص أمان متعاقد لجلستي تدقيق موجهتين أثناء المشروع (الأسبوع 12 و22). في المرحلة النهائية، انضم متخصص QA لمدة ستة أسابيع. نقص مراجعة الكود من النظير هو خطر حقيقي — خففناه باستخدام أداة مؤتمتة (وضع TypeScript الصارم وESLint مع القواعد العدوانية وVitest مع عتبات التغطية) والتدقيق الخارجي.

ماذا يحدث عندما يولد Claude Code كود معيب؟

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

هل هذا يعمل فقط للمشاريع greenfield أم يعمل مع قواعد البيانات الموجودة؟

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

هل تفعل هذا مرة أخرى؟

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