يمثل ظهور الذكاء الاصطناعي التوليدي في مجال تطوير البرمجيات نقطة تحول جوهرية، مما يطرح تساؤلات ملحة حول آليات الحوكمة عندما تتولى الأنظمة الذكية مهمة كتابة الشيفرة البرمجية. وفي هذا السياق، برزت شركة Treasure Data، الرائدة في مجال منصات بيانات العملاء والتي تدعم أكثر من 450 علامة تجارية عالمية، لتقدم نموذجاً مبتكراً استند إلى خبراتها المكتسبة، لاسيما في تطوير "Treasure Code"، واجهة سطر الأوامر الجديدة كلياً المبنية على الذكاء الاصطناعي.
تتيح هذه الأداة لمهندسي البيانات وفرق المنصات التفاعل مع كامل إمكانيات منصة Treasure Data باستخدام اللغة الطبيعية، مع الاعتماد على نموذج Claude Code في عملية الإنشاء والتطوير. وما يثير الدهشة هو أن تطوير هذه الواجهة قد استغرق مهندساً واحداً حوالي 60 دقيقة فقط من حيث كتابة الكود. لكن القصة الأعمق تكمن في المتطلبات الأساسية التي سبقت هذه الـ 60 دقيقة، والتحديات التي واجهت الشركة بعد ذلك.
بناء طبقة الحوكمة أولاً: أساس الأمان في عصر البرمجة بالذكاء الاصطناعي
قبل البدء في كتابة سطر واحد من التعليمات البرمجية، كان على Treasure Data الإجابة على سؤال أكثر تعقيداً: ما هي الإجراءات التي يجب على النظام تجنبها، وكيف يمكن فرض هذه القيود على مستوى المنصة بدلاً من مجرد الاعتماد على امتثال الشيفرة البرمجية؟
تمثلت الحلول التي وضعتها Treasure Data في بناء طبقة حوكمة قوية تقع في مرحلة سابقة للكود نفسه. عند اتصال أي مستخدم بمنصة بيانات العملاء عبر Treasure Code، يتم تطبيق ضوابط الوصول وإدارة الأذونات مباشرة من المنصة الأم. وهذا يضمن أن المستخدمين لا يمكنهم الوصول إلا إلى الموارد المصرح لهم بها مسبقاً. كما تمنع هذه الطبقة من كشف معلومات التعريف الشخصية (PII) أو مفاتيح واجهات برمجة التطبيقات (API)، ولا يسمح للنظام بإطلاق تصريحات سلبية حول علامة تجارية أو منافس.
قال رافا فلوريس، كبير مسؤولي المنتجات في Treasure Data: "كان علينا إشراك كبار مسؤولي أمن المعلومات، وكنت مشاركاً، وكذلك كبير مسؤولي التكنولوجيا لدينا ورؤساء الهندسة، للتأكد من أن هذا النظام لن يخرج عن السيطرة."
النظام الثلاثي لمراجعة جودة الكود المولّد بالذكاء الاصطناعي
مكنت هذه البنية التحتية القوية من تطبيق الخطوة التالية: السماح للذكاء الاصطناعي بتوليد 100% من الشيفرة البرمجية، مع وجود نظام جودة ثلاثي المستويات يفرض معايير الإنتاج طوال العملية.
يتكون المستوى الأول من مراجع كود يعتمد على الذكاء الاصطناعي، ويستخدم أيضاً نموذج Claude Code. يعمل مراجع الكود هذا في مرحلة طلبات الدمج (pull requests)، ويطبق قائمة تحقق منظمة للمراجعة على كل دمج مقترح. يشمل ذلك التحقق من التوافق المعماري، والامتثال الأمني، ومعالجة الأخطاء بشكل سليم، وتغطية الاختبارات، وجودة التوثيق. في حال استيفاء جميع المعايير، يمكن دمج الكود تلقائياً. أما في حالة عدم استيفاء المعايير، يتم لفت الانتباه للتدخل البشري.
وتجدر الإشارة إلى أن بناء مراجع الكود نفسه باستخدام Claude Code ليس أمراً عرضياً. فهذا يعني أن الأداة التي تتحقق من صحة الكود المولّد بالذكاء الاصطناعي هي نفسها مولّدة بالذكاء الاصطناعي، مما يثبت أن سير العمل يعزز نفسه بنفسه بدلاً من الاعتماد على طبقة جودة منفصلة مكتوبة بشرياً.
المستوى الثاني هو خط أنابيب التكامل المستمر/التسليم المستمر (CI/CD) القياسي، الذي يقوم بتشغيل اختبارات الوحدة، والاختبارات التكاملية، والاختبارات الشاملة، والتحليل الثابت، والتدقيق اللغوي، والفحوصات الأمنية على كل تغيير. أما المستوى الثالث فهو المراجعة البشرية، والتي تكون مطلوبة في الحالات التي تحدد فيها الأنظمة الآلية مخاطر أو تتطلب سياسات المؤسسة موافقة نهائية.
المبدأ الداخلي الذي تعمل به Treasure Data هو: الذكاء الاصطناعي يكتب الكود، لكن الذكاء الاصطناعي لا يقوم بشحن الكود (أي نشره).
لماذا يختلف Treasure Code عن الأدوات العامة؟
قد يتساءل أي فريق هندسي عن سبب عدم استخدام أدوات موجودة مثل Cursor، وتوجيهها نحو منصة البيانات الخاصة بهم، أو تعريضها كخادم MCP والسماح لـ Claude Code بالاستعلام عنها مباشرة. يجيب فلوريس بأن الفرق الرئيسي يكمن في عمق الحوكمة. الاتصال العام يوفر الوصول إلى البيانات عبر اللغة الطبيعية ولكنه لا يرث هياكل الأذونات الحالية للمنصة، مما يعني أن كل استعلام يتم تنفيذه بنفس مستوى الوصول المسموح به لمفتاح API.
على النقيض، يرث Treasure Code طبقة التحكم الكامل في الوصول والأذونات الخاصة بـ Treasure Data، لذا فإن ما يمكن للمستخدم القيام به عبر اللغة الطبيعية يقتصر على ما هو مصرح له بالفعل في المنصة. التمييز الثاني هو التنسيق. نظراً لأن Treasure Code يتصل مباشرة بـ "AI Agent Foundry" من Treasure Data، يمكنه تنسيق الوكلاء والمهارات الفرعية عبر المنصة بدلاً من تنفيذ مهام فردية بمعزل عن غيرها؛ وهذا هو الفرق بين توجيه الذكاء الاصطناعي لإجراء تحليل، وتمكينه من تنسيق هذا التحليل عبر التفعيل متعدد القنوات، والتقسيم، وإعداد التقارير في وقت واحد.
التحديات غير المتوقعة: ما الذي حدث بشكل خاطئ؟
على الرغم من وجود بنية الحوكمة، لم يمر الإطلاق بسلاسة تامة. اعترفت Treasure Data بصراحة بهذه التحديات. فقد أتاحت الشركة "Treasure Code" للعملاء دون خطة تسويق جاهزة، على افتراض أنه سيبقى سرياً بينما يحدد الفريق الخطوات التالية. ومع ذلك، اكتشف العملاء الأداة بشكل طبيعي؛ فقد تبناها أكثر من 100 عميل وحوالي 1000 مستخدم في غضون أسبوعين فقط عبر الاكتشاف العضوي.
قال فلوريس: "لم نضع أي تحركات تسويقية له. لم نعتقد أن الناس سيكتشفونه. لكنهم فعلوا". وأضاف: "وجدنا أنفسنا في سباق مع الزمن لتحديد كيفية تنفيذ هذه التحركات التسويقية. هل نقوم بإطلاق تجريبي، نظراً لأنه متاح تقنياً؟"
أدى هذا التبني غير المخطط له أيضاً إلى فجوة امتثال. لا تزال Treasure Data في طور التصديق الرسمي لـ "Treasure Code" بموجب برنامج "Trust AI" الخاص بها، وهو اعتماد لم تكن قد أكملته قبل وصول المنتج إلى العملاء.
ظهرت مشكلة ثانية عندما فتحت Treasure Data تطوير المهارات لفرق غير هندسية. بدأ مديرو نجاح العملاء ومديرو الحسابات في بناء وتقديم مهارات دون فهم ما سيتم اعتماده ودمجه، مما أدى إلى إهدار كبير للجهد وتراكم في الطلبات التي لم تتمكن من تجاوز سياسات الوصول الخاصة بالمستودع.
التحقق من الاعتماد المؤسسي وما لا يزال مفقوداً
تعد Thomson Reuters من بين المتبنين الأوائل. أفاد فلوريس أن الشركة كانت تحاول بناء منصة وكلاء ذكاء اصطناعي داخلية وتواجه صعوبة في التحرك بالسرعة الكافية. تواصلت الشركة مع "AI Agent Foundry" من Treasure Data لتسريع عمل تجزئة الجمهور، ثم توسعت لتشمل "Treasure Code" للتخصيص والتكرار بشكل أسرع. وأشار فلوريس إلى أن التعليقات تركزت على قابلية التوسيع والمرونة، وحقيقة أن عملية الشراء كانت قد تمت بالفعل، مما أزال حاجزاً كبيراً أمام تبني المؤسسات.
الفجوة التي أشارت إليها Thomson Reuters، والتي يقر فلوريس بأن المنتج لا يعالجها بعد، هي توجيهات حول نضج الذكاء الاصطناعي. "Treasure Code" لا يخبر المستخدمين بمن يجب استخدامه، أو ما يجب معالجته أولاً، أو كيفية تنظيم الوصول عبر مستويات مهارة مختلفة داخل المؤسسة.
ويضيف فلوريس: "أعتقد أن الذكاء الاصطناعي الذي يسمح لك بأن تكون فعالاً، ولكنه يخبرك أيضاً بكيفية الاستفادة منه، هذا تمييز قوي". ويرى أنها الطبقة الهادفة التالية التي يجب بناؤها.
دروس للمهندسين القادة: استخلاص العبر من تجربة Treasure Data
وجد فلوريس الوقت للتفكير في ما تعلمه فعلياً من هذه التجربة، وكان صريحاً بشأن ما سيغيره. في المرة القادمة، كما يقول، سيتم إطلاق المنتج داخلياً أولاً. "سنطلقه داخلياً فقط. لن أطلقه لأي شخص خارج المنظمة"، كما قال. "سيكون الأمر أشبه بإطلاق متحكم فيه حتى نتمكن فعلياً من تعلم ما نتعرض له فعلياً بمخاطر أقل."
فيما يتعلق بتطوير المهارات، كان الدرس هو وضع معايير واضحة لما سيتم اعتماده ودمجه قبل فتح العملية أمام فرق خارج الهندسة، وليس بعد ذلك. الخيط المشترك في كلا الدرسين هو نفسه الذي شكّل بنية الحوكمة وخط الأنابيب الثلاثي: السرعة ليست ميزة إلا إذا كان الهيكل المحيط بها ثابتاً. بالنسبة لقادة الهندسة الذين يقيمون ما إذا كانت البرمجة الوكيلة جاهزة للإنتاج، فإن تجربة Treasure Data تترجم إلى ثلاث استنتاجات عملية:
يجب أن تسبق البنية التحتية للحوكمة الكود، لا أن تلحق به. كانت ضوابط الوصول على مستوى المنصة واستعارة الأذونات هي ما جعل من الآمن السماح للذكاء الاصطناعي بالتوليد بحرية. بدون هذه الأساس، تختفي ميزة السرعة لأن كل مخرج يتطلب مراجعة يدوية شاملة.
بوابة الجودة التي لا تعتمد كلياً على البشر ليست اختيارية على نطاق واسع. يجب بناء بوابة جودة لا تعتمد كلياً على البشر. يمكن للذكاء الاصطناعي مراجعة كل طلب دمج باستمرار، دون إرهاق، والتحقق من الامتثال للسياسات بشكل منهجي عبر كامل قاعدة الأكواد. تظل المراجعة البشرية ضرورية، ولكن كفحص نهائي بدلاً من آلية الجودة الأساسية.
خطط للتبني العضوي. إذا كان المنتج يعمل، سيجده الناس قبل أن تكونوا مستعدين. فجوات الامتثال والتسويق التي لا تزال Treasure Data تعمل على سدها هي نتيجة مباشرة للتقليل من شأن ذلك.
يختتم فلوريس بالقول: "نعم، يمكن أن تعمل البرمجة التوليدية إذا تم إجراؤها بطريقة آمنة وتم وضع الضوابط المناسبة. "احتضنوها لإيجاد وسائل ليس لاستبدال العمل الجيد الذي تقومون به، بل العمل الممل الذي يمكنكم أتمتته على الأرجح."
