Human on the Loop: מה למדתי משיחה עם המייסד של BMAD על עתיד הקידוד עם AI

לאחרונה הקשבתי לשיחה ארוכה עם בריאן, מייסד BMAD - אחד ה-frameworks המחושבים יותר לעבודה עם סוכני קידוד AI. השיחה כיסתה המון, אבל כמה רעיונות ממנה נשארו איתי.

מאיפו BMAD באמת בא

בריאן לא התחיל את BMAD כמוצר. הוא ניהל צוותי הנדסה וניסה לגרום למהנדסים המנוסים שלו לאמץ את לולאות הסוכן המוקדמות בכלים כמו Cursor. התגובה הייתה חדה: זה היה טוב ל-autocomplete, אבל כלולאה אוטונומית, המהנדסים הכי טובים שלו קראו לזה זבל - איטי יותר מלעשות את העבודה בעצמם. במקביל, ההייפ ברשת טען שכל אחד יכול לשגר "אפליקציית SaaS במיליון דולר בן לילה". הפער בין שתי המציאויות האלה הוא מה שדחף אותו להתנסות בלילות, הרבה לפני שמונחים כמו context engineering או spec engineering בכלל היו קיימים.

התובנה האמיתית שלו הגיעה מ-25 שנות ניסיון בתוכנה ארגונית, לא מ-AI: agile עובד כי הוא שובר רעיונות גדולים לחתיכות קטנות. אז במקום לכתוב פרומפטים גדולים יותר או לערום עוד כללים (משהו שהרגיש כמו כדור קסם לפני שנה וחצי, ובעיקר לא היה), הוא התחיל לפרק עבודה לכוונות קטנות וספציפיות - קרוב למה שהיום היינו קוראים לו specs - ולהזין אותן לסוכן אחת אחת. מזה גדל BMAD.

הפילוסופיה האמיתית: להישאר בשליטה

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

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

לפני כל framework, תעשו את זה קודם

עצה ששווה לחזור עליה: לפני שמאמצים framework או אוסף skills כלשהו, כדאי לבזבז זמן אמיתי סתם על שיחה עם מודל רגיל דרך ה-harness שבחרתם, בלי שום דבר אחר בדרך. לראות מה הוא כבר יכול לעשות לבד. לאמץ frameworks או לכתוב skills משלכם רק אחרי שהרגשתם בעצמכם את הפער.

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

לאן ה-frameworks באמת הולכים

BMAD זז מרצף נוקשה יחיד (PRD, אז ארכיטקטורה, אז stories) למשהו מודולארי יותר: כמה נקודות כניסה תלוי איך אתם חושבים - PRD מלא, product brief רזה יותר, ואפילו תרגיל בסגנון "הודעה לעיתונות + FAQ" של אמזון לבדיקה אם רעיון בכלל שווה בנייה, ומסלול "quick build" קליל יותר למשימות קטנות שמדלג לגמרי על תכנון כבד.

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

נקודת המפנה שאף אחד לא מזהיר עליה

ברגע שצוות באמת מאיץ, בריאן תיאר פגיעה בקיר כמעט מיד, בשני כיוונים. מצד אחד, code review הופך לצוואר הבקבוק, מה שדוחף צוותים לבנות שערי CI/CD טובים יותר ומיון חכם יותר של מה בכלל דורש ביקורת אנושית. מצד שני, ומעניין אותי יותר, מתברר ש-AI מגביר כל תהליך שכבר קיים - כולל החלקים הרעים. תהליך חלש לא מתתקן בשקט על ידי AI - הוא נחשף מהר יותר.

הלחץ הזה מעצב מחדש גם את מבנה הצוות: במקום צוותי scrum של חמשה עד שמונה אנשים עם מנהל מוצר ייעודי, בריאן רואה מעבר לפודים קטנים של שניים עד ארבעה אנשים שבבעלותם יחידת עבודה גדולה יותר מקצה לקצה - יותר כמו mini-agile-team עצמאי מאשר אוסף טיקטים. התפקיד על הדלת פחות משנה מאשר האם מישהו בפוד הזה באמת חושב במונחי מערכות.

אפוקליפסת ה-Slop

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

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

Human on the Loop, לא Dark Factory

כבר תקופה שאני שומע על "dark factory" - אוטומציה מלאה של spec-in, code-out בלי מעורבות אנושית - כמטרה הסופית. בריאן דחף בחזרה נגד המסגור הזה, ולדעתי הוא צודק: גם אם זה טכנית בר-השגה, עדיין נשארת שאלה אמיתית של מי מחליט מה שווה לבנות ומי בכלל מדבר עם הלקוחות. אוטומציה מלאה של צד התכנון היא לא בהכרח משהו שמישהו באמת רוצה, גם אם אפשרי.

מה שהוא כן שואף אליו זה human on the loop - להישאר מעורב מספיק כדי לקבוע כיוון ולתפוס בעיות, בלי לגעת אישית בכל הקשת מקש שהביצוע המכני מייצר.

מה זה אומר על ה-skills עצמם

פרט אחד שלא ציפיתי לו: לא בריאן ולא האורח השני בשיחה סומכים על skills שמשתפרים לגמרי לבד - כאלה שכותבים את עצמם מחדש אוטומטית על סמך לוגים של סשנים. מהניסיון שלהם, הגישה הזו נוטה להכניס התנהגות נוקשה ודטרמיניסטית למקומות שמעולם לא היו אמורים להיות נוקשים, והאיכות מתדרדרת אחרי כמה סבבים. Skills, בסופו של דבר, הם רק prompts - בקובץ markdown כלשהו שטוענים אותם ממנו. היוצא מן הכלל האמיתי היחיד הוא hooks, כי שם באמת נכנס קוד דטרמיניסטי ללולאה במקום עוד prompt.

לסיכום

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