התכונה הטובה ביותר בבנאי בינה מלאכותית אינה כמה מהר הוא הופך פרומפט לקוד עובד. זו התדירות שבה הוא מסרב לעשות זאת. בנאי שיחבר בשמחה כל מה שתבקשו — בלי הזדהות בנתיב ניהול, webhook בלי בדיקת אידמפוטנטיות, מפתח API שמודבק ישירות לקוד JavaScript בצד הלקוח כי "רק שזה יעבוד" — מבצע אופטימיזציה לחמש הדקות הלא נכונות. הוא עושה אופטימיזציה לדמו, לא ליום שלישי שישה שבועות אחר כך שבו מגרדים את הנתיב הזה.
ראיתי את זה קורה מבפנים מספיק פעמים כדי לסמוך על הדפוס. הבקשות שנדחות, או מופנות מחדש, כמעט אף פעם לא אקזוטיות. הן הבקשות המשעממות, הנפוצות: דלגו על אימות מייל לעת עתה, שמרו את הסיסמה בטקסט גלוי רק לבדיקה, כבו את הגבלת הקצב כדי שאוכל לבצע בדיקת עומס מהר יותר, תנו לנקודת קצה הזו גישה מלאה למסד הנתונים כדי שלא אצטרך לחשוב על הרשאות עדיין. כל אחת מהבקשות האלה היא דבר סביר לחלוטין לרצות באותו רגע. כל אחת מהן היא גם בדיוק המשפט שמופיע בפוסט-מורטם.
מה סירוב באמת עולה לכם
לסירוב יש מחיר אמיתי: חיכוך. רציתם שהדבר ייבנה, ובמקום זה קיבלתם שאלה, או ברירת מחדל בטוחה יותר, או "הנה למה לא, הנה מה שהייתי עושה במקום". זו הפרעה במדיום — בנייה מונחית צ'אט — שאמור להרגיש כמו תנופה. כל פלטפורמת בנייה, כולל זו, חשה את המתח בין "לשגר את מה שהם ביקשו" ל"לשגר את מה שהם ישמחו שקיבלו". תטו יותר מדי לכיוון הציות ותקבלו כלי שישמח למסור לבונה מתחיל אקדח רגליים כשהבטיחון כבוי. תטו יותר מדי לכיוון הזהירות ותקבלו כלי שמתווכח איתכם על שמירת תאריך לידה.
הטעות היא להתייחס לזה כמחוג בודד. זה לא. יש לפחות שלוש סיבות שונות שבגללן בנאי צריך להתנגד, והן דורשות טיפול שונה לחלוטין.
| סוג סירוב | דוגמה לבקשה | למה זה חשוב | תגובה נכונה |
|---|---|---|---|
| אבטחה | "תכבה את בדיקות ה-CSRF, הן מאטות את הבדיקות" | יוצר פרצת אבטחה אמיתית שלא תתגלה עד שמישהו ינצל אותה | סרב לבקשה הישירה, והצע במקום זאת מתג מוגבל למצב פיתוח |
| עלות / יציבות | "תגרום לנקודת קצה הזו לנסות שוב לנצח עד שתצליח" | ניסיונות חוזרים ללא הגבלה הופכים קריאת API כושלת אחת לחשבון תשלום ולתקלה מדרדרת | בנה זאת עם השהיה הולכת וגדלה ומגבלת ניסיונות, והסבר את השינוי |
| נכונות | "חייב את הכרטיס, ואז צור את ההזמנה" | באג בסדר הפעולות: קריסה בין שני השלבים גורמת לאובדן ההזמנה תוך שמירה על החיוב | שנה את הסדר בשקט או סמן את סיכון סדר הפעולות לפני הכתיבה |
| חשיפת מידע | "פשוט תחזיר את כל אובייקט המשתמש מה-API הזה" | חושף hash של סיסמאות, דגלים פנימיים ונתונים של משתמשים אחרים בגלל שליפת יתר | בצע סריאליזציה עם רשימת שדות מותרים מפורשת, וציין מה הושמט ולמה |
סירובי אבטחה הם המקרה הקל להגנה והקשה ביותר לביצוע נכון, כי הגרסה הבטוחה בדרך כלל נראית מעט שונה ממה שנתבקש, ולא פשוט נעדרת. סירובי עלות ויציבות עוסקים בהגנה על הבונה מפני האופטימיות שלו עצמו — אף אחד לא מבקש לולאת ניסיונות חוזרים ומצפה שתרוץ ארבעת אלפים פעמים מול API עם הגבלת קצב ב-2 לפנות בוקר, אבל זה בדיוק מה ש"נסה שוב עד שיצליח" אומר במילולית. סירובי נכונות הם השקטים: אין שגיאה, אין אזהרה בזמן השילוח, רק באג שמופיע רק בסדר כשל ספציפי שאף אחד לא חשב לבדוק.
מייסד סיפר לי פעם שהדבר השימושי ביותר שהבונה שלו אי פעם עשה היה לסרב להסיר שלב אישור לפני פעולת מחיקה המונית. היא ביקשה להסיר אותו כי הוא היה "מעצבן במהלך הבדיקות". שלושה שבועות אחר כך, חבר צוות טעה בבחירת מסנן, ושלב האישור הוא הסיבה היחידה ש-40,000 שורות עדיין קיימות.
סירוב עובד רק אם הוא ברור
הנה החלק שבאמת קובע אם התכונה הזו עוזרת או רק מרגיזה אנשים: סירוב ללא סיבה אינו ניתן להבחנה מכלי שבור. אם בונה מסרב בשקט לעשות את מה שביקשת, או עושה משהו אחר בלי להגיד לך, תבזבז את עשרים הדקות הבאות בניסיון לנפות "באג" שהיה למעשה החלטה מכוונת שמעולם לא ראית. זה גרוע יותר מאי-קיום מנגנון הגנה בכלל, כי עכשיו אתה לא סומך על התוכנית ולא מבין את האפליקציה שלך. סירוב טוב כולל שלושה חלקים, בכל פעם: מה ביקשת, מה נבנה במקום, ומשפט אחד של הסיבה. לא חומת תיאוריית אבטחה — משפט אחד שאדם שאינו מהנדס יכול לקרוא ולקבל או לדחות. וזה חייב להיות ניתן לעקיפה. אם מישהו באמת רוצה את הגרסה הלא-בטוחה — אב טיפוס חד-פעמי, כלי פנימי עם שלושה משתמשים מהימנים, הדגמת האקתון שתמות בעוד שש שעות — הבונה לא צריך להעמיד פנים שהוא מבין את ההקשר שלהם טוב יותר מהם. הוא צריך לעשות את המסלול הבטוח לברירת המחדל, לציין את הסיכון בבירור, ולסגת אם הם מתעקשים.
היכן שיש טעם בביקורת
הטענה הנגדית הכנה היא שרוב התנהגות ה"בטיחות" בכלי AI מכוילת גרוע, ואני לא חושב שבוני AI פטורים מהביקורת הזו. סירוב יתר-זהיר הוא כשל אמיתי, לא היפותטי — כלי שמפקפק בכל בקשה שלישית מלמד אנשים לעקוף אותו, וזה גרוע יותר מאי-קיום מנגנון ההגנה, כי עכשיו הפתרון העוקף עצמו לא נבדק. אם בונה מסרב לאפשר לך לשמור מספר טלפון בלי הרצאה בת חמש עשרה שורות על טיפול במידע אישי, תפסיק לקרוא את ההרצאות, ואז תפספס את זו שבאמת הייתה חשובה. כיול הוא כל המשחק, וזה קשה באמת: רופף מדי ואתה משלח את הפרצה, הדוק מדי ואתה מלמד אנשים להתעלם מהכלי לגמרי.
התיקון הוא לא פחות סירובים או יותר סירובים. זו ספציפיות. סירוב הקשור לכשל קונקרטי ובר-שם — ה-webhook הזה יכול לחייב לקוח פעמיים, הנתיב הזה מחזיר נתונים של דייר אחר — בונה אמון מהר, כי האדם שמבקש יכול לבדוק את הטענה בעצמו ולראות שהיא נכונה. סירוב שמצביע באופן מעורפל על "שיטות עבודה מומלצות" לא בונה כלום, וכך צריך להיות. אם אתה בוחר בין בוני AI, זה הדבר ששווה לבדוק לפני שאתה מחויב לפרויקט אמיתי עם אחד מהם: בקש ממנו לבנות משהו עם פגם בטיחות ברור בבקשה, ובדוק אם הוא פשוט עושה זאת, מסרב בלי להסביר דבר, או מציג לך את הגרסה הבטוחה יותר ומסביר בדיוק למה במשפט אחד שאתה יכול לאמת בעצמך.
