1.5 מתכונים שימושיים הרצאה

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

הסבר קוד לא מוכר

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

Explain the following code to me line by line. I know basic Python
but I'm not familiar with the asyncio library. Also explain why the
developer chose this approach instead of a simple synchronous
approach.

[paste the code here]

מה מקבלים: פירוק שורה-שורה, הסבר על asyncio ועל הסיבה הארכיטקטונית מאחורי הבחירה - לא רק "מה" אלא גם "למה".

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

למידת ספרייה חדשה

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

I know React but I've never worked with Zustand for state
management. I'm building a simple To-Do app. Explain the basic
ideas of Zustand compared to what I'd do with
useState/useContext, and give a minimal code example that manages
a list of tasks.

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

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

כתיבה והסבר של ביטויים רגולריים - regex

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

Write a regex in Python that identifies a valid email address,
including support for subdomains (like user@mail.company.co.il).
Explain each part of the expression on a separate line.

או בכיוון ההפוך, כשיש regex קיים שלא ברור:

Explain what the following regular expression does, part by part:
^(?=.*[A-Z])(?=.*[0-9]).{8,}$

מה מקבלים: לא רק את הביטוי אלא פירוק שלו - שימושי במיוחד כי regex הוא אחד התחומים שהכי קל לשכוח למה כתבתם משהו ככה.

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

כתיבת שאילתות SQL

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

I have two tables in PostgreSQL:
orders(id, customer_id, total, created_at)
customers(id, name, email, signup_date)

Write a query that returns, for every customer who signed up in
2025, their total order amount and number of orders - including
customers who haven't placed any order (with 0 in both fields).

מה מקבלים: שאילתה עם ה-JOIN הנכון (במקרה הזה LEFT JOIN כדי לכלול לקוחות בלי הזמנות), ולעיתים גם הסבר קצר על הבחירה.

המלכודת: המודל לא רואה את בסיס הנתונים האמיתי שלכם - הוא עובד לפי מה שתיארתם. אם שכחתם להזכיר אילוץ (למשל שהעמודה total יכולה להיות NULL), השאילתה עלולה להתנהג לא כמו שציפיתם. תמיד תרוצו על נתוני בדיקה לפני production, ואם יש קונבנציות ספציפיות (שמות עמודות, טיפוסים מדויקים), כדאי להדביק את סכימת הטבלה האמיתית (CREATE TABLE או פלט \d) במקום לתאר אותה במילים.

תרגום בין שפות תכנות

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

Convert the following Python code to idiomatic TypeScript (not a
literal translation - use patterns natural to TypeScript, including
appropriate types):

def group_by_category(items):
    result = {}
    for item in items:
        result.setdefault(item["category"], []).append(item)
    return result

מה מקבלים: לא רק תרגום שורה-לשורה, אלא קוד שמרגיש טבעי בשפת היעד - למשל שימוש ב-Map וטיפוסים גנריים ב-TypeScript במקום לחקות בדיוק את מבנה המילון של פייתון.

המלכודת: "תרגום מילולי מדי" הוא כשל נפוץ - קוד שעובד אבל לא מרגיש כמו קוד שמתכנת TypeScript מנוסה היה כותב. אם התוצאה נראית מוזרה, בקשו במפורש "תכתוב את זה כמו שמתכנת TypeScript מנוסה היה כותב, לא כתרגום מילה במילה". גם כדאי לבדוק הבדלי התנהגות עדינים בין שפות (למשל טיפול בערכי null/undefined, או סדר איטרציה על מבני נתונים).

דיבוג בשיטת הברווז הגומי - rubber duck

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

I'm trying to understand why this function returns a wrong result.
Help me go through its logic step by step, and ask me questions if
something isn't clear - don't give me the answer right away, let's
go through it together.

[paste the code and the unexpected behavior]

מה מקבלים: תהליך דיאלוגי - המודל שואל שאלות מכוונות ("מה קורה אם הרשימה ריקה?", "האם בדקת מה הערך של X בשלב הזה?") שעוזרות לכם למצוא את הבאג בעצמכם, במקום לקבל תיקון מיידי.

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

כתיבת הודעות commit ותיעוד

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

Write a commit message for the following change, in Conventional
Commits format.
The change: I added validation to the email field in the signup
form, and fixed a type error in a hook that caused a crash when the
user isn't logged in.

diff:
[paste the git diff output]

מה מקבלים: הודעת commit מפוצלת נכון (במקרה הזה כנראה שני commits נפרדים - feat ו-fix), בפורמט עקבי שקל לסרוק בהיסטוריה.

לתיעוד קוד, בקשה דומה עובדת היטב:

Write a docstring for the following function in Google style,
including a description of the arguments, the return value, and
exceptions it might raise.

[paste the function]

המלכודת: הודעת commit שנוצרה מ-diff בלבד (בלי context על למה בוצע השינוי) עלולה לתאר רק את השינוי הטכני ("שיניתי X ל-Y") בלי לתפוס את הכוונה העסקית מאחוריו. אם יש context חשוב שלא נראה מהקוד עצמו (למשל "זה תיקון לבאג שדווח על ידי לקוח"), הוסיפו אותו לפרומפט.

כתיבת בדיקות יחידה - unit tests

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

Write pytest unit tests for the following function. Cover a normal
case, boundary cases (empty list, single value), and invalid
input.

def calculate_discount(price: float, quantity: int) -> float:
    if quantity >= 10:
        return price * quantity * 0.8
    elif quantity >= 5:
        return price * quantity * 0.9
    return price * quantity

מה מקבלים: סט בדיקות שמכסה את הגבולות המדויקים של הלוגיקה (בדיקה ליד quantity=5 ו-quantity=10, לא רק "בתוך הטווח"), ולעיתים גם הצעה לבדיקות על קלט שלילי או לא צפוי (מחיר שלילי, כמות שלילית) שלא חשבתם עליהן.

המלכודת: בדיקות שנוצרות מהקוד עצמו (ולא מהדרישה המקורית) עלולות "לאשר" התנהגות שגויה במקום לתפוס אותה - אם הפונקציה עצמה מכילה באג, הבדיקה שנוצרת ממנה עלולה לצפות לאותה תוצאה שגויה. לכן חשוב לתת גם את הכוונה מאחורי הפונקציה, לא רק את הקוד: "הפונקציה אמורה לתת 20% הנחה מ-10 יחידות ומעלה" - כך המודל בודק מול הדרישה, לא רק מול המימוש.

המרת פורמטים של נתונים

המרה בין פורמטים (JSON, CSV, YAML, XML) היא משימה מכנית שקל לפשל בה ידנית (פסיקים חסרים, גרשיים לא תואמים) ומודל שפה עושה אותה במהירות.

Convert the following JSON to a CSV table. If there are nested
fields, flatten them using a dot as a separator (e.g. address.city).

{"name": "Dana", "age": 31, "address": {"city": "Tel Aviv", "zip": "6473000"}}
{"name": "Yossi", "age": 45, "address": {"city": "Haifa", "zip": "3303221"}}

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

המלכודת: על קבצים גדולים (מאות או אלפי רשומות), מודל שפה בצ'אט עלול לקצר, לדלג על שורות, או "לעייף" באמצע ולעצור מוקדם - במיוחד אם הקובץ ארוך מכדי להיכנס לחלון תשובה סביר. למשימות המרה על נפח גדול, עדיף להשתמש בagent (כמו Claude Code) שכותב סקריפט המרה אמיתי ומריץ אותו, במקום לבקש מהצ'אט "לעבד" את הנתונים ידנית שורה אחר שורה. תמיד בדקו שמספר הרשומות בפלט תואם למספר בקלט.

טבלת סיכום - מתי כל מתכון הכי שימושי

מתכון	הכי שימושי כש...
הסבר קוד לא מוכר	נכנסים לקודבייס חדש או קוד ישן בלי מסמכי הסבר
למידת ספרייה	מתחילים לעבוד עם כלי חדש ורוצים להתחיל מהר, לא מהתיעוד המלא
regex	צריך ביטוי מדויק וגם הבנה שתישאר איתכם לתחזוקה עתידית
SQL	יש מבנה טבלאות ברור ושאילתה מורכבת עם joins או אגרגציה
תרגום שפות	יש לוגיקה עובדת בשפה אחת וצריך אותה בשפה אחרת
ברווז גומי	הבאג עמיד וחשוב להבין את שורש הבעיה, לא רק לתקן
commit/תיעוד	יש diff או פונקציה מוכנים וחסר רק הניסוח
בדיקות יחידה	כותבים פונקציה חדשה ורוצים כיסוי שיטתי של מקרי קצה
המרת פורמטים	נתונים קטנים עד בינוניים בפורמט אחד שצריך בפורמט אחר

עקרון משותף לכל המתכונים

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

סיכום

• הסבר קוד: ציינו מה אתם כבר יודעים, כדי לקבל הסבר ברמה הנכונה ולא כללי מדי.
• למידת ספרייה חדשה: מפו למושגים שאתם כבר מכירים, ותבדקו מול תיעוד עדכני - המודל עלול לזכור גרסה ישנה.
• regex: בקשו פירוק חלק-אחר-חלק ובדקו על דוגמאות תקינות ולא תקינות כדי לתפוס מקרי קצה.
• SQL: הדביקו את סכימת הטבלה האמיתית במקום לתאר אותה, ובדקו על נתוני בדיקה לפני production.
• תרגום בין שפות תכנות: בקשו קוד אידיומטי לשפת היעד, לא תרגום מילולי, ובדקו הבדלי התנהגות עדינים.
• ברווז גומי - rubber duck: בקשו מהמודל לשאול שאלות ולא לקפוץ לפתרון, כדי להבין את שורש הבאג.
• הודעות commit ותיעוד: תנו context על למה בוצע השינוי, לא רק diff גולמי.
• בדיקות יחידה: תנו את הכוונה מאחורי הפונקציה, לא רק את הקוד - אחרת בדיקה שנוצרת מהמימוש עלולה לאשר באג קיים במקום לתפוס אותו.
• המרת פורמטים: לנפח קטן זה עובד מצוין בצ'אט; לנפח גדול עדיף agent שכותב וממריץ סקריפט המרה אמיתי.
• העיקרון המשותף לכל המתכונים: הcontext קונקרטי, אילוץ ברור, ולעיתים דוגמה - אותה היוריסטיקה מהרצאות הקודמות, מיושמת על משימות יומיומיות.