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

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

האם Test Driven Development עדיין רלוונטי?

06/03/2026

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

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

האלטרנטיבה של TDD בה גם אני משתמש וגם אני רואה בתעשייה היא PDD, כלומר Prompt Driven Development. כותבים פרומפט, נותנים ל AI לייצר קוד ובדיקות, קוראים את הבדיקות והקוד, אם אוהבים שומרים ואם לא אוהבים מנקים ומתקנים את הפרומפט.

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

import pytest
import GameUI


def test_first_player_plays(game_logic):
    game_logic.play(0, 0)
    assert not game_logic.game_over()
    assert game_logic.winner() is None

def test_second_player_plays_in_taken_square(game_logic):
    game_logic.play(0, 0)

    with pytest.raises(Exception):
        game_logic.play(0, 0)

def test_player1_wins_first_row(game_logic):
    game_logic.play(0, 0)
    game_logic.play(1, 0)

    game_logic.play(0, 1)
    game_logic.play(1, 1)

    game_logic.play(0, 2)
    assert game_logic.game_over()
    assert game_logic.winner() == game_logic.players[0]

def test_player2_wins_diagonal(game_logic):
    game_logic.play(0, 1)
    game_logic.play(0, 0)

    game_logic.play(1, 0)
    game_logic.play(1, 1)

    game_logic.play(1, 2)
    game_logic.play(2, 2)
    assert game_logic.game_over()
    assert game_logic.winner() == game_logic.players[1]

def test_cant_play_after_win(game_logic):
    game_logic.play(0, 1)
    game_logic.play(0, 0)

    game_logic.play(1, 0)
    game_logic.play(1, 1)

    game_logic.play(1, 2)
    game_logic.play(2, 2)

    with pytest.raises(Exception):
        game_logic.play(2, 0)


def test_show_empty_board(game_logic, capsys):
    GameUI.print_current_game(game_logic)
    printed_text = capsys.readouterr().out
    assert printed_text == """Waiting for player X
. . .
. . .
. . .
"""

def test_show_board_after_play(game_logic, capsys):
    game_logic.play(0, 0)
    game_logic.play(1, 1)
    game_logic.play(2, 0)

    GameUI.print_current_game(game_logic)
    printed_text = capsys.readouterr().out
    assert printed_text == """Waiting for player O
X . .
. O .
X . .
"""

def test_show_draw(game_logic, capsys):
    game_logic.play(0, 0) # X
    game_logic.play(1, 1) # O

    game_logic.play(2, 0) # X
    game_logic.play(1, 0) # O

    game_logic.play(1, 2) # X
    game_logic.play(2, 1) # O

    game_logic.play(0, 1) # X
    game_logic.play(0, 2) # O

    game_logic.play(2, 2) # X

    GameUI.print_current_game(game_logic)
    printed_text = capsys.readouterr().out
    assert printed_text == """Game Over. It's a draw
X X O
O O X
X O X
"""

def test_show_player_1_won(game_logic, capsys):
    game_logic.play(0, 0)
    game_logic.play(1, 0)
    game_logic.play(0, 1)
    game_logic.play(1, 1)
    game_logic.play(0, 2)

    GameUI.print_current_game(game_logic)
    printed_text = capsys.readouterr().out
    assert printed_text == """Bravo! X Won
X X X
O O .
. . .
"""

def test_read_move_from_player(game_logic, monkeypatch, capsys):
    monkeypatch.setattr("builtins.input", lambda _: "0, 0")
    next_move = GameUI.read_next_move(game_logic)
    game_logic.play(*next_move)

    capsys.readouterr() # clear the buffer
    GameUI.print_current_game(game_logic)
    printed_after = capsys.readouterr().out
    assert printed_after == """Waiting for player O
X . .
. . .
. . .
"""

ואז בפרומפט מאוד פשוט מקבל את GameLogic שבדיוק מתאים לממשק שהגדרתי.

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

ההבדלים המרכזיים בין הגישות:

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

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

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

create a text based tic tac toe game in python with pytest. use uv
Use multiple modules for game logic and display
Implement pytest tests for both logic and display

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

def test_render_board_with_markers(self):
    board = Board()
    board.place_marker("A1", "X")
    board.place_marker("B2", "O")
    rendered = Display.render_board(board)
    assert "X" in rendered
    assert "O" in rendered

נראה ש glm עבד מאוד קשה רק בשביל לא להשתמש ב capsys של pytest והפך את קוד המשחק ליותר מסורבל.

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

סיכום וובינר מודלים פתוחים

05/03/2026

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

עכשיו בואו נזכר מה היה לנו בשבוע שעבר.

המשך קריאה

המעמד החברתי של המודל

04/03/2026

פרומפט-

create a vue component that takes a flat JSON object as "model" (just key/value and value has to be string) and provide an editable form for it

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

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

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

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

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

סקריפט חדש לכתיבה לטלגרם

03/03/2026

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

המשך קריאה

בעיות פתורות, בעיות חדשות ולמה לשים לב

02/03/2026

לקלאודפלייר היתה בעיה - כולם כתבו יישומים ב next.js ואת היישומים האלה אפשר היה להריץ בקלות על השרתים של ורסל. הבעיה? קלאודפלייר היא מתחרה של ורסל ורוצה גם לאפשר לאנשים להריץ יישומי next.js על השרתים שלה. אבל נקסט בנויה עם webpack ואצל קלאודפלייר יש תמיכה רק ב vite.

מה עושים? נותנים לקלוד (דרך אופןקוד) לבנות מחדש את החלקים של next.js שתלויים ב webpack הפעם עבור vite. הפיתוח לקח שבוע. הריפו מתחיל מגרסה בסיסית וכולל 90 קומיטים ואת כל התהליך ניהל מפתח יחיד בעלות 1,100$ בטוקנים של קלוד. סטיב פולקנר, המפתח שעבד על הפרויקט, כתב פוסט מאוד מפורט על התהליך.

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

  1. תיעוד אינסופי - כולם מכירים את next.js, מודלים מכירים אותו, יש אינסוף חומר ותיעוד רלוונטי.

  2. חבילת בדיקות מקיפה - הם לקחו את חבילת הבדיקות של next.js למימוש מחדש וכך היה ברור שבונים את הדבר הנכון.

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

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

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

ואז הגיע סטאק אוברפלו

01/03/2026

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

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

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

  1. קראו תשובה ודרכה הכירו את הכלים כדי לדעת איזה דפי תיעוד לקרוא.

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

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

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

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

https://overreacted.io/a-social-filesystem/

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

לפני רגע זה עבד

28/02/2026

אחת ההטיות המבלבלות של המוח האנושי היא ההרגשה שאפשר לתקן באותה מהירות שמשהו התקלקל.

לוקח דקה למחוק בסיס נתונים. במקרה הטוב להחזיר אותו מהגיבוי ייקח חצי יום.

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

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

לפני רגע הכל היה טוב. עכשיו יש בעיה. אלה שני משפטים נפרדים.

מדברים AI עונה 3

27/02/2026

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

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

נושא שני שנדבר עליו יהיה כתיבת סוכנים והוא כולל וובינר על OpenAI Agents SDK, על ChatKit של OpenAI שמאפשר להטמיע סוכן באתר שלנו, על dspy ואיך הוא עוזר לנו לארגן פרומפטים בתוך תוכנית וגם נראה איך לכתוב שרת MCP לסוכנים שלנו.

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

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

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

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

ניתוח פרומפט - הוספת וולידציה למסך

26/02/2026

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

זה היה הפרומפט:

plan the validation
extract the logic from <file:lines> and the validation in a
common concern so we can use it from the 3 relevant controllers (automation rules, advanced webhook and
macro)
verify frontend shows the correct proper error

המשך קריאה

שתי נקודות או שלוש נקודות ב git diff

25/02/2026

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

# 1. two dots diff
git diff dev..main

# 2. three dots diff
git diff dev...main

רואים את ההבדל? נכון זו רק נקודה.

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

  1. פקודת diff עם שתי נקודות תראה לי את ההבדל בין המצב העדכני ביותר בענף dev למצב העדכני ביותר בענף main.

  2. פקודת diff עם שלוש נקודות תראה לי את ההבדל בין המצב העדכני ביותר בענף dev לבין הקומיט ב main ממנו הוא יצא, כלומר בלי אותם קומיטים חדשים ב main שנכתבו אחרי שהתחלתי לכתוב את הפיצ'ר.

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