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

את הבלוק הבא ראיתי בקוד קטן ש AI יצר:

useEffect(() => {
  getWaitlistCount().then((count) => setWaitlistCount(count + 100))
}, [])

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

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

1. הוא גורם להצגה של מידע שגוי כשהעמוד רק עולה.

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

3. הוא מאט את זמן הרינדור בקלאיינט ומכריח את הקלאיינט להריץ JavaScript אפילו שאפשר היה להתספק רק ב HTML/CSS וקומפוננטת צד שרת.

שתי אפשרויות טובות יותר יהיו למשוך את המידע בקומפוננטת צד שרת לפני שטוענים את העמוד או למשוך את המידע מהשרת ולהוסיף אותו לעמוד ב Streaming. שניהם נתמכים בצורה מובנית ב next.

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

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

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

Modify useEffect(() => { getWaitlistCount().then((count) => setWaitlistCount(count + 100)) }, []) to improve performance by moving the code to run on the server in the request handling phase and stream the response to the client by passing a promise to use. Use the result as the initial value to useState

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

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

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

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

את הקוד הבא כתבתי בטעות ואני מודה שהתוצאה הפתיעה אותי:

const data = await fetch('https://api.vercel.app/blog', {
    cache: 'no-store',
    next: {
        revalidate: 60
    }
})

הקוד עבד בפיתוח אבל גרם ל build להיתקע. בואו נבין מה קורה פה.

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

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

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

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

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

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

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

מה זה אומר עלינו, על המוטיבציה ללמוד ועל העתיד? כמה מחשבות:

1. כל מי שלמד כלים רק בשביל "לגרום לדברים לעבוד" עובר או יעבור ל AI.

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

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

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

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

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

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

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

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

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

import { open } from "node:fs/promises";

const getFileHandle = async (path: string) => {
  const fh = await open(path, "w");

  return {
    fh,
    [Symbol.asyncDispose]: async () => {
      await fh.close();
    },
  };
};

הפונקציה פותחת קובץ ומחזירה גם את הקובץ וגם את פונקציית הסגירה באוביקט אחד, כשפונקציית הסגירה נשמרת במפתח Symbol.dispose או אם היא אסינכרונית כמו בדוגמה זה יהיה Symbol.asyncDispose.

במקום אחר בקוד אנחנו יוצרים את המשאב עם המילה החדשה using:

{
  await using file = await getFileHandle("thefile.txt");
  const { fh } = file;
  fh.write('hello world');
}

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

var __addDisposableResource = (this && this.__addDisposableResource) || function (env, value, async) {
    if (value !== null && value !== void 0) {
        if (typeof value !== "object" && typeof value !== "function") throw new TypeError("Object expected.");
        var dispose, inner;
        if (async) {
            if (!Symbol.asyncDispose) throw new TypeError("Symbol.asyncDispose is not defined.");
            dispose = value[Symbol.asyncDispose];
        }
        if (dispose === void 0) {
            if (!Symbol.dispose) throw new TypeError("Symbol.dispose is not defined.");
            dispose = value[Symbol.dispose];
            if (async) inner = dispose;
        }
        if (typeof dispose !== "function") throw new TypeError("Object not disposable.");
        if (inner) dispose = function() { try { inner.call(this); } catch (e) { return Promise.reject(e); } };
        env.stack.push({ value: value, dispose: dispose, async: async });
    }
    else if (async) {
        env.stack.push({ async: true });
    }
    return value;
};
var __disposeResources = (this && this.__disposeResources) || (function (SuppressedError) {
    return function (env) {
        function fail(e) {
            env.error = env.hasError ? new SuppressedError(e, env.error, "An error was suppressed during disposal.") : e;
            env.hasError = true;
        }
        var r, s = 0;
        function next() {
            while (r = env.stack.pop()) {
                try {
                    if (!r.async && s === 1) return s = 0, env.stack.push(r), Promise.resolve().then(next);
                    if (r.dispose) {
                        var result = r.dispose.call(r.value);
                        if (r.async) return s |= 2, Promise.resolve(result).then(next, function(e) { fail(e); return next(); });
                    }
                    else s |= 1;
                }
                catch (e) {
                    fail(e);
                }
            }
            if (s === 1) return env.hasError ? Promise.reject(env.error) : Promise.resolve();
            if (env.hasError) throw env.error;
        }
        return next();
    };
})(typeof SuppressedError === "function" ? SuppressedError : function (error, suppressed, message) {
    var e = new Error(message);
    return e.name = "SuppressedError", e.error = error, e.suppressed = suppressed, e;
});
import { open } from "node:fs/promises";
const getFileHandle = async (path) => {
    const fh = await open(path, "w");
    return {
        fh,
        [Symbol.asyncDispose]: async () => {
            await fh.close();
        },
    };
};
{
    const env_1 = { stack: [], error: void 0, hasError: false };
    try {
        const file = __addDisposableResource(env_1, await getFileHandle("thefile.txt"), true);
        const { fh } = file;
        fh.write('hello world');
    }
    catch (e_1) {
        env_1.error = e_1;
        env_1.hasError = true;
    }
    finally {
        const result_1 = __disposeResources(env_1);
        if (result_1)
            await result_1;
    }
} // Automatically disposed!

ולמה אני מספר לכם את כל זה עכשיו? הסיבה פשוטה ובכותרת. הפיצ'ר הגיעה השבוע ל node.js ותוכלו להשתמש בו גם בלי טייפסקריפט עם node 24. אני חושב שיש פה מדיניות של node.js לתמוך בטייפסקריפט בלי לקמפל לטייפסקריפט - מדיניות שהתחילה עם מנגנון ה strip types שלהם וממשיכה עם טיפול בפקודות הטייפסקריפט שלא קשורות רק לטיפוסים. עכשיו נשאר לחכות ל enum.

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

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

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

3. זמן לימוד - רוב הזמן אני מבין את הקוד של ה AI אבל לפעמים הוא משתמש בתבניות או יכולות שלא הכרתי, לדוגמה בקוד JavaScript היה שימוש ב Passive Event Listeners שלא הכרתי והייתי צריך להשלים פערים.

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

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

ריאקט היא דוגמה לספריה שיכולה להתאים לכל חור:

1. היא רצה בצד לקוח ובונה DOM

2. היא רצה בצד שרת ובונה מחרוזת HTML

3. אפשר לחבר אותה לקומפוננטות של Mobile ולקבל אפליקציות.

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

5. אפשר לבנות איתה יישומי Text UI.

6. אפשר לבנות איתה Prompt-ים ל AI (כן הפרומפט של קרסר נבנה בצורה דינמית בכתיב JSX).

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

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

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

1. כלים ספציפיים נותנים לנו הבנה טובה יותר של תפיסת העולם עבורה הם נוצרו. היכרות עם סטימולוס (או htmx שמקביל לו) תלמד אתכם לעבוד טוב יותר עם מערכות Rails ו Django וקוד הפרונט אנד שלהן.

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

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

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

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

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

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

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

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

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

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

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

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

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

מתי נראה את ה Digital Ocean הראשונה למודלי קוד פתוח? ואיזה קפיצה טכנולוגית עוד צריך כדי להגיע לשם?