מה למדתי מה-live session של בוריס צ'רני

ראיתי את ה-live coding session של בוריס צ’רני (Head of Claude Code ב-Anthropic) עם ג’ארד סאמנר (יוצר Bun). רציתי ללמוד ממנו הכל, אז עשיתי את הדבר המתבקש: ביקשתי מ-Claude ומ-Codex לנתח את הוידאו בנפרד, ואז שילבתי את התשובות שלהם יחד עם Claude. מה שלמטה זה מה ש-Claude הרכיב — ההסבר שלו, ה-timeline והסיכום של Codex, כולל החלקים שביקשתי להשאיר.

לצפייה בוידאו המקורי ב-YouTube.

---

מ”כתוב את הקוד” ל”בנה את ה-loop”

ניתוח של live coding session שבו צוות Bun מדגים איך הם מריצים את Claude Code בסקייל באמצעות הבוט שלהם, RoboBun. משלב את ההסבר של Claude עם ה-timeline והסיכום של Codex.

תוכן עניינים

1. מה זה RoboBun בעצם
2. ה-bottleneck שזז → merge confidence
3. ה-Merge Confidence Stack (איך להחליט אם למרג’)
4. Adversarial review ומי מתקן את הקומנטים
5. CLAUDE.md כזיכרון תפעולי
6. Self-verification: איך agents מוכיחים את העבודה של עצמם
7. Hill climbing
8. כלים: auto mode, no-flicker
9. הכללה מעבר ל-Bun
10. תוכנית פעולה
11. ה-timeline ורעיונות מפתח של Codex

1. מה זה RoboBun בעצם

RoboBun הוא בוט מותאם שצוות Bun בנה לעצמו — לא feature שמתקינים מ-Anthropic. זה GitHub webhook + Claude Code SDK + ה-CI שלהם, חוטים זה לזה. השם הוא סתם כינוי. את היית בונה לעצמך משהו מקביל (RoboPBF, RoboBitclick) — אותה תבנית, glue אחר.

על כל issue חדש ב-GitHub הוא עושה אוטומטית:

1. מעלה container
2. מנסה לשחזר את ה-bug
3. כותב test שנכשל ותופס את ה-bug
4. כותב fix
5. מאמת שה-test נכשל ב-main ועובר ב-branch של ה-fix (gate קשיח — בלי זה לא נפתח PR)
6. פותח PR
7. מתקדם ב-loop מול בוטי ה-review עד שהקומנטים נסגרים

התוצאה: RoboBun הוא היום ה-contributor הכי גדול ל-Bun, אפילו לפני ג’ארד עצמו (commits ל-main, שלושת החודשים האחרונים) — וזה כשרוב ה-PRs שלו לא ממורג’ים.

למה container חדש לכל issue?

• בידוד — issue אחד לא רואה את הקבצים או ה-state של אחר; שחזורים לרוב דורשים התקנה נקייה.
• מקבילות — 50 issues בלילה = 50 containers, בלי קונפליקטים.
• בר-זריקה — שחזור נכשל? לזרוק את ה-container, בלי ניקיון.
• שחזוריות — ה-container הוא סביבת השחזור שאחרת מתחזק היה בונה ביד.

2. ה-bottleneck שזז → merge confidence

העיקרון: אל תייעלי את מה שכבר קל. בכל פעם שפותרים bottleneck, צץ חדש — אחרי הצץ הזה.

תקופה	Bottleneck	נפתר על ידי
עבר	להגיע לקוד שעובד	מודלים טובים יותר
לאחרונה	לדעת אם הקוד נכון	Self-verification (גישה ל-tests, ל-CI)
עכשיו	Merge confidence — איזו הוכחה אני צריכה?	לא נפתר (הנושא של §3)
הבא	תכנון וטעם — מה בכלל לבנות?	עדיין עבודה אנושית כבדה

3. ה-Merge Confidence Stack

איזו הוכחה מצדיקה לחיצה על merge? חמש שכבות של ראיות. כולן ירוקות → merge. משהו חסר → לחקור.

שכבות 1–4 מתאימות למה שמתואר בוידאו. שכבה 5 היא תוספת של Claude — לא בוידאו (היגיינת PR כללית).

שכבה 1 — הוכחת test (הרצפה)

• test שתופס את ההתנהגות החדשה / ה-bug
• נכשל ב-main (מוכיח שה-test באמת בודק את הדבר — לא טאוטולוגיה)
• עובר ב-branch (מוכיח שהשינוי עובד)
• במקום הנכון, dependencies אמיתיים — לא mocks של הדבר הנבדק

בלי שכבה 1, לעולם לא למרג’. גם אם ה-diff נראה מושלם.

שכבה 2 — הוכחת CI

• כל ה-suite ירוקה ב-branch; lint, typecheck, build כולם ירוקים
• ירוק בריצה הראשונה — בלי flaky retries
• ה-coverage לא ירד על קבצים שהשתנו

שכבה 3 — הוכחת adversarial review

• שני reviewers עצמאיים (prompts שונים, רצוי vendors שונים) רצו
• כל קומנט נסגר עם fix commit, או נדחה עם נימוק
• אף reviewer לא באמצע שיחה

שכבה 4 — הוכחה התנהגותית (זו שרוב האנשים מדלגים עליה)

• השינוי באמת רץ ב-instance חי — endpoint נקרא ב-curl, כפתור נלחץ, query רץ מול DB אמיתי
• ה-output שנצפה תואם למצופה
• UI: יש screenshot של ה-state החדש. דאטה: ה-row נבדק אחרי.

שכבות 1–3 מאמתות קוד. שכבה 4 מאמתת התנהגות. זה המשמעות של “self-verification”.

שכבה 5 — הוכחת blast radius (תוספת של Claude, לא בוידאו)

• גודל ה-diff תואם ל-issue — אין scope creep
• אין קבצים לא קשורים שנגעו בהם; אין dependencies חדשים בלי הצדקה
• יש מסלול rollback (revert בודד, בלי migrations שאי אפשר להפוך)

חוק ההכרעה

כל 5 השכבות ירוקות                              -> merge
שכבה 4 חסרה אבל 1,2,3,5 ירוקות והשינוי טריוויאלי -> merge
שכבה 1 או 2 חסרה                                -> אף פעם לא למרג'
שכבה 3 חסרה                                     -> אל תמרגי אלא אם קראת כל שורה בעצמך
שכבה 5 חשודה                                    -> אל תמרגי גם אם השאר ירוק (scope creep מסתיר PR-ים גרועים)

חשוב: ל-Bun אין auto-merge. אדם לוחץ על הכפתור בכל פעם. הבוט פשוט הופך review של 30 דקות ל-5 דקות. הרף עבר מ”האם הקוד הזה עובר?” ל”האם אני סומכת מספיק על האימות?“

4. Adversarial review ומי מתקן את הקומנטים

למה CodeRabbit וגם Claude — ולא שני Claudes?

• התמחויות שונות. CodeRabbit: סטייל, קונבנציות, התאמה ל-CLAUDE.md, ריחות אבטחה. Claude review: עוקב אחרי control flow, מוצא edge cases עמוקים מעבר ל-diff.
• שגיאות לא מתואמות. שתי מערכות שונות חולקות פחות נקודות עיוורון משני instances של אותו מודל. ערבוב vendors = מודי שגיאה עצמאיים.

אפשר לשחזר את רוב זה עם שני Claudes ב-prompts מאוד שונים (אחד “auditor של סטייל,” השני “צייד של לוגיקה”). CodeRabbit פשוט מגיע מוכן (~$15 לחודש לrepo). לא קסום — בר-החלפה.

מי מתקן את הקומנטים?

RoboBun (בוט הסופר) מתקן אותם. ה-reviewers מגיבים; RoboBun קורא קומנטים חדשים ב-PR של עצמו, דוחף commits שמטפלים בכל אחד, וסוגר את השרשורים.

RoboBun פותח PR
  -> CodeRabbit:    "זה O(n^2), השתמשי ב-map"
  -> Claude review: "מפספס את ה-null case בשורה 47"
  -> RoboBun קורא את שניהם, דוחף fix commit, סוגר את שניהם
  -> חזרה עד שה-reviewers מפסיקים להגיב

המשפט של בוריס: “תגובה היא הופעה, תיקון הוא העבודה.” הבוט לא כותב “תפיסה טובה, אתקן” — הוא פשוט דוחף את התיקון. תשובה בקוד, לא במילים.

5. CLAUDE.md כזיכרון תפעולי

ברמת ה-project, לא גלובלי. ה-CLAUDE.md הגלובלי = העדפות אישיות. CLAUDE.md של project = עובדות ספציפיות ל-project שאם מפספסים אותן, זה עולה סיבוב של PR.

מה ש-CLAUDE.md של project / הוראות agent צריך לכלול:

• איך לבנות את ה-project
• איך להריץ את ה-tests המדויקים שהשתנו
• איך להריץ CI מלא לוקלית אם אפשר
• איפה ה-tests יושבים
• איך לקרוא ל-tests
• שגיאות נפוצות שה-agents עושים
• מפת ארכיטקטורה / תיקיות
• פקודות שמונעות builds ישנים
• פורמט PR צפוי
• הגדרה של “done”

דוגמה קונקרטית מ-Bun: הם גרמו ל-test harness להדפיס את הודעת השגיאה לפני ה-assertion הפחות אינפורמטיבי, כדי ש-Claude יראה מה באמת נכשל. הפרט הזה הגיע מצפייה ב-Claude כותב tests גרועים פעם-פעמיים, ואז הם רשמו את הלקח. בוריס קורא לזה compound engineering.

6. Self-verification: איך agents מוכיחים את העבודה של עצמם

“Agents יכולים לרוץ באוטונומיה רק אם הם יכולים לאמת את עצמם.” לפני שאומרים “done,” ה-agent חייב להיות מסוגל להוכיח שזה עובד. תנו לו את היכולות:

1. להריץ את ה-build, לראות שגיאות
2. להריץ tests, לראות pass/fail
3. להריץ את האפליקציה עצמה, לדפוק על endpoint, לראות output אמיתי
4. לקרוא CI (gh run view <id> --log-failed)
5. לקרוא את ה-logs של עצמו בזמן הבדיקות

לעבודת UI, להוסיף:

6. לצלם screenshots (chrome-cdp / playwright)
7. להשוות לפני/אחרי ויזואלית

Bun מקבל את זה כמעט בחינם: כ-CLI, הבינארי עצמו הוא ה-runtime — מריצים, וזה אמיתי. המהלך הפרקטי לכל project: verify script שמריץ את כל השרשרת מקצה לקצה, עם הפנייה ב-CLAUDE.md בסגנון “לפני שאומרים done, להריץ ./verify.”

7. Hill climbing

לא feature — תבנית prompt. תני למודל (א) מטריקה, (ב) דרך למדוד אותה, (ג) רשות לעשות איטרציות. ואז להתרחק ב-auto mode.

מטרה:    להפוך את X למהיר מ-Y
מדידה:   להריץ `bench/sharp-comparison.ts`, לפרסר את ה-output
תקציב:   להמשיך עד 20% מעל ה-baseline, או 50 ניסיונות

ה-loop: להריץ benchmark → להעלות השערה → ליישם → להריץ שוב → לשמור אם השתפר, להפוך אם הורע → לחזור. בדמו ג’ארד אמר “תעשה את ספריית התמונות הזו מהירה יותר מ-Sharp,” נתן benchmark על קופסת Linux ושני רמזים, ו-Claude עשה איטרציות עד הניצחון. בוריס אומר ש-4.7 הוא המודל הראשון שיעיל מספיק כדי לעשות את זה ביום-יום — והוא בלתי מנוצל. ה-skill הגלובלי /loop יכול להניע את זה.

8. פרטי כלים

• Auto mode — אישור אוטומטי של permissions. הפתרון האמיתי ל”הלכתי, חזרתי, Claude חיכה ל-prompt.” מחליף את --dangerously-skip-permissions המסוכן יותר. מאפשר sessions שרצים שעות / לילה שלם.
• No-flicker mode — CLAUDE_NO_FLICKER=1. renderer שנכתב מחדש עם virtualized scroll/selection: זיכרון ו-CPU קבועים, לחיצות עכבר עובדות ב-composer. הושק ב-1 באפריל, נראה כמו בדיחה; בוריס חושב שזה צריך להיות ברירת המחדל.
• /loop למוניטורינג — ג’ארד גרם ל-Claude לעקוב אחרי PR ב-wake interval של 20 דקות (מודה שזה יותר מדי).

9. הכללה מעבר ל-Bun

רוב החברות לא open source, אז “GitHub issue → bot” לא חל ישירות. התרגום:

טיקט תמיכת לקוחות -> Claude bot -> שחזור -> PR -> adversarial review loop

אותה צורה, inbox שונה. בשבילי ה-input הכי טבעי הוא Linear (כבר מחובר דרך MCP): skill שעוקב אחרי label כמו claude-fix ומריץ את ה-loop — זה המקבילה ל-RoboBun. הודעות ה-WhatsApp של אבי על באגים ב-BitClick הן candidate נוסף.

למה projects של CLI/systems קלים יותר: שחזוריות חזקה (פקודה נכנסת, output יוצא, tests ספציפיים לארכיטקטורה). אפליקציות UI צריכות אימות מקביל — screenshots, וידאו, בדיקות דפדפן.

10. תוכנית פעולה

א. Adversarial PR review. להרחיב את /land כדי להעלות שני reviewer agents (auditor של סטייל + צייד לוגיקה), והבוט הסופר מתקן את שני הסבבים לפני שאני רואה. או להתקין CodeRabbit על ה-repos.

ב. Gate של “נכשל ב-main, עובר ב-branch.”

git stash; git checkout main
bun test path/to/new-test.ts   # חייב להיכשל
git checkout fix-branch; git stash pop
bun test path/to/new-test.ts   # חייב לעבור

מקומו ב-skill של reproduce-bug כצעד אימות לפני הצהרת הצלחה.

ג. CLAUDE.md כגלאי חזרות. אחרי כל session: “האם ה-agent עשה טעות שתיקנתי?” → שורה אחת ל-CLAUDE.md של ה-project. להריץ claude-md-improver חודשי לכל project.

ד. Hill-climb skill. עטיפה קטנה של /hill-climb: inputs של מטרה + פקודת מדידה + סף, ואז loop אוטומטי. ~30 שורות.

ה. מקבילה ל-RoboBun ל-Linear. עוקב אחרי label ב-Linear → sandbox → שחזור → test שנכשל → fix → PR. הכי משתלם, הכי הרבה עבודה מקדימה.

11. ה-timeline ורעיונות מפתח של Codex

Timeline

• 1:27–2:34 הקדמה: Bun משתמשת ב-Claude Code כדי לבנות ולתחזק את Bun; ג’ארד מתחיל agents בלייב לתקן GitHub issues.
• 2:05–3:10 RoboBun משחזר כל issue חדש; יכול לפתוח PR רק אם הוא כולל tests.
• 3:11–4:09 ה-bottleneck משתנה: לא “האם אנחנו יכולים לתקן?” אלא “האם זה התיקון הנכון והאם צריך למרג’?”
• 4:12–5:45 Loop של CodeRabbit + Claude review עם RoboBun. CodeRabbit: סטייל/קונבנציה. Claude: edge cases עמוקים יותר.
• 5:48–6:17 ה-agents מסירים חיכוך מ-review: מתקנים lint, דוחפים, סוגרים קומנטים בלי context switching אנושי.
• 6:19–7:51 Bun מתאים לזה (CLI/systems, בר-שחזור). מוצרי UI משתמשים ב-screenshots/וידאו לאימות.
• 7:16–7:51 חברות פרטיות: להחליף “GitHub issue” ב”טיקט תמיכת לקוחות.”
• 8:11–10:00 CLAUDE.md קריטי — כל הוראה חוזרת, פקודת build, קונבנציית test, טעות.
• 10:20–10:59 Agents צריכים גישה לשגיאות CI, ל-build logs, ל-tests, לקוד — כדי לסגור את ה-loop לפני שאדם בודק.
• 11:01–12:53 החזון: מאות agents במקביל — עובד רק אם הם מאמתים את עצמם.
• 12:56–15:39 בדיקת PR בלייב: ג’ארד בודק סטייל, ממתין ל-Claude review, מסביר מתי הוא סומך על tests.
• 16:29–17:39 ה-bottleneck החדש הוא ביטחון: איך מוכיחים שה-PR מספיק נכון כדי למרג’?
• 18:10–20:21 עבודה גדולה יותר: HTTP/3, HTTP/2, עיבוד תמונה, benchmarks. נותנים למודל מטרות, נותנים לו לבצע איטרציות.
• 20:23–21:39 Hill climbing: מטריקה + מדידה + רשות לבצע איטרציות עד שיפור.
• 22:15–23:55 כלים: CLI, auto mode, no-flicker, רינדור וירטואלי, תמיכת עכבר.
• 24:00–24:47 במהלך ההרצאה, ה-agents מפיקים מספר PR-ים בלייב.
• 25:03–26:13 ה-bottlenecks ממשיכים לזוז: קוד → tests → אימות עמוק → תכנון.
• 26:14–27:31 RoboBun יכול לפעמים בקשות feature, אבל ג’ארד זהיר — features צריכות טעם.
• 27:33–28:43 PR-ים של agent הופכים להצעות — דחייה בלי עלות חברתית, מה שמעלה את רף ה-merge.
• 29:13–30:08 Auto mode מאפשר ל-agents ארוכי-טווח לעבוד שעות בלי עצירות permission.
• 30:20–30:54 סיכום: הצוותים עדיין מבינים את זה תוך כדי, על ידי חיפוש ואוטומציה מתמדת של ה-bottleneck הבא.

הרעיונות הכי חשובים של Codex

1. RoboBun הוא לא רק “AI כותב קוד” — זה loop הנדסי אוטומטי (קריאה, שחזור, test, PR, review, CI).
2. Tests הם כרטיס הכניסה — PR חייב לכלול tests שנכשלים בגרסה הקודמת, עוברים ב-branch.
3. ה-bottleneck האמיתי הוא merge confidence — איזו הוכחה אני צריכה לפני merge?
4. Review של agent צריך להיות adversarial — אחד תופס קונבנציות, השני עוקב אחרי code paths.
5. CLAUDE.md הוא זיכרון תפעולי — לתקן טעות פעם אחת, לכתוב אותה לנצח.
6. ה-agent צריך את כל ה-feedback loop — בלי גישה ל-CI/test/build/branch הוא זורק עבודה חצי-גמורה.
7. Projects של CLI/systems קלים יותר — שחזוריות חזקה; UI צריך screenshots/וידאו/בדיקות דפדפן.
8. Hill climbing הוא חזק — לתת מטרה שניתנת למדידה וכלים לעשות איטרציות.
9. Auto mode משנה את ה-workflow — sessions רצים בלילה בלי עצירות permission.
10. תכנון וטעם עדיין כבדים-אנושית — האם Bun צריך API לעיבוד תמונה זו החלטה מוצרית.

---

ניתוח של ה-live coding session “Bun × Claude Code” — בוריס צ’רני וג’ארד סאמנר. משלב את ההסבר של Claude עם ה-timeline של Codex.