چگونه مدیر ابزارهای توسعه‌دهندگان گوگل، کدنویسی با هوش مصنوعی را عملی می‌کند
به‌عنوان مدیر پروژه ابزارهای توسعه‌دهندگان در گوگل، رایان سالوا (Ryan Salva) از نزدیک شاهد تغییراتی است که ابزارهای هوش مصنوعی در دنیای کدنویسی ایجاد کرده‌اند. او که پیش‌تر در GitHub و مایکروسافت فعالیت داشته، اکنون مسئول ابزارهایی مانند Gemini CLI و Gemini Code Assist است که توسعه‌دهندگان را به سمت دنیای جدید «برنامه‌نویسی عامل‌محور (agentic programming)» هدایت می‌کند.
تیم او روز سه‌شنبه تحقیق جدیدی از یک شرکت ثالث منتشر کرد که نشان می‌دهد توسعه‌دهندگان در عمل چگونه از ابزارهای هوش مصنوعی استفاده می‌کنند — و همچنین چه مسیر طولانی‌ای برای پیشرفت باقی مانده است. من با سالوا درباره این گزارش و تجربه شخصی‌اش با ابزارهای کدنویسی هوش مصنوعی گفت‌وگو کردم.
هر سال گوگل گزارشی درباره روندهای توسعه‌دهندگان منتشر می‌کند — اما گزارش امسال بیشتر بر ابزارهای هوش مصنوعی و به‌طور خاص میزان تمایل توسعه‌دهندگان به رویکرد «عامل‌محور» در برنامه‌نویسی تمرکز دارد. آیا چیزی در این تحقیق برایتان شگفت‌انگیز بود؟
یکی از یافته‌های جالب، تاریخ میانی (میانه) شروع استفاده توسعه‌دهندگان از ابزارهای هوش مصنوعی بود. مشخص شد این تاریخ آوریل ۲۰۲۴ است؛ زمانی که به‌خوبی با عرضه Claude 3 و Gemini 2.5 همزمان شد. این در واقع آغاز دوران مدل‌های «استدلالی یا تفکری» است و تقریباً در همان زمان، توانایی ما در فراخوانی ابزارها به شکل قابل توجهی بهتر شد.
برای انجام وظایف کدنویسی، واقعاً لازم است بتوان از اطلاعات خارجی برای حل مسئله استفاده کرد. بنابراین ممکن است نیاز باشد که ابزار grep اجرا شود، یا کد کامپایل شود. اگر کد بدون خطا کامپایل شد، شاید لازم باشد تست واحد (unit test) و سپس تست یکپارچه‌سازی (integration test) نیز اجرا شود. به‌نظر من قابلیت فراخوانی ابزارها (tool-calling) همان بخش مهمی است که به مدل‌ها توانایی می‌دهد در حین کار خودشان را اصلاح کنند.
این روزها بیشتر کدنویسی من مربوط به پروژه‌های سرگرمی است و بیشتر وقتم را با ابزارهای مبتنی بر خط فرمان می‌گذرانم. از جمله Gemini CLI. کمی هم از Claude Code و کمی از Codex استفاده می‌کنم. در واقع، هیچ‌وقت یک ابزار مبتنی بر ترمینال را به تنهایی استفاده نمی‌کنید، بنابراین محیط‌های توسعه (IDE) من کاملاً متنوع هستند. از Zed، VS Code، Cursor و Windsurf استفاده می‌کنم — همه آن‌ها را امتحان می‌کنم چون علاقه‌مندم ببینم دنیا چطور کار می‌کند و صنعت به چه سمتی می‌رود.
در سمت حرفه‌ای، مدیران محصول معمولاً بیشتر وقت خود را در اسناد می‌گذرانند. بنابراین اولین کار من استفاده از هوش مصنوعی برای نوشتن مستندات مشخصات و نیازمندی‌هاست.
سؤال شدنی است: شما از Gemini CLI برای ساخت خود Gemini CLI استفاده می‌کنید، اما واضح است که خودش به تنهایی نمی‌چرخد.
یک وظیفه توسعه معمولاً به‌صورت یک «ایشو» شروع می‌شود؛ شاید یک GitHub issue که کسی برای یک باگ ثبت کرده باشد. اغلب اگر صادق باشم، این ایشو خیلی ناقص است. بنابراین من از Gemini CLI استفاده می‌کنم تا یک مستند نیازمندی جامع‌تر در قالب Markdown بسازم. این مستند معمولاً حدود ۱۰۰ خط است، فنی اما در عین حال بر نتیجه‌محور بودن تمرکز دارد. سپس از Gemini CLI می‌خواهم براساس آن مشخصات و ترجیحات کلی مستندات تیم، کد را تولید کند.
در تیم مهندسی ما چندین لایه قوانین و مستندات Markdown داریم که مدل از آن‌ها استفاده می‌کند — از جمله «چگونه تست می‌گیریم»، «چطور وابستگی‌ها را مدیریت می‌کنیم» و غیره. بنابراین زمانی که کد تولید می‌شود، از این مستندات هم پیروی می‌کند.
هنگام رفع خطاها، Gemini CLI مستند نیازمندی‌هایم را به‌روزرسانی می‌کند و می‌نویسد: «این مرحله رفع شد، حالا مرحله بعدی را انجام می‌دهم.» و به همین ترتیب ادامه می‌دهد. هرکدام از این مراحل خودش یک commit و یک pull request در مخزن ایجاد می‌کند، بنابراین همیشه می‌توانم به عقب برگردم یا تغییرات را لغو کنم.
احتمالاً می‌توانم بگویم ۷۰ تا ۸۰ درصد کارم این است که در ترمینال با زبان طبیعی کار می‌کنم، تلاش می‌کنم با Gemini CLI نیازمندی‌ها را بنویسم و سپس اجازه می‌دهم خودش بیشتر کد را تولید کند. بعد کد را در هر IDE که استفاده می‌کنم، مرور و بررسی می‌کنم. بیشتر اوقات IDE برای من جایی برای خواندن کد است، نه نوشتن آن.
آینده کدنویسی خام چه خواهد شد؟ آیا همه‌چیز به ترمینال منتقل می‌شود؟
برای سه دهه، IDE جایی بود که همه کارهای توسعه نرم‌افزار در آن انجام می‌شد. شما IDE داشتید، مرورگر داشتید و یک پنجره ترمینال. فکر می‌کنم این موضوع هنوز هم تا حد زیادی برقرار است. اما حدس می‌زنم با گذشت زمان، بیشتر وقتمان صرف کار روی مستندات نیازمندی‌ها خواهد شد و میزان زمان صرف‌شده در IDE به‌تدریج کاهش می‌یابد. این تغییر احتمالاً در یک بازه زمانی نسبتاً طولانی رخ خواهد داد.
در این میان نگرانی زیادی وجود دارد که این تحول برای آینده توسعه نرم‌افزار چه معنایی دارد. اگر ۱۰ سال دیگر دیگر کسی مستقیماً به کد نگاه نکند، نقش توسعه‌دهندگان چه خواهد بود؟ آیا هنوز شغلی برایشان باقی می‌ماند؟
به نظر من، شغل یک توسعه‌دهنده در آینده بیشتر شبیه یک معمار خواهد بود. یعنی کار شما بیشتر شامل شکستن مسائل بزرگ و پیچیده به وظایف کوچک‌تر و قابل حل است. باید به تصویر کلی و هدفی که می‌خواهید بسازید فکر کنید، نه زبان واسطه‌ای که قرار است آن را به کد ماشین تبدیل کند.
منبع : techcrunch