صار بناء النسخة الأولى من منتجك رخيصًا، أمّا الإبقاء عليه فلا. ضغطت أدوات البرمجة بالذكاء الاصطناعي عملًا كان يملأ اثني عشر أسبوعًا إلى بضعة أسابيع، وكل مؤسّس نتحدّث إليه لاحظ انخفاض العرض السعري. لكن ما لم يحسب أحد تكلفته تقريبًا هو الطرف الآخر من عمر المنتج: الكود الذي يصل بهذه السرعة أصعب في التغيير لاحقًا بقياس واضح، و«لاحقًا» هي المرحلة التي استهلكت دائمًا معظم ميزانية أي برمجية.
ما الذي صار أرخص فعلًا؟
الجزء الذي يبدأ من الصفر: البناء الأول، على مستودع فارغ، دون نظام قائم يجب احترامه. هذه هي المهمة التي تتفوّق فيها هذه الأدوات، وحجم الأفضلية صار مقيسًا لا مخمّنًا. تضع أبحاث Stanford المستشهد بها في تقرير ROI of AI-assisted Software Development الصادر عن DORA مكاسب الإنتاجية عند ٣٥٪ إلى ٤٠٪ في المهام البسيطة التي تبدأ من الصفر، وعند نحو ١٠٪ في الكود القديم المعقّد (InfoQ، ١١ مايو ٢٠٢٦). ضع الرقمين جنبًا إلى جنب يتّضح شكل المشكلة: الخصم يخصّ الشهر الذي أنت فيه، ويتبخّر نحو ثلاثة أرباعه لحظة أن يصير لمنتجك ماضٍ.
لماذا تكلّف السنة الثانية أكثر ممّا كانت؟
لأن ما يجعل السنة الثانية رخيصة هو إعادة الاستخدام، وهو تحديدًا ما تفقده قواعد الكود المبنيّة بمساعدة الذكاء الاصطناعي. حلّلت GitClear وGitKraken ٦٢٣ مليون تغيير برمجي حقيقي بين ٢٠٢٣ و٢٠٢٦ فوجدت تكرار الكتل البرمجية مرتفعًا ٨١٪، ونقل الأسطر في إعادة الهيكلة منخفضًا ٧٠٪ عن مستويات ٢٠٢٢، وصيانة الكود القديم طويلة الأمد منخفضة ٧٤٪، وبُنى إخفاء الأخطاء مرتفعة ٤٧٪، وترابط الدوال منخفضًا ٣٥٪ — من ٣٤٣ استدعاء لكل ألف سطر متغيّر إلى ٢٢٣ (LeadDev، ٧ يوليو ٢٠٢٦). هذه خمس زوايا لحدث واحد: يُكتب الكود من جديد بدل أن يُعاد استخدامه، فينتهي السلوك الواحد منفّذًا في خمسة مواضع. يعمل. ويُطلق. ثم تغيّر تسعيرتك، فيتعيّن على المواضع الخمسة أن تتفق.
In the long term it starts to get painful when you realize you have five different implementations of the same thing that are similar yet different.
كم تساوي هذه التكلفة بالمال؟
يضع تقرير DORA رقمًا على الطرفين. فهو يُنمذج عائدًا في السنة الأولى يقارب ١١٫٦ مليون دولار مقابل استثمار ٨٫٤ مليون دولار لمؤسسة هندسية من ٥٠٠ شخص — عائد ٣٩٪ باسترداد خلال ثمانية أشهر — بينما تسجّل الحاسبة نفسها ٣٤٤٬٠٠٠ دولار سالبة تكلفةً للتعطّل مع ارتفاع معدّل فشل التغيير من ٥٪ إلى ٦٪ (InfoQ، ١١ مايو ٢٠٢٦). وانتبه لمن يصفه ذلك النموذج: خمسمئة مهندس، وعملية مراجعة، وهامش يكفي لامتصاص نقطة إضافية من معدّل الفشل. أنت لا تملك ذلك. في منتج يديره مؤسّس ومتعاقد واحد، النقطة الإضافية من عدم الاستقرار ليست بندًا في جدول، بل هي أسبوعك.
الفخّ يأتي على هيئة إطلاق ناجح
الأشهر الثلاثة الأولى هي أقوى دليل ستراه على صواب الأسلوب الذي سيرسل لك فاتورته في الشهر الرابع عشر. لا شيء يتعطّل ما دام السطح صغيرًا ولم يلمسه سوى شخص واحد.
ما الذي ينبغي أن تفعله على نحو مختلف قبل أن تبني؟
لا شيء ممّا سبق حجّة للبناء ببطء. إنها حجّة لأن تُنفق جزءًا من الوقت الذي أعاده لك الذكاء الاصطناعي على ما لا يفعله نيابةً عنك: أن تقرّر ما الذي يجب ألّا يفعله المنتج، وأن تُبقي تنفيذًا واحدًا فقط لكل ما يمسّ المال أو الهوية، وأن تتأكّد من قدرة إنسان على شرح النظام دون فتح الأداة التي كتبته. القائمة أدناه هي ما نمرّ عليه قبل تقدير أي بناء، وهي قصيرة عن قصد.
- اختصر قائمة الميزات إلى ما يحتاجه عميل دافع واحد.
- احتفظ بتنفيذ واحد للفوترة وتسجيل الدخول والصلاحيات.
- اشترط مراجعًا بشريًا محدّدًا لكل تغيير يكتبه الذكاء الاصطناعي.
- قِس معدّل فشل التغيير منذ الإصدار الأول.
- خصّص للسنة الثانية ميزانية بحجم ميزانية السنة الأولى.
- امتلك أنت المستودع والنطاق وقاعدة البيانات.
متى تكون النسخة الأولى المبنيّة بالذكاء الاصطناعي القرار الصحيح؟
حين يكون المنتج صغيرًا، واحتمال أن تكون مخطئًا عاليًا، وتنوي التخلّص منه. بناء خام يجيب عن سؤال «هل سيدفع أحد مقابل هذا؟» في ثلاثة أسابيع أثمن من بناء قابل للصيانة يجيب عن السؤال نفسه في ثلاثة أشهر — بشرط أن يتفق الجميع مسبقًا على أن المُسلَّم هو الإجابة لا الكود. الخلل ليس في البناء السريع، بل في أن تبني سريعًا، وتحصل على إجابة بنعم، ثم تدير عملًا حقيقيًا على النموذج الأولي سنتين لمجرّد أنه كان موجودًا. ومن يقول لك إن الذكاء الاصطناعي ألغى سؤال الصيانة إنما يبيعك الأسابيع الثلاثة الأولى.




