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

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

برای مشاهده ویدیوی ضبط شده این گفتگو میتوانید از این لینک استفاده کنید.

۱. مغالطه بزرگ: کدنویسی همان توسعه نرم‌افزار نیست

سال‌ها در صنعت نرم‌افزار، «کد زدن» به عنوان گلوگاه اصلی دیده می‌شد. مدیر پروژه تلاش می‌کرد estimate دقیق‌تری بگیرد. برنامه‌نویس‌ها متهم می‌شدند که کار را طول می‌دهند. سازمان‌ها دنبال low-code، no-code، سیستم‌ساز و ابزارهایی بودند که به‌نوعی از شر این گلوگاه خلاص شوند.

حالا AI آمده و دقیقاً به همان نقطه حمله کرده است: تولید کد.

واقعیت هم این است که AI تولید کد را بسیار ارزان‌تر کرده. کاری که قبلاً شاید چند روز طول می‌کشید، امروز ممکن است در چند ساعت یا حتی چند دقیقه تولید شود. اما سؤال اصلی اینجاست:

آیا چون تولید کد ارزان شده، توسعه نرم‌افزار هم ارزان شده؟

پاسخ پنل روشن بود: نه لزوماً.

چون برنامه‌نویسی فقط تایپ کردن syntax نیست. برنامه‌نویسی فرآیند فکر کردن، تصمیم گرفتن، کشف جزئیات پنهان و ساختن یک مدل ذهنی از مسئله است. کد، فقط خروجی نهایی این فکر کردن نیست؛ بخشی از خود فرآیند فکر کردن است.

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

اینجاست که ارجاع به مقاله معروف Peter Naur، یعنی Programming as Theory Building، بسیار معنادار می‌شود: برنامه‌نویسی در اصل ساختن یک نظریه ذهنی درباره سیستم است. کد و داکیومنت، محصول جانبی این نظریه‌اند؛ نه خود آن.

پس اگر فکر کنیم AI فقط specification را می‌گیرد و کد تحویل می‌دهد، احتمالاً داریم همان سوءتفاهم قدیمی را با سرعت بیشتری تکرار می‌کنیم.

۲. کد ارزان شده، اما نه فرآیند توسعه

AI در کارهای مکانیکی، تکراری و pattern-based فوق‌العاده است. اگر کاری شبیه هزاران نمونه قبلی در اینترنت باشد، AI می‌تواند مثل یک Recipe Finder عالی عمل کند یعنی دستور پخت مناسب را پیدا کند، بافت پروژه را بفهمد و چیزی تحویل دهد که در نگاه اول کاملاً کار می‌کند.

برای boilerplate، کانفیگ‌ها، setup کردن ابزارها، mapperها، تست‌های ساده، rate limitingهای معمول، یا اتصال چند سرویس شناخته‌شده، AI واقعاً می‌تواند سرعت بدهد.

اما مشکل از جایی شروع می‌شود که خروجی AI از سطح فهم تیم جلوتر می‌زند.

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

اما واقعیت تلخ این است: اگر تیم نتواند آن کد را بفهمد، review کند، تغییر دهد و نگه داری کند، آن کد یک دارایی نیست؛ یک بدهی پنهان است.

یا دقیق‌تر:

اگر AI چیزی بسازد که در سطح فهم و نگهداری تیم نیست، شما یک بمب ساعتی در پروژه گذاشته‌اید.

این همان جایی است که «وایب‌کدینگ» فقط مسئله آدم‌های غیرفنی نیست. برنامه نویس حرفه‌ای هم می‌تواند وارد vibe coding شود؛ فقط با vocabulary فنی‌تر و اعتمادبه‌نفس بیشتر.

۳. توهم سرعت: حس می‌کنیم سریع‌تر شده‌ایم، اما آیا واقعاً شده‌ایم؟

یکی از بخش‌های مهم بحث، تفاوت بین «حس سرعت» و «سرعت واقعی» بود.

وقتی با AI کار می‌کنیم، لحظه‌به‌لحظه خروجی می‌بینیم. prompt می‌دهیم، کد تولید می شود. دوباره prompt می‌دهیم، اصلاح می‌شود. دوباره تست می‌کنیم، خطا می‌دهد، دوباره می‌فرستیم، دوباره چیزی تولید می‌شود.

این تجربه، حس فوق‌العاده‌ای از سرعت می‌دهد.

اما آیا کل چرخه توسعه نرم‌افزار واقعاً به همان نسبت سریع‌تر شده؟ نه همیشه.

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

اینجاست که باید مراقب متریک‌های غلط باشیم.

اگر فقط تعداد PR، تعداد خط کد یا دفعات deployment را اندازه بگیریم، ممکن است فکر کنیم بهره‌وری چند برابر شده. اما متریک‌های جدی‌تر چیزهای دیگری‌اند:

• آیا یادگیری تیم سریع‌تر شده؟
• آیا feedback از مشتری زودتر گرفته می‌شود؟
• آیا خرابی ها یا باگ ها کمتر شده؟
• آیا تصمیم‌های معماری بهتر شده؟
• آیا time-to-value واقعاً کاهش پیدا کرده؟
• آیا تیم هنوز کدی را که تولید می‌کند می‌فهمد؟

بدون این سؤال‌ها، افزایش سرعت ممکن است فقط افزایش تولید آشفتگی باشد.

۴. شکاف ارتباطی؛ AI می‌تواند مشکل را بزرگ‌تر کند

یکی از بزرگترین هشدارهای جلسه درباره communication gap بود. در توسعه نرم‌افزار، سخت‌ترین بخش همیشه این نیست که کد را بنویسیم. سخت‌ترین بخش خیلی وقت‌ها این است که بفهمیم مشتری واقعاً چه می‌خواهد.

چون مشتری معمولاً به جای بیان نیازبه ما راه حل میدهد. می‌گوید: «یک فرم می‌خواهم که export Excel داشته باشد.»
اما شاید نیاز واقعی‌اش این باشد که گزارش‌گیری سریع‌تر شود، خطای انسانی کمتر شود، یا یک KPI مهم قابل مشاهده شود.

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

اما AI می‌تواند این فرآیند را دور بزند.

• مدیر محصول به AI می‌گوید: «برای این فیچر یک specification کامل بنویس.»
• AI یک داکیومنت مرتب، طولانی، خوش‌ ظاهر و پر از acceptance criteria تحویل می‌دهد.
• توسعه‌دهنده هم بدون اینکه در فرآیند فکر کردن شریک شده باشد، همان را به coding agent می‌دهد.
• نتیجه؟ حجم زیادی کد که ظاهراً همه چیز دارد؛ فرم، دکمه، API، تست و … اما شاید هنوز مسئله واقعی بیزنس را حل نکرده باشد.

اینجاست که AI به‌جای کم کردن شکاف ارتباطی، آن را عمیق‌تر می‌کند. چون خروجی‌ها حرفه‌ای‌تر به نظر می‌رسند، اما فهم مشترک کمتر شده است.

قبلاً شاید مجبور بودیم حرف بزنیم. حالا هرکسی در غار خودش با AI حرف می‌زند و خروجی مرتب‌تری به نفر بعدی تحویل می‌دهد. این خطر کوچکی نیست.

۵. فرصت واقعی: AI برای بهتر حرف زدن، نه کمتر حرف زدن

اما نیمه روشن ماجرا کجاست؟

AI وقتی ارزشمند می‌شود که جای گفتگو را نگیرد، بلکه کیفیت گفتگو را بالا ببرد.

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

این یعنی چرخه بازخورد کوتاه تر شده است.

اگر از AI برای ساختن پروتوتایپ استفاده کنیم تا زودتر از مشتری بازخورد بگیریم، احتمالاً یکی از سالم‌ترین کاربردهای AI را پیدا کرده‌ایم. چون در این حالت AI قرار نیست گفتگو را حذف کند؛ قرار است گفتگو را عینی‌تر، سریع‌تر و دقیق‌تر کند.

به جای اینکه درباره یک ایده مبهم حرف بزنیم، چیزی نشان می‌دهیم و می‌پرسیم:

• «آیا منظورت همین بود؟»
• «اینجا چه چیزی کم است؟»
• «این مسیر واقعاً کار تو را ساده‌تر می‌کند؟»
• «اگر این را بسازیم، چه چیزی در زندگی کاری تو تغییر می‌کند؟»

اینجا AI می‌تواند به کشف نیاز واقعی کمک کند، نه اینکه فقط راه حل یا سولوشن اولیه را شیک‌تر بسته‌بندی کند.

۶. AI به‌عنوان دستیار معماری؛ وقتی سؤال‌های خوب می‌پرسد

یکی از کاربردهای بسیار مهم AI در جلسه، کمک به تحلیل نیازمندی‌های غیرکارکردی یا همان NFR بود.

مثال ساده بود: یک فیچر بازنشانی رمزعبور.

در ظاهر، تسک ساده‌ای است. خیلی‌ها شاید بگویند: «دو سه ساعت بیشتر کار ندارد.» اما وقتی AI به codebase، context سیستم و یک template خوب برای NFR دسترسی داشته باشد، می‌تواند سؤال‌هایی بپرسد که تیم‌ها گاهی فراموش می‌کنند:

• اگر کاربر ایمیل نداشته باشد چه؟
• لینک reset تا چه زمانی معتبر است؟
• توکن‌های منقضی‌شده کجا پاک می‌شوند؟
• آیا rate limiting داریم؟
• آیا این endpoint در برابر brute force امن است؟
• آیا audit log لازم داریم؟
• اگر کاربر چند بار پشت سر هم درخواست reset بدهد چه اتفاقی می‌افتد؟

اینجا AI فقط کد تولید نمی‌کند؛ به فکر کردن مهندسی کمک می‌کند. این تفاوت بسیار مهم است. استفاده خوب از AI یعنی آن را وارد فرآیند reasoning، طراحی، کشف ریسک و بازبینی کنیم؛ نه اینکه فقط از آن به‌عنوان دستگاه تولید syntax استفاده کنیم.

۷. SDLC ما برای این سرعت طراحی نشده است

یکی از جمع‌بندی‌های مهم پنل این بود که چرخه توسعه نرم‌افزار ما برای این حجم از سرعت آماده نیست.

ابزارها، فرایندها، عادت‌های تیمی، reviewها، تست‌ها، معماری، مدیریت دانش و حتی مدل همکاری ما، همگی برای دنیایی طراحی شده‌اند که تولید کد کندتر بود.

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

تولید سریع کد بدون تست اتومات، CI/CD بالغ، code review معنادار، observability، security check، documentation زنده و ownership روشن، مثل این است که با ماشین بدون ترمز تخت گاز برویم. شاید چند ثانیه هیجان‌انگیز باشد، اما نتیجه‌اش احتمالاً تصادف سریع‌تر است.

پس برخلاف بعضی تصورها، اصول مهندسی نرم‌افزار در عصر AI کم‌اهمیت‌تر نشده‌اند؛ اتفاقاً حیاتی‌تر شده‌اند.

Continuous Delivery، تست خوب، معماری قابل فهم، refactoring، observability، و تیم cross-functional حالا از همیشه مهم‌ترند. چون وقتی تولید سریع‌تر می‌شود، ظرفیت جذب و کنترل این تولید هم باید قوی‌تر شود.

۸. Specification-Driven Development؛ نجات‌دهنده یا واترفال سلف‌سرویس؟

این روزها دوباره بحث specification جدی شده است. ایده این است که قبل از coding agent، یک spec دقیق داشته باشیم و بعد AI از روی آن کد بسازد. در ظاهر، منطقی است. حتی می‌تواند بسیار مفید باشد.

اما خطرش هم جدی است.

اگر specification تبدیل شود به یک سند بزرگ که AI نوشته، کسی درست نخوانده، تیم در فرآیند فکر کردنش شریک نبوده، و بعد همان سند به agent بعدی داده شده، ما فقط یک نسخه جدید از واترفال ساخته‌ایم؛ شاید حتی بدتر.

چون در واترفال قدیمی، حداقل چند نفر واقعاً ساعت‌ها روی سند کار کرده بودند. اما در نسخه جدید، ممکن است در چند دقیقه یک سند بسیار شیک تولید شود که هیچ‌کس واقعاً ownership ذهنی نسبت به آن ندارد.

• Spec خوب، سند تحویل دادن نیست.
• Spec خوب، ابزار فکر کردن و همسو شدن است.

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

۹. تیم‌های آینده باید cross-functionalتر باشند

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

در چنین فضایی، تیم‌هایی موفق‌ترند که مرزهای خشک بین نقش‌ها در آن‌ها کمتر باشد.

• Product owner باید کمی بیشتر از تکنولوژی بفهمد.
• Developer باید کمی بیشتر از بیزنس و محصول بفهمد.
• Tester باید از ابتدا در طراحی فکر کند، نه فقط آخر کار ایراد بگیرد.
• Architect نباید جدا از تیم تصمیم بگیرد.
• و کل تیم باید بتواند با هم درباره مسئله، ریسک، طراحی و ارزش بحث کند.

AI-native engineering یعنی فقط داشتن Cursor، Claude Code، Copilot یا هر ابزار دیگری نیست. یعنی تیم بتواند با سرعت جدید یاد بگیرد، هماهنگ شود و تصمیم بگیرد.

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

جمع‌بندی: آینده برای تیم‌هایی است که سریع‌تر فکر می‌کنند، نه فقط سریع‌تر کد می‌زنند

پیام اصلی این گفتگو را شاید بتوان در یک جمله خلاصه کرد:

AI کد را ارزان کرده، اما تفکر مهندسی را ارزان نکرده است.

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

AI می‌تواند یک اهرم بزرگی باشد. اما فقط برای تیم‌هایی که می‌دانند برای چه چیزی از این اهرم استفاده کنند.

آینده نرم‌افزار از اینجا شروع نمی‌شود که AI به جای ما کد بزند.
از اینجا شروع می‌شود که ما یاد بگیریم با کمک AI، عمیق‌تر فکر کنیم.