واحد 12 / 12

ابزارهای کدنویسی هوش مصنوعی و یکپارچه سازی گردش کار

سود:

  • امکان نگاشت تکمیل ویرایشگر، دستیار چت، عامل CLI و دسته های اتوماسیون CI به وظایف
  • توانایی تنظیم سطح خودمختاری با توجه به ریسک و اعمال نظم و انضباط "اول برنامه" برای عوامل CLI
  • امکان تبدیل استفاده از هوش مصنوعی به یک سیستم تیمی مبتنی بر ابزار معتبر، دروازه تأیید، شفافیت و پاسخگویی

تاکنون یاد گرفته‌ایم که از هوش مصنوعی در کارهای فردی (کدنویسی، بررسی، آزمایش، اشکال‌زدایی) استفاده کنیم. در این بخش نهایی، قطعات را کنار هم می‌گذاریم: آشنایی با ابزارهای مختلف کدنویسی هوش مصنوعی، تطبیق ابزار مناسب با کار مناسب، و جاسازی ایمن آن‌ها در جریان توسعه روزانه شما - از ویرایشگر تا کنترل نسخه، از خط لوله CI/CD تا مدیریت تیم. هدف این است که عادت کثیف "هرازگاهی از هوش مصنوعی بپرس" به یک سیستم کاری سازگار و قابل بازرسی تبدیل شود.

ما انواع خودروها را با دسته‌های خنثی پوشش می‌دهیم (نام محصولات خاص به سرعت تغییر می‌کند؛ این که دسته چه کاری انجام می‌دهد مهم است). هر دسته دارای یک "نقطه شیرین" و یک نمایه ریسک است. تسلط این است که بدانیم به کدام وظیفه چقدر خودمختاری بدهیم.

دسته بندی ابزارهای کدنویسی هوش مصنوعی

1. تکمیل در ویرایشگر. پلاگین هایی که هنگام تایپ در IDE (محیط توسعه که در آن کد می نویسید) خطوط/بلاک ها را پیشنهاد می کنند. نقطه شیرین: سرعت در جریان، کد دیگ بخار. ریسک: زمینه محدود، پذیرش پیشنهاد بدون تفکر.

2. چت / دستیار پانل جانبی. رابط چت با قابلیت مشاهده در بخشی از پایگاه کد شما در IDE تعبیه شده است. نقطه شیرین: توضیحات، بازساز، آزمایش، تجزیه و تحلیل اشکال. ریسک: محدود به زمینه ای است که ارائه می دهید، نیاز به تأیید دارد.

3. عوامل CLI (ابزار عامل). ابزارهایی که از خط فرمان اجرا می شوند، می توانند چندین فایل را بخوانند و تغییر دهند، دستورات را اجرا کنند و وظایف چند مرحله ای را به تنهایی اجرا کنند. نقطه شیرین: تغییرات چند فایلی، کارهای تکراری، کارهای نوع "افزودن این ویژگی". ریسک: خودمختاری بالا = تاثیر زیاد. اگر علامت نزنید، تغییرات گسترده و دشواری ایجاد می کند.

4. یکپارچه سازی خط/اتوماسیون. ربات‌های CI (ادغام پیوسته) که نظرات بررسی خودکار را در مورد PR می‌گذارند، آزمایش‌هایی را پیشنهاد می‌کنند یا تغییرات را تولید می‌کنند. نقطه شیرین: صافی اول بدون خستگی، قوام. ریسک: سر و صدا، اعتماد به نفس کاذب.

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

گام به گام: تعبیه هوش مصنوعی در گردش کار

  1. وظیفه را به ابزار نگاشت کنید. اضافه شدن کوچک در جریان → تکمیل. درک/بازساز/تست → چت; کار چند فایلی، تکراری → عامل CLI. اولین فیلتر پیوسته → ادغام CI.
  2. سطح خودمختاری را انتخاب کنید. نماینده چقدر آزادی دارد؟ پیشنهاد فقط خواندنی یا اصلاح فایل + اجرای دستور؟ برای ریسک تنظیم کنید.
  3. زمینه را پرورش دهید. قوانین پروژه (سبک، معماری، "نباید") را به طور دائم به ابزار وارد کنید. به جای توضیح مکرر از فایل دستورالعمل پروژه استفاده کنید.
  4. دروازه های تأیید را حفظ کنید. تغییر هوش مصنوعی مانند تغییرات انسانی است: از طریق گردآوری، آزمایش، بررسی و (اگر حیاتی) تایید کارشناسان انجام می شود. AI باز کردن روابط عمومی تایید را دور نمی زند.
  5. اندازه گیری و تنظیم کنید. مراقب باشید که چه چیزی واقعاً شتاب می‌گیرد، جایی که بار اصلاحی افزایش می‌یابد. استفاده هایی که کار نمی کنند را هرس کنید.

سه کیف کوچک

مورد 1 - عامل CLI تغییر نام چند فایل را مدیریت کرد. یک تیم نام مفهومی را که در 60 فایل پخش شده است تغییر می دهد. آنها این وظیفه را به یک عامل CLI دادند، ابتدا طرحی را درخواست کردند، طرح را تأیید کردند، سپس تغییر را انجام دادند و کل مجموعه آزمایشی را اجرا کردند. عامل 3 یک مورد لبه در پرونده را از دست داده است. آزمایشات آن را گرفت، آن را برطرف کرد. این کار که تقریباً 3 ساعت به صورت دستی به طول انجامید، در 50 دقیقه با نظارت کامل شد.

مورد 2 - استقلال بررسی نشده نتیجه معکوس داد. یکی دیگر از توسعه دهندگان به یک نماینده گفت که "این ماژول را بهبود بخشد" و آن را منتشر کرد. عامل 18 فایل را اصلاح کرد و دو وابستگی اضافه کرد. این تغییر به قدری گسترده بود که قابل بررسی نبود و باید پس گرفته می شد. درس: به کارگزاران دامنه محدود، معیارهای پذیرش واضح، و نظم و انضباط برنامه اول- بعداً به کارگزاران بدهید.

مورد 3 - ربات بررسی CI اولین فیلتر شد. یک تیم رباتی ساخت که نظرات بررسی خودکار هوش مصنوعی را در مورد روابط عمومی ارائه می کند. هنگامی که ربات حذف‌های چک پوچ و مشکلات سبک را پیدا کرد، بازبین‌های انسانی توانستند وقت خود را به منطق تجاری اختصاص دهند. با این حال، تیم مشخص کرد که ربات «تأیید» ارائه نکرده است: حداقل یک تأیید انسانی هنوز مورد نیاز است. برای کاهش سر و صدا، آنها قایق را تنظیم کردند تا فقط صدایی با شدت بالا/متوسط ​​ایجاد کند.

چهار قالب قابل کپی

رشته "اول برنامه ریزی" برای عامل CLI:

وظیفه: {{کار باریک و روشن}}معیارهای پذیرش: {{نتیجه قابل اندازه‌گیری}}محدودیت: فقط روی {{فایل/فایل‌های زیر}} کار کنید. اضافه کردن وابستگی جدید. ابتدا یک طرح بدون تغییر ارائه دهید: کدام فایل ها، چه چیزی تغییر خواهد کرد، کدام آزمایش ها را اجرا کنید. منتظر بمانید تا طرح را تأیید کنم. سپس آن را گام به گام اعمال کنید و در هر مرحله تست ها را اجرا کنید.

فایل دستورالعمل پروژه (زمینه مداوم ابزارها):

قوانین پایدار برای ابزارهای هوش مصنوعی در این پروژه: - زبان/نسخه: {{...}}. سبک: {{...}}.- محدودیت معماری: {{به عنوان مثال. جهت بین لایه ها}}.- هرگز: جاسازی اسرار، با استفاده از داده های تولید، {{کتابخانه های ممنوع}}.- هر تغییری باید قابل آزمایش باشد. تغییر امضای عمومی API بدون درخواست. - وقتی شک دارید بایستید و بپرسید.

تصمیم نقشه برداری Task-Tool:

من کار زیر را تعریف می کنم: {{وظیفه}}. با کدام دسته از ابزارها باید این کار را انجام دهم: (الف) تکمیل ویرایشگر، (ب) دستیار چت، (ج) عامل CLI، (د) اتوماسیون CI؟ منطق، ریسک و سطح استقلال توصیه شده خود را بنویسید (صرف پیشنهاد / تغییر فایل / دستور اجرا).

کد رفتاری ربات بررسی CI:

فقط یافته های با شدت بالا و متوسط ​​را به عنوان نظرات در بررسی روابط عمومی بگذارید. هر یافته: دسته، شدت، اصلاح پیشنهادی. یادداشت ها را در سطح ترجیحی سبک در یک نظر خلاصه جداگانه جمع آوری کنید. شما رضایت نمی دهید؛ تایید انسانی مورد نیاز است

اعلان ضعیف / اعلان قوی

ضعیف: (به نماینده CLI) "ماژول پرداخت را بهتر کنید."
Strong: (برای عامل CLI) "فقط تحت src/payments/ اجرا شود. وظیفه: منطق اعتبار سنجی بازگشتی را از تابع refund() در یک کمک کننده استخراج کنید؛ رفتار و امضاها تغییر نمی کنند. ابتدا طرح را ارائه دهید و منتظر تایید من باشید؛ سپس تست ها/پرداخت ها/بسته را اجرا و اجرا کنید. وابستگی جدید اضافه کنید."

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

کلاس خودرو

کاری که او در آن بهترین است

خودمختاری

وزن بازرسی

تکمیل ویرایشگر

اضافه شده کوچک در جریان

پایین

نور (خواندن فوری)

دستیار چت

فهمیدن، آزمایش کردن، بازساز

متوسط

متوسط (تأیید خروجی)

عامل CLI

چند فایلی، بازگشتی

بالا

سنگین (طرح + بررسی کامل)

اتوماسیون CI

فیلتر اول پیوسته

متوسط

متوسط (قاعده + تایید انسانی)

مدیریت تیمی: از مهارت فردی تا سیستم مشترک

استفاده از هوش مصنوعی به صورت فردی یک شروع است. بلوغ واقعی یک سیستم سازگار در سطح تیم است. این سیستم بر چند ستون استوار است: فهرست ابزارهای تایید شده (که ابزارهایی را می توان با چه داده هایی استفاده کرد - از واحد 10)، گیت های تایید (تغییر هوش مصنوعی از همان دروازه های ساخت/تست/بازبینی می گذرد - از واحد 11)، شفافیت (با بیان اینکه یک تغییر مبتنی بر هوش مصنوعی است، قابلیت ردیابی را در صورت لزوم فراهم می کند)، و وضوح مسئولیت (شخصی است که حساب را تایید می کند). این چارچوب ریسک را با حفظ سرعت محدود می‌کند و تضمین می‌کند که اعضای جدید تیم با همان نظم و انضباط کار می‌کنند.

احتیاط: هرچه استقلال یک ابزار بیشتر باشد - به ویژه عوامل CLI که می توانند فایل ها را تغییر دهند، دستورات را اجرا کنند - دسترسی آن به محیط تولید، داده های محرمانه و عملیاتی که به سختی قابل بازگرداندن است محدودتر می شود. دستورات مخرب (حذف دائم، استقرار) را به تایید انسان گره بزنید.

اشتباهات رایج

  • وظیفه - به معنای ناسازگاری است. تلاش برای انجام یک کار چند فایلی با تکمیل ویرایشگر یا یک پیوست کوچک با یک عامل سنگین.
  • آزاد کردن نماینده وظایف عاملی که با دامنه محدود و بدون «ابتدا طرح» انجام می شود، تغییرات بررسی نشده ای را ایجاد می کند.
  • باز کردن گیت های تایید برای هوش مصنوعی. "هوش مصنوعی آن را انجام داد، بیایید به سرعت حرکت کنیم" خطرناک ترین استثنا است. درها برای همه یکسان است.
  • دادن متن به صورت دستی هر بار. عدم نوشتن قوانین پروژه در یک فایل دستورالعمل دائمی باعث ایجاد ناهماهنگی و تکرار می شود.
  • اشتباه گرفتن تایید ربات CI با تایید انسانی. یک ربات یک فیلتر است. تایید انسانی پاسخگو اجباری است.

به طور خلاصه

ابزارهای کدنویسی هوش مصنوعی به چهار دسته اصلی تقسیم می شوند: تکمیل ویرایشگر، دستیار چت، عوامل CLI و اتوماسیون CI. تسلط، تطبیق کار با ابزار مناسب و سطح مناسب استقلال است. با افزایش استقلال، کنترل نیز افزایش می یابد. به ابزارها زمینه پروژه پایدار بدهید، نظم و انضباط «اول برنامه‌ریزی» را بر عوامل چند فایلی تحمیل کنید و تغییرات هوش مصنوعی را از همان گیت‌های تأییدی که تغییرات انسانی انجام می‌دهند عبور دهید. مهارت فردی؛ آن را به یک سیستم تیمی تبدیل کنید که بر اساس لیست ابزار تایید شده، دروازه های تأیید، شفافیت و وضوح مسئولیت ساخته شده است. هوش مصنوعی یک ضرب کننده سرعت سرتاسری است. کسی که امضا می‌کند و حساب می‌دهد همیشه یک فرد صالح است.

وظیفه کاربردی

سه کار واقعی را که هفته آینده انجام خواهید داد، فهرست کنید. از الگوی «تصمیم تطبیق کار با خودرو» برای هر کدام استفاده کنید تا مشخص کنید کدام کلاس خودرو و چه سطحی از استقلال را انتخاب خواهید کرد. سپس یک کار محدود را برای یک عامل CLI (یا دستیار چت) با یک رشته «اول برنامه‌ریزی» اجرا کنید: طرح را تأیید کنید، آن را اجرا کنید، آزمایش‌ها را اجرا کنید و تغییر را مانند یک روابط عمومی انسانی بررسی کنید. در نهایت، یک «قانون استفاده از هوش مصنوعی» 5 نقطه‌ای را برای تیم خود پیش‌نویس کنید (ابزارهای تأیید شده، قانون داده، دروازه تأیید، محدودیت استقلال، مسئولیت‌پذیری).

چک لیست

  • [ ] می توانم بین دسته های ابزار کدنویسی هوش مصنوعی و نقطه شیرین هر کدام تمایز قائل شوم.
  • [ ] من کار را به کلاس خودروی صحیح و سطح خودمختاری مناسب ترسیم می کنم.
  • [ ] من زمینه پروژه دائمی (فایل دستورالعمل) را به ابزارها می دهم.
  • [ ] من دامنه محدود و نظم و انضباط "اول برنامه ریزی" را برای عوامل CLI اعمال می کنم.
  • [ ] من تغییرات هوش مصنوعی را از همان گیت های تاییدی عبور می دهم که تغییرات انسانی انجام می شود.
  • [ ] من از یک ابزار معتبر، قانون داده، شفافیت و چارچوب پاسخگویی در سطح تیم دفاع می کنم.

امتحان ماژول

1. مدل زبان بزرگ زیربنایی یک دستیار کدنویسی واقعاً هنگام تولید کد چه می کند؟

  • الف) به طور الگوی محتمل ترین ادامه را بر اساس زمینه داده شده پیش بینی می کند ✔
  • ب) با کامپایل و اجرای واقعی کد، نتیجه صحیح را تضمین می کند
  • ج) کد را به صورت زنده در سراسر اینترنت اسکن می کند و دقیق ترین کد را کپی می کند.
  • د) منطق رمز را مانند یک مهندس انسانی درک می کند و قصد را درک می کند

توضیح: LLM مانند یک انسان کد را نمی فهمد. بر اساس الگوهایی که از مجموعه بسیار بزرگی از متن و کد یاد می‌گیرد، محتمل‌ترین ادامه متن را ایجاد می‌کند. بنابراین، کیفیت خروجی مستقیماً به کیفیت متن و دستورالعملی که می دهید بستگی دارد و هر خروجی باید اعتبارسنجی شود.

2. وقتی هوش مصنوعی به طور متقاعدکننده ای یک تابع یا کتابخانه ناموجود را جعل می کند، چه می نامید و تنها پادزهر واقعی چیست؟

  • الف) به این خطای کامپایل می گویند. پادزهر تجهیزات قوی تری است
  • ب) به این حالت توهم می گویند. پادزهر این است که کد و هر API استفاده شده را تأیید کنید ✔
  • ج) به این رگرسیون می گویند. پادزهر راه اندازی مجدد مدل است
  • د) این سرریز متن نامیده می شود. پادزهر کوتاه کردن اعلان است

توضیحات: این توهم نامیده می شود و یکی از گران ترین باگ های نرم افزاری را ایجاد می کند. تنها پادزهر واقعی تأیید است: تأیید اینکه هر تابع، API و بسته استفاده شده واقعاً وجود دارد و کد کار می کند. لحن مطمئن مدل دلیلی بر دقت نیست.

3. کدام رویکرد کیفیت و ثبات خروجی را هنگام تولید کد با هوش مصنوعی بیشتر بهبود می بخشد؟

  • الف) رها کردن مدل با گفتن "این را برای من بنویس" بدون ارائه هیچ زمینه ای
  • ب) نوشتن طولانی ترین و فانتزی ترین دستور ممکن
  • ج) نمونه هایی از قرارداد ورودی/خروجی، موارد لبه، نسخه و سبک را مشخص کنید و مثال بزنید
  • د) ترکیب کد تولید شده به طور مستقیم بدون خواندن آن

توضیح: تعیین انواع ورودی/خروجی تابع (قرارداد)، موارد لبه، زبان/نسخه و محدودیت سبک و مثال زدن به مدل، انتقال از پیش‌بینی به دقت را امکان‌پذیر می‌سازد. درخواست‌های «برای من این را بنویس» بدون زمینه کدی تولید می‌کنند که هر بار متفاوت است و اغلب موارد لبه را دور می‌زند.

4. هنگام کاوش یک پایگاه کد خارجی با هوش مصنوعی، نام یک تابع ممکن است "validateAndSave" باشد اما خلاصه AI ممکن است نادرست باشد. رویکرد درست چیست؟

  • الف) اطمینان کامل به خلاصه AI همانطور که نام آن کاملاً قابل توضیح است
  • ب) تغییر تابع به طور مستقیم بدون خواندن آن
  • ج) تصمیم گیری فقط با نگاه کردن به نام تابع
  • د) توضیحات هوش مصنوعی را به عنوان یک فرضیه در نظر بگیرید و ادعاهای مهم را خط به خط در کد بررسی کنید ✔

توضیح: ممکن است هوش مصنوعی به نام موجود در کد نگاه کند و به شما بگوید «به نظر می‌رسد که دارد انجام می‌دهد»، اما در واقعیت ممکن است منطق متفاوت باشد (یا حتی معکوس). بنابراین توضیح هوش مصنوعی یک فرضیه است. ادعاهای مهم، به ویژه آنهایی که شامل امنیت، قدرت یا جریان پول هستند، باید به صورت بصری در خطوط مربوطه تأیید شوند.

5. در بررسی کد به کمک هوش مصنوعی گفتن اینکه «هوش مصنوعی به نظر می رسد، واضح است» چه خطری دارد؟

  • الف) هوش مصنوعی ممکن است منفی کاذب ایجاد کند. اشتباهات واقعی از دست رفته اعتماد به نفس کاذب ایجاد می کند ✔
  • ب) بررسی هوش مصنوعی بسیار کند است بنابراین زمان را تلف می کند
  • ج) تیم متوجه نمی شود زیرا هوش مصنوعی فقط به زبان انگلیسی نظر می دهد
  • د) روابط عمومی همگرا نمی شود زیرا هوش مصنوعی همیشه بیش از حد تفسیر می کند

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

6. موذیانه ترین تله ای که زمانی رخ می دهد که فقط کد را به هوش مصنوعی می دهید و آزمایش های چاپی را می دهید چیست؟

  • الف) هوش مصنوعی همیشه تست های زیادی می نویسد و پایگاه کد را پر می کند
  • ب) هوش مصنوعی رفتار فعلی (شاید اشتباه) کد را به عنوان "درست" آزمایش می کند و اشکال را برطرف می کند ✔
  • ج) هوش مصنوعی هنگام نوشتن تست ها به طور خودکار کد را حذف می کند
  • د) هوش مصنوعی تست هایی را نه تنها برای مسیر شاد بلکه همیشه برای لبه می نویسد

توضیح: هوش مصنوعی تمایل دارد به کد نگاه کند و ادعاهایی بنویسد که رفتار فعلی را آزمایش می کند. اگر کد از ابتدا اشتباه باشد، هوش مصنوعی این رفتار اشتباه را به عنوان "درست" تصحیح می کند. بنابراین انتظارات آزمون باید بر اساس قاعده (مشخصات) مورد نیاز نوشته شود نه بر اساس خروجی فعلی کد.

7. چه چیزی صحت فرضیه ها را هنگام اشکال زدایی باگ با هوش مصنوعی تعیین می کند؟

  • الف) چقدر مودبانه نوشته شده است.
  • ب) چند بار دوباره سوال پرسیده شد
  • ج) کیفیت شواهد ارائه شده به مدل: پیام خطای کامل، ردیابی پشته، ورودی و رفتار مورد انتظار ✔
  • د) کد با چه تم رنگی نوشته شده است؟

توضیح: هوش مصنوعی خطا را همانطور که شما می بینید نمی بیند. او فقط شواهدی را که شما به او می دهید می داند. با توجه به پیام خطای کامل، ردیابی پشته، ورودی محرک و رفتار مورد انتظار، مدل احتمالات واقعی را برمی شمارد. اگر هیچ مدرکی وجود نداشته باشد، حدس می زند (توهم) و شما را به مسیر اشتباه هدایت می کند.

8. مهم ترین مرحله قبل از دادن گزارش تولید به هوش مصنوعی برای تجزیه و تحلیل چیست؟

  • الف) چسباندن کنده به همان صورت که تمام روز را در بر می گیرد
  • ب) ابتدا لاگ را به حروف بزرگ تبدیل کنید
  • ج) ترتیب خطوط لاگ به ترتیب حروف الفبا
  • د) پوشاندن اطلاعات و اسرار شخصی و دادن فقط پنجره مربوطه ✔

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

9. اگر هوش مصنوعی بگوید دو رویداد به طور همزمان در تجزیه و تحلیل گزارش اتفاق افتاده و یکی را به عنوان علت اصلی اعلام کند، چه باید کرد؟

  • الف) عدم توجه به همبستگی به عنوان علیت و تأیید ادعا با معیارها و کد ✔
  • ب) قبول علت قطعی زیرا هوش مصنوعی رابطه زمانی برقرار می کند
  • ج) راه اندازی مجدد بلافاصله جزء متهم اول
  • د) حذف کامل لاگ ها و جمع آوری مجدد آنها

توضیح: رایج ترین دام در تحلیل لاگ، اشتباه همبستگی با علیت است. رابطه زمانی ایجاد شده توسط هوش مصنوعی یک سرنخ است، نه مدرک. علیت واقعی مستلزم زمان‌بندی، مکانیسم و ​​در صورت امکان تکرارپذیری است. ادعا باید با معیارها و کد تأیید شود.

10. قانون طلایی غیرقابل مذاکره هنگام بازسازی با هوش مصنوعی چیست و چه چیزی آن را تضمین می کند؟

  • الف) کد باید کوتاهتر باشد. تعداد خطوط این امر را تضمین می کند
  • ب) عدم تغییر در رفتار; تست هایی که رفتار فعلی را نشان می دهند این را تضمین می کنند ✔
  • ج) کد حاوی نظرات بیشتری است. هوش مصنوعی این را تضمین می کند
  • د) بازنویسی کل فایل به یکباره. نماینده این را تضمین می کند

توضیح: Refactoring بهبود ساختار داخلی کد بدون تغییر رفتار خارجی آن است. قانون طلایی این است که رفتار ثابت می ماند. چیزی که این را تضمین می کند آزمایش است: یک شبکه آزمایشی که رفتار فعلی را قبل از تغییر آن ثبت می کند، راه اندازی می شود و بعد از هر مرحله اجرا می شود. بازسازی بدون شبکه آزمایشی یک قمار است.

11. لایه ای در تولید اسناد چیست که هوش مصنوعی نمی تواند آن را بشناسد و ایجاد آن خطرناک است؟

  • الف) نحوه اجرای مراحل نصب
  • ب) لیست پارامترهای یک تابع
  • ج) توجیه «چرا» تصمیم طراحی به این صورت گرفته شد ✔
  • د) کد به چه زبانی نوشته شده است؟

توضیحات: هوش مصنوعی می تواند لایه "what/how" (این تابع چه کاری انجام می دهد، چگونه تنظیم می شود) را از کد استخراج کند. اما نمی تواند لایه «چرا» را بداند (منطق طراحی برای یک تصمیم، دلیل یک مقدار حد). یک «دلیل» ساختگی خطرناکتر از عدم توجیه است. صاحب کد باید این لایه را اضافه کند.

12. اگر یک توسعه‌دهنده بخواهد یک فایل پیکربندی حاوی یک کلید API زنده را در یک ابزار غیرمجاز هوش مصنوعی جای‌گذاری کند، در حالی که یک اشکال فوری را برطرف می‌کند، چه باید بکند؟

  • الف) برای سرعت، فایل را به همان شکلی که هست Paste کنید و سپس چت را پاک کنید
  • ب) یک یادداشت «محرمانه» در انتهای فایل اضافه کنید و آن را ارسال کنید
  • ج) کلید را رها کرده و فقط نام فایل را تغییر دهید
  • د) اسرار را بردارید/ماسک کنید و فقط زمینه غیرحساس لازم را بدهید ✔

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

13. یک کد تولید شده توسط هوش مصنوعی آزمایش را پشت سر گذاشته و در مرحله تولید اجرا می شود. آیا این ثابت می کند که کد امن است؟

  • الف) خیر؛ "کار" به معنای ایمن نیست، امنیت نیاز به لایه جداگانه ای از احراز هویت دارد ✔
  • ب) بله؛ کدی که آزمون را پشت سر می گذارد بنا به تعریف ایمن است
  • ج) بله؛ اجرای آن در تولید تمام آسیب پذیری ها را از بین می برد
  • د) خیر؛ اما امنیت تنها زمانی مهم است که کد کند باشد

توضیح: "کار کردن" با "ایمن" یکسان نیست. حتی اگر کد حاوی آسیب‌پذیری مانند تزریق SQL باشد، می‌تواند آزمایش را پشت سر بگذارد و به راحتی اجرا شود. این آسیب پذیری تنها زمانی آشکار می شود که مهاجم آن را پیدا کند. بنابراین، علاوه بر دقت، بررسی امنیتی محور و اسکن هایی مانند SAST باید به عنوان یک لایه جداگانه انجام شود.

14. ایمن ترین نظم در هنگام دادن یک کار چند فایلی به یک عامل CLI (ابزار مستقلی که می تواند فایل ها را تغییر داده و دستورات را اجرا کند) چیست؟

  • الف) به نماینده بگویید "این ماژول را بهبود ببخشید" و آزادی کامل بدهید
  • ب) محدود کردن محدوده و ضوابط پذیرش، ابتدا درخواست طرح، تایید آن، اجرای مرحله به مرحله و اجرای آزمون ها ✔
  • ج) تمام تغییرات عامل را بدون بازبینی مستقیماً ادغام کنید
  • د) دسترسی نامحدود عامل به محیط تولید و داده های محرمانه

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

15. چه کسی مسئولیت ناشی از کد تولید شده توسط هوش مصنوعی در نرم افزارهای مهم امنیتی (مانند پرداخت یا احراز هویت) را دارد؟

  • الف) از آنجایی که کد از هوش مصنوعی می آید، در ارائه دهنده خودرو قرار دارد
  • ب) اگر هوش مصنوعی به اندازه کافی توسعه یافته باشد، هیچ کس آن را ندارد. نیازی به تایید نیست
  • ج) تیم/مهندسی که کد را بررسی، مونتاژ و توزیع می کند. هوش مصنوعی جایگزین رضایت نمی شود ✔
  • د) فقط شخصی که دستور را می نویسد، نه کسانی که آن را بررسی می کنند

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