📌 קידוד עם AI משנה את סדר העבודה (וזה חלק מהקושי)

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

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

אחרי שעברתי על הקוד ראיתי שקלוד יצר קובץ צד שרת חדש לטיפול באותם שיעורי חזרה אישיים. זה הקובץ החדש:

https://github.com/ynonp/langlets-rails/blob/main/app/controllers/review_lessons_controller.rb

וזה הקובץ המקורי שטיפל במשתמשים שפשוט תרגלו את השיעור:

https://github.com/ynonp/langlets-rails/blob/main/app/controllers/lessons_controller.rb

וקל לראות שיש המון קוד משותף בין שני הקבצים האלה.

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

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

1. תאר מה עושה קובץ א
2. תאר מה עושה קובץ ב
3. הסבר מהם כל התהליכים שמבוצעים בפונקציה X בקובץ א ובקובץ ב, ואיזה מהם משותפים לשני הקבצים?
4. סדר מחדש את הקוד של פונקציה X ופצל אותו לפונקציות קטנות יותר כדי שנוכל לראות מה התפקיד של כל חלק

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

📌 ומי יפתח את הריאקט הבא?

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

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

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

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

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

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

אני חושב שיש פה 3 תשובות אפשריות:

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

ועוד מילה על העתיד 😂
https://notes.zachmanson.com/copilot-edited-an-ad-into-my-pr/

בסיפור פה שמשום מה טלגרם לא מציג את התקציר שלו
קופיילוט הוסיף פרסומת ל raycast בתוך הודעת הקומיט

📌 כל יצרן והסקילז שלו

למינימקס יש ריפו של סקילז למודל שלהם:
https://github.com/MiniMax-AI/skills

זה של אנטרופיק:
https://github.com/anthropics/skills

זה של OpenAI:
https://github.com/openai/skills

וכמובן של Gemini:
https://github.com/google-gemini/gemini-skills

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

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

Copy

1. Write in product language, not design commentary.
2. Let the headline carry the meaning.
3. Supporting copy should usually be one short sentence.
4. Cut repetition between sections.
5. Do not include prompt language or design commentary into the UI.
6. Give every section one responsibility: explain, prove, deepen, or convert.

If deleting 30 percent of the copy improves the page, keep deleting.

לעומתם אנטרופיק מתארים לנו פרומפט הרבה יותר פתוח ויצירתי:

Design Thinking

Purpose: What problem does this interface solve? Who uses it?
Tone: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
Constraints: Technical requirements (framework, performance, accessibility).
Differentiation: What makes this UNFORGETTABLE? What's the one thing someone will remember?

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

ככל שהמודלים משתפרים והפערים ביניהם הולכים וקטנים אנחנו נראה יותר עבודת התאמה באקוסיסטם - סקילז, אימון לשימוש בכלים מסוימים, גישה בלעדית ל APIs מסוימים (ג'מיני כבר עושים את זה עם היכולת הבלעדית שלהם לקרוא סרטים מיוטיוב). וככל שהדגש עובר לאקוסיסטם כך נראה יותר אפשרויות ושילובים מעניינים, כמו היכולת לחבר סקיל של אנטרופיק למודל פתוח של מינימקס ולהריץ אותו בתוך סוכן הקידוד של OpenAI.

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

📌 לא הכי חדש

עוד לא הספקנו להתאושש מהגרסאות המזויפות של LiteLLM וכבר התפרסם שגם axios נפרצו וגרסאות זדוניות עלו ל npm. אם בטעות תתקינו את אקסיוס 1.14.1 או 0.30.4 סקריפט שרץ אחרי התקנה יכניס סוס טרויאני שישתלט מרחוק על המחשב שלכם.

מאחר והגרסאות הזדוניות האלה לרוב מתגלות מהר הבעיה היא בעיקר של אנשים שמפעילים npm install axios בדיוק באותם יום או יומיים שהגרסה המזויפת היא החדשה ביותר על npm. מה עושים? אפשר לבדוק כל פעם ב npm מה הגרסה העדכנית, מה השינויים שהיא מביאה וכמה זמן היא באוויר ולבחור לבד גרסה אחת יותר ישנה. אפשר גם לזכור שכלי ניהול חבילות רבים מגיעים עם מנגנון Cooldown מובנה שימנע התקנת גרסאות חדשות מדי.

ב npm נוכל להשתמש בו באמצעות הפקודות הבאות בקובץ ~/.npmrc:

min-release-age=7 # days

הרבה אנשים מוסיפים גם את הפקודה:

ignore-scripts=true

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

בפייתון אין לנו עדיין פתרון מובנה ב pip אבל אם אתם משתמשים ב uv תוכלו להוסיף לקובץ ~/.config/uv/uv.toml את הפקודה:

exclude-newer = "7 days"

כדי ש uv יתעלם מחבילות שעוד לא ישבו בריפו שבוע להתייבש.

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

📌 טיפ הנדסת פרומפטים: עדיף להשתמש במה שהמודל מכיר

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

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

1. **Audio Analysis**: You need to actually listen to the audio and not rely only on the existing youtube captions. YouTube transcriptions can be inaccurate and is not suitable for our requirements.

2. **Language Focus**: The provided content might include text in other languages in the beginning or the end (before or after the actual content). Only extract the main video in the clip language. You can ignore prefix or suffix if they're in another language.

3. **Phrase Segmentation Rules**:
   - **Mandatory splits**: Always split before coordinating conjunctions (and, but, or, so)
   - Split at clause boundaries (before subordinating conjunctions, after complete thoughts)
   - Keep grammatically linked words together (modal + verb, adjective + noun, etc.)
   - Target 4-7 words per phrase for optimal memorization
   - Each phrase should demonstrate one primary grammatical concept
   - Break at natural pauses that would occur in speech

אבל לא משנה מה עשיתי תמיד היו מדי פעם פספוסים.

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

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

📌 זהירות: תפיסת חריג מבלוק ברובי

הקוד הבא ברובי זורק Exception מתוך הלולאה ותופס אותה, וקל לראות שזה עובד:

begin
  [1, 2, 3].each do |i|
    raise 'Stop' if i.even?
  end
rescue => e
  puts "Error: #{e.message}"
end

אבל חשוב לא להתבלבל, המבנה של rescue אחרי בלוק לא מבטיח שכל Exception שייזרק מהבלוק באמת ייתפס. הדוגמה הקלאסית היא קוד שנשלח להרצה ב Thread נפרד, וזה נראה ככה:

class Array
  def pmap(&block)
    each do |i|
      Thread.new { block.call(i) }
    end
    self
  end
end

begin
  [1, 2, 3].pmap do |i|
    raise 'Stop' if i.even?
  end
rescue => e
  puts "Error: #{e.message}"
end

פונקציית pmap שהגדרתי על Array שולחת את הבלוק לרוץ ב thread נפרד ולכן ה Exception שהבלוק זורק לא נתפס ב Thread הראשי. דרך אחת לטפל בקוד כזה היא להקפיד להעביר את ה Exception ל Thread הראשי מתוך pmap, כלומר:

class Array
  def pmap(&block)
    threads = each.map do |i|
      Thread.new do
        block.call(i)
      end
    end

    threads.each(&:join)
    threads.each(&:value)
  end
end

והפעם הפעלה תדפיס את השגיאה:

#<Thread:0x000000012233cbd8 a.rb:4 run> terminated with exception (report_on_exception is true):
a.rb:15:in `block in <main>': Stop (RuntimeError)
        from a.rb:5:in `block (2 levels) in pmap'
Error: Stop

📌 סיכום שנה ראשונה של langlets

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

✏ מה זה לנגלטס

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

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

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

✏ מה עובד

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

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

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

התחלתי להכניס למערכת שירים בצרפתית, ספרדית וערבית ואתם יכולים למצוא אותם בדף הראשי של האתר ולאחרונה עברתי להוסיף סדרות רשת קצרות, בערבית שמתי 10 קליפים מתוך حياة عيلتنا (סדרת רשת מצוירת ירדנית), בצרפתית 13 קטעים מתוך הסדרה bref (מהירה, הרבה סלנג, לא היה קל לשכנע את ה AI לשתף פעולה) ובספרדית 5 ספורי ילדים.

✏ מה התוכניות להמשך

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

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

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

✏ רוצים לעזור? אתם מוזמנים

לנגלטס הוא פרויקט קוד פתוח. אם יש לכם רעיונות לשיפור או סתם רוצים לראות איך זה עובד אפשר למצוא את הקוד בגיטהאב בקישור הזה:
https://github.com/ynonp/langlets-rails

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