הבלוג של ינון פרק

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

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

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

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

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

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

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

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

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

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

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

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

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

הקוד הבא ברובי זורק 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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. נגלה בינה מלאכותית חכמה יותר מ LLM-ים והיא תמציא את הדור הבא של שפות תכנות.

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