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