זה החלק האחרון בסדרה “כל המושגים ב-AI מאפס עד מקצוענות” של אריאל, שבעה חלקים בסך הכול, וזה החלק שבו התיאוריה הופכת לעבודה. שישה חלקים עסקו במה זה מודל, איך עובד הקונטקסט, למה סוכנים משקרים ואיך מנהלים זיכרון. חלק 7 שואל את השאלה שבאמת חשובה: איך גורמים לסוכן לעשות עבודה אמיתית בזמן שאתה ישן, ולהתעורר למשהו שהיית מעלה לפרודקשן?
אם פספסתם את היסודות, פוסט המילון המלא מכסה אותם. הפוסט הזה עוסק בתהליכי עבודה.
Human in the loop מול AFK
החלוקה הראשונה פשוטה. Human in the loop זה כשאתה והסוכן מתכתבים באותו סשן: אתה נותן הוראה, הוא עונה, אתה חושב ומתקן. AFK (קיצור של Away From Keyboard) זה כשאתה מוסר משימה, הולך, ומסתכל על התוצאה אחר כך. לפעמים אפילו לא מסתכל.
אף אחד מהם לא עדיף באופן כללי, הכול תלוי במשימה. הדוגמה של אריאל היא מיגרציה של סכמת מסד נתונים. את זה לא מריצים ב-AFK בלילה. נשארים בלופ, עוקבים אחרי כל צעד, ותופסים את העמודה השגויה לפני שהיא עולה לך סוף שבוע.
AFK עובד רק כשהסוכן יכול לקבל החלטות בעצמו בלי להרוס כלום. בפועל זה אומר סביבות סנדבוקס. ההגדרה שהוא מתאר: הסוכנים מקבלים הרשאות מלאות (“תעשה מה שאתה רוצה”), אבל מערכת הקבצים האמיתית במצב קריאה בלבד, כל סוכן כותב רק בתוך הסנדבוקס שלו, אין גישה לרשת, והתוצר הוא Pull Request מול הקוד הראשי. הרבה חופש בתוך קופסה שאי אפשר לברוח ממנה.
דפוס נפוץ ב-AFK: כשהסוכן נתקל בהחלטה לא ברורה, הוא לא מעיר אותך. הוא מבקש חוות דעת מסוכן אחר.
בדיקות: ההגדרה השחורה-לבנה של “גמרתי”
המרכיב החשוב ביותר בריצת AFK טובה הוא בדיקות אוטומטיות: טסטים דטרמיניסטיים של עבר/נכשל, שיושבים בסביבה ואומרים לסוכן אם הוא סיים, בלי שתצטרך לעשות את זה אתה.
לא “תעריך אם זה טוב”, אלא: “טוב זה שאני מצליח להתחבר. טוב זה שכשאני שואל איפה אני, אני מקבל מיקום. טוב זה שבנקודה הזאת יש טרמפ ובנקודה ההיא אין.” לפני ריצה ארוכה, בין אם זה לילה אחד או שבועיים, מייצרים את הבדיקות האלה מראש.
ואז עוטפים את הסוכן בלולאת בקרה. בדרך כלל ריצה של סוכן נגמרת כשהוא שולח לך תשובה. בלולאה, הריצה נגמרת כשהבדיקות עוברות. שני משפטים מהמקור שאריאל עובר עליו שווה לזכור:
- גם בדיקה שבורה היא בדיקה, והיא עדיפה על שום בדיקה.
- בדיקה היא לא ריוויו. בדיקה אומרת אם משהו עובד. היא לא אומרת כלום על אבטחה, איכות קוד או עמידה ב-GDPR.
הוא גם נותן דוגמה לבדיקה שהיא לא בדיוק “טסט” במובן הרגיל. הוא בנה שכבת גישה לנתונים (DAL) משלו, והסוכנים כל הזמן מנסים לגשת למסד הנתונים בדרכים משלהם. סריקה סטטית שעוברת על כל הקוד ומוודאת ש-100% מהגישות למסד הנתונים עוברות דרך השכבה שלו נותנת תשובת כן/לא בכל ריצה. גם זו בדיקה.
ריוויו: ממוקד, נפרד, ושבאמת קוראים אותו
ריוויו הוא בחינה: Code Review לקוד, Plan Review לתוכנית, QA למוצר הסופי. ריוויו אוטומטי זה סוכן אחר שקורא את העבודה, רצוי עם מודל אחר, System Prompt אחר ופרמטרים אחרים. הוא לא דטרמיניסטי ומפעיל שיקול דעת, ובדיוק בגלל זה הוא לא בדיקה.
המפתח הוא להיות ספציפי. “ריוויו של AI” לא אומר כלום. “ריוויו של אבטחה ושינויים שוברים, שמוודא שהשינוי תואם לטיקט” אומר הרבה. אם ריצות ה-AFK ממשיכות לייצר PR-ים גרועים, מוסיפים עוד ריוויו אוטומטי ממוקד לפני המיזוג.
ואז יש ריוויו אנושי לתוצרי AFK, ואיתו מקרה השימוש הלא נעים: בסיכום של הסוכן נכתב שהוא מחק את הקוד המת. האדם בדק בפועל, והפונקציה המתה עדיין הייתה שם. קוראים את ה-diff, לא את הסיכום.
וייב קודינג, כמו שצריך
ההגדרה של אריאל: וייב קודינג זה מה שאתה עושה ברגע שהוצאת מהתהליך את הריוויו האנושי על הקוד. אתה מפסיק להסתכל על מה שהסוכן עשה ומסתכל רק על התוצאה.
כשעושים את זה לא נכון, הבעיות נערמות עד שהקוד כבר לא ניתן לתיקון, ולכן אנשים מגבילים את זה לאבות טיפוס. כשעושים את זה נכון, עם בדיקות אוטומטיות, Design Concept מסודר וגרילינג, זה לא שם נרדף לקוד מרושל. קוד מרושל נוצר כשנותנים ל-AI לעבוד ברישול.
יש חריג אחד קשיח: אימות משתמשים ותהליכים רגישים אחרים. “הלוגין עובד, זה כל מה שבדקתי” זה בדיוק איך סיסמאות מגיעות לקבצי לוג. אם אתה מתכנת, תקרא מה הוא עשה. אם לא, תחקור את הסוכן או תביא מישהו שיודע.
Design Concept, גרילינג ואבות טיפוס
- Design Concept: האפיון ברמה הגבוהה. אתה והסוכן מדברים עד שיש מסמך מסירה שמגדיר כל מה שצריך כדי לבנות את הדבר. אם הסוכן “עשה בדיוק מה שביקשתי ועדיין פספס”, עדיין אין לך Design Concept, והוא ממלא את החורים בהנחות. תגיד לו: אל תניח, תשאל.
- גרילינג (Grilling): הטכניקה לבניית ה-Design Concept. “יש לי משימה חדשה. תחקור אותי.” ככל שתגיד לו להיות אכזרי יותר, הוא ישאל יותר שאלות. 30, 40, ואפילו כמה מאות זה בסדר. גרילינג הוא תמיד Human in the loop. אם סוכן כבר קפץ ישר למימוש וטעה בלוגיקה: מחזירים אחורה, עושים גרילינג קודם, ומתעדים הכול.
- אבות טיפוס: להחלטות שמילים לא יכריעו. צבעים, סדר, זרימה. הדוגמה שלו: ויכוח של חצי שעה אם טופס צריך להיות בעמוד אחד או אשף בשלושה שלבים. תגיד לסוכן לבנות את שניהם, ותדע את התשובה בתוך חמש דקות. אחר כך לוקחים את מה שלמדת וחוזרים לעוד סבב גרילינג.
DX מול AX
חוויית מפתח (DX) זה כמה הסביבה נוחה לבן אדם: פידבק מהיר, שגיאות ברורות, תיעוד שעונה על שאלות, והתקנה שעובדת בפעם הראשונה.
חוויית סוכן (AX) זו אותה שאלה מנקודת המבט של הסוכן, וכאן הטוויסט: סוכנים הם stateless, בני אדם הם stateful. עובד חדש נהיה פרודוקטיבי בתוך שבוע כי מישהו יושב איתו והוא זוכר. סוכן שוכח בכל סשן. אז “ה-DX שלנו מצוין, עובדים חדשים נקלטים תוך שבוע” לא מלמד כלום על AX. צריך לבדוק AX בנפרד.
כשאותו מודל ואותו הארנס עושים עבודה מעולה בריפו אחד ועבודה איומה בריפו אחר, האינסטינקט הוא להאשים את המודל או לשכתב את הפרומפט. התיקון הוא בדרך כלל בריפו. ל-AX טוב יש שלושה ממדים:
- הרבה בדיקות אוטומטיות טובות, יחד עם טיפוסים ו-linters.
- ארכיטקטורה טובה: תיקיות ברורות, ממשקים ברורים, שמות שאומרים את מה שהם עושים.
- חלון קונטקסט פנוי: קובץ MD רזה לסוכן, רוב הידע בסקילים, כלים פשוטים, כך שכל סשן מתחיל באזור החכם של המודל.
הדוגמה שלו: הסוכן כותב קוד API מצוין ובלגן בפרונטאנד. זה בגלל שה-API מלא בכללים נוקשים ולפרונטאנד אין כאלה. הוא גם נותן עצה מעשית שנשמעת מעצבנת אבל עובדת: לתת לסוכן להעמיס על הקוד הערות. מכוער לעין אנושית, זהב לסשן הבא של הסוכן.
מפעל תוכנה
כל זה מוביל למושג הלוהט של התקופה: מפעל תוכנה (Software Factory). בלי מפעל, כל סשן מתחיל כי בן אדם פתח Claude Code. אפילו סשן AFK מתחיל כי אתה כתבת את ההנחיה ולחצת “סע”.
במפעל, סשנים מתחילים מטריגרים: דיווח על באג פותח טיקט, הטיקט מעיר סוכן, והסוכן מריץ את כל התהליך ב-AFK לפי כל הכללים שלמעלה, עד שהוא מגיע להחלטה גדולה מספיק בשביל בן אדם, או מגיש תוצאה סופית לריוויו. טריגר יכול להיות Issue, הודעה בצ’אט, תזמון קרון או סיום של סשן אחר.
שני פרטים חשובים:
- מפעל לא חייב לשלוט בכל הקוד. אפשר לבנות מפעל רק ל-UI, או רק לשכבת מסד הנתונים.
- בני אדם יכולים להיכנס בכל נקודה בתחום של המפעל. אם לוקחים את הרעיון עד הסוף מקבלים מפעל חשוך (Dark Factory): מפעל שמופעל 100% על ידי רובוטים, אז אף אחד לא טורח להדליק את האור.
🔥 Roast Corner
כולם רוצים מפעל חשוך. כמעט לאף אחד אין אפילו בדיקה דטרמיניסטית אחת.
זה הפער שהסרטון הזה חושף. אנשים קופצים ישר מ"ביקשתי מ-ChatGPT פונקציה" ל"הסוכנים שלי מגישים PR-ים בלילה", ומדלגים על כל שלב משעמם באמצע: סנדבוקס, בדיקות, ריוויו ממוקד, Design Concept, וריפו שגם מישהו עם אמנזיה יכול להתמצא בו. ואז הם מתעוררים ל-PR ש"מחק את הקוד המת" בלי למחוק את הקוד המת, ומאשימים את המודל.
המודל הוא לא הבעיה שלך. הבעיה שלך היא שההגדרה של “גמרתי” נמצאת רק בראש שלך, שבריפו יש קובץ סוכן של 4,000 שורות ואפס בדיקות, ושאתה קורא את הסיכום במקום את ה-diff. מפעל תוכנה בלי בדיקות הוא לא מפעל. הוא דרך מהירה מאוד לעשות את אותן טעויות בזמן שאתה ישן.
ודבר אחרון לכל מי שאומר “וייב קודינג” כעלבון: הרישול אף פעם לא היה בווייב. הוא היה בבדיקות שלא נכתבו.
🤖 AI for Humans
אם אתם רוצים לנסות עבודת AFK השבוע בלי לשרוף כלום, הנה הגרסה הכי קצרה:
- בחרו משימה עם קו סיום שחור-לבן. “עמוד ההתחברות נטען ומקבל משתמש תקין.” לא “לשפר את תהליך ההתחברות”.
- כתבו את הבדיקות קודם. גם גסות. גם שבורות. תגידו לסוכן שהריצה נגמרת כשהן עוברות, לא כשהוא מרגיש שסיים.
- שימו אותו בקופסה. סנדבוקס, בלי רשת, קריאה בלבד לכל מה שחשוב, והתוצר כ-PR או בתיקייה נפרדת.
- הוסיפו בודק ממוקד אחד. מודל אחר עם תפקיד אחד, למשל “תמצא בעיות אבטחה ב-diff הזה”.
- קראו את ה-diff. במיוחד כל מה שנוגע בהתחברות, סיסמאות, תשלומים או מידע אישי.
- לפני כל משימה גדולה, תגידו “תחקור אותי”. תנו לו לשאול 30 שאלות. תקבלו תוצאה טובה יותר מכל פרומפט שהייתם כותבים לבד.
תעשו את זה כמה פעמים, ותהיה לכם ההתחלה של מפעל תוכנה. אחר כך אפשר להתווכח על האור.
💬 תגובות