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

טיפים קצרים וחדשות למתכנתים

היום למדתי: פקודת browser ב next.js

07/09/2026

כשלמדתי next.js לקח לי זמן להבין שכשאני כותב use client בתחילת קובץ הכוונה שלהם היא שהקוד ירוץ גם ב client וגם ב server, ולא רק ב client כמו שאולי היה אפשר להבין מהשם.

למעשה בעבודה עם ריאקט ו next הרצת קוד רק בדפדפן תמיד היתה קצת מסורבלת. הנה מה שקלוד הדפיס כשביקשתי ממנו לכתוב קומפוננטה ל next שקוראת ערך ששמור ב local storage ומדפיסה אותו:

'use client';

import { useEffect, useState } from 'react';

export default function StoredValue({ storageKey = 'username', fallback = 'Not set' }) {
  // null means "haven't read storage yet" — distinct from an empty stored value
  const [value, setValue] = useState(null);

  useEffect(() => {
    try {
      setValue(localStorage.getItem(storageKey) ?? fallback);
    } catch {
      // Storage can throw in private mode or when disabled
      setValue(fallback);
    }
  }, [storageKey, fallback]);

  if (value === null) return <p>Loading…</p>;

  return <p>{value}</p>;
}

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

לאחרונה next הוסיפו מנגנון חמוד בשם browser: https://react.dev/reference/react-dom/browser

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

'use client';

import { use, useState } from 'react';
import { browser } from 'react-dom';

export default function StoredValue({ storageKey = 'username', fallback = 'Not set' }) {
  use(browser('The value is stored in localStorage.'));

  const [value] = useState(() => localStorage.getItem(storageKey) ?? fallback);

  return <p>{value}</p>;
}

המלכודת היחידה בעדכון היא לכתוב את הקומפוננטה רק בתוך Suspense Boundary כלומר:

import { Suspense } from 'react';
import StoredValue from './StoredValue';

export default function Page() {
  return (
    <Suspense fallback={<p>Loading…</p>}>
      <StoredValue />
    </Suspense>
  );
}

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

הכח של next הוא כבר לא במימוש

06/09/2026

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

זה הפוסט שהוא כתב לסכם את הניסוי: https://maxleiter.com/blog/thank-u-next

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

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

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

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

למה ואיך להקים מכונת פיתוח בענן לפיתוח ווב

05/09/2026

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

המשך קריאה

מה מאט אותך ב Code Review

04/09/2026

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

לקרוא כל שורת קוד ייקח נצח.

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

מה עושים? משלבים:

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

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

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

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

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

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

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

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

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

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

הקוד שאני הייתי כותב

03/09/2026

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

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

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

איך זה קורה?

אפשר לספר על דיוק פרומפטים ו Context Engineering. אפשר לספר על סדר פעולות ואם צריך קודם לעבוד במצב תכנון ואז לממש. אפשר לדבר על MCP ו Skills ופלאגינים.

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

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

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

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

קלישאות של AI שמצאתי בטקסטים שאני כתבתי

02/09/2026

אם אתם כותבים כדאי לנסות את הכלי הזה:

https://tools.simonwillison.net/llm-cliche-highlighter

הוא מרכז 38 תבניות כתיבה אופייניות ל AI ויכול למצוא אותן בטקסטים שאתם כותבים. בין התבניות שמצאתי בטקסטים שלי שממש מתאימות ל AI הכלי זיהה:

  1. שימוש ברצף של שאלות רטוריות.

  2. נקודותיים ואז שלושה פריטים.

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

  4. משפט חיובי ואחריו מה שלא הצליח (לדוגמה Reading mostly passed … Writing didn’t)

  5. שרשראות של no לדוגמה No fluff, no filler, no jargon

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

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

  1. טיפול במקרי קצה שאי אפשר להגיע אליהם (על חשבון מקרי הקצה האמיתיים שלא טופלו).

  2. כתיבת המון בדיקות יותר מדי ספציפיות.

  3. כפל קוד.

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

  5. כתיבת הערות בהגזמה במקום קוד קריא.

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

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

טעויות שלא רואים

01/09/2026

טעות בפרומפט גרמה לסוכן לעלות מ 10% שגיאות ל 30%.

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

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

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

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

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

מה בעצם הבעיה שם?

31/08/2026

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

"מה בעצם הבעיה?"

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

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

אבל זאת לא ההשוואה הנכונה.

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

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

לא מיועד לקריאה על ידי בני אדם

30/08/2026

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

  1. בפרויקט יש תיקיית _components ולידה תיקייה בשם components. כן הבנתי שאתם משתמשים ב shadcn אבל האילוצים הטכניים הם בחירה שלכם.

  2. הפרויקט מכיל 3 תיקיות עזר נסתרות: .vercel, .next ו .eve.

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

  4. גישה ל Sessions מבוצעת דרך נתיב בשם s. כן רק האות s ואחריה מזהה ה Session.

הנה DHH מתוך הדוקטרינה של ריילס בשביל השוואה:

We write code not just to be understood by the computer or other programmers, but to bask in the warm glow of beauty. Aesthetically pleasing code is a value unto itself and should be pursued with vigor. That doesn’t mean that beautiful code always trumps other concerns, but it should have a full seat at the table of priorities.

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

class Project < ApplicationRecord
  belongs_to :account
  has_many :participants, class_name: 'Person'
  validates_presence_of :name
end

מעט שורות, הרבה משמעות ונקרא כשפה טבעית.

בפרויקט eve החדש זה התוכן של page.tsx:

import { AgentChat } from "@/app/_components/agent-chat";

export default function Page() {
  return <AgentChat />;
}

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

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

from pydantic_ai import Agent

agent = Agent('openai:gpt-5.2', instructions='You are a helpful assistant.')
app = agent.to_web()

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

ההבדל בין שיפור לאופטימיזציה

29/08/2026

אלה שני מושגים שאנחנו הרבה פעמים מבלבלים.

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

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

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