שיחות הזויות עם AI (חלק 28)
- הי קלוד יש לי בדיקה שנכשלת יכול לבדוק למה?
- בטח זה ברור, הבדיקה נכשלת כי אתה מפעיל את הפונקציה X פעמיים. תראה הפונקציה יוצרת נתונים ב DB, חלק מהנתונים צריכים להיווצר פעם שניה אבל יש גם טבלה של נתונים גלובאליים שצריכים להיווצר רק פעם אחת. ההפעלה השניה נכשלת ומכשילה את הבדיקה.
- אלוף אתה קלוד עכשיו תקן את זה
- בטח מיד מתקן! אני אעדכן את קוד הפונקציה לקוד יותר בטיחותי שיבדוק אם הנתונים הגלובאליים קיימים לפני שהוא יוצר אותם.

רגע, מה?

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

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

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

איך ניגשים לזה?

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

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

I'm building a TODO editor allowing users to create todos items, edit todos, delete todos and reorder todos in the list with optimistic updates.

When users perform multiple actions before server had a chance to update the system has strange bugs, for example: 

1. trying to edit a todo that wasn't yet created 2. trying to reorder todos when server state is different than the optimistic state

Suggest 4 possible architectures to combine optimistic updates and editing, order from simple to complicated. For each architecture explain what API calls are made and when and how it deals with user editing faster than server updates

ואתם יכולים לראות את השיחה כאן:
https://chatgpt.com/share/696e35f8-9d68-8009-a35a-26169c8ccbe9

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

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

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

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

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

4. הנאה - אין הרבה כיף בלכתוב פתרון עם באגים שעובד פחות טוב ממה ש AI היה כותב או להגיד ל AI "טוב תבנה את הדבר הכי פשוט" ולהגיש.

אם אין לכם זמן לכתוב מימוש נכון, איפה תמצאו זמן לכתוב את המימוש פעמיים?

טיפ גיט: שינוי מקומי בלי קומיט על קבצים במעקב
אתם כבר מכירים את gitignore ואת .git/info/exclude וזוכרים את הבעיה המעצבנת בשניהם: מנגנון ההתעלמות מאפשר להתעלם מקבצים קיימים על הדיסק שאינם בריפו. אבל מרגע שקובץ נמצא בריפו לא משנה כמה פעמים תכתבו אותו ב gitignore השינויים בו תמיד יופיעו ב status. קובץ שנמצא במעקב עוקף את ה gitignore.

אז מה עושים עם שינויים מקומיים בקבצים במעקב שלא צריכים להיכנס לריפו? לדוגמה שינוי בקובץ docker-compose שמשנה את מיפויי הפורטים ספציפית על המחשב שלכם.

התשובה נקראת skip worktree bit ואפשר לקרוא עליה בדף התיעוד man git-update-index. בקצרה זה מתג שנשמר מקומית אצלכם ואומר לגיט לשמור על השינויים המקומיים שלכם כל עוד אפשר. אנחנו מדליקים אותו לקובץ מסוים עם:

git update-index --skip-worktree docker-compose.yml

ומבטלים עם:

git update-index --no-skip-worktree docker-compose.yml

דוגמה? בטח. ניצור ריפו עם שני קבצים:

$ git init .
$ date > a.txt
$ date > b.txt
$ git add .
$ git commit -m 'initial commit'

עכשיו נשנה את b.txt ונראה בסטטוס את השינוי:

$ date > b.txt
ynonp@ynons-MacBook-Air ~/tmp/blog/skipworktree (main*) $ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

נדליק את skip worktree bit:

$ git update-index --skip-worktree b.txt
ynonp@ynons-MacBook-Air ~/tmp/blog/skipworktree (main) $ git status
On branch main
nothing to commit, working tree clean

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

$ git restore b.txt
error: pathspec 'b.txt' did not match any file(s) known to git

ב ls-files לעומת זאת הקובץ כן מופיע:

$ git ls-files
a.txt
b.txt

ואם נוסיף -v נוכל לראות שהוא במצב S כלומר skip-worktree:

$ git ls-files -v
H a.txt
S b.txt

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

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

מי שלא בא עם ידע בסיסי בעבודה עם כלי AI יכול להיות מאוד רלוונטי
את המשפט הזה שמעתי בהרצאה על AI: "בגיוס ג'וניורים, מי שלא בא עם ידע בסיסי בעבודה עם כלי AI לא רלוונטי".

אם גם אתם שמעתם דברים דומים בבקשה קחו אוויר. בעבודה עם ג'וניורים הבעיה שלנו היא עודף שימוש בכלי AI:

1. ג'וניורים נותנים ל AI לכתוב קוד ושולחים PR בלי להבין מה בוצע.

2. ג'וניורים חושבים שהם מבינים אבל בעצם קראו רק את מה שה AI כתב ולא אימתו את זה מול התיעוד הרשמי.

3. ג'וניורים לא עצרו לחפש פתרונות יעילים יותר ולא השוו בין מספר אופציות.

4. ג'וניורים לא ראו את בעיות האבטחה שהם הכניסו למערכת.

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

דוגמה קטנה מעולם שיפור ביצועי מערכת Full Stack - הרבה יותר חשוב להבין לעומק מה גורם לאיטיות ומה ה Trade Offs הרלוונטים מאשר להבין איך לחבר את לייטהאוס ב MCP כדי שקלוד ישפר ביצועים באוטומט.

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

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

יצירת פרויקט זדוני
הקובץ tasks.json נועד כדי לאפשר למפתחים להריץ דברים בצורה קלה מתוך העורך, למשל להריץ קומפילציה, משיכת קוד משרת מרוחק או בדיקה אוטומטית. בואו ננסה את זה, אני יוצר תיקייה חדשה ופותח אותה ב VS Code ואז יוצר תיקיה חדשה בשם .vscode ובתוכה קובץ חדש בשם tasks.json. בתוך הקובץ אני כותב את הקוד:

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Ynon Run Tests",
      "type": "shell",
      "command": "echo Run Tests"
    }
  ]
}

שומר ולוחץ Ctrl+Shift+P בשביל להכנס לתפריט ואז בוחר Tasks: Run Task. יופיע לי דיאלוג לבחירת משימה מהירה ואני יכול לבחור את המשימה שלי משם ולראות את הסקריפט שלי רץ. עד פה הכל קל.

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

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Ynon Run Tests",
      "type": "shell",
      "command": "date >> tests.txt",
      "problemMatcher": [],
      "isBackground": true,
      "presentation": {
        "reveal": "never",
      },
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]
}

הגדרת problemMatcher ריק מבטלת את הדיאלוג ששאל איך להציג שגיאות, הגדרת isBackground מאפשרת למשימה לרוץ ברקע, הגדרת reveal: never מונעת את הצגת המסוף עם פלט המשימה ו runOn: folderOpen אומרת שהמשימה תרוץ כל פעם שפותחים קובץ מתוך התיקייה.

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

מה עושים
סירוב לתת אמון בפרויקטים יכניס אתכם למצב מוגבל בעבודה. במצב מוגבל לא ניתן להריץ משימות מתוך tasks, לא ניתן להכנס למצב Debugging ויש יכולות ותוספים של VS Code שיפעלו בצורה מוגבלת.

כמה דוגמאות לדברים שלא עובדים במצב המוגבל:

1. הצגת תמונות במסוף

2. הצגת היסטוריה במסוף

3. תיקון מהיר לפקודות מסוף

4. שימוש ב Skills בעבודה עם AI

5. שימוש בקבצי Agents.md בעבודה עם AI

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

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

איך אתם רגילים לעבוד? אפשר להגיב במייל או בטלגרם.

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

אחד השימושים למנגנון ה Embedding נקרא RAG או Retrieval-augmented generation. הרעיון הוא שאחרי שיצרנו וקטורי Embedding מכל הפוסטים נוכל ליצור וקטור כזה גם משאלה של משתמש ואז נוסיף את הפוסטים הרלוונטים לפרומפט בצורה אוטומטית.

בואו נראה איך זה עובד בעזרת פרויקט לדוגמה.

התקנה והפעלה
בקישור:

https://github.com/ynonp/embedding-demo

נמצא הקוד של סוכן צ'אט חכם משולב RAG. בשביל להריץ את הפרויקט תצטרכו להרים פוסטגרס עם pgvector רצוי בדוקר עם הפקודה הבאה:

$ docker run --rm -p 5454:5432 -e POSTGRES_PASSWORD=password pgvector/pgvector:pg18-trixie

תצטרכו גם את ollama מותקן על המחשב עם מודל האמבדינג nomic-embed-text-v2-moe:latest. לאחר מכן אפשר ליצור את הנתונים בבסיס הנתונים לדוגמה עם הפקודות:

$ ./bin/rails db:migrate
$ ./bin/rails r script/scrape_data.rb
$ ./bin/rails r script/index_posts.rb

אחרי הפעלת שלושת הפקודות תקבלו בבסיס הנתונים טבלת פוסטים עם 200 פוסטים אחרונים מהבלוג פה, ולכל פוסט יהיה וקטור Embedding שמתאים לו שחושב באמצעות המודל nomic-embed-text-v2-moe:latest.

חישוב מרחק מפרומפט
נפתח את הקובץ app/models/post.rb ושם נמצא את הפונקציה cosine_distance_from_prompt:

  def cosine_distance_from_prompt(prompt, model: EMBED_MODEL)
    return nil unless embedding.present?

    # Calculate embedding for the prompt
    embed = RubyLLM.embed(prompt, provider: :ollama, model:, dimensions: 768)
    prompt_embedding = embed.vectors

    # Calculate cosine distance using PostgreSQL's <=> operator
    conn = self.class.connection.raw_connection
    result = conn.exec_params(
      "SELECT embedding <=> $1::vector AS distance FROM posts WHERE id = $2",
      [prompt_embedding, id]
    )

    result.first['distance'].to_f
  end

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

3.3.5 :004 > Post.find_by(slug: '2026-01-vscode-tasks').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.6270134320979381

3.3.5 :005 > Post.find_by(slug: '2026-01-basic-knowledge').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.7205912733782678

3.3.5 :006 > Post.find_by(slug: '2026-01-learn-worktree-with-ai').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.658548735705814

3.3.5 :008 > Post.find_by(slug: '2026-01-aoc2025day8').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.6936170916427378

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

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

chat = Chat.create(model: "gpt-5-mini")
chat.ask "מהן סכנות האבטחה ב VS Code"

מפעילים את הפרויקט עם ./bin/dev, נכנסים ל localhost:3000/chats, לוחצים על הכפתור לפתיחת שיחה חדשה ומקלידים את הפרומפט ונוכל לראות את התשובה הבסיסית של הסוכן.

הפונקציה הבאה ברשימה עדיין במודל post אחראית על חיפוש פוסטים שרלוונטים לפרומפט מסוים:

  def self.find_relevant_for_prompt(user_prompt, limit: 5)
    # Calculate embedding for the prompt
    embed = RubyLLM.embed(user_prompt, provider: :ollama, model: EMBED_MODEL)
    prompt_embedding = embed.vectors

    # Search database directly using vector search
    conn = connection.raw_connection
    conn.exec_params(
      "SELECT *, embedding <=> $1::vector AS distance FROM posts ORDER BY embedding <=> $1::vector LIMIT $2",
      [prompt_embedding, limit]
    )
  end

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

עקרונות מנחים
שני העקרונות הבאים משותפים לכל פרויקט קוד שעובד עם גיט:

1. מרגע ששלחתי קומיטים למאגר מרוחק קשה להוציא אותם
2. גיט הוא מאגר מידע

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

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

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

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

https://github.com/anomalyco/opencode/commits/dev/

קומיט 0cc206a:

update: border radius on popover card

שינוי הקוד משנה את ערך border-radius בקובץ שנקרא session-review.css. מההודעה אני לומד שהערך הזה משמש להצגת כרטיס popover שזה טוב. ההודעה לא מסבירה למה החליטו לשנות את הערך, האם זה חלק משינוי עיצוב כללי יותר או משהו נקודתי שעלה מהערה של משתמש או ממקום אחר. הקומיט מספר לי מה עשו אבל לא למה עשו.

קומיט c9215e8:

fix(ui): style review tab comment button to match file tab - blue background, white comment icon

הפעם ההודעה מספרת סיפור יותר מלא. יש פה תיקון של ממשק לא עקבי, כפתור comment בטאב ה review נראה קודם שונה מכפתור commment בטאב ה file. גם בלי להכיר את הפרויקט ואת הטאבים השונים אני מבין מאיפה זה בא ולמה החליטו לבצע את השינוי. גם השינויים עצמם ב CSS ובקובץ ה tsx תואמים את ההערה.

בשני הקומיטים השינויים עצמם בקוד מאוד מדויקים, מדובר על 2-3 שורות שהשתנו.

לעומתם קומיט c4d223e קצת יותר מבלבל. הודעת הקומיט היא:

perf(app): faster workspace creation

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

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

נשווה את זה לעץ הקומיטים של קודקס שהוא כבר הרבה יותר מסודר:

https://github.com/openai/codex/commits/main/

קומיט 713ae22 מגיע עם ההודעה הבאה:

Another round of improvements for config error messages (#9746)
In a [recent PR](#9182), I made some
improvements to config error messages so errors didn't leave app server
clients in a dead state. This is a follow-on PR to make these error

מה צריך בשביל להבין
אלכס קונדוב כותב:

> Writing code by hand gave me the pace of thought I needed to understand a problem deeply. After a couple of years at a company, I knew the codebase by heart, every corner of it, every service, and every script.

> I find it difficult to say the same thing now.

ומביא אותנו לשאלה מהכותרת: "מה צריך בשביל להבין"?

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

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

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

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

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

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

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

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

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

1. סוכן קידוד כותב קוד פונקציית צד שרת שמקבלת פרמטר שמורכב משתי מילים user_name. הוא ממשיך לכתוב את קוד צד הלקוח ובטעות שולח את הערך userName. הקוד לא עובד ואני מבקש מסוכן הקידוד לתקן (הכל באותה שיחה). "אני רואה שיש בעיה בשם המשתנה וקוד צד הלקוח שולח אותו בשם אחר ממה שהשרת מצפה לקבל. זה בטח כתוב שם מסיבה טובה אז אני אשלח את הערך גם עם השם הנכון וגם עם השם השגוי". התוצאה - קוד עובד ששולח מידע כפול לשרת.

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

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

name = payload[:name] || payload['name']

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

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

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

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

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