الترميز بالحدس وصل إلى التمويل. وهو بحاجة إلى طبقة أساس مُسوّاة.

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

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

المنطق يُراجَع. الأرقام لا تُراجَع أبداً

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

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

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

خط النضج، وأين تتوقف الموثوقية عن كونها اختيارية

ليست كل أداة مبنية بالحدس بحاجة إلى المعيار نفسه. حجم المخاطرة يتبع مدى ابتعاد المخرج عن الشخص الذي بناه.

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

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

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

لماذا “أعِد كتابتها بشكل صحيح فحسب” غريزة خاطئة

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

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

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

كيف يبدو “تحتها، لا بدلاً منها” على أرض الواقع

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

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

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

الخلاصة

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

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