6 دقیقه مطالعه

الگوی DevDay ۲۰۲۵ که برایم مهم است: ابزار بهتر، سطح کوچک‌تر

Mehdi Rezaei
Mehdi
نویسنده

تا DevDay ۲۰۲۵ داستان پلتفرم AI از «ببین مدل چه می‌گوید» به «ببین توسعه‌دهنده چه چیزی را می‌تواند قابل اتکا بسازد» جابه‌جا شده بود. این جای سالم‌تری برای اکوسیستم است. چیزی که برایم از خود جاه‌طلبی مهم‌تر بود ابزار بهتر برای گردش کار باریک‌تر و ترکیب‌پذیرتر بود.

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

ابزارها کوچک‌تر شدند، سطح محصول نه لزوماً

در همان رویداد OpenAI بسته AgentKit را روی Responses API و Agents SDK گذاشت. Agent Builder بوم بصری برای ساخت و نسخه‌بندی گردش چندایجنتی بود و آن موقع بتا اعلام شد. ChatKit برای نشاندن تجربه چت داخل محصول خودت بود. Connector Registry جای مدیریت اتصال داده و ابزار بود و عرضه محدودتری داشت. ارزیابی هم جزو همان حلقه معرفی شد. Apps SDK جداگانه اپ را داخل ChatGPT، روی MCP، قابل صدا زدن کرد.

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

اعلام وضعیت دسترسی آن روز را با وضعیت امروز یکی نگیر. بتا و دسترسی محدود ممکن است عوض شده باشد. الگوی طراحی عوض نشده: ابزار بهتر حق بزرگ کردن مسئله را نمی‌دهد.

چرا برای تیم محصول مهم است

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

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

در کار روزانه این یعنی محدوده تیکت، بودجه تأخیر، کش، نقطه پایانی تعاملی، و جرئت برداشتن راه‌حل موقتی. وقتی قابلیت پایدارتر است، حرف محصول و مهندسی کمتر حدسی می‌شود. ترتیب انتشار، مسیر جایگزین، مشاهده، و پشتیبانی جای «نکند اصلاً کار نکند» را می‌گیرند.

سوگیری من: ساده‌تر کن

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

اپ اطراف باید کار سنگین را بردارد. رابط تایپ‌دار، مرز روشن بین کار مدل و منطق اپ، و تحمل کمتر برای پرامپت پهن. اهرم تازه را اول خرج قابلیت اطمینان و وضوح و تناسب محصول کن. تیمی که همان هفته هر آیتم بک‌لاگ را «ایجنت» می‌نامد، معمولاً فضای مسئله را بزرگ کرده چون ابزار بهتر شده، نه چون کاربر کار تازه‌ای خواسته.

بوم بصری برای پیش‌نویس و حرف با آدم غیرمهندس مفید است. اگر تنها نسخه حقیقت همان بوم بماند و کد معادل بازبینی نشود، حادثه را نمی‌شود diff کرد. خروجی را به گردش کوچکی ببر که بشود تست کرد. ChatKit اگر فقط ویترین است و مسیر پشتش تأیید و اعتبار و سقف ندارد، همان جعبه چت قبلی است با پوست تازه.

اشتباه و کار همین هفته

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

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

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

قطعه را بردار، بوم را محصول نکن

Agent Builder برای پیش‌نویس و برای حرف زدن با کسی که کد نمی‌خواند مفید است. خطرش این است که بوم تنها جایی شود که حقیقت گردش کار آن‌جاست. نسخه‌بندی داخل ابزار، اگر معادلش در ریپو نباشد، حادثه را به «کسی نود را تکان داده» تقلیل می‌دهد. اگر مسیر خروجی به Agents SDK را جدی بگیری، بوم پیش‌نویس می‌ماند و کد بازبینی‌شده اجرا می‌شود. اگر آن مسیر را نادیده بگیری، پلتفرم تازه همان قفل داشبورد قبلی است با ظاهر مدرن‌تر.

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

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

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

Share this article

الگوی DevDay ۲۰۲۵ که برایم مهم است: ابزار بهتر، سطح کوچک‌تر | Mehd.ir