ToCode

📌 הסכנות בהרצת סוכני קידוד על המכונה שלנו סוכנים חכמים ובפרט סוכני קידוד הם התוכנה הראשונה שמותקנת בקנה מידה גדול ושהתנהגותה אינה דטרמניסטית. אף אחד לא יכול לדעת מראש מה סוכן הקידוד יעשה בתגובה להודעה הבאה. מאפיין זה חושף אותנו לסכנות אבטחה משמעותיות בעבודה עם סוכני קידוד. בואו נראה כמה דוגמאות להפתעות כאלה לקראת הוובינר השבוע שיעסוק באבטחת מידע בעידן הסוכנים החכמים. ✏ הרעלת מודלי שפה מקור: 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 נמצא בפיתוח וכל הזמן יש מוצרים חדשים. המטרה שלנו היא לא להכיר כל כלי שיוצא אלא להתמקד במיומנויות ולחפש את הכלים שיאפשרו לנו לכתוב קוד מהר יותר בלי להתפשר על איכות המוצר.

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

The problem with agents is that they make errors. Which is fine, humans also make errors There's a much more important difference between clanker and human. A human is a bottleneck. A human cannot shit out 20,000 lines of code in a few hours. Even if the human creates such booboos at high frequency, there's only so many booboos the human can introduce in a codebase per day. You have removed yourself from the loop, so you don't even know that all the innocent booboos have formed a monster of a codebase. You only feel the pain when it's too late.

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

Spend 40% of your time on code health, or else you’ll wind up spending >60% Basically the agent will always find problems, often shocking ones, e.g. where you discover you have two or even three completely redundant systems (databases, logging, telemetry, whatever) that need consolidating.

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

We are entering a surprising new phase of software development, in which rewriting things is often easier (and smarter) than trying to fix them.

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

📌 מה למדתי על Code Review מהסוכנים של Qt החברים ב Qt שחררו מסמך סקיל שמלמד את קלוד קוד איך לעשות Code Review לקוד Qt. אפשר לקרוא כאן ואני ממליץ: https://github.com/TheQtCompanyRnD/agent-skills/blob/main/skills/qt-cpp-review/SKILL.md הנקודה הראשונה הקריטית שהמסמך מזכיר לנו בעבודה עם סוכני קידוד היא החשיבות של הפרומפט. מי שרוצה לקבל Code Review ברמה גבוהה לא יכול לבקש "תעשה לי Code Review" או אפילו "תעשה לי Code Review ותחפש בעיות ביצועים". הסוכן צריך פרומפט שישים אותו בנקודת התחלה מדויקת לגבי מה אתם מחפשים. דף ההוראות של Qt מתחיל בזיהוי על מה בכלל אנחנו מחפשים לעשות Code Review, כאשר יש הוראות שונות אם רוצים לעשות Code Review על קומיט מסוים או Code Review על המערכת כולה. ממשיכים בבקשה לניתוח סטטי של הקוד ואז מגיע החלק המעניין - הגדרת 6 סוכני Review, כל אחד עם התפקיד שלו. יש סוכנים שאחראיים על חיפוש בעיות נפוצות בקלאס מסוים או אוסף קלאסים, למשל הסוכן הראשון מחפש רק בעיות ב QAbstractItemModel. סוכן שני מחפש בכל המערכת בעיות זכרון, ושימו לב להגדרה שלו שכוללת ממש רשימה של בעיות זכרון נפוצות ב Qt:

Check for:

    Structs/classes with raw pointers where new is visible and no corresponding delete/deleteLater/smart-pointer wrapping exists (Rule of Five violation)
    
    Missing deleteLater() on QNetworkReply in finished handlers
    
    Q_ASSERT wrapping side-effectful expressions (compiled out in release builds — the side effect disappears)
    
    Q_ASSERT as the sole null guard (crashes in release)
    
    Polymorphic QObject subclasses missing Q_DISABLE_COPY_MOVE
    
    Polymorphic classes missing virtual destructor
    
    QTimer/QObject created with new but no parent and no other lifecycle management (scope, smart pointer, explicit delete)
    
    QObject::connect() called with potentially null sender/receiver outside a null guard (runtime warning)
    
    m_recentlyAccessed-style tracking lists that maintain pointers to objects that may be deleted elsewhere (dangling)
    
    Unbounded container growth (append without cap or trim)
    
    Destructor not cleaning up owned children recursively
    
    Abstract interfaces with no implementations beyond one class (YAGNI violation — codebase scope only)
References: references/qt-review-checklist.md § Ownership & Lifecycle, § Polymorphic Classes, § RAII Classes

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

Missing const on methods that don't modify state

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

Expensive operation before cheap early-exit check (wasted allocation)
Missing re-entrancy guard on methods that emit signals which could trigger re-entry

הביקורת שיש לי על רשימה כזאת היא לא בהכרח על הרשימה אלא על האנשים שישתמשו בה. רשימה מדויקת של הערות מעודדת את המודל למצוא את הבעיות ברשימה, גם אם מדובר ב False Positives, ולכן מפתחים שישתמשו ב Code Review מבוסס סוכנים עם רשימה ספציפית צריכים לשים לב: 1. לקרוא בצורה ביקורתית את הנקודות שהמודל מחזיר, להבין מה אמיתי ומה False Positive. 2. לקרוא בצורה ביקורתית את הקוד עצמו כדי למצוא נקודות שלא נמצאות ברשימה או שהמודל פספס. 3. לעדכן את הרשימה מדי פעם ככל שמגלים נקודות שלא עלו ב Code Reviews או נקודות שמעודדות False Positives. מוחקים מה שיצר טעויות ומוסיפים את מה שלא עלה. אני גם לא בטוח ש Skill זה המנגנון הכי טוב לבנות דפי הנחיות כאלה. מצד אחד טוב שאפשר להתקין Skill-ים בקלות וכל הסוכנים אימצו תמיכה במנגנון. מצד שני אולי יהיה יותר פשוט ונכון להשתמש בקובץ Prompt ייעודי שיושב בתוך הפרויקט ומפתחים יודעים לקרוא אותו ולעדכן אותו.