يبدو مخطط مساهماتي على GitHub في 2025 وكأنه يخص مطورين مختلفين. النصف الأول من العام شبه فارغ. أما النصف الثاني ففيه أكثر من 4000 commit.
لم أحصل فجأة على وقت فراغ إضافي. كنت ما زلت أوازن بين وظيفة بدوام كامل ومشاريع جانبية. ما تغيّر هو مقدار الاحتكاك بين الفكرة ونسخة تعمل فعلاً: بدأت أستخدم أدوات البرمجة بالذكاء الاصطناعي بجدية أكبر بكثير.
لكن يجب التعامل مع هذا الرقم بدقة. عدد الـcommits ليس بحد ذاته مقياساً للإنتاجية. أربعة آلاف commit لا تعني أربعة آلاف تحسين مهم، ولا تثبت أن جودة الشيفرة كانت عالية. ما يوضحه المخطط فعلاً هو تغيّر حقيقي في نمط عملي: أصبحت أبني وأكرر وأصل إلى نسخ عاملة باستمرارية أكبر بكثير من السابق.
المشكلة الحقيقية كانت تكلفة بدء التجربة
مع الوقت لاحظت المشكلة نفسها في كثير من المشاريع الجانبية: النسخة الأولى المفيدة تكون غالباً خلف كمية كبيرة من العمل الروتيني. Routing وvalidation والscripts والtests والconfiguration والتنظيف قد تستهلك الحماس قبل أن أصل إلى الجزء الذي أريد اختباره فعلاً.
كنت أؤجل بعض التجارب عندما تبدو كأنها تحتاج عدة أمسيات من الإعداد. أدوات AI coding لم تلغِ هذا العمل، لكنها خفّضت تكلفة المسودة الأولى وجعلت الوصول إلى نسخة قابلة للاختبار أسرع.
لهذا لا أرى المكسب الأساسي على أنه كتابة أسرع. المكسب الأهم كان انخفاض طاقة البدء: أصبحت أفكار أكثر تصل إلى مرحلة يمكنني فيها جمع دليل حقيقي بدلاً من بقائها في قائمة المهام.
كيف تغيّر workflow الخاص بي مع Node.js
لم أستبدل عملية التطوير بنافذة chat. استخدمت DeepSeek كزوج ثانٍ من الأيدي في مهام محددة داخل مشاريع Node.js: إعداد مسودة أولى، قراءة جزء غير مألوف من codebase، اقتراح tests، تحليل stack trace، تقسيم refactor كبير إلى خطوات أصغر، ومراجعة افتراضات deployment.
- Scaffolding: إنشاء النسخة المملة الأولى من handlers وvalidation وscripts وtests.
- Code reading: تتبع مسار قيمة أو request قبل تعديلها.
- Refactoring: اقتراح تغييرات ميكانيكية صغيرة يمكن مراجعتها بسهولة.
- Debugging: توليد عدة فرضيات من logs بدلاً من التعلق بأول تفسير.
- Verification: اقتراح edge cases وregression tests بعد نجاح happy path.
كلما كان العقد المحلي أوضح—inputs وoutputs والقيود والأنماط الموجودة—كانت النتيجة أسهل في التحقق. أما المهمة الغامضة فكانت أكثر عرضة لإنتاج حل يبدو مقنعاً لكنه يختار abstraction غير مناسب.
لذلك تعاملت مع كل output كـcandidate patch، لا كإجابة نهائية. Type checking والtests والbuild وتجربة المسار الحقيقي كانت الدليل؛ الثقة في صياغة النموذج لم تكن دليلاً.
أين ساعدني DeepSeek أكثر — وأين لم يساعد
كان DeepSeek مفيداً خصوصاً لأن استخدامه المتكرر في مهام البرمجة كان عملياً بالنسبة لي. أستطيع طلب first pass، رفض جزء منه، إرسال الخطأ الحقيقي، تضييق المهمة، ثم إعادة المحاولة بسرعة.
لا أقدّم ذلك كـbenchmark. لم أشغّل دراسة مضبوطة ضد كل نموذج منافس، والنماذج تتغير بسرعة. الادعاء الذي أستطيع الدفاع عنه أبسط: كان DeepSeek مناسباً بما يكفي لسير عملي لدرجة أنني استخدمت AI assistance بتكرار أكبر، وهذا غيّر طريقة تعاملي مع المشاريع الجانبية.
كان أقوى عندما تكون المشكلة محددة والتغذية الراجعة رخيصة: function وtests وerror واضح. وكان أضعف عندما تعتمد المهمة على سياق منتج غير مكتوب أو trade-offs معمارية دقيقة. في تلك الحالات قد تجعل الطلاقة افتراضاً سيئاً يبدو مكتملًا.
الذكاء الاصطناعي غيّر تكلفة التجربة
أكبر فائدة لم تكن «الذكاء الاصطناعي يكتب الشيفرة، إذن التطوير أصبح تلقائياً». ما تغيّر هو أن أجزاء صغيرة كثيرة أصبحت رخيصة بما يكفي لتجربتها. ميزة جانبية كانت تبدو سابقاً وكأنها تحتاج إلى إعداد طويل يمكن أن تتحول الآن إلى prototype بينما ما زلت مهتماً بالفكرة.
هذا الفرق مهم. خفّض الذكاء الاصطناعي تكلفة الوصول إلى نسخة قابلة للاختبار، لكنه لم يلغِ المعمارية أو قرارات المنتج أو الـdeployment أو الحاجة إلى صحة التنفيذ. تنفيذ مولّد قد يكون خاطئاً؛ build ناجح قد يفشل في runtime؛ وprototype منشور قد يظل منتجاً سيئاً.
الفائدة العملية بالنسبة لي كانت الزخم. عندما أرى النظام كله يعمل، يصبح من الأسهل بكثير الاستمرار في تحسينه.
ما الذي يحتاجه benchmark أقوى
لتحويل هذه التجربة إلى benchmark قابل لإعادة الإنتاج، سأحتاج إلى تسجيل نسخ النماذج الدقيقة، مهام برمجية ثابتة، snapshots من المستودع، prompts، outputs الخام، الزمن، patches المقبولة والمرفوضة، وقت المراجعة، نتائج tests وحجم إعادة العمل.
وسأقيس workflow بأكثر من عدد commits: الزمن من الفكرة إلى نسخة موثقة، defects التي وصلت بعد الدمج، rollbacks، وكمية العمل التي احتاجت إلى إعادة كتابة. من دون ذلك، 4000 commit دليل على تغيّر السلوك والنشاط، لا على جودة software.
ما الذي تغيّر بالنسبة لي
كان 2025 العام الذي توقفت فيه عن النظر إلى كل side project باعتباره جبلاً من الإعداد يجب أن أتسلقه يدوياً. جعل الذكاء الاصطناعي الوصول إلى أول نسخة عاملة أقل كلفة بما يكفي لأصل مرات أكثر إلى المرحلة التي تصبح فيها قرارات المنتج هي المهمة فعلاً.
لهذا يبدو النصف الثاني من مخطط GitHub مختلفاً إلى هذه الدرجة. ليس لأن الذكاء الاصطناعي أعطاني ساعات إضافية في اليوم، ولا لأن كل سطر مولّد كان جيداً. بل لأنه خفّض الاحتكاك الذي كان يقتل أفكاراً سابقة قبل أن تصبح حقيقية.
في 2026، يهمني الجزء الأقل بريقاً من المعادلة: تحسين الـworkflow، وقياس الجودة بجدية أكبر، والتأكد من أن التطوير الأسرع ينتج برمجيات أفضل، لا مجرد commits أكثر.