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

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

إذن، أين ينبغي للمطوّر أن يقضي وقته؟

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

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

الجزء الذي يحتاج إلى أكبر قدر من الشرح هو التحقق. إذا لم أكن أقرأ كل سطر، فأنا بحاجة إلى طريقة أخرى لتحديد ما إذا كان التنفيذ يتصرّف بشكل صحيح. أريد نظامًا معياريًا، والكثير من اختبارات التكامل، واختبارات وحدة مركّزة، واختبارات شاملة (end-to-end) للتدفقات المهمة. أفضّل التصميم لهذا منذ البداية بدلًا من إضافته لاحقًا.

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

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

وأحيانًا أحتاج إلى إيقاف التطوير. يمكن للميزة التالية أن تنتظر بينما نصلح ما أصبح هشًّا أو صعب الاختبار. شرح ذلك لمدير المنتج يتطلّب أكثر من قول “دين تقني”. أي التغييرات أصبحت محفوفة بالمخاطر؟ ما الذي يستمر في التعطّل؟ ما الذي سيحسّنه فعلًا توحيد النظام الحالي؟

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