‏نصف کد Ashby رو هوش مصنوعی می‌نویسه، آسمون هم نیفتاد

این مقاله رو کالین هاو، مدیر مهندسی Ashby در منطقه‌ی EMEA نوشته. به گفتهٔ نویسنده از اوت ۲۰۲۵ بیش از نصف کد جدیدی که به سیستم‌های production شرکت می‌رسه با AI تولید شده، ولی مشکلات مشتری‌ها یهو زیاد نشدن؛ با وجود دو برابر شدن مشتری‌ها و ۶۰٪ بیشتر شدن مهندس‌ها. نویسنده تأکید می‌کنه که این نه یه مقاله‌ی تبلیغ AI هست نه ضدش، و می‌گه افت کیفیت کد، سرعت یا زمان onboarding مهندس‌ها رو ندیدن. Ashby هم پروژه‌ی اسباب‌بازی نیست؛ یه مجموعه نرم‌افزار جذب استعداد با بیش از ۱۰۰ هزار کاربر فعال هفتگیه.

تز اصلی این تیم اینه که هزینه‌ی نوشتن کد داره به سمت صفر می‌ره، ولی هزینه‌ی تولید نرم‌افزار معنادار نه. به گفتهٔ نویسنده AI سراغ شغل مهندس‌ها نیومده، سراغ بخش‌های مکانیکی کارشون اومده: سینتکس، کد چسب‌مانند و تق‌تق کیبورد. در عوض چیزی که مهم‌تر می‌شه قضاوت، سلیقه و درک مشتریه. یکی از مهندس‌هاشون می‌گه تقریباً همه‌ی PRهاش الان کاملاً با AI نوشته می‌شن و یه بار حدود ۴۰ تا PR برای یه سیستم data ingestion این‌طوری زده.

دو تا قانون پایه دارن. اول اینکه همدلی رو AI نمی‌تونه جایگزین کنه؛ مدل‌ها سلیقه ندارن و مشتری رو نمی‌شناسن. نویسنده مثال می‌زنه که یه LLM براش یه توضیح PR نوشته بود که پر از جزئیات بی‌ارزش بود و حتی مهم‌ترین خطش هم نمی‌گفت چرا فلان تصمیم گرفته شده؛ این یعنی بی‌احترامی به وقت همکار. قانون دوم اینه که تو مسئول چیزی هستی که ship می‌کنی؛ چه دستی نوشته باشیش چه AI. می‌گه بزرگ‌ترین خطر AI این نیست که اشتباه می‌کنه، اینه که درست به نظر می‌رسه، پس باید شک رو بیشتر کنی نه کمتر.

نویسنده یه مدل ذهنی جالب می‌ده: به LLM به چشم یه دست تاس نگاه کن، نه ابرهوش. بعضی کارها (خلاصه کردن، پیدا کردن الگو) رو خوب انجام می‌ده و لازم نیست تاس بالا بیاری؛ بعضی کارها رو هم اصلاً نمی‌تونه. بر همین اساس دو حالت کار با AI رو از هم جدا می‌کنه: حالت «دستیار» (sidekick) که خودت بیشتر تصمیم‌ها رو می‌گیری و حالت پیش‌فرض و مناسب کارهای پرریسک مثل مایگریشن دیتابیس و کد امنیتیه؛ و حالت «واگذاری» (delegate) که وقتی شعاع خرابی کوچیکه ازش استفاده می‌کنی، مثل پروتوتایپ و ابزارهای داخلی. سؤال درست «آیا از AI استفاده کنم؟» نیست، «چقدر این‌جا بهش اعتماد کنم؟» هست.

تو عمل، Ashby استفاده از AI رو با آموزش و workshop و بودجه‌ی سخاوتمندانه‌ی توکن تشویق می‌کنه ولی استفاده‌ش رو اجباری نمی‌کنه و میزان مصرف توکن رو هم اندازه نمی‌گیره، چون معتقدن این کار باعث تولید slop می‌شه. به جاش روی ایمنی تو زیرساخت سرمایه‌گذاری می‌کنن با یه مدل «پنیر سوئیسی»: تست‌ها، feature flagها و observability هرکدوم یه لایه‌ان که سوراخ‌هاشون سر جاهای مختلفه. از linter، DangerJS، ابزارهایی مثل CodeRabbit و یه ابزار review داخلی خودشون برای گرفتن باگ استفاده می‌کنن.

به گفتهٔ نویسنده نقش review هم داره عوض می‌شه: انسان نباید وقتش رو صرف چک کردن خط‌به‌خط کد یا درست استفاده شدن useMemo کنه، اون‌ها رو linter و self-review باید بگیره. آدم‌ها باید روی این تمرکز کنن که آیا خود تغییر منطقیه، نقاط پرریسک کجان و انتزاع‌ها درست‌ان یا نه؛ چون LLMها تمایل دارن کد جدید بسازن به جای استفاده‌ی مجدد و اگه جلوشون رو نگیری یه کدبیس می‌سازن که کار می‌کنه ولی کسی توش نمی‌تونه حرکت کنه. جمع‌بندی نهایی اینه که الان کدبیس مخاطب جدیدی داره؛ خود LLMها هم اون رو می‌خونن و عین جمله برداشت می‌کنن، پس کیفیت کد دیگه فقط مهم نیست، بلکه اثرش chained و انباشته می‌شه.

نکات کلیدی:

• از اوت ۲۰۲۵ بیش از نصف کد production در Ashby با AI نوشته شده بدون افت کیفیت
• تز اصلی: هزینه‌ی نوشتن کد به صفر می‌ره ولی ساختن نرم‌افزار معنادار نه
• دو قانون پایه: همدلی جایگزین نمی‌شه و تو مسئول چیزی هستی که ship می‌کنی
• دو حالت کار با AI: «دستیار» برای کار پرریسک و «واگذاری» برای شعاع خرابی کوچیک
• استفاده از AI اجباری نیست و توکن اندازه‌گیری نمی‌شه؛ ایمنی تو زیرساخت با مدل پنیر سوئیسی