كل الأبحاث
تعليق
2025-03-27 · 6 دقيقة
الذكاء الاصطناعي يستطيع كتابة الكود، لكنه لا يستطيع تعويض الخبرة الهندسية في البرمجة
كشفت تجربة حديثة أثناء فحص نظام لإدارة عيادة عن مشكلة متزايدة في عالم البرمجيات: التعامل مع الكود الذي يولده الذكاء الاصطناعي باعتباره بديلاً عن الخبرة الهندسية في تطوير البرمجيات. يستطيع الذكاء الاصطناعي إنشاء التطبيقات بسرعة، لكن من دون فهم قواعد البيانات والأداء والمعمارية البرمجية والتصحيح والأمن والصيانة، يمكن أن يتحول نموذج يعمل ظاهرياً إلى منتج تجاري مليء بالمشكلات.
غيّر الذكاء الاصطناعي طريقة تطوير البرمجيات بشكل كبير. اليوم يستطيع الذكاء الاصطناعي توليد واجهات المستخدم وواجهات API و Database Models و Backend Logic وحتى تطبيقات كاملة خلال وقت قصير.
لكن توليد الكود ليس هو نفسه فهم Software Engineering.
مررت مؤخراً بتجربة عملية أثناء فحص نظام لإدارة عيادة تم شراؤه من جهة أخرى تقدم خدمات برمجية بسعر منخفض. بعد فترة تقارب الشهر من الاستخدام، بدأت تظهر مشاكل واضحة في الأداء. أصبح النظام بطيئاً، وبدأت بعض المشاكل تتكرر، ولم تكن هناك عملية تقنية واضحة لتحديد Root Cause للمشاكل.
بعد الحصول على الموافقة لفحص التطبيق والاطلاع على Source Code، ظهر أن البرنامج تم تطويره باستخدام Python ثم تم Package للتطبيق ليصبح برنامجاً قابلاً للتشغيل.
لكن المشكلة الأساسية لم تكن في Python ولا في طريقة Packaging.
المشكلة كانت في أساسيات Software Engineering.
من أهم المشاكل التي ظهرت أثناء الفحص عدم وجود Database Indexing مناسب.
الـ Database Indexing يعتبر من أساسيات Database Optimization. عندما يقوم التطبيق بعمليات Search أو Filter أو Join أو Sort على كمية كبيرة من البيانات بدون Indexes مناسبة، فقد تضطر قاعدة البيانات إلى تنفيذ عمليات غير فعالة مثل Full Table Scan.
عندما تكون كمية البيانات قليلة، قد لا تظهر المشكلة بشكل واضح.
لكن نظام إدارة العيادة ليس تطبيقاً ثابتاً.
مع مرور الوقت تبدأ قاعدة البيانات بالنمو من خلال بيانات المرضى والمواعيد والسجلات الطبية والوصفات والمعاملات المالية وغيرها من البيانات التشغيلية.
ومع نمو Dataset، يمكن أن تتحول Queries غير المحسنة إلى Performance Bottleneck حقيقي داخل النظام.
وهنا يظهر الفرق الحقيقي بين AI Generated Code وبين الخبرة في Software Engineering.
الذكاء الاصطناعي يستطيع أن يولد Database Query.
لكن من الذي يقوم بتحليل Query Execution Plan؟
الذكاء الاصطناعي يستطيع إنشاء Database Model.
لكن من الذي يحدد الأعمدة التي تحتاج إلى Index؟
الذكاء الاصطناعي يستطيع إنشاء تطبيق كامل.
لكن من الذي يقوم بمراقبة Performance داخل Production Environment؟
كون البرنامج يعمل لا يعني بالضرورة أنه تم تصميمه بشكل هندسي صحيح.
أي نظام تجاري يجب أن يأخذ بعين الاعتبار Scalability و Performance و Logging و Debugging و Error Handling و Database Optimization و Security و Backup Strategy و Maintenance.
المشكلة في الاعتماد الأعمى على الذكاء الاصطناعي هي أنه قد يعطي البعض انطباعاً بأن تطوير البرمجيات عبارة عن توليد كمية من الكود إلى أن يبدأ البرنامج بالعمل.
لكن الواقع مختلف تماماً.
الجزء الأصعب يبدأ بعد Deployment.
عندما يشتكي المستخدمون من بطء النظام، يبدأ المطور الحقيقي بتحليل Performance Bottleneck، ومراجعة Logs، وفحص Database Queries، وتحليل Indexes، وقياس Execution Time، وتحديد العمليات غير الفعالة للوصول إلى Root Cause.
من دون هذه المعرفة، يمكن أن يتحول الكود الذي تم توليده بالذكاء الاصطناعي بسرعة إلى Technical Debt.
قد تبدو الواجهة احترافية.
وقد يعمل البرنامج بشكل طبيعي أثناء الاختبار.
لكن عندما تبدأ قاعدة البيانات بالنمو أو يزداد Workload، تبدأ المشاكل المعمارية الحقيقية بالظهور.
المشكلة ليست في الذكاء الاصطناعي.
الذكاء الاصطناعي اليوم من أقوى الأدوات المتاحة للمطورين. يمكنه تسريع عملية التطوير، والمساعدة في Debugging، وكتابة Boilerplate Code، وشرح التقنيات الجديدة، وتحسين الإنتاجية.
لكن المشكلة تبدأ عندما يتم بيع نظام تجاري تم بناؤه بالذكاء الاصطناعي من دون وجود المعرفة التقنية اللازمة لفهمه وصيانته و Troubleshooting عند حدوث المشاكل.
Software Engineering ليست منافسة على من يستطيع توليد الكود بشكل أسرع.
القيمة الحقيقية هي في فهم النظام الذي تتحمل مسؤوليته.
الذكاء الاصطناعي يستطيع كتابة الكود.
لكن عندما يحدث Performance Degradation، أو تظهر Production Errors، أو تصبح Database Queries بطيئة، أو تبدأ Software Architecture بالفشل تحت الاستخدام الحقيقي، يجب أن يكون هناك شخص يفهم سبب المشكلة.
وهنا تظهر حقيقة مهمة.
الخبرة في Software Engineering لا يمكن الحصول عليها بمجرد كتابة Prompt.
لكن توليد الكود ليس هو نفسه فهم Software Engineering.
مررت مؤخراً بتجربة عملية أثناء فحص نظام لإدارة عيادة تم شراؤه من جهة أخرى تقدم خدمات برمجية بسعر منخفض. بعد فترة تقارب الشهر من الاستخدام، بدأت تظهر مشاكل واضحة في الأداء. أصبح النظام بطيئاً، وبدأت بعض المشاكل تتكرر، ولم تكن هناك عملية تقنية واضحة لتحديد Root Cause للمشاكل.
بعد الحصول على الموافقة لفحص التطبيق والاطلاع على Source Code، ظهر أن البرنامج تم تطويره باستخدام Python ثم تم Package للتطبيق ليصبح برنامجاً قابلاً للتشغيل.
لكن المشكلة الأساسية لم تكن في Python ولا في طريقة Packaging.
المشكلة كانت في أساسيات Software Engineering.
من أهم المشاكل التي ظهرت أثناء الفحص عدم وجود Database Indexing مناسب.
الـ Database Indexing يعتبر من أساسيات Database Optimization. عندما يقوم التطبيق بعمليات Search أو Filter أو Join أو Sort على كمية كبيرة من البيانات بدون Indexes مناسبة، فقد تضطر قاعدة البيانات إلى تنفيذ عمليات غير فعالة مثل Full Table Scan.
عندما تكون كمية البيانات قليلة، قد لا تظهر المشكلة بشكل واضح.
لكن نظام إدارة العيادة ليس تطبيقاً ثابتاً.
مع مرور الوقت تبدأ قاعدة البيانات بالنمو من خلال بيانات المرضى والمواعيد والسجلات الطبية والوصفات والمعاملات المالية وغيرها من البيانات التشغيلية.
ومع نمو Dataset، يمكن أن تتحول Queries غير المحسنة إلى Performance Bottleneck حقيقي داخل النظام.
وهنا يظهر الفرق الحقيقي بين AI Generated Code وبين الخبرة في Software Engineering.
الذكاء الاصطناعي يستطيع أن يولد Database Query.
لكن من الذي يقوم بتحليل Query Execution Plan؟
الذكاء الاصطناعي يستطيع إنشاء Database Model.
لكن من الذي يحدد الأعمدة التي تحتاج إلى Index؟
الذكاء الاصطناعي يستطيع إنشاء تطبيق كامل.
لكن من الذي يقوم بمراقبة Performance داخل Production Environment؟
كون البرنامج يعمل لا يعني بالضرورة أنه تم تصميمه بشكل هندسي صحيح.
أي نظام تجاري يجب أن يأخذ بعين الاعتبار Scalability و Performance و Logging و Debugging و Error Handling و Database Optimization و Security و Backup Strategy و Maintenance.
المشكلة في الاعتماد الأعمى على الذكاء الاصطناعي هي أنه قد يعطي البعض انطباعاً بأن تطوير البرمجيات عبارة عن توليد كمية من الكود إلى أن يبدأ البرنامج بالعمل.
لكن الواقع مختلف تماماً.
الجزء الأصعب يبدأ بعد Deployment.
عندما يشتكي المستخدمون من بطء النظام، يبدأ المطور الحقيقي بتحليل Performance Bottleneck، ومراجعة Logs، وفحص Database Queries، وتحليل Indexes، وقياس Execution Time، وتحديد العمليات غير الفعالة للوصول إلى Root Cause.
من دون هذه المعرفة، يمكن أن يتحول الكود الذي تم توليده بالذكاء الاصطناعي بسرعة إلى Technical Debt.
قد تبدو الواجهة احترافية.
وقد يعمل البرنامج بشكل طبيعي أثناء الاختبار.
لكن عندما تبدأ قاعدة البيانات بالنمو أو يزداد Workload، تبدأ المشاكل المعمارية الحقيقية بالظهور.
المشكلة ليست في الذكاء الاصطناعي.
الذكاء الاصطناعي اليوم من أقوى الأدوات المتاحة للمطورين. يمكنه تسريع عملية التطوير، والمساعدة في Debugging، وكتابة Boilerplate Code، وشرح التقنيات الجديدة، وتحسين الإنتاجية.
لكن المشكلة تبدأ عندما يتم بيع نظام تجاري تم بناؤه بالذكاء الاصطناعي من دون وجود المعرفة التقنية اللازمة لفهمه وصيانته و Troubleshooting عند حدوث المشاكل.
Software Engineering ليست منافسة على من يستطيع توليد الكود بشكل أسرع.
القيمة الحقيقية هي في فهم النظام الذي تتحمل مسؤوليته.
الذكاء الاصطناعي يستطيع كتابة الكود.
لكن عندما يحدث Performance Degradation، أو تظهر Production Errors، أو تصبح Database Queries بطيئة، أو تبدأ Software Architecture بالفشل تحت الاستخدام الحقيقي، يجب أن يكون هناك شخص يفهم سبب المشكلة.
وهنا تظهر حقيقة مهمة.
الخبرة في Software Engineering لا يمكن الحصول عليها بمجرد كتابة Prompt.
Artificial IntelligenceAISoftware EngineeringProgrammingPythonDatabaseDatabase IndexingPerformance OptimizationSoftware DevelopmentClinic Management SystemAI Generated CodeSoftware Architecture