כלל ה-80/20 של קוד AI

AI כתב 80% מהפיצ'ר שלי ב-10 דקות. הקוד נראה נקי. הלוגיקה הייתה הגיונית. זה עבד בניסיון הראשון. הרגשתי נהדר.

אבל AI שימושי עבור ה-80% הראשונים וחסר תועלת עבור ה-20% האחרונים.

AI מבצע אופטימיזציה עבור ה-"happy path". הוא בונה לעולם שבו הכל הולך כשורה. תוכנה אמיתית חיה בעולם שבו דברים משתבשים.

בניתי לאחרונה Sol Email Worker. ה-AI יצר את הלוגיקה המרכזית, את ה-threading ואת ה-routing תוך 20 דקות. זה היה החלק הקל.

ה-20% האחרונים דרשו את המומחיות האמיתית שלי:

• Deduplication: טיפול בהודעות כפולות. • Sender-skip logic: הימנעות מעיבוד הודעות של עצמי. • Error recovery: ניהול תגובות API בלתי צפויות. • Log output: הפיכת ה-debugging לאפשרי ב-2 לפנות בוקר.

ה-AI עשה מה שביקשתי. נכשלתי בלבקש להתייחס למקרי קצה (edge cases) כי עדיין לא חשבתי עליהם לעומק.

יש לנו בעיית מדידה. אנחנו עוקבים אחרי שורות קוד וכרטיסים (tickets) שנסגרו. המדדים האלה מתגמלים את ה-80% המהירים. אף אחד לא עוקב אחרי הזמן המושקע בטיפול בשגיאות או בבדיקות null.

ה-20% האלה בלתי נראים בלוח בקרה (dashboard), אבל שם קורה העבודה האמיתית. אני עוקב עכשיו אחרי זמן prompt-to-ship. זה הזמן מהפרומפט הראשון ועד לפיצ'ר יציב ב-production. המספר הזה הוא תמיד לפחות פי 4 מזמן יצירת ה-AI.

כך אני עובד עכשיו:

  • אני מקצה פי 4 מזמן ה-AI עבור כל משימה.
  • אני כותב פרומפטים עבור ה-"unhappy path". אני אומר ל-AI להניח שהרשת קורסת או שה-API מחזיר null.
  • אני מתייחס לטיוטה הראשונה כנקודת התחלה, לא כקו סיום.

3 השעות שביליתי בטיפול בשגיאות אחרי 30 שניות של יצירה לא היו בזבוז. זו הייתה העבודה האמיתית. ה-AI העביר את העבודה מכתיבת המבנה להפיכת הקוד לממשי.

להפוך קוד לממשי זה תהליך איטי. זה דורש את ההקשר הספציפי שלך, את המשתמשים שלך ואת היסטוריית ה-codebase שלך. זה מה שמומחיות אומרת.

AI עובד בטריטוריה מוכרת. מקרי קצה הם טריטוריה לא מוכרת בכל פעם.

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

מקור: https://dev.to/amrree/the-8020-rule-of-ai-code-id

קהילת למידה אופציונלית: https://t.me/GyaanSetuAi