لماذا سيحتاج MVP المبني بالذكاء الاصطناعي لإعادة بناء وكيف تتجنب ذلك المصير

، مدير تقني سابق، وضح مؤخراً لماذا يحدث هذا. يصف كيف تسلم أدوات برمجة الذكاء الاصطناعي كوداً بسرعة ملحوظة لكن دون الفهم الذي يبنيه المطورون البشريون بينما يعملون. "معظم الوقت سيُنفق على فهم بعد الحدث لما كود كتبه الذكاء الاصطناعي،" يكتب. ادعاءات التسويق بتطوير أسرع بـ10x تصطدم بالواقع، حيث مكاسب الإنتاجية المقاسة أقرب لـ10%.

هذه الفجوة بين الوعد والواقع ليست فشل الأدوات. إنما سوء فهم أساسي لما الأدوات جيدة فيه وما ليست. فهم هذا التمييز أساسي لأي مؤسس يبني بمساعدة ذكاء اصطناعي اليوم.

ما الفرق بين Vibe Coding والتطوير المستدام؟

Loy يقدم تمييزاً مفيداً بين نهجين للتطوير المساعد بالذكاء الاصطناعي. "Vibe coding" يعني التحرك بسرعة، ترك الذكاء الاصطناعي يولد كوداً بإشراف ضئيل، تحديد أولوية سرعة التسليم على الفهم. "الهندسة المقادة بالذكاء الاصطناعي" تعني توظيف أفضل الممارسات، ضمان فهم البشر ما ينتجه الذكاء الاصطناعي، التحرك بتأنٍ لإبقاء التطوير مستداماً.

للمشاريع البسيطة ونماذج يمكن التخلص منها، vibe coding يعمل بجمال. الذكاء الاصطناعي يولد كوداً، الكود يعمل، المنتج يُشحن. البساطة تعني لا يوجد تعقيد متراكم لإدارته.

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

عندما احتاج Electrosmart للانتقال من فوضى جداول البيانات لمراجحة آلية، القرارات المعمارية التي اتخذناها مبكراً حددت إذا كان النظام يستطيع التوسع. أدوات الذكاء الاصطناعي استطاعت توليد خوارزميات تسعير بسرعة، لكنها لم تستطع تصميم أنظمة ستتعامل مع حجوم معاملات تتنامى أو تضيف استراتيجيات تسعير جديدة لاحقاً بأمان. مدير المنتج الأول Paweł Dudek تأمل: "Digital Bunch لم تبنِ لنا برمجية فقط؛ غيرت كيف نفكر في عملنا."

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

كيف تعرف إذا اصطدمت أو تقترب من جدار vibe coding؟ بعد مشاهدة عشرات المشاريع تعاني مع هذا، حددنا أعراض مميزة.

لماذا تصبح الجداول الزمنية غير قابلة للتنبؤ؟

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

ماذا يعني الخوف من قاعدة الكود؟

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

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

لماذا تصبح أدوات الذكاء الاصطناعي أقل مساعدة مع الوقت؟

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

ما يسبب شلل تصحيح الأخطاء؟

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

كيف تضاعف الحلول المؤقتة المشاكل؟

العرض الخامس هو حلول مؤقتة تتصاعد. بدلاً من إصلاح قضايا أساسية، الفريق بدأ بالالتفاف حولها. حالات خاصة تتكاثر. التكوين يصبح معقداً. كل حل مؤقت يجعل المشكلة التالية أصعب للحل بشكل صحيح.

إذا عدة من هذه الأعراض تبدو مألوفة، على الأرجح اصطدمت بالجدار. السؤال يصبح: ماذا الآن؟

لفهم الطريق للأمام، يساعد أن تفهم لماذا تنتج أدوات الذكاء الاصطناعي هذه النتيجة بموثوقية.

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

كيف يختلف الفهم البشري عن سياق الذكاء الاصطناعي؟

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

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

عندما احتاج C&R Software لتحديث 40 عاماً من الأنظمة القديمة، التحدي لم يكن توليد كود جديد. كان فهم 40 عاماً من منطق العمل، معرفة المجال، وقرارات معمارية مدمجة في ذلك الإرث. الرئيس التنفيذي Ed Wallen لاحظ: "Digital Bunch فهمت أن تحدينا لم يكن التكنولوجيا. كان شرحها." أدوات الذكاء الاصطناعي لا تستطيع بناء ذلك الفهم من خلال السياق وحده.

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

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

متى تكون المعالجة منطقية؟

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

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

متى تكون إعادة البناء المسار الأفضل؟

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

إشارات قليلة تقترح إعادة البناء أفضل. إذا وجدت نفسك تقول "لا نستطيع عمل X بسبب كيف يعمل Y" بشكل متكرر، حيث X شيء يحتاجه منتجك وY قرار معماري أساسي، ذلك يقترح مشاكل معمارية. إذا كانت تكلفة كل ميزة جديدة يهيمن عليها الالتفاف حول بنية موجودة بدلاً من بناء الميزة نفسها، ذلك يقترح أن البنية ضارة بنشاط.

عندما احتاج Premier Construction Software لتحول منصة، قيّمنا المعالجة مقابل إعادة البناء. القرار بإعادة بناء أجزاء بينما نحفظ منطق المجال يعني استطعنا التسليم في ثلاثة أشهر ما أخذ سنوات أصلاً. الرئيس التنفيذي Karoline Lapko تأملت: "نحن سعداء جداً بالنتائج. Digital Bunch مبدعون، مستجيبون، منخرطون ومتحمسون لما يقومون به."

ما القيمة التي يوفرها الكود القديم ما زال؟

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

سواء تعالج أو تعيد البناء، الطريق للأمام يتطلب شيئاً افتقره vibe coding: بنية متأنية وفهم مستدام.

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

ما الممارسات المعمارية التي تمنع مشاكل مستقبلية؟

لقاعدة كود بالفعل في مشكلة، أو لمنع المشكلة في مشاريع جديدة، ممارسات عدة أساسية.

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

عملية الاستراتيجية الرقمية لدينا تبدأ هنا لأن القرارات المعمارية لها رافعة 10x إلى 100x على سرعة التنفيذ.

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

كيف يجب أن تستخدم أدوات الذكاء الاصطناعي بفعالية أكثر؟

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

عندما احتاجت Valley Insurance Associates لـCRM المخصص، الذكاء الاصطناعي كان يستطيع توليد برمجية تأمين عامة بسرعة. لكن القيمة جاءت من بنية حذرة فهمت متطلبات امتثالهم المحددة وسير عمل إيداعاتهم. تأمل الرئيس التنفيذي Gina Doyle، "أفضل استثمار قمنا به،" جاء من أنظمة مستدامة، ليس توليد كود سريع.

للمؤسسين الذين لم يصطدموا بالجدار بعد، أو يبدأون مشاريع جديدة، الدرس واضح: vibe coding جيد للنماذج الأولية لكن خطر للمنتجات.

ما الغرض الذي يخدمه كل منهما؟

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

منتج موجود لخدمة المستخدمين عبر الوقت. سيحتاج ميزات جديدة، إصلاحات أخطاء، تحسينات أداء، تحديثات أمان. سيحتاج للتطور بينما تتعلم أكثر عن المستخدمين والسوق. الاستدامة تهم لأنك ستعيش مع قاعدة الكود لسنوات.

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

عندما أطلقت Opus Platform منصة توظيفها، الأساس المعماري كان عليه دعم التنامي من اليوم الأول. الرئيس التنفيذي Naif Alwehaiby لاحظ: "Digital Bunch أنجزت في ثلاثة أشهر ما كنا نعاني معه لسنوات." ذلك جاء من معاملتها كمنتج، ليس نموذج أولي، من البداية.

ما الممارسات التي تصنع الفرق؟

الحل هو أن تكون صادقاً مع نفسك حول أي مرحلة أنت فيها. إذا كنت تصنع نموذجاً أولياً، vibe code بحرية وخطط لرميه. إذا كنت تبني منتجاً، استثمر في البنية، التوثيق، والاختبار من البداية. التباطؤ الأولي يدفع أرباحاً بينما يتنامى التعقيد.

Loy يقترح ممارسات محددة: مواصفات وتوثيق قبل البرمجة، تصميم معياري للتحكم بنطاق السياق، تطوير موجه بالاختبارات لتوجيه التنفيذ، معايير برمجة مفروضة من خلال هندسة السياق. هذه الممارسات تشعر أبطأ من vibe coding لأنها أبطأ. إنها أيضاً الفرق بين منتج يتوسع وواحد ينهار تحت وزنه.

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

متى لا تساعد إضافة قدرة أكثر؟

إذا كانت مشكلتك قدرة، إضافة أشخاص أكثر سيعملون بنفس الطريقة لن تساعد. مهندسون أكثر يقومون بـvibe coding سينتجون كود متشابك أكثر أسرع. ستصطدم بالجدار أسرع، ليس لاحقاً.

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

ما الأسئلة التي تكشف جودة شريك التطوير؟

السؤال الرئيسي لطرحه على أي شريك تطوير محتمل هو كيف يعملون، ليس فقط ماذا بنوا. هل يؤكدون على التخطيط والبنية من خلال أبحاث تجربة المستخدم والتخطيط الاستراتيجي، أم يفتخرون بالتحرك بسرعة؟ هل يوثقون القرارات وينشئون أنماط، أم يكتشفون الأشياء بينما يمضون؟

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

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

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

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

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