لا تقرأ كود AI كأنك linter بشري: اكتب بوابة القبول أولاً

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

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

السير العملي يبدأ بأمر عمل قابل للتحقق: الهدف، النطاق، ما لا يجب تغييره، معايير القبول، الحالات السلبية، أوامر الاختبار، قواعد الخصوصية، وشروط توقف الوكيل وطلب مساعدة بشرية. “أضف JWT login” طلب غامض. “أبق خدمة hashing الحالية، ارفض المستخدمين المعطلين، دوّر refresh tokens، اختبر replay وrate limit وسجّل audit events” عقد قابل للفحص.

وثائق Claude Code من Anthropic، ووثائق GitHub Copilot coding agent، وإرشادات OpenAI حول Codex وprompting تشير إلى الدرس نفسه: سياق مشروع واضح، تعليمات repository، نطاق محدود، سجلات، اختبارات وموافقة بشرية. الأداة لا تصبح عملية هندسية وحدها؛ هي تعمل داخل عملية.

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

الاختبارات الآلية هي ذاكرة المحادثة. النموذج قد ينسى تعليمة في جلسة طويلة، أما الاختبار الفاشل فلا يجامل. Unit tests، اختبارات التكامل، type checks، lint، فحص أمني وقائمة مراجعة منتج قصيرة تعطي أساساً أقوى من الانطباع بأن diff نظيف.

يجب إدخال الخصوصية والكلفة وvendor lock-in في العقد. قد يرى المساعد سياق المستودع أو logs أو أمثلة حساسة. يجب فهم retention، التدريب على البيانات، حدود الصلاحيات، والحاجة إلى أدوات محلية عند وجود بيانات حساسة. كما يجب أن تبقى الاختبارات والتذاكر قابلة للتكرار خارج نافذة الدردشة.

هذه الطريقة مناسبة للفرق التي تعطي Copilot أو Claude Code أو Codex أو وكلاء مشابهين تغييرات حقيقية: authentication، billing، APIs، automation داخلية وmigrations. أما الفرق بلا tests أو staging أو rollback فيجب أن تبدأ ببناء هذه الحواجز قبل تفويض مهام كبيرة.

التحول في الهوية غير مريح لكنه صحي. المطور لا يصبح linter بشرياً للآلة. يصبح مصمم القيود التي تجعل النظام يثبت صحة التغيير. AI يجعل كتابة الأسطر أرخص؛ لذلك يجعل الوضوح والاختبار أغلى قيمة.

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

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

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

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