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

والآن بعد أن دخل الوكلاء إلى اللعبة، تغيّر ذلك.

It was almost impossible for a programmer who wrote all their code by hand to divorce their ego from the output. Now agents are delivering what decades of agile admonishing about “collective ownership” never could. What a gift!

— DHH (@dhh) October 6, 2026

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

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

إذا اقترح أحدهم استبداله (جذريًا) بنهج مختلف (تمامًا)، كان الرد غالبًا “قضيت وقتًا طويلًا جدًا؛ إنه يعمل؛ لا يجب أن نلمسه”

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

الآن، ولأن الوكلاء يكتبون معظم التنفيذات، لم يعد هذا الضغط موجودًا.

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

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

التعلق نفسه لم يختفِ؛ بل انتقل ببساطة إلى شيء أهم: التصميم المعماري، والحزمة التقنية، وتعريف البنية التحتية، والعمليات، والمنتج، وغير ذلك.

تلك القرارات ما زالت تتطلب تفكيرًا حقيقيًا، وهي ما سأدافع عنه في المراجعة.

الكود نفسه مجرد وسيلة للتعبير عن تلك الأفكار.

لذا فالقرارات التي أدت إلى ذلك الكود هي المكان الصحيح للتعلق.

هذا يفتح الأبواب لمزيد من التجريب، ولقدرة أوسع على التغيير والتكيّف بمرونة أكبر، دون الحاجة إلى كسر جدار الغرور لدى المهندسين.

لكن هناك خطرًا يجب أخذه في الحسبان.

عدم التعلق بالكود قد يعني أيضًا عدم فهمه.

لا يمكن استبدال أجزاء من الكود بأمان إلا إذا كان المهندسون يعرفون ما يُفترض أن يفعله النظام، ولديهم اختبارات تثبت أن البديل ما زال يفعل ذلك.