قادة الفكر
انفجار واجهات برمجة التطبيقات حقيقي – وطريقة كودينج الفايب تُشعل فتيله
منذ بضع سنوات فقط، كان إنشاء نقطة نهاية جديدة لواجهة برمجة التطبيقات في قاعدة كود ناضجة عملية معقدة. كنت بحاجة إلى التنقل في ملكية نطاقات الكود المتعددة، والتعامل مع الموافقات من المعماريين الغاضبين، وإجراء استعراضات أحياناً تستمر لأسابيع أو أشهر. كانت الاحتكاكات مؤلمة، ولكنها ضمانت أن كل واجهة برمجة تطبيقات جديدة تحمل معها مستوى من التدقيق والذاكرة المؤسسية.
الآن؟ أدوات التطوير التي تعمل بالذكاء الاصطناعي قد أزالت هذه العائق.
يمكن للوكلاء التوليديين تناول كميات هائلة من البيانات السياقية وتوليد تغييرات في الكود عبر مئات الملفات في ثوان. هذا قد دمقرطة القدرة على إنشاء واجهات برمجة التطبيقات – ليس فقط للمهندسين، ولكن حتى للأدوار غير التقنية (صدمة رعب) مثل مديري المنتجات وفرق الدعم الذين قد يشعرون الآن بالتمكين لتحميل التجارب مباشرة إلى الإنتاج.
إنه تحول كبير في من يملك السلطة في عملية تطوير البرمجيات. وليس بالضرورة أمراً سيئاً، خاصة في بيئة أعمال تُفضل السرعة والتكرار. ولكن النتيجة هي حريق من واجهات برمجة التطبيقات المُستخدمة بسرعة: العديد منها تم إطلاقه كـ “تجريبي” أو مخفي خلف أعلام الميزات، ولكن سرعان ما أصبح بنية تحتية أساسية مع تطور احتياجات الأعمال. ما يبدأ كبروتوتايب سريع يصبح تكاملًا رئيسيًا. والآن من المتأخر لفك ذلك.
صعود “كودينج الفايب”
تأتي هذه السلالة الجديدة من واجهات برمجة التطبيقات التي تم إنشاؤها بواسطة الذكاء الاصطناعي غالباً مع قليل من الهياكل أو الوثائق أو الاختبارات. نسمي هذه الظاهرة “كودينج الفايب” – كتابة البرمجيات بناءً على直ور خفيفة، وتحفيز غير دقيق، وsense عام لما “يجب أن يعمل”، بدلاً من فهم عميق للنظم أو أنماط التصميم.
لسوء الحظ، تميل واجهات برمجة التطبيقات التي تم إنشاؤها بهذه الطريقة إلى اتباع اتفاقيات غير متسقة، وlack صلبة، وغالبًا ما تتجاهل المعايير الداخلية المقبولة. أسوأ من ذلك، يمكن أن تُقدم مخاطر أمنية أو تنظيمية خطيرة، خاصة عند الاتصال ببيانات حساسة أو نقاط نهاية مواجهة الخارج. الذكاء الاصطناعي لا يعرف نموذج الحوكمة الخاص بشركتك – أو متطلبات الامتثال الخاصة بك. trừ إذا أخبرته صراحة، لن يكتب معها في الاعتبار.
وتتضاعف المشاكل بسرعة. يتم استخدام الذكاء الاصطناعي بشكل متزايد لإنشاء اختبارات. ولكن عندما يتم اختبار الكود التالف باختبارات توليدية بواسطة الذكاء الاصطناعي، فإن الاختبارات تؤكد فقط السلوك المعيب. يُحجم المطورون عن كتابة اختبارات للكود الذي لم يؤلفوه، ناهيكم عن الكود الذي تم توليده بواسطة الآلات، لذا يُقوم الذكاء الاصطناعي بملء الفراغ. النتيجة؟ حلقة مُرتدة من الكود ذي الجودة المنخفضة والهياكل الشaky.
واجهات برمجة التطبيقات المتنوعة وأزمة الملكية
كل هذا يؤدي إلى طبقة واجهة برمجة التطبيقات المتفرقة داخل معظم المنظمات. تنتشر واجهات برمجة التطبيقات الآن عبر نطاقات متداخلة، وتؤدي وظائف متشابهة بطرق مختلفة قليلاً، وغالبًا ما تفتقر إلى ملكية واضحة. تم كتابة العديد منها بدون فهم عميق للنماذج الأساسية للبيانات، أو حدود الخدمات، أو الميثاق الفريق. لا يُ驚 أن يصبح الصيانة كابوساً. من يملك هذه النقطة النهاية؟ من يمكنه تعديلها؟ من يعرف حتى أنها موجودة؟
تُفضل أدوات الذكاء الاصطناعي الفائدة والسرعة. إذا تركت دون رقابة، سوف تخلق أقصر طريق إلى التسليم، سواء كان ذلك يتوافق مع رؤية الهندسة المعمارية الخاصة بك أم لا. مع مرور الوقت، يمكن أن يؤدي وزن هذا الدين التقني إلى إبطاء التقدم.
بعض الخطوات العملية التي يمكن اتخاذها.
1. الرؤية
الجواب ليس في إبطاء كل شيء أو منع الذكاء الاصطناعي. ذلك ليس واقعياً، وسيترك قيمة هائلة على الطاولة. بدلاً من ذلك، يجب أن نطور كيفية إدارة البرمجيات في عصر التطوير التوليدي.
الخطوة الأولى الأساسية هي الرؤية. لا يمكنك الحكم على ما لا يمكنك رؤيته. المنظمات تحتاج إلى اكتشاف واجهات برمجة التطبيقات المستمرة، وليس الوثائق الثابتة التي تصبح غير محدثة في اللحظة التي يتم نشرها فيها.
أصبحت الأدوات التي تُراقب واجهات برمجة التطبيقات – في وقت التشغيل وفي الكود – ضرورية. بمجرد أن تتمكن من رسم خريطة لمساحة واجهة برمجة التطبيقات في العالم الحقيقي، يمكنك تقييم المخاطر، وتحديد التكرار، وبدء بناء الحوكمة الموثوقة على قمة ذلك.
على نحوironic، يمكن للذكاء الاصطناعي نفسه المساعدة في هذه العملية. استخدام نماذج الذكاء الاصطناعي المُحفزة لتحليل ومراجعة خرائط واجهة برمجة التطبيقات يساعد في الكشف عن الشذوذ، والمخاطر، وفرص التوحيد. هذا هو الذكاء الاصطناعي الذي يساعد في بناء المزيد، ولكن في تنظيف ما لدينا بالفعل.
2. إعداد معايير المنظمة للهندسة والادوات
السيطرة الأفضل على كل من الإخراج والمدخلات إلى أدوات الذكاء الاصطناعي يذهب بعيداً في الحفاظ على مستوى من السيطرة على الكود المُولَّد. الخطوات البسيطة مثل محاذاة واجهات التطوير المتقدمة والطرازات المعتمدة للاستخدام داخل المنظمة سوف تساعد في التباين. هذا也有 فائدة جعل إطلاق نماذج جديدة أسهل وجعلها أكثر احتمالاً أن تكون التحفيزات قابلة للتكرار عبر محطات عمل المهندسين.
أكثر قوة هو محاذاة الملفات من نوع rules.md التي تتطلبها من كودرز الذكاء الاصطناعي لتزويد السياق لعميلهم. كلما كان الكود أكثر تعقيداً، كان من المفيد أن يعمل جميع المهندسين مع نفس المجموعة من القواعد، وتزويد السياق للوكيل الذكاء الاصطناعي حول كيفية توليد الكود الذي يعمل بشكل أفضل مع الهياكل الحالية.
لن نستطيع وضع الجني التوليدي مرة أخرى في الزجاجة. ولكن يمكننا توجيهه، ووضع نطاق الانفجار، واستخدامه لتعزيز الابتكار المسؤول. هذا العمل يبدأ ليس مع الكود، ولكن مع الوضوح.
