תוכן עניינים
סוף סוף אנחנו יכולים לאלץ סוכני AI להפסיק להתנהג כמו ג'וניורים
הפרויקט Superpowers של Jesse Vincent (obra) פותר בעיה שכולנו מתמודדים איתה - סוכני קוד של AI שמתנהגים כמו ג'וניורים נלהבים שממהרים לשחרר קוד בלי לחשוב. הכלי הזה מזריק משמעת הנדסית של מפתחים בכירים ישירות לתוך תהליך העבודה של Claude Code.
הבעיה שכולנו מכירים טוב מדי
כולנו היינו שם. אנחנו מבקשים מ-Claude או GitHub Copilot לבנות פיצ'ר, ותוך שניות הוא מייצר מאות שורות קוד. בלי שלב תכנון. בלי אסטרטגיית טסטים. בלי שיקול של maintainability. סתם קוד שבקושי עובד ונשבר ברגע שאנחנו מנסים להרחיב אותו.
מסתבר שהתוצאה היא שאנחנו מבזבזים יותר זמן על דיבוג ורפקטורינג של הפלט של ה-AI מאשר אם היינו כותבים את הקוד בעצמנו מאפס. הקודבייסים שלנו הופכים לסבך בלתי ניתן לתחזוקה כי ה-AI מייעל למהירות ולא לאיכות.
הבעיה המרכזית היא שסוכני AI לא חושבים באופן טבעי במונחים של תהליך הנדסי. הם אומנו על ריפואים מלאים בקוד, אבל לא על המשמעת והמתודולוגיה שיצרה את הקוד הזה. הם רואים את התוצרים, לא את האומנות.
למה הפתרונות הקיימים לא מספיקים
כלים אחרים ניסו להוסיף מעקות לסוכני קוד של AI. חלקם נוקשים מדי - מאלצים אותנו לעבור דרך צ'קליסטים בירוקרטיים שמאטים אותנו במשימות פשוטות. אחרים רופפים מדי - הם מציעים best practices אבל לא אוכפים אותם, אז ה-AI מתעלם מהם כשיש לחץ.
האתגר הבסיסי הוא שפרומפטים לבד לא עובדים. אנחנו יכולים לכתוב פרומפטים מפורטים שאומרים ל-AI "תכתוב טסטים קודם" או "תתכנן לפני לקוד", אבל כשמגיעים לעניין, ה-AI לוקח קיצורי דרך. הוא מחווט לייצר קוד מהר, לא לעקוב אחרי תהליך.
איך Superpowers באמת עובד
הריפו Superpowers לוקח גישה שונה לחלוטין. במקום לקוות שה-AI יעקוב אחרי ההוראות שלנו, הוא מזריק מה שהמחבר מכנה "Subagent-Driven Development" ישירות לתוך חלון הקונטקסט של הסוכן. תחשבו על זה כמו שיש מהנדס בכיר שיושב פיזית ליד ה-AI ועוצר אותו מלמהר קדימה.
הקסם קורה דרך מה שנקרא "skills" מורכבים - בעצם הגדרות כלים ופרומפטים שמופעלים אוטומטית לפי הקונטקסט הנוכחי. אלה לא הצעות. אלה שלבי עבודה חobligatory שהסוכן לא יכול לדלג עליהם.
התחלה מהירה
ככה אנחנו מריצים את Superpowers עם Claude Code:
# שיבוט הריפו
git clone https://github.com/obra/superpowers.git
cd superpowers
# התקנת תלויות
npm install
# קונפיגורציה של Claude Code
cp config.example.json config.json
# עריכת config.json עם מפתח ה-API של Claude
# הפעלת ה-skills
npm run activate-skillsמחזור אכיפת TDD
הפיצ'ר החזק ביותר הוא ה-skill בשם test-driven-development. הנה מה קורה כשאנחנו מבקשים פיצ'ר חדש:
# לפני Superpowers:
# משתמש: "תוסיף פונקציית התחברות"
# AI: *מיד כותב 200 שורות של קוד התחברות*
# עם Superpowers:
# משתמש: "תוסיף פונקציית התחברות"
# AI: *חייב לעקוב אחרי המחזור הזה*
# שלב 1: כתיבת טסט נכשל
def test_login_with_valid_credentials():
user = User(email="test@example.com", password="secret123")
result = login(user.email, user.password)
assert result.success == True
assert result.token is not None
# שלב 2: הרצת הטסט וצפייה בו נכשל
# FAIL: NameError: name 'login' is not defined
# שלב 3: כתיבת קוד מינימלי שמעביר
def login(email, password):
# הטמעה הכי פשוטה שאפשר
if email and password:
return LoginResult(success=True, token="dummy_token")
return LoginResult(success=False, token=None)
# שלב 4: רפקטורינג אחרי ירוק
# עכשיו משפרים את ההטמעה בזמן שהטסטים נשארים ירוקיםהנה החלק הקריטי: אם קוד קיים בלי טסטים מלווים, הסוכן מקבל הוראה למחוק אותו. זה נשמע קשוח, אבל זה בדיוק מה שהיינו אומרים למפתח ג'וניור בצוות שלנו.
בידוד Git Worktree
פיצ'ר מבריק נוסף הוא ה-skill בשם using-git-worktrees. כשאנחנו עובדים על פיצ'ר, הסוכן לא נוגע בתיקיית העבודה הנוכחית שלנו. במקום זאת:
# הסוכן יוצר worktree מבודד
git worktree add ../feature-temp feature-branch
cd ../feature-temp
# מריץ setup של הפרויקט בבידוד
npm install
npm test # אימות בייסליין נקי
# עושה שינויים בסביבה מבודדת
# אין סיכון לשבור את ה-workspace הראשי שלנו
# כשסיימנו, אנחנו יכולים לבדוק ולעשות merge
cd ../main-project
git worktree remove ../feature-tempהקטע המדליק הוא שזה פותר את בעיית "זה עובד אצלי". הסוכן מוכיח שהקוד עובד בסביבה נקייה, לא כזו שמזוהמת מהטוויקים והניסויים המקומיים שלנו.
פיצ'רים מרכזיים שמשנים איך אנחנו עובדים
- סיעור מוחות לפני קוד - הסוכן חייב לעסוק בשיפור עיצוב סוקרטי לפני לכתוב כל הטמעה. הוא שואל אותנו שאלות מבהירות על מקרי קצה, דרישות ביצועים ונקודות אינטגרציה. תחשבו על זה כמו מהנדס בכיר שעושה גילוי לפני הערכה.
- שלב תכנון חובה - אחרי סיעור המוחות, הסוכן כותב תכנית מפורטת. אנחנו בודקים ומאשרים את התכנית הזו לפני שכל קוד נכתב. בלי הפתעות, בלי scope creep, בלי שיחות "חשבתי שהתכוונת ל..." אחרי המעשה.
- מחזור ביקורת עצמית - לפני לסמן עבודה כסיימה, סוכן אחד כותב את הקוד וסוכן אחר בודק אותו מול התכנית המקורית. זה משקף איך מהנדסים בכירים באמת עובדים בצוותים - עיניים רעננות תופסות בעיות שהמחבר המקורי פספס.
- אכיפת YAGNI ו-DRY - הסוכן מקבל הוראה מפורשת לעקוב אחרי עקרונות "You Aren't Gonna Need It" ו-"Don't Repeat Yourself". הוא דוחה אם אנחנו מבקשים פיצ'רים ספקולטיביים או דפוסי קוד כפולים.
מתי להשתמש בזה לעומת אלטרנטיבות
הריפו Superpowers אופטימלי ספציפית ל-Claude Code כרגע, אם כי ה-skills ניתנים להתאמה ל-GitHub Copilot או OpenCode עם קצת tweaking של קונפיגורציה. זה לא תחליף לכלים כמו Cursor או Aider - זה משלים.
להשתמש ב-Superpowers כש-maintainability חשוב יותר ממהירות. אם אנחנו עושים פרוטוטייפ של דמו חד-פעמי, התקורה לא שווה את זה. אבל לקודבייסים של פרודקשן שבהם נתחזק את הקוד שנים? המשמעת שהוא אוכף משתלמת.
בהשוואה ל-LangChain או מצבי הקידוד של AutoGPT, הריפו Superpowers הרבה יותר opinionated. הכלים האלה נותנים לנו גמישות להגדיר תהליכי עבודה משלנו. Superpowers אומר "הנה הדרך הנכונה לעשות הנדסה" ואוכף אותה. חלק מהמפתחים יאהבו את זה, אחרים יתחככו נגד האילוצים.
בעיניי - האם אשתמש בזה בפרודקשן?
לעניות דעתי, זה הכלי הראשון שראיתי שמתייחס לסוכני AI כמו מהנדסים בהכשרה ולא כמו מחוללי קוד. אכיפת תהליך העבודה לא עוסקת בהגבלת ה-AI - היא עוסקת בהוראה שלו הרגלים שמובילים לתוכנה ניתנת לתחזוקה.
אני כבר משלב את זה לתהליך העבודה שלי לכל פרויקט שבו אני לא המפתח היחיד. אכיפת ה-TDD לבד חוסכת לי שעות של דיבוג של קוד שנוצר על ידי AI בלי טסטים. בידוד ה-Git worktree מבריק למניעת זיהום סביבה.
המגבלה היא שזה בהחלט opinionated. אם יש לנו תהליך עבודה מועדף משלנו שנבדל מ-TDD קפדני, נצטרך להתאים את ה-skills. מבנה הריפו מודולרי, אז זה אפשרי, אבל זה דורש הבנה של איך ה-skills מתחברים יחד.
מגבלה נוספת: שלבי ה-Brainstorm וה-Planning מוסיפים תקורה אמיתית. לשינויים זעירים - תיקון טיפוגרפי, עדכון תלות - זה מרגיש כמו יתר על המידה. אנחנו צריכים לפתח שיפוט מתי להפעיל את Superpowers ומתי לתת ל-AI לעבוד בחופשיות.
שורה תחתונה: לכל צוות שרציני לגבי איכות קוד, זה שווה לנסות. בדקו את הריפו ב-github.com/obra/superpowers ונסו את ה-skills שמתאימים לתהליך העבודה שלכם.