الذكاء الاصطناعي مسألة هندسية. وليس عرضاً تجريبياً.
أتعامل مع الذكاء الاصطناعي كمسألة هندسية: أقيسه، وأتحكم بتكلفته، وأصمم لحالات خطئه.
-
أقيسه
كل ميزة ذكاء اصطناعي تُطلق مع مجموعة اختبار ورقم يبيّن جودتها.
-
أتحكم بتكلفته
التكلفة والسرعة لكل تشغيل محددة قبل الإطلاق، لا تُكتشف بعده.
-
أصمم لحالات الخطأ
ضعف الثقة أو الصمت أو المدخلات السيئة تقود إلى خطوة تالية آمنة وواضحة.
نظامان، ونهج واحد
محرك تقييم السير الذاتية
أداة عامة تقيّم السيرة الذاتية من 100 كما تقرؤها أنظمة التوظيف. دقّقت طريقة تقييمها، وأصلحت القواعد التي كانت تخصم نقاطاً بغير حق، وجعلت كل نتيجة قابلة للتفسير — والسيرة المثالية تصل الآن إلى 100.
النتيجة لا قيمة لها إن لم تستطع تفسيرها.
النتيجة على نفس السيرة التجريبية
قبل الإصلاحات وبعدها · النتيجة من 100
-
نتيجة السيرة التجريبية +5 نقاطقبل: 85بعد: 90
كيف بُني
- النهج
- قواعد واضحة وموزونة تحدد النتيجة، دون أي نموذج في خطوة التقييم. أصلحت أربع مشاكل: الفحوصات التي لا تنطبق على السيرة لم تعد تخصم نقاطاً، والوظيفة المستهدفة تُفهم من السيرة نفسها، وملفات Word والنصوص تُقرأ بشكل صحيح، ولا تُحسب المشكلة نفسها مرتين.
- التقييم
- بدأت بتدقيق مكتوب لطريقة عمل التقييم، ثم فحصت كل إصلاح على نفس السيرة التجريبية. ولأن القواعد ثابتة، تحصل نفس السيرة دائماً على نفس النتيجة.
- التكلفة والسرعة
- لا يُستدعى أي نموذج لحساب النتيجة، فتكلفة كل فحص شبه معدومة، والنتيجة تظهر فوراً.
- عند الخطأ
- كل فحص يعرض نتيجته وسببها، فيعرف المتقدم بالضبط ما يجب إصلاحه. وإذا كان ملف Word أو النص صعب القراءة، يسترجع الفاحص النص بدل أن يفشل.
- دعم العربية
- الأداة تعمل بالعربية والإنجليزية. وقراءة السير العربية بصيغة PDF هي الخطوة التالية.
هندسة برمجيات بوكلاء الذكاء الاصطناعي تقودها المواصفات
هكذا أبني البرمجيات مع وكلاء البرمجة بالذكاء الاصطناعي. أكتب المواصفات أولاً: نموذج البيانات، وقواعد العمل، وشروط قبول كل ميزة. يكتب الوكيل الكود وفق هذه المواصفات، وتتحقق منه الاختبارات، وأراجع أنا كل تغيير قبل إطلاقه. بهذه الطريقة بنيت نظام ERP متعدد المستأجرين من 18 وحدة وحدي، إلى جانب عملي الآخر في الأنظمة العاملة.
الوكيل يكتب الكود. أما التصميم والقواعد وقرار الإطلاق فهي مسؤوليتي.
- المواصفات عقد مكتوب
- الوكيل يكتب الكود
- الاختبارات تتحقق من المواصفات
- المراجعة إنسان يوافق
عندما تكون المواصفات غير واضحة، يتوقف الوكيل ويسأل إنساناً بدلاً من التخمين.
كيف بُني
- النهج
- قبل أي كود، أكتب مواصفات بصيغة Markdown: نموذج البيانات، وقواعد العمل، والشاشات، وشروط قبول كل ميزة. ولكل مشروع مهارات خاصة بالوكيل — قواعد مكتوبة للتقنيات والتسميات وترتيب المجلدات والنصوص باللغتين. يعمل الوكيل على مهام صغيرة، ميزة واحدة في كل مرة. المهام الصغيرة أسهل في المراجعة، وأسهل في التراجع عنها.
- التقييم
- لا يكتمل أي تغيير إلا بعد ثلاثة فحوص: شروط القبول في المواصفات، والاختبارات الآلية، ومراجعتي أنا للكود. أقرأ كل تغيير قبل دمجه. وإذا لم أستطع شرح سطر، لا يُطلق.
- التكلفة والسرعة
- السرعة تأتي من تقسيم العمل، لا من تجاوز المراجعة. يتولى الوكيل العمل المتكرر — الشاشات والنماذج والـ migrations والترجمات — وأركّز أنا على التصميم وقواعد العمل والحالات الصعبة. هذا التقسيم هو ما يسمح لمهندس واحد ببناء نظام ERP كامل متعدد المستأجرين وتشغيله.
- عند الخطأ
- عندما تكون المواصفات غير واضحة، يتوقف الوكيل ويسأل بدل أن يخمّن. وعندما يفشل تغيير في أحد الفحوص، يعود إلى الوكيل مع الاختبار الفاشل نفسه، لا مع ملاحظة عامة. أما المناطق الحساسة — المال، والصلاحيات، والفوترة الضريبية، والبيانات الشخصية — فتراجَع دائماً سطراً سطراً.
- دعم العربية
- كل مواصفات تُكتب للغتين من البداية. نصوص الواجهة، والاتجاه من اليمين، والأرقام والتواريخ العربية جزء من شروط القبول — لا شيء يُصلح في النهاية.
تحتاج ذكاءً اصطناعياً مُقاساً قبل إطلاقه؟
أخبرني بالقرار الذي يجب أن يتخذه، وسأخبرك كيف سنعرف أنه يعمل.