ToCode

📌 לזרוק או לשמור (קוד בינוני של AI) אחת השאלות שחזרו בוובינר על שיפור הקוד שאנחנו מקבלים מסוכני AI היתה מה עושים כשמזהים שהקוד שאותו סוכן יצר לא היה מספיק טוב. אופציית ה"לשמור" היא להמשיך עוד איטרציות מול ה AI כדי לסדר את זה. באופציית ה"לזרוק" אנחנו מנקים את כל השינויים, מתקנים את הפרומפט ומג'נרטים מחדש את הקוד בתקווה שהפעם זה יהיה טוב יותר. בעזרת שיטת שלושת השכבות נראה שרוב הזמן התשובה ברורה. אנחנו יודעים שקוד ש AI מייצר מושפע משלוש שכבות של מידע: 1. שכבת ההוראות - שזה הדברים שאנחנו כותבים בשפה טבעית. 2. שכבת הקוד - שזה הדברים שהסוכן מוצא במערכת שלנו, בקוד הקיים. 3. שכבת הווריפיקציה - אלה הפרטים שהסוכן מקבל מכלים חיצוניים אחרי כתיבת הקוד, למשל מה רואים בדפדפן, מה תוצאות הבדיקות ומה אומרים כלי ניתוח הקוד האוטומטיים. אז איך יודעים אם לזרוק או לשמור? מסתכלים באיזו שכבה היתה הבעיה. לפעמים המודל כותב קוד אחר ממה שרציתם כי הוא לא הבין דברים בסיסיים באיך המערכת עובדת או ברצונות שלכם מהקוד. לדוגמה אתם רציתם קוד לשימוש חוזר עם אבסטרקציות וחלוקה נכונה לקומפוננטות אבל המודל חשב שהוא צריך לתת לכם פתרון מהיר ועם הכי מעט שינויים בקוד קיים. במצב כזה הבעיה היא בשכבת ההוראות, ואז ברור שעלינו למחוק את כל הקוד שנכתב, לכתוב את ההוראות מחדש בצורה מדויקת יותר ולתת לו לרוץ שוב. מאוד קשה לתקן קוד שהתחיל מנקודת מוצא שגויה. לפעמים המודל מנסה לכתוב את הקוד שרציתם אבל זה לא יוצא. הוא משתמש לא נכון בדוגמאות ב Codebase או משתמש בדוגמאות הקיימות ולא מצליח לצאת מהן כדי לבנות אבסטרקציה חדשה. דוגמה קטנה שהראיתי בוובינר היא הנסיון המגושם הזה של אופוס לתקן קוד JavaScript:

export const setAuthCredentials = response => {
  const expiryDate = getHeaderExpiry(response);
  const now = new Date();
  const diffMs = expiryDate.getTime() - now.getTime();
  const diffDays = diffMs / (1000 * 60 * 60 * 24);
  Cookies.set('cw_d_session_info', JSON.stringify(response.headers), {
    expires: diffDays > 0 ? diffDays : 1, // fallback to 1 day minimum
  });
  setUser(response.data.data);
};

ולמה זה מגושם? כי expiryDate הוא תאריך ו expires יכול לקבל או ערך מסוג תאריך או ערך מספרי שמייצג מספר ימים. מה עושה אופוס? הופך את התאריך לערך מספר (שמייצג מספר ימים) רק בשביל להעביר אותו ל expires של Cookies.set, בלי לשים לב שבתוך Cookies.set הערך הזה יומר חזרה מימים לתאריך. הוא בהחלט שם לב לבאג, הוא בהחלט ניסה לתקן אותו בהתבסס על הקוד במערכת תוך שמירה על המבנה, אבל פשוט לא הצליח. אולי אם החתימה של Cookies.set היתה טובה יותר או היה ברור יותר מהקוד שאפשר להעביר שם תאריך זה כן היה מצליח לו. גם במצב כזה אני ממליץ לזרוק את הקוד ולייצר מחדש, אחרי שמתקנים את הקוד או ההוראות כדי להבהיר למודל מה הפתרון הרצוי. אפילו בדוגמה הקטנה שהדבקתי כאן, שברור שהרבה יותר קל לתקן את הפונקציה מאשר לייצר קוד מחדש, אני חושב שעדיף לתקן את הקוד שמסביב (במקרה הזה להוסיף Unit Test שמעביר ערך תאריך בתור expires למשל), ואז לייצר את הקוד מחדש. כך אנחנו מחזקים את המערכת והופכים אותה לקלה יותר עבור סוכני קידוד בעתיד. המקרה האחרון הוא בעיות בשכבת הווריפיקציה. כאן יש לנו קוד שנראה ממש סבבה, הוא גם תואם להוראות והוא גם כתוב מדויק אבל יש רק בעיה אחת - הוא לא עובד או לא עובד מספיק טוב. זה יכול להיות שהעמוד לא נטען, או שהעמוד נטען לאט מדי, או שיוצר יותר מדי עומס על בסיס הנתונים או כל דבר שאפשר לזהות אותו בקלות רק דרך כניסה לעמוד, בדיקת הלוגים והרצת כלים אוטומטיים. כשיש בעיות בשכבת הווריפיקציה אין טעם לייצר את כל הקוד מחדש, הקוד כבר טוב. יותר קל לתת לקלוד קוד כלי אוטומטי איתו הוא יוכל לראות את הבעיה ולשלוח אותו לדרכו כדי לסדר. בסוף התהליך נקרא שוב את הקוד, ואם אנחנו עדיין מרוצים נוכל למזג.

📌 איך ללמוד Design Patterns היום בספר המפורסם Design Patterns של GoF יושבים 4 חכמים ומציגים תבניות עיצוב שהם מצאו במערכות תוכנה שראו. הספר פורסם ב 1994 ולכן ברור למה המימושים שהוצגו שם מורכבים מקטעי קוד קטנים ומספרים רק חלק מהסיפור. ב 1994 אי אפשר היה לשתף מערכת מלאה ולתת דוגמאות ממנה. הנחת העבודה שלהם היתה שהאנשים שקוראים את הספר מכירים את הבעיות ממערכות גדולות שלהם ומתעניינים בבניית הפתרונות. זה מזמן לא המצב. כמות הקוד הפתוח שיש לנו באינטרנט והיכולת לגשת לכל ריפו עם AI הם המפתח ללימוד יעיל של Design Patterns. לא במובן של להכיר איך בנוי Singleton, אלא במובן של להבין איפה אנשים אמיתיים משתמשים בתבנית זו. נסו את הפרומפט הבא ב Gemini:

explain the singleton design pattern in python

1. what problem does it try to solve
2. what are some different implementations (variants) of the pattern?
3. provide examples for real world usages of the pattern in existing python open source libraries

וג'מיני ישמח להראות לכם קוד אמיתי מתוך Django, tornado, kivy ואפילו מתוך הספריה הסטנדרטית של פייתון שמשתמש ב Singleton וגם יסביר וירחיב למה הם בחרו בתבנית זו. המשיכו בשיחה ונסו להציע פתרונות אחרים לבעיה ומימושים שלכם ובקשו מ Gemini פידבק על ההצעות שלכם. ברור שבעידן ה AI לא אכפת לכם איך לממש סינגלטון או Event Bus בפייתון. כן צריך להיות לכם אכפת איך הקוד נראה, איזה בעיה התבנית פותרת ואיך שימוש בתבנית גורם לקוד להיראות. במקום "אני יודע לכתוב סינגלטון" אמרו "אני יודע לזהות סינגלטון כשאני רואה אותו, או לזהות שהוא חסר כשאני לא רואה אותו".

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

query = <<~END
  SELECT name, email
  FROM users
  WHERE active = true
END

puts query

מדפיס:

SELECT name, email
FROM users
WHERE active = true

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

query = """
  SELECT name, email
  FROM users
  WHERE active = true
""".strip()

print(query)

מדפיס את זה:

SELECT name, email
  FROM users
  WHERE active = true

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

import textwrap

query = textwrap.dedent("""
  SELECT name, email
  FROM users
  WHERE active = true
""").strip()

print(query)

והתוצאה:

SELECT name, email
FROM users
WHERE active = true

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

query = d"""
  SELECT name, email
  FROM users
  WHERE active = true
  """

print(query)

ולקבל את אותו פלט. לפי התיעוד הם מורידים את האינדנטציה המשותפת לכל השורות כולל שורת הסיום (עם השלושה סימני מרכאות האחרונה) אבל לא כולל שורת הפתיחה ושורות ריקות - כך שכל עוד נקפיד שהשורה האחרונה תקבל את אותה אינדנטציה כמו כל הבלוק דברים אמורים לעבוד בסדר. ב PEP תוכלו למצוא עוד המון דוגמאות מה יעבור ומה לא יעבוד עם הכתיב החדש: https://peps.python.org/pep-0822/

📌 לא ממזגים קוד גרוע אם שמתם מדיח, הסבון לא התמוסס והכלים יצאו מלוכלים, אתם תחזירו לארון ותתנהגו כאילו זה סבבה לאכול מכלים מלוכלכים? או תעשו כאילו אתם לא רואים שהכלים מלוכלכים? או תסבירו לעצמכם שעד שתצטרכו לאכול מהם מישהו כבר ימציא מדיח יותר טוב שינקה אותם כשהם בארון? או תזכרו בפעם ההיא ששטפתם כלים ביד וגם הם לא יצאו הכי נקיים אז מה כבר יש לצפות ממדיח? או אולי תסבירו לאורחים שרוב הזמן הכלים יוצאים אחלה ורק היום המדיח קצת התעייף? ברור שלא. וכמו שלא מחזירים כלים מלוכלכים לארון כך לא נמזג קוד גרוע. גם אם קלוד עבד ממש קשה לכתוב אותו. גם אם ממש השקעתי בפרומפט. גם אם זה בגדול בסדר, וממילא גם מתכנתים אנושיים לא כותבים מושלם. גם אם זה עובד. קוד גרוע הרבה יותר מסוכן מכלים מלוכלכים. קוד גרוע יישאר אתנו לכל החיים. הוא ייכנס לקונטקסט ויהפוך לבסיס לכל פיצ'ר חדש שה AI יכתוב. הוא ישאיר אותנו ערים בלילות לחפש את מקרי הקצה שגרמו לו להישבר. ולא, אל תבנו על קלוד שיציל אתכם ברעי המשבר האלה. כשהקוד הגרוע מצטבר לכדור ענק של בוץ גם קלוד לא מצליח לפרק אותו. ככל שאנחנו כותבים פחות קוד אבל מייצרים אוטומטית יותר ממנו, כך גדל הפיתוי והלחץ למזג גם קוד לא מושלם ואפילו לדלג לגמרי על קריאת הקוד ולהסתפק בבדיקת UI מהירה. שלושת המחלות של קוד AI שלא ניתן לראות בבדיקות UI הן: 1. קוד משוכפל שחוזר על עצמו. 2. קוד שמפספס את התמונה הגדולה ולכן מפספס מקרי קצה חשובים. 3. קוד מנופח שמטפל בדברים לא קיימים או שלא צריך לטפל בהם. בוובינר השבוע אראה לכם איך לזהות קוד גרוע, מה גורם לקלוד ליצור כזה קוד והכי חשוב איך לשפר את איכות הקוד שאנחנו מקבלים לאורך זמן. הטיפ הכי חשוב בשביל לקבל קוד טוב יותר לאורך זמן הוא בדיוק הכותרת - "לא ממזגים קוד גרוע".

📌 שינוי ההתנהגות המובנית ב JavaScript גם גבור קוס ראה את הקוד הזה והרגיש בחילה:

const todoResponse = await client.get('/api/todos/1');
const todo = await todoResponse.json();

הבעיה? הוא לא צריך את todoResponse והגדיר אותו רק בשביל להפעיל עליו .json. יש כמה דרכים טבעיות ב JavaScript לוותר עליו, אבל אף אחת מהן לא עושה חשק. הראשונה היא להשתמש בשני await באותה שורה:

const todo = await (await client.get('/api/todos/1')).json();

ודרך שניה עם then:

const todo = await client.get('/api/todos/1').then(r => r.json());

החלום של גבור היה לכתוב קוד שנראה כך:

const todo = await client.get('/api/todos/1').json()

אתם יכולים להעיף מבט בבלוג שלו כדי לראות איך הוא מימש את זה. כאן אני רוצה שנחשוב אם זה בכלל חלום ששווה להתאמץ בשבילו. ✏ מה אנחנו מפסידים כשאנחנו משנים התנהגות קוד נקי הוא קוד שעושה מה שאנחנו חושבים שהוא עושה. קל להרחיב אותו, קל לשנות אותו, קל לקרוא אותו. קוד נקי אמור לתת יתרון לאנשים (או סוכני קידוד) שמכירים את עולם התוכן ויודעים למה לצפות. כשמפתחים וותיקים רואים קוד שנראה כמו מה שהם מכירים הם רגועים ויכולים להמשיך בקריאה. כשמפתחים חדשים רואים קוד נקי הם לומדים ממנו איך דברים עובדים. בגרסת שני המשתנים ברור ההבדל בין פונקציית get לפונקציית json, ברור שכל אחת מחזירה משהו אחר ואפשר למצוא בתיעוד מהם שני האוביקטים המעורבים. גרסת ה then גם יפה בדרכה. היא מזכירה לנו שבעצם async/await הוא כתיב קיצור דרך לכתיב ה Promises, ש Promises אפשר לשרשר ושכדאי לנו ללמוד איך לעבור בצורה שוטפת בין שני התחבירים. את גרסת שני ה await-ים אני לא אוהב, היא נראית לא טבעית, אבל לפחות אני מבין אותה במבט ראשון. גרסת ה await הבודד היא הכי מבלבלת. בתור מפתח וותיק אני קורא את זה ולא מבין איפה ה then של ה get, ולמה מתיחסים ל Promise כמו לתוצאה שלה. אם הייתי מפתח חדש שלא מספיק מכיר JavaScript הייתי עלול לחשוב שאפשר להתנהג בצורה דומה גם עם פונקציות אחרות של Promises או עם Promises אחרים, וזו כמובן היתה טעות. הבלבול רק מחריף כשאנחנו מנסים להשתמש בגרסה זו בהקשרים אחרים, לדוגמה:

const todoRequest = await client.get('/api/todos/1');
const todo = todoRequest.json();

במקרה הזה השורה השניה תחזיר Promise כי ה await שלה "נשכח" בשורה הראשונה. הדרך הנכונה לשבור את הקוד לשתי שורות היא דווקא לשים את ה await בשורה השניה ולקרוא ל json ישירות על ה Promise:

const todoRequestPromise = client.get('/api/todos/1');
const todo = await todoRequestPromise.json();

האתגר בשינוי התנהגות מובנית הוא שלמערכות יש הגיון פנימי. אם משנים רק חלק אחד מאבדים את היופי של המערכת ואת היכולת להסיק מסקנות ממקרה אחד למקרים אחרים. כמובן שגם סוכני קידוד ילכו לאיבוד כשבקודבייס אנחנו משתמשים בפונקציות לא בצורה הסטנדרטית שלהן. במקרה של fetch הרבה יותר קל ונכון להשתמש בכתיב ה then כדי לשרשר Promises וכך נלמד מבנה שיעזור לנו גם באתגרים דומים בעתיד. אם מתעקשים אפשר לכתוב פונקציה בשם אחר, למשל getJson שמפעילה את ה then ומחזירה Promise ל json.

📌 הזמנה לוובינר: איך לקבל קוד טוב יותר מהסוכן באמצעות שיטת שלושת השכבות הי חברים השבוע זה קורה. המון זמן לא נפגשנו לדבר על AI והמון דברים קרו גם בעולם וגם בעולם ה AI והגיע הזמן לחזור להתעדכן. ** שימו לב ** הוובינרים יחזרו להתקיים בימי חמישי אבל עוברים לשעה 15:00. השבוע נדבר על האתגר הכי גדול של עבודה עם סוכני קידוד והוא לקבל מהם קוד טוב, כלומר קוד שעובד, שאני יכול לקרוא ולהבין אותו, שיהיה לי קל להשתמש בו ושאינו מסתיר אי הבנות, בעיות אבטחה או מוקשים אחרים שישברו לי את המערכת. אנחנו רואים כלים ומודלים חדשים כל יום והרשתות מציפות אותנו ב FOMO: "אתה חייב לנסות את קלוד אופוס החדש", "קלוד קוד שינה לי את החיים" או "מה לא התקנת עדיין Cursor 2?". אבל לא משנה כמה אנחנו משדרגים את הכלים והמודלים איכות הקוד של המערכת לא משתפרת. בוובינר השבוע אציג שיטת עבודה וגישה שמסבירה בדיוק מה הבעיות באיך שאתם עובדים עם סוכני קידוד, איך להבין את הכלים החדשים ולהשתמש בהם כדי באמת לייעל את תהליך העבודה ואיך לבנות תהליך פיתוח שבו הסוכן יוצר קוד טוב יותר ככל שהמערכת גדלה. ספציפית אנחנו נראה בוובינר: 1. שכבה 1 - איך סוכן קידוד ניגש לפתור בעיה, ואיך אני יכול לשפר את האינטואיציה של הסוכן. כאן נדבר על Prompt-ים, קבצי הוראות, סקילים, תיעוד ומצב תכנון. 2. שכבה 2 או שכבת הקוד - למה סוכן הקידוד כתב את הקוד שהוא כתב? איך אנחנו יכולים להשפיע על הקוד עצמו שייכתב? איזה טעויות סוכן קידוד צפוי לעשות ואיך אפשר למנוע אותן מראש? 3. שכבה 3 או שכבת האימות - איך סוכן הקידוד יודע שהוא סיים? האם הקוד שלו בכלל עובד? כאן נדבר על MCP, בדיקות אוטומטיות וחיבור הסוכן לעולם האמיתי. נפגש השבוע ביום חמישי בשעה 15:00. מוזמנים להצטרף בדף הוובינרים בקישור: https://www.tocode.co.il/talking_ai ואשלח לכם למייל את הלינק לזום.

📌 מ Vibe Coding ל Coding המעבר מ Vibe Coding ל Coding הוא ההמשך הכי טבעי לאנשים שהתחילו לבנות מוצרים בעצמם בלי לדעת לתכנת. הוא טבעי כמו שאנשים שעוברים לארץ חדשה לומדים את השפה של אותה ארץ - ידע בתכנות עוזר לבנות מוצרים טובים יותר עם AI. אנשים שיודעים תכנות יודעים לשאול את ה AI שאלות טובות יותר, יודעים להכנס לקוד ולהכניס תיקון קטן שיגרום ל AI לבנות מוצר מהיר יותר או מאובטח יותר. אנשים שיודעים תכנות יודעים מה לעשות כשה AI אומר "אי אפשר" או נכנס עם עצמו לשיחה אינסופית. ידע בתכנות הוא סקאלה, כמו ידע בשפה חדשה בארץ אליה עברתם. בהתחלה מצליחים רק לקנות במכולת או לשאול מישהו איפה יש בנק באזור. בהמשך כבר אפשר להזמין בבית קפה ולהתייעץ עם המלצר מה יש בכל מנה ואחרי חודשים או שנים כבר אפשר ללמוד באוניברסיטה או להכיר חברים ולדבר בשפה שלהם. כך גם בתכנות, המעבר מ Vibe Coding ל Coding נעשה בשלבים: 1. בהתחלה נוכל רק להסתכל על הקוד שה AI מייצר ולהבין בגדול מה קשור למה. 2. בהמשך נתחיל לשלב מילים טכניות או מילים מתוך הקוד בשיחה - "אני חושב שאם נשפר את ה description של העמוד יהיה קל יותר למנועי חיפוש למצוא אותנו" או "העמוד הזה נטען לאט אולי צריך להוסיף אינדקס ב Database?". לא כל ההצעות יהיו הגיוניות וזה בסדר, גם מהתשובות של ה AI לומדים המון. 3. עם הזמן נוכל לבקש מה AI הסברים על הקוד - "אני לא מבין את הפונקציה הזאת, תוכל להוסיף הערות?", למה השתמשת בלולאת while ולא for? איפה הקוד שמטפל בתצוגה על מסכים קטנים של טלפון? 4. ואז יקרה הקסם הראשון ונתחיל לשים לב לבעיות אפילו לפני שהן קורות. "ראיתי שהגדלת את הטקסט של הכותרת, אבל מה קורה במובייל?", "אני רואה שאתה עושה פה משימה בשלבים, מה קורה אם אחד השלבים נכשל?", "רגע וזה יעבוד גם כשהמשתמש לא מחובר למערכת?". 5. ככל שנקרא יותר קוד והשיחה שלנו עם סוכן הקידוד תהפוך טכנית יותר כך נתחיל לבוא בבקשות - "תעביר את הפונקציה הזאת לקובץ נפרד", "תשנה את סדר הפעולות בקובץ", "הצג את הדיאלוג עם CSS ולא עם JavaScript". 6. עד שיום אחד, בשביל הכיף, תגידו לסוכן הקידוד "יודע מה את זה אני אכתוב". לא בגלל שה AI לא יכול, אלא רק בגלל שאתם יכולים. המעבר מ Vibe Coding ל Coding הוא סקאלה. הוא מאפשר לקחת אחריות על התוצרים ולעבוד יותר בבטחון. ולא, לא צריך לקרוא ספרים ארוכים, להיאבק בבעיות קומפילציה ולהעביר לילות ללא שינה בנסיון לגרום לתוכנית להחזיר את התוצאה הנכונה. מספיק להתחיל בשאלה לקלוד "תסביר לי רגע מה כל חלק בקוד עושה".

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

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

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

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

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

It was three months of hard work, and you had to learn CGI-bin Perl programming in order to build a “buy now” button on your website. So it’s about three months of hard work and about 1000 dollars in setup fees to get a merchant account with my local bank. And I had to incorporate and set up a separate bank account. And after all that work, I had a “buy now” button on my website.

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

📌 כזה ניסיתי: ה mcp של val town הוא הדרך הכי מהירה לשתף ניסויים מקלוד קוד כשאנשים מתלבטים אם כדאי לכתוב את פרויקט ה Vibe הבא בלאבבל או בקלוד קוד (מקומי) אחד השיקולים לבחור בסביבת אונליין זה שפשוט לא צריך להתקין כלום. אתה אומר ל AI מה אתה רוצה, ה AI בונה ויש לך את זה באוויר, כולל קוד צד שרת ואפשרות להריץ שירותים ברקע. ה mcp של val.town מאפשר לנו לעבוד מקומית בתוך קלוד קוד ולהתחבר ל val.town כדי לפרסם את האפליקציה שלנו וכך לקבל במתנה את כל יכולות הפלטפורמה. קוד שרץ על val.town מקבל (בחינם) מהם: 1. ניהול משתמשים דרך מערכת אימות של val.town. 2. בסיס נתונים SQLite פנימי שלכם. 3. ניהול Storage עם אפשרות לשמירת blob-ים. 4. חיבור לאימיילים נכנסים ושליחת אימיילים. 5. חיבור ל ChatGPT (הטוקנים עליהם). 6. יצירת cron jobs שירוצו מהענן שלהם. בשביל המשחק נתתי לקלוד קוד שלי (מודל פתוח glm-5.1 רץ על הענן של ollama, רק 20$ בחודש כמעט בלי הגבלת טוקנים) להריץ שני ניסויים. בפרומפט הראשון ביקשתי משחק סנייק שירוץ על val.town:

find val town docs here
https://docs.val.town/

create a snake game val and return to me its address

הוא יצר את המשחק והעלה אותו לאוויר אוטומטית בקישור הזה: https://ynonp--734c4bca341c11f1b3c142b51c65c3df.web.val.run/ אבל זה רק פרונטאנד אז המשכתי לניסוי שני יותר רציני וביקשתי אפליקציית כרטיסיות שגם מתרגמת מילים מאנגלית לספרדית וחזרה וגם מאפשרת למשתמשים לשמור כרטיסיות ולתרגל אותן, זה הפרומפט:

Create a Spanish flashcards app on val.town using the MCP server:
 1. user will sign in via val town https://docs.val.town/guides/auth/#sign-in-with-val-town
 2. user can type a word in English or Spanish and get the translation in the opposite language (use openai to translate
 https://docs.val.town/reference/std/openai/)
 3. user can save cards (use their sqlite db to save https://docs.val.town/reference/std/sqlite/)
 4. user can "practice" their saved words

אחרי כמה דקות קיבלתי את המערכת בקישור הזה: https://ynonp--b97610c0341e11f1851b42b51c65c3df.web.val.run/ הפעם הקוד מחולק לקוד צד שרת וצד לקוח, קוד צד לקוח JavaScript נקי ללא פריימוורק, קוד צד שרת משתמש ב Hono, יוצר טבלה בבסיס הנתונים מנהל משתמשים ויודע לשמור ולהחזיר מילים שמורות לכל משתמש. בגלל שזה glm וקלוד קוד אז הקוד יוצא מאוד קריא ואפילו ידידותי למתחילים ואני חייב להודות שזה הפתיע אותי לטובה, הנה דוגמה מאוד קריאה לקוד שמחזיר את רשימת המילים של משתמש מסוים:

// Get all cards for user
app.get("/api/cards", async (c) => {
  const session = await getOAuthUserData(c.req.raw);
  if (!session?.user) {
    return c.json({ error: "Not authenticated" }, 401);
  }

  const result = await sqlite.execute({
    sql: "SELECT * FROM flashcards WHERE user_id = ? ORDER BY created_at DESC",
    args: [session.user.id],
  });

  return c.json(result.rows);
});

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

// Initialize database
await sqlite.execute(`
  CREATE TABLE IF NOT EXISTS flashcards (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id TEXT NOT NULL,
    english TEXT NOT NULL,
    spanish TEXT NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
  )
`);

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

📌 אבל המידע שאני צריך לא שם מאקו העלו במלחמה דף זמן ממד שמאפשר לחפש את הישוב שלכם ולגלות כמה אזעקות היו. כל ישוב גם מדורג לדוגמה רמת גן מערב מדורגת מקום 6 במספר האזעקות. שכן מהמקלט רצה לדעת מי העיר עם הכי הרבה אזעקות אז חיפשנו את כפתור ה"מובילים" אבל לא היה כזה. https://sheltertime.mako.co.il/ מה עושים? עד עידן ה AI התשובה היתה לפתוח את מסך כלי הפיתוח של כרום, לחפש בקשות רשת מעניינות, אולי להסתכל על ה JavaScript, להבין מאיפה מגיעים הנתונים ולמשוך אותם בסקריפט כדי להציג את הדברים כמו שאחנו רוצים. היום הייתי צריך רק לכתוב את הפרומפט הבא בקלוד קוד:

Use chrome-devtools
Explain how this site works
https://sheltertime.mako.co.il/

Create a command line script in this directory that uses curl and shows the 5 cities with the highest count of alerts

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

#!/bin/bash
# Top 5 cities by shelter time from Mako's Shelter Time site
# Data source: https://sheltertime.mako.co.il/

DATA_URL='https://storage.googleapis.com/mamad-time-mako.firebasestorage.app/data_2026.json?v=7'

curl -s "$DATA_URL" \
  -H 'Accept: application/json' \
  -H 'Referer: https://sheltertime.mako.co.il/' \
  -H 'User-Agent: Mozilla/5.0' \
  | python3 -c '
import json, sys
from collections import defaultdict

data = json.load(sys.stdin)

# Each top-level key is an operation (e.g. "Iran")
# Each city: [total_time_ms, alert_count, cat1, cat2, days, rank, percentile]
for op, cities in data.items():
    print(f"\n=== Operation: {op} ===")
    print("Top 5 cities by total shelter time:")
    print("-" * 55)
    sorted_by_time = sorted(cities.items(), key=lambda x: x[1][0], reverse=True)[:5]
    for city, vals in sorted_by_time:
        ms = vals[0]
        hours = ms / 3600000
        alerts = vals[1]
        print(f"  {hours:>8.1f} hrs  ({alerts:>4} alerts)  {city}")

    print()
    print("Top 5 cities by alert count:")
    print("-" * 55)
    sorted_by_alerts = sorted(cities.items(), key=lambda x: x[1][1], reverse=True)[:5]
    for city, vals in sorted_by_alerts:
        ms = vals[0]
        hours = ms / 3600000
        alerts = vals[1]
        print(f"  {alerts:>5} alerts  ({hours:>6.1f} hrs)  {city}")
'

נשים לב: 1. למרות שביקשתי Shell Script קיבלתי קוד פייתון. ה Shell מפעיל פייתון. לא הכי ממושמע מצד glm אבל מצד שני אפשר לראות למה הוא עשה את זה. אולי גם הוא מסתבך עם התחביר של jq. 2. גלם כן הבין מיד את מבנה הנתונים והוסיף הערה שמסבירה מה יש ברוב העמודות. לא ברור מה זה cat1 ו cat2 אבל כל השאר די מסבירים את עצמם. 3. לא ברור למה גלם החליט לייבא את defaultdict, בכל מקרה הוא לא בשימוש.