لا أحب التحدث إلى الروبوتات

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

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

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

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

ما لم أتوقعه هو مدى صعوبة تعليم هذا.

هل أصبحت بيكاسو بعد؟

هناك فكرة (بين الإدارة العليا؟) أن أدوات النماذج اللغوية الكبيرة ستزيد إنتاجية جميع المهندسين. عمليًا، لم أرَ هذا. ما أراه هو مهندسون متمرسون وقادرون على التكيف يحققون عدة أضعاف مما كانوا ينتجونه، بينما الآخرون ينتجون نفس الكمية أو أقل.

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

متلازمة التنفيذ المتوازي

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

ومع ذلك، بطريقة ما، لم يكن يعمل.

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

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

جلست معها وطرح سؤالاً بسيطاً: "قبل أن تطلب هذا، هل كنت تعلمين كيف نتعامل مع الجلسات اليوم؟" توقفت للحظة. "ليس تماماً." كانت هذه هي الفجوة. لم تكن قد رسمت خريطة المنطقة قبل أن تطلب من النموذج البناء عليها.

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

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

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

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

المهارات الناعمة هي المهارات الصلبة الجديدة

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

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

أحيانًا تدرك أن النموذج محق وأنت مخطئ، وتحتاج إلى التواضع لتقييم ذلك بعدل.

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

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

يتم وضع مهندسين مبتدئين في مواقف حيث يحتاجون إلى إجراء مفاوضات التصميم على مستوى عالٍ، ولكن لا يبدو أن هناك منهج دراسي لذلك. حان الوقت للتحول من 'LeetCode' إلى مفاوضات التصميم، وهذا سيكون موضوع المنشورات المستقبلية في هذه السلسلة.

ملحق

المهارات الناعمة لتفاوض المواصفات الفنية مع الذكاء الاصطناعي

خلال التفاوض

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

خلال العملية بأكملها

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

تفاوض التصميم: المهارات الناعمة المطلوبة للبرمجة بالذكاء الاصطناعي