המושג 10x programmer הומצא הרבה לפני ש AI כתב את כל הקוד. הוא בא לתאר את התופעה שיש מפתחים הרבה יותר יעילים שמקפיצים את הארגון קדימה ולפעמים מפתח או מפתחת כאלה יכולים להיות שווים לארגון אפילו יותר מעשרה אחרים. אותם מפתחי 10x כמובן לא מצטיינים בגלל שהם מקלידים מהר יותר (יש גבול כמה מהר אפשר להקליד, וממילא מהירות הקלדה אף פעם לא היתה הבעיה). התכונות שהפכו אותם ליעילים היו חדות חשיבה, יכולת לראות דברים שאחרים לא ראו, יכולת קבלת החלטות, בחירת הטכנולוגיה הנכונה, בניית מערכת כך שבאגים יקרו פחות או יהיו קלים יותר לאיתור.

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

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

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

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

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

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