לפני כמה ימים נתקלתי בפוסט שסחף לי את הפיד. מפתח מספר איך הוא "פרץ" שיטת עבודה חדשה: במקום להתכתב עם קלוד ישירות ולעבור איתו סבב אחרי סבב של "מצאתי את הבעיה, תיקנתי" - "בדקתי ולא עבד" - "הנה עוד לוגים" (מכיר את זה? כל מי שעובד עם AI מכיר), הוא נתן לצ'אט אחד לנסח פרומפט "בלי הגבלות" לקלוד השני, הגדיר תוצאה תקינה אחת, ואמר לו: "לך תריץ את זה בלולאה, אל תעצור, אל תשאל, יש לך הרשאות מלאות."
מה הסוכן עשה בפועל, לבד, בלי אישור אנושי
ומה שקרה בפועל מרשים בטירוף: קלוד התקין לעצמו MCP server לגישה לפרודקשן, התחבר עם הרשאות שקיבל דרך .env, קרא לוגים ישירות מהשרת בלי שאף אחד יעתיק-הדביק לו כלום, מצא באג שהתחבא מכל הניסיונות הקודמים, תיקן, בדק לוקאלית, דחף לדב, ואז - וזה החלק שממש עצר לי את הנשימה - הוא נכנס בעצמו לפלטפורמה החיה, העלה קובץ אמיתי, וחיפש הוכחות שהוא הצליח, כדי לכתוב בסוף "המשימה הושלמה".
הכתיבה שם הייתה נלהבת, ובצדק - זה מרשים. אבל אני קוראת את זה ומרגישה משהו אחר לגמרי מהתלהבות. אני קוראת את זה ומרגישה את כל שנות הניסיון שלי כמפתחת e-commerce צועקות עליי משהו אחד: מי בדיוק שיפט שהוא הצליח?
הבעיה לא בקלוד. הבעיה בשופט
אני עובדת מול קוד ולקוחות כבר יותר מעשור. הדבר הראשון שלמדתי, עוד לפני AI, עוד לפני CI/CD, זה שהאדם (או המערכת) שמריץ את הבדיקה לא יכול להיות אותו גורם שקובע אם היא עברה. זה לא עניין של אמון בטכנולוגיה - זו בדיוק אותה סיבה שאני לא בודקת את הקוד של עצמי כ-QA הסופי, ולמה שום פרויקט רציני שאני מובילה לא עולה לפרודקשן בלי שמישהו אחר עבר עליו.
באותו פוסט, הסוכן היה גם מי שביצע את התיקון, גם מי שהריץ את הבדיקה, וגם מי שקבע שהיא עברה. הוא "חיפש הוכחות שהוא הצליח" - וזה בדיוק המשפט שמדליק לי נורה אדומה. חיפוש הוכחות זה לא אותו דבר כמו טסט שנכשל או עבר. זה סיפור שהמערכת מספרת לעצמה, ואז מספרת לך. פעם אחת זה עבד ובגדול. השאלה שלי היא לא "האם זה יעבוד שוב", השאלה שלי היא מה קורה בפעם שזה לא יעבוד, ואיך תדעו.
הרשאות מלאות לפרודקשן, בלי אדם בלולאה
ויש עוד משהו שהפריע לי, אולי אפילו יותר: הרשאות מלאות לפרודקשן, בלי אישור אנושי באמצע, בגלל שהוגדר מראש "אל תעצור לשאלות". אני מבינה את התסכול - אני חיה את התסכול הזה, לולאה של תיקון-בדיקה-כישלון היא אחת החוויות הכי מתישות בעבודה שלנו. אבל הפתרון לתסכול הזה הוא לא לוותר על שער ביקורת, הוא לבנות שער ביקורת שלא דורש ממני להיות עצבנית וערה ב-2 בלילה כדי לוודא שהוא שם.
אז מה כן
הפתרון שאני מאמינה בו הרבה פחות דרמטי, ודווקא בגלל זה הוא עובד: CI/CD עם טסטים דטרמיניסטיים. בלי לצלול לפרטים הטכניים (זה לא הפוסט הזה) - הרעיון הבסיסי הוא שכל שינוי בקוד עובר את אותה סדרת בדיקות בדיוק, בכל פעם, ומישהו - סקריפט, לא agent שמשוטט - קובע אם זה עבר. יש שכבת lint שתופסת שטויות תוך שניות, יש טסטים על פונקציות בודדות, יש בדיקה שהזרימה המלאה (למשל: לקוח נכנס, ממלא טופס, מקבל אישור) עדיין עובדת מקצה לקצה - ורק אחרי כל זה, ורק עם אישור אנושי מפורש, זה עולה לאוויר. לא agent שמחליט לבד שהגיע הזמן.
זה פחות מרשים כסיפור. אין בזה רגע דרמטי של "הוא בדק לבד בלייב והצליח!". אבל בפרויקטים שאני מובילה - בטח בפרויקטים שיש בהם הזמנות אמיתיות, כסף אמיתי, לקוחות אמיתיים - "פחות מרשים אבל עקבי" מנצח "מרשים פעם אחת" בכל יום בשבוע.
מה שבאמת למדתי מהפוסט הזה
לא ללמד אתכם "לוותר על AI" - ההפך. אני עובדת עם AI כל יום, ואני כן משתמשת בכלים כמו Claude כדי לזרז תהליכים, לזהות באגים, אפילו לכתוב חלק מהטסטים האלה. השאלה מעולם לא הייתה "AI כן או לא", השאלה היא איפה שמים את קו הביקורת. אם הסוכן שמתקן הוא גם הסוכן ששופט, זה לא תהליך - זה סיפור שמתחפש לתהליך. ואני, אחרי הרבה שנים בתחום הזה, מעדיפה שהתוצאה תישאר משעממת, חוזרת על עצמה, ומדויקת - במקום מרשימה פעם אחת ומפתיעה בפעם השנייה.
