1.3 מיליון שורות, 630 PRs בשבוע: איך אנחנו שומרים על קוד מבוסס Vibe שנשאר ניתן לתחזוקה

ביולי 2026, רוברט סי. מרטין כתב שהוא כבר לא קורא את הקוד שמפיקים הסוכנים שלו.

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

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

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

אנחנו מתמודדים עם אותה בעיה ב-vm0 בשמונה החודשים האחרונים. רוב המימוש במאגר שלנו נכתב ע"י סוכנים — vibe coding, בקיצור המקובל — בעוד שישה מהנדסים אחראים למה שהקוד הזה עושה בפרודקשן.

הגרסה הקצרה

vm0 הוא בסיס קוד מבוסס vibe: סוכנים כותבים את רוב המימוש, ושישה מהנדסים אחראים למה שקורה בפרודקשן. אחרי שמונה חודשים, המאגר מכיל 1,329,170 שורות וקלט 630 pull requests בשבוע אחד. חמישה מנגנונים נושאים את עול האיכות שביקורת שורה-אחר-שורה כבר לא יכולה לשאת לבד.

• סביבות אחידות. מהנדסים וסוכנים עובדים באותו dev container, וכל pull request יכול לקבל ענף מסד נתונים משלו. פקודה שעבדה לסוכן תעבוד גם לאדם.
• הגבלות ניתנות להרצה. TypeScript קפדני, כ-135 מודולי חוזה API מוקלדים, Oxlint, ESLint וחוקי ארכיטקטורה, כאשר CI לא מקבל אזהרות. חוק שניתן לבדוק מכנית לא נשאר לביקורת.
• בדיקות ממוקדות גבול. גביע בדיקות במקום פירמידה: בדיקות אינטגרציה דרך גבולות מודולים ציבוריים, PostgreSQL אמיתי ומיגרציות אמיתיות, mocks רק במערכות חיצוניות. קוד בדיקות הוא כ-36 אחוז מהמאגר.
• לולאות משוב שלמות. סוכנים מעלים את האפליקציה והמסד, מריצים מיגרציות, מפעילים דפדפן אמיתי, ואז מדווחים אילו פקודות הריצו, איזה מסלול נבדק וצילומי מסך. ה-PR החציוני מתמזג בכ-53 דקות.
• ניקוי מתמשך. Knip מסיר קוד מת, workflows יומיים מנקים שאריות AI שאף linter לא מזהה, ודפוס שחוזר מספיק פעמים הופך לחוק lint או מוקלד.

מה המשמעות של vibe coding ו-agentic coding

Vibe coding הוא לתת prompt ל-LLM עבור קוד, להריץ את מה שהוא מחזיר, לבקש שינויים, ולא להתייחס לקוד שנוצר. ההגדרה של מרטין פאולר מצומצמת במכוון, והוא מדגיש את הביטוי "לשכוח שהקוד בכלל קיים." זה מתאים לאבטיפוסים, תוכנה חד-פעמית וכלים עם השלכות מוגבלות.

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

ההבדל אינו כמה מהקוד המודל כותב, אלא לאן מופנית תשומת הלב האנושית.

	Vibe coding	Agentic coding
אוטונומיית סוכן	prompt, הרצה, prompt נוסף	קורא מאגר, עורך, בודק, חוזר
מי קורא את הקוד	אף אחד	אנשים קוראים מה שנושא סיכון
מה מאומת	האם הפלט נראה נכון	טיפוסים, חוזים, בדיקות, תצוגות, אותות פרודקשן
התאמה מיטבית	אבטיפוסים וכלים חד-פעמיים	תוכנה עם אופק תחזוקה
כשל אופייני	קוד שאף אחד לא מבין	אימות חלש מדי לנפח

סוכנים שעורכים מאגר הם ענף אחד של שינוי רחב יותר; בחנו את הצד הלא-מפתח בנפרד.

לעיתים קרובות אנו מכנים את vm0 פרויקט vibe-coded כי זה הפך לקיצור נפוץ לתוכנה שנכתבה בעיקר ע"י AI. במונחי פאולר זה קרוב יותר ל-agentic coding. המהנדסים שלנו מקלידים פחות מהמימוש מבעבר, אך ממשיכים להיות אחראים לארכיטקטורה, עלות תחזוקה והתנהגות בפרודקשן.

כשהפקת קוד הפכה מהירה יותר, יותר מהאחריות עברה לסביבת הפיתוח, מערכת הטיפוסים, סט בדיקות ו-workflows אוטומטיים לתחזוקה.

שמונה חודשים של צמיחה בבסיס קוד vibe-coded

מאגר vm0 נוצר בנובמבר 2025. בזמן דוח קנה המידה ההנדסי השבועי האחרון, היה בן כשמונה וחצי חודשים.

המאגר כלל:

מדד	כמות
שורות לוגיות לא ריקות	1,329,170
שורות ייצור	850,913
שורות בדיקה	478,257
קבצי מקור	5,549
קבצי בדיקה	1,327
חבילות	44
קומיטים בענף הראשי	14,005

הנתונים מגיעים מדוח קנה המידה השבועי לשבוע של 20–26, 2026, נמדדו ישירות מה-monorepo. קוד בדיקות היווה כ-36 אחוז מהקוד הנמדד. זהו נפח קוד, לא כיסוי בדיקות, אך נותן מושג כמה מימוש נאגר סביב אימות.

בשלושה שבועות מלאים אחרונים, שישה מהנדסים ביצעו 541, 640 ו-631 קומיטים בהתאמה. בשבוע של 20–26 ביולי, GitHub רשם 630 pull requests ממוזגים. שישה מהנדסים כתבו 556 מהם, ואוטומציית שחרור את 74 הנותרים.

הזמן החציוני מפתיחת pull request ועד מיזוגו היה כ-53 דקות. הפרסנטיל ה-90 היה כ-7.4 שעות.

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

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

איחוד סביבת הפיתוח עם dev containers

רבות מהכשלים שקשה לשחזר נובעות ממצב שאינו מופיע ב-pull request.

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

בהדרגה הפסקנו להתייחס למכונת המארח כסביבת הפיתוח הסטנדרטית. מהנדסים וסוכנים עובדים בתוך dev container. דמות הפיתוח כוללת את כלי הפרויקט, PostgreSQL, pgvector, Chromium וכלי אוטומציית דפדפן.

CI מריץ דמויות toolchain מגרסאות שנבנות מאותה משפחת Dockerfile מרובת שלבים. לדמויות הפיתוח ו-CI יש מטרות שונות, ולפרודקשן יש צורת פריסה משלו. התכונה החשובה היא איחוד: גרסאות כלים, תלויות והנחות ריצה הן מפורשות ומנוהלות בגרסאות.

זה נותן לנו ציפייה ברורה. פקודות שסוכן מריץ צריכות להיות ניתנות לשחזור ע"י מהנדס באותו dev container. בדיקות שעוברות בפיתוח צריכות לרוץ תחת toolchain דומה ב-CI.

אנו מיישמים רעיון דומה גם לנתונים. לכל preview של pull request יכול להיות ענף מסד נתונים משלו, להריץ מיגרציות אמיתיות ושלבי seed. סוכן יכול ליצור נתונים, לשנותם ולבצע בדיקות הרסניות בלי להסתמך על מסד נתונים של מפתח אחר או לרשת מצב מ-pull request אחר.

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

הפיכת סטנדרטים הנדסיים להרצה בטיפוסים וחוקי lint

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

אנחנו מכניסים חוקים יציבים למערכת הטיפוסים, linters ו-CI בכל פעם שהחוק ניתן לביטוי אמין.

vm0 משתמשת בהגדרות TypeScript קפדניות, כולל strict ו-noUncheckedIndexedAccess. חלק מהחבילות מאפשרות בדיקות נוספות לערכים לא בשימוש והחזרות משתמעות.

ה-API משתמש בשכבת חוזה REST מוקלדת בגישת schema-first שנבנתה עם מנגנון הטיפוסים של tRPC ועם סכמות Zod. Drizzle מחבר גישה למסד נתונים לטיפוסי TypeScript. בזמן סקירה זו, המאגר כלל כ-135 מודולי חוזה.

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

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

כשבעיה חוזרת, אנו בוחנים היכן לבדוק אותה:

1. האם מערכת הטיפוסים יכולה לבטא אותה?
2. האם לינטר או כלי מבני יכולים לזהות אותה במדויק?
3. האם היא דורשת שיפוט סמנטי על פני המאגר?

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

צמצום דפוסים מועדים לטעויות בקוד שנוצר ע"י AI

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

try/catch עלול לטשטש גבול שגיאה. כשסוכן נתקל בכשל, הוספת בלוק catch ו-fallback היא דרך קלה להמשיך את המסלול הנוכחי תוך אובדן השגיאה המקורית. שילוב Promise .then() ו-.catch() עם async/await מפזר זרימת בקרה בין כמה סגנונות.

useEffect של React יוצר בעיה דומה בניהול מצב. הוא משמש לעיתים להעתקת מצב, סנכרון שני מקורות אמת או קידוד תלות סדר שקשה לראות ממודל הנתונים.

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

קוד הייצור בפלטפורמת ה-web המרכזית אינו מכיל כיום useEffect. אנו משתמשים ב-ccstate ודפוסים נטולי תופעות לוואי כדי למפות תלות ותופעות לוואי במפורש. מספר קטן של קריאות useEffect בייצור עדיין קיים במקומות אחרים ב-monorepo, בעיקר בקוד UI משותף וקוד דסקטופ, לכן היקף הטענה חשוב.

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

בדיקות בגבולות מודולים: גביע בדיקות, לא פירמידה

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

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

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

התשתית הפנימית נשארת אמיתית כל עוד העלות סבירה:

• PostgreSQL ו-pgvector
• מיגרציות מסד נתונים
• מערכת קבצים
• שירותים פנימיים
• mocks בגבולות מערכות חיצוניות

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

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

Uncle Bob מעדיף תמהיל אחר, עם שימוש כבד בבדיקות יחידה, Gherkin ובדיקות מוטציה. העיקרון המשותף הוא אימות עצמאי. התהליך שיצר את הקוד לא צריך להיות המקור היחיד שטוען שהקוד עובד.

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

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

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

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

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

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

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

איכות עבודת הסוכן תלויה מאוד במשוב שהוא יכול לקבל מבלי להמתין לאדם.

שמירה על ענפים קצרים עם trunk-based development

הפקת קוד מהירה יכולה ליצור מלאי גדול של ענפים.

ענפי פיצ'ר ארוכי טווח צוברים קונפליקטים, עבודה כפולה והקשר מיושן. ככל שה-pull request גדל, הביקורת קשה ואיטית יותר. אנו משתמשים ב-trunk-based development כדי לשמור על ענפים קצרים ולשלב ברציפות סביב main.

חוקי הענף הראשי שלנו דורשים:

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

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

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

Knip כאיסוף אשפה למאגר: הסרת קוד מת

הפקת קוד מוסיפה קבצים ומופשטות. מחיקה לרוב דורשת prompt נפרד.

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

אנו משתמשים ב-Knip למציאת קבצים, יצוא, תלויות ונקודות כניסה לא בשימוש. TypeScript מאשר שהקוד תקין; Knip שואל האם הוא עדיין משתתף במערכת.

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

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

Workflows חוזרים לניקוי שאריות AI

ל-Knip ו-ESLint יש גבולות ברורים. צורות רבות של התדרדרות דורשות הקשר פרויקט ושיפוט סמנטי.

אנו משתמשים ב"AI slop" כתווית מעשית לשאריות אלו: fallbacks מיותרים, הפשטות כפולות, בדיקות שעוקפות גבול ציבורי או ענפים מגוננים למצבים בלתי אפשריים. כל מופע נראה לא מזיק. במצטבר, הם מקשים על הבנת המאגר ונותנים לסוכנים הבאים דוגמאות גרועות.

כמה workflows קבועים של vm0 סורקים דפוסים אלו בלו"ז קבוע.

ניקוי יומי של AI-slop מחפש שאריות חדשות ובוחר סט קטן של תיקונים בסיכון נמוך ובביטחון גבוה. Workflows אחרים בודקים בדיקות API שנוגעות בשירותים פנימיים, אנטי-דפוסים ב-React ו-ccstate וחוב טכני שניתן לטפל בו בבטחה.

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

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

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

הפיכת כשלי בדיקות רופפות לתיקונים אוטומטיים

קבוצת workflows נוספת מתחילה מכשלים ב-GitHub Actions.

כשבדיקה נכשלת בענף הראשי או בתור המיזוג, workflow קורא את הלוגים, בודק עדויות לרופפות, ובוחן ניסיונות חוזרים, תזמונים ופקטורים סביבתיים. אם העדויות תומכות בתיקון מסוים, הוא מעדכן את הבדיקה או המימוש, פותח pull request ומריץ שוב את כל מסלול ה-CI.

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

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

מערכת האיכות שלנו כיום כוללת שלוש שכבות עיקריות:

שלב	מנגנונים	דאגות אופייניות
בזמן כתיבה	TypeScript, חוזים, Drizzle, ESLint	שגיאות טיפוס, סטיית ממשק, דפוסי קוד מוכרים
לפני מיזוג	Knip, בדיקות אינטגרציה, מסדי נתונים אמיתיים, תצוגות, תור מיזוג	קוד מת, התנהגות מודול, תוצאות ריצה מלאות
אחרי מיזוג	workflows של vm0 מתוזמנים ומבוססי אירועים	שאריות AI, אנטי-דפוסים סמנטיים, בדיקות רופפות, סטיית ארכיטקטורה

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

לאן מופנית תשומת הלב האנושית בביקורת קוד שנוצר ע"י AI

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

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

כמה החלטות עדיין דורשות שיפוט מנוסה:

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

שינוי דומה התרחש גם בצד העיצוב, שם design-as-code העביר החלטות ויזואליות לאותו מאגר ואותו מסלול ביקורת. מהנדסים גם מתחזקים את הסביבה סביב הסוכנים. כשבעיה חוזרת, אנו מחליטים האם להוסיף הגבלת טיפוס, חוק lint, בדיקה או workflow חוזר. מערכת הפיתוח הפכה לארכיפקט הנדסי חשוב בפני עצמו.

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

אבטחה והשינויים שלא מואצים

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

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

• בדיקות יחידה, שבדרך כלל אנו משתמשים בהן במשורה, משמשות במכוון ללוגיקה רגישה לאבטחה, אלגוריתמים ומכונות מצבים.
• בדיקות עושות mocks רק בגבולות מערכות חיצוניות. תשתית פנימית נשארת אמיתית, כך ששינוי ששובר חוזה פנימי נכשל ב-CI ולא בפרודקשן.
• סוכנים עובדים בתוך dev container מול ענף מסד נתונים לכל pull request, לא על מכונת מפתח ולא על מסד נתונים משותף.
• תור המיזוג והבדיקות הנדרשות לא נעקפים בשגרה, גם לא ל-pull request שסוכן פתח וסימן למיזוג אוטומטי.
• try/catch מוגבל כברירת מחדל, כך שכשל פחות סביר שייבלע ע"י fallback שסוכן הוסיף כדי להמשיך מסלול.

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

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

מה המספרים האלו לא מראים

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

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

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

שאלות נפוצות

מה זה vibe coding? Vibe coding הוא לתת prompt ל-LLM עבור קוד, להריץ את מה שהוא מחזיר, לבקש שינויים ולא לקרוא את הקוד שנוצר. ההגדרה של מרטין פאולר מצומצמת בכוונה: המפתח אמור "לשכוח שהקוד בכלל קיים." זה מתאים לאבטיפוסים, תוכנה חד-פעמית וכלים עם השלכות מוגבלות.

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

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

מה זה AI slop? AI slop הוא השאריות שקוד שנוצר ע"י AI משאיר: fallbacks מיותרים, הפשטות כפולות, בדיקות שעוקפות גבול ציבורי, ענפים מגוננים למצבים בלתי אפשריים. כל מופע נראה לא מזיק. במצטבר הם מקשים על הבנת המאגר ונותנים לסוכן הבא דוגמאות גרועות.

איך בודקים קוד שנוצר ע"י AI ב-630 pull requests בשבוע? לא שורה-שורה. ב-vm0, ביקורת אנושית מתמקדת היכן שנדרש שיפוט: ארכיטקטורה, עבודה רגישה לאבטחה, תשלומים, מיגרציות נתונים. כל השאר נתמך ע"י מנגנונים: טיפוסים וחוזים קפדניים, בדיקות אינטגרציה בגבולות מודול, מסדי נתונים אמיתיים ב-previews, אימות דפדפן, Knip ותור מיזוג שאף שינוי לא עוקף בשגרה.

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

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

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

כמה מהקוד של vm0 נכתב ע"י AI? רוב המימוש. שישה מהנדסים כתבו 556 מתוך 630 ה-pull requests שמוזגו בשבוע של 20–26 ביולי, 2026, כאשר אוטומציית שחרור כתבה את השאר, והסוכנים כתבו את רוב הקוד בתוך אותם pull requests. מה שהמהנדסים מחזיקים בו הוא הארכיטקטורה, ההגבלות וההתנהגות בפרודקשן.

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

איך מוצאים קוד מת במאגר שנכתב ע"י AI? הפקת קוד מוסיפה קבצים והפשטות; מחיקה לרוב דורשת prompt נפרד. vm0 מריצה את Knip כבדיקה שגרתית למציאת קבצים, יצוא, תלויות ונקודות כניסה לא בשימוש. TypeScript מאשר שהקוד תקין; Knip שואל האם הוא עדיין משתתף במערכת, וזו השאלה החשובה לקוד מת.

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

שמונה חודשים בפנים

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

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

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

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