لماذا تعرض عليك منصّة بناء التطبيقات بالذكاء الاصطناعي بيانات وهمية أولاً (ولماذا هي الخطوة الصحيحة)

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

تصف تطبيقاً لمنصّة بناء التطبيقات بالذكاء الاصطناعي. وبعد دقيقة تنظر إلى واجهة تعمل — صفحات، وأزرار، وجدول مستخدمين بأسماء مثل “Alex Rivera” و”Priya Shah”، وأسعار لا معنى لها، و”خطّة Pro” لم تطلبها. لا شيء محفوظ. إن أعدت التحميل، فالبيانات لا تزال موجودة. وإن أضفت مستخدماً جديداً، فإنه يختفي.

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

ماذا يعني فعلاً “البيانات الوهمية أولاً”

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

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

هذا معكوس عن الطريقة التي يبدأ بها المطوّر البشري عادةً. المطوّر التقليدي يصمّم قاعدة البيانات أولاً، ثم يبني الشاشات بناءً عليها. منصّات الذكاء الاصطناعي قلبت ذلك، ومعظم الناس لا يلاحظون — هم فقط يرون المستخدمين الوهميين ويفترضون أن المنصّة تتظاهر بالبناء.

لماذا ينجح هذا الترتيب مع الذكاء الاصطناعي بشكل أفضل

جرّبنا بناء قاعدة البيانات والشاشات في الوقت نفسه. لم ينجح. إليك النسخة المختصرة من السبب.

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

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

لهذا تستطيع منصّة بناء التطبيقات بالذكاء الاصطناعي أن تعرض عليك تطبيقاً يبدو منتهياً في دقيقة. لم تتظاهر بالبناء. بل أنجزت ربع البناء — الجزء الذي يقرّر كل شيء آخر — وقاعدة البيانات هي العشر ثوانٍ التالية من العمل، لا العشر ساعات التالية.

ما الذي تبحث عنه حين تكون البيانات الوهمية على الشاشة

هذه هي اللحظة التي يتخطّاها معظم الناس. يرون البيانات النائبة ويبدؤون بطلب تغييرات الألوان. لكن البيانات النائبة سؤال يُطرح عليك. اقرأه.

بضعة أمثلة على ما تنتبه له:

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

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

لماذا يهمّ الترتيب لما يأتي تالياً

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

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

السبب في نجاح هذا أصلاً هو أن كل شيء لاحق — تصميم قاعدة البيانات، والاستعلامات، وحالات التحميل، وحالات الفراغ — قرّره ما رأيته على الشاشة خلال مرحلة البيانات النائبة. إن وافقت على ثلاثة أعمدة، فستحصل على ثلاثة أعمدة. وإن وافقت على حقل “status” بقيمتي “draft” و”sent”، فهذا بالضبط ما تقبله قاعدة البيانات. لا توجد خطوة ترجمة ثانية تشوّه فيها عملية تسليم من مصمّم إلى مطوّر الأمورَ.

اختبار صغير يمكنك إجراؤه

في المرّة القادمة التي تبني فيها شيئاً، جرّب هذا: حين تظهر البيانات النائبة، غيّر شيئاً واحداً فيها قبل أن تطلب أي شيء آخر. أعِد تسمية حقل. أضِف عموداً. استبدل “users” بـ “members”. ثم راقب ما يحدث حين تُبنى قاعدة البيانات.

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

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