IntelliSense یکی از نوآوریهای اولیه مایکروسافت در زمینه کمک به کدنویسی بود که برای اولین بار در Visual Basic 5.0 (1996) معرفی شد و بعداً در Visual Studio 97 گسترش یافت. این ابزار به تکمیل خودکار اشیاء کمک میکرد - به عنوان مثال، اگر شیئی به نام فرمان (steering wheel) داشتید، ویژگیها و متدهای مرتبط را پیشنهاد میکرد و توسعهدهندگان را از جستجوی مداوم مستندات نجات میداد.
زبان برنامهنویسی، شیء و IDE همگی با هم کار میکردند، بنابراین برنامهنویس مجبور نبود زیاد به سینتکس فکر کند. این ابزار همانطور که انتظار میرفت، تکمیل میشد. این موضوع بسیار قبل از آن بود که تکمیل خودکار با ابزارهایی مانند جستجوی گوگل به جریان اصلی تبدیل شود. بنابراین، ما به عنوان برنامهنویس، مدتهاست که به این نوع تقویت عادت کردهایم. دستیاران کدنویسی هوش مصنوعی فقط یک توسعه از آن هستند.
تکامل ابزارهای کدنویسی
ویرایشگرهای متن مانند Vi و Emacs تقریباً 50 سال است که وجود دارند و نحوه نوشتن و ویرایش کد توسط توسعهدهندگان را شکل میدهند. به عنوان مثال، Vi مانند نواختن یک ساز است - اگر در آن مهارت پیدا کنید، میتوانید کد را به طرز باورنکردنی سریع جابجا کنید. این ابزار به شما امکان میدهد آخرین عمل را 20 بار تکرار کنید، که برای کارآمدتر کردن کارهای خستهکنندهای مانند حذف فاصلهها از 100 خط بسیار مهم است.
با گذشت زمان، ویرایشگرها تکامل یافتند تا برنامهنویسی را کارآمدتر کنند. Vi و Emacs رویکردهای اصلی و مبتنی بر صفحهکلید خود را داشتند، و بعداً، VS Code آن را با یکپارچهسازی خط فرمان تکمیل خودکار هوشمندتر و کمک مبتنی بر هوش مصنوعی گسترش داد. یک تغییر اساسی، معرفی پروتکل سرور زبان (Language Server Protocol - LSP) بود که نحوه ارائه بازخورد و پیشنهادات بلادرنگ توسط ویرایشگرها در زبانهای برنامهنویسی مختلف را استاندارد کرد.
وضعیت فعلی دستیاران کدنویسی هوش مصنوعی
ما در TigerEye خودمان را به یک راهحل واحد کدنویسی هوش مصنوعی محدود نمیکنیم، زیرا هنوز هیچکدام از آنها چشمگیر نیستند. هیچ برنده مشخصی وجود ندارد.
ما GitHub Copilot، Cursor و Zed را بررسی کردهایم، و آنچه مشخص است این است که تفاوت بین آنها چندان قابل توجه نیست. همه آنها توسط مدلهای مشابهی پشتیبانی میشوند و مزیت واقعی به تجربه کاربری در ویرایشگرهای مختلف بستگی دارد تا اینکه یک هوش مصنوعی به طور قابل توجهی بهتر از دیگری باشد.
برای ادامه ارزیابیهای خود، تیم TigerEye همچنین مدلهای محلی را برای آزمایش آنها اجرا کرده است. این کار به یک ماشین قوی نیاز دارد، اما راهی خصوصی و رایگان برای آزمایش عوامل کدنویسی بدون ارسال کد به سرورهای خارجی فراهم میکند. این رویکرد کنترل بیشتری بر امنیت، عملکرد و سفارشیسازی به ما میدهد و در عین حال به ما امکان میدهد ارزیابی کنیم که این مدلها در جریانهای کاری توسعه در دنیای واقعی چقدر خوب عمل میکنند.
سؤال بزرگ اکنون این است: کدام یک سریعتر تکامل مییابد؟
با IntelliSense سنتی، تکمیل خودکار به شما کمک میکرد تا ویژگیهای شیء را پر کنید. با هوش مصنوعی، تکمیل خودکار بسیار بیشتر امکانپذیر است، اما هنوز به اندازه کافی خوب نیست که به طور کامل به آن اعتماد کنید. شما باید همه چیز را بررسی کنید. هوش مصنوعی هنوز نمیتواند به طور قابل اعتماد کد کامل و آماده تولید بنویسد. رقابت در حال حاضر بر سر این است که کدام دستیار کدنویسی پاکترین و بهترین تجربه کاربری را با ارزشمندترین پیشرفتهای هوش مصنوعی ارائه میدهد.
دستیاران کدنویسی هوش مصنوعی کجا میدرخشند
هوش مصنوعی در چند مورد خوب است:
- نوشتن تستهای واحد: این یک دردسر بزرگ برای توسعهدهندگان است. توسعه مبتنی بر تست مستلزم این است که قبل از نوشتن کد واقعی، موارد آزمایشی بنویسید، که یک کار طاقتفرسا است. با هوش مصنوعی، میتوانید ابتدا کد را بنویسید و اجازه دهید دستیار موارد آزمایشی را ایجاد کند. این کار ساعتها صرفهجویی میکند.
- تولید کد Boilerplate: هوش مصنوعی میتواند به خوبی از پس آن برآید زمانی که نیاز به نوشتن یک بلوک کد تکراری دارید.
- پیادهسازیهای ریاضی و الگوریتمی: فرض کنید من نیاز دارم رنگها را بین قرمز و آبی در 100 مرحله درونیابی کنم. هوش مصنوعی میتواند منطق سنگین ریاضی را برای آن به سرعت و با دقت تولید کند. این نوع کار قبلاً 50+ خط کد طول میکشید و نیاز به کار دستی از طریق فرمولها داشت، اما اکنون میتوانم فقط از هوش مصنوعی بپرسم و یک پیادهسازی با کیفیت بالا را در عرض چند ثانیه ارائه میدهد.
- شناسایی اشکالات احتمالی: من ممیزیهای امنیتی رسمی را جایگزین نمیکنم، اما میتواند به عنوان یک برنامهنویس جفتی ضعیف یا دستیار اشکالزدایی عمل کند. یک درخواست مفید این است: "فکر میکنم این حافظه را نشت میدهد. به من نشان بده کجاست." دستیاران کدنویسی هوش مصنوعی میتوانند مسائل بالقوه و زمینههایی را که ارزش بررسی دارند برجسته کنند.
ما دیدهایم که دستیاران هوش مصنوعی در توسعه دنیای واقعی به خوبی کار میکنند. حدود 50٪ از تستهای واحد DuckDB.dart توسط هوش مصنوعی نوشته شدهاند، و همه نظرات کد خاص API یا توسط هوش مصنوعی برای وضوح و سازگاری بررسی یا تولید شدهاند. این به استانداردسازی مستندات کمک کرده و در عین حال در نوشتن تست تکراری صرفهجویی کرده است.
دستیاران کدنویسی هوش مصنوعی کجا شکست میخورند
- طراحی سیستم: این وظیفه اصلی یک توسعهدهنده سطح متوسط تا ارشد است و هوش مصنوعی در آن وحشتناک است.
- بازسازی کد: هوش مصنوعی هنوز این قابلیت را ندارد که یک کدبیس کامل را تجزیه و تحلیل کند و به طور معناداری کد موجود را بهبود بخشد.
- درک زمینه فراتر از یک فایل واحد: در حالی که دستیاران هوش مصنوعی در درجه اول روی فایلهای جداگانه کار میکنند، ابزارهایی مانند ویژگی Composer کرسر و ویژگی Suggest Edit آینده زد شروع به پرداختن به این موضوع کردهاند و به برنامهنویسان اجازه میدهند مشخص کنند کدام فایلها ضروری هستند. با این حال، این هنوز مدیریت دستی زمینه LLM است و مهندسان را ملزم میکند تا هوش مصنوعی را راهنمایی کنند تا اینکه هوش مصنوعی آگاهی مناسب در سطح سیستم را توسعه دهد. در حال بهبود است، اما هنوز از بینقص بودن فاصله دارد.
بزرگترین مشکل؟ هوش مصنوعی فاقد شهود است.
مدلهای زبانی بزرگ نمیتوانند به گونهای فکر کنند که به آنها اجازه دهد سیستمهای بزرگ مقیاس را طراحی کنند. آنها میتوانند بهترین شیوههای شناخته شده را خلاصه و تکرار کنند، اما وقتی صحبت از طراحی سیستم خلاقانه و واقعی به میان میآید ... آنها شکست میخورند.
این مانند این است که از هوش مصنوعی بخواهید یک استارتآپ کامل را از ابتدا طراحی کند. این میتواند به شما توصیههای سطح بالا ارائه دهد (زیرا کتابها و پستهای وبلاگی در مورد آن وجود دارد)، اما نمیتواند این کار را انجام دهد.
امنیت و حریم خصوصی
TigerEye از ابزارهای هوش مصنوعی که برای کل کدبیس ما اعمال میشود استفاده نمیکند. ما فقط از هوش مصنوعی با عدم حفظ دادهها استفاده میکنیم. هیچ چیز از آنچه تایپ میکنیم ذخیره یا برای آموزش مدل استفاده نمیشود.
این برای ما یک معیار اساسی است. ما کد اختصاصی را به مدلهای خارجی ارسال نمیکنیم مگر اینکه صریحاً نحوه مدیریت آن را کنترل کنیم. بسیاری از شرکتها باید به این موضوع توجه بیشتری داشته باشند.
آینده توسعه مبتنی بر هوش مصنوعی
جهش بزرگ بعدی در دستیاران کدنویسی هوش مصنوعی زمانی خواهد بود که شروع به یادگیری از نحوه کار توسعهدهندگان در زمان واقعی کنند.
در حال حاضر، هوش مصنوعی الگوهای کدنویسی را در یک جلسه تشخیص نمیدهد. اگر من یک عمل را 10 بار پشت سر هم انجام دهم، هیچ یک از ابزارهای فعلی نمیپرسند: "آیا میخواهید من این کار را برای 100 خط بعدی انجام دهم؟" اما Vi و Emacs این مشکل را دههها پیش با ماکروها و کاهش خودکار ضربه کلید حل کردند. دستیاران کدنویسی هوش مصنوعی هنوز به آن سطح کارایی نرسیدهاند.
در نهایت، دستیاران هوش مصنوعی ممکن است مبتنی بر افزونه شوند تا توسعهدهندگان بتوانند بهترین ویژگیهای مجهز به هوش مصنوعی را برای ویرایشگر دلخواه خود انتخاب کنند. تجربههای IDE یکپارچه عمیق احتمالاً عملکرد بیشتری را ارائه میدهند، اما بسیاری از توسعهدهندگان نمیخواهند IDEها را تغییر دهند.
آیا هوش مصنوعی جایگزین توسعهدهندگان خواهد شد؟
نه.
این ایده که هوش مصنوعی جایگزین مهندسان نرمافزار خواهد شد، مزخرف است، به خصوص برای نقشهای جوان و متوسط. کاری که هوش مصنوعی انجام خواهد داد این است که مهندسان خوب را بسیار سریعتر میکند. این مشاغل را حذف نمیکند. این بهرهوری فردی را افزایش میدهد.
این تغییر اساسی است: مهندسان 10 برابر دیگر تکشاخ نیستند.
با هوش مصنوعی، اکثر مهندسان متوسط تا ارشد اکنون میتوانند مهندسان 10 برابر باشند.
نکات نهایی
دستیاران کدنویسی هوش مصنوعی پتانسیل دارند، اما هنوز تغییری در بازی ایجاد نکردهاند. در حال حاضر، آنها:
- سرعت بخشیدن به وظایف کدنویسی تکراری (تستها، بویلرپلیت، الگوریتمها)
- سریعتر کردن یادگیری (توضیح مفاهیم مانند یک استاد CS)
- شکست در طراحی سیستم (عدم توانایی حل مسئله در دنیای واقعی)
- فقدان زمینه کامل پروژه (فقط روی فایلهای واحد کار کنید)
بهترین رویکرد امروز این است که از هوش مصنوعی در جایی که قوی است استفاده کنید و در جایی که ضعیف است آن را نادیده بگیرید.
مهندسی نرمافزار یک حرفه پرشتاب است. زبانها، چارچوبها و فناوریها میآیند و میروند، و توانایی یادگیری و انطباق کسانی را که پیشرفت میکنند از کسانی که عقب میمانند جدا میکند.
دستیاران کدنویسی هوش مصنوعی تکامل دیگری در این چرخه هستند. آنها جایگزین مهندسان نخواهند شد، اما نحوه انجام مهندسی را تغییر خواهند داد. نکته کلیدی مقاومت در برابر این ابزارها نیست. این یادگیری نحوه استفاده صحیح از آنها و کنجکاو ماندن در مورد قابلیتها و محدودیتهای آنها است.
تا زمانی که این ابزارها بهبود یابند، بهترین مهندسان کسانی خواهند بود که میدانند چه زمانی به هوش مصنوعی اعتماد کنند، چه زمانی خروجی آن را دوباره بررسی کنند و چگونه آن را در گردش کار خود ادغام کنند بدون اینکه به آن وابسته شوند.