📌 חמש תקריות אבטחה הקשורות לסוכני AI שחשוב להכיר

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

✏ דליפת הקוד של קלוד קוד דרך sourcemap

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

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

מקור לקריאה נוספת:
https://dev.to/varshithvhegde/the-great-claude-code-leak-of-2026-accident-incompetence-or-the-best-pr-stunt-in-ai-history-3igm

✏ פרצת אבטחה ב Code Rabbit חשפה מידע סודי

קודרביט הוא סוכן חכם שכותב Code Reviews, כלומר הוא קורא קוד (PR-ים) שאנשים מעלים לגיטהאב ומסביר מה טוב ומה צריך לשפר בהם. קודרביט מאפשר להריץ כלי אנאליזה אוטומטיים על הקוד. אחד הכלים הנתמכים נקרא rubocop ותפקידו לבדוק קוד רובי. ופה יש שתי בעיות:

1. קודרביט הריץ את הכלי רובוקופ על מכונה פנימית שלהם, לה יש הרשאות והגדרת מפתחות API בתור משתני סביבה שמאפשרים לגשת להמון תשתית פנימית של קוד רביט.
2. רובוקופ מאפשר לטעון Extensions שהם קבצי Ruby מתוך מאגר הקוד הנבדק.

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

מקור לקריאה נוספת:
https://kudelskisecurity.com/research/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories

✏ מתקפת הזרקת פרומפט EchoLeak לקופיילוט

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

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

מתקפה זו מזכירה לנו את הבעיה בהגנה מבוססת סינון - מנגנוני סינון אפשר לעקוף ובהנתן תמריץ מספיק חזק מישהו בוודאות ימצא מעקף. לקח לנו עשרות שנים לנצח מתקפות SQL Injection וזמן דומה לנצח מתקפות JavaScript Injection (XSS). כמה זמן ייקח לנצח את מתקפות ה Prompt Injection?

קריאה נוספת:

https://www.forcepoint.com/blog/insights/echoleak-m365-copilot-attack

✏ בסיס הנתונים המלא של מולטבוק היה זמין ברשת

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

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

למידע נוסף:
https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys

✏ סוכן תמיכה של מטא שכנע עובד לבטל מדיניות אבטחה

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

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

לקריאה נוספת על האירוע:

https://agatsoftware.com/blog/ai-agent-security-meta-rogue-agent-incident/

📌 כזה ניסיתי: פיתוח צד-שרת עם vavite

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

בעוד ש next.js מאפשרת לכתוב גם קוד צד שרת וגם קוד צד לקוח, הפוקוס של vite הוא על צד לקוח בלבד. ומה קורה למי שרוצה לפתח קוד צד שרת node.js למשל עם express אבל בלי React? פה עדיין אין אפשרויות טובות:

1. אפשר להשאר עם node.js ולהשתמש בכלי כמו nodemon כדי לרענן את השרת אחרי כל שינוי בקוד ובכלי כמו ts-node בשביל להריץ את הטייפסקריפט (וכן נוד מתקרב לשם עם מצב watch מובנה והפשטת טיפוסי טייפסקריפט אבל אנחנו עדיין לא בעולם של ויט).
2. אפשר לעבור ל deno או bun שיודעים להריץ יופי טייפסקריפט מהקופסה אבל עלולים לסבך אותנו עם חבילות מסוימות שלא נתמכות (בעיקר דינו).

"לך מהר", או בשמו המקצועי vavite הוא פלאגין ל vite שמציע חווית פיתוח צד שרת עם ויט שעובדת טוב כמו פיתוח צד לקוח עם vite וגם מאפשרת הרחבות כמו Server Side Rendering למי שרוצה לבנות לעצמו next.js פשוט ומהיר יותר.

הקישור לפרויקט הוא:
https://github.com/cyco130/vavite

ואפשר למצוא המון דוגמאות בתיקיית הדוגמאות שלהם כאן:
https://github.com/cyco130/vavite/tree/main/examples

בשביל הניסוי התחלתי פרויקט vite חדש והוספתי את vavite:

$ npm create vite@latest server-demo
$ cd server-demo
$ npm install --save-dev vavite
$ npm install express @types/express

לאחר מכן יצרתי לפי ההוראות קובץ vite.config.ts עם התוכן הבא:

import { defineConfig } from "vite";
import { vavite } from "vavite";

export default defineConfig({
 appType: "custom",
 builder: {
  async buildApp(builder) {
   await builder.build(builder.environments.ssr!);
  },
 },
 plugins: [vavite()],
});

וקובץ src/entry.server.ts עם התוכן הבא:

import express from "express";

const text: string = "Hello New World";

const app = express();

app.get("/", async (req, res) => {
  res.send({ text });
});

// Default export a Connect-compatible handler for dev
export default app;

if (import.meta.env.COMMAND === "build") {
 // Start the Express server in production mode
 app.listen(3000, () => {
  console.log("Server is running on http://localhost:3000");
 });
}

if (import.meta.hot) {
 import.meta.hot.accept();
}

הפעלת שרת הפיתוח עם:

$ npm run dev

ואנחנו באוויר. התוצאה:

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

אחרי שמסיימים פיתוח מפעילים npm run build והפלאגין הופך את קבצי הטייפסקריפט לקובץ dist/entry.server.js אותו אפשר להפעיל ישירות עם node dist/entry.server.js או ליצור קיצור דרך מה package.json.

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

📌 תרגום ספריה? כבר לא בעיה

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

1. אפשר להריץ node.js בצד שרת כדי שיריץ את ה JavaScript.
2. אפשר לשלוח את הקוד להרצה בדפדפן ב Client Side.

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

היום זה כבר לא המצב.

הבוקר רציתי לרנדר מארקדאון בצד שרת בהזרמה. רדקרפט שהוא מנוע פענוח המארקדאון של רובי לא בנוי לזה. אולי היה אפשר להתאים אותו. אולי לא. לא נשארתי לגלות. במקום מצאתי את streaming markdown שהוא ספריית JavaScript לפענוח מדורג של מארקדאון, בדיוק מה שהייתי צריך. מה עושים? נותנים לקלוד קוד עם מודל פתוח GLM-5 לרוץ על הספריה ולבנות גרסת רובי שלה. שלוש שעות אחרי קיבלתי את:

https://github.com/ynonp/streaming-markdown-rb

אותו ממשק, 282 בדיקות אוטומטיות שהועתקו מגרסת ה JavaScript ועוברות בגרסת הרובי וקוד שעבד בנסיון הראשון.

📌 למה AI פוגע בבטחון שלכם כמפתחים ומה אפשר לעשות עם זה

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

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

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

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

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

function spawnAsteroid(){
  let r=Math.random()*22+14;
  let y=Math.random()*(H-r*2)+r;
  // מרחק מינימלי מהשחקן
  if(Math.abs(y-player.y)<60) y+=80;
  y=Math.max(r,Math.min(H-r,y));
  asteroids.push({x:W+r,y,r,speed:Math.random()*120+100+difficulty*15,rot:0,rotSpeed:(Math.random()-0.5)*3,hit:false});
}

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

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

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

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

📌 אבל המידע שאני צריך לא שם

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

https://sheltertime.mako.co.il/

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

היום הייתי צריך רק לכתוב את הפרומפט הבא בקלוד קוד:

Use chrome-devtools
Explain how this site works
https://sheltertime.mako.co.il/

Create a command line script in this directory that uses curl and shows the 5 cities with the highest count of alerts

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

#!/bin/bash
# Top 5 cities by shelter time from Mako's Shelter Time site
# Data source: https://sheltertime.mako.co.il/

DATA_URL='https://storage.googleapis.com/mamad-time-mako.firebasestorage.app/data_2026.json?v=7'

curl -s "$DATA_URL" \
  -H 'Accept: application/json' \
  -H 'Referer: https://sheltertime.mako.co.il/' \
  -H 'User-Agent: Mozilla/5.0' \
  | python3 -c '
import json, sys
from collections import defaultdict

data = json.load(sys.stdin)

# Each top-level key is an operation (e.g. "Iran")
# Each city: [total_time_ms, alert_count, cat1, cat2, days, rank, percentile]
for op, cities in data.items():
    print(f"\n=== Operation: {op} ===")
    print("Top 5 cities by total shelter time:")
    print("-" * 55)
    sorted_by_time = sorted(cities.items(), key=lambda x: x[1][0], reverse=True)[:5]
    for city, vals in sorted_by_time:
        ms = vals[0]
        hours = ms / 3600000
        alerts = vals[1]
        print(f"  {hours:>8.1f} hrs  ({alerts:>4} alerts)  {city}")

    print()
    print("Top 5 cities by alert count:")
    print("-" * 55)
    sorted_by_alerts = sorted(cities.items(), key=lambda x: x[1][1], reverse=True)[:5]
    for city, vals in sorted_by_alerts:
        ms = vals[0]
        hours = ms / 3600000
        alerts = vals[1]
        print(f"  {alerts:>5} alerts  ({hours:>6.1f} hrs)  {city}")
'

נשים לב:

1. למרות שביקשתי Shell Script קיבלתי קוד פייתון. ה Shell מפעיל פייתון. לא הכי ממושמע מצד glm אבל מצד שני אפשר לראות למה הוא עשה את זה. אולי גם הוא מסתבך עם התחביר של jq.
2. גלם כן הבין מיד את מבנה הנתונים והוסיף הערה שמסבירה מה יש ברוב העמודות. לא ברור מה זה cat1 ו cat2 אבל כל השאר די מסבירים את עצמם.
3. לא ברור למה גלם החליט לייבא את defaultdict, בכל מקרה הוא לא בשימוש.

📌 כזה ניסיתי: ה mcp של val town הוא הדרך הכי מהירה לשתף ניסויים מקלוד קוד

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

ה mcp של val.town מאפשר לנו לעבוד מקומית בתוך קלוד קוד ולהתחבר ל val.town כדי לפרסם את האפליקציה שלנו וכך לקבל במתנה את כל יכולות הפלטפורמה. קוד שרץ על val.town מקבל (בחינם) מהם:

1. ניהול משתמשים דרך מערכת אימות של val.town.
2. בסיס נתונים SQLite פנימי שלכם.
3. ניהול Storage עם אפשרות לשמירת blob-ים.
4. חיבור לאימיילים נכנסים ושליחת אימיילים.
5. חיבור ל ChatGPT (הטוקנים עליהם).
6. יצירת cron jobs שירוצו מהענן שלהם.

בשביל המשחק נתתי לקלוד קוד שלי (מודל פתוח glm-5.1 רץ על הענן של ollama, רק 20$ בחודש כמעט בלי הגבלת טוקנים) להריץ שני ניסויים. בפרומפט הראשון ביקשתי משחק סנייק שירוץ על val.town:

find val town docs here
https://docs.val.town/

create a snake game val and return to me its address

הוא יצר את המשחק והעלה אותו לאוויר אוטומטית בקישור הזה:

https://ynonp--734c4bca341c11f1b3c142b51c65c3df.web.val.run/

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

Create a Spanish flashcards app on val.town using the MCP server:
 1. user will sign in via val town https://docs.val.town/guides/auth/#sign-in-with-val-town
 2. user can type a word in English or Spanish and get the translation in the opposite language (use openai to translate
 https://docs.val.town/reference/std/openai/)
 3. user can save cards (use their sqlite db to save https://docs.val.town/reference/std/sqlite/)
 4. user can "practice" their saved words

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

https://ynonp--b97610c0341e11f1851b42b51c65c3df.web.val.run/

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

// Get all cards for user
app.get("/api/cards", async (c) => {
  const session = await getOAuthUserData(c.req.raw);
  if (!session?.user) {
    return c.json({ error: "Not authenticated" }, 401);
  }

  const result = await sqlite.execute({
    sql: "SELECT * FROM flashcards WHERE user_id = ? ORDER BY created_at DESC",
    args: [session.user.id],
  });

  return c.json(result.rows);
});

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

// Initialize database
await sqlite.execute(`
  CREATE TABLE IF NOT EXISTS flashcards (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id TEXT NOT NULL,
    english TEXT NOT NULL,
    spanish TEXT NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
  )
`);

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

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

📌 אתה עדיין יכול להיות מתכנת

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

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

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

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

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

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

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

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

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

It was three months of hard work, and you had to learn CGI-bin Perl programming in order to build a “buy now” button on your website. So it’s about three months of hard work and about 1000 dollars in setup fees to get a merchant account with my local bank. And I had to incorporate and set up a separate bank account. And after all that work, I had a “buy now” button on my website.

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

📌 מ Vibe Coding ל Coding

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

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

כך גם בתכנות, המעבר מ Vibe Coding ל Coding נעשה בשלבים:

1. בהתחלה נוכל רק להסתכל על הקוד שה AI מייצר ולהבין בגדול מה קשור למה.
2. בהמשך נתחיל לשלב מילים טכניות או מילים מתוך הקוד בשיחה - "אני חושב שאם נשפר את ה description של העמוד יהיה קל יותר למנועי חיפוש למצוא אותנו" או "העמוד הזה נטען לאט אולי צריך להוסיף אינדקס ב Database?". לא כל ההצעות יהיו הגיוניות וזה בסדר, גם מהתשובות של ה AI לומדים המון.
3. עם הזמן נוכל לבקש מה AI הסברים על הקוד - "אני לא מבין את הפונקציה הזאת, תוכל להוסיף הערות?", למה השתמשת בלולאת while ולא for? איפה הקוד שמטפל בתצוגה על מסכים קטנים של טלפון?
4. ואז יקרה הקסם הראשון ונתחיל לשים לב לבעיות אפילו לפני שהן קורות. "ראיתי שהגדלת את הטקסט של הכותרת, אבל מה קורה במובייל?", "אני רואה שאתה עושה פה משימה בשלבים, מה קורה אם אחד השלבים נכשל?", "רגע וזה יעבוד גם כשהמשתמש לא מחובר למערכת?".
5. ככל שנקרא יותר קוד והשיחה שלנו עם סוכן הקידוד תהפוך טכנית יותר כך נתחיל לבוא בבקשות - "תעביר את הפונקציה הזאת לקובץ נפרד", "תשנה את סדר הפעולות בקובץ", "הצג את הדיאלוג עם CSS ולא עם JavaScript".
6. עד שיום אחד, בשביל הכיף, תגידו לסוכן הקידוד "יודע מה את זה אני אכתוב". לא בגלל שה AI לא יכול, אלא רק בגלל שאתם יכולים.

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

📌 הזמנה לוובינר: איך לקבל קוד טוב יותר מהסוכן באמצעות שיטת שלושת השכבות

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

** שימו לב ** הוובינרים יחזרו להתקיים בימי חמישי אבל עוברים לשעה 15:00.

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

אנחנו רואים כלים ומודלים חדשים כל יום והרשתות מציפות אותנו ב FOMO: "אתה חייב לנסות את קלוד אופוס החדש", "קלוד קוד שינה לי את החיים" או "מה לא התקנת עדיין Cursor 2?". אבל לא משנה כמה אנחנו משדרגים את הכלים והמודלים איכות הקוד של המערכת לא משתפרת.

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

ספציפית אנחנו נראה בוובינר:

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

נפגש השבוע ביום חמישי בשעה 15:00. מוזמנים להצטרף בדף הוובינרים בקישור:

https://www.tocode.co.il/talking_ai

ואשלח לכם למייל את הלינק לזום.

📌 שינוי ההתנהגות המובנית ב JavaScript

גם גבור קוס ראה את הקוד הזה והרגיש בחילה:

const todoResponse = await client.get('/api/todos/1');
const todo = await todoResponse.json();

הבעיה? הוא לא צריך את todoResponse והגדיר אותו רק בשביל להפעיל עליו .json. יש כמה דרכים טבעיות ב JavaScript לוותר עליו, אבל אף אחת מהן לא עושה חשק. הראשונה היא להשתמש בשני await באותה שורה:

const todo = await (await client.get('/api/todos/1')).json();

ודרך שניה עם then:

const todo = await client.get('/api/todos/1').then(r => r.json());

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

const todo = await client.get('/api/todos/1').json()

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

✏ מה אנחנו מפסידים כשאנחנו משנים התנהגות

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

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

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

את גרסת שני ה await-ים אני לא אוהב, היא נראית לא טבעית, אבל לפחות אני מבין אותה במבט ראשון.

גרסת ה await הבודד היא הכי מבלבלת. בתור מפתח וותיק אני קורא את זה ולא מבין איפה ה then של ה get, ולמה מתיחסים ל Promise כמו לתוצאה שלה. אם הייתי מפתח חדש שלא מספיק מכיר JavaScript הייתי עלול לחשוב שאפשר להתנהג בצורה דומה גם עם פונקציות אחרות של Promises או עם Promises אחרים, וזו כמובן היתה טעות.

הבלבול רק מחריף כשאנחנו מנסים להשתמש בגרסה זו בהקשרים אחרים, לדוגמה:

const todoRequest = await client.get('/api/todos/1');
const todo = todoRequest.json();

במקרה הזה השורה השניה תחזיר Promise כי ה await שלה "נשכח" בשורה הראשונה. הדרך הנכונה לשבור את הקוד לשתי שורות היא דווקא לשים את ה await בשורה השניה ולקרוא ל json ישירות על ה Promise:

const todoRequestPromise = client.get('/api/todos/1');
const todo = await todoRequestPromise.json();

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

במקרה של fetch הרבה יותר קל ונכון להשתמש בכתיב ה then כדי לשרשר Promises וכך נלמד מבנה שיעזור לנו גם באתגרים דומים בעתיד. אם מתעקשים אפשר לכתוב פונקציה בשם אחר, למשל getJson שמפעילה את ה then ומחזירה Promise ל json.