این سؤال به شکل خاصی مطرح میشود. نه بهصورت «آیا باید از یک ابزار ساخت هوش مصنوعی استفاده کنم» — آن یک پست دیگر است، و معمولاً هم فرد دیگری میپرسد. این یکی از زبان کسی میآید که شش، هشت، دوازده ماه در دل پروژهای است که واقعاً کار میکند. کاربران واقعی، درآمد واقعی، و این احساس مزاحم که در حال رسیدن به دیواری هستند که ابزار نمیتواند از آن عبور کند. در ادامه، سؤالاتی که واقعاً از من پرسیده میشود آمده، تقریباً به همان ترتیبی که پرسیده میشوند.
آیا واقعاً میتوان از یک ابزار ساخت هوش مصنوعی فراتر رفت، یا این فقط داستانی است که افراد به خودشان میگویند؟
هر دو اتفاق میافتند، و از بیرون یکسان به نظر میرسند. رشد واقعی فراتر از حد، مشخص است: نیاز دارید به یک فرایند پرداخت با تسویه تقسیمشده بین سه طرف، یا یک گردشکار انطباق (compliance) با ردپای حسابرسی (audit trail) که یک نهاد نظارتی واقعاً آن را بخواند، یا کاری محاسباتی غیرمعمول انجام میدهید — پردازش ویدئوی بلادرنگ، شبیهسازی فیزیکی، یا یک مدل پیشنهاددهنده سفارشی که روی دادههای خودتان آموزش دیده. اینها مسائل معماری هستند، نه مسائل پرامپت.
نسخه دروغین، پرامپتی است که هنوز ننوشتهاید. «این ابزار نمیتواند اسکرول بینهایت با صفحهبندی مبتنی بر cursor انجام دهد» معمولاً یعنی هیچکس اسکرول بینهایت با صفحهبندی cursor را توصیف نکرده — یعنی کسی یک بار «صفحهبندی اضافه کن» را امتحان کرده، نتیجه را دوست نداشته، و بیصدا آن را بهجای یک تلاش دوم، بهعنوان یک محدودیت ثبت کرده. حدس میزنم سهچهارم گفتگوهای «به سقف رسیدهام» با یک پرامپت بهتر حل میشوند، نه با بازنویسی کامل.
چطور بفهمم واقعاً کدام حالت را دارم؟
| حس رشد از حد | معمولاً همین است | معمولاً این نیست |
|---|---|---|
| «نمیتواند X را انجام دهد» | X به زیرساختی نیاز دارد که پلتفرم اصلاً در اختیار نمیگذارد (پروتکل TCP سفارشی، کار آموزش روی GPU، جریان دادهای با حسابرسی HIPAA) | X با جزئیات کافی توصیف نشده، یا یکجا درخواست شده بهجای تکرار و بهبود پلهای |
| «در مقیاس بزرگ خیلی کند است» | از نقطهای گذشتهاید که کد تولیدشده و دستههای میزبانی استاندارد زیر بار واقعی تاب نمیآورند | درباره باری که هنوز ندارید فقط حدس میزنید |
| «به کنترلی نیاز دارم که ندارم» | باید مستقیماً و خارج از چرخه چت، کد تولیدشده را برای یک اصلاح خاص با دست ویرایش کنید | هنوز درخواست اصلاح را با زمینه بیشتر برای بار دوم امتحان نکردهاید |
| «تیمم باید به کد دسترسی داشته باشد» | مهندسانی استخدام کردهاید و آنها به یک گردشکار git معمول نیاز دارند | شما تنها کسی هستید که آن را لمس میکند و فقط میخواهید احساس «واقعیتر» بودن به آن داشته باشید |
در واقع، نشانه اصلی این است که آیا میتوانید یک نیاز فنی مشخص را نام ببرید یا فقط یک احساس را توصیف میکنید. «نیاز دارم به تلاش مجدد وبهوک با backoff نمایی و یک صف dead-letter» یک نیاز است. «فقط حس میکنم الان باید چیز خودم را داشته باشم» یک احساس است، و احساسات معمولاً با نوشتن یک پرامپت بهتر حل میشوند، نه با مهاجرت.
اگر تصمیم بگیرم بروم، واقعاً چه چیزی مالکش هستم؟
این همان سؤالی است که بیشترین نگرانی را ایجاد میکند، و در عین حال واضحترین پاسخ را هم دارد: شما مالک هر چیزی هستید که روی دامنه خودتان مستقر شده، بهعلاوه دادههایتان. اگر به دامنهای که خودتان کنترلش میکنید منتشر کردهاید — از طریق SFTP، از طریق ثبتکننده خودتان — فایلهای روی آن سرور مال شماست، همانطور که هر کد روی هر سروری که اجاره کرده باشید مال شماست. هیچکس آن را پس نمیگیرد. اتصالات Search Console و Analytics شما حسابهای گوگلی هستند که خودتان مجوزشان را دادهاید؛ قطع اتصال ابزار ساخت، به دادههای تاریخی موجود در سیستمهای گوگل دست نمیزند، چون این دادهها از ابتدا هم مال ابزار ساخت نبودهاند. این حساب خودتان است، صرفاً فیلترشده.
چیزی که بهطور خودکار به دست نمیآورید تاریخچه چت، اسناد برنامه، سوابق تأیید، و مدل داخلی ابزار ساخت از پروژه شماست — همان چیزی که تکرار سریع را ممکن میکرد. این بخش است که واقعاً به پلتفرم گره خورده، و همان بخشی است که بیشتر افراد تا زمانی که بخواهند آن زمینه را با ابزاری جدید دستی بازسازی کنند، ارزشش را دستکم میگیرند.
آیا قفلشدگی (lock-in) وجود دارد، یا بیشازحد محتاطم؟
کاملاً بستگی دارد به منظورتان از قفلشدگی. اگر منظورتان این است که «آیا میتوانند سایتم را گروگان بگیرند» — نه، نه اگر از روز اول روی دامنه خودتان مستقر شده باشید، که دقیقاً همین دلیل اصلی مالکیت دامنه بهجای اجرای دائمی روی یک زیردامنه است. اگر منظورتان این است که «آیا ترک کردن، ارزش انباشته ماهها تکرار و بهبود را از من میگیرد» — بله، و این واقعاً قفلشدگی نیست، بلکه همان هزینه تحمیلشدهای است که با تغییر از هر ابزاری که برایش وقت گذاشتهاید، متوجه میشوید. هر ویرایشگر، هر فریمورک، هر CRM همین ویژگی را دارد. سؤال این نیست که آیا هزینههای جابجایی وجود دارند یا نه. سؤال این است که آیا ساختگیاند (شرایط قرارداد، گروگانگیری داده) یا طبیعی (شما در جایی مومنتوم ساختهاید و جابجایی یعنی دوبارهسازی آن). قفلشدگی ساختگی یک علامت هشدار است. هزینه جابجایی طبیعی فقط همان معنای «در یک ابزار مسلط شدن» است.
واقعاً کِی منطقی است که بهجای نوشتن یک پرامپت دیگر، یک مهندس استخدام کنیم؟
سه حالت، به ترتیب فراوانی که میبینم:
- به دلایل انطباق (compliance) به یک فرد حاضر در جریان کار نیاز دارید — برخی چارچوبهای نظارتی یک مهندس پاسخگو با نام مشخص میخواهند، نه یک ردپای حسابرسی از کامیتهای تولیدشده با هوش مصنوعی، هرقدر هم که آن کامیتها خوب باشند.
- با یک مسئله فنی واقعاً نو مواجه شدهاید — نه «یک بازارگاه بساز»، که مسیر شناختهشدهای است، بلکه چیزی مثل یک الگوریتم تطبیق سفارشی که روی دادههای اختصاصی تنظیم شده، جایی که ارزش در همان نوآوری است، و به کسی نیاز دارید که بتواند درباره ریاضیات خاص آن استدلال کند، نه فقط نتیجه دلخواه را توصیف کند.
- از مقیاسی گذشتهاید که «کد تولیدشدهای که کار میکند» و «کد تولیدشدهای که برای شکل دقیق ترافیک شما پروفایل و تنظیم شده» از هم جدا میشوند — این واقعی است، اما دورتر از آنچه بیشتر افراد فکر میکنند. بسیاری از اپلیکیشنهایی که حس «خیلی بزرگ برای ابزار ساخت» میدهند، در حد چند دههزار کاربر فعال ماهانه هستند، که واقعاً برای کد تولیدشده با ساختار مناسب مسئله مقیاس نیست.
توجه کنید چیزی در این فهرست نیست: «میخواهم کنترل بیشتری داشته باشم.» خواستن کنترل بیشتر یک ترجیح است، نه یک نیاز، و ارزش دارد با خودتان صادق باشید که کدام یک را احساس میکنید.
اگر یک مهندس بیاورم، باید کد ساختهشده با هوش مصنوعی را توسعه دهد یا از صفر شروع کنیم؟
تقریباً همیشه: توسعهاش دهید. بیشتر از آنچه درست پیش رفته، دیدهام که تیمها بهطور پیشفرض میگویند «از صفر بازنویسی کنیم چون تولید هوش مصنوعی است، پس باید دورانداختنی باشد»، و این اشتباه از آب درآمده. این یک پیشداوری است، نه یک ارزیابی. اول کد واقعی را بخوانید. اگر ساختار معقولی دارد — و ابزار ساختی که پیش از انتشار، برنامه و مراحل تأیید خودش را نشان میدهد معمولاً کدی تولید میکند که منسجم خوانده میشود، چون یک برنامه منسجم، کد منسجم تولید میکند — سریعترین مسیر معمولاً یک مهندس عادی است که یک پایگاه کد عادی را به دست میگیرد. بازنویسی کامل گزینه پرهزینه است؛ آن را برای زمانی نگه دارید که کد واقعاً نمیتواند از آنچه در پیش است پشتیبانی کند، نه بهخاطر اینکه از کجا آمده است.
واقعیترین الگوی شکست که افراد شش ماه پس از «فارغالتحصیلی» از ابزار ساخت با آن مواجه میشوند چیست؟
حلقه تکرار را از دست میدهند و جایگزینش نمیکنند. ارزش واقعی ابزار ساخت برای بیشتر افراد هرگز فقط «کد مینویسد» نبوده — خیلی چیزها کد مینویسند. ارزشش این بود: پیشنهاد بده ← بررسی کن ← مستقر کن ← اندازهگیری کن، در یک چرخه تنگ، بدون اینکه انسان در هر مرحله گرهگاه باشد. تیمهایی که میروند و چرخه معادلی بازسازی نمیکنند — CI، محیط آزمایشی، مانیتورینگ، مسیر سریع از ایده تا انتشار — در نهایت کندتر از روز اول استفاده از ابزار ساخت، محصول ارائه میدهند، و معمولاً این را برای چند ماه متوجه نمیشوند چون پایگاه کد همچنان «واقعیتر» حس میشود. واقعی و سریع یک ویژگی نیستند. اگر میخواهید از ابزار فراتر بروید، به سمت فرایندی بروید که حداقل به همان تنگی فرایندی باشد که ترک میکنید، نه فقط به سمت فایلهای بیشتری که مالکشان هستید.
نسخه صادقانه «از آن فراتر رفتیم» معمولاً این است: «به یک نیاز مشخص و قابل نامبردن رسیدیم که این ابزار پوشش نمیدهد.» اگر نمیتوانید آن نیاز را نام ببرید، احتمالاً از هیچ چیزی فراتر نرفتهاید — فقط تکرار و بهبود را متوقف کردهاید.
