اگر امروز برای نوشتن کدها، پیش‌نویس اسناد، تحقیق درباره موضوعات مختلف، ساخت اسکلت (Scaffold) یک نمونه اولیه یا رفع باگ‌ها در چند ثانیه به مدل‌های زبانی تکیه می‌کنید، باید بدانید که سرعت بالای تولید، لزوماً به معنای موفقیت محصول نیست. هزینه واقعی درک نیازهای انسانی دست‌نخورده باقی مانده است. این عدم توازن به این معناست که تیم‌های مهندسی اکنون نرم‌افزارها را سریع‌تر از آنکه بتوانند تصمیم بگیرند «چه چیزی» بسازند، توسعه می‌دهند. در واقع، گلوگاه اصلی توسعه نرم‌افزار از مرحله «تحویل» (Delivery) به مرحله «کشف» (Discovery) منتقل شده است.
در دهه‌های گذشته، صنعت نرم‌افزار تمام تلاش خود را برای بهینه‌سازی «خط لوله تحویل» (Delivery Pipeline) می‌کرد. تیم‌های نرم‌افزاری از توالی مشخصی شامل نیازمندی‌ها، طراحی، توسعه، تضمین کیفیت (QA) و در نهایت انتشار عبور می‌کردند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی چرخه حیات نرم‌افزارهای مدرن اشاره کردیم، این فرآیند تکامل یافت؛ ابتدا مدل آبشاری (Waterfall) جای خود را به متدهای چابک (Agile) داد و سپس Agile به DevOps تبدیل شد. در تمام این تغییرات، یک فرض زیربنایی ثابت بود: ساختن نرم‌افزار گران است، بنابراین هدف باید برنامه‌ریزی دقیق پیش از شروع باشد.
این منطق تا پیش از ظهور مدل‌های زبانی بزرگ (LLM) صادق بود. اثر LLMها بر توسعه نرم‌افزار دقیقاً مشابه تاثیری بود که ماشین‌حساب‌ها بر حسابداری داشتند. این فناوری شغل را حذف نمی‌کند، بلکه سطح آن را یک پله بالاتر می‌برد. طبق گزارش‌های منتشرشده تا ۲۴ ژوئن ۲۰۲۶، صنعت در حال تجربه یک تغییر بنیادین است که در آن سینتکس (Syntax)، کدهای تکراری (Boilerplate)، پیش‌نویس‌های اولیه و بخش بزرگی از فرآیند دیباگینگ به ماشین‌ها سپرده شده است.
با این حال، بر اساس تحلیل مفصل وب‌سایت dev.to، چالش‌های محوری انسانی همچنان کند و گران هستند. یادگیری هنوز هزینه دارد. به‌طور مشخص، آنچه ارزان نشده است عبارت است از: درک اینکه مردم واقعاً به چه چیزی نیاز دارند، هم‌راستا کردن ذینفعان (Stakeholders)، تصمیم‌گیری درباره اینکه چه شواهدی می‌تواند نظر شما را تغییر دهد، قرار دادن یک محصول واقعی در برابر کاربران و خواندن سیگنال‌ها بدون اینکه خودتان را گول بزنید. پرسش قدیمی این بود: «آیا می‌توانیم آن را به‌سریع بسازیم؟» اما پرسش جدید این است: «آیا مشکل را به‌اندازه کافی می‌شناسیم؟»
چرخش به سمت مهندسی محصول
برای بقا در این وضعیت، تیم‌ها به سمت دیسیپلینی به نام «مهندسی محصول» (Product Engineering) حرکت می‌کنند. این نقطه‌ای است که در آن مهندسی (که با تکنولوژی شروع شده و همدلی را می‌آموزد) و محصول (که با همدلی شروع شده و نحوه ساخت را می‌آموزد) با هم ادغام می‌شوند. این رویکرد، اجرای فنی را با یک ذهنیت علمی ترکیب می‌کند.
انسان‌ها به‌طور کلی در تعیین دقیق نیازمندی‌ها در ابتدای مسیر ضعیف هستند. این موضوع به دلیل دشوار بودن کار نیست، بلکه به دلیل ماهیت انسانی است؛ اکثر مردم تا زمانی که نتوانند به نسخه‌ای از یک ویژگی واکنش نشان دهند — خواه یک ماکاپ باشد، یا یک نمونه اولیه، یا یک برش خشن از محصول یا یک جریان کاری واقعی با لبه‌های تراش‌نخورده — نمی‌دانند چه حسی نسبت به آن ویژگی دارند. در نتیجه، سریع‌ترین راه برای یادگیری، نوشتن یک سند نیازمندی‌های بهتر نیست، بلکه قرار دادن نرم‌افزار عملیاتی در دسترس کاربران در سریع‌ترین زمان ممکن است.
برای جلوگیری از تله‌ی جهش مستقیم از مشکل به پیاده‌سازی (یعنی: «کاربران X را می‌خواهند، پس X را بساز»)، حلقه مهندسی محصول یک مرحله میانی گمشده را اضافه می‌کند. این فرآیند اکنون نیازمند یک «فرضیه» است: «ما باور داریم که انجام X باعث ایجاد Y می‌شود چون Z.»
- حلقه یادگیری: مشکل $\rightto$ فرضیه $\rightto$ نرم‌افزار عملیاتی $\rightto$ بازخورد کاربر $\rightto$ تکرار.
- هدف: اکنون بازخوردها چیزی برای تست شدن در مقابل آن دارند و انتشار کد (Shipping) به جای اینکه صرفاً پایان خط لوله تحویل باشد، به بخشی از یک حلقه یادگیری تبدیل می‌شود.
این تغییر، «انتشار» را از پایان یک مسیر به یک مکانیسم یادگیری تبدیل می‌کند. هدف دیگر تنها «سرعت رسیدن به کد» نیست، بلکه «سرعت رسیدن به داده» است. در این مدل، «دانشمند نرم‌افزار» (Software Scientist) ارزشمندترین دارایی است. این یک عنوان شغلی نیست، بلکه یک دیسیپلین است. دانشمند نرم‌افزار با کد به عنوان ابزار، با بازار به عنوان آزمایشگاه و با رفتار کاربر به عنوان داده برخورد می‌کند. او نازک‌ترین نسخه ممکن از یک ویژگی را شناسایی می‌کند تا یک باور خاص را تست کند؛ او می‌داند که اگر فرضیه‌ای غلط باشد، کد هدر نرفته است، بلکه وظیفه‌اش را در پاسخ به آن سؤال انجام داده است.
سیستم‌های یادگیری در مقیاس بزرگ
بر اساس بررسی منابع متعدد، چندین رهبر صنعت در حال حاضر این سیستم‌های یادگیری را برای حفظ برتری خود پیاده‌سازی کرده‌اند:
- PostHog: مهندسان مستقیماً با کاربران صحبت می‌کنند، در متریک‌ها عمیق می‌شوند و آزمایش‌ها را منتشر می‌کنند بدون اینکه همیشه منتظر بمانند تا یک مدیر محصول کار را برای آن‌ها ترجمه کند.
- Amazon: این شرکت هزاران آزمایش هم‌زمان را برای بهینه‌سازی و پالایش تجربه کاربری اجرا می‌کند.
- Netflix: برتری آن‌ها هرگز فقط الگوریتم پیشنهاددهنده نبود، بلکه سیستمی برای یادگیری این بود که «چه چیزی را در برابر چه کسی قرار دهند».
این شرکت‌ها از قابلیت‌هایی نظیر Feature Flags، تست‌های A/B، استقرار قناری (Canary Deploys) و بخش‌بندی مخاطبان (Audience Segmentation) نه به عنوان ابزارهای خاص و عجیب، بلکه به عنوان ابزارهای استاندارد علمی استفاده می‌کنند. امروزه ابزارهای متن‌باز و تجاری برای تمام این روش‌ها وجود دارد. شکاف اصلی برای اکثر تیم‌ها، کمبود ابزار نیست، بلکه نبودِ عادت به تفکر در قالب «آزمایش‌ها» به جای «ویژگی‌ها» است.
ریسک تولید «نویز»
سرعت بدون نظم آزمایشی، یک حالت شکست جدید ایجاد می‌کند: «نویز». از آنجایی که هوش مصنوعی پیاده‌سازی را ارزان‌تر می‌کند، ریسک این است که تیم‌ها در انتشار سریع متخصص شوند اما در یادگیری پیشرفتی نکنند.
این وضعیت منجر به تغییراتی بیش از حد در جریان (In flight) و آزمایش‌های هم‌پوشان زیاد می‌شود. اگر کاربر در یک هفته با ۶ قابلیت جدید مواجه شود، برای تیم غیرممکن می‌شود که تشخیص دهد کدام تغییر واقعاً نتیجه را جابجا کرده است. سرعت بدون نظم، صرفاً نویز بیشتری را با سرعت بیشتر به تیم تحمیل می‌کند.
خلأ مستندات: دفترچه آزمایشگاه
از آنجایی که نرم‌افزار در حال تبدیل شدن به امری آزمایشی است، نحوه ثبت کارهای تیم‌ها نیز باید تغییر کند. در حال حاضر، تیم‌ها تکه‌هایی از فرآیند را در سیلوهای جداگانه و غیرمتصل ثبت می‌کنند:
- Jira: تیکت‌ها را دنبال می‌کند.
- GitHub: درخواست‌های ادغام (Pull Request) را ثبت می‌کند.
- Slack: بحث‌ها و گفتگوها در آن می‌گذرد.
- Analytics: متریک‌ها را می‌سنجد.
- AI Chat: استدلال‌ها و منطق‌ها در آن است.
- حافظه: مصالحه‌ها (Trade-offs) در ذهن فرد باقی می‌ماند.
این سیستم تکه‌تکه در زمانی که کسی به مرخصی می‌رود، یک رشته گفتگو (Thread) ناپدید می‌شود یا تاریخچه چت AI پاک می‌گردد، شکست می‌خورد. نفر بعدی مجبور است آزمایش را از میان تکه‌های پراکنده بازسازی کند. دانشمندان برای جلوگیری از این اتفاق از «دفترچه آزمایشگاه» (Lab Notebook) استفاده می‌کنند. نکته اصلی خودِ دفترچه نیست، بلکه این است که اجازه می‌دهد آزمایش بعدی بر پایه نتایج آزمایش قبلی بنا شود.
در اینجاست که رویکرد «دفترچه آزمایشگاه» برای ردیابی فرضیات، تصمیمات، شواهد و یادگیری‌ها حیاتی می‌شود. ابزارهایی مانند imdone در تلاش‌اند تا این شکاف را با نگه داشتن کارهای Jira و GitHub در یک فضای کاری محلی Markdown پر کنند تا بافتار (Context) به اندازه کافی نزدیک باشد که یک انسان بتواند بعداً آن را برداشت کند و یک عامل هوش مصنوعی (AI Agent) بتواند بدون حدس زدن، از آن استفاده کند. برای کسانی که علاقه‌مندند بدانند imdone چگونه این مورد را ادغام می‌کند، مستندات CLI در imdone.io/docs/imdone-cli در دسترس است.
تحلیل: مزیت رقابتی جدید
برای یک توسعه‌دهنده (Individual Contributor)، این بدان معناست که تعریف یک «مهندس قوی» در حال تغییر است. تسلط فنی در یک زبان خاص در حال تبدیل شدن به یک کالای عمومی (Commodity) است. مهارت گران‌بهای جدید، توانایی نگه داشتن هم‌زمان «چگونگی» فنی و «چرایی» محصول است؛ تمرکز بر اینکه چه شواهدی باعث می‌شود تیم به مسیر خود ادامه دهد، تغییر جهت دهد یا متوقف شود. این جابجایی تمرکز از خروجی کد به سمت قضاوت مهندسی، بخشی از یک روند گسترده‌تر است که در تحلیل ما درباره جایگزینی خروجی کد با قضاوت مهندسی در سال ۲۰۲۶ به تفصیل بررسی شده است.
برای کسب‌وکارها، ریسک دیگر «آیا می‌توانیم آن را بسازیم؟» نیست، بلکه این است که «آیا داریم سریع‌تر زباله تولید می‌کنیم؟». شرکت‌هایی که در عصر AI پیروز می‌شوند، کسانی نیستند که سریع‌ترین کدنویس‌ها را دارند، بلکه کسانی هستند که سریع‌ترین «حلقه‌های یادگیری» را دارند. کسانی که با کد به عنوان یک ابزار مصرف‌شدنی برای جمع‌آوری داده برخورد می‌کنند، از کسانی که کد منتشرشده را معیار اصلی موفقیت می‌بینند، پیشی خواهند گرفت.
برای شروع این انتقال، تیم‌ها باید در اسپرینت بعدی خود یک سؤال بپرسند: «چگونه می‌توانیم این حلقه را کمی سریع‌تر بچرخانیم؟»
- فرضیه بسازید: پیش از ساختن، یک فرضیه واقعی بنویسید.
- نمونه‌سازی کنید: به جای ماه آینده، همین هفته یک نسخه خام را در برابر کاربر قرار دهید.
- اندازه‌گیری کنید: یک Feature Flag یا یک Event در PostHog اضافه کنید تا دقیقاً ثبت شود چه اتفاقی افتاد.
- مستند کنید: یادداشت‌های بهتری بردارید تا نفر بعدی مجبور نباشد آنچه قبلاً یاد گرفته شده را دوباره کشف کند.
هوش مصنوعی ساختن را آسان کرده است. تیم‌هایی برنده می‌شوند که در یادگیری بهتر شوند. این است کاری که اکنون باید انجام شود. اما تأثیر این تغییر روی ساختار دستمزد مهندسان حتی پیچیده‌تر است — به تحلیل ما درباره اقتصاد جدید نیروی کار AI مراجعه کنید.
گفتگو