البناء بموثوقية باستخدام الـ agents

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

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

ومن الأفضل قراءتها بهذا الترتيب تقريبًا. vibe coding يسمّي العادة الافتراضية — أن تصف ما تريده وتوجّه بالإحساس — وهو صريح في مواضع تألّقها ومواضع ضررها. والـ slop والحتمية يعطيك الإصلاح البنيوي: أبقِ ما يمكن أن يكون مؤكّدًا مؤكّدًا، ودع الـ model يتولّى ما هو ضبابي فعلًا وحده. والـ recursive agents وهندسة الـ loop هما حجّتا التنسيق، إحداهما عن agent يفكّك عمله ويتحقّق منه بنفسه، والأخرى عن تصميم الـ loop الذي يوجّه الـ agent بدل أن توجّهه أنت بنفسك. والـ software factory يبتعد بالعدسة إلى الدورة كاملة — إشارة تدخل، وتغيير مُطلَق يخرج — وهو الأكثر تكهّنًا بين الخمسة.

وتحذيران قبل أن تدخل. أولًا، لا شيء من هذا يتعلّق بكتابة prompts أفضل؛ بل إن الادّعاء المشترك بينها هو أن جودة الـ prompt تتوقّف عن كونها المتغيّر المثير للاهتمام في وقت مبكّر بشكل مفاجئ. ثانيًا، هذه المادة تميل إلى التقنية وإلى مسار Power Track — فالأمثلة كلها كود و pipelines. لكن الحُكم ينتقل جيدًا إلى ما هو أبعد من الكود. فـ«قسّمه صغيرًا بما يكفي للفحص، واجعل الفحص تلقائيًا» صحيحة في عملية تقرير شهري كما هي صحيحة في أي test suite.