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

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

چرا هوش مصنوعی از نقشه راه خارج و به IDE منتقل شد؟

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

ابزارهای هوش مصنوعی اکنون در کل چرخه عمر توسعه نفوذ می‌کنند. ابزارهایی وجود دارند که ابهامات موجود در سند الزامات را قبل از نوشتن کارت داستان (story card) نشان می‌دهند. ابزارهایی که کد کارآمدی را با درک واقعی از پایگاه کد اطراف، نه فقط فایل فعلی، تولید می‌کنند. ابزارهایی که مشکلات امنیتی را در حین بررسی تشخیص می‌دهند و ابزارهای دیگری که سعی می‌کنند پیش‌بینی کنند کدام خط لوله (pipeline) احتمالاً قبل از شروع کار با شکست مواجه می‌شود.

گیت‌هاب در سال ۲۰۲۲ یک آزمایش آزمایشگاهی کنترل‌شده را با ۹۵ توسعه‌دهنده حرفه‌ای انجام داد که به یک گروه Copilot و یک گروه کنترل تقسیم شده بودند و هر دو در حال ساخت یک سرور HTTP مشابه در جاوا اسکریپت بودند. گروه Copilot به طور متوسط ​​۵۵.۸٪ سریع‌تر کار را به پایان رساند – عددی که دائماً به آن اشاره می‌شود، بنابراین ارزش دارد که بدانیم از کجا آمده است. گیت‌هاب از این نتیجه به شدت در بازاریابی خود استفاده کرد و در حالی که یک مقاله دانشگاهی مرتبط که همان آزمایش را تجزیه و تحلیل می‌کرد، بعداً منتشر شد، خود پست وبلاگ اصلی هرگز مورد بررسی دقیق قرار نگرفت. سایر مطالعات نیز همگی با آن موافق نیستند. یک آزمایش شش هفته‌ای در بانک ANZ افزایش سرعت ۴۲.۳۶٪ را نشان داد که بیشترین جهش در بین توسعه‌دهندگان کم‌تجربه‌تر بود. یک مطالعه دانشگاهی جداگانه توسط ویتیلینگام و همکارانش هیچ تفاوت آماری معنی‌داری در زمان تکمیل پیدا نکرد. بنابراین، روایت صادقانه این است: اکثر مطالعات کنترل‌شده، افزایش سرعت واقعی را نشان می‌دهند، اما میزان این افزایش بسته به وظیفه، تیم و مدت زمانی که آن تیم واقعاً از این ابزار استفاده کرده است، بسیار متفاوت است. هر درصد واحد – از جمله موارد بالا – را به عنوان یک نقطه داده در نظر بگیرید، نه یک قانون فیزیک.

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

پنج روشی که هوش مصنوعی به تیم‌های توسعه کمک می‌کند تا سریع‌تر محصول خود را عرضه کنند

۱. تولید کدی که زمینه را درک می‌کند

ابزارهایی مانند GitHub Copilot و Cursor به خوبی از سینتکس تکمیل خودکار عبور کرده‌اند – آنها بلوک‌های عملکردی ایجاد می‌کنند که در واقع با کد اطراف مطابقت دارند. یک توسعه‌دهنده که یک نقطه پایانی API جدید می‌سازد، دیگر واقعاً از یک تابع خالی شروع نمی‌کند. آنها آنچه را که می‌خواهند توصیف می‌کنند، به آنچه برمی‌گردد نگاه می‌کنند، آن را اصلاح می‌کنند و ادامه می‌دهند. تغییر بزرگتر از تکمیل خودکار خط به خط به چیزی نزدیک‌تر به تولید عامل‌محور و آگاه از کدبیس است و این احتمالاً بزرگترین تغییر عملکردی در نحوه رفتار این ابزارها در مقایسه با سه سال پیش است. اگر به جای حرف من، به دنبال رسید هستید، در اینجا نحوه عملکرد دستیاران برنامه‌نویسی هوش مصنوعی پیشرو امروزی در مقایسه با همان کار در دنیای واقعی آورده شده است و این تجزیه و تحلیل نحوه تکامل دستیاران برنامه‌نویسی هوش مصنوعی تا سال 2026، زمینه مشابهی را از زاویه دیگری پوشش می‌دهد.

صرفه‌جویی در زمان واقعی در اینجا واقعاً مربوط به سرعت تایپ نیست. بلکه کاهش تغییر زمینه است. توسعه‌دهندگان ارشد در نهایت زمان کمتری را صرف تولید کدهای تکراری و زمان بیشتری را صرف تصمیمات معماری می‌کنند که در واقع به یک انسان برای تصمیم‌گیری نیاز دارند.

در اینجا یک تبادل نسبتاً معمول بین اعلان و داربست آورده شده است:

// Prompt to the assistant: // "POST endpoint that validates the request body against the User schema, // saves it, and returns a paginated response." router.post('/users', validate(UserSchema), async (req, res) => { const user = await User.create(req.body); const { page = 1, limit = 20 } = req.query; const users = await User.find().skip((page - 1) * limit).limit(limit); res.json({ data: users, page: Number(page), total: await User.countDocuments() }); }); این یک نقطه شروع است، نه یک درخواست pull نهایی. مدیریت خطا، میان‌افزار احراز هویت، و موارد حاشیه‌ای پیرامون // Prompt to the assistant: // "POST endpoint that validates the request body against the User schema, // saves it, and returns a paginated response." router.post('/users', validate(UserSchema), async (req, res) => { const user = await User.create(req.body); const { page = 1, limit = 20 } = req.query; const users = await User.find().skip((page - 1) * limit).limit(limit); res.json({ data: users, page: Number(page), total: await User.countDocuments() }); });

limit هم به کسی نیاز دارند که واقعاً به آنها نگاه کند. اما این یک داربست کاری در عرض چند ثانیه است، به جای پانزده دقیقه‌ای که معمولاً برای تایپ همان کد قالبی اکسپرس که قبلاً صد بار نوشته‌اید، طول می‌کشد.

۲. تست خودکار که تضمین کیفیت را از تنگنا خارج می‌کند

تقریباً همیشه در بخش تضمین کیفیت (QA) زمان‌بندی‌ها دچار لغزش می‌شوند و این به ندرت به این دلیل است که مهندسان تضمین کیفیت مهارت کافی ندارند. مشکل این است که نوشتن تست‌های جامع برای هر تغییر ویژگی، کاری کند و تکراری است و این کار با هر انتشار، پیچیده‌تر می‌شود.

ابزارهای تست با کمک هوش مصنوعی – Testim، Mabl، Diffblue Cover و غیره – تست‌های واحد و مجموعه‌های رگرسیون را مستقیماً از تغییرات کد تولید می‌کنند. با افزایش سابقه مدل با یک پایگاه کد مشخص، تست‌های پیشنهادی هدفمندتر می‌شوند و پس از آن نیاز به پاکسازی دستی کمتری وجود دارد. تیم‌هایی که به طور مداوم به این روش پایبند هستند، تمایل دارند چرخه‌های QA را به جای هفته، بر حسب روز گزارش دهند. با این حال، ارزش علامت‌گذاری دارد: این دلتا به شدت به این بستگی دارد که چه مقدار از مجموعه تست موجود قبل از ظهور ابزارهای هوش مصنوعی، خودکار شده است و این چیزی نیست که کسی بتواند یک معیار جهانی واضح برای آن به شما ارائه دهد. این موضوع از یک تیم به تیم دیگر بسیار متفاوت است.

۳. تحلیل نیازمندی‌ها قبل از نوشتن اولین خط

ابزارهای مبتنی بر LLM می‌توانند سند الزامات محصول را دریافت کرده و ابهامات، تناقضات و موارد حاشیه‌ای از قلم افتاده را قبل از برنامه‌ریزی اسپرینت، علامت‌گذاری کنند. ویژگی‌های هوش مصنوعی Jira، دستیار هوش مصنوعی Linear و گردش‌های کاری سفارشی مختلف مبتنی بر GPT، سوالات «وقتی کاربر X را انجام می‌دهد چه اتفاقی می‌افتد» را مطرح می‌کنند که در غیر این صورت به عنوان گزارش اشکال در حدود هفته ششم ظاهر می‌شدند.

جبران کمبود یک نیازمندی در هفته صفر هیچ هزینه‌ای ندارد. جبران همان کمبود در طول هفته چهارم تضمین کیفیت، یک اسپرینت هزینه دارد.

۴. بررسی کد با کمک هوش مصنوعی که آنچه انسان‌ها از دست می‌دهند را آشکار می‌کند

بازبین‌های انسانی در تشخیص خطاهای منطقی و اجرای استانداردهای تیمی خوب هستند. چیزی که آنها به طور قابل اعتمادی در آن خوب نیستند، تشخیص هر خطر تزریق SQL، هر الگوی نشت حافظه یا ارجاع تهی است که در نهایت قرار است ساعت ۳ صبح به کسی اطلاع دهد.

ابزارهایی مانند CodeRabbit، SonarQube AI و Amazon CodeGuru قبل از اینکه حتی یک انسان تفاوت‌ها را باز کند، بررسی‌های امنیتی و عملکردی را روی درخواست‌های pull انجام می‌دهند. این جایگزین قضاوت یک بررسی‌کننده در مورد طراحی و منطق نمی‌شود – فقط لایه مکانیکی را از سر راه برمی‌دارد تا توجه آنها به جایی که واقعاً مهم است معطوف شود.

یک .coderabbit.yaml ساده ممکن است چیزی شبیه به این باشد:

reviews: profile: assertive auto_review: enabled: true path_filters: - "!**/*.test.ts" - "!**/node_modules/**" tools: eslint: enabled: true در یک درخواست pull واقعی، نوع نظر خودکاری که قبل از اینکه یک بررسی‌کننده انسانی حتی تفاوت را باز کند، ظاهر می‌شود، معمولاً چیزی شبیه به این را می‌خواند: reviews: profile: assertive auto_review: enabled: true path_filters: - "!**/*.test.ts" - "!**/node_modules/**" tools: eslint: enabled: true

⚠️ مشکل احتمالی : req.query.limit مستقیماً در فراخوانی .limit() بدون اعتبارسنجی استفاده می‌شود. یک مقدار مخرب یا ناقص می‌تواند محدودیت‌های صفحه‌بندی را دور بزند یا یک استثنای مدیریت نشده ایجاد کند. تجزیه و محدود کردن آن را در نظر بگیرید: Math.min(parseInt(limit, 10) || 20, 100) .

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

۵. خطوط لوله CI/CD که به مرور زمان هوشمندتر می‌شوند

ابزارهای CI/CD تقویت‌شده با هوش مصنوعی مانند Harness و LinearB به داده‌های تاریخی خط تولید نگاه می‌کنند تا مشخص کنند کدام تغییرات از نظر آماری احتمالاً باعث اختلال در ساخت می‌شوند، استقرارهای پرخطر را قبل از رسیدن به مرحله تولید شناسایی می‌کنند و در صورت بروز مشکل، استراتژی‌های بازگشت به عقب را توصیه می‌کنند.

به جای اینکه ساعت ۶ عصر جمعه از یک نسخه ناقص مطلع شوند، تیم‌ها قبل از اینکه ادغام حتی اتفاق بیفتد، یک سیگنال خطر دریافت می‌کنند. این مزیت واقعی قرار دادن هوش مصنوعی در خط تولید است، نه اینکه با آن به عنوان یک ابزار جانبی که گاهی اوقات کسی آن را بررسی می‌کند، برخورد شود.

هر یک از این ابزارها حالت‌های خرابی دارند که قبل از اینکه در تولید به آنها تکیه کنید، ارزش دانستن آنها را دارد.

کد تولید شده توسط هوش مصنوعی دچار توهم می‌شود و این کار را با اطمینان انجام می‌دهد. یک تابع تولید شده می‌تواند کاملاً صحیح به نظر برسد اما همچنان به طرقی اشتباه باشد که بعداً مشخص می‌شود. بررسی ارشد در اینجا غیرقابل مذاکره است. این کمک است، نه خودمختاری، مهم نیست که پیشنهاد چقدر خوب به نظر برسد.

افشای داده‌ها یک خطر واقعی است، نه یک خطر فرضی. بسیاری از ابزارهای کدنویسی هوش مصنوعی، قطعه کدهایی را برای پردازش به سرورهای شخص ثالث ارسال می‌کنند. اگر در حال ساخت چیزی هستید که با داده‌های تنظیم‌شده سروکار دارد – سوابق سلامت، اطلاعات پرداخت، هر چیزی تحت HIPAA، PCI-DSS یا موارد مشابه – قبل از اینکه به تیمی اجازه دهید به آن پایگاه کد دسترسی پیدا کند، دقیقاً بررسی کنید که هر ابزار با کد ارسالی چه می‌کند و کجا پردازش می‌شود. اسناد فروشنده و یک DPA امضا شده چیزی است که واقعاً می‌خواهید آن را با آن تأیید کنید، نه یک صفحه بازاریابی. برای تیم‌هایی که این خطر کاملاً مانع معامله می‌شود، ارزش دارد که بدانند تنظیمات کدنویسی هوش مصنوعی کاملاً محلی به طور خاص وجود دارد، بنابراین کد اختصاصی هرگز از همان ابتدا دستگاه را ترک نمی‌کند.

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

چگونه بدون ایجاد اختلال در روند کار، شروع کنیم؟

لازم نیست همه چیز را در هفته اول کاملاً تغییر دهید. تقریباً همیشه یک انتشار متمرکز و قابل اندازه‌گیری، یک انتشار گسترده و مبهم را شکست می‌دهد.

بزرگترین نقطه اصطکاک خود را شناسایی کنید. زمان چرخه تضمین کیفیت، تأخیرهای بررسی، ابهام در نیازها – یکی را انتخاب کنید. اینجاست که ابزار هوش مصنوعی ابتدا وارد عمل می‌شود.

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

قبل از گسترش، مستندسازی کنید که چه چیزی کار کرده و چه چیزی نه. استفاده از ابزارهای هوش مصنوعی بدون هیچ گونه دستورالعمل، فقط باعث ایجاد ناهماهنگی در بین تیم‌ها می‌شود. یک انتشار مستند، به چیزی تبدیل می‌شود که تیم بعدی می‌تواند به جای یک آزمایش تک نفره که هیچ کس دیگری نمی‌تواند آن را تکرار کند، دوباره از آن استفاده کند. همچنین مفید است که قبل از اختصاص بودجه واقعی به انتشار گسترده‌تر، بدانید که این ابزارها در مقیاس واقعی چقدر هزینه دارند.

بیشتر تیم‌هایی که مشکل سرعت تحویل را دنبال می‌کنند، در واقع مشکل استعداد ندارند – آنها یک مشکل فرآیندی دارند و ابزارهای هوش مصنوعی که در نقاط مناسب به کار گرفته می‌شوند، مستقیماً به این مشکل می‌پردازند. تیم‌هایی که سریع‌تر تحویل می‌دهند، همیشه آن‌هایی نیستند که مهندسان بیشتری دارند. آنها معمولاً تیم‌هایی هستند که دیگر هوش مصنوعی را به عنوان یک ابتکار آینده در نظر نمی‌گیرند و آن را به عنوان بخشی از گردش کار فعلی در نظر می‌گیرند.

اشکال‌زدایی هم سریع‌تر می‌شود

نوشتن کد فقط نیمی از کار است. فهمیدن اینکه چرا مشکل پیش آمده معمولاً بیشتر از ساخت خود ویژگی طول می‌کشد – گرفتن گزارش‌ها، ردیابی درخواست‌ها در سرویس‌ها، بررسی آنچه در آخرین استقرار ارسال شده است، ارجاع متقابل داشبوردهایی که با یکدیگر ارتباط ندارند. هر کسی که نیمه‌شب برای یک حادثه در مرحله تولید فراخوانده شده باشد، احساس باز بودن پنج تب مرورگر و ندانستن از کجا را می‌داند.

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

مستنداتی که همگام با پیشرفت هستند

معمولاً اولین چیزی که وقتی یک تیم مشغول می‌شود، از دست می‌رود، مستندات است. یادداشت‌های API قدیمی می‌شوند. نمودارهای معماری دیگر با آنچه واقعاً در محیط عملیاتی در حال اجرا است، مطابقت ندارند. آشناسازی یک توسعه‌دهنده جدید با تیم، بیشتر از آنچه که باید طول می‌کشد، زیرا نیمی از آنچه آنها باید بدانند، به جای مستندات، در ذهن فرد وجود دارد.

ابزارهای هوش مصنوعی در حال پر کردن این شکاف هستند – تولید مستندات API مستقیماً از کد، خلاصه کردن تغییرات در یک نسخه خاص، و علامت‌گذاری زمانی که اسناد از پایگاه کدی که قرار است توصیف کنند، منحرف شده‌اند.

اما راستش را بخواهید، مشکل عمیق‌تری که اکثر تیم‌ها دارند، مشکل مستندسازی نیست. این یک مشکل اطلاعات پراکنده است. توسعه‌دهندگان برای یافتن پاسخ، تاپیک‌های قدیمی Slack را بررسی می‌کنند. QA بر اساس مشخصات سه‌ماهه گذشته کار می‌کند زیرا هیچ‌کس آن را به‌روزرسانی نکرده است. DevOps حدس می‌زند. محصول، شکاف‌ها را از حافظه پر می‌کند. همه مشغول هستند، اما هیچ‌کس در واقع از یک منبع حقیقت استفاده نمی‌کند.

وقتی مستندات متمرکز و به‌روز باشند، این وضعیت تغییر می‌کند – نه به این دلیل که داشتن آن خوب است، بلکه به این دلیل که ارسال به موقع مستلزم آن است که همه افراد تیم، صرف نظر از نقششان، به اطلاعاتی که در مقابلشان قرار دارد اعتماد کنند. یک منبع. بدون حدس و گمان.

چک لیست اجرا

بزرگترین نقطه اصطکاک در چرخه تحویل فعلی خود را شناسایی کنید

یک دسته ابزار هوش مصنوعی را برای آزمایش در برابر آن انتخاب کنید – تولید کد، آزمایش، بررسی، CI/CD یا اشکال‌زدایی

یک طرح آزمایشی دو اسپرینت را روی یک تیم با معیار قبل/بعد تعریف‌شده اجرا کنید

قبل از استفاده از هر ابزار روی هر پایگاه کد تنظیم‌شده، سیاست مدیریت داده‌های آن را تأیید کنید.

بررسی تمام کدهای تولید شده توسط هوش مصنوعی و تست‌ها توسط کارشناسان ارشد را الزامی نگه دارید.

قبل از گسترش به تیم‌های دیگر، نتایج آزمایشی و مراحل اجرای آن را مستند کنید.

هر سه ماه یکبار، روند انتشار را دوباره بررسی کنید – به تیم‌های بیشتری گسترش دهید، مواردی را که کار نمی‌کنند حذف کنید، و با افزایش اعتماد به ابزارها، دستورالعمل‌ها را به‌روزرسانی کنید.

فکر پایانی

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

تست مسدودسازی تبلیغات