قبل عدة سنوات، كانت فكرة مراجعة 15 مشروعًا برمجيًا بجدية في الوقت نفسه تبدو لي غير واقعية. لا أقصد فتح 15 repository وإلقاء نظرة سريعة عليها، بل مراجعة مشاريع حقيقية بشكل متكرر بحثًا عن الأخطاء والافتراضات الضعيفة ومشكلات SEO وأخطاء الترجمة وعدم اتساق التوطين والاختبارات الناقصة والـregressions والكود القديم الذي لم يعد منسجمًا مع بقية النظام.
عنق الزجاجة لم يكن سرعة الكتابة يومًا. كان الانتباه. لكل مشروع تاريخه واتفاقياته وedge cases وأجزاء من الكود قد تبدو خاطئة لكنها موجودة عمدًا. المراجعة الجيدة تحتاج إلى قراءة وبحث ومقارنة وتشغيل checks، وبعد ذلك فقط يأتي القرار حول ما يجب تغييره فعلاً.
Codex غيّر بالنسبة لي تكلفة هذا العمل المتكرر. يمكنه تنفيذ first pass على repository، وتتبع المراجع، وفحص الملفات المرتبطة، وإظهار patterns مشبوهة، واقتراح اختبارات، ومساعدتي في التحقيق في مناطق كنت سأفتحها يدويًا ملفًا بعد ملف. هذا لا يجعل القرار النهائي آليًا، لكنه يجعل الجزء المكلف الذي يسبق القرار أسرع بكثير.
أهم قاعدة تعلمتها بسيطة: لا أستخدم Codex لإخراج نفسي من review loop، بل لتوسيع نطاق تلك الحلقة.
عنق الزجاجة الحقيقي هو التكرار، لا كتابة الكود
عندما تحافظ على مشروع واحد يمكنك الاحتفاظ بكمية كبيرة من السياق في ذهنك. مع عدة مشاريع، يتوقف ذلك عن التوسع. نفس أنواع العمل تظهر باستمرار:
- البحث عن bugs متشابهة في components مختلفة؛
- التحقق من أن refactor لم يترك call site قديمًا؛
- مراجعة الاختبارات بعد تغيّر السلوك؛
- العثور على عدم اتساق في metadata أو منطق اللغات أو headings أو الروابط الداخلية؛
- مقارنة localization keys والمحتوى المترجم؛
- البحث عن error handling مفقود وedge cases؛
- التحقق مما إذا كان تغيير “صغير” قد لمس ملفات أكثر من المتوقع؛
- قراءة diffs بسيطة منفردة لكنها تستهلك وقتًا كبيرًا مجتمعة.
لا شيء من هذا مثير. لكنه كله مهم. وعندما يتكرر النوع نفسه من المراجعة عبر عدة codebases تصبح التكلفة كبيرة جدًا.
هنا يكون AI coding agent أكثر فائدة بالنسبة لي. فهو يستهلك الجزء المتكرر من مساحة البحث، ويترك لي مزيدًا من الانتباه للحكم.
أبدأ بالفحص، لا بإعطاء الإذن لإعادة كتابة كل شيء
من أسهل الطرق للحصول على نتيجة سيئة أن تقول للوكيل: “راجع المشروع كله وأصلح كل شيء”. تبدو العبارة فعالة، لكنها تجمع discovery وتحديد الأولويات والهندسة والتنفيذ والتحقق في مهمة واحدة غير منضبطة.
أحصل على نتائج أفضل بكثير عندما أفصل المراحل.
inspect → explain findings → prioritize → change → validate → review diffأريد أولاً من الوكيل أن يفهم المنطقة المعنية ويشرح ما وجده. أريد مسارات ملفات محددة، والكود المتأثر، وسبب اعتبار شيء ما مشبوهًا، والتأثير المحتمل. التعديلات تأتي بعد ذلك.
هذا مهم لأن AI يمكن أن يكون واثقًا جدًا وهو مخطئ. كود يبدو زائدًا قد يكون موجودًا لدعم متصفح قديم أو payment edge case أو مسار migration أو business rule لا يظهر من ملف واحد. مرحلة الفحص تعطيني فرصة لإيقاف افتراض سيئ قبل أن يتحول إلى diff ضخم.
أتعامل مع findings كخيوط، لا كأحكام
مراجعة جيدة من Codex لا تنتهي بعبارة “وجدت 17 مشكلة”. الرقم وحده لا يعني الكثير. ما يهمني هو الدليل.
لكي يكون finding قابلاً للتنفيذ فعلاً، أريد معرفة:
- أين المشكلة؛
- لماذا هي مشكلة؛
- أي سلوك يمكن أن يفشل؛
- ما مستوى الثقة المناسب في النتيجة؛
- أي check يمكن أن يثبتها أو ينفيها؛
- ما أصغر fix آمن.
هذا مهم خصوصًا في security وSEO وbusiness logic. قد يشير الوكيل إلى شيء يستحق التحقيق، لكن شرحًا يبدو أمنيًا لا يعني تلقائيًا وجود vulnerability مؤكدة. تحذير SEO ليس بالضرورة مشكلة ranking. شرط غريب ليس تلقائيًا dead code.
AI يقلل تكلفة العثور على المرشحين. التحقق هو الذي يحدد ما هو حقيقي.
Validation loop هو ما يجعل الـworkflow موثوقًا
توليد الكود هو الجزء الأكثر وضوحًا من AI-assisted development، لكن التحقق هو ما يجعله مناسبًا للإنتاج.
بعد التغيير، أريد من codebase أن يرد بالأدلة. حسب المشروع، قد يشمل ذلك:
- TypeScript أو compiler/type checker آخر؛
- lint؛
- unit وintegration tests؛
- build checks؛
- بحثًا موجّهًا عن أسماء أو call sites قديمة؛
- مراجعة يدوية للـdiff النهائي؛
- تحققًا يدويًا من السلوك الظاهر للمستخدم.
الأوامر نفسها أقل أهمية من الحلقة. الوكيل يضع افتراضًا، repository يعيد evidence، والقرار التالي يُبنى على هذا الدليل.
لهذا أحب المشاريع ذات الأنواع الصارمة عند العمل مع AI. كتبت بشكل منفصل عن سبب عمل TypeScript بشكل جيد جدًا مع Codex في تطوير البرمجيات الحقيقي: الأنواع تحوّل كثيرًا من الافتراضات الخاطئة إلى feedback فوري قابل للقراءة آليًا.
بعض أنواع المراجعة مناسبة جدًا للذكاء الاصطناعي
الأخطاء والـregressions
يمكن للوكيل تتبع قيمة عبر عدة ملفات، وفحص callers، ومقارنة implementations متشابهة، والبحث عن branches غير متسقة. هذا مفيد لتضييق مصدر المشكلة. لكنني ما زلت أعيد إنتاج السلوك أو أتحقق منه بطريقة أخرى قبل قبول النتيجة.
الاختبارات
AI مفيد لاكتشاف سلوك تغيّر من دون test coverage مناسب، واقتراح edge cases، وشرح ما الذي يحميه test موجود فعلاً. كما يمكنه إظهار الاختبارات التي تتحقق من تفاصيل التنفيذ بدل السلوك الحقيقي.
SEO
Technical SEO يحتوي على الكثير من عمل الاتساق: metadata، بدائل اللغات، indexability، الروابط الداخلية، templates، sitemap generation، redirects، وقواعد الصفحات. يستطيع الوكيل مقارنة هذه القواعد عبر codebase كبيرة أسرع من فتح كل route يدويًا. لكنني أفصل دائمًا الصحة التقنية عن السؤال الأصعب: هل المحتوى نفسه يستحق أن يتصدر؟
التوطين والترجمات
هذه من أكثر المناطق تكرارًا في المنتج متعدد اللغات. يستطيع AI مقارنة keys، والعثور على قيم مفقودة، واكتشاف خلط لغات واضح، والتحقق من placeholders، وإبراز المكان الذي انحرف فيه locale هيكليًا. أسرع كثيرًا من قراءة translation objects كبيرة يدويًا، رغم أن النص المهم ما زال يحتاج حكمًا بشريًا.
الاتساق بعد refactoring
الـrefactors الكبيرة تفشل غالبًا بأسباب مملة: import قديم بقي، route واحدة ما زالت تستخدم اسم field القديم، test fixture واحدة بقيت على shape قديمة. البحث عبر repository مع وكيل يفهم هدف التغيير مفيد جدًا هنا.
العمل المتوازي يفيد فقط عندما تكون المهام مستقلة
من المغري تشغيل العديد من الوكلاء والسماح لهم بتغيير كل شيء في الوقت نفسه. قد يزيد throughput، لكنه قد يضاعف conflicts والافتراضات المتعارضة أيضًا.
أتعامل مع parallelism كمشكلة تنسيق. الـaudits المستقلة مرشحة جيدة: يمكن فحص localization في مشروع بينما تتم مراجعة tests في مشروع آخر، أو فحص repositories منفصلة في وقت واحد. وكيلان يعيدان كتابة architecture نفسها دون خطة مشتركة أمر مختلف.
كلما زاد العمل المتوازي، أصبحت الحدود أهم: project واضح، task واضحة، definition of done واضحة، ونتيجة يمكن مراجعتها بشكل مستقل.
الهدف ليس زيادة عدد الوكلاء العاملين. الهدف هو زيادة التقدم المفيد والقابل للتحقق.
ما لا أفوضه بشكل أعمى
- قرارات architecture: النموذج يمكن أن يقترح خيارات، لكن trade-offs طويلة الأجل قد تعتمد على سياق خارج repository.
- استنتاجات security: findings تحتاج تحققًا وthreat context وغالبًا أدوات متخصصة.
- Business rules: قد يكون الكود متسقًا داخليًا ويطبق مع ذلك سلوك منتج خاطئ.
- Refactors كبيرة مدمرة: diff ضخم أصعب في الفهم وأسهل في الموافقة عليه بلا انتباه كافٍ.
- Production deployment: نجاح الاختبارات لا يزيل operational risk.
- Final review: أريد أن أعرف ما الذي تغير قبل أن أضع اسمي عليه.
ليس لأن AI عديم الفائدة في هذه المناطق، بل لأن الإجابة الخاطئة التي تبدو منطقية قد تكون مكلفة جدًا.
AI review لا يستبدل static analysis
لا أرى Codex بديلًا للـcompilers والlinters والtests والscanners والmonitoring. هذه الأدوات تملك ميزة لا يملكها AI: محددة، deterministic، وقابلة للتكرار.
أقوى workflow يجمع بينها. Codex يمكنه التفكير في السياق واقتراح أين يجب النظر. الأدوات الثابتة تفرض قواعد دقيقة. الاختبارات تتحقق من السلوك. Logs وmonitoring تظهر الواقع. Human review يربط كل هذه الإشارات بهدف المنتج.
من دون هذه feedback systems، سأثق في AI أقل، لا أكثر.
أكبر مكسب إنتاجية هو توزيع الانتباه بشكل أفضل
من السهل القول “Codex يوفر الوقت”، لكن ذلك يقلل من حجم التغيير بالنسبة لي.
المورد النادر في تطوير البرمجيات ليس keystrokes، بل الانتباه عالي الجودة. قبل AI coding agents، كان جزء كبير منه يضيع في discovery المتكرر: البحث عن نفس patterns، قراءة ملفات متشابهة، تتبع references، التحقق من انتشار التغيير، ثم تكرار audit نفسه في repository آخر.
الآن يمكنني تفويض المزيد من first-pass work والاحتفاظ بانتباهي للقرارات الأصعب في الأتمتة: هل finding مهم؟ هل fix مناسب للarchitecture؟ هل UX يتحسن؟ هل الخطر مقبول؟ هل أريد فعلاً ship هذا التغيير؟
لهذا أصبحت صيانة ومراجعة عدة مشاريع مختلفة. لا أراجع أقل. في حالات كثيرة أستطيع مراجعة أكثر لأن الجزء الميكانيكي لم يعد يستهلك الميزانية كلها.
الـworkflow الذي أثق به
- تحديد هدف مراجعة ضيق. Bugs أو tests أو SEO أو localization أو refactor أو مجال محدد آخر.
- السماح للوكيل بالفحص قبل التعديل. أريد evidence والمواقع المتأثرة أولاً.
- ترتيب findings حسب الأولوية. ليست كل مشكلة نظرية تستحق تغيير الكود.
- إبقاء التغييرات محدودة. diffs صغيرة ومتجانسة أسهل في التحقق.
- تشغيل machine checks. Typecheck وlint وtests وbuild وsearch أو validation خاصة بالمشروع.
- قراءة diff يدويًا. أبحث عن rewrites غير ضرورية وافتراضات خاطئة وedge cases ناقصة وتغييرات خارج scope.
- التحقق من السلوك المهم. خصوصًا ما يتعلق بالمستخدمين والمال وsecurity وSEO وproduction infrastructure.
- ثم الانتقال للمشروع التالي. Parallelism مفيد، لكن الغموض غير المحلول لا يجب أن ينتشر.
15 مشروعًا لم تعد تبدو كأنها 15 ضعف عمل المراجعة
Codex لم يجعل 15 مشروعًا بسيطة ولم يلغ مسؤوليتي. ما غيّره هو العلاقة بين الحجم والجهد المتكرر.
أستطيع طلب first passes أعمق، وفحوص اتساق أوسع، وأفكار اختبارات أكثر، وaudits أكثر نظامية من دون أن أقضي كل دقيقة أبحث بنفسي في كل ملف. ثم أستخدم الانتباه الذي وفرته في القرارات التي ما زالت تحتاج مطورًا.
هذا هو AI-assisted development الذي أراه مفيدًا: ليس autopilot، ولا ثقة عمياء، ولا “ولّد كودًا حتى ينجح شيء”. إنه loop أقصر بين inspection على مقياس الآلة وjudgment على مقياس الإنسان.
بالنسبة لي، هذه هي الرافعة الحقيقية لـCodex. لا يلغي المراجعة، بل يجعل المراجعة الجادة ممكنة على نطاق كان أصعب بكثير من قبل.