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

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

מנסחים חוזה לפני בקשת קוד

במקום ״תבנה לי authentication״, כתבו מה צריך לקרות: קישור חד־פעמי, תפוגה, שמירת גיבוב של האסימון, עוגיית session והגנה מפני ניסיונות חוזרים. הוסיפו מה אסור: אין פתיחת חשבון על סמך מייל ללא אימות ואין הופעת אסימונים בלוגים.

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

מבקשים חלופות והנחות

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

Requirement -> Candidate approaches -> Assumptions
            -> Small verification -> Implementation -> Review

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

בודקים את התלות מול המקור

שמות פונקציות ופרמטרים יכולים להיראות אמינים גם כשהם לא קיימים בגרסה שבה אתם משתמשים. בדקו בתיעוד הרשמי, בקוד החבילה או בטיפוסים המותקנים. כשמחברים שירות חיצוני, דוגמת JSON שנראית סבירה אינה תחליף למפרט ולבדיקת sandbox.

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

בדיקות צריכות לאתגר את הפתרון

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

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

שומרים על יכולת להסביר ולתחזק

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

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

תרגיל מעשי

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

אפשר להמשיך לIdempotency כתרגיל טוב לבדיקת גבולות, או לObservability כדי לתכנן איך תדעו מה קרה אחרי ההשקה. כלי חזק עוזר לבנות; שיקול דעת עוזר לדעת מה נבנה.