ToCode

השאלה היא לא כמה אחוז מהקוד ה 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.

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

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

השוואה בין 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. כולם יודעים לשגר מספר סוכנים שיעבדו על בעיה במקביל.

טיפ: סוכני קידוד וקבצי הזכרון שלהם נתתם לקלוד לבנות פיצ'ר, המימוש לא היה משהו, מחקתם את מה שהוא כתב עם git restore . && git clean -f -d והמשכתם הלאה בחיים. סוף סיפור? לא בדיוק. קלוד קוד וקופיילוט CLI מנהלים זכרונות תוך כדי תנועה. הם עושים את זה אוטומטית ויש גם תוספים שגורמים להם לשמור יותר זכרונות או לשמור את הזכרונות בצורה יותר טובה. הבעיה? כשמנקים את העבודה שלהם עם git restore קבצי הזכרון לא נמחקים. כשעוברים בין כמה סוכני קידוד קבצי הזכרון לא מתעדכנים. המידע הישן בקבצי הזכרון יכול לפגוע בתוצאות של הדברים הבאים שקלוד יבנה. הזכרון של קלוד קוד מוסבר בדף התיעוד הזה: https://code.claude.com/docs/en/memory הרבה פעמים שווה להגדיר CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 ולוותר על יצירת הזכרונות תוך כדי תנועה ובמקום זה להסתמך על קבצי הוראות. הזכרונות עצמם נשמרים בתיקיית ~/.claude/projects/<project>/memory/. תיקייה אחת למעלה תוכלו למצוא את כל השיחות הקודמות שעשיתם עם קלוד. מדי פעם מומלץ: 1. לכתוב /memory בתוך קלוד קוד, לבקש עריכה של קובץ הזכרון ולנקות אותו. 2. לבקש מקלוד קוד עצמו שינקה זכרונות לא רלוונטיים או לבקש שימחק פרטים ספציפיים (בפרומפט של קלוד קוד).

טיפ: סוכני קידוד וקבצי הזכרון שלהם נתתם לקלוד לבנות פיצ'ר, המימוש לא היה משהו, מחקתם את מה שהוא כתב עם git restore . && git clean -f -d והמשכתם הלאה בחיים. סוף סיפור? לא בדיוק. קלוד קוד וקופיילוט CLI מנהלים זכרונות תוך כדי תנועה. הם עושים את זה אוטומטית ויש גם תוספים שגורמים להם לשמור יותר זכרונות או לשמור את הזכרונות בצורה יותר טובה. הבעיה? כשמנקים את העבודה שלהם עם git restore קבצי הזכרון לא נמחקים. כשעוברים בין כמה סוכני קידוד קבצי הזכרון לא מתעדכנים. המידע הישן בקבצי הזכרון יכול לפגוע בתוצאות של הדברים הבאים שקלוד יבנה. הזכרון של קלוד קוד מוסבר בדף התיעוד הזה: https://code.claude.com/docs/en/memory הרבה פעמים שווה להגדיר CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 ולוותר על יצירת הזכרונות תוך כדי תנועה ובמקום זה להסתמך על קבצי הוראות. הזכרונות עצמם נשמרים בתיקיית ~/.claude/projects/<project>/memory/. תיקייה אחת למעלה תוכלו למצוא את כל השיחות הקודמות שעשיתם עם קלוד. מדי פעם מומלץ: 1. לכתוב /memory בתוך קלוד קוד, לבקש עריכה של קובץ הזכרון ולנקות אותו. 2. לבקש מקלוד קוד עצמו שינקה זכרונות לא רלוונטיים או לבקש שימחק פרטים ספציפיים (בפרומפט של קלוד קוד).

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

functions aren't used for the second account because they are hard coded with $this->accountId
  Map the helper functions that could be reused, refactor them to accept accountId and then refactor the tests to
  use them

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

I see file @tests/Automations/AutomationQueueReconciliationWorkerTest.php uses 2 accounts but many of the helper
functions aren't used for the second account because they are hard coded with $this->accountId
Create a class to wrap test helpers of an account call it TestAccount. Move all test helpers to be mthods of this class and use it to create multiple accounts:

$account1 = new TestAccount();
$account1->seupWorkflowWithSubscribers();
$account2 = new TestAccount();
$account2->seupWorkflowWithSubscribers();

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

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

// Create workflow in account 1
$messageIds1 = $this->createSeriesMessages(2);
$template1 = $this->generateSeriesLogicJsonTemplate(2);
$result1 = $this->createSeriesAutomationWithMessages(
    $this->accountId,
    $this->listId,
    $template1,
    array_combine(range(0, count($messageIds1) - 1), $messageIds1)
);
$workflowId1 = $result1['workflowId'];

// Add subscribers to account 1
$subscriberIds1 = array_slice($this->subscriberIds, 0, 3);
$this->seedUserEnterList($this->listId, $subscriberIds1, $this->accountId);
$this->runAutomationHandler($this->accountId);

// Create second account
$this->secondAccount = $this->createSecondAccount(5);

// Create workflow in account 2
$messageIds2 = [];
for ($i = 0; $i < 2; $i++) {
    $messageIds2[] = $this->createMessageForAccount(
        $this->secondAccount['accountId'],
        $this->secondAccount['listId'],
        $this->secondAccount['senderId'],
        "Account2 Message " . ($i + 1),
        "Account2 Subject " . ($i + 1)
    );
}
// ... skip more code ...
$workflowId2 = $responseData2['createdId'];

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

$workflowId1         = $this->createWorkflowInAccount($this->accountId);
$this->addSubscribersToAccount($this->accountId);
$this->secondAccount = $this->createSecondAccount(['subscribers' => 5]);
$workflowId2         = $this->createWorkflowInAccount($this->secondAccount);

למה הקוד לא עקבי דבר שני שאנחנו מיד שמים לב הוא חוסר העקביות בקוד בין יצירת ה workflow לחשבון הראשון ליצירת ה workflow לחשבון השני. זה החשבון הראשון:

// Create workflow in account 1
$messageIds1 = $this->createSeriesMessages(2);
$template1 = $this->generateSeriesLogicJsonTemplate(2);
$result1 = $this->createSeriesAutomationWithMessages(
    $this->accountId,
    $this->listId,
    $template1,
    array_combine(range(0, count($messageIds1) - 1), $messageIds1)
);
$workflowId1 = $result1['workflowId'];

בחשבון השני דילגתי על רוב הקוד כי הוא היה מאוד ארוך. מה שקלוד עשה שם הוא מעניין - הפונקציות שמופיעות בקטע ויוצרות את המידע לחשבון הראשון לא מקבלות את מזהה החשבון בתור פרמטר ותמיד יעבדו על $this->accountId. קלוד קוד משתדל מאוד לא לשנות חתימות של פונקציות ולכן הוא יעדיף להעתיק את תוכן הפונקציות מתחת להערה ולייצר הרבה יותר קוד שגם לא עקבי עם הקוד שהיה לפניו. ההזדמנות חוסר העקביות הוא סימן ברור לזה שהתשתית שהיתה לי בקוד לא היתה מספיק טובה בשביל הקוד החדש שקלוד יצר. ופה יש לי הזדמנות לשים לב לפער ולתקן אותו וכך גם ה Code Review שלי יהיה מהיר יותר. ברגע שזיהיתי את הבעיה אני יכול להשתמש בפרומפט בסגנון הזה:

I see file @tests/Automations/AutomationQueueReconciliationWorkerTest.php uses 2 accounts but many of the helper