هوش مصنوعی طبقه متوسط مهندسی نرمافزار را حذف میکند — و این برای فریلنسرها یعنی چه
نویسنده: آرش لطیفی — موسس The DevArt
خلاصهی پست پرحاشیهی Florian Herrengt و بحث ۹۰۰ کامنتی Hacker News: چرا AI باعث نمیشود مهندس ضعیف بهتر شود بلکه فقط سریعتر خرابکاریش را بزرگ میکند، و فریلنسر/تیم کوچک ایرانی چطور خودش را بالای این خط نگه دارد.
TL;DR — استدلال اصلی پست Florian Herrengt (با ۱۰۱۴ امتیاز و ۹۳۷ کامنت در Hacker News) این است: AI «حل مسئله» را ارزان نکرده، فقط «تولید کد» را ارزان کرده — چون سرعت خرابکاری بیسابقه شده ولی سرعت فهمیدن و رفعش نه، آدمها به دو گروه تقسیم میشوند: کسانی که قضاوت فنی دارند (گرانتر میشوند) و کسانی که ندارند (ارزانتر یا حذف).
داستان پست: ۷ PR صبح دوشنبه
Herrengt صحنه را اینطور روایت میکند: یک تیم با فرهنگ مهندسی خوب، همه با AI کد میزنند. صبح دوشنبه ۷ PR برای ریویو داری؛ اولی +۲۴۵۰۶ و -۳۹۳۸ خط است با توضیحات AI-generated. کد «کار میکند» — تستش را میکشی، اجرا میشود. و دقیقاً همینجا خطر است: به چشم غیرمتخصص، کار میکند. پس ادامه میدهند، PR بعدی، PR بعدی… تا جایی که هیچکس — حتی نویسندهی کد — نمیدانند چطور چیزی کار میکند.
مثل خرید ماشین لوکس با کارت اعتباری: ماشین را میبینی، بدهی را نمیبینی. تا وقتی باگی چهارمین بار برمیگردد و مینشینید جلوی Claude تماشای دیوار متن — و هیچکدامتان مطمئن نیستید جواب درست است.
نکتهی منصفانهی پست: مشکل AI نیست، استفاده از AI بهجای فهمیدن است. خود نویسنده صریح میگوید سنگین از AI استفاده میکند و برنمیگردد که همهچیز را دستی بنویسد.
چرا «کد بد همیشه بوده» این بار جواب نیست
رایجترین اعتراض در کامنتها همین بود: مهندس ضعیف همیشه بوده. جواب پست این است: قبلاً «حد سرعت» وجود داشت — خسارتی که یک مهندس ضعیف میزد به سرعت تایپش محدود بود. حالا میتواند قبل ناهار ۱۰ هزار خط «کارکننده» تولید کند. جملهی کلیدی:
سرعتی که تصمیمات بد مرکب میشوند کاملاً عوض شده، ولی سرعت رفعشان نه.
و بحث پایتونیِ پست — «خروجی AI مثل اسمبلی کامپایلر است، ما هم اسمبلی را نمیخوانیم» — اینطور جواب داده شد: کامپایلر معنای کدت را حفظ میکند و تصمیم نمیگیرد؛ LLM دهها تصمیم معماری و انتخاب abstraction را بهجای تو میگیرد. اسمبلی خواندنی نیست چون هیچ تصمیم جدیدی در آن نیست.
چیزهایی که در کامنتهای HN روشنتر شد
۹۳۷ کامنت این بحث را کاملتر کردند؛ اینها نکتههای واقعی آدمهایی بود که همین الان با این موضوع دستبهگریبانند:
- «بهرهوری» تو گاهی دزدی از بقیه است: اگر روزی ۱۰ PR تولید میکنی ولی سه مهندس دو روز وقت صرف فهمیدن و اصلاحشان میکنند، ۱۰ برابر بهرهورتر نشدهای — کار را جابهجا کردهای، به سراغ گرانترین و کمموقعتترین آدمهای تیم.
- فرایند هم نجات نمیدهد: ریویو کد برای دنیایی طراحی شده بود که تولید تغییر انبوه در آن ممکن نبود. CI سبز با کاوریش کامل هم رفتارهایی را که کسی به فکرش نرسیده بود تست نمیکند.
- کامپایلرِ نرمافزار هم از AI درد میکشد: Oracle کد AI را به JDK — پروژهی خودش — ممنوع کرد؛ با سه دلیل: فشار ریویو، پایداری، و ابهام حقوقی مالکیت. (البته در بحث مشخص شد GraalVM همان شرکت سیاست لینوکسی دارد: مجاز ولی با مسئولیت شخصی submitter.)
- جونیورها دو دسته شدند: Herrengt از دو جونیور میگوید که دقیقاً بهخاطر AI بهتر شدهاند — چون از آن برای فهمیدن استفاده میکنند نه برای جلو زدن از فهمیدن. در همان رشته، سنیورهایی بودند که کلاً فهمیدن را رها کردند و بدتر شدند.
- دربارهی آینده: بعضیها میگفتند حقوق پایین میآید و ورود به حرفه سختتر میشود (بحث H-1B هم در کامنتها بود)، بعضیها میگفتند دوباره چرخهی «ابزار بهتر» تکرار میشود. پست خودش شرطبندی مشخصی دارد: فاصلهی حقوقی بیشتر میشود — بهترینها با AI سریعتر میشوند، بقیه جایگزین یا ارزان.
جدول: دو مسیر از اینجا به بعد
| | کاربر عادی AI (vibe coder) | مهندسی که قضاوت فنی دارد | |---|---|---| | رابطه با خروجی AI | تحویل میدهد و میرود | میفهمد چه تولید شده و چرا | | PRها | بزرگ، زیاد، توضیح AI-generated | کوچک، قابل ریویو، با دلیل | | وقتی باگ برمیگردد | «بپرسم از Claude» | میداند داده از کجا میآید | | ارزش در بازار | رقابت با خودِ مدل → رو به صفر | AI او را سریعتر میکند → رو به بالا | | با تیم | زمان ریویو بقیه را مصرف میکند | ریسک را قبل merge میگیرد |
چکلیست: خودت را بالای خط نگه دار
- [ ] هیچ PRای را پوش کن که نتوانی خطبهخط توضیحش بدهی — حتی اگر AI نوشته
- [ ] تغییرات بزرگ را به تکههای کوچک بشکن؛ PR بالای چند صد خط را قبول نکن (چه نویسندهاش باشی، چه ریویوئر)
- [ ] هر abstraction جدیدی که AI معرفی میکند را بپرس: «چرا اینجا لازم است؟» — جواب قانعکننده نبود، حذفش کن
- [ ] قبل از merge، به سه سوال جواب بده: داده از کجا میآید؟ اگر مایگریشن شکست چه میشود؟ شش ماه بعد چه کسی این را نگهداری میکند؟
- [ ] بدهی فنی آگاهینه اشکال ندارد — ولی باید بدانی بدهی است و برنامه پرداخت داشته باشد
- [ ] از AI برای فهمیدن استفاده کن (بپرس چرا، سناریوها را بپرس)، نه برای جلو زدن از فهمیدن
- [ ] اگر ریویوئری، PR خیلی بزرگ را رد کن — این بخش کار توست، نه سختگیری اضافه
برای فریلنسر و تیم کوچک ایرانی این یعنی چه؟
بازار فریلنسری ما هم از این موج مستثنا نیست — شاید حتی بیشتر، چون مشتری ایرانی اغلب مهندس داخلی ندارد که خروجی AI را چک کند. چند جمعبندی عملی از دل همین بحث:
۱. قیمتگذاری بر اساس «کد زدن» تمام شد. اگر کوتیشن پروژهات را بر اساس ساعت کدنویسی میدهی، با ابزارهایی رقابت میکنی که همان کار را چند برابر ارزانتر میکنند. چیزی که باید بفروشی «تصمیم درست» است: معماری، انتخاب ابزار، پیشبینی ریسک. پست همین را میگوید: «امروز پیادهسازی ارزان است؛ برای تصمیمهای خوب به تو پول میدهند.» ۲. تحویل با فهم، مزیت رقابتی توست. همان مشتری که امروز یک جوان با AI برایش اپ زده، شش ماه بعد وسط انبوهی از کد نفهمیده گیر کرده. خدمت پاکسازی و نگهداریِ این پروژهها — همانطور که یکی از کامنتهای HN پیشبینی کرد «دههی آیندهی کانسلینگ، تعمیر Big Ball of Mud است» — بازار تازهای است. ۳. کوچک بودن مزیت است، اگر حرفهای باشی. بحث پست دربارهی سیستمهای بزرگ و چندساله است؛ اگر پروژهات کوچک، ایزوله و قابل بازنویسی است، سریع تحویل بده و برو سراغ کار بعدی. خط قرمز جایی است که پروژه قرار است سالها زنده بماند.
FAQ
Q: پس باید از AI کمتر استفاده کنم؟
نه — دقیقاً نقطهی پست هم این نیست. نویسنده خودش هر روز و سنگین استفاده میکند. تفکیک مهم این است: AI بهعنوان ابزار ساختن (مشکل ندارد) در برابر AI بهجای فهمیدن (فاجعه میسازد). معیار ساده: اگر نتوانی کدی که پوش کردی را از حافظه توضیح بدهی، هنوز آمادهی merge نیست.
Q: جونیور هستم — این بحث یعنی آیندهام از بین رفت؟
برعکس، پست خودش مثال میدهد: جونیورهایی که با AI «میفهمند» بهتر از سنیورهاییاند که رها کردند. راه ورود به حرفه سختتر شده — این را رد نمیکند — ولی مسیرش تغییر کرده: بهجای تایپ سریع، باید مهارت قضاوت بسازی و AI را ابزار یادگیریات کنی، نه جایگزینش.
Q: اگر تیم/مشتری فشار میآورد سریعتر شِپ کنم؟
پست جملهی صریحی دارد: کسی که کارش را قابل اعتماد تحویل میدهد ولی کندتر است، از کسی که سریع است ولی از خروجیاش میترسی، خیلی باارزشتر است. اگر مطمئنی چیزی مشکل جدی میسازد، گفتنش بخش کار توست — ولی انعطاف هم لازم است: وقتی تریدآف تجاری واقعی هست، کامپرایز کن و بدهی را ثبت کن.