ساخت اپلیکیشن با هوش مصنوعی

هوش مصنوعی کدام قسمت اپلیکیشن را واقعا می سازد؟

جوابی که مدل ها را عادلانه قضاوت می کند یک عدد لازم دارد و ما آن را از یکی از محصول های خودمان برداشتیم، چون تنها پروژه ای است که می توانیم تا آخرین خطش بشماریم.

افزونه بازار کار ما، rgb-freelance، سه پوشه دارد. پوشه صفحه ها ۳۲۳۱ خط است، پوشه منطق پشت صفحه ها ۱۱۵۹۷ خط، و ظاهر یعنی CSS و جاوااسکریپت ۳۱۳۵ خط. جمعا ۱۷۹۶۳ خط، که در آن سهم صفحه ها کمی زیر یک پنجم است. این یک اپ موبایل نیست و ادعایش را هم نداریم؛ یک محصول وب با کاربر و پروژه و پیام و فایل است، و شکل تقسیمش همان شکلی است که در اپ موبایل هم دیده می شود.

حالا نقشه را روی مدل ها بگذارید. آن یک پنجم، یعنی صفحه ها، همان چیزی است که مدل ها امروز واقعا خوب می سازند: فرم، فهرست، حالت خالی، چیدمان واکنشگرا. آن دو سوم وسط، یعنی اینکه چه کسی چه چیزی را می بیند و پول کجا حساب می شود و وقتی سرور جواب نداد چه اتفاقی می افتد، همان جایی است که کد تولید شده معمولا کامل به نظر می رسد و نیست.

پس ادعای «اپ را با هوش مصنوعی بساز» نه دروغ است و نه کامل. دقیق ترش این است: سریع ترین بخش را سریع تر می کند. اگر انتظارتان همین باشد، سود واقعی می برید؛ اگر انتظارتان محصول تمام شده باشد، وقتی کشفش می کنید که کاربر واقعی دارید.

سرعت نمونه سازی: چیزی که واقعا عوض شده

قبل از فهرست خطرها، یک اعتراف که کم گفته می شود: چیزی اینجا واقعا عوض شده و کوچک شمردنش همان قدر بی دقتی است که بزرگ کردنش.

کاری که سخت ترین بخش شروع یک محصول بود، یعنی رساندن ایده به چیزی که بشود دستش گرفت و به کسی نشان داد، حالا در همان جلسه ممکن است. سه صفحه با داده الکی، یک جریان ورود، و یک فهرست که اسکرول می شود. برای اپ این حتی مهم تر از وب است، چون آدم ها روی گوشی درباره یک ایده جور دیگری قضاوت می کنند تا روی کاغذ.

ارزش واقعی این سرعت جایی است که کمتر به آن فکر می شود: هزینه دور ریختن. وقتی یک نسخه اولیه در نیم روز ساخته می شود، بی خیال شدنش هم آسان است. تیم هایی که ماه ها روی نسخه اول کار می کنند، به همان اندازه به آن وابسته می شوند و ایده بد را دیرتر رها می کنند. این تنها جایی است که کد ارزان واقعا یک مزیت راهبردی است و نه فقط صرفه جویی.

و مرز این حرف را هم صریح بگوییم، چون همه جا با هم قاطی می شود: نمونه، محصول نیست. نمونه ای که کار می کند هنوز نه کاربر واقعی دیده، نه شبکه ضعیف، نه کسی که عمدا ورودی غلط می فرستد. فاصله بین این دو همان دو سوم بخش قبلی است، و هیچ مدلی آن را برایتان کوتاه نمی کند. اگر همین بحث را از طرف وب دیده اید، وایب کدینگ؛ مزایا و خطرها همین موضع را با جزئیات بیشتری روی کد گرفته.

چهار چیزی که در اپ ساخته شده با مدل خراب می شود

این چهار تا از روی حدس نوشته نشده اند؛ هر کدام یک منبع دارند و منبع هر کدام حرف خود همان شرکتی است که ابزارش را می فروشد.

یک، کلید داخل اپ. اینجا اول باید یک بدفهمی رایج را کنار گذاشت: هر کلیدی داخل اپ خطر نیست. صفحه خود گوگل درباره کلیدهای فایربیس می نویسد که آنها «به طور ذاتی عمومی» هستند و فقط پروژه و اپ شما را معرفی می کنند، و اگر تنظیمات درست باشد لازم نیست مثل راز با آنها رفتار شود و گذاشتنشان در کد ایمن است. ولی همان صفحه یک استثنای صریح دارد که دقیقا همان چیزی است که در اپ های تولید شده دیده می شود: هیچ وقت ای پی آی جمینای را در فهرست مجاز یک کلید عمومی نگذارید. یعنی مدلی که کلید هوش مصنوعی را کنار کلید فایربیس داخل اپ می گذارد، در ظاهر همان کار را کرده و در عمل حساب شما را باز گذاشته.

دو، دسترسی که نوشته نشده. کد تولید شده معمولا مسیر خوشبینانه را کامل می سازد و مسیر بدبینانه را نه. فهرست OWASP Mobile Top 10 خانه اول را به «استفاده نادرست از اطلاعات هویتی» داده و شیوع آن را رایج، تشخیصش را آسان و اثرش را شدید ارزیابی کرده؛ یعنی این کلاس خطا هم زیاد اتفاق می افتد و هم راحت پیدا می شود، که ترکیب بدی است. اولین سوالی که باید از کد تولید شده بپرسید این است: کجا چک شده که این کاربر اجازه این کار را دارد؟

سه، کدی که ماه بعد قابل نگهداری نیست. این خطر برخلاف دو تای قبلی امنیتی نیست و به همین دلیل دیرتر معلوم می شود. مشکل کد بد نیست، کد بی صاحب است: چهار تکه از چهار جواب مختلف که هر کدام الگوی خودشان را دارند و هیچ کس نمی داند کدامشان چرا آنجاست. راه حل ساده ای دارد که هیچ ربطی به هوش مصنوعی ندارد: قبل از قبول هر تکه کد، بتوانید در یک جمله بگویید چه می کند.

چهار، مجوز. اینجا هم واقعیت از هر دو روایت رایج معتدل تر است. مستندات گیتهاب درباره کوپایلت می نویسد که پیشنهادها با کد عمومی مقایسه می شوند و اگر تطابقی پیدا شود، آدرس فایل ها و نام مجوزی که بر آن کد حاکم است ثبت می شود تا خودتان تصمیم بگیرید. همان صفحه می گوید این تطابق ها معمولا در کمتر از یک درصد پیشنهادها رخ می دهد، و دو نکته مهم تر: این بررسی فقط برای پیشنهادهای درون ویرایشگر که پذیرفته شده اند انجام می شود، و کدی که خودتان نوشته اید یا پیشنهادی که تغییرش داده اید اصلا بررسی نمی شود. پس ابزار سنجش وجود دارد، ولی محدود است و روشن بودنش یک تنظیم است نه یک پیش فرض جهانی.

ترتیب درست: اول مشخصات، بعد کد

هر چهار مورد بالا یک ریشه مشترک دارند و آن ریشه فنی نیست: از مدل خواسته شده کد بنویسد در حالی که هنوز کسی تصمیم ها را نگرفته بود. مدل تصمیم نمی گیرد، جای خالی را پر می کند، و جای خالی را با متعارف ترین چیزی که دیده پر می کند.

پس ترتیب را عوض کنید. سه پاس، به همین ترتیب، و هیچ کدام را جا نیندازید.

پاس اول مشخصات است و هیچ کدی در آن نیست: فهرست قابلیت ها به زبان ساده، شکل داده، و اینکه هر کسی چه چیزی را می بیند و چه چیزی را عوض می کند. اگر بک اند اپلیکیشن چیست را خوانده باشید، این همان جدول دسترسی است و جایش دقیقا اینجاست، قبل از تولید.

پاس دوم تولید است و ورودی اش خروجی پاس اول است، نه توضیح شفاهی شما. تفاوت این دو زیاد است: وقتی فهرست قابلیت ها و شکل داده جلوی مدل باشد، چیزی برای حدس زدن نمانده و کدی که می سازد قابل مقایسه با یک سند است.

پاس سوم بازبینی است و آن را نباید همان جلسه ای انجام داد که کد تولید شده. یک پاس جداگانه با یک پرسش مشخص: این کد کجا فرض کرده که کاربر راست می گوید. این پاس همان چیزی است که در بخش بعد به شکل نسخه آمده.

یک قاعده که در هر سه پاس صادق است و ساده ترین آنهاست: هر کد تولید شده ای که خودتان نمی توانید در یک جمله توضیحش بدهید، وارد پروژه نشود. نه به این دلیل که حتما غلط است، به این دلیل که وقتی خراب شود کسی نمی داند از کجا شروع کند. کدنویسی با هوش مصنوعی همین قاعده را از سمت زبان برنامه نویسی باز کرده.