איך להגיע למצב ירוק עם AI בלי להרוס את הקוד

Test until green

Repair loop ממושמע

1. מה זה בעצם מצב ירוק

מצב ירוק הוא לא רק build שעובר. הוא מצב שבו אפשר להסביר:

• מה שינית
• למה השינוי היה נכון
• אילו בדיקות כיסו אותו
• מה עדיין עלול להישבר לידו

כש-AI עוזר לכתוב, לערוך או לתקן, הפיתוי הוא להתייחס לכל כשל כמו תקלה מקומית. בפועל, הרבה מהכשלים נובעים מזה שהשינוי כבר הפסיק להיות קטן וברור.

2. קודם לזהות מה נשבר

ה-loop הכי מזיק נראה בערך כך:

1. טסט נופל
2. שולחים את השגיאה למודל
3. המודל מתקן משהו
4. טסט אחר נופל
5. חוזרים על התהליך

זה נראה יעיל. בדרך כלל זאת דרך מנומסת לאבד שליטה על הקשר הסיבתי.

לפני כל תיקון, צריך להכריע איזו משכבה באמת נשברה:

• קוד המוצר
• הטסט
• חוזה API או schema
• הנחת סביבה
• dependency צדדי

אם לא יודעים את זה, המודל רק ממלא מקום שבו השיפוט נעדר.

3. דיפים קטנים עדיין מנצחים

AI יכול לייצר יותר קוד בדקה. הוא לא ביטל את הכלל הישן שלפיו דיפים קטנים יותר בטוחים יותר.

דיף קטן נותן:

• blast radius קטן יותר
• רוורס קל יותר
• review ברור יותר
• קלות גבוהה יותר להבין אם הבעיה נפתרה או רק זזה הצידה

אם השינוי גדול מכדי להסביר אותו בשני משפטים, יש סיכוי טוב שהוא גדול מדי בשביל repair loop מהיר.

4. מתי לתקן טסט ומתי לתקן קוד

יש כאן בלבול קבוע.

המודל רואה failing test ומציע לעדכן assertion. לפעמים זה נכון. לפעמים זאת רק דרך אלגנטית להשתיק אזעקה.

אני מתקן טסט רק אם אחד מהדברים הבאים נכון:

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

בכל מצב אחר, ברירת המחדל היא לחשוד קודם בקוד.

5. איפה AI באמת עוזר

AI עוזר היטב ב:

• boilerplate חוזר
• scaffolding ראשוני
• רפקטור טכני צר
• הצעות לטסטים חסרים
• הסבר מהיר של שגיאה לא מוכרת
• איתור מקומות סמוכים שעשויים להיפגע

הוא עוזר הרבה פחות ב:

• קביעה אם שינוי עקרוני הוא נכון
• ניהול פשרה בין correctness, product intent ו-maintainability
• החלטה אם בכלל צריך את abstraction החדש
• הבחנה בין “עובר” לבין “אפשר לסמוך על זה”

6. AI לא מחליף ownership

הטעות הגדולה ביותר היא לא קוד גרוע. היא העברת ownership לכלי.

ברגע שהflow נהיה “המודל יסדר”, אף אחד כבר לא מחזיק באמת את התוצאה. זה מורגש מהר:

• commit messages נהיים עמומים
• rationale נעלם
• tests עוברים אבל האמון יורד
• רגרסיות מתחילות להרגיש מקריות

AI טוב בפיתוח כשהוא משמש כתוספת ל-owner ברור. לא כתחליף.

7. Repair loop טוב נראה משעמם

הגרסה הבריאה נראית ככה:

1. להבין את ה-failure class
2. לצמצם את השינוי
3. להריץ את הבדיקה הקרובה ביותר
4. להרחיב רק אחרי שהשכבה הראשונה יציבה
5. לעצור אם צריך rewrite קטן במקום עוד patch

זה לא נשמע נוצץ. גם טוב.

סיכום

המטרה היא לא להגיע לירוק מהר ככל האפשר. המטרה היא להגיע לירוק בלי להפוך את הריפו לסדרה של פשרות שאף אחד כבר לא בטוח בהן.

במובן הזה, AI לא ביטל את המשמעת הישנה. הוא רק הפך אותה ליקרה יותר כשהיא חסרה.