כלי קידוד AI ושילוב זרימת עבודה

רווחים:

• יכולת למפות השלמת עורך, עוזר צ'אט, סוכן CLI וקטגוריות אוטומציה של CI למשימות
• יכולת להתאים את רמת האוטונומיה בהתאם לסיכון ולהחיל משמעת 'תכנון תחילה' על סוכני CLI
• יכולת להפוך את השימוש ב-AI למערכת צוותית המבוססת על כלי מאומת, שער אימות, שקיפות ואחריות

עד כה למדנו להשתמש ב-AI במשימות בודדות (קידוד, סקירה, בדיקה, איתור באגים). ביחידה הסופית הזו, מרכיבים את החלקים: היכרות עם כלי קידוד AI שונים, התאמת הכלי הנכון לעבודה הנכונה, והטמעתם בבטחה בזרימת הפיתוח היומית שלך - מעורך ועד בקרת גרסאות, מצינור CI/CD ועד לניהול צוות. המטרה היא להפוך את ההרגל המבולגן "לשאול את הבינה המלאכותית מדי פעם" למערכת עבודה עקבית וניתנת לביקורת.

אנו מכסים סוגי רכב עם קטגוריות ניטרליות (שמות מוצרים ספציפיים משתנים במהירות; מה שהקטגוריה עושה זה מה שחשוב). לכל קטגוריה יש "נקודה מתוקה" ופרופיל סיכון; שליטה היא לדעת כמה אוטונומיה לתת לאיזו משימה.

קטגוריות של כלי קידוד AI

1. השלמת עורך. תוספים שמציעים קווים/בלוקים בזמן שאתה מקליד ב-IDE שלך (סביבת הפיתוח שבה אתה כותב קוד). נקודה מתוקה: מהירות בזרם, קוד לוחית. סיכון: הקשר צר, קבלת ההצעה בלי לחשוב.

2. עוזר צ'אט/פאנל צד. ממשק צ'אט מוטבע ב-IDE עם נראות לתוך חלק מבסיס הקוד שלך. נקודה מתוקה: תיאור, רפקטור, בדיקות, ניתוח באגים. סיכון: מוגבל להקשר שאתה נותן, דורש אימות.

3. סוכני CLI (כלי סוכן). כלים הפועלים משורת הפקודה, יכולים לקרוא ולשנות מספר קבצים, להריץ פקודות ולבצע משימות מרובות שלבים בעצמם. נקודה מתוקה: שינויים מרובי קבצים, משימות חוזרות ונשנות, עבודות מסוג "הוסף מאפיין זה". סיכון: אוטונומיה גבוהה = השפעה גבוהה; אם לא מסומן, הוא מייצר שינויים רחבים וקשים לאימות.

4. שילוב קו/אוטומציה. בוטים של CI (Integration Continuous Integration) שמשאירים הערות סקירה אוטומטיות על יחסי ציבור, מציעים בדיקות או מייצרים יומני שינויים. נקודה מתוקה: מסננת ראשונה ללא עייפות, עקביות. סיכון: רעש, ביטחון כוזב.

רמז: ככל שהאוטונומיה גוברת, השליטה צריכה גם לגדול. מכיוון שההשלמה של העורך היא קטנה ומיידית, היא מפוקחת קלה; יש לבחון שינוי מרובה קבצים של סוכן CLI בדיוק כמו, אם לא יותר בזהירות, מאשר יחסי ציבור אנושיים.

שלב אחר שלב: הטמעת AI לתוך זרימת העבודה

1. מפה את המשימה לכלי. תוספת קטנה בזרם → השלמה; להבין/לשחזר/ לבדוק ← צ'אט; עבודה מרובת קבצים שחוזרת על עצמה ← סוכן CLI; מסנן ראשון מתמשך → שילוב CI.
2. בחר את רמת האוטונומיה. כמה חופש יש לסוכן? הצעה לקריאה בלבד או שינוי קובץ + ביצוע פקודה? התאם לסיכון.
3. לטפח את ההקשר. הכנס לכלי כללי פרויקט (סגנון, ארכיטקטורה, "אל תעשה") באופן קבוע; השתמש בקובץ הוראות פרויקט במקום להסביר אותו שוב ושוב.
4. שמור על שערי אימות. שינוי בינה מלאכותית הוא כמו שינוי אנושי: הוא עובר הידור, בדיקה, סקירה ואישור (אם קריטי) של מומחים. יחסי ציבור פתיחה בינה מלאכותית אינה עוקפת את האישור.
5. למדוד ולהתאים. צפו מה באמת מאיץ, איפה עומס התיקון גדל; גזום שימושים שלא עובדים.

שלושה מיני מארזים

מקרה 1 - סוכן CLI טיפל בשינוי שמות מרובי קבצים. צוות אחד ישנה שם קונספט המתפרס על פני 60 קבצים. הם נתנו את המשימה לסוכן CLI, ביקשו תחילה תוכנית, אישרו את התוכנית, אחר כך ביצעו את השינוי והריצו את כל חבילת הבדיקות. סוכן 3 החמיץ תיק קצה בתיק; בדיקות תפסו את זה, תיקנו את זה. העבודה, שנמשכה כ-3 שעות באופן ידני, הסתיימה תוך 50 דקות עם השגחה.

מקרה 2 - אוטונומיה לא מבוקרת השפיעה לאחור. מפתח אחר אמר לסוכן "לשפר את המודול הזה" ושחרר אותו; הסוכן שינה 18 קבצים והוסיף שתי תלות. השינוי היה כה רחב עד שלא ניתן היה לבדוק אותו והיה צורך לבטלו. שיעור: תן לסוכנים היקף צר, קריטריוני קבלה ברורים ומשמעת של תוכנית ראשונה-מאוחר יותר.

מקרה 3 - בוט סקירת CI הפך למסנן הראשון. צוות אחד בנה בוט שמשאיר הערות אוטומטיות של סקירת AI על יחסי ציבור. ברגע שהבוט תפס השמטות של בדיקת אפס ובעיות בסגנון, סוקרים אנושיים יכלו להקדיש את זמנם להיגיון עסקי. עם זאת, הצוות הבהיר שהבוט לא סיפק "אישור": עדיין נדרש אישור אנושי אחד לפחות. כדי להפחית את הרעש, הם כיוונו את הסירה כך שיותיר רק רעש בעוצמה גבוהה/בינונית.

ארבע תבניות הניתנות להעתקה

דיסציפלינת "תכנן תחילה" עבור סוכן CLI:

משימה: {{משימה ברורה, צרה}}קריטריוני קבלה: {{תוצאה ניתנת למדידה}}אילוץ: עבודה רק על {{הספרייה/הקבצים הבאים}}; הוספת תלות חדשה. תחילה הצג תוכנית ללא שינוי: אילו קבצים, מה ישתנה, אילו בדיקות להפעיל. חכה שאאשר את התוכנית. לאחר מכן יש ליישם אותו שלב אחר שלב, ולהריץ בדיקות בכל שלב.

קובץ הוראות פרויקט (הקשר מתמיד לכלים):

כללים קבועים עבור כלי AI בפרויקט זה:- שפה/גרסה: {{...}}. סגנון: {{...}}.- אילוץ אדריכלי: {{למשל. כיוון בין שכבות}}.- לעולם לא: הטמעת סודות, שימוש בנתוני ייצור, {{ספריות אסורות}}.- כל שינוי חייב להיות בר בדיקה; שינוי חתימת ה-API הציבורי מבלי לשאול. - כאשר יש ספק, עצור ושאל.

החלטה למיפוי כלי משימות:

אני מגדיר את המשימה הבאה: {{משימה}}. באיזה סוג של כלים עלי לעשות זאת עם: (א) השלמת עורך, (ב) עוזר צ'אט, (ג) סוכן CLI, (ד) אוטומציה של CI? כתוב את הרציונל, הסיכון ורמת האוטונומיה המומלצת שלך (רק הצעה / שינוי קובץ / פקודת הרץ).

קוד התנהגות בוט של ביקורת CI:

השאר רק ממצאי חומרה גבוהים ובינוניים כהערות בסקירת יחסי הציבור. כל ממצא: קטגוריה, חומרה, הצעה לתיקון. אסוף הערות ברמת העדפת הסגנון להערת סיכום נפרדת אחת. אינך מסכים; נדרש אישור אנושי.

הנחיה חלשה / הנחיה חזקה

חלש: (לסוכן CLI) "הפוך את מודול התשלום לטוב יותר."

חזק: (לסוכן CLI) "הפעל רק תחת src/payments/. משימה: חלץ את לוגיקת האימות הרקורסי מהפונקציה refund() לתוך עוזר יחיד; התנהגות וחתימות לא משתנות. ראשית הצג את התוכנית והמתן לאישורי; לאחר מכן בצע והפעל את הבדיקות/תשלומים/חבילה. הוסף תלות חדשה."

הגרסה החזקה מצמצמת את ההיקף, קובעת קריטריוני קבלה ואילוצים, ומטילה את דיסציפלינה של "תוכנית תחילה". דרישות מעורפלות של "עשה טוב יותר" הן הסיבה העיקרית לשינויים עצומים ובלתי נשלטים.

מחלקת רכב

במה הוא הכי טוב

אוטונומיה

משקל בדיקה

השלמת עורך

תוספת קטנה בזרם

נמוך

אור (קריאה מיידית)

עוזר צ'אט

להבין, לבדוק, לשחזר

בינוני

בינוני (אימות פלט)

סוכן CLI

ריבוי קבצים, רקורסיבי

גבוה

כבד (תוכנית + סקירה מלאה)

אוטומציה של CI

מסנן ראשון רציף

בינוני

בינוני (כלל + אישור אנושי)

ממשל צוות: ממיומנות אישית למערכת משותפת

שימוש טוב ב-AI על בסיס אישי הוא התחלה; בגרות אמיתית היא מערכת עקבית ברמת הצוות. מערכת זו מבוססת על מספר עמודי תווך: רשימת כלים מאושרים (באילו כלים ניתן להשתמש עם אילו נתונים - מיחידה 10), שערי אימות (שינוי בינה מלאכותית עוברת דרך אותם שערי בנייה/בדיקה/בדיקה - מיחידה 11), שקיפות (הקביעה ששינוי מופעל בינה מלאכותית מספקת מעקב במידת הצורך), ובהירות אחריות (האדם שחותם ומקבל דין וחשבון). מסגרת זו מגבילה סיכונים תוך שמירה על מהירות ומבטיחה שחברי צוות חדשים עובדים באותה משמעת.

זהירות: ככל שהאוטונומיה של כלי גבוהה יותר - במיוחד סוכני CLI שיכולים לשנות קבצים, להריץ פקודות - כך מגבילים אותו בצורה הדוקה יותר מגישה לסביבת הייצור, נתונים סודיים ופעולות שקשה לחזור בהן. קשרו פקודות הרסניות (מחיקה לצמיתות, פריסה) לאישור אנושי.

טעויות נפוצות

• משימה משמעה אי התאמה. מנסה לעשות עבודה מרובת קבצים עם השלמת עורך או קובץ מצורף קטן עם סוכן כבד.
• משחררים את הסוכן. משימות סוכן הניתנות בהיקף מצומצם וללא "תוכנית תחילה" מייצרות שינויים שלא נבדקו.
• שחרור שערי האימות עבור AI. "AI עשה את זה, בואו נמשיך במהירות" הוא החריג המסוכן ביותר; הדלתות זהות לכולם.
• מתן ההקשר באופן ידני בכל פעם. אי כתיבת כללי פרויקט לתוך קובץ הוראות קבוע מייצר חוסר עקביות וכפילות.
• טעות באישור של בוט ה-CI לאישור אנושי. בוט הוא מסנן; אישור אנושי אחראי הוא חובה.

לסיכום

כלי קידוד AI מתחלקים לארבע קטגוריות עיקריות: השלמת עורך, עוזר צ'אט, סוכני CLI ואוטומציה של CI. שליטה היא התאמת המשימה לכלי הנכון ולרמת האוטונומיה הנכונה; ככל שהאוטונומיה גוברת, השליטה גוברת גם היא. תן לכלים הקשר פרויקט מתמשך, כפה דיסציפלינה של "תוכנית תחילה" על סוכנים מרובי קבצים, והעבר שינוי בינה מלאכותית דרך אותם שערי אימות כמו שינוי אנושי. מיומנות אישית; הפוך אותה למערכת צוותית הבנויה על רשימת כלים מאושרת, שערי אימות, שקיפות ובהירות אחריות. AI הוא מכפיל מהירות מקצה לקצה; מי שחותם ונותן את החשבון הוא תמיד אדם מוכשר.

משימת יישום

רשום שלוש משימות אמיתיות שתבצע בשבוע הבא. השתמש בתבנית "החלטה התאמת משימה לרכב" עבור כל אחד מהם כדי להצדיק איזו מחלקת רכב ואיזו רמת אוטונומיה תבחר. לאחר מכן הפעל משימה צרה עבור סוכן CLI (או עוזר צ'אט) עם דיסציפלינה של "תוכנית תחילה": אשר את התוכנית, אכיף אותה, הרץ את הבדיקות וסקור את השינוי כמו יחסי ציבור אנושיים. לבסוף, נסח "כלל שימוש ב-AI" בן 5 נקודות עבור הצוות שלך (כלים מאושרים, כלל נתונים, שער אימות, מגבלת אוטונומיה, אחריות).

רשימת בדיקה

• [ ] אני יכול להבחין בין קטגוריות כלי קידוד AI לבין הנקודה המתוקה של כל אחת מהן.
• [ ] אני ממפה את המשימה לדרגת הרכב הנכונה ולרמת האוטונומיה המתאימה.
• [ ] אני נותן הקשר קבוע לפרויקט (קובץ הוראות) לכלים.
• [ ] אני מיישם תחום מצומצם ומשמעת "מתכנן תחילה" על סוכני CLI.
• [ ] אני מעביר שינויים בינה מלאכותית דרך אותם שערי אימות כמו שינויים אנושיים.
• [ ] אני דוגל בכלי מאומת, כלל נתונים, שקיפות ואחריות ברמת הצוות.

מבחן מודול

1. מה בעצם עושה מודל השפה הגדול הבסיסי של עוזר קידוד כשהוא מייצר קוד?

• א) מנבא באופן דפוסי את ההמשך הסביר ביותר בהתבסס על ההקשר הנתון ✔
• ב) מבטיח את התוצאה הנכונה בעצם קומפילציה והרצה של הקוד
• ג) הוא סורק את הקוד בכל רחבי האינטרנט בשידור חי ומעתיק את הקוד המדויק ביותר.
• ד) מבין את ההיגיון של הקוד כמו מהנדס אנוש ומבין את הכוונה

הבהרה: LLM אינו 'מבין' קוד כמו אדם; הוא מייצר את ההמשך הסביר ביותר להקשר הנתון, בהתבסס על דפוסים שהוא לומד ממאגר גדול מאוד של טקסט וקוד. לכן, איכות הפלט תלויה ישירות באיכות ההקשר וההוראה שאתה נותן, ויש לאמת כל פלט.

2. איך קוראים לזה כשבינה מלאכותית רוקחת בצורה משכנעת פונקציה או ספרייה שלא קיימת, ומהו התרופה האמיתית היחידה?

• א) זה נקרא שגיאת קומפילציה; התרופה היא ציוד חזק יותר
• ב) זה נקרא הזיה; האנטידוט הוא לאמת את הקוד וכל API בשימוש ✔
• ג) זה נקרא רגרסיה; התרופה היא להפעיל מחדש את המודל
• ד) זה נקרא הצפת הקשר; התרופה היא לקצר את ההנחיה

תיאור: זה נקרא הזיה וגורם לאחד הבאגים היקרים ביותר בתוכנה. התרופה האמיתית היחידה היא אימות: אישור שכל פונקציה, API וחבילה בשימוש אכן קיימים ושהקוד עובד. הטון הבטוח של הדגם אינו עדות לדיוק.

3. איזו גישה הכי משפרת את האיכות והעקביות של הפלט בעת יצירת קוד עם AI?

• א) שחרור המודל באמירת 'כתוב לי את זה' מבלי לתת שום הקשר
• ב) כתיבת ההנחיה הארוכה והמהודרת ביותר האפשרית
• ג) ציין ותן דוגמאות של חוזה קלט/פלט, מקרי קצה, גרסה וסגנון ✔
• ד) שילוב הקוד שנוצר ישירות מבלי לקרוא אותו

הסבר: קביעת סוגי הקלט/פלט של הפונקציה (חוזה), מקרי קצה, אילוץ שפה/גרסה וסגנון ומתן דוגמה למודל מאפשרים את המעבר מחיזוי לדיוק. בקשות 'כתוב לי את זה' חסרות הקשר מייצרות קוד שונה בכל פעם ולעיתים קרובות עוקף מקרי קצה.

4. כאשר בודקים בסיס קוד זר עם AI, שם הפונקציה עשוי להיות 'validateAndSave' אבל תקציר ה-AI עשוי להיות שגוי. מהי הגישה הנכונה?

• א) אמון מלא בסיכום הבינה המלאכותית שכן השם מובן מאליו
• ב) שינוי הפונקציה ישירות מבלי לקרוא אותה
• ג) החלטה רק על ידי הסתכלות על שם הפונקציה
• ד) התייחסו לתיאור הבינה המלאכותית כהשערה ואמת תביעות קריטיות שורה אחר שורה בקוד ✔

הסבר: בינה מלאכותית עשויה להסתכל על השם בקוד ולהגיד לך 'מה זה נראה כאילו הוא עושה', אבל במציאות ההיגיון עשוי להיות שונה (או אפילו הפוך). אז ההסבר של AI הוא השערה; תביעות קריטיות, במיוחד אלה הכרוכות באבטחה, סמכות או זרימת כסף, צריכות להיות מאומתות ויזואלית בקווים הרלוונטיים.

5. מהי הסכנה הגדולה ביותר באמירה 'AI נראה את זה, זה ברור' בסקירת קוד בסיוע בינה מלאכותית?

• א) בינה מלאכותית עשויה לייצר שליליות כוזבות; טעויות החמצה אמיתיות יוצרות ביטחון כוזב ✔
• ב) סקירת AI איטית מדי ולכן היא מבזבזת זמן
• ג) הצוות לא מבין כי ה-AI מעיר רק באנגלית
• ד) יחסי ציבור לא מתכנסים כי AI תמיד מפרש יתר על המידה

הסבר: בינה מלאכותית מייצרת גם תוצאות חיוביות שגויות (סימון בעיה שבה היא לא קיימת) וגם שליליות שגויות (חסר את הבאג האמיתי). שלילי שווא שותקים; הטעויות המסוכנות ביותר הן אלו שלא מוזכרות כלל בסקירה. אז AI הוא מסנן ראשון, לא אישור; ההחלטה על המיזוג היא של בעל דין וחשבון.

6. מהי המלכודת הכי ערמומית שמתרחשת כאשר אתה רק נותן ל-AI את הקוד ואת בדיקות ההדפסה?

• א) AI תמיד כותב יותר מדי בדיקות ומנפח את בסיס הקוד
• ב) AI בודק את ההתנהגות הנוכחית (אולי שגויה) של הקוד כ'נכונה' ומתקן את הבאג ✔
• ג) AI מוחק אוטומטית קוד בעת כתיבת מבחנים
• ד) AI כותב מבחנים לא רק עבור הנתיב המאושר אלא תמיד עבור מקרה הקצה

הסבר: בינה מלאכותית נוטה להסתכל על קוד ולכתוב קביעות הבודקות את ההתנהגות הנוכחית. אם הקוד שגוי מההתחלה, AI מתקן את ההתנהגות השגויה הזו כ'נכונה'. לכן, יש לכתוב את הציפיות מהמבחן לפי הכלל הנדרש (מפרט), ולא לפי הפלט הנוכחי של הקוד.

7. מה הכי קובע את הדיוק של השערות בעת איתור באגים עם AI?

• א) באיזה נימוס כתובה ההנחיה.
• ב) כמה פעמים נשאלה השאלה שוב
• ג) איכות הראיות שסופקו למודל: הודעת שגיאה מלאה, עקבות מחסנית, קלט והתנהגות צפויה ✔
• ד) באיזה נושא צבע נכתב הקוד?

הסבר: AI לא רואה את השגיאה כמו שאתה רואה; הוא יודע רק את ההוכחות שאתה נותן לו. בהתחשב בהודעת השגיאה המלאה, מעקב מחסנית, קלט הפעלה והתנהגות צפויה, המודל מונה את האפשרויות האמיתיות; אם אין ראיות, זה עושה ניחוש (הזיה) ומוביל אותך למסלול הלא נכון.

8. מהו השלב הקריטי ביותר לפני מתן יומני ייצור ל-AI לצורך ניתוח?

• א) הדבקת היומן כפי שהוא, מכסה את כל היום
• ב) תחילה המר יומן לאותיות רישיות
• ג) סידור שורות יומן לפי סדר אלפביתי
• ד) מיסוך נתונים וסודות אישיים ומתן רק את החלון הרלוונטי ✔

תיאור: יומני ייצור גולמיים מכילים IP, אימייל, מזהה הפעלה, אסימון ולפעמים סוד פתוח. הדבקתם בכלי AI מבלי להסוות אותם היא הפרת פרטיות חמורה. בנוסף, יש לסנן את היומן לחלון זמן צר; אבל ההכרח הראשון הוא לנקות נתונים רגישים.

9. מה צריך לעשות אם ה-AI אומר ששני אירועים התרחשו 'בו זמנית' בניתוח יומן ומכריז על אחד כגורם השורש?

• א) התעלמות מתאם כסיבתיות ואימות הטענה עם מדדים וקוד ✔
• ב) קבלת הסיבה כסופית מכיוון שבינה מלאכותית מייצרת קשר זמן
• ג) הפעלה מחדש מיידית של הרכיב הנאשם הראשון
• ד) מחיקת היומנים לחלוטין ואיסוףם שוב

הסבר: המלכודת הנפוצה ביותר בניתוח לוג היא בלבול בין מתאם לסיבתיות. קשר הזמן שנוצר על ידי ה-AI הוא רמז, לא ראיה. סיבתיות אמיתית דורשת תזמון, מנגנון, ואם אפשר, חזרתיות; יש לאמת את התביעה באמצעות מדדים וקוד.

10. מהו כלל הזהב שאינו ניתן למשא ומתן בעת ​​עיבוד מחדש עם AI ומה מבטיח אותו?

• א) הקוד צריך להיות קצר יותר; מספר השורות מבטיח זאת
• ב) אין שינוי בהתנהגות; בדיקות הלוכדות התנהגות נוכחית מבטיחות זאת ✔
• ג) הקוד מכיל הערות נוספות; AI מבטיחה זאת
• ד) כתיבה מחדש של כל הקובץ בבת אחת; הסוכן מבטיח זאת

הסבר: Refactoring הוא שיפור המבנה הפנימי של הקוד מבלי לשנות את ההתנהגות החיצונית שלו; כלל הזהב הוא שההתנהגות נשארת קבועה. מה שמבטיח את זה הוא בדיקה: רשת בדיקות הלוכדת התנהגות נוכחית לפני שינוי שלה, מוגדרת ומופעלת לאחר כל שלב. Refactoring ללא testnet הוא הימור.

11. מהו הרובד בייצור התיעוד ש-AI לא יכול לדעת ומסוכן להמציא?

• א) כיצד להפעיל את שלבי ההתקנה
• ב) רשימת פרמטרים של פונקציה
• ג) נימוק 'למה' התקבלה כך החלטה עיצובית ✔
• ד) באיזו שפה כתוב הקוד?

תיאור: בינה מלאכותית יכולה לחלץ את שכבת 'מה/איך' (מה עושה הפונקציה, איך היא מוגדרת) מהקוד; אבל הוא לא יכול לדעת את שכבת ה'למה' (הרציונל התכנוני להחלטה, הסיבה לערך הגבלה). 'סיבה' מומצאת מסוכנת יותר מחוסר הצדקה; בעל הקוד חייב להוסיף שכבה זו.

12. מה על מפתח לעשות אם הוא רוצה להדביק קובץ תצורה המכיל מפתח API חי לתוך כלי AI לא מאושר תוך פתרון באג דחוף?

• א) למהירות, הדבק את הקובץ כפי שהוא ולאחר מכן מחק את הצ'אט
• ב) הוסף הערה 'סודית' בסוף הקובץ ושלח אותה
• ג) השאר את המפתח ושנה רק את שם הקובץ
• ד) הסר/מסך סודות ותן רק הקשר נחוץ לא רגיש ✔

חשיפה: אסור להכניס סודות, נתונים אישיים ונכסים חסויים באמצעים לא מאושרים; דחיפות לא משעה את הקו האדום הזה. הגישה הנכונה היא לחלץ/להסוות קודם את הסודות ולתת רק את ההקשר הדרוש, הלא רגיש. אם סוד עדיין דולף, הדבר הראשון שצריך לעשות הוא לסובב את המפתח מיד.

13. קוד שנוצר בינה מלאכותית עובר בדיקות ורץ בייצור. האם זה מוכיח שהקוד בטוח?

• א) לא; 'עובד' לא אומר מאובטח, אבטחה דורשת שכבה נפרדת של אימות ✔
• ב) כן; קוד שעובר את המבחן בטוח בהגדרה
• ג) כן; הפעלתו בייצור מבטלת את כל הפגיעויות
• ד) לא; אבל האבטחה חשובה רק אם הקוד איטי

הבהרה: 'עבודה' אינה זהה ל'מאבטח'. גם אם הקוד מכיל פגיעות כמו הזרקת SQL, הוא יכול לעבור בדיקות ולרוץ בצורה חלקה; הפגיעות מתגלה רק כאשר תוקף מוצא אותה. לכן, בנוסף לדיוק, יש לבצע סקירה וסריקות מוכוונות אבטחה כגון SAST כשכבה נפרדת.

14. מהי הדיסציפלינה הבטוחה ביותר כאשר נותנים משימה מרובת קבצים לסוכן CLI (כלי אוטונומי שיכול לשנות קבצים ולהריץ פקודות)?

• א) לומר לסוכן 'שפר את המודול הזה' ומתן חופש מלא
• ב) מתן היקף צר וקריטריוני קבלה, בקשת תכנית תחילה, אישורה, יישום שלב אחר שלב והפעלת הבדיקות ✔
• ג) מיזוג ישירות את כל השינויים של הסוכן מבלי לבדוק אותם
• ד) מתן גישה בלתי מוגבלת לסוכן לסביבת הייצור ולנתונים חסויים

הסבר: ככל שהאוטונומיה גוברת, גם השליטה צריכה לגדול. מתן היקף צר לסוכן וקריטריוני קבלה ברורים, תחילה בקשת תכנית ללא שינויים, אישור התכנית, לאחר מכן מימושה שלב אחר שלב והפעלת בדיקות בכל שלב; זה מונע שינויים רחבים, בלתי ניתנים לבדיקה וצריך להחזיר אותם לאחור.

15. למי יש אחריות הנובעת מקוד שנוצר בינה מלאכותית בתוכנות קריטיות לאבטחה (למשל תשלום או אימות)?

• א) מכיוון שהקוד מגיע מ-AI, הוא נמצא בספק הרכב
• ב) אם AI מפותח מספיק, לאף אחד אין; אין צורך לאמת
• ג) הצוות/מהנדס הבוחן, מרכיב ומפיץ את הקוד; AI אינו מחליף הסכמה ✔
• ד) רק מי שכותב את ההנחיה, לא מי שעוסק בה

תיאור: AI הוא מכפיל מהירות ומחולל שרטוטים; לא יכול לקחת אחריות. האחריות לכל שגיאה, פגיעות או הפרות הנובעות מהקוד בייצור היא של הצוות הסוקר, מרכיב ומפיץ את הקוד הזה. באזורים קריטיים לבטיחות, פלט AI אינו מהווה תחליף לבדיקה ואישור על ידי מהנדס מוסמך בשום פנים ואופן.