Free

ביקשתי מ-Claude לתקן lint, וקיבלתי בחזרה CI שגוסס

ביקשתי מ-Claude תיקון של שורת lint אחת. הוא חזר עם CI שגווע מזמן ו-CVE ש מתוקן בדרך — תופעות הלוואי גימדו את המשימה.

ב-repo של how2claude עמדתי לעשות מקבץ קטן של עריכות, וצעד הקדם היה להעביר את ה-rubocop lint. צילמתי מסך של GitHub Actions אדום ושלחתי ל-Claude.

המשפט הראשון שלו:

ה-CI נפל. אני הולך לבדוק למה.

הנחתי שהוא ירוץ עם rubocop, יסתכל על השגיאות ויתקן. לא.

כמה דקות אחר כך הוא חזר עם זה:

ה-CI נפל כבר זמן רב (גם ה-run הקודם מ-12 באפריל נפל). שתי קטגוריות של בעיות:

דברים שהכנסתי עכשיו: 2 הפרות RuboCop בקבצי migration

דברים שכבר היו שבורים:

  • ה-CI לא מוגדר עם postgres service, אז test/system-test אפילו לא עולים (בעיית infra, ככה כבר שבועיים)
  • 61 הפרות RuboCop קיימות מקודם (בקבצים שלא נגעתי בהם)

אני מתחיל מהשתיים שהכנסתי.

על הפסקה הזו שווה לעצור לשנייה.

מה שביקשתי ממנו זה "תקן rubocop." בזמן שהוא הלך לבדוק את היסטוריית ה-CI, הוא עשה דבר שלא ביקשתי — הוא מיין את "למה זה שבור" לשני סלים: מה שהבאתי הפעם אני, מול מה שה-repo כבר נשא איתו מזמן.

את הסיווג הזה לא ביקשתי. הוא עשה אותו בכל זאת.

שלושה שבועות באדום

מבין שני הסלים, השני הוא העיקר:

  • ה-workflow של ה-CI לא היה מוגדר עם postgres service, אז db:test:prepare נפל ב-connection refused בכל run
  • job של system-test ירש את אותה נפילה
  • ועוד 61 הפרות RuboCop פזורות בקבצים שאף פעם לא נגעתי בהם

במילים שלו:

גם ה-run הקודם מ-12 באפריל נפל.

ה-CI היה אדום שלושה שבועות. דחפתי כל יום. כל push הראה CI אדום, אבל מאחר ובדרך כלל אני committing ישירות ל-master ומריץ specs לוקאלית, אילפתי את העין שלי לראות את האדום הזה כרעש רקע.

באותו רגע שאני מבקש מ-Claude לתקן lint אחד, הוא מושך את ההיסטוריה ודוחף לי לפנים: "זה לא התחיל מהשינוי שלך."

ובדרך גם חיסל CVE

הוא דחף את הכול במעבר אחד:

✓ 63 הפרות RuboCop → 0 (autocorrect של whitespace ב-17 קבצים)
✓ MCP gem CVE-2026-33946 → bundle update mcp, 0.9.0 → 0.14.0
✓ test/system-test ללא postgres service → נוסף postgres:17 service container
✓ כל 241 הבדיקות עוברות עדיין לוקאלית
✓ bundler-audit: No vulnerabilities found

תסתכל על השורה השנייה. הוא bumpנה את גרסת ה-mcp gem מיוזמתו, כי ראה שהגרסה החדשה סוגרת CVE. לא ביקשתי. הוא פשוט ראה את האזהרה כשהריץ bundler-audit ולקח אותה איתו.

השורה השלישית היא מה שבאמת תיקן את ה-CI: postgres:17 כ-service container ב-workflow, עם health check ו-DATABASE_URL.

ואז הוא שאל על גרנולריות commits:

שני commits או אחד?

  • chore(lint): rubocop autocorrect (whitespace only)
  • fix(ci): add postgres service + bump mcp gem for CVE-2026-33946

או אחד: fix(ci): make CI green again?

עניתי במילה אחת — commit — כלומר: לך עם השניים מופרדים. הוא pushed.

ארבעה ירוקים, אחד אדום

ה-CI רץ שוב. אמרתי לו לעקוב.

4 ירוקים, system-test עדיין אדום. בודק.

אחרי כמה תחקורים חזר עם:

תיקיית test/system/ בכלל לא קיימת — ה-job הזה מריץ test:system בלי אף system test בכלל. בוא נמחק את ה-job.

נשארתי כמה שניות מסתכל על השורה הזו.

test/system/ היא תיקיית ברירת המחדל של Rails ל-system tests. אף פעם לא כתבתי system test בפרויקט הזה, אפילו לא פעם אחת, מהיום שעשיתי לו init. אבל ב-ci.yml ישב לו job של system-test שרץ בכל push, נפל בכל פעם, כי bundle exec rails test:system לא מצא את התיקייה.

ה-job הזה לא נשבר כש-Claude הוסיף postgres. הוא היה שבור מהיום הראשון של הפרויקט. הנחתי שעם postgres הוא יהפוך לירוק — לא, postgres לא היה הבעיה. הבעיה הייתה שה-job צריך להימחק.

ה-commit השלישי שלו:

e1d91d1 chore(ci): drop system-test job

CI ירוק.

תופעות הלוואי שוות יותר מהמשימה

אם מסתכלים אחורה על ההרצה:

  • ביקשתי דבר 1: לתקן rubocop
  • הוא עשה למעשה 4: תיקן lint / טיפל ב-CVE של mcp / הוסיף postgres service / מחק job של system-test שהסתובב סרק

אם הייתי עושה את זה לבד, הייתי עושה רק את ה-1 — כי ראיתי CI אדום שלושה שבועות, העין שלי הייתה קהה, והייתי אומר "תקן את ה-lint ונמשיך." אילפתי את המוח שלי לראות את האדום הזה כתפאורה.

ל-Claude אין את ההרגל הזה. אין לו זיכרון של "תמיד היה ככה" ל-repo. בכל פעם שהוא מסתכל על CI, הוא מסתכל בעין רעננה. וזה בדיוק היתרון — מה שאצלי הפך כבר ל"שבור-by-default מזמן," אצלו רואים.

כשמעבירים ל-Claude משימה קטנה, תופעת הלוואי הכי יקרה היא לרוב לא המשימה עצמה — אלא בדיקת בריאות אגב אורחא. אם הוא אומר לך "אגב X גם שמתי לב ש-Y ו-Z שבורים מזמן," אל תרשום את זה לרעש. זאת הדיאגנוזה.

מה שהפך להרגל

כמה התאמות קטנות שאימצתי:

לפני המשימה הקטנה — תן לו לסרוק את הסביבה פעם אחת. שיסתכל על היסטוריית ה-CI לפני שהוא מריץ lint. שיראה מתי לאחרונה נגעו ב-schema לפני שהוא כותב migration. שיעשה grep על כיסוי הבדיקות של controller לפני שהוא עורך אותו. "הצצה לפני שמתחילים" עולה כמעט כלום, ולעיתים קרובות מוציאה "רגע, יש פה משהו."

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

אל תעקוף את האדום ארוך הטווח. אמרתי לעצמי "זה known issue, אסתכל אחר כך" בכל push. "אחר כך" יכול להיות בעוד שלוש שנים. לתת ל-Claude לסדר את זה אגב שהוא ממילא בסביבה הוא הרבה יותר ריאלי מלהקדיש סלוט "ללכת לתקן את ה-CI."

שלושת ה-commits, עוד פעם:

74a3ebf  chore(lint): rubocop autocorrect — Layout cops only
76264ee  fix(ci): add postgres service + bump mcp gem for CVE-2026-33946
e1d91d1  chore(ci): drop system-test job

הראשון הוא מה שביקשתי. השני והשלישי הם מה שהוא הביא לבד. השניים האלה שווים הרבה יותר מהראשון.