תירגעו. תכננו לפני כתיבת הפרומפט.

לאחרונה הבנתי משהו בנוגע למנהל הקודם שלי.

הוא ניסה שוב ושוב לשכנע אותי להשתמש ב-Kiro.

״באסל, תשתמש ב-Kiro.״

התגובה המיידית שלי הייתה פשוטה:

״מה לעזאזל זה Kiro?״

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

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

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

אז אני משחרר את זה.

מהר. נקי. גמור.

לפחות, זה מה שאמרתי לעצמי.

המנהל שלי הבחין בבעיה

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

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

זו הייתה הסיבה שהוא המשיך לומר:

״באסל, תשתמש ב-Kiro.״

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

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

במילים פשוטות יותר, Kiro הכריח אותי לתכנן.

וכנראה הייתי צריך שיכריחו אותי.

כתיבת פרומפטים ותכנון הם כישורים שונים

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

גם פרומפט מפורט יכול להסתיר חשיבה חלשה.

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

ואז הבינה המלאכותית מתחילה לממש מיד.

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

לפעמים היא רק קיבלה פרשנות.

תכנון יוצר עצירה בין הרצון במשהו לבין בנייתו. בזמן העצירה אפשר לשאול:

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

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

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

בעיית המזון המהיר

חשבו על כתיבת פרומפטים בלי תכנון כמו על מזון מהיר.

אתם רעבים. מזמינים משהו. הוא מגיע כמעט מיד. הוא טעים, והבעיה המיידית נעלמת.

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

כך יכול להרגיש מימוש מהיר באמצעות בינה מלאכותית.

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

שוחרר.

אבל מה למדתם?

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

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

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

שתי ההזיות ה״לא מזיקות״

נהגתי להתייחס להזיות קטנות של בינה מלאכותית כרעש רקע.

הבינה המלאכותית לא הבינה שני פרטים? בסדר. התכונה עדיין עובדת.

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

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

שלב תכנון הופך את ההחלטות האלה לגלויות.

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

הרבה יותר זול לתקן אותה אז.

למהירות עדיין יש ערך

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

הלקח הוא שהמהירות נעשית בעלת ערך רב יותר כשיש לה כיוון.

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

המטרה היא ביצוע מתוך מחשבה, ללא בירוקרטיה מיותרת.

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

הגדירו את הדרישות.

בדקו את התכנון.

חלקו את העבודה למשימות.

ואז תנו לבינה המלאכותית להתקדם מהר.