وقتی در تابستان ۲۰۲۵ GPT-5 برای توسعه‌دهنده معرفی شد، بازار از قبل پر از اعلام مدل بود. چیزی که برای من جدا شد تیتر هوش نبود. شکل ابزار اطرافش بود: استفاده از ابزار که به گردش واقعی نزدیک‌تر شده بود، کدنویسی که کمتر به یک جعبه متن شبیه بود، و API که می‌شد دورش برنامه ریخت. اگر این‌ها در محصول ترجمه شوند، پلتفرم عوض شده. اگر فقط در دمو دیده شوند، همان چرخه هیجان است.
عدد بنچمارک را اگر خودت تکرار نکرده‌ای قول محصول ندان. مدل بهتر، قرارداد و داده و مرز هزینه تو را ندارد. قبل از نوشتن نسخه در نقشه راه سه چیز را جدا می‌کنم. چه کاری از چسب دستی به رابط پایدار منتقل شد. چه شکستی قابل دیدن‌تر شد. چه چیزی هنوز کاملاً مال سیستم خودت ماند. این جدا کردن جلوی عوض کردن شتاب پلتفرم با آمادگی محصول را می‌گیرد.
مغز همه‌کاره نیست؛ قطعه خط لوله است
برداشت عملی من این بود که GPT-5 را مغز همه‌کاره محصول ندانم. یک قطعه قوی در خط لوله است. پشت قرارداد تایپ‌دار می‌نشیند. مجموعه ابزارش کوچک و اسم‌دار است. هر فراخوانی گران باید دلیل داشته باشد، نه اینکه چون مدل تازه‌تر است در هر کلیک تکرار شود.
اگر خروجی ساخت‌یافته، هماهنگی ابزار، و کار کدنویسی قابل‌اتکاتر شده باشد، حجم چسب دفاعی دور مدل باید کم شود. آن چسب همان عبارت باقاعده بعد از متن آزاد، همان تلاش دوباره بی‌سقف، و همان پرامپتی است که هم‌زمان نیت کاربر را حدس می‌زند، داده را عوض می‌کند، و شکل پاسخ را هم خودش تعیین می‌کند. وقتی مدل در مرزها قابل‌اتکاتر است، کد عادی باید مالک اعتبار، ذخیره، و مجوز بماند. مدل مالک جمله‌ای نمی‌ماند که «تمام شد».
از نگاه فول‌استک ارزش وقتی واقعی است که شکل اپ عوض شود. شاید مسیری که از ترس قطع شدن هم‌زمان مانده بود، بشود به کار پس‌زمینه شکسته شود. شاید به‌جای یک فراخوانی غول، سه گام با خروجی مشخص داشته باشی. شاید مدل گران فقط جایی بیاید که آن گام واقعاً به آن نیاز دارد. قابلیت خام اگر اصطکاک کاری را که کاربر می‌بیند کم نکند، خبر است نه محصول.
جایی که در کار روزانه دیده می‌شود
این نوع انتشار در جای کم‌زرق‌وبرق ظاهر می‌شود. تیکت را چطور محدوده می‌دهی. بودجه تأخیر را کجا می‌نویسی. چه چیزی را کش می‌کنی. کدام نقطه پایانی تعاملی می‌ماند و کدام می‌رود صف. کدام راه‌حل موقتی را که ماه‌ها در ریپو مانده بالاخره جرئت می‌کنی حذف کنی، چون دیگر برای جبران ضعف رابط لازم نیست.
همکاری محصول و مهندسی هم عوض می‌شود. وقتی قابلیت زیرین قابل توضیح است، حرف از «نمی‌دانم مدل نگه می‌دارد یا نه» می‌رود سمت ترتیب انتشار، مسیر جایگزین، مشاهده‌پذیری، و بار پشتیبانی. تکنولوژی وقتی جای ثابت در استک می‌گیرد که بشود دورش برنامه ریخت، نه وقتی جادویی به نظر برسد.
همان هفته فقط یک مسیر را دست می‌زنم. مسیری که این مدل اصطکاک مشخصی را در آن کم می‌کند. بعد می‌سنجم تجربه، خطا، صدای پشتیبانی، یا پیچیدگی مهندسی واقعاً تکان خورده یا فقط دمو بلندتر شده. اگر هیچ‌کدام را نمی‌توانی ببینی، هنوز دلیلی برای پخش کردن مدل در بقیه صفحه نداری.
اهرم را خرج وضوح کن
اطراف اپ باید سنگین‌تر از مدل کار کند. رابط تایپ‌دار. مرز روشن بین کار مدل و منطق اپ. تحمل کمتر برای پرامپتی که بی‌نسخه در چند فایل پخش شده. اهرم تازه را اول خرج قابلیت اطمینان و وضوح و جور بودن با محصول کن، بعد خرج جاه‌طلبی. اگر مدل بهتر شد و هم‌زمان سطح تغییر را هم بازتر کردی، سود را با ریسک تازه عوض کرده‌ای.
قانون ساده برای من این است: فراخوانی که نمی‌توانی بگویی چرا گران است، نباید در مسیر تعاملی بماند. یا حذفش کن، یا ببرش به کار پس‌زمینه با سقف مشخص، یا خروجی‌اش را کش کن اگر ورودی واقعاً تکرار می‌شود. «مدل جدید به نظر ارزان‌تر می‌رسد» دلیل کافی برای برداشتن سقف نیست. ارزانی را در صورتحساب همان مسیر ببین، نه در پست معرفی.
ابزار را هم فهرست کن، نه اینکه مدل هر تابعی را که در کدبیس پیدا کرد صدا بزند. ابزار خوب یک کار محصولی دارد: خواندن یک سند، ساختن یک پیش‌نویس در وضعیت مشخص، یا برگرداندن فیلدهایی که فرم از قبل می‌شناسد. اگر اسم ابزار را نمی‌توانی در تیکت بنویسی، آن ابزار هنوز طراحی نشده. فقط یک قابلیت مدل است که به کد نشت کرده.
مدل بهتر مجوز شل کردن سیستم نیست
اشتباه رایج این است که مدل توانمندتر را اجازه برای استراحت دادن به سیستم اطرافش بدانی. نیست. مدل بهتر هنوز زمینه را بد می‌خواند، هنوز خروجی را جابه‌جا می‌کند، و هنوز از رابط تمیز، ارزیابی کوچک، تلاش دوباره با سقف، و schema خروجی سود می‌برد. بهبود پلتفرم معماری را خودکار ارتقا نمی‌دهد. گردش کار مبهم یا نرده ضعیف یعنی راه سریع‌تر برای ادامه آشفتگی.
اعتماد کاربر را تکه‌های خسته‌کننده می‌سازند. حالت خطا، زمان پاسخ، لاگ، حسابرسی، و دست دادن به کد عادی. برای یک فیچر محصول، حسابرسی یعنی بشود گفت کدام ورودی رفت، کدام ابزار صدا زده شد، و خروجی ذخیره شد یا دور ریخته شد. رد چت این را عوض نمی‌کند.
فرضی که این انتشار برای من عوض کرد را صریح می‌نویسم: حاضر نیستم یک مدل را به‌خاطر تیتر، بدون قرارداد خروجی و بدون دلیل برای هر فراخوانی، وارد مسیر کاربر کنم. GPT-5 سقف را بالا برد. ارگونومی توسعه‌دهنده است که در طول زمان جمع می‌شود. هوش خام اگر زیر تیتر به مرز و هزینه و مشاهده ترجمه نشود، همان هفته بعد فراموش می‌شود.
یک مسیر، نه بازنویسی محصول
وسوسه بعد از این نوع انتشار این است که «حالا که ابزار بهتر شده، دستیار همه‌کاره بسازیم». این همان جایی است که بخش مفید زیر تیتر را دور می‌ریزی. ابزار بهتر باید یک کار موجود را باریک‌تر کند. استخراج فیلد از یک سند. پیشنهاد اصلاح روی یک محدوده مشخص. پاسخ ساخت‌یافته به یک فرم داخلی. نه یک سطح که هر درخواست را به عامل آزاد تبدیل کند.
ارزیابی را به همان مسیر گره بزن. چند ورودی واقعی که تازه شکست خورده‌اند، بهتر از یک نمودار کلی از کیفیت مدل است. اگر خروجی از schema بیرون زد، شکست محصول است حتی اگر نثر قشنگ باشد. اگر ابزار خارج از فهرست صدا زده شد، شکست طراحی است حتی اگر نتیجه مفید به نظر برسد.
چیزی که سخت ماند را هم بنویس. داده کثیف، مجوز، و هزینه هنوز مال مدل نیست. GPT-5 این سه تا را حل نکرد. فقط جایی که رابط تمیز است، کمتر مجبورت می‌کند دور مدل دیوار دفاعی بسازی. اگر رابط تمیز نیست، نسخه جدید همان دیوار را بلندتر و گران‌تر می‌کند. بخش مفید زیر تیتر همین است: حق داری چسب را کم کنی، به شرطی که مرز را بیشتر از مدل جدی بگیری.