Alex ChernyshAlex ChernyshAgentic behaviorist · תל אביב
כתיבהעוזר
חזרה לכתיבה

הערה

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

איך להשתמש ב-AI בתוך תהליך פיתוח בלי להפוך green build למשחק ניחושים ובלי לשחוק את הריפו.

4 במרץ 2026·3 דק׳ קריאה
Delivery
בעמוד הזה(8)
מה זה בעצם מצב ירוקקודם לזהות מה נשברדיפים קטנים עדיין מנצחיםמתי לתקן טסט ומתי לתקן קודאיפה AI באמת עוזרAI לא מחליף ownershipRepair loop טוב נראה משעמםבסוף

הבעיה ב-AI-assisted development היא כמה מהר אפשר לשכנע את עצמך שהכול ירוק, אחרי שהקוד כבר איבד צורה.

ברירת המחדל

משתמשים ב-AI כדי לקצר עבודה משעממת, לא כדי לוותר על שיפוט הנדסי. Green state שלא ברור איך הגעת אליו לא שווה את האמון.

מה מחזיק ריפו בריא

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

Test until green

Repair loop ממושמע

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

מצב ירוק הוא יותר מ-build שעובר. הוא מצב שבו אפשר להסביר מה שונה, למה השינוי היה נכון, אילו בדיקות כיסו אותו ומה עדיין עלול להישבר לידו.

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

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

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

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

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

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

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

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

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

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

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

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

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

AI לא מחליף ownership

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

מורגש מהר. commit messages נהיים עמומים, rationale נעלם, טסטים עוברים אבל האמון יורד, רגרסיות מתחילות להרגיש מקריות. AI עובד כשהוא תוספת ל-owner ברור.

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

הגרסה הבריאה: להבין את ה-failure class, לצמצם את השינוי, להריץ את הבדיקה הקרובה ביותר, להרחיב רק אחרי שהשכבה הראשונה יציבה, לעצור אם צריך rewrite קטן במקום עוד patch.

לא נוצץ. גם טוב.

כללים פרקטיים

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

בסוף

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

✓ Reading complete

Alex ChernyshAlex ChernyshApplied AI Systems & Platform Engineer

עוד על Delivery

חלק מהערות ציבוריות על מערכות AI עם grounding, retrieval, evals ועל איך שולחים את זה תחת מגבלות אמיתיות.

  • →מחפשים עבודה? תלגמו לאט. אנחנו נחפש בשבילכם.23 באפר׳ 2026·4 דק׳ קריאה
  • →הרצתי 12 סוכני AI במשך 47 שעות. הנה מה ששרד.29 במרץ 2026·6 דק׳ קריאה
  • →לבנות מערכות Agentic שמחזיקות מעמד2 במרץ 2026·4 דק׳ קריאה
בעמוד הזה
  • 01מה זה בעצם מצב ירוק
  • 02קודם לזהות מה נשבר
  • 03דיפים קטנים עדיין מנצחים
  • 04מתי לתקן טסט ומתי לתקן קוד
  • 05איפה AI באמת עוזר
  • 06AI לא מחליף ownership
  • 07Repair loop טוב נראה משעמם
  • 08בסוף