ToCode

📌 אז עדיין צריך הודעות קומיט? ב 2026 סוכני קידוד יודעים לכתוב הודעות קומיט טובות יותר מאיתנו גם בדיעבד. ניסיתי את זה - הפרומפט:

explain the commit 
1. what changed?
2. why?
3. what's still left to do for this issue?

עם הקומיט שעשיתי כאן: https://github.com/ynonp/langlets-rails/commit/c07821619789ce2c814f9056088f0b083c7e92c7 נתן לי הסבר הרבה יותר טוב ומדויק מזה שאני כתבתי בהודעת הקומיט. הוא גם הזכיר לי שהקומיט הזה בכלל כלל 4 שינויים נפרדים, כשהודעת הקומיט מדברת על שינוי אחד. מי שיקרא את הקוד עם ההסבר של ה AI יקבל הסבר הרבה יותר טוב למה קרה שם. ועכשיו השאלה בכותרת היא התלבטות אמיתית. למה לא לתת ל AI לכתוב את הודעת הקומיט הזאת מראש ולרוץ יותר מהר? מה הטעם לכתוב הודעות קומיט לא מדויקות בעצמי? במקרה בדוגמה הודעת הקומיט שלי לא היתה מדויקת כי נתתי ל AI לכתוב כמה פיצ'רים במקביל ודחפתי הכל בלי לקרוא לעומק. אם זאת שיטת העבודה ברור שחבל על הזמן. אבל למרות ש AI מתאר יופי מה קרה בקומיט, הוא לא יודע את הקונטקסט האמיתי, את הסיבה האמיתית בגללה דחפתי דווקא את הקוד הזה. הוא לא יודע איזה אופציות אחרות בדקתי, מה חשבתי שעלול להשתבש, מה השתבש או לא השתבש בסוף, בקיצור את כל המסביב של הפיצ'ר. ב 2026 הודעת קומיט לא צריכה לספר מה קרה. חבל על הביטים. אבל היא כן צריכה לספר את סיפור הרקע. הודעת קומיט טובה היא כמו מכונת זמן שלוקחת אותנו ישר לאותו רגע בזמן בו החלטנו לדחוף דווקא את הקוד הזה. היא Context Dump של מי שישב ליד ההגה והחליט שזה מוכן. הרבה פעמים כדאי לשלב כוחות. סוכן הקידוד יכתוב הודעות קומיט אוטומטיות בענף משלו. ברגע שזה מוכן אני עובר עם ריבייס, בוחר איזה קומיטים היו בעלי משמעות בתהליך הפיתוח, כותב להם הודעות קומיט משמעותיות וזורק את כל היתר. לא "למה תיקנתי את זה" או "מה היה שבור", אלא "למה דווקא את זה", "מה היו האפשרויות האחרות" ואפילו מה בדיוק הלקוח ראה ואמר כשהוא דיווח על הבאג.

כשאנחנו עובדים עם סוכן קידוד אנחנו מכניסים שותף לא צפוי למחשב. רוב הזמן שותף זה יעזור לנו לכתוב קוד מהר יותר וטוב יותר אבל השגחה ובידוד הם הכרחיים כדי שדברים לא יישברו. הדברים המרכזיים שעלינו לשים לב אליהם בעבודה השוטפת: 1. קראתי ואני מבין כל שורה שהסוכן כתב, היא מתאימה לפרויקט שלי ולא יוצרת בעיות אבטחה חדשות. 2. הסוכן רץ בסביבה מבודדת - גם אם הוא יחליט לשבור דברים אין לו יכולת לעשות נזק אמיתי. בוובינר ביום חמישי השבוע נדבר בהרחבה על כל המקרים מכאן ודוגמאות נוספות. מוזמנים להצטרף אלינו בקישור: https://www.tocode.co.il/talking_ai

📌 הסכנות בהרצת סוכני קידוד על המכונה שלנו סוכנים חכמים ובפרט סוכני קידוד הם התוכנה הראשונה שמותקנת בקנה מידה גדול ושהתנהגותה אינה דטרמניסטית. אף אחד לא יכול לדעת מראש מה סוכן הקידוד יעשה בתגובה להודעה הבאה. מאפיין זה חושף אותנו לסכנות אבטחה משמעותיות בעבודה עם סוכני קידוד. בואו נראה כמה דוגמאות להפתעות כאלה לקראת הוובינר השבוע שיעסוק באבטחת מידע בעידן הסוכנים החכמים. ✏ הרעלת מודלי שפה מקור: https://ron.stoner.com/how-i-won-a-championship-that-doesnt-exist/ בסוף ינואר 2025 רון סטונר העלה אתר עם תמונה של גביע בו כתוב שהוא זכה באליפות הנימיץ השנתית שהתקיימה במינכן. הוא גם עדכן את הדף של נימיץ בויקיפדיה עם קישור לדף הנצחון שלו. זה הספיק בשביל לגרום ל ChatGPT למצוא את הקישור ולספר שהוא היה הזוכה בתגובה לשאלה בצ'אט. התרגיל של סטונר הוא שטחי. סטונר גרם למודל להיתקל בשם שלו במהלך חיפוש ברשת - אבל מבהיר לנו עד כמה קל לרמות סוכנים חכמים במיוחד כאלה שיוצאים לחפש ברשת. אותו מנגנון יכול להיות מנוצל לרעה על ידי גורמים זדוניים שיקימו אתרים שיפרסמו חבילות npm שהן בעצם רוגלות, אותן הסוכן יתקין בלי להבין שמדובר ברוגלה. ✏ באג בסוכן יוצר חיוב מוגזם סוכני קידוד הם כלי פיתוח ייחודי בכך שהם מחוברים לכרטיס אשראי, כך שככל שהסוכן משתמש ביותר טוקנים אנחנו צריכים לשלם יותר. שני באגים מעניינים מבהירים לנו שהחיבור הזה אף פעם לא עובד חלק. במקרה אחד אנטרופיק החליטו שהם לא רוצים לאפשר לעוזר אישי בשם Hermes להשתמש בתוכנית המנויים שלהם אז הם ניסו לנתב בקשות מ Hermes לחיוב גבוה יותר. התוצאה היתה שמספיק לכתוב את המילה HERMES.md בהודעת קומיט וקלוד קוד יחייב אותך בתשלום גבוה יותר על הפיתוח: https://github.com/anthropics/claude-code/issues/53262 במקרה אחר אופןקוד (עוד סוכן קידוד) התחבר לתוכנית המנויים של גיטהאב קופיילוט, אבל בגלל באג במצבים מסוימים השתמש ביותר בקשות בתשלום וכך סיים למשתמשים את המנוי מוקדם: https://github.com/anomalyco/opencode/issues/16937 ✏ טעות של המודל מוחקת נתוני פרודקשן מקור: https://x.com/lifeof_jer/status/2048103471019434248?s=46 ג'ר קריין, המייסד של PocketOS חיבור את קלוד אופוס לסביבת הפיתוח שלו ב Cursor. הוא שכח שבאיזשהו קובץ טקסט בתיקיית הפרויקט היה כתוב טוקן הגישה לסביבת הפרודקשן - כדי להריץ תהליך תחזוקה שגרתי. קלוד אופוס נתקל בבעיה, חשב שצריך ליצור מחדש את הסביבה, מצא את הטוקן של סביבת הפרודקשן והשתמש בו כדי ליצור מחדש את סביבת הפרודקשן - וכך מחק את כל נתוני המשתמשים. בעבודה עם סוכני קידוד אנחנו נוטים לחשוב שיש לנו עוזר אישי מיומן על המחשב שתמיד יעשה מה שטוב לפרויקט. זה נכון ב 99% מהמקרים. לשאר ה-1% עלינו לוודא מנגנוני הגנה טובים בסביבה שימנעו מאנשים או סוכנים פזיזים לעשות נזקים. ✏ הזרקת פרומפט מובילה להשתלטות על מכונות מקור: https://neciudan.dev/cline-ci-got-compromised-here-is-how הצוות של cline (עוד סוכן קידוד) רצה למיין את הבקשות שהם מקבלים ממשתמשים באמצעות AI. אז הם יצרו Github Action שמפעיל את קלוד כדי לשים כל פניה במקום המתאים. הפרומפט לקלוד הכיל את כותרת ה Issue שנפתח והסוכן הופעל עם הרשאה להרצת כלים:

allowed_non_write_users: "*"
claude_args: >-
  --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch"
prompt: |
  **Issue:** #${{ github.event.issue.number }}
  **Title:** ${{ github.event.issue.title }}

לא לקח הרבה זמן עד שפורצים ראו את זה ויצרו Issue עם שם שגרם לסוכן להתקין חבילת npm זדונית שהם יצרו וכך השתלטו על מכונת המיון, וממנה על כל הפרויקט. סיפור דומה קרה עם Coderabbit, סביבה ל Code Review ואפשר לקרוא עליו כאן: https://kudelskisecurity.com/research/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories ✏ קידוד מהיר מוביל ליותר באגים נקודה אחרונה ברשימה היא תרבות העבודה של עידן ה AI - לכתוב המון קוד, לדחוף מהר לפרודקשן אחרי בדיקה קצרה, לסמוך על הסוכן שכותב את הקוד הנכון. כנראה שמיזוג מהיר של פיצ'רים הוא אחד הגורמים לבאג הזה באופןקוד: https://github.com/anomalyco/opencode/security/advisories/GHSA-vxw4-wv6m-9hhh שם אופןקוד פתחו שרת HTTP שלא דורש הזדהות ומאפשר הרצת פקודות על המחשב של המפתח. התוצאה היא שאתרים זדוניים יכולים להריץ קוד וכך להשתיל רוגלות ווירוסים על מחשבים של מפתחים שמריצים אופןקוד וגולשים לאותם אתרים. ✏ סיכום

📌 טוקנים מיותרים ביקשתי מקלוד אופוס לכתוב דוגמה לאפליקציית Hello World בפלאסק. הקוד של main שהוא כתב היה:

from app import create_app

app = create_app()


if __name__ == "__main__":
    app.run(host="127.0.0.1", port=5100, debug=True)

פורט 5100 שם כי אני ביקשתי. את debug הוא כתב על דעת עצמו ו host הוא סתם רעש. פלאסק משתמש ב 127.0.0.1 בתור ערך ברירת מחדל. מרגע שערך זה נכתב הוא מגדיל את הקובץ, תופס טוקנים בכל בקשה עתידית ועלול לגרום למפתחי פייתון לתהות למה זה שם. בעבודה אמיתית עם סוכני קידוד אני נתקל בהמון טוקנים מיותרים ואני מודה שיש התלבטות אמיתית מה עושים איתם. מצד אחד לנקות קוד של מאות שורות יכול להיות מאתגר, מצד שני להשאיר טוקנים מיותרים שגורמים לקוד להיות פחות ברור רק יסבך אותנו בעתיד. הפתרון שלי היום הוא לוודא קיום בדיקות אוטומטיות לכל פיצ'ר ואז לנקות את הפיצ'ר לפי הגדרת סוכן ניקוי נפרד. אם סוכן הניקוי מפספס מבנה מסוים אני מוסיף אותו לקובץ הוראות סוכן הניקוי. אחרי הניקוי אני יכול להיעזר בבדיקות האוטומטיות כדי לוודא שסוכן הניקוי לא שבר כלום, וכן כל התהליך הזה קורה אוטונומית. המטרה היא לקבל מ AI קוד עובד בו אני מבין כל טוקן. נ.ב. גם המודל וגם ה Harness אחראים לטוקנים המיותרים. לפעמים יותר קל להעתיק את הפרומפט ל pi או לקופיילוט ולראות מה הם יעשו במקום לנקות קוד מנופח של קלוד קוד. המשחק הוא לא AI אלא פייתון. לדעת שלא צריך לציין host=127.0.0.1 בקריאה ל run כי זו ברירת המחדל.

📌 הוק לקלוד עבור קומיט אחרי כל שינוי אתמול בוובינר הראיתי איך להשתמש בגיט בעבודה עם סוכני קידוד ואחת ההמלצות החשובות היתה לא לפחד מקומיטים. כל פעם שיש שינוי קוד עושים קומיט ואחרי זה אם מתחרטים אפשר להשתמש ב git reset --hard כדי לחזור אחורה. חלק מהמשתתפים העירו שאפשר לעשות את הקומיטים האלה אוטומטית ואז לא שוכחים. הלכתי לחקור את הרעיון ושמחתי לראות שזה עבד די בקלות. אם אתם בקלוד קוד אפשר ליצור קובץ .claude/settings.json בתיקיית הפרויקט עם התוכן הבא:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/auto-commit.sh",
            "async": true,
            "timeout": 30
          }
        ]
      }
    ]
  }
}

ואז הסקריפט auto-commit.sh ירוץ כל פעם שקלוד מסיים לכתוב תשובה. את הסקריפט עצמו נתתי לקלוד לכתוב והוא נראה כך:

#!/usr/bin/env bash
# Stop hook: auto-commit Claude's changes using the last user prompt
# as the commit message.

set -uo pipefail

INPUT=$(cat)
read -r STOP_HOOK_ACTIVE TRANSCRIPT_PATH PROJECT_DIR < <(
  printf '%s' "$INPUT" | jq -r '[.stop_hook_active // false, .transcript_path // "", .cwd // ""] | @tsv'
)

[ "$STOP_HOOK_ACTIVE" = "true" ] && exit 0

[ -n "$PROJECT_DIR" ] && cd "$PROJECT_DIR" 2>/dev/null || exit 0
git rev-parse --git-dir >/dev/null 2>&1 || exit 0
git add -A 2>/dev/null || exit 0
git diff --cached --quiet && exit 0

# Last user text message from this turn's transcript.
# Skips tool_result entries and slash-commands (which start with '<').
USER_PROMPT=""
if [ -f "$TRANSCRIPT_PATH" ]; then
  USER_PROMPT=$(jq -r '
    select(.type == "user") | .message.content
    | if type == "string" then .
      elif type == "array" then (map(select(.type == "text")) | .[0].text // "")
      else "" end
    | select(. != "" and (startswith("<") | not))
  ' "$TRANSCRIPT_PATH" 2>/dev/null | tail -1)
fi

# Use the user prompt as the commit message; first line as subject (capped at
# 72 chars), remaining lines as the body.
if [ -n "$USER_PROMPT" ]; then
  SUBJECT=$(printf '%s' "$USER_PROMPT" | head -1 | cut -c1-72)
  BODY=$(printf '%s' "$USER_PROMPT" | tail -n +2)
else
  SUBJECT="checkpoint: $(date +%H:%M)"
  BODY=""
fi

if [ -n "$BODY" ]; then
  git commit --no-verify -m "$SUBJECT" -m "$BODY" >/dev/null 2>&1 || true
else
  git commit --no-verify -m "$SUBJECT" >/dev/null 2>&1 || true
fi
exit 0

קלוד מפעיל את הסקריפט עם JSON של מידע על השיחה האחרונה. מה שמעניין אותנו מתוך ה JSON הזה הוא ההודעה של המשתמש, כי אני אוהב שהפרומפט שלי הופך להודעת הקומיט (אם צריך הודעה יותר מתוחכמת אפשר להשתמש ב git commit --amend כדי לתקן). ליתר בטחון קלוד הוסיף --no-verify לפקודת הקומיט כדי לדלג על קומיט הוקס. אני חושב שזה הוגן וממילא לא משתמש בקומיט הוקס. יש גם בדיקה בהתחלה שמדלגת על כל הסקריפט אם אנחנו לא בתוך ריפו. סך הכל רעיון מעניין. שימו לב שאפשר להפעיל את ה hook או מקומית לפרויקט הנוכחי או באופן גלובאלי אם רושמים אותו ב settings של קלוד בתיקיית הבית. אני מתכנן להתחיל עם פרויקט אחד ולראות איך זה יעבוד לאורך זמן.

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

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

const message = await streamAssistantResponse(currentContext, config, signal, emit, streamFn);

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

const toolCalls = message.content.filter((c) => c.type === "toolCall");

מודלי שפה רבים יודעים לעבוד עם כלים. עבודה עם כלים אומרת שהמודל מחזיר לסוכן אוביקט שאומר איזה כלי צריך להפעיל. כלי הוא פונקציה שסוכן הקידוד מגדיר והמודל צריך את התוצאה שלה כדי לבצע משימה. כשתשובת המודל כוללת בקשות להפעלת כלים הסוכן תופס את הבקשות ומפעיל את הכלים ברשימה. הסוכן יוסיף את תוצאות הפעלת הכלים לקונטקסט ובאיטרציה הבאה של הלולאה המודל כבר יקבל את ההודעות יחד עם תוצאות הפעלת הכלים כדי שאפשר יהיה להתקדם. אחרי ששלחנו הודעה למודל, קיבלנו תשובה, הפעלנו כלים והדבקנו את התשובות שלהם על הקונטקסט אנחנו מגיעים לנקודה שנקראת turn_end. פאי יאפשר לנו לכתוב תוספים שיתפסו את הנקודה הזאת ויעצרו את הלולאה כאן, ואם אין בקשה מיוחדת לעצירה אנחנו ממשיכים לאיטרציה הבאה. לולאת הפעלת הכלים תיעצר כשהמודל לא יבקש להפעיל שוב כלים, כשהסוכן יחליט שהפעלנו מספיק כלים וצריך לעצור או כשכל הכלים מחזירים ערך עצירה. לולאת הסוכן היא הלב של סוכני קידוד והיא מטפלת בכל הודעה שאנחנו שולחים. בזכות פאי ראינו איך הלולאה הזו בנויה ומה היא מאפשרת. הלולאה שקראנו נקראת לולאת React שזה קיצור של Reason ו Act, וזה אומר שהקוד שולח הודעה למודל שפה, נותן לו הזדמנות להריץ כלים, שולח את התוצאה של הכלים שוב למודל וממשיך בלולאה עד שאין יותר קלים להפעיל. ✏ שאלות למיטיבי לכת קראו את הקוד ונסו לחשוב: 1. באיזה מצבים נרצה לעצור את לולאת הסוכן כשהמודל רוצה להמשיך ולהפעיל עוד כלים? 2. איזה כלים עשויים לגרום לסיום הלולאה? 3. האם לולאה זו מתאימה לכל מצבי העבודה שאנחנו מכירים עם סוכנים חכמים? מה קורה במצב תכנון? במצב טייס אוטומטי? במצב Ask?

📌 קריאה מודרכת בלולאת הסוכן של פאי פאי הוא סוכן קידוד מינימליסטי, מה שאומר שהוא כולל מעט מאוד פיצ'רים ובשביל לקבל ממנו תוצאות טובות עלינו לבנות לבד הרחבות. עוד זה אומר שאפשר להכנס די בקלות לקוד שלו ולהבין מה קורה שם, שזה נפלא למי שרוצה להבין איך דברים עובדים. הריפו של פאי נמצא כאן: https://github.com/badlogic/pi-mono/ ובשביל להבין איך עובדת לולאת סוכן נסתכל על הקובץ: https://github.com/badlogic/pi-mono/blob/main/packages/agent/src/agent-loop.ts ונחפש את הפונקציה runLoop. זה המימוש כמו שהוא - סופר קריא ומתועד:

async function runLoop(
 currentContext: AgentContext,
 newMessages: AgentMessage[],
 config: AgentLoopConfig,
 signal: AbortSignal | undefined,
 emit: AgentEventSink,
 streamFn?: StreamFn,
): Promise<void> {
 let firstTurn = true;
 // Check for steering messages at start (user may have typed while waiting)
 let pendingMessages: AgentMessage[] = (await config.getSteeringMessages?.()) || [];

 // Outer loop: continues when queued follow-up messages arrive after agent would stop
 while (true) {
  let hasMoreToolCalls = true;

  // Inner loop: process tool calls and steering messages
  while (hasMoreToolCalls || pendingMessages.length > 0) {
   if (!firstTurn) {
    await emit({ type: "turn_start" });
   } else {
    firstTurn = false;
   }

   // Process pending messages (inject before next assistant response)
   if (pendingMessages.length > 0) {
    for (const message of pendingMessages) {
     await emit({ type: "message_start", message });
     await emit({ type: "message_end", message });
     currentContext.messages.push(message);
     newMessages.push(message);
    }
    pendingMessages = [];
   }

   // Stream assistant response
   const message = await streamAssistantResponse(currentContext, config, signal, emit, streamFn);
   newMessages.push(message);

   if (message.stopReason === "error" || message.stopReason === "aborted") {
    await emit({ type: "turn_end", message, toolResults: [] });
    await emit({ type: "agent_end", messages: newMessages });
    return;
   }

   // Check for tool calls
   const toolCalls = message.content.filter((c) => c.type === "toolCall");

   const toolResults: ToolResultMessage[] = [];
   hasMoreToolCalls = false;
   if (toolCalls.length > 0) {
    const executedToolBatch = await executeToolCalls(currentContext, message, config, signal, emit);
    toolResults.push(...executedToolBatch.messages);
    hasMoreToolCalls = !executedToolBatch.terminate;

    for (const result of toolResults) {
     currentContext.messages.push(result);
     newMessages.push(result);
    }
   }

   await emit({ type: "turn_end", message, toolResults });

   if (
    await config.shouldStopAfterTurn?.({
     message,
     toolResults,
     context: currentContext,
     newMessages,
    })
   ) {
    await emit({ type: "agent_end", messages: newMessages });
    return;
   }

   pendingMessages = (await config.getSteeringMessages?.()) || [];
  }

  // Agent would stop here. Check for follow-up messages.
  const followUpMessages = (await config.getFollowUpMessages?.()) || [];
  if (followUpMessages.length > 0) {
   // Set as pending so inner loop processes them
   pendingMessages = followUpMessages;
   continue;
  }

  // No more messages, exit
  break;
 }

 await emit({ type: "agent_end", messages: newMessages });
}

אלה החלקים המרכזיים: 1. הסוכן מאפשר למשתמשים להקליד הודעות בזמן שהמודל משלים טקסט. אלה ה pendingMessages ואנחנו מקבלים אותן מהפונקציה getSteeringMessages כבר בתחילת הפונקציה. 2. לולאת הסוכן מורכבת מלולאה כפולה, הלולאה החיצונית מטפלת בהודעות נוספות שאנחנו כותבים אחרי שהסוכן מתחיל לעבוד. הלולאה הפנימית אחראית על מענה לפרומפט. 3. הלולאה הפנימית מעניינת - למה צריך לענות לפרומפט בלולאה? למה לא לשלוח את ההודעה למודל, לקבל השלמה וזהו? התשובה היא מנגנון בסיסי של סוכני קידוד שנקרא הפעלת כלים. 4. נשים לב שכמעט בכל שלב בלולאה, וזה נכון באופן כללי לקוד של פאי, יש לנו קריאות ל emit עם מזהה אירוע. אלה "נקודות התחברות". בעבודה עם פאי נוכל לכתוב תוספים שיופעלו בכל נקודת התחברות שנרצה.

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

ונ.ב. סופר קריטי לפוסט הזה ששכחתי בזמן הכתיבה - קריאה ביקורתית לא לקבל קוד ש AI כותב בלי שאני מבין את זה כאילו זה קוד שאני כתבתי

📌 חמש מיומנויות קריטיות למפתחים בעידן ה AI כן המפתחים המובילים בתעשייה כבר משתמשים ב AI כדי לכתוב מעל 90% מהקוד שנכנס למוצר שלהם. שמעתי גם על צוותים שמתעקשים לא לאפשר למפתחים לכתוב קוד ידנית במטרה לזהות Best Practices בעבודה עם AI, כלומר במקום לכתוב לבד תקרא מסודר את הפלט של ה AI, תבין למה הוא לא יצר את הקוד שרצית ותתקן את הפרומפט, קוד במקום אחר, קבצי תיעוד או מה שלא יהיה כדי לקבל את הקוד שצריך. ולמרות שאף אחד לא יודע איך יראה המקצוע עוד שנתיים, יש כמה מיומנויות שבטוח נצטרך וכדאי לפתח כבר מאתמול: הראשונה היא המיומנות הטכנית, היכרות עם הכלים. סוכני קידוד יכולים לעבוד מהענן, משורת הפקודה, מאפליקציית Desktop או מתוך VS Code. צריך לדעת איך לפנות אליהם, מה עושה כל כפתור ומה הפעולות המרכזיות שאפשר לעשות איתם בכל סביבה. המפתחים של העתיד ירגישו בנוח לדבר עם AI בכל כלי בו הוא נמצא. מיומנות שניה היא ניהול קונטקסט (של ה AI) וכתיבת פרומפטים. ההבנה שכל דבר הוא פרומפט ושאם אני לא מקבל תשובה מספיק טובה מהמודל אני יכול לנסח פרומפט אחר ולשנות את הקלט כדי לשפר את התוצאות. סוכן קידוד הוא כמו טייס אוטומטי לקוד. כתיבת קונטקסט ופרומפט זה הגדרת היעד לטייס האוטומטי. מיומנות שלישית היא הגדרת חיבורים ותהליכי עבודה: איך הסוכן יודע שהקוד שהוא כתב נכון או עובד? איך הקוד שקיים אצלנו במערכת משפיע על הקוד החדש שנוצר? ואיך אנחנו שומרים על איכות כשקוד נכתב יותר מהר ממה שאנחנו מצליחים להבין? בשביל לשפר את קצב הפיתוח נרצה להריץ סוכנים במקביל וסוכנים בענן, נרצה לבנות מערכות שמפתחות את עצמן ומזהות בעיות. בשביל לשמור על איכות הקוד נרצה לייצר צווארי בקבוק ומנגנונים שיאפשרו למפתחים לכוון את הסוכנים למימושים שאנחנו יודעים שהם נכונים. זאת כבר חשיבה מערכתית על תהליך הפיתוח וניתוח ה Outputs של התהליך כדי לשפר אותו. מלבד שלושת המיומנויות האלה שהן ייחודיות ל AI אני מזהה עוד שתי מיומנויות שתמיד היו חשובות ומקבלות חיזוק משמעותי בעידן החדש: הראשונה היא המיומנות ההנדסית, להבין מה אני בונה, איך החלקים במערכת עובדים, לראות מקרי קצה, שגיאות, להבין איך קוד גורם למערכות לעבוד. היכולת לקרוא ולהבין מהר. מיומנות שניה היא ניהול קונטקסט, אבל הפעם שלנו, מה שנקרא Context Switching. מפתחים כבר היום עובדים במקביל עם מספר סוכני קידוד והמספרים האלה רק יגדלו. אנחנו קופצים ממשימה למשימה, מסוכן לסוכן, מפיצ'ר לפיצ'ר. אי אפשר לדמיין יותר מפתח שיושב שבועיים בחדר סגור לתכנן פיצ'ר ועוד שלושה חודשים לכתוב את הקוד. העתיד מורכב ממקביליות ומביצוע המון משימות יחד. תחום GenAI נמצא בפיתוח וכל הזמן יש מוצרים חדשים. המטרה שלנו היא לא להכיר כל כלי שיוצא אלא להתמקד במיומנויות ולחפש את הכלים שיאפשרו לנו לכתוב קוד מהר יותר בלי להתפשר על איכות המוצר.