مفیدترین چیزی که سال گذشته از تیم‌های درگیر AI دیدم یک ابزار تازه نبود. این بود که فرض را دیر به دیر قایم نمی‌کردند. کار هنوز در جریان بود و کسی می‌توانست بگوید این خروجی را فقط برای این نوع ورودی باور داریم، این ابزار اگر timeout بدهد مسیر دیگری نداریم، و این هزینه را هنوز اندازه نگرفته‌ایم. سرعت ظاهری تیم‌هایی که این حرف را به بعد از انتشار موکول می‌کردند معمولاً همان هفته‌های اول بود.
عادت ساده‌ای است و برای همین راحت دور زده می‌شود. وقتی مدل یک جواب روان می‌دهد، حس تمام‌شدن کار می‌آید. پرامپت را در یک چت شخصی رها می‌کنی، چند نمونه خوب را در اسلاید می‌گذاری، و فرض‌های واقعی می‌مانند در سر کسی که دمو را ساخته. دو هفته بعد نفر بعدی همان مسیر را با داده کمی متفاوت امتحان می‌کند و شکست را به «مدل ضعیف است» نسبت می‌دهد. مدل ممکن است ضعیف باشد. اغلب چیزی که ضعیف است این است که هیچ‌کس فرض را جایی ننوشته که بشود ردش کرد.
فرض پنهان کجا جمع می‌شود
در کار AI فرض معمولاً در چهار جا قایم می‌شود. اول داخل پرامپت است: لحن، قالب، و کاری که مدل نباید بکند، بدون اینکه کسی آن را با بقیه قرارداد محصول یکی کرده باشد. دوم داخل ارزیابی است: اگر فقط مثال‌های خوش‌حال را نگاه کنی، شکاف را نمی‌بینی. سوم داخل هزینه است: یک فراخوان در دمو ارزان به نظر می‌رسد و در مسیر واقعی کاربر، با تکرار و زمینه بلند، شکل دیگری دارد. چهارم داخل تجربه کاربر است: رابط طوری حرف می‌زند که انگار مطمئن است، در حالی که سیستم فقط یک حدس مرتب‌شده برگردانده.
هیچ‌کدام از این‌ها در یک لحظه فاجعه نیست. هر کدام مالیات کوچکی می‌گیرد. مالکیت مبهم می‌شود، اشتباه تکراری می‌ماند، دست‌به‌دست شدن کار بین محصول و مهندسی کند می‌شود، و تصمیم‌هایی که باید در کد یا در سیاست تیم باشند به دانش شفاهی منتقل می‌شوند. بعد از مدتی حادثه پرسر و صدا نیست. محصولی است که اعتماد کردنش سخت‌تر از چیزی است که قابلیت‌ها نشان می‌دهند.
تیم‌هایی که این عادت را داشتند عجله را حذف نکرده بودند. فقط قبول کرده بودند که عدم‌قطعیت اگر نوشته شود قابل‌بازبینی است و اگر نوشته نشود تبدیل به شخصیت سیستم می‌شود. پرامپت را می‌شد در PR دید. جای خالی ارزیابی را می‌شد نشان داد. بحث هزینه به‌جای دعوای سلیقه، بحث روی یک سقف مشخص بود. حتی متن رابط بهتر می‌شد، چون محصول دیگر وانمود نمی‌کرد جایی که شواهد ندارد مطمئن است.
شکل عملی این عادت
لازم نیست برای هر فیچر سند بلند بنویسی. یک یادداشت کوتاه کنار همان تغییری که می‌فرستی کافی است، به شرطی که سه چیز را جدا کند. ورودی که این رفتار برایش طراحی شده. چیزی که عمداً خارج از محدوده است. کاری که سیستم هنگام شکست ابزار، جواب بی‌ربط، یا قطع شدن کاربر باید بکند.
این یادداشت را جایی بگذار که با کد حرکت کند. توضیح در چت تیمی فردا دفن می‌شود. اگر فیچر یک Route Handler در Next.js است، همان کنارش بگو این مسیر چه وضعیتی را در Postgres نگه می‌دارد و کدام خطا را به کاربر برمی‌گرداند. اگر گام بعدی انسان باید نتیجه را تأیید کند، آن تأیید را دکمه تزئینی ندان. بگو بدون تأیید چه چیزی نوشته نمی‌شود.
بازبینی هم عوض می‌شود. به‌جای اینکه فقط بپرسی «این پرامپت قشنگ است؟» می‌پرسی «فرض این پرامپت را کجا می‌توانم غلط ثابت کنم؟» اگر جواب این است که فقط با تماشای دمو، هنوز عادت را برنداشته‌ای. یک مجموعه کوچک از ورودی‌های بد، تکراری، و مرزی بهتر از تعریف بلند از کیفیت است. لازم نیست روز اول پلتفرم ارزیابی بسازی. لازم است دفعه بعد که کسی رفتار را عوض می‌کند، همان نمونه‌ها را دوباره اجرا کند و فرق را ببیند.
هزینه را هم از جنس فرض بنویس. «ارزان است» فرض است. «این مسیر را فقط برای کاربر واردشده و با سقف مشخص فراخوان می‌زنیم» فرضی است که می‌شود رد یا قبول کرد. اگر هنوز نمی‌دانی مسیر شاد چند بار در روز اجرا می‌شود، همان را بنویس: نمی‌دانیم، و برای همین این قابلیت را پشت پرچم کوچک نگه می‌داریم. پنهان کردن ندانستن، تیم را سریع‌تر نشان می‌دهد و تصمیم بعدی را گران‌تر می‌کند.
چه چیزی را فرض حساب نکن
هر تردیدی لایق یک جلسه نیست. اگر مسئله را می‌توانی با یک تست یا یک کوئری در همان روز ببندی، نوشتنش به‌عنوان «فرض باز» فقط تعویق است. فرض مفید چیزی است که امروز با شواهد موجود بسته نمی‌شود و اگر غلط از آب دربیاید طراحی را عوض می‌کند. مثلاً اینکه کاربر حاضر است قبل از دیدن نتیجه صبر کند، یا اینکه داده بازیابی‌شده برای جواب کافی است، یا اینکه خطای ابزار را باید خودکار تکرار کرد نه اینکه به انسان برگرداند.
دام دیگر این است که فرض را آن‌قدر نرم بنویسی که رد نشود. «تجربه باید خوب باشد» فرض مهندسی نیست. «اگر ابزار جستجو خالی برگردد، مدل حق ندارد از دانش عمومی جواب قطعی بسازد» فرض است. دومی را می‌شود با یک مثال نقض کرد. اولی را فقط می‌شود پسندید یا نپسندید.
و این عادت را با بدبینی اشتباه نگیر. هدف این نیست که هر ایده AI را تا حد مرگ مشروط کنی. هدف این است که محدوده باور را هم‌اندازه شواهد نگه داری. تیم‌هایی که همه‌چیز را «بعداً درست می‌کنیم» رها می‌کنند و تیم‌هایی که هیچ چیز را بدون سند کامل شروع نمی‌کنند هر دو گیر می‌کنند. میانه‌اش این است که کار کوچک جلو برود و فرضی که کار به آن تکیه دارد قابل اشاره باشد.
خارج از محصول AI هم همان عادت است
این الگو فقط برای مدل نیست. در نرم‌افزار معمولی هم فرض دیررس درد می‌سازد. فکر می‌کنی این فرم فقط روی دسکتاپ پر می‌شود، این صف همیشه کوتاه است، این webhook را سرویس مقابل حداکثر یک بار می‌فرستد. اگر این‌ها را وقتی کد هنوز کوچک است بنویسی، نفر بعدی به‌جای کشف تصادفی، تصمیم را می‌بیند. اگر ننویسی، حادثه اول همان لحظه‌ای است که فرض غلط بودن خودش را اعلام می‌کند، آن هم در پروداکشن.
فرق تیم‌های مرتب با تیم‌های شلوغ اغلب هوش مدل یا تعداد ابزار نیست. این است که می‌توانی به یک نفر جدید بگویی این قابلیت روی چه باورهایی ایستاده و کدام باور را هنوز نیازموده. اگر آن نفر نتواند از روی ریپو این را بفهمد، سرعت امروز را با کندی ماه بعد تاخت زده‌ای.
عادت را کوچک نگه دار. در هر تغییر، یک فرض را که اگر غلط باشد طراحی عوض می‌شود انتخاب کن و طوری بنویس که کس دیگری بتواند مثال نقض بیاورد. همین برای شروع کافی است. بقیه بلوغ، تکرار همین کار است نه اضافه کردن فرآیند تازه.
پرسش‌های کوتاه
اگر فرض را بنویسم و غلط باشد، وقت تلف نشده؟ نه. رد شدن فرض همان فایده است. فرض نانوشته غلط هم وقت می‌گیرد، فقط دیرتر و گران‌تر.
این کار را فقط برای فیچر AI انجام بدهم؟ هر جا شکست خاموش و تکرارشونده داری. AI فقط جایی است که جواب روان، فرض غلط را دیرتر لو می‌دهد.
یادداشت کوتاه کافی است یا باید قالب رسمی داشته باشیم؟ تا وقتی با کد حرکت می‌کند و می‌شود با مثال نقض ردش کرد، قالب مهم نیست. رسمی شدن وقتی به درد می‌خورد که تیم دیگر یادداشت را پیدا نمی‌کند.