📌 איפה אני גר?

ניסיון ראשון:

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

ניסיון שני:

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

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

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

הנה דוגמה מהיום. סוכן מייצר קוד כזה:

else
  slug = generate_slug_with_video_id(title, video_id)
  course = create_course_with_unique_slug(user: user, name: title, slug: slug, main_media_url: progress.youtubeurl, language: language, cover: cover_attributes(video))
end

ואז בהמשך הקובץ:

  def create_course_with_unique_slug(user:, name:, slug:, main_media_url:, language:, cover: {}, max_retries: 10)
    retries = 0
    begin
      course = Course.new(
        name: name,
        slug: slug,
        main_media_url: main_media_url,
        language: language,
        user: user,
        status: :processing,
        **cover
      )

      course.save!
      course

    rescue ActiveRecord::RecordNotUnique => e
      retries += 1
      if retries < max_retries
        Rails.logger.warn "Slug collision for '#{slug}', adding suffix (attempt #{retries})..."
        slug = "#{slug}-#{retries}"
        retry
      else
        raise
      end
    end
  end

הקוד מפעיל את הפונקציה generate_slug_with_video_id ואז מעביר את התוצאה שלה ל create_course_with_unique_slug כדי למצוא בלולאה מזהה לא תפוס. וזה עקום כי הרבה יותר הגיוני לכתוב:

course = Course.create!(...)

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

📌 מה קרה עם Prompt Engineering

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

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

ויש רק שני דברים שחשוב לשפר כאן:

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

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

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

פרומפט אנג'ינירינג אולי התיישן מהר. הטכניקה שהולידה אותו תישאר איתנו להרבה זמן.

📌 סיכום וובינר בדיקות עם AI

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

✏ יצירת פרויקט בדיקות

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

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

בשביל הדוגמה בדקנו את langlets. יצרנו פרויקט בדיקות חדש בתיקייה חדשה עם הפקודה:

npm init playwright@latest

לאחר מכן חיברנו את קלוד קוד לדפדפן בעזרת MCP עם הפקודה:

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

וגם התקנו את ה Skill של פליירייט עם הפקודה:

playwright-cli install --skills

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

✏ הדגמה ראשונה - סוכן כותב בדיקה

כתבתי את הפרומפט הבא:

Use playwright

  Implement a first test in a new test file

  Test langlets.app loads, the click "Sign in" In the top right corner
  Then verify we are in the login page

  Iterate until the test pass.
  Use a real browser to check the site and understand its structure

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

import { test, expect } from '@playwright/test';

test('sign in link in the top right corner opens the login page', async ({ page }) => {
  await page.goto('https://langlets.app/');

  // The home page is loaded.
  await expect(page.getByRole('heading', { level: 1 })).toContainText(
    'Practice your target language with videos you love'
  );

  // Click "Sign in" in the top right corner (the page body has another
  // "Sign in" button, so scope the locator to the navigation).
  await page.getByRole('navigation').getByRole('link', { name: 'Sign in' }).click();

  // We are on the login page.
  await expect(page).toHaveURL(/\/users\/sign_in$/);
  await expect(page.getByRole('heading', { name: 'Log in' })).toBeVisible();
  await expect(page.getByRole('textbox', { name: 'Email or username' })).toBeVisible();
  await expect(page.getByRole('textbox', { name: 'Password' })).toBeVisible();
  await expect(page.getByRole('button', { name: 'LOG IN' })).toBeVisible();
});

בשביל להריץ את הבדיקות אני כותב:

npx playwright test

פליירייט אוטומטית הריץ את הבדיקה שקלוד כתב בשלושה דפדפנים - כרומיום, פיירפוקס וספארי ומסמן לי שבכולם הוא קיבל את התוצאה הרצויה.

בשביל הנוחות אני מוסיף לקובץ package.json סקריפט להרצה מהירה של הבדיקות:

{
  "name": "testlanglets",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "playwright test"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "commonjs",
  "devDependencies": {
    "@playwright/test": "1.62.0",
    "@types/node": "26.1.2"
  }
}

וכך אוכל לכתוב:

npm run test

כדי להריץ את הבדיקות.

✏ דוגמה 2 - כתיבת בדיקה אינטרקטיבית עם AI

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

1. פתח חלון דפדפן חדש.
2. התחבר ל https://langlets.app/app/import_requests.
3. ספר לי מה קרה.

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

ok that's actually the good behaviour
write a playwright test to verify what we just saw

ובתגובה קלוד מימש את הבדיקה הבאה:

import { test, expect } from '@playwright/test';

test('a signed out visitor is redirected from /app/import_requests to the login page', async ({
  page,
}) => {
  const response = await page.goto('https://langlets.app/app/import_requests');

  // The guarded page itself answers with a redirect...
  const redirect = response?.request().redirectedFrom();
  expect(redirect).toBeTruthy();

  expect(redirect!.url()).toBe('https://langlets.app/app/import_requests');
  expect((await redirect!.response())?.status()).toBe(302);

  // ...and we end up on the login page, not on the protected content.
  expect(response?.status()).toBe(200);
  await expect(page).toHaveURL(/\/users\/sign_in$/);
  await expect(page.getByRole('heading', { name: 'Log in' })).toBeVisible();
  await expect(page.getByRole('textbox', { name: 'Email or username' })).toBeVisible();
  await expect(page.getByRole('textbox', { name: 'Password' })).toBeVisible();
  await expect(page.getByRole('button', { name: 'LOG IN' })).toBeVisible();
});

✏ דוגמה 3 - חקור את האתר

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

explore the site and implement playwright tests for important functionality

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

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

https://earendil.com/posts/session-portability/

Together all of these things change the ownership reality of an AI session: the transcript on your machine is no longer your session but a partial view of a session whose operational state belongs to an inference provider and not you.

📌 תראה מה קלוד הסביר לי

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

ומצד שני החיים האמיתיים.

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

Not only did I get sidetracked by a bunch of useless suggestions but I also had to put up with others dumping their raw AI output at me as if it was somehow a meaningful contribution.

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

"אי אפשר להחליף מטכנולוגיה X ל Y" - ואז הסבר ארוך מודבק מ AI.

"יש בעיית אבטחה אם עושים X" - ואז הסבר ארוך מודבק מ AI.

"יהיה יותר נכון להוסיף redis" - ואז הסבר ארוך מודבק מ AI.

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

📌 מה לוקח זמן בפיתוח עם AI

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

✏ מנגנונים עודפים

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

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

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

✏ מנגנונים חסרים

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

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

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

✏ ארגון מחדש של החלטות עקומות של AI

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

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

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

✏ שיפור ביצועים באמצעות שינוי מבני באופן העבודה של המערכת

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

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

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

✏ סינון שטויות ש AI מסביר

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

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

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

✏ אינטגרציה עם שירותי צד שלישי

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

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

✏ אופטימיזציה לפרומפטים וקריאות AI

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

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

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

✏ תחזוקה ושיפור עבודת הסוכן

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

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

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

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

📌 מה למדתי מלקרוא את הקוד

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

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

כשהוא מתחיל להסביר לי על התיקון שהוא בנה שמפענח טוב יותר את ההודעות שחוזרות מהסוכן אני שואל "ולמה לא השתמשנו לפני כן ב Structured Output"?

כשהוא מדבר בשבחי מנגנון ה Cache שהוא הוסיף עכשיו כדי שהמידע יחזור מהשרת מהר יותר אני שואל "אבל למה השאילתה עד עכשיו לקחה כל כך הרבה זמן"?

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

כל תיקון כשלעצמו אולי הכי מדויק שיכול להיות - אבל במערכת טובה זו התמונה המלאה שקובעת.

📌 נקודות כשל (או: אולי כבר לא צריך ללמוד פייתון)

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

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

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

ב Langlets בניתי סוכן AI שמייצר תרגילי אוצר מילים בשפה. ההחלטות על היכולות של הסוכן - האם הוא מייצר HTML מלא? האם הוא מייצר אפליקציה מלאה (כולל צד שרת)? האם הוא מייצר את התרגיל בפורמט פנימי שלי, איך יישמרו התרגילים ואיך יישמרו התשובות, כל אלה קובעות מה אפשר יהיה לבצע בתרגילים. ההחלטות יוצרות את המסגרת, הסוכן מצייר בתוך הקווים.

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

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

דוגמה קטנה מ Langlets להמחשה - יצרתי פעילות של סידור מילים במשפט, לדוגמה

https://he.langlets.app/courses/president-franklin-d-roosevelt-declares-war-on-jap-lk8gygg0dke/lessons/peaceful-relations-and-deception?a=4

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

def word_order_phrases(phrases)
  phrase_list = phrases.is_a?(ActiveRecord::Relation) ? phrases.to_a : phrases
  phrase_list.select do |phrase|
    words = phrase.text_l1.to_s.split(/\s+/).reject(&:empty?)
    words.any? && words.size <= MAX_WORD_ORDER_WORDS
  end
end

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

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

מצד אחד לא צריך לדעת לכתוב לולאות ב Ruby ולא צריך לזכור אם זה filter או select או reject ואם צריך לבדוק שמערך גדול מאפס או שיש פונקציה בשם any? שמחזירה את זה ואפילו לא יקרה כלום אם נדלג על ה to_a או התנאי בשורה הראשונה. אבל פיצול שורה למילים לפי רווחים כבר ישבור את ההגיון הפנימי של המערכת וזו החלטה לא נכונה. גם אם זה יעבוד היום זה מהר מאוד יישבר.
(ושלא תתחילו עם "פשוט תכניס את כל החוכמה הזאת ל AGENTS.md. הגיון של החלטות משתנה ויש כל הזמן החלטות חדשות. ברור שצריך להשתמש ב AGENTS.md אבל הוא לא מחליף את קריאת הקוד).

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

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

📌 היום למדתי: fgrep לעומת grep

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

לדוגמה נתון קובץ טקסט עם השורות הבאות:

line1
line2
line3
line4
line.txt

בשביל לבדוק אם קיימת בו השורה line3 נוכל לכתוב:

$ grep line3 demo.txt

ונקבל את השורה.

בשביל לבדוק אם קיימת בו השורה line.txt מפתה לכתוב גם:

$ grep line.txt demo.txt

וזה גם עובד ומדפיס את line.txt - אבל זה בטעות. הנקודה ב line.txt היא תו של ביטויים רגולאריים ובעצם מתאימה לכל תו. לדוגמה אם הקובץ שלנו מכיל:

line-txt
line_txt
line2txt

אותה פקודת grep תחזיר את כל השורות:

grep line.txt demo.txt
line.txt
line-txt
line_txt
line2txt

מה עושים? נזכרים בטיפ בכותרת. פקודת grep -F או פקודת fgrep מחפשות טקסט פשוט ולא ביטוי רגולארי לכן כשאנחנו מחפשים טקסט רגיל נעדיף לכתוב:

$ fgrep line.txt demo.txt
line.txt

ונקבל רק את השורה עם הנקודה ולא את השורות שמתאימות לביטוי הרגולארי.

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

2+4
2229

פקודת grep תחזיר ממש את הפלוס ותתעלם מהפלוס במשמעותו המיוחדת של "תו נוסף" שאנחנו מכירים מביטויים רגולאריים:

$ grep '2+' demo.txt
2+4

אבל זו רק הטעיה כי אם מוסיפים לה \ לפני הפלוס היא חוזרת להתיחס אליו כמו תו של ביטויים רגולאריים:

$ grep '2\+' demo.txt
2+4
2229