«پاک‌سازی کدهای AI زمان‌برتر از نوشتن دستی است»؛ تجربه یک برنامه‌نویس

تصور کنید برنامه‌نویسی هستید که با چند پرامپت ساده، در ۶ ساعت به یک پروتوتایپ کامل می‌رسد، اما سال‌ها بعد متوجه می‌شود که روی یک بمب ساعتی از کدهای غیرقابل تعمیر سرمایه‌گذاری کرده است. الکس هایت (Alex Hyett) دقیقاً همین مسیر را طی کرد تا به حقیقتی تلخ برسد: هوش مصنوعی می‌تواند ۸۰ درصد مسیر را در چند ساعت طی کند، اما ۲۰ درصد باقی‌مانده مانند کوهی از بدهی فنی (Technical Debt) است که پیش روی شما قرار می‌گیرد و مسیر رسیدن به یک اپلیکیشن آماده برای انتشار را بسیار طولانی‌تر از آنچه پرامپت‌های اولیه وعده می‌دهند، می‌کند.

این تجربه نشان‌دهنده شکافی عمیق در جامعه توسعه‌دهندگان است. مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در ساخت سریع نمونه‌های اولیه عالی‌اند، اما پیش‌بینی معماری برای سیستم‌های مقیاس‌پذیر را نمی‌فهمند. طبق گزارش هایت، بسیاری از برنامه‌نویسان اکنون در چرخه تکراری کپی‌کردن خطاها در پنجره چت گیر کرده‌اند و با AI مانند یک «جادوی اصلاحی» برخورد می‌کنند، نه ابزاری برای یادگیری. این وضعیت باعث می‌شود توسعه‌دهنده به جای درک منطق کد، به دنبال حدس‌های مدل باشد.

انگیزه و شکاف بازار

هایت و همسرش ماه‌ها به دنبال یک ردیاب عادت (Habit Tracker) بودند که نیازهای خاص آن‌ها را پوشش دهد. با وجود صدها گزینه در App Store — که معمولاً در کنار لیست‌های To-do، ساده‌ترین اپلیکیشن‌ها برای ساخت شناخته می‌شوند — هیچ‌کدام کاملاً مناسب نبودند. آن‌ها ده‌ها برنامه را امتحان کردند، اما اکثر آن‌ها در پاسخگویی به نیازهای منحصربه‌فردشان شکست خوردند.

نیازهای خاص آن‌ها شامل موارد زیر بود:

• چیدمان (Layout): داشتن یک لیست طولانی از عادت‌ها به‌جای جابه‌جایی بین صفحات متعدد. این امر از خستگی ناشی از ورق زدن صفحات هنگام ردیابی بیش از ۲۰ مورد جلوگیری می‌کند.
• حریم خصوصی: عدم ذخیره‌سازی هیچ داده‌ای در فضای ابری (Cloud) یا روی سرورهای شخص ثالث. این رویکرد یادآور تلاش برای بهینه‌سازی محیط کاربر است، مشابه آنچه در پروژه Swipe Cleaner برای مدیریت محلی داده‌ها در آیفون مشاهده شد.
• بصری‌ها: ادغام ایموجی‌های نسل جدید (gen-emojis) در iOS 18 برای آیکون‌ها. این قابلیت زمانی حیاتی است که آیکون‌های پیش‌فرض با عادت خاص کاربر همخوانی ندارند.
• انعطاف در اهداف: پشتیبانی از اهداف روزانه، هفتگی یا ماهانه و همچنین حالت «فقط وقوع» (occurrence only). این مورد به‌طور خاص برای ردیابی مواردی مانند سردرد طراحی شده بود؛ جایی که شما هدف مشخصی ندارید و صرفاً می‌خواهید تعداد دفعات وقوع یک اتفاق منفی را بشمارید.
• زمینه (Context): قابلیت افزودن یادداشت‌های دقیق. برای مثال، نوشتن تمرینات خاص در حین ورزش یا ثبت سرعت رسیده‌شده هنگام تمرین یک آهنگ با گیتار.
• زمان‌بندی: یادآورهایی که برای هر روز یا روزهای خاصی از هفته و ماه تنظیم شوند.

ارزیابی جایگزین‌های موجود

پیش از شروع ساخت، هایت چندین اپلیکیشن محبوب را تست کرد. آن‌ها Streaks را امتحان کردند؛ برنامه‌ای رایگان با قابلیت ادغام با Apple Health. با وجود اینکه این برنامه برنده جوایز طراحی شده بود، اما به‌جای لیست از صفحات استفاده می‌کرد. همچنین امکان ساخت آیکون سفارشی و شمارش وقوع بدون هدف مشخص را نداشت؛ شما مجبور بودید یک عدد مشخص برای تکمیل روزانه تعیین کنید که برای ردیابی اتفاقات منفی مثل سردرد کاملاً غیرمنطقی است. همسر او همچنین متوجه شد که به راهی برای غیرفعال کردن کامل «رشته‌ها» (Streaks) نیاز دارد، زیرا این سیستم برای هر نوع ردیابی مفید نیست.

آن‌ها همچنین HabitKit و Grit را بررسی کردند. HabitKit دارای نمودارهای مشارکت به سبک گیت‌هاب بود، اما این ویژگی برای همسر هایت که برنامه‌نویس نیست، جذابیت نداشت. Grit از نظر عملکردی نزدیک‌ترین گزینه بود اما همچنان چندین ویژگی ضروری را کم داشت.

با این حال، مدل‌های قیمت‌گذاری مانع بزرگی بودند. Grit هزینه‌ای معادل ۹.۹۹ پوند در ماه، ۲۹.۹۹ پوند در سال یا ۴۴.۹۹ پوند برای لایسنس مادام‌العمر داشت که تقریباً با قیمت یک بازی کنسولی جدید برابری می‌کرد. قیمت HabitKit کمی کمتر بود: ۱.۹۹ پوند در ماه، ۱۱.۹۹ پوند در سال یا ۲۹.۹۹ پوند برای خرید دائمی. هایت اشاره کرد که اگرچه از توسعه‌دهندگان مستقل حمایت می‌کند و دوران برنامه‌های ارزان‌قیمت (به قیمت یک فنجان قهوه) را به یاد دارد، اما نمی‌خواست اشتراک‌های ماهانه بیشتری به بودجه‌اش اضافه کند. این فشار مالی باعث شد او HabitTed را بسازد و لوگوی خرسی آن را همسرش طراحی کند.

توهم موفقیت اولیه

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

از آنجایی که او هرگز با Swift توسعه نداده بود، بر روی یک فرآیند رفت‌وبرگشتی بین Cursor و Xcode متکی شد تا کدها را در شبیه‌ساز تست و دیباگ کند. این اتفاق پیش از انتشار Claude Code رخ داد، بنابراین این یک مهندسی کاملاً ایجنتی (Agentic) نبود، بلکه او توسعه را به تکالیف دستی کوچک تقسیم کرده بود.

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

هایت اشاره می‌کند که به‌جای یادگیری زبان Swift، زمان خود را صرف کپی-پیست کردن پیام‌های خطا و منتظر ماندن برای اینکه AI «حدس» بزند راه حل چیست کرد. او هم از AI دلیل اینکه به اندازه کافی خوب نبود تا مشکل را حل کند عصبانی بود و هم از خودش به دلیل ناتوانی در رفع خطاهای کد.

فروپاشی معماری

به نقل از مستندات شخصی هایت، بررسی دقیق‌تر نشان داد که کدها یک فاجعه هستند. AI نمایش‌های تک‌بدیه (Monolithic Views) خلق کرده بود که برخی تا ۱۰۰۰ خط طول داشتند و باعث کند شدن کامپایلر Xcode می‌شدند و به او هشدار می‌داد که باید کدها را خرد کند. استایل دکمه‌های مشابه به‌جای متمرکز شدن، در هر صفحه به‌صورت ناسازگار تکرار شده بود.

هایت مجبور شد به روش‌های سنتی بازسازی کد (Refactoring) روی آورد تا پروژه را نجات دهد. او نمایش‌های غول‌آسای کد را به اجزای کوچک‌تر (زیر ۱۰۰ خط) تبدیل کرد و استایل‌های ناسازگار را اصلاح کرد. این بازبینی دستی، شکست‌های عملکردی شدیدی را آشکار کرد که AI نادیده گرفته بود:

• از دست رفتن داده‌ها: همگام‌سازی iCloud در ظاهر کار می‌کرد، اما مکانیزم آن معیوب بود. اگر کاربر برنامه را حذف و دوباره نصب می‌کرد، تمام داده‌ها پاک می‌شد.
• گلوگاه‌های عملکردی: با افزایش داده‌ها، برنامه به‌شدت کند می‌شد؛ زیرا AI صفحه آمار را طوری طراحی کرده بود که هر بار کاربر وارد صفحه شود، تمام عادت‌ها را از ابتدا پیمایش (Loop) کرده و داده‌ها را محاسبه کند.
• بهینه‌سازی: هایت مجبور شد به‌طور دستی ویژگی‌های (Properties) خاصی را روی عادت‌ها ایجاد کند تا آمارها را ذخیره کند و محاسبات را طوری تغییر دهد که فقط هنگام تکمیل یک عادت تحریک شوند.
• شکنندگی مدل داده: مدل داده بیش از حد پیچیده بود و نام‌گذاری متغیرها بسیار عجیب بود. این موضوع ایجاب می‌کرد که او یک نقشه دستی برای مهاجرت داده‌ها (Data Migration) طراحی کند تا با هر تغییر در مدل (Schema)، عادت‌های کاربر خراب نشوند.

سد iOS 26

در حالی که پروژه به اتمام نزدیک می‌شد، عرضه iOS 26 محدودیت سخت LLMهای فعلی یعنی «تاریخ قطع داده‌های آموزشی» (Training Data Cutoff) را به رخ کشید. نسخه جدید سیستم‌عامل باعث ایجاد چندین باگ و تغییر در رابط کاربری شد که AI اصلاً قادر به درک آن‌ها نبود.

مشکلات خاص شامل موارد زیر بود:

• باگ‌های شفافیت: هایت از افکت شیشه‌ای (Glass effect) خوشش نمی‌آید، بنابراین گزینه دسترسی «کاهش شفافیت» (Reduce Transparency) را فعال کرد. این کار باعث ایجاد زنجیره‌ای از مشکلات در سراسر رابط کاربری برنامه شد.
• شکست در حالت تیره (Dark Mode): در حالت Dark Mode، هنگام باز کردن یک عادت، نوار عنوان سفید می‌شد اما متن هم سفید می‌ماند و در نتیجه تیترها کاملاً ناخوانا می‌شدند.

وقتی هایت درباره این باگ‌ها از AI پرسید، مدل با اطمینان انکار کرد که iOS 26 آخرین نسخه باشد، حتی زمانی که هایت سعی کرد او را متقاعد کند. او مجبور شد AI را کاملاً کنار بگذارد و تنها از وبلاگ‌های توسعه‌دهندگان و آپدیت‌های رسمی اپل — به‌ویژه نسخه ۲۶.۱ که در نهایت باگ شفافیت را رفع کرد — برای بازگرداندن رابط کاربری استفاده کند.

نتیجه و محصول نهایی

در نهایت، HabitTed پس از ماه‌ها توسعه و ماه‌های اضافی برای تست، در App Store منتشر شد. فراتر از کدنویسی، هایت مجبور شد زمان زیادی را صرف ساخت وب‌سایت و تهیه اسکرین‌شات‌های اپ‌استور کند؛ فرآیندی که بیشتر از آنچه انتظار داشت طول کشید.

این برنامه برای حداکثر شش عادت رایگان است و گزینه‌ای برای باز کردن تمام قابلیت‌ها به قیمت یک فنجان قهوه دارد. در حالی که هایت سپاسگزار است که AI به او انگیزه شروع داد، اعتراف می‌کند که اگر از آن استفاده نمی‌کرد، احتمالاً بیشتر یاد می‌گرفت و ماه‌ها وقتش را برای پاک‌سازی «آشغال‌های کدی» (AI Slop) که اصلاً نمی‌خواست بنویسد، تلف نمی‌کرد.

هزینه «عیلای AI»

هایت این تجربه را یک داستان هشداردهنده درباره فرسایش مهارت‌ها می‌داند. او استدلال می‌کند که تکیه کامل به AI برای همه چیز شبیه «قورباغه در آب جوش» است؛ برنامه‌نویسان به‌آرامی توانایی کدنویسی را از دست می‌دهند بدون اینکه بفهمند دارند منسوخ می‌شوند. او نتیجه می‌گیرد که کدنویسی با AI می‌تواند شما را به ۸۰ درصد مسیر برساند، اما ۲۰ درصد باقی‌مانده، ۸۰ درصد زمان (یا بیشتر) را می‌گیرد، مگر اینکه زیربنای کد را درک کنید.

او روند خطرناکی را در صنعت مشاهده کرد:

• جایگزینی جونیورها: شرکت‌ها دیگر توسعه‌دهندگان جونیور استخدام نمی‌کنند چون سنیورهای مجهز به AI می‌توانند حجم (Volume) کار را مدیریت کنند.
• فرسودگی سنیورها: توسعه‌دهندگان باسابقه به دو دسته تقسیم شده‌اند: نیمی از آن‌ها برای هر کاری از AI استفاده می‌کنند و مهارت‌هایشان را از دست می‌دهند و نیمی دیگر از یکنواختیِ نوشتن پرامپت‌های روزانه دچار فرسودگی شغلی شده‌اند.

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

گام بعدی شما

• اگر از AI برای کدنویسی استفاده می‌کنید، هر هفته یک جلسه «بازبینی معماری» بگیرید و کدهای تولیدشده توسط مدل را به صورت دستی به اجزای کوچک‌تر تقسیم کنید.
• یاد بگیرید چگونه از ابزارهای Static Analysis برای شناسایی تکرارهای غیرضروری در کدهای AI استفاده کنید.
• به جای کپی-پیست کردن خطاها، از مدل بخواهید «دلیل» بروز خطا را توضیح دهد تا یادگیری شما متوقف نشود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell برای استنتاج سریع‌تر مدل‌های کدنویسی مراجعه کنید.