نمودارهایی که این سالها توسط تیمهای مهندسی نمایش داده میشود یک نکته را نشان میدهد: فعالسازی حسابها و مصرف توکنها افزایش یافته، اما روش واقعی ساخت نرمافزار تغییر نکرده است. این فاصله میان «مصرف» و «پذیرش» مشکل اصلی است.
چرا معیارها فریبندهاند
معیارهای رایج عملاً فقط نشاندهندهٔ مصرفاند. هزینهٔ توکن میگوید کسی متنی وارد کرده است؛ تعداد درخواستهای ادغام (Pull Request) نشان میدهد کامیتها به مخزن ارسال شدهاند؛ درصد کد «تولیدشده با هوش مصنوعی» یعنی پیشنهاد خودکار پذیرفته شده است. هیچکدام تضمین نمیکنند خروجی تیم بهتر یا باکیفیتتر شده باشد.
قانون گودهارت میگوید وقتی یک عدد تبدیل به هدف میشود، دیگر نشانگر واقعیت نیست و صرفاً رفتارها را شکل میدهد. نمونهٔ عملی آن را در تستهای پوشش کد دیدهایم: پوشش خطی بالا اما اعتبارسنجی واقعی پایین.
سؤال بهتر برای سنجش پذیرش
بهجای افزایش «نشانههای مصرف»، پرسش مناسب این است: «اگر ابزارهای مبتنی بر هوش مصنوعی فردا حذف شوند، چه چیزی واقعاً از کار میافتد؟» اگر پاسخ صادقانه «هیچچیز حیاتی، فقط کمی ناراحتی» باشد، یعنی پذیرش واقعی وجود ندارد؛ تنها مصرف و اشتراک وجود دارد.
سه سنخ که اغلب بهاشتباه «پذیرش» خوانده میشوند
۱. تغییر در حلقهٔ کاری فردی
یک نفر برای کارهای شخصی از مدل استفاده میکند—مثلاً برای نوشتن پیام کامیت یا گرفتن خلاصهٔ سریع از کد. مفید و سریع است، اما ناپایدار؛ زیر فشار یا در غیاب آن فرد، معمولاً به شیوهٔ قبلی بازمیگردند.
۲. واگذاری دائم یک کار تکراری
یک گردشکار یا اسکریپت کار مشخصی را انجام میدهد و مهندس فقط خروجی را بررسی میکند. این مدل کارایی ایجاد میکند اما با تغییر مالک یا کنار گذاشته شدن صاحبِ فرایند، عموماً ناپدید میشود.
۳. تغییر رسمی در فرایند تیمی
تیم تصمیم میگیرد مرحلهای از جریان کاری را به شکل جدید اجرا کند، آن را مستندسازی و نسخهبندی میکند و الگو مستقل از افراد حفظ میشود. تنها این نوع پذیرش است که با تغییر نیروی انسانی و فشارهای زمانی پایدار میماند.
اکثر سازمانها مورد اول را جشن میگیرند، گاهی دومی را تجربه میکنند و کمتر به سوم میرسند. رسیدن به نوع سوم نیازمند تغییر هنجارها، نه صرفاً خرید مجوز یا ابزار است.
نمونهٔ عملی: مدیریت پرامپتها
تیم Webflow پرامپتها را از فایلهای شخصی و پراکنده خارج کرد و بهعنوان دارایی مشترک، نسخهبندیشده و دارای مالک در مخزن قرار داد. برای هر پرامپت زمان استفاده و قواعد بازبینی تعریف شد. این کار نیازمند ابزار خاصی نبود؛ نیازمند تصمیم دربارهٔ ارزش نگهداری و مالکیت بود. برای آشنایی بیشتر رجوع کنید به صفحهٔ مهندسی پرامپت.
چرا «عاملها» گاهی اثر معکوس دارند
عاملها یا ابزارهایی که کارها را خودکار شروع میکنند، میتوانند از صفر تا پیشنویس را سریعتر جلو ببرند اما تا تولید نهایی هنوز بازبینی و یکپارچهسازی انسانی لازم است. نتیجهٔ متداول این است که مهندسان چند کار را همزمان شروع میکنند و سپس هر کدام را از صفر اصلاح میکنند؛ موازیسازی ظاهری به صفهای بازبینی طولانی، کاهش اطمینان و تجربهٔ کاری بدتر میانجامد.
پیشنهادها برای تبدیل مصرف به پذیرش واقعی
- معیارهای خروجیمحور تعریف کنید: بهجای تمرکز صرف بر مصرف، روی کاهش زمان عرضه، کاهش باگهای پس از انتشار و افزایش رضایت کاربر تمرکز کنید.
- پرامپتها و گردشکارها را نسخهبندی و صاحبدار کنید: پرامپتهای موفق را در مخزن قرار دهید، مسئول مشخص برایشان تعیین کنید و تغییرات را از طریق بازبینی کنترل کنید.
- قوانین بازبینی و آستانهٔ اعتماد را بازنویسی کنید: تعیین کنید کدام خروجیها نیاز به بررسی انسانی دارند و چه معیارهایی برای پذیرش خروجیهای تولیدشده کافی محسوب میشود.
- تجربهٔ کاری را بسنجید، نه فقط مصرف را: پرسشهای مستقیم مطرح کنید: چه چیزی در جریان کاری واقعاً تغییر کرده و با حذف ابزار چه چیزی آسیب میبیند؟
جمعبندی
پذیرش واقعی یعنی تغییر هنجارها و انتقال دانش بهصورت قابلانتقال؛ نه فقط افزایش اعداد روی داشبورد. تیمهایی که پرامپتها و فرایندها را به دارایی مشترک تبدیل کنند و معیارهای خروجیمحور را پیاده کنند، بیشتر احتمال دارد از تبوتاب ابزار عبور کنند و به تحول پایدار برسند. این مسیر با تصمیمهای کوچک دربارهٔ مالکیت و سنجش آغاز میشود و در بلندمدت تفاوت اصلی را رقم میزند.
