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

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

ספריות חיצוניות במידה רבה וקוד תשתית פנימי במידה יותר קטנה קובעים את הגבולות של האפשרי. הם החוזה שלנו עם העולם. וכן אפשר להפר חוזה אבל לפעמים יש קנס. ניקח ספריית רובי בשם acts-as-taggable-on בשביל הדוגמה:

https://github.com/mbleigh/acts-as-taggable-on

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

@another_user.skill_list.add("clowning")

אבל אם נכתוב:

all_users.each do |u|
  u.skill_list.add("clowning")
  u.save
end

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

כמה מחשבות סביב זה בעקבות התנגשויות בין פיצ'רים:

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

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

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

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

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

קיבלת קוד שעובד, הצלחת לקמפל ולהריץ ובתור משתמש אתה לא מצליח לזהות אף בעיה, אבל יש רק בעיה אחת בתור מפתח: אתה לא מצליח להבין אפילו שורה אחת מכל הערימה.

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

הדילמה פה ברורה ויושבת בגדול בין שלוש אפשרויות:

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

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

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

שלושת האפשרויות גרועות.

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

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

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

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

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

אני ממשיך עם סדרת Advent Of Code לשמחתנו השנה יש רק 12 חידות אז יש סיכוי שאצליח לפתור ולפרסם את כולם לפני שיעלו האתגרים של 2026. אנחנו היום באמצע הדרך עם יום 6 ותרגיל שאני חשבתי שהיה סופר מעניין. בואו נראה את המספרים.

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

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

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

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

ה AI לא מחליף את הג'וניורים הוא מחליף את מה שהם צריכים לעשות. ברוכים הבאים לתעשייה.

זה לא היה אפשרי עד לא מזמן, ועכשיו צריך לשאול - מה הטריגר ללמידה?

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

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

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

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

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

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

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

עכשיו לשאלה - האם זה באג?

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

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

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

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

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

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

כלל אצבע טוב למחפשים את המשחק הארוך - התרחקו מקרבות הכרעה ומרגעי "הכל או כלום" וכשרגעים כאלה מתקרבים חפשו את ההשפעה לטווח הרחוק של כל החלטה.