עריכה וכתיבת קוד — Editing and Writing

כלי Edit — דיוק כירורגי

הכלי Edit הוא הכלי המרכזי של Claude Code לשינוי קבצים קיימים. חשבו עליו ככירורג — הוא משנה בדיוק מה שצריך ולא נוגע בשום דבר אחר. שום רווח לא זז, שום הזחה לא משתנה, שום encoding לא נשבר. רק המילים שביקשתם להחליף — מוחלפות.

איך זה עובד מאחורי הקלעים? Edit מקבל שני פרמטרים:

• old_string — הטקסט המדויק שצריך להחליף. חייב להיות ייחודי בקובץ
• new_string — הטקסט שיחליף אותו

זהו. פשוט ואלגנטי. Claude מוצא את הטקסט המדויק בקובץ, מחליף אותו, ומשאיר את כל השאר בדיוק כפי שהיה. הפורמטינג, ההזחה (Indentation), הרווחים, ה-Encoding — הכול נשמר. זו הסיבה שזה הכלי המועדף תמיד לשינויים בקבצים קיימים.

# הקוד הנוכחי (עם הבאג):
def calculate_price(base_price):
    vat = base_price * 0.17  # שגוי — צריך 0.18 מ-2025
    return base_price + vat

old_string: "vat = base_price * 0.17  # שגוי — צריך 0.18 מ-2025"
new_string: "vat = base_price * 0.18  # מע\"מ 18% — מעודכן 2025"

הכלל הקריטי: ייחודיות (Uniqueness)

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

הפתרון: תנו יותר הקשר. במקום להחליף רק return True (שיכול להופיע 5 פעמים בקובץ), תנו שורות נוספות סביב:

# במקום זה (לא ייחודי):
old_string: "return True"

# תנו הקשר (ייחודי):
old_string: "def validate_email(email):\n    if '@' in email:\n        return True"

replace_all — שינוי כל המופעים

לפעמים אתם דווקא כן רוצים לשנות את כל המופעים. שינוי שם משתנה, שינוי שם CSS class, החלפת URL ישן בחדש — כאן נכנס הפרמטר replace_all: true.

Edit:
  old_string: "userName"
  new_string: "currentUser"
  replace_all: true

Edit להוספת קוד חדש

Edit לא רק מחליף טקסט — הוא גם מוסיף טקסט. כשאתם רוצים להוסיף פונקציה חדשה, import חדש, או שורת קוד חדשה — Edit עדיין הכלי הנכון. ה-old_string מגדיר את המיקום (הטקסט שאחריו או לפניו צריך להוסיף), וה-new_string כולל גם את הטקסט הישן וגם את החדש.

# הקוד הנוכחי:
import os
import sys

# אתם אומרים: "הוסף import json"
# Claude עושה Edit:
old_string: "import os\nimport sys"
new_string: "import os\nimport sys\nimport json"

# אתם אומרים: "הוסף פונקציה validate_phone אחרי validate_email"
# Claude מוצא את סוף הפונקציה הקיימת ומוסיף את החדשה:
old_string: "def validate_email(email):\n    return '@' in email"
new_string: "def validate_email(email):\n    return '@' in email\n\n\ndef validate_phone(phone):\n    return len(phone) == 10 and phone.isdigit()"

Edit לתיקון Indentation ופורמטינג

אחד השימושים הנפוצים ב-Edit שלא חושבים עליו: תיקון הזחה שבורה. אם קוד מעובד ב-IDE אחד ונשבר ב-IDE אחר, או אם מישהו ערבב tabs ו-spaces — Claude יכול לתקן את זה בדיוק:

"תקן את ההזחה בפונקציה calculate_total — היא משתמשת ב-tabs במקום spaces"

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

אישור עריכות — Shift+Tab

כשClaude מציג לכם Edit ומבקש אישור, אתם יכולים ללחוץ Shift+Tab כדי לאשר את העריכה מהר. זה קיצור הדרך ברירת המחדל עבור acceptEdits ב-Claude Code, ואפשר לשנות אותו דרך קובץ ~/.claude/keybindings.json. אם אתם אוהבים לעבוד מהר ולאשר הרבה עריכות ברצף — Shift+Tab חוסך לחיצות.

כלי Write — יצירת קבצים חדשים

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

מתי משתמשים ב-Write?

• קובץ חדש: יצירת קומפוננטה, סקריפט, קובץ קונפיגורציה, דוח, תבנית — כל דבר שלא קיים עדיין
• שכתוב מלא: כשצריך לשנות 80% ומעלה מהקובץ, שכתוב מלא יעיל יותר מ-10 פעולות Edit נפרדות

מנגנון בטיחות מובנה

Write כולל מנגנון בטיחות חשוב: Claude חייב לקרוא (Read) קובץ קיים לפני שהוא מחליף אותו עם Write. זה מונע מצב שבו Claude מחליף קובץ שהוא לא מכיר ומאבד תוכן חשוב. אם Claude ינסה לעשות Write על קובץ קיים בלי שקרא אותו קודם — הפעולה תיכשל.

כשאתם מבקשים ליצור קובץ חדש, Write מציג את כל התוכן של הקובץ לפני שהוא כותב — אתם רואים בדיוק מה ייכתב ויכולים לאשר או לדחות.

Write לסוגי קבצים שונים

Write עובד עם כל סוג קובץ טקסטואלי. הנה כמה שימושים נפוצים:

Edit מול Write — מטריצת ההחלטה

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

למה Edit תמיד עדיף לקבצים קיימים?

יש כמה סיבות עמוקות למה Edit הוא הכלי המועדף כשהקובץ קיים:

• שקיפות: ב-Edit, אתם רואים בדיוק מה השתנה — old → new. ב-Write, אתם צריכים להשוות את כל הקובץ החדש לישן כדי להבין מה שונה.
• בטיחות: Edit לא יכול למחוק קוד שלא ביקשתם למחוק. Write מחליף הכול — אם Claude שכח לכלול פונקציה שהייתה בקובץ, היא נעלמה.
• היסטוריית Git: Edit יוצר Diff נקי ב-git שמראה בדיוק מה השתנה. Write מסמן את כל הקובץ כשינוי, גם שורות שלא השתנו.
• Code Review: ל-Reviewer קל הרבה יותר לסקור שינוי של 5 שורות (Edit) מאשר שכתוב מלא של 200 שורות (Write).

עריכה רב-קובצית — שינויים מתואמים

אחד היתרונות הכי חזקים של Claude Code הוא היכולת לערוך מספר קבצים ב-turn אחד. אתם מתארים את השינוי שאתם רוצים, ו-Claude מבין אילו קבצים צריכים להשתנות ומעדכן את כולם בצורה מתואמת.

שינויים גדולים: עבדו בשלבים

לשינויים רב-קובציים גדולים (10+ קבצים), כדאי לעבוד בשלבים במקום לבקש הכול ב-turn אחד:

דפוסים נפוצים של עריכה רב-קובצית

הנה התרחישים הנפוצים ביותר שבהם תבצעו שינויים בכמה קבצים:

Codebase קיים מול פרויקט חדש (Greenfield)

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

Codebase קיים — גישה שמרנית

כשנכנסים לקוד שמישהו אחר כתב (Legacy Code, קוד של קולגה, או פרויקט Open Source), הגישה היא להבין קודם, לשנות אחר כך:

Greenfield — פרויקט חדש מאפס

כשבונים פרויקט חדש, הגישה יצירתית יותר:

# Project: E-Commerce API
## Stack
- TypeScript (strict mode)
- Express.js
- PostgreSQL with Prisma ORM
- Jest for testing

## Conventions
- Use Repository Pattern for data access
- All functions must have JSDoc comments
- Error handling: always return proper HTTP status codes
- File naming: kebab-case (user-service.ts)
- Keep functions under 30 lines

## Testing
- Every new endpoint needs at least 3 tests: happy path, validation error, not found
- Use fixtures for test data, not inline objects

הבנה וסקירת Diffs

Diff (קיצור של Difference) הוא הצגת ההבדלים בין שתי גרסאות של קובץ. כל פעם ש-Claude מבצע Edit, אתם רואים Diff שמראה בדיוק מה הוסר ומה נוסף. זה אחד הכלים הכי חשובים שלכם — לא לאשר שינוי בלי לקרוא את ה-Diff.

איך קוראים Diff

- const PORT = 3000;    ← שורה שהוסרה (ישנה)
+ const PORT = 8080;    ← שורה שנוספה (חדשה)
  const HOST = '0.0.0.0';  ← שורה ללא שינוי (הקשר)

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

Diffs מרובי שינויים

כשClaude מבצע כמה שינויים בקובץ, כל Edit מראה Diff נפרד. אבל לפעמים תרצו לראות את כל השינויים יחד — את התמונה הגדולה. כאן נכנס git diff:

ביקשו סיכום של שינויים גדולים

אם Claude ביצע הרבה שינויים ואתם רוצים סיכום מהיר במקום לקרוא כל שורה:

"סכם מה שינית ולמה"

Claude ייתן סקירה ברמה גבוהה: אילו קבצים השתנו, מה השתנה בכל אחד, ולמה. זה מושלם לשינויים גדולים שבהם ה-Diff המלא ארוך מדי לקריאה.

מה לחפש כשקוראים Diff

כשאתם מסתכלים על Diff שClaude ביצע, חפשו את הדברים הבאים:

• האם רק מה שביקשתם השתנה? אם ביקשתם לשנות פורט ו-Claude גם שינה את שם המשתנה — זה יותר ממה שרציתם. בקשו לחזור.
• האם יש שינויים "שקופים"? לפעמים Claude מוסיף שורה ריקה, משנה הזחה, או מוסיף comment שלא ביקשתם. בדקו.
• האם ההיגיון נשמר? אם שינוי של שורה אחת שבר את הלוגיקה של הבלוק — ה-Diff יראה לכם את זה.
• האם אין מידע רגיש? לפעמים Claude כותב API Key, password, או secret בקוד. ה-Diff הוא ההזדמנות לתפוס את זה לפני commit.

Diff בפורמט Git — הפורמט שתראו הכי הרבה

כשאתם מריצים git diff או כשClaude מראה לכם את השינויים, הפורמט נראה כך:

diff --git a/config.json b/config.json
--- a/config.json    ← הגרסה הישנה
+++ b/config.json    ← הגרסה החדשה
@@ -3,7 +3,7 @@   ← מיקום השינוי (שורה 3, 7 שורות)
   "name": "my-app",
-  "port": 3000,     ← הוסר
+  "port": 8080,     ← נוסף
   "host": "0.0.0.0"

פתרון Merge Conflicts

Merge Conflict (קונפליקט מיזוג) קורה כש-git לא מצליח למזג שני שינויים אוטומטית — בדרך כלל כשאתם ומישהו אחר (או branch אחר) שיניתם את אותן שורות באותו קובץ. התוצאה היא קובץ עם סימני קונפליקט שנראים ככה:

<<<<<<< HEAD
const API_URL = "https://api.myapp.com/v2";
=======
const API_URL = "https://staging.myapp.com/v1";
>>>>>>> feature-branch

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

שלב 1: הבינו את שני הצדדים

בקשו מ-Claude: "הסבר את הקונפליקט ב-config.js — מה שינה כל צד ולמה?"

Claude יקרא את הקובץ, יזהה את סימני הקונפליקט, ויסביר: "ב-HEAD שיניתם ל-API v2 בפרודקשן. ב-feature-branch שיניתם ל-staging v1 לבדיקות."

שלב 2: החליטו והנחו

"פתור את הקונפליקט — שמור את ה-URL של v2 בפרודקשן"

Claude ישתמש ב-Edit כדי להסיר את סימני הקונפליקט ולשמור את הגרסה הנכונה.

שלב 3: ודאו

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

טיפים לפתרון קונפליקטים יעיל

• היו ספציפיים: במקום "פתור את הקונפליקט", אמרו "פתור את הקונפליקט — שמור את הגרסה שלנו לכל מה שקשור לסגנון, ואת הגרסה שלהם לכל מה שקשור ללוגיקה"
• בקשו הסבר קודם: "הסבר את כל הקונפליקטים בקובץ לפני שאתה פותר" — ככה אתם מבינים מה קורה לפני שמחליטים
• ודאו אחרי: אחרי פתרון, תמיד הריצו git diff ובדקו שסימני הקונפליקט (<<<<<<<, =======, >>>>>>>) באמת נעלמו
• הריצו טסטים: קונפליקטים שנפתרו לא בהכרח קוד שעובד. הריצו את ה-test suite כדי לוודא

Code Review — Claude כסוקר הקוד שלכם

Code Review (סקירת קוד) הוא תהליך שבו מישהו אחר בודק את הקוד שלכם לפני שהוא נכנס לפרודקשן. ב-2026, Claude הוא ה-Reviewer הכי סבלני, הכי זמין, והכי מקיף שיש — הוא עובד 24/7, לא מקפיד אישית, ובודק ממש הכול.

סוגי Review

יש כמה סוגי סקירה שאפשר לבקש מ-Claude:

ה-Review Checklist

כש-Claude עושה סקירה מקיפה, הוא בודק לפי הסדר הבא:

1. Bugs — שגיאות לוגיות, null checks חסרים, off-by-one errors
2. Security — SQL Injection, XSS, סודות חשופים, הרשאות חסרות
3. Performance — queries כבדים, loops מיותרים, memory leaks
4. Readability — שמות משתנים, תיעוד, מורכבות מיותרת
5. Edge Cases — מה קורה עם input ריק? עם null? עם מספר שלילי?
6. Tests — יש כיסוי? האם הטסטים בודקים את מה שחשוב?

Review של תוכן — לא רק קוד

Claude יכול לסקור גם תוכן שאינו קוד:

• פוסט בלוג: "סקור את הפוסט הזה — דקדוק, בהירות, SEO"
• מייל שיווקי: "סקור את המייל — Subject Line, CTA, ברור מה הצעד הבא?"
• תיעוד API: "סקור את ה-README — מובן למפתח חדש? מכסה את כל ה-endpoints?"
• הצעת מחיר: "סקור את ההצעה — מחירים הגיוניים? התנאים ברורים? יש CTA?"
• מצגת: "סקור את הסליידים — המסר ברור? יש יותר מדי טקסט?"

פרומפטים מומלצים ל-Code Review

עקרון הפשטות — Keep It Simple

Claude הוא מתכנת מצוין. אבל בדיוק בגלל זה, לפעמים הוא מייצר פתרונות מורכבים מדי — שכבות אבסטרקציה, Design Patterns, ומודולים שלא באמת צריך. הוא לא עושה את זה מתוך רוע — הוא פשוט מנסה לכתוב קוד "נכון" לפי הספר. אבל קוד "נכון" לפי הספר ≠ קוד שמתאים לצרכים שלכם.

ביטויי קסם לפשטות

• "Keep it simple" — ההנחיה הכי ישירה. Claude יפשט.
• "No over-engineering" — מונע שכבות מיותרות.
• "Straightforward approach only" — גישה ישרה, בלי עקיפות.
• "This doesn't need to be production-quality, just functional and readable" — לסקריפטים חד-פעמיים.
• "Is there a simpler way to achieve the same thing?" — שאלו את זה אחרי כל פתרון מורכב.

"תקציב מורכבות" — Complexity Budget

לפני שמאשרים פתרון, שאלו את עצמכם: "האם המורכבות הזו פרופורציונלית לבעיה?" תיקון של 5 שורות לא צריך Refactoring של 50 שורות. סקריפט שרץ פעם ביום לא צריך ארכיטקטורת Microservices. טופס עם 3 שדות לא צריך State Management מורכב.

סימנים שהפתרון מורכב מדי

איך תזהו שClaude (או אתם) הלכתם רחוק מדי? חפשו את הסימנים:

• יותר מ-3 קבצים חדשים למשימה פשוטה: אם ביקשתם סקריפט קטן וקיבלתם ארכיטקטורה של 5 קבצים — זה Over-Engineering.
• Abstract classes ו-Interfaces לדבר אחד: אם יש Interface אחד ו-Implementation אחד — לא צריך את ה-Interface.
• Design Patterns לבעיה של 10 שורות: Factory Pattern, Observer Pattern, Strategy Pattern — מצוינים לפרויקטים גדולים, Overkill לסקריפט חד-פעמי.
• Configuration ש-Nobody Will Ever Change: אם ה-timeout הוא 5000ms ולעולם לא ישתנה — כתבו 5000 בקוד, לא בקובץ Config נפרד.

Undo ורשת ביטחון — כשדברים משתבשים

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

רשת 1: Git — רשת הביטחון הבסיסית

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

• git checkout -- filename.py — מחזיר קובץ ספציפי למצב של ה-commit האחרון
• git stash — שומר את כל השינויים הנוכחיים בצד, מחזיר למצב נקי
• git stash pop — מחזיר את השינויים ששמרתם
• git diff — מראה מה השתנה (לפני שמחליטים אם לשמור או לבטל)

רשת 2: Checkpoints — נקודות שחזור אוטומטיות

Claude Code יוצר Checkpoint אוטומטי בכל פרומפט שלכם. אתם לא צריכים לעשות כלום — זה קורה ברקע. ה-Checkpoints נשמרים 30 יום ומתעדים גם את השיחה וגם את מצב הקבצים.

חשבו על Checkpoints כמו Save Points במשחק מחשב: כל פעם שאתם כותבים פרומפט, המערכת שומרת "תמונת מצב" של הכול. אם משהו משתבש — אפשר לחזור לכל Save Point.

רשת 3: /rewind — חזרה בזמן

הפקודה /rewind מחזירה אתכם לנקודת Checkpoint קודמת — גם את השיחה וגם את הקבצים. זה כמו Ctrl+Z על סטרואידים: לא רק פעולה אחרונה, אלא חזרה לרגע ספציפי בשיחה.

אפשר גם לעשות Escape כפול (לחיצה כפולה על Escape) — זה מפעיל rewind מהיר שמחזיר את השינוי האחרון.

רשת 4: "בטל את זה" — בקשה מילולית

הדרך הכי פשוטה: פשוט אמרו ל-Claude "בטל את השינוי האחרון" או "Undo that". Claude יבצע Edit הפוך — יחליף את הטקסט החדש בטקסט הישן. זה עובד הכי טוב לשינוי אחרון בודד.

עריכת תוכן — קבצים שהם לא קוד

Claude Code לא מוגבל לקוד. הוא עורך כל קובץ טקסטואלי — Markdown, CSV, HTML, JSON, YAML, plain text, קבצי קונפיגורציה, ועוד. אותם כלי Edit ו-Write עובדים בדיוק אותו דבר, לא משנה אם הקובץ הוא Python script או מייל שיווקי בעברית.

דוגמאות לשימושים נפוצים

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

# פרומפט אחד:
"מצא את כל קבצי ה-HTML בתיקיית pages/ שמכילים את הלוגו הישן
old-logo.png, והחלף אותו ב-new-logo.svg בכל אחד מהם"

עריכת תוכן בעברית

Claude מצוין בעריכת תוכן בעברית. כמה שימושים נפוצים:

• תיקון דקדוק: "בדוק ותקן שגיאות דקדוק בקובץ about.md"
• שיפור סגנון: "שפר את הסגנון של הפסקה הראשונה — יותר מקצועי ופחות אקדמי"
• תרגום: "תרגם את ה-error messages בקובץ הזה מאנגלית לעברית"
• עדכון מידע: "עדכן את כל השנים מ-2025 ל-2026 בקובץ הזה"
• קיצור: "קצר את הפסקה הזו ל-2 משפטים בלי לאבד את המסר"

טעויות נפוצות בעריכה — ואיך להימנע מהן

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

Frameworks להחלטות

שגרת עבודה — עריכה יומיומית עם Claude Code

בנוסף לשגרת הניווט מפרק 5, הנה משימות העריכה שכדאי לשלב:

תרחיש יומיומי — כל השלבים יחד

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

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

תרגילים מעשיים

בדוק את עצמך

צ'קליסט — סיכום פרק 6

• אני יודע להשתמש ב-Edit לשינויים ממוקדים בקבצים קיימים
• אני יודע להשתמש ב-replace_all כשצריך להחליף את כל המופעים
• אני יודע להשתמש ב-Write ליצירת קבצים חדשים
• אני מבין את כלל ה-80% — מתי Edit ומתי Write
• אני יכול להנחות Claude לבצע שינויים רב-קובציים מתואמים
• אני יודע לקרוא Diff ולהבין מה השתנה (+ ירוק, - אדום)
• אני יודע לבקש מ-Claude לפתור Merge Conflicts
• אני עושה Code Review לפני כל commit
• אני יודע לבקש מ-Claude פתרון פשוט ("Keep it simple")
• אני יודע לעשות Undo עם git checkout
• אני יודע לעשות Undo עם /rewind או Escape x2
• אני עושה git commit לפני שינויים ניסיוניים
• אני יודע לערוך קבצים שהם לא קוד (Markdown, CSV, JSON)
• אני מבדיל בין גישה שמרנית (Codebase קיים) לגישה יצירתית (Greenfield)