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

אבל מה שאנחנו רואים בקלות לגבי אנגלית קשה לנו לראות לגבי תכנות.

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

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

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

טיפ: סוכני קידוד וקבצי הזכרון שלהם
נתתם לקלוד לבנות פיצ'ר, המימוש לא היה משהו, מחקתם את מה שהוא כתב עם git restore . && git clean -f -d והמשכתם הלאה בחיים.

סוף סיפור? לא בדיוק.

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

הזכרון של קלוד קוד מוסבר בדף התיעוד הזה:

https://code.claude.com/docs/en/memory


הרבה פעמים שווה להגדיר CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 ולוותר על יצירת הזכרונות תוך כדי תנועה ובמקום זה להסתמך על קבצי הוראות.

הזכרונות עצמם נשמרים בתיקיית ~/.claude/projects/<project>/memory/. תיקייה אחת למעלה תוכלו למצוא את כל השיחות הקודמות שעשיתם עם קלוד. מדי פעם מומלץ:

1. לכתוב /memory בתוך קלוד קוד, לבקש עריכה של קובץ הזכרון ולנקות אותו.

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

השוואה בין Claude Code, Copilot CLI ו Cursor CLI
סוכני הקידוד משורת הפקודה השתפרו מאוד ממש בחודשים האחרונים. זה התחיל עם קלוד קוד וההתלהבות הגדולה ממנו, משך את תשומת הלב של מייקרוסופט והביא לפיתוח Cursor CLI ואחרונים הגיעו Cursor עם כלי CLI משלהם. כל השלושה מעולים ובזכותם הצלחתי בתקופה האחרונה לחזור לקודד עם vim. בכל זאת אני רוצה לשתף את המסקנות המרכזיות שלי מהעבודה עם שלושתם, לא בשביל להגיד תשתמשו בכלי X או Y אלא יותר לעשות סדר, לראות חוזקות וחולשות ולתת לכם את הכלים איך לבחור.

איך אני עובד
אני עובד על מספר פרויקטים בו זמנית ומפצל את הטרמינל עם tmux, כל פרויקט מקבל session. בכל session של tmux יש לי כמה טאבים פתוחים ותמיד אחד מהם יהיה neovim, עוד אחד shell והשאר לפי צרכי הפרויקט.

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

app/controllers/demo_controller.rb:69-70 

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

קודקס לא מופיע בהשוואה הזו כי לא ניסיתי אותו.

כמה זה עולה
הדרך המקובלת לעבוד עם כלי AI היא מנוי חודשי ולכל אחד מהכלים יש את המנוי שלו:

1. קרסר מציעים מנוי בסיסי ב 20$ לחודש ומנויים עם יותר שיחות ביותר.
2. קופיילוט מציעים מנוי בסיסי ב 10$ לחודש ומנוי עם יותר שיחות ב 40$.
3. קלוד קוד מציעים את המנוי הבסיסי ב 20$ לחודש ומנוי מתקדם ב 100$.

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

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

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

מצבי פעולה
בכל אחד מהכלים כפתור Shift+Tab יחד מחליף מצב פעולה. המצבים הם:

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

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

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

פיצ'רים
אלה הפיצ'רים המרכזיים שניסיתי בשלושת הכלים:

1. כולם תומכים בשרתי MCP
2. כולם תומכים ב Skills
3. כולם יכולים להראות שיחות ישנות ולהמשיך סשן קודם
4. קופיילוט וקלוד יודעים לנתח פרויקט וליצור לעצמם קובץ AGENTS בסיסי.
5. קופיילוט יודע להראות את השינויים בתיקייה בדומה ל git diff. אישית אני מעדיף את git diff מתוך וים כדי לעבור על שינויים.
6. כולם יודעים לעבוד עם sub agents וליצור סוכנים, למשל סוכן עבור code review.
7. כולם יודעים לשגר מספר סוכנים שיעבדו על בעיה במקביל.

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

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

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

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

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

הגדרת תלויות ב docker-compose עלולה להסתיר באג במערכת
נתבונן בדוקר קומפוז הבא:

services:
  db:
    image: postgres:15
    container_name: my_postgres

  api:
    build: ./api
    container_name: my_api
    depends_on:
      - db

קלאסי נכון? שרת API שתלוי בבסיס נתונים והגדרת depends_on בדוקר קומפוז כדי לוודא שבסיס הנתונים עולה קודם.

אבל בעצם... למי אכפת מה עולה קודם?

אם שרת ה API מנסה לעשות משהו עם בסיס הנתונים ולא מצליח הוא צריך להציג שגיאה. כשבסיס הנתונים יעלה ה API יחזור לעבוד. מה עוזר ה depends_on כאן?

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

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

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

הנה כמה מטריקות טובות יותר לשילוב AI במהלך הפיתוח:

1. כמה אחוז מהקוד נכנס למערכת בלי שאף אחד קרא אותו?
2. כמה אחוז מהקוד ש AI כותב הרגשנו בנוח לזרוק לפח?
3. מה אנחנו עושים היום טוב יותר או אחרת ממה שעשינו בעבר בזכות ה AI?
4. כמה גרסאות שונות אני בודק לכל פיצ'ר לפני שאני מתקדם?
5. כמה תהליכי עבודה מבוססי AI חדשים בנינו בארגון?

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

אם ה AI כתב 100% או 80% מהקוד זה לא הדבר החשוב, מה שחשוב זה איך אנחנו עובדים היום ואיך תהליך העבודה השתפר בזכות שימוש בכלי AI.

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

בעולם של ספריות לפיתוח סוכנים חכמים המשחק שונה לגמרי: הממשק מול המודל מתפתח כל הזמן, אגרגטורים כמו Bedrock, Open Router ו Copilot Models עוטפים את ה API הבסיסי ויכולים לספק פונקציונאליות נוספת או כפולה, סביבות להרצת סוכנים כמו Vertex AI Engine או Agent Core מספקות עוד יכולות וכל אלה משתנים כל הזמן. כך יש לנו היום כלים מובנים בתוך ה API של OpenAI, כלים מובנים ב AgentCore, שער של אייג'נט קור להרצת כלים או חיבור שרתי MCP וספריית פיתוח סוכנים שבעצמה מתחברת לשרתי MCP.

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

ומתוך הבנה של תנאי העבודה השונים כדאי לאמץ גישה שונה למתנות שאנחנו מקבלים מכל עולם:

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

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

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

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

הנה רובי:

def create_connection
  Bunny.new(@connection_config[:url]).tap(&:start)
end

הפונקציה פותחת חיבור ל Rabbitmq ומחזירה את החיבור שנפתח. נתעלם רגע מהשאלה אם צריך פונקציה בשביל זה (אני חושב שלא), אבל השאלה היותר חשובה היא מה ה tap עושה שם? הנה הקוד בצורה הכי מפורשת שלו:

def create_connection
  conn = Bunny.new(@connection_config[:url])
  conn.start
  return conn
end

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

def create_connection
  Bunny.new(@connection_config[:url]).start
end

אז הפונקציה היתה מחזירה את מה ש start מחזירה ואולי זה משהו אחר ממה ש new מחזירה. פה המקום לשים לב לנטיה של AI לעבוד בתבניות - קלוד לא בדק מה start מחזירה. אם הוא היה בודק הוא היה רואה שהיא מחזירה בדיוק את אוביקט החיבור כי מי שכתב את Bunny כבר חשב על מנגנון הקריאה הזה. כלומר ה tap מיותר לגמרי שם.

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