اگر تا به حال کنار یک برنامهنویس نشسته باشید، احتمالاً دیدهاید که بیشتر وقتش را خیره به هوا میگذارد تا خیره به کیبورد. این صحنه تنبلی نیست؛ ماهیت توسعهٔ نرمافزار همین است: حل مسئله. کدنویسی در واقع آخرین مرحلهٔ یک پازل ذهنی طولانی است—مثل پر کردن خانههای یک جدول که از قبل هزار بار در ذهنتان چرخیده.
در دنیای واقعی، بخش سخت کار همان لحظات بیحرکت است: فهمیدن حوزهٔ مسئله، کشف نیازهای دقیق، ساختن انتزاعهای درست، طراحی ماژولها، فکر کردن به اثرات جانبی، تست تدریجی، و البته، جنگ همیشگی با باگهایی که از همهجا سر درمیآورند. اما وقتی پای AI به ماجرا باز میشود، ریتم کار عوض میشود.
مدلهای زبانی مثل Claude Code در نوشتن کد سریعتر از هر انسان عمل میکنند. با این حال، بیشتر نرمافزارها موجوداتی پیچیدهاند و هیچ LLMی نمیتواند تمام یک سیستم را یکجا در ذهنش نگه دارد. نتیجه؟ سرعت نوشتن کد با سرعت تحویل نرمافزار یکی نیست.
بخش بزرگی از زمان مهندسان امروز صرف این میشود که بفهمند این هوش مصنوعی دقیقاً چه ساخته و چطور باید آن را در سیستم جا داد.
این همان فاصلهای است که بین وعدهٔ «۱۰ برابر سریعتر کدنویسی» و واقعیت «۱۰ درصد سریعتر تحویل نرمافزار» دیده میشود. LLMها بخش سرگرمکنندهٔ کار—کدنویسی خام—را با سرعت نور انجام میدهند، و مهندس میماند با بخشی که معمولاً کمجذابتر است: تست، دیباگ، پاکسازی کدهای تکراری، نوشتن سند، و مراقبت از معماری.
در مسیر شغلی هر مهندس لحظهای میرسد که باید هم تحویل بگیرد و هم تیم را رشد دهد. دو راه پیش پای اوست:
یا کارها را عادلانه پخش کند و با سرعت پایینتر کنار بیاید؛
یا همهٔ کارهای سخت را خودش انجام دهد تا پروژه تند جلو برود—اما با هزینهای سنگین برای سلامت تیم.
AI دقیقاً همین دوگانگی را ایجاد میکند، با یک twist مهم:
این جونیورِ نورانیِ بیوقفه، نه خسته میشود، نه یاد میگیرد، و نه مسئولیت بلندمدت میپذیرد.
مهندسان انسانی در گذر زمان هم در کیفیت رشد میکنند و هم در سرعت: کدهای تمیزتر، معماری بهتر، درک عمیقتر از لبهها و استثناها. اما LLMها تنها وقتی بهتر میشوند که «مدل» جدیدی منتشر شود یا مهندس «کانتکست بهتر» برایشان مهیا کند. یک مهندس واقعی هر روز از درون قویتر میشود؛ مدل زبانی نه.
بنابراین، تعامل با AI دو شکل متفاوت پیدا میکند:
AI-driven engineering: کار با سرعت معقول، طراحی دقیق، رعایت بهترینروشها، مستندسازی، تست، و فهمیدن اینکه سیستم دقیقاً دارد چه میکند.
Vibe coding: رها کردن همهچیز و ساختن سریع—بدون توجه به معماری، مقیاسپذیری یا آیندهٔ پروژه—تا لحظهای که کد از هم بپاشد.
مسیر دوم برای اسکریپتهای کوچک و پروتوتایپهای یک روزه عالی است. اما برای هر چیزی بزرگتر از یک اپ کوچک، در نهایت باید همان مسیر اول را برگردید؛ چون پروژهای که بدون فکر رشد میکند، فقط تودهای از پیچیدگی تولید میکند.
راز ماجرا این است که AI را مثل یک جونیور فوقسریع ببینیم: بااستعداد، پرانرژی، اما نیازمند هدایت. رها کردنش مساوی است با تولید کدی که کار میکند… اما قابلاعتماد نیست، قابلنگهداری نیست، و در آینده هزینهٔ سرسامآوری میسازد.
بنابراین مهندس امروز باید نقش لید را برای AI بازی کند و همان اصول قدیمی چرخهٔ توسعه را به آن تزریق کند—نه فقط هنگام کدنویسی، بلکه قبل و بعدش:
در مرحلهٔ برنامه ریزی، AI را وارد تحلیل کنید تا لبهها و سناریوها روشن شوند.
در مستندسازی، سندهای اولیه بسازید تا پروژه روی ریل بماند.
در طراحی ماژولار، برایش اسکلت و محدودیت تعریف کنید تا کد آشفته نشود.
در تستمحور بودن، قبل از پیادهسازی موارد تست را بسازید تا خروجی کنترلپذیر بماند.
در استانداردهای کدنویسی، با کانتکستانجینیرینگ مسیر را مشخص کنید.
و در نظارت، از توان AI برای تحلیل لاگها و الگوها استفاده کنید.
تحویل نرمافزار از همیشه بیشتر شبیه یک همکاری انسان–هوشمصنوعی شده است: انسان ساختار را میدهد، AI سرعت را. اگر این همکاری درست مدیریت شود، خروجی نه فقط سریع، بلکه سالم و قابلاتکا خواهد بود.
در نهایت، مسئله این نیست که AI جای توسعهدهنده را میگیرد؛ مسئله این است که توسعهدهندهای که با AI درست کار نمیکند، جای خودش را از دست میدهد.
شما تجربهٔ کار با «جونیورِ سریع اما بیفهم» یعنی AI را چطور توصیف میکنید؟ بیشتر وایبکد میزنید یا مهندسیمحور جلو میروید؟
بر اساس
"The AI coding trap"
نویسنده: Chris Loy.
با کمک چت جی پی تی جهت ترجمه و ویراستاری
