Habr AI: توليد الكود يغيّر دور المطور — روتين أقل ومعمارية أكثر

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

المطوّر بوصفه محرِّراً

كانت نقطة الانطلاق تجربةً عملية: حاول الكاتب بناء خدمة كاملة تقريباً عبر توليد الكود، مُفوِّضاً النموذجَ بكتابة API وقاعدة البيانات والمعالجات. في هذا السياق، يتداعى النهج المألوف «الجلوس والكتابة» بسرعة. لم يعد المطوّر يكتب المتحكمات وجمل SQL يدوياً، بل يحدد البنية والقيود والسلوك المتوقع، ثم يتلقى مسودةً للنظام. ينتقل العمل إلى مستوى أعلى: من تنفيذ كل دالة — إلى وصف المهمة ثم تحرير النتيجة لاحقاً.

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

يصوغ الكاتب ذلك بوضوح تام:

«يكاد يختفي وقت كتابة الكود. لكن وقت فهم الكود، على العكس من ذلك، يتزايد.»

الهندسة المعمارية وتصحيح الأخطاء

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

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

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

• أين وبأي شكل تُخزَّن البيانات
• كيف يتوسع الخدمة في مواجهة الحمل المتزايد
• كيف هو هيكل التخزين المؤقت وdata pipeline
• كيف تتناسق الأنماط والقوالب وحدود الوحدات
• كيف تُفحص الأخطاء المنطقية في الكود المولَّد

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

ثمة مخاطرة أخرى أيضاً — تشتت قاعدة الكود بين أساليب مختلفة. يكتب مولِّد بطريقة، ويكتب آخر بطريقة مغايرة؛ وبعد عام تغيّر الفريق الأداةَ، فتغيّرت معها بنية الدوال ومعالجة الأخطاء وأنماط التسمية. النتيجة ليست مشروعاً موحداً، بل خليط من أساليب كتابة متعددة يصعب قراءتها وصيانتها أكثر فأكثر.

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

ماذا يعني هذا

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

في هذا السياق، تبدو فكرة تخصص جديد مقنعةً بشكل خاص: مهندس يعرف كيف يصوغ مهمةً بصورة صحيحة للمولِّد، ويتحقق من النتيجة، ويُبقي الهندسة المعمارية في حالة عمل.

البداية وحدها ستصبح أسهل. أما كل ما عداها، فيبدو أنه سيكون أصعب من ذي قبل.