خالق Redis: مهندسان باید کنترل ایده‌ها را جایگزین بررسی خط‌به‌خط کد کنند

برنامه‌نویسانی که روی خودِ کد وسواس دارند، در عصر هوش مصنوعی تأثیرگذاری خود را محدود می‌کنند. این ادعای صریح سلواتوره سانفیلیپو است؛ مردی که با نام antirez شناخته می‌شود و خالق Redis است. او استدلال می‌کند که بسیاری از توسعه‌دهندگان امروز، چون بیش از حد درگیر بررسی خط‌به‌خط کدها هستند، کمتر از پتانسیل واقعی خود اثر می‌گذارند. در واقع، بازبینی دستی هزاران خط کد در دنیای امروز، چیزی جز اتلاف هوش انسانی نیست.

این چرخش در حالی رخ می‌دهد که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — از ابزارهای ساده‌ای برای تکمیل خودکار متن، به سامانه‌هایی تبدیل شده‌اند که قادرند کل ماژول‌های کاربردی را تولید کنند. سال‌ها بود که صنعت، کدنویسی را خروجی اصلی یک برنامه‌نویس می‌دید. اما اکنون کدنویسی در حال تبدیل شدن به یک کالای ارزان است و ارزش واقعی به «قصد معماری» و «تأیید دقیق» منتقل شده است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی تغییر ماهیت شغل برنامه‌نویسی اشاره کردیم، تخصص در ابزار جای خود را به تخصص در طراحی می‌دهد. در همین راستا، درک لایه‌های کلیدی برای گذار از ابزارهای تک‌منظوره به سیستم‌های جامع هوش مصنوعی می‌تواند دیدگاه بهتری درباره‌ی مدیریت این تغییرات در سطح شخصی و سازمانی ارائه دهد. antirez اشاره می‌کند که از ژانویه ۲۰۲۴ به‌طور مستمر در وبلاگ خود درباره برنامه‌نویسی با AI بحث کرده و حتی در سال ۲۰۲ own ۲، پیش از ظهور ChatGPT، کتابی در این زمینه منتشر کرده بود تا بسیاری از این تغییرات را پیش‌بینی و اعلام کند.

ناکارآمدی بازبینی دستی

به نقل از پست وبلاگی او در ۱۳ جولای ۲۰۲۶، antirez می‌گوید حجم کدهای تولید شده توسط هوش مصنوعی، بازبینی سنتی را غیرممکن کرده است. او این سؤال حیاتی را می‌پرسد که یک انسان چگونه می‌تواند روزانه ۵۰۰۰ خط کد را بررسی کند بدون اینکه تصویر کلی پروژه را گم کند؛ به‌خصوص وقتی مدل‌های زبانی تمایل دارند کدوطور (Verbose) و بیش از حد طولانی بنویسند.

او معتقد است مدل‌ها در حال حاضر در نوشتن کدهای «بهینه محلی» فوق‌العاده‌اند — یعنی هر تابع به‌تنهایی درست کار می‌کند و خروجی صحیحی دارد — اما هنوز در مواجهه با «ایده‌های کلان» و معماری‌های سطح بالا مشکل دارند. بنابراین، صرف ۸ ساعت کاری برای اسکن خط‌به‌خط کد، بهینه‌ترین استفاده از زمان یک متخصص نیست. او باور دارد اگر توسعه‌دهنده کنترل ایده‌های نرم‌افزار را در دست داشته باشد، نگاه کردن به خودِ کد اغلب بی‌معنی و بی‌فایده است.

گردش کار جدید برای توسعه‌دهندگان

به جای خواندن کد، antirez رویکرد «اول طراحی» (Design-first) را پیشنهاد می‌کند که شامل مراحل زیر است:

• طراحی دقیقی که در ذهن دارید را به مدل پرامپت کنید تا چارچوب کلی شکل بگیرد.
• از هوش مصنوعی بخواهید دقیقاً توضیح دهد که هر بخش از طراحی چگونه کار می‌کند (برای مثال بپرسید: «طراحی این بخش دقیقاً چگونه است و سازوکار آن چیست؟»).
• به‌جای بررسی نحو (Syntax) یا استایل کدنویسی، ارزیابی کنید که آیا مدل ذهنی و منطق خروجی درست است یا خیر.

این روش به توسعه‌دهنده اجازه می‌دهد روی حیاتی‌ترین بخش‌ها تمرکز کند: تعیین مسیرهای جدید، ایده‌پردازی برای ترفندهای بهینه‌سازی و اجرای سخت‌گیرانه تضمین کیفیت (QA). برای کاهش زمان تحلیل کدهای پیچیده در این مسیر، استفاده از رویکردهای بصری‌سازی معماری‌ها می‌تواند سرعت درک منطق سیستم را به‌شدت افزایش دهد. او تأکید می‌کند که این روش، «Vibe Coding» — یا همان درخواست ساده برای محصول نهایی بدون درک سازوکار و صرفاً بر اساس حس — نیست، بلکه یک کنترل دقیق و سخت‌گیرانه بر ایده‌های نرم‌افزاری است.

درس‌هایی از عصر «کدهای بی‌کیفیت»

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

او حتی به کتاب کلاسیک «ماه مردانه افسانه‌ای» (The Mythical Man Month) استناد می‌کند و خاطرنشان می‌کند که کتابی از دهه ۷۰ میلادی، امروز درباره عصر فعلی نرم‌افزار ما بیشتر از تمام بحث‌های تخصصی ۲۰ سال اخیر می‌گوید.

او برای اثبات این موضوع، تجربه‌اش در DwarfStar را شرح می‌دهد، جایی که استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی و نه دوره‌ی آموزش آشپز — برای مدل‌های DeepSeek v4 و GLM 5.2 را به‌طور کامل خودکار پیاده کرد. او دریافت که پیاده‌سازی‌های انسانی موجود برای استنتاج محلی، پر از خطاهای ظریف در مکانیزم توجه (Attention) بودند. این خطاها باعث می‌شد خروجی مدل پس از رسیدن به محدودیت‌های پنجره متنی (Context Limits) به‌شدت آسیب ببیند. به‌طور مشخص، او دریافت که پیاده‌سازی‌های «توجه نمایه شده» (Indexed Attention) شکسته بودند و کارهای بیش از حد و اضافه‌ای را انجام می‌دادند که باعث کاهش کارایی می‌شد.

مطالعه موردی Redis

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

او به کار خود روی پیاده‌سازی آرایه‌های Redis و یک Pull Request (PR) در راه برای بهینه‌سازی Sorted Sets اشاره می‌کند که منجر به کاهش ۵۰ درصدی مصرف حافظه می‌شود. او می‌گوید هرچند برای خوانایی کاربرانی که دستی فایل‌ها را تغییر می‌دهند، کدها را تمیز می‌کند، اما این بازبینی دستی در حال تبدیل شدن به امری بی‌فایده است.

او باور دارد با عرضه GPT 5.5 و مدل‌های فعلی GPT 5.6 Sol و Fable، هوش مصنوعی می‌تواند وضعیت‌های مسابقه‌ای (Race Conditions) و خطاهای منطقی پیچیده‌ای را پیدا کند که بازبینی انسانی احتمالاً آن‌ها را نادیده می‌گیرد. او استدلال می‌کند که مهندسی سخت‌گیرانه در بخش طراحی و تست، بسیار بهتر و موثرتر از نوشتن یا خواندن دستی یک هسته گرافیکی (GPU Kernel) است.

آینده مستندات

او پیشنهاد می‌کند بازبینی‌های سنتی کد (Code Reviews) با یک فایل DESIGN.md جایگزین شوند. در این مدل، هر ساختار داده با زبان انسانی توصیف می‌شود و تمامی ترفندهای پیاده‌سازی و منطق اصلی طراحی در آن ثبت می‌گردد.

اگر توسعه‌دهنده‌ای بخواهد ویژگی‌ای مثل Sorted Sets در Redis را تغییر دهد، این مسیر را طی می‌کند:

• ابتدا فایل DESIGN.md را باز می‌کند.
• طراحی را می‌خواند تا «مالک ایده‌ها» شود و مدل ذهنی دقیقی از سیستم پیدا کند.
• سپس از یک عامل (Agent) هوش مصنوعی می‌خواهد تغییرات را بر اساس آن مدل و منطق خاص اجرا کند.

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

ریسک برای توسعه‌دهندگان تازه‌کار

تنها نگرانی باقی‌مانده، مسیر رشد و یادگیری برنامه‌نویسان جوان است. antirez می‌ترسد مبتدیان اگر هرگز یاد نگیرند برنامه‌ای را از صفر بنویسند، نتوانند مدل ذهنی لازم را برای درک سیستم‌ها بسازند. او احساس می‌کند باید به کسانی که برای این تغییر آماده نیستند، به‌ویژه نسل‌های جوان‌تر که شاهد این چرخش‌ها نبوده‌اند، هشدار دهد.

او پیشنهاد می‌کند دانشجویان به‌جای تلف کردن وقت خود برای بازبینی کدهای جاوااسکریپتی که AI برای یک سایت مشتری تولید کرده است — که آن را «گذراندن وقت با آن آشغال‌ها» می‌نامد — باید با پیاده‌سازی ابزارهای بنیادی یاد بگیرند:

• مفسرهای کوچک (Small Interpreters)
• پایگاه‌های داده کوچک (Small Databases)
• جداول هش (Hash Tables)

این کار دانش پایه‌ای لازم را می‌سازد تا آن‌ها بتوانند در آینده شغلی خود «کنترل ایده‌ها» را در دست بگیرند. او معتقد است آن‌ها باید یاد بگیرند چگونه برنامه بنویسند، حتی اگر بررسی خروجی‌های LLM دیگر مفیدترین راه برای انجام این کار نباشد.

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

گام بعدی شما

• اگر مدیر فنی هستید، بررسی کنید آیا تیم شما هنوز ساعت‌ها وقت صرف بازبینی سینتکس می‌کند یا روی «طراحی مدل ذهنی» متمرکز است.
• تمرین کنید تا الزامات فنی پروژه‌های خود را در قالب فایل‌های DESIGN.md بنویسید و سپس اجرای آن‌ها را به مدل‌های زبانی بسپارید.
• برای یادگیری عمیق، به‌جای اصلاح کدهای AI، سعی کنید یک ابزار بنیادی (مثل یک Hash Table ساده) را بدون کمک AI پیاده کنید تا مدل ذهنی شما تقویت شود.

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