ToCode

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

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

באגים בקוד של אחרים הבאגים הכי מתסכלים הם באגים בקוד של אחרים, ובמיוחד בקוד של אחרים כשאין לך גישה לקוד המקורי או לסביבת הריצה שלהם. כשהתוכנה שלי צריכה בשביל לעבוד למשוך מידע מ X אבל אותו X החליט היום בבוקר שהוא מחזיר מידע בפורמט שונה ממה שהחזיר עד עכשיו זה אני שצריך להתאים את הקוד לפורמט החדש. ואם אותו X מתחיל להחזיר שגיאות על בקשות שעד היום עבדו זאת המערכת שלי שלא תעבוד עד ש X יחזור לעבוד. כשאמזון יורדת כל האינטרנט יורד איתה, כי כולם משתמשים בתשתיות הענן של אמזון בתור בסיס למערכות שלהם. אם שירות ענן מפסיק להגיב כל המערכות שתלויות באותו שירות ענן יפסיקו לעבוד. וכך נולדה שרשרת האמון שאנחנו צריכים לתעד בכל מערכת שנבנה: 1. קוד שלי - אמון הכי גבוה, אני רואה את הקוד ושולט בסביבת הריצה. 2. קוד של ספריה שמשולב בקוד שלי - דורש קצת יותר זהירות, אני שולט בסביבת הריצה ויש לי גישה לקוד ובכל זאת לא אני כתבתי ואולי תיקון שאני אכניס ייצור קונפליקט עם פיתוח עתידי של אותה ספריה. 3. מערכת צד שלישי שרצה אצלי On Prem - עוד יותר זהירות, הפעם הקוד בשפה שאני לא מכיר ולא בטוח שיש לי גישה אליו, אבל לפחות אני שולט בסביבת הריצה. במקרה חירום אני יכול להעלות או להוריד גירסה ובכל מקרה אני מחליט מתי לשדרג. 4. מערכת צד שלישי שרצה על מחשב של מישהו אחר - זו תשתית הענן של אמזון. אלה המערכות שצריך להיות הכי חשדנים לגביהם כי כשמשהו נשבר אנחנו תקועים. הבעיה שאין התאמה בין רמת האמון הנדרשת לכמה קל להתחיל להשתמש במוצר: הכי קל לשלב מוצר ענן חדש במערכת שלי (הרבה פעמים זו רק קריאת API). להתקין ספריה חיצונית יהיה יותר קשה, לכתוב לבד עוד יותר קשה ולהתקין מערכת חדשה On Prem דורש לא רק קוד אלא גם משאבי מחשוב נוספים וניטור מה שהופך את זה לאופציה הכי פחות נגישה. וכמובן AI מסבך עוד יותר את התמונה כי עכשיו אני לא יודע מי כותב את הקוד ומה האיכות. מה עושים? קל להגיד קשה לממש: לומדים לקודד, בונים מערכות טובות, משתמשים במעט שירותי ענן ובוחרים שירותים אמינים, מבקרים קוד AI שנכתב, משלבים תלויות חיצוניות רק כשאנחנו מבינים מי כותב את הספריה ומי מפקח על גירסאות חדשות. וכדאי לזכור שזה תהליך, לא להיות קשים עם עצמנו שהמערכת שלנו היום לא כזאת. ה GDPR כן עשה משהו טוב בזה שהוא הכריח אותנו למפות את כל המערכות צד-שלישי שאנחנו מתחברים אליהן. עכשיו תוסיפו למיפוי הזה דירוג אמינות, בחרו מערכות יציבות שלא נופלות ונסו להבין אם באמת אתם צריכים מערכת צד-שלישי לפיצ'ר הזה במערכת או שאתם תעשו את זה טוב יותר In House.

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

תרגילי JavaScript למתחילים יש לכם חברים או ילדים שמתחילים ללמוד תכנות מאפס ואתם רוצים לעזור להם לתרגל? הנה דף לא מאוד ארוך של תרגילים בסיסיים שמתאימים לכל מי שמתחיל או מתחילה ללמוד תכנות. הדף כתוב בשפת JavaScript אבל אפשר בקלות להשתמש בו גם לשפות אחרות. אל תפספסו את פרומפט העזר בסוף הדף שיגרום ל ChatGPT להיות המורה הפרטי שלכם. הדפסות למסך 1. כתבו תוכנית שמדפיסה את המספר 5 ל console. 2. כתבו תוכנית שמדפיסה את תוצאת התרגיל 725 כפול 912 לקונסול. 3. כתבו תוכנית שמדפיסה את שמכם ואת גילכם למסך, כל אחד בשורה נפרדת. 4. כתבו תוכנית שמדפיסה את שמכם ואת גילכם למסך, שניהם באותה שורה. משתנים 5. כתבו תוכנית ששומרת את גילכם למשתנה ואז מדפיסה אותו. 6. עדכנו את התוכנית כך שאחרי ההדפסה היא תוסיף 1 לגיל ואז תדפיס את ערך המשתנה שוב. 7. עדכנו את התוכנית כך שאחרי ההדפסה היא תנסה להוסיף את המחרוזת "a" לגיל ואז תדפיס אותו שוב. מה הודפס? שימו לב שב JavaScript פעולת החיבור מושפעת מסוג הדבר שנמצא במשתנה: כשמחברים מספרים מקבלים את סכומם וכשמחברים מחרוזות מקבלים את שרשורן. המציאו דוגמאות נוספות כדי להדגים התנהגות זו. 8. כתבו תוכנית שמגדירה משתנה בשם minutes ושומרת בו את הערך 5 ולאחר מכן מגדירה משתנה בשם seconds ושומרת אליו את ערך הביטוי minutes כפול 60 (כלומר מספר השניות של minutes). 9. כתבו תוכנית ששומרת למשתנה מחיר של מוצר ומדפיסה את מחיר המוצר בצירוף מע"מ כלומר עם תוספת 18%. תנאים 10. כתבו תוכנית ששומרת את גילכם למשתנה ולאחר מכן בודקת האם הגיל שלכם גדול מעשר. אם כן היא מדפיסה הודעה אחת ואם לא הודעה אחרת. 11. עדכנו את התוכנית ושנו את התנאי כך שהתוכנית תבדוק האם הגיל שלכם הוא מספר זוגי. לאחר מכן עדכנו אותה שוב ובדקו האם הגיל מתחלק ב-7. 12. כתבו תוכנית ששומרת סיסמה סודית למשתנה בשם password. לאחר מכן התוכנית תבדוק אם הערך במשתנה הוא secret היא תדפיס שהסיסמה לא מספיק בטוחה. כל סיסמה אחרת כן מספיק טובה. 13. עדכנו את תוכנית הסיסמאות כדי שתבדוק אם אורך הסיסמה ששמורה במשתנה password גדול מ 8. הדפיסו שהסיסמה בטוחה רק אם היא ארוכה מ-8 תווים. 14. כתבו תוכנית ששומרת במשתנה בשם height גובה של מלבן ובמשתנה בשם width רוחב שלו. זכרו ששטח מלבן הוא רוחב כפול גובה. על התוכנית לבדוק אם שטח המלבן גדול מ-50 להדפיס הודעה אחת ואם לא גדול מ-50 להדפיס הודעה אחרת. לולאות 15. כתבו תוכנית המדפיסה את שמכם 10 פעמים למסך. 16. כתבו תוכנית שמחשבת את הסכום 1+2+3+4+...+100. 17. כתבו תוכנית שמחשבת את המכפלה 1*2*3*4*5*6*7*8*9*10. השתמשו בלולאה. 18. כתבו תוכנית שמדפיסה את סכום המספרים הזוגיים מ-2 עד 100. 19. כתבו תוכנית JavaScript שמוצאת את המספר הראשוני הקטן ביותר שיהיה גדול מאלף, כלומר המספר הקטן ביותר שגדול מאלף שמתחלק רק באחד ובעצמו. 20. כתבו תוכנית JavaScript שמוצאת את המספר הקטן ביותר שמתחלק גם ב 13, גם ב 15 וגם ב 17. 21. כתבו תוכנית JavaScript שמדפיסה את הפלט הבא:

1
22
333
4444
55555
666666
7777777
88888888
999999999

22. כתבו תוכנית JavaScript שמציירת משולש מכוכביות:

09:16:10.079 demo.html:11      *    
09:16:10.079 demo.html:11     ***   
09:16:10.079 demo.html:11    *****  
09:16:10.079 demo.html:11   ******* 
09:16:10.079 demo.html:11  *********

23. כתבו תוכנית JavaScript שמדפיסה את לוח הכפל עד 100. טיפ לסיום: פרומפט עזרה מ ChatGPT תקועים על אחד התרגילים? מחפשים מורה לתכנות? ChatGPT ישמח להיות המורה שלכם. הנה הפרומפט: אני לומד JavaScript ואין לי רקע קודם בתכנות. אני מנסה לפתור את התרגיל: הדביקו את התרגיל כאן הסבר לי לאט את הפיתרון כולל כל שלבי הביניים ואת כל המושגים ב JavaScript ובתכנות שאני צריך להכיר כדי שאוכל לפתור תרגיל זה ותרגילים דומים בהמשך. כדי לוודא שהבנתי הצע שלושה תרגילים דומים.

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

פוסט נוסטלגי: הצגת XML עם XSLT בדפדפן לאחרונה נשמעים קולות שקוראים להפסיק לתמוך בהצגת XML באמצעות XSLT בדפדפנים וזו הזדמנות טובה להיזכר בסטנדרט שאף אחד לא משתמש בו אבל עדיין עובד בכל הדפדפנים והיה נשמע כמו רעיון טוב לפני בערך 20 שנה. באזור שנת 2000 האינטרנט הגיע למיצוי. פיירפוקס ייוולד רק ב 2004 וכרום עוד 4 שנים אחריו ב 2008. דפדפן האינטרנט שכולם השתמשו בו נקרא Internet Explorer. גירסה 5 שלו יצאה ב 1999 וב 2001 גירסה 6 שנחשבה אלמותית. באותו הזמן מפתחים ראו באינטרנט הזדמנות ליצירת אפליקציות מבוזרות ולחבר בין מערכות שונות, בלי קשר לדפדפן. כלומר כל מערכת תשלח ותקבל קבצי מידע מסוג XML ובאמצעותם תחובר למערכות אחרות, כך שלדוגמה מערכת להזמנת טיסות תכיל שרת שישלח XML-ים עם המידע לתוכנת צד לקוח שתדע להציג את ה XML-ים האלה. וכן היתה טכנולוגיה בשם Java Applets שאפשרה לכתוב קוד Java ולהפיץ אותו באמצעות דפדפן אינטרנט. בתוך העולם הזה היה נשמע רק הגיוני לאפשר לדפדפנים להציג קבצי XML, אך מאחר ודפדפנים ידעו להציג רק קבצי HTML ו XML הוא פורמט כללי שבו אין מגבלה על שמות התגים עלה הצורך למפות בין תגיות XML לתגיות HTML. בדוגמה של אתר הזמנת הטיסות אם כבר יש לך מערכת להזמנת טיסות שמוציאה קבצי XML לתוכנות ול Applets שרצים אצל הלקוחות, תוכל להוסיף קובץ מיפוי שיראה לדפדפן איך לעבור מקובץ נתוני הטיסות שלך ל HTML וכך גם הדפדפן יוכל להציג את המידע לפחות לקריאה. ואיך זה נראה? האמת שדי פשוט. ניקח קובץ XML לדוגמה מאתר של ספריה שמכיל רשימה של 3 ספרים:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>

<librairie>
  <livre>
    <titre>Le Petit Prince</titre>
    <auteur>Antoine de Saint-Exupéry</auteur>
    <prix>8.50</prix>
  </livre>
  <livre>
    <titre>1984</titre>
    <auteur>George Orwell</auteur>
    <prix>9.90</prix>
  </livre>
  <livre>
    <titre>Harry Potter à l'école des sorciers</titre>
    <auteur>J.K. Rowling</auteur>
    <prix>12.00</prix>
  </livre>
</librairie>

חוץ מהצרפתית שימו לב לשורה השנייה בקובץ, שמצביעה לקובץ מיפוי. זה תוכנו:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <!-- Le résultat sera du HTML -->
  <xsl:output method="html" encoding="UTF-8" indent="yes"/>

  <!-- Modèle de transformation principal -->
  <xsl:template match="/">
    <html>
      <head>
        <title>Liste des livres</title>
        <style>
          body { font-family: Arial, sans-serif; margin: 40px; }
          table { border-collapse: collapse; width: 60%; }
          th, td { border: 1px solid #999; padding: 8px; text-align: left; }
          th { background-color: #f2f2f2; }
        </style>
      </head>
      <body>
        <h2>Ma librairie</h2>
        <table>
          <tr>
            <th>Titre</th>
            <th>Auteur</th>
            <th>Prix (€)</th>
          </tr>
          <!-- Boucle sur chaque livre -->
          <xsl:for-each select="librairie/livre">
            <tr>
              <td><xsl:value-of select="titre"/></td>
              <td><xsl:value-of select="auteur"/></td>
              <td><xsl:value-of select="prix"/></td>
            </tr>
          </xsl:for-each>
        </table>
      </body>
    </html>
  </xsl:template>

</xsl:stylesheet>

קובץ המיפוי מכיל תבנית HTML שבתוכה פקודת for-each שאחראית לשתול את המידע מה XML לתוך התבנית. עכשיו הקסם מתחיל: 1. שימו את שני הקבצים באותה תיקיה. 2. הפעילו משורת הפקודה בתיקיה:

npx local-server

3. כנסו בדפדפן ל localhost:8000 ותוכלו לראות את רשימת הספרים בטבלה - כאילו בנינו קובץ HTML עם הרשימה. תהנו מזה כל עוד זה עובד. הדיבור הוא להוריד את התמיכה עד סוף 2026 אבל נחכה ונראה: https://developer.chrome.com/docs/web-platform/deprecating-xslt

הכלל הראשון של סוכני קידוד מישהו פרסם רשימה של 10 כללים של סוכני קידוד. כבר הראשון שבהם מעורר מחלוקת: > Your Agent is not going to have a better idea about what you want to achieve than you do. In other words, if you don’t have a clear idea about what you want, your agent won’t either. והבעיה היא המילה what במשפט. כמפתחים חלק חשוב מהעבודה שלנו הוא לתרגם דרישות לקוח בשפה טבעית לשפת מכונה ואותו תרגום כולל קבלת החלטות וגם ניחושים לגבי העתיד. אם הלקוח שלי זיהה שטבלה מסוימת לא מציגה את הנתונים כמו שהוא רוצה לראות אותם אני כמפתח יכול לבחור אם אני רוצה לשנות רק את התצוגה באותה טבלה או לבנות תשתית לבחירת אופן התצוגה שתעזור לי גם לתקן את הטבלה וגם אולי לתקן מקומות אחרים בעתיד (אם הלקוח יבקש אותם) או לשנות את מבנה בסיס הנתונים. לכל אופציה יתרונות וחסרונות שתלויים בכל הסיטואציה של המערכת והתוכניות לעתיד. ברור שלסוכן קידוד אין את הכלים להחליט איזה משלושת האופציות היא הכי טובה לטיפול בדרישה זו. מה שסוכן קידוד כן יודע לעשות ומאוד טוב זה לייצר רעיונות. אז באותה סיטואציה של דרישת לקוח לתקן טבלה אני יכול להיעזר בסוכן קידוד כדי לקבל מפה רחבה של האפשרויות שלי - מפה שלעולם לא הייתי מקבל מ Junior Engineer בצוות. פרומפטים לדוגמה: > לקוח ביקש לשנות את מבנה הטבלה. אני מתלבט אם צריך לשנות רק את התצוגה או גם את הנתונים בבסיס הנתונים. הצג לי את היתרונות והחסרונות של כל גישה. > לקוח ביקש לשנות את מבנה הטבלה ואני חושד שהוא יבקש שינויים דומים בעתיד. מפה במערכת את כל המקומות שעשויים להרוויח מיצירת תשתית גנרית לבחירת אופן תצוגה של נתונים אלה. > לקוח ביקש לשנות את מבנה הטבלה. סרוק את כל ה Issues מהשנה האחרונה ושער מה יהיו השינויים הבאים שהלקוח יבקש על טבלה זו. נמק באמצעות דוגמאות מ Issues קודמים. > לקוח ביקש לשנות את מבנה הטבלה. הצע 5 דרכים שונות לביצוע השינוי, החל משינוי נקודתי בתצוגה ועד שינוי גורף במבנה בסיס הנתונים. > אני רוצה לשנות את מבנה הטבלה דרך שינוי התצוגה. למה חשוב לשים לב כשכותבים את השאילתות מבחינת ביצועים ושימוש בזיכרון? ההצעה להתיחס לסוכן קידוד בתור Junior Engineer נכונה לפרויקטים מסוימים בעיקר פרויקטים חדשים. בפרויקטים וותיקים כשהקידוד הוא לא צוואר הבקבוק אנחנו מעדיפים להשתמש ב AI כמכונת רעיונות שמחזקת ומגבירה את החשיבה. כן הוא בהחלט יודע יותר ממני ואני שמח לסחוט כל טוקן של אינפורמציה לפני שאני ניגש לשבור את הקוד.

אבל מי יבדוק את זה? דיברתי עם לקוח אתמול ועל הדרך גילינו באג במערכת שלהם. בלי להכיר את הקוד שמחתי לעזור "אל תדאגו אני יודע לדבר עם קופיילוט" אמרתי ותוך שעתיים היתה להם גירסה מתוקנת רצה על מכונת בדיקה. אבל כשצלצלתי בשמחה לספר להם על ההישג קיבלתי מקלחת קרה: "אתה יודע כמה פיצ'רים של AI כבר יש לנו מחכים לבדיקה?", "מי יודע איזה בעיות זה הכניס" ו"זה לא תיקון שאפשר פשוט לדחוף ללקוחות ולראות מה יקרה". הנה עוד טייק שכתב סאם סאפרון באותו נושא: > On one side there is a contributor who spent a few minutes fiddling with AI prompts, on the other side you have an engineer that needs to spend many hours or even days deciphering alien intelligence. האם אנחנו סתם שמרנים או שיש פה נקודה? למה אנחנו דורשים שבן אדם יקרא ויבין את הקוד לפני שנוכל לאשר אותו למערכת? והאם אי פעם זה הולך להשתנות? נתחיל בהווה - כל עוד AI הוזה, טועה ומניח הנחות שגויות, גם אם זה "רק" בחלק קטן מהריצה, אנחנו צריכים מוח אנושי שיוודא שמיזוג של הפיצ'ר לא שובר כלום. זה המצב כרגע בכל המודלים שאנחנו מכירים. לדעתי זה גם יהיה המצב בעתיד הנראה לעין. לכן הצעד הבא הוא להבין איך לארגן את קבוצות הפיתוח כך שיהיה לנו יותר קל להבין קוד של AI. כמה טיפים בנושא הזה: 1. החלטה מהירה אם לזרוק או לשמור - כשקוראים קוד של בן אדם אתם רוצים לתת לו ליהנות מהספק, אנחנו מניחים שהיתה מחשבה מאחורי הדברים ושווה להתאמץ כדי להבין אותה. ב AI זה לא המצב. אם הסתכלתי 5-10 דקות על קוד AI והקוד לא קוהרנטי מספיק, לא מספר את הסיפור הנכון, אפשר לזרוק אותו ולתת ל AI לייצר חדש. 2. התמקצעות והבנת הגורמים שמשפיעים על הקוד ש AI מייצר. אני רוצה ש AI יכתוב קוד שאני יכול להבין מהר. אם זה לא המצב אני צריך להתאים את מבני הקבצים, ארכיטקטורה, קבצי פרומפט ואפילו שמות של קלאסים ופונקציות כדי שדברים יתחברו. 3. אנחנו צריכים בדיקות, סביבות בדיקה, וכלים שמאפשרים לנו לראות מה קורה במערכת כשאנחנו מריצים ניסוי ולהבין מהר מה עובד ומה נשבר. 4. והכי חשוב רמה מקצועית. קוד ש AI מייצר תמיד מבוסס על רעיונות שהוא למד מהתעשייה, מספרים, מפוסטים ומקוד של אחרים. חשוב לראות מאיפה זה בא ולהבין כמה שיותר מהר אם זה הכיוון שמתאים לפרויקט שלי. 5. יכולת מיזוג בקבוצת בקרה וגידור הסיכון - אם AI כותב מיגרציה ל DB אני רוצה לתת ל-5 מפתחים לקרוא אותה לפני שאני מריץ את ה SQL. אבל אם AI משנה משהו בקוד UI אני שמח לדחוף את השינוי לקבוצת משתמשים קטנה ובהדרגה להרחיב את קבוצת הבדיקה שלי עד שזה יגיע לכולם. אם AI שולח PR שמשפיע על עשרות קבצים אני מעדיף שהארכיטקט הראשי יקרא את זה לפני שאני מוכן לשלב את השינוי, אבל בעדכון מימוש של פונקציה אחת אני מוכן לקחת סיכון יותר גדול. לא כל הפיצ'רים זהים ולכן גם האנרגיה שאני משקיע בקריאת קוד של כל פיצ'ר יכולה להיות שונה.

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

create a twitter clone using python and django. Use only memory no persistent storage. support actions:

login
tweet
follow / unfollow
retweet
public feed with latest tweets
Use only HTML/CSS/JavaScript not frontend framework

וזה הריפו שנוצר: https://github.com/ynonp/copilot-twitter-clone זה לא רע! מתכנת אנושי שהיה מקבל פרומפט כזה ומצליח לייצר כזה ריפו היה מתקבל לעבודה בקלות בהרבה חברות. אבל זה לא מוצר. מאפיין מרכזי של קוד הוא המחשבה שהושקעה בו: לאן המערכת הולכת? מי הולך להמשיך לעבוד על הקוד הזה? מה לא מופיע בפרומפט? מה יקרה אם? ואיך? קוד הוא קודם כל מערכת של אילוצים לגבי שינויים עתידיים, כל שורת קוד מכניסה לעולם תפיסת עולם ומשפיעה על מה אפשר או אי אפשר יהיה לעשות בהמשך. ו AI? הוא כל עוד מנגנון קבלת ההחלטות של ה AI הוא הסתברותי אין לו סיכוי לקבל את ההחלטות הנכונות בזמן הבנייה. הסטטיסטיקה לרעתו. ככל ש GenAI כותב את שורות הקוד יותר מהר כך אנחנו מבינים בצורה יותר ברורה שמהירות הקלדה היא לא הסיפור כאן. המפתח להנדסת תוכנה - אם אני כותב X אז בעתיד יהיה יותר קל לבנות את Z ויותר קשה לבנות את Y.