טיפים קצרים וחדשות למתכנתים
בעקבות הערה בקבוצת הדיונים על כך שלא כל הפוסטים מצליחים להגיע במלואם לטלגרם קיבלתי המלצה על ספריה שכותבת מארקדאון לטלגרם. הפוסט הזה הוא הראשון שנשלח עם הספריה החדשה וכולי תקווה שהוא יגיע ליעדו, אבל לפני שאספר לכם איך ה AI שילב את הספריה החדשה בסקריפט בואו נבין למה בכלל צריך ספריה לכתיבת מארקדאון לטלגרם ומה היה עד עכשיו.
לקלאודפלייר היתה בעיה - כולם כתבו יישומים ב next.js ואת היישומים האלה אפשר היה להריץ בקלות על השרתים של ורסל. הבעיה? קלאודפלייר היא מתחרה של ורסל ורוצה גם לאפשר לאנשים להריץ יישומי next.js על השרתים שלה. אבל נקסט בנויה עם webpack ואצל קלאודפלייר יש תמיכה רק ב vite.
מה עושים? נותנים לקלוד (דרך אופןקוד) לבנות מחדש את החלקים של next.js שתלויים ב webpack הפעם עבור vite. הפיתוח לקח שבוע. הריפו מתחיל מגרסה בסיסית וכולל 90 קומיטים ואת כל התהליך ניהל מפתח יחיד בעלות 1,100$ בטוקנים של קלוד. סטיב פולקנר, המפתח שעבד על הפרויקט, כתב פוסט מאוד מפורט על התהליך.
בפוסט הוא מונה שלושה מאפיינים של הפרויקט שאפשרו את ההצלחה:
תיעוד אינסופי - כולם מכירים את next.js, מודלים מכירים אותו, יש אינסוף חומר ותיעוד רלוונטי.
חבילת בדיקות מקיפה - הם לקחו את חבילת הבדיקות של next.js למימוש מחדש וכך היה ברור שבונים את הדבר הנכון.
יסודות חזקים באמצעות vite - התשתית של vite כיסתה את החלקים הקשים בפרויקט.
למעשה אלה בדיוק העקרונות של גישת שלושת השכבות לפרויקטים ידידותיים ל AI שגם אני מקדם: שכבת הפרומפטים (תיעוד ואיפיון), שכבת הווריפיקציה (בדיקות ו MCP) ושכבת הקוד (תשתית קוד חזקה שה AI יכול להתבסס עליה להמשך).
מעניין לשים לב גם להפצה של Agent Skills למיגרציה יחד עם הפרויקט. לא יפתיע אותי לראות בעתיד הקרוב פרויקטים שמפיצים בנוסף לתיעוד גם תיקיית Agent Skill כדי לעזור לסוכני קידוד לעבוד עם המערכת.
עד 2008 כשרצית לכתוב קוד שעושה משהו היה צריך לחפש את התיעוד של הספריה הרלוונטית, לקרוא כמה עשרות עמודים, להבין לעומק איך דברים עובדים ואיך פונקציות שונות עובדות יחד ואז לכתוב את הקוד. אחרי שהגיע סטאק אוברפלו משימות כאלה הפכו טריוויאליות, מספיק היה להכנס לסטאק אופרפלו ולמצוא שם את התשובה.
מפתחים רבים, גם וותיקים וגם בתחילת דרכם אימצו את הכלי החדש בזרועות פתוחות ופשוט העתיקו קטעי קוד למערכות שלהם. באפריל 2021, שנה וקצת לפני השקת ChatGPT, סטאק אוברפלו פרסמו נתונים לפיהם רבע מהמבקרים לאתר מעתיקים משהו תוך 5 דקות מהכניסה. וכן בכל תקופת החיים של סטאק אוברפלו אנשים התלוננו שקוד שמועתק משם עלול לגרום לבעיות אבטחה, למפתחים פחות מקצועיים, מערכות פחות יעילות ופחות יצירתיות.
ובעוד שמפתחים מסוימים העתיקו מסטאק אוברפלו בלי להבין תעשיית התוכנה בכללותה מאוד הרוויחה מהאתר. מפתחים שידעו מה הם עושים יכלו לעבוד יותר מהר ולהבין אפילו טוב יותר. בין הדברים שמפתחים מנוסים עשו:
קראו תשובה ודרכה הכירו את הכלים כדי לדעת איזה דפי תיעוד לקרוא.
קראו את כל הדיונים בתשובה מסוימת כדי להבין את מקרי הקצה וההשלכות האפשריות.
בנו לעצמם מוניטין באמצעות מענה על שאלות של אחרים והשתתפות בדיונים.
מה שלא היה בתשובה בסטאק אוברפלו הוא חדשנות. אם זה היה כתוב בסטאק אוברפלו זה אומר שמישהו עשה את זה קודם וממילא אנחנו שמחים לבנות על עבודות קודמות של אחרים כדי להתקדם.
אני קורא את הפוסט של דן אברמוב שמשווה בין פעילות ברשתות החברתיות למערכת קבצים:
https://overreacted.io/a-social-filesystem/
שום סוכן קידוד לא היה יכול לכתוב אותו או לחשוב הרעיונות שם. זו לא אותה עבודה. העבודה שלנו היא עדיין ותמיד היתה להתבסס על רעיונות ישנים כדי ליצור דברים חדשים. ככל שיותר קל להשתמש באותם רעיונות ישנים כך רק ברור יותר כמה חשוב החלק של יצירת הרעיונות החדשים.
אחת ההטיות המבלבלות של המוח האנושי היא ההרגשה שאפשר לתקן באותה מהירות שמשהו התקלקל.
לוקח דקה למחוק בסיס נתונים. במקרה הטוב להחזיר אותו מהגיבוי ייקח חצי יום.
לפני עשר דקות המערכת שלך עבדה כמו שצריך ועכשיו כל הנתונים מוצפנים ואתה מסתכל על דרישת כופר.
בגרסה הקודמת של הדפדפן האתר שלי נראה אחלה. עכשיו הוא שבור ואפילו לא בגלל משהו שעשיתי.
לפני רגע הכל היה טוב. עכשיו יש בעיה. אלה שני משפטים נפרדים.
הי חברים העליתי השבוע תוכנית וובינרים חדשה לחודשים הקרובים ואני כמובן מקווה לראות את כולכם במפגשים בימי חמישי בבוקר. אני רוצה לנצל את הפוסט הזה כדי לפרט קצת על ההגיון בבחירת הנושאים והדברים שחשוב לדעתי למפתחים להכיר בתחום ה AI בתקופה הקרובה.
נושא ראשון שיעסיק אותנו במפגשים הוא פרודוקטיביות, כלומר איך גורמים לסוכן קידוד לכתוב את הקוד הנכון למערכת שלכם. במפגש הראשון בסדרה אציג את גישת שלושת השכבות (קוד, חיבור לעולם ופרומפטים) ואיך היא עוזרת להבין את העבודה עם סוכן הקידוד ואחריה מפגש יותר פרקטי שם נראה איך ליישם את הגישה בקופיילוט. בהמשך מתוכנן גם וובינר על גיט ובפרט אראה את פקודות הגיט המרכזיות שעוזרות לי לעבוד עם סוכני קידוד.
נושא שני שנדבר עליו יהיה כתיבת סוכנים והוא כולל וובינר על OpenAI Agents SDK, על ChatKit של OpenAI שמאפשר להטמיע סוכן באתר שלנו, על dspy ואיך הוא עוזר לנו לארגן פרומפטים בתוך תוכנית וגם נראה איך לכתוב שרת MCP לסוכנים שלנו.
והנושא האחרון הוא התזכורת למגבלות של AI וסוכני קידוד. יהיה וובינר על Vibe Coding ונראה מה המצב שם, מה אפשר לבנות ומה עדיין קצת מסובך, וובינר על פיתוח בדיקות אוטומטיות באמצעות AI ווובינר על אבטחת מידע עם השם "מה כבר יכול להשתבש" שם נדבר על בעיות אבטחת המידע ש AI כבר מכניס לחיים שלנו.
שלושת הנושאים נבחרו בצורה לגמרי שמרנית מתוך הסתכלות היום על התעשייה - רוב מוחלט של חברים ולקוחות שלי בתעשייה כבר בונים סוכנים או שאצלם בחברה בונים סוכנים, רוב מוחלט נעזרים ב AI במהלך הקידוד ובהמון מקומות יש כבר אנשי פרודקט או IT מוכשרים שמתחילים להשתמש בכלי Vibe Coding כדי לקדם דברים שלא אחד לא היה זמן לפתח.
אפשר לראות את התוכנית המלאה עם תאריכים בדף של מדברים AI ושם גם להצטרף לרשימת הדיוור ולקבל קישור לזום. נתראה בוובינרים:
אם בשנים הקרובות אנחנו הולכים לעשות 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
שתי הפקודות האלה נראות דומות ועושות משהו דומה ואולי בגלל הדמיון בתחביר הן כל כך מבלבלות:
# 1. two dots diff
git diff dev..main
# 2. three dots diff
git diff dev...main
רואים את ההבדל? נכון זו רק נקודה.
נתונים שני ענפים dev ו main והם התקדמו במקביל. בעבר dev יצא מ main כדי לפתח פיצ'ר ומאז main התקדם עם תיקוני באגים קטנים. עכשיו אנחנו רוצים לראות מה ההבדל ביניהם:
פקודת diff עם שתי נקודות תראה לי את ההבדל בין המצב העדכני ביותר בענף dev למצב העדכני ביותר בענף main.
פקודת diff עם שלוש נקודות תראה לי את ההבדל בין המצב העדכני ביותר בענף dev לבין הקומיט ב main ממנו הוא יצא, כלומר בלי אותם קומיטים חדשים ב main שנכתבו אחרי שהתחלתי לכתוב את הפיצ'ר.
מתי נשתמש בכל אחת? ברגע שהבנו את ההבדל גם השימוש הוא ברור: לפני מיזוג או ריבייס כשאני רוצה למפות פערים אני אשתמש ב diff שתי הנקודות. כך אני יכול לדעת כמה אני רחוק מהקוד הראשי. בזמן העבודה על dev אני אשתמש ב diff שלוש הנקודות כדי לראות מה בדיוק עשיתי, אם צריך לערוך קומיטים או לנקות קוד. בעבודה עם AI אני אוהב לעשות Code Review עם diff שלוש הנקודות, כך אני יכול לראות בדיוק את השינויים שסוכן הקידוד הכניס בלי להתבלבל בגלל שינויים אחרים חדשים יותר בענף הראשי.
כמו לכל דבר גם לסוכני קידוד יש מדדים אבל כשנכנסים להבין מה יש במדדים האלה מתחילים לראות למה הקוד שהם מייצרים לא דומה לקוד שבני אדם כותבים.
חיפוש agentic coding benchmarks בגוגל החזיר לי די הרבה תוצאות אז בואו נסקור את הראשונות:
אתר דירוג ראשון נקרא LiveBench. מדד זה כולל אוסף של בעיות קידוד בהן על הסוכן לכתוב קוד שפותר בעיה ויש קוד בדיקה אוטומטי שמוודא שהבעיה נפתרה. את הבעיות כתבו מומחים של LiveBench והם ממשיכים וכותבים בעיות חדשות כל הזמן כדי שכותבי המודלים לא יוכלו לרמות את המדד. אגב לסקרנים סוכן הקוד המוביל שם הוא GPT-5.2-Codex ובמדד Agentic Coding המוביל הוא אופוס 4.5 במאמץ בינוני.
דירוג נוסף שקופץ גבוה הוא SWE Bench והמדד המוביל שם נקרא SWE-bench Verified. מדד זה לוקח Github Repos שיש להם מערכת בדיקות אוטומטית עם Issues שנבחרו בקפידה ושם מבקשים מהסוכן לפתור את ה Issue בצורה שתגרום לבדיקה לעבור ולא תשבור בדיקות אחרות. גם כאן אף בן אדם לא מסתכל על הקוד שהמודלים מייצרים והדבר היחיד שנמדד זה כמה אחוז מהבעיות הסוכן הצליח לפתור. אופוס 4.5 במאמץ בינוני גם כאן מדורג ראשון.
דירוג שלישי שקופץ הוא Aider Polyglot. בדירוג זה נתנו למודלים מובילים לפתור בעיות תכנות תחרותי מאתר Exercism והדירוג מתבסס על אחוז הבעיות שהמודלים הצליחו לפתור.
מה משותף לכל ה-3? נכון, בני אדם לא קוראים את הקוד שנכתב, הדירוג מבוסס על ביצוע משימות סגורות (עובר או לא עובר) ולא על איכות הקוד וקוד שסוכן כותב לא מגיע להתמודד עם data אמיתי.
כל זה לא אומר שסוכני קידוד לא יודעים לקודד. אנחנו יודעים שהם מקודדים ואפילו הרבה. זה כן אומר משהו על המדדים ובמיוחד על הפער בין הצלחה במדדים לבין הצלחה בפתרון בעיות במערכות הספציפיות שלנו. יכול להיות שהקפיצה הבאה בפרודוקטיביות לא תגיע מהגרסה הבאה של קלוד אלא מהבנה שלנו איך לשלב כמה מודלים ולהשתמש במודלים שונים לבעיות שונות או אפילו לאותה בעיה כדי לראות מספר פתרונות במקביל.
השבוע בוובינר נדבר על מודלים פתוחים ומודלים חופשיים, המדדים של סוכני הקידוד ואיך גם המודלים הפתוחים שלא תמיד מובילים במדדים יכולים לפתור בעיות טוב יותר וזול יותר מהמודלים המפורסמים, וכמובן אראה לכם איך למצוא ולהתקין את כל אותם מודלים. רוצים לבוא? בכיף. נרשמים כאן ואשלח לכם את הלינק לזום:
מובן כלומר ״ברור״, ״נתפס בשכל״. כשאני אומר על משהו שהוא מובן אני מתכוון שאני כבר מקבל אותו או שהוא בנוי בצורה כזאת שאנשים אחרים יוכלו לקבל אותו, יוכלו להבין אותו.
כשמשהו מובן מאליו זה אומר שהוא מובן ללא כל הסבר נוסף או ללא כל מאמץ נוסף. אי אפשר להתכחש למובנות שלו.
תרגול, חשיפה ועבודה בתבניות עוזרות להפוך קוד ממובן למובן מאליו, כלומר מכזה שדורש רגע לעצור כדי להבין מה רצו שם לכזה שאפשר לראות ולהמשיך. דוגמה? בטח הנה דיפסיק מדפיס 10 מספרים ראשונים בסדרת פיבונאצ'י:
def print_fibonacci():
first = 0
second = 1
count = 2 # We already have two elements: 0 and 1
while count < 10:
next_num = first + second
sequence.append(next_num)
first, second = second, next_num
count += 1
print(' '.join(map(str, sequence)))
מובן לגמרי ואפילו עם הערה שעוזרת להבין למה מתחילים מ-2 אבל דורש קריאה וקצת ריכוז.
והנה מינימקס פותר את אותה בעיה:
def print_fibonacci(count=10):
a, b = 0, 1 # start with the first two numbers
for _ in range(count):
print(a, end=' ')
a, b = b, a + b # move to the next pair
print() # final newline
גם הוא מעמיס הערות אבל הפעם ברור שאין בהן צורך. את התבנית:
a, b = b, a + b
מכיר כל מי שכתב פיבונאצ'י בפייתון.
כל עוד קריאת קוד היא חלק משמעותי מהחיים שלנו, ונראה שלשנים הקרובות היא רק הולכת והופכת יותר משמעותית, שווה להתאמץ ולהשתפר בזה. מצד אחד באמצעות שיפור מיומנות ויצירת ציפיות ומצד שני באמצעות השפעה על ה AI שיבנה את הקוד שיתאים לציפיות שלנו.
המטלה הכי שנואה על מפתחים בעולם החדש היא קריאת הקוד ש AI כותב. קריאת קוד של אחרים זה תמיד כאב ראש ובמקרה של AI הקושי כפול כי אנחנו צריכים להתרכז ולחפש איפה ה AI פספס דברים בסיסיים שיסבכו אותנו בהמשך.
אחת הדרכים להקל על העומס היא לגשת למשימה בראש אחר. במקום "אני צריך למצוא מה ה AI פספס" ננסה את הגישה "יש לי הזדמנות ללמוד".
במקום לחפש "איפה ה AI פספס" נחפש "איך הקוד החדש פותר את הבעיה"
במקום לחפש "מה ה AI לא ראה" נשאל "מאיפה התבנית הזאת הגיעה?"
במקום להתאמץ ולמצוא שגיאות הגיון ננסה למצוא את ההגיון ולעקוב אחר חוט המחשבה שהיה יכול להיות שם.
במקום לחשוש לפתוח את הקוד כי "מי יודע מה אמצא שם" כדאי לזכור שהקוד הזה ממילא לא עלה לי כלום וכמו שהוא נכתב מהר אפשר גם להעיף אותו מהר ולייצר הכל מחדש עם פרומפט קצת יותר טוב.
במקום לחשוש שאני אצא טמבל ולא אבין דברים בסיסיים כדאי להזכר - יש לי הזדמנות ללמוד. כל מה שלא אבין אוכל לשאול את אותו AI. מעולם לא היה יותר קל ללמוד טריקים חדשים על קוד. מעולם לא היה יותר חשוב להבין.