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

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

האזור החכם והאזור הטיפש

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

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

ניקוי מול דחיסה: תהיו כמו הגיבור מ-Memento, לא אספנים

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

תפסיקו עם "ממפרט לקוד" - תתחילו בשיחת "תחקרו אותי"

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

במקום זה, הוא פותח כל פיצ'ר חדש בסקיל קטנטן שנקרא grill me (תחקרו אותי): הסוכן מתחקר אתכם ללא רחם על כל ענף בעיצוב, שאלה אחת בכל פעם, ומציע המלצה משלו לכל שאלה. המטרה היא לא תוכנית או מפרט - היא להגיע ל_הבנה משותפת_ עם המודל, מה שפרדריק ברוקס כינה "מושג העיצוב" בספרו The Design of Design. שיחת תחקור יכולה לכלול 20, 40, ואפילו 100 שאלות. התמליל הזה הופך לנכס האמיתי - לא מסמך שכותבים פעם אחת ומעבירים הלאה, אלא מודל מנטלי משותף ומוסכם.

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

ה-PRD הוא מסמך יעד, לא משהו לעבור עליו בקורקטורה

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

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

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

הפתרון, שאול מ-The Pragmatic Programmer: כדורי עקבה (tracer bullets). כמו תותחן נגד מטוסים שלא יכול לדעת לאן הכדורים הרגילים שלו הולכים בחושך, מצמידים זרחן לכל כמה כדורים כדי לקבל קו נראה לעין למשוב תוך כדי ירי. כשמיישמים את זה על פיצ'רים, זה אומר שכל חתיכת עבודה צריכה לחתוך אנכית דרך כל השכבות שהיא נוגעת בהן - קצת סכמה, קצת שירות, מעט פרונט אנד מינימלי - כדי לקבל תוצאה משולבת וניתנת לבדיקה בסוף כל חתיכה, לא רק בסוף התוכנית כולה.

הפיכת תוכנית לגרף שאפשר להריץ במקביל

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

לולאת Ralph: תיאום משמרת הלילה

ברגע שהמשימות מוכנות, סוכן AFK (על שם תרגול התוכנה "Ralph Wiggum") עובר על העומס ללא השגחה: קורא את קבצי המשימות המקומיים, בוחר את המשימה הבאה לפי עדיפות (תיקוני באגים קריטיים קודם, אחר כך תשתית, אחר כך כדורי עקבה, ואז ליטוש), ממש אותה עם TDD, מריץ את לולאות המשוב, מבצע קומיט, וחוזר חלילה. מריצים פעם אחת קודם, בפיקוח, כדי לכוונן את הפרומפט לפני שסומכים עליו לרוץ בלולאה בתוך קונטיינר מבודד. המודל המנטלי: שלבי התכנון והיישור הם משמרת היום, שעושים בני אדם; לולאת המימוש היא משמרת הלילה, שעושים סוכנים בזמן שאתם לא שם.

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

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

מודולים עמוקים במקום שטוחים

בהסתמך על ג'ון אוסטרהאוט וספרו A Philosophy of Software Design: בסיס קוד מלא במודולים קטנים ושטוחים עם תלויות צולבות משתרעות הוא בדיוק מה שסוכנים מתקשים לנווט בו ולבדוק - ה-AI מסיים בכתיבת בדיקות שטחיות שעוטפות פונקציות קטנות בנפרד, ומפספסות את הבאגים שחיים בגבולות שביניהן. מודולים עמוקים - ממשק קטן ופשוט שמסתיר מאחוריו פונקציונליות משמעותית - קלים יותר גם לבדיקה (עוטפים גבול ברור אחד סביב פונקציונליות אמיתית) וגם להאצלה. ברגע שהממשק וההתנהגות של מודול מוגדרים היטב, אפשר להאציל את המימוש שלו לגמרי, בלי צורך לסקור כל שורה בפנים. סקיל ייעודי בשם "improve codebase architecture" סורק בסיס קוד לאיתור אשכולות של מודולים קשורים וחסרי בדיקות, ומציע איפה להעמיק אותם - ההמלצה הבודדת הכי גדולה של פוקוק מכל ההרצאה.

Push מול Pull, ולמה סקירה צריכה מודל טרי

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

הקבלה אמיתית: מתכנן, N ארגזי חול, וממזג

הכלי שלו לזה, שנבנה לאחרונה, מריץ סוכן מתכנן שקורא את העומס ובוחר קבוצת משימות לא-חוסמות להרצה במקביל, מקים ארגז חול מבודד (git worktree בתוך קונטיינר Docker) לכל משימה, מריץ מממש בכל אחד, ואז מעביר את הענפים שנוצרו לסוכן ממזג שמפשר קונפליקטים, מתקן כשלי טיפוסים או בדיקות מהמיזוג, ונוחת עם העבודה. זו אותה לולאת משמרת-יום/משמרת-לילה כמו קודם, רק מפוזרת על פני כמה סוכנים במקום אחד.

התובנה המרכזית

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