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

אמג'ד מסד, המייסד של רפליט, צייץ לאחרונה:

I no longer think you should learn to code.

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

כמה מחשבות על זה-

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

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

3. אמג'ד, ובכירים רבים נוספים כן חושבים שהנדסת תוכנה היא דבר חשוב. הנה עוד ציוץ הפעם של Pratik Kotkar שקיבל הסכמה מאמג'ד באותו דיון:

this doesn’t mean engineering is obsolete. The engineering approach to solving problems is now even more crucial to make best use of AI tools. the paradigm of what the focus of engineering just changes from syntax and semantics to problem solving

1. עכשיו לשאלות - איך לומדים Problem Solving בהנדסת תוכנה? איך מתאמנים על אותן המיומנויות שיהפכו אותנו למהנדסים הטובים של העתיד? האם לא סביר לחשוב שהשיקולים של ברנדון איי ב 1995 יכולים ללמד אותנו על פיתרון בעיות והנדסת תוכנה? אולי אפילו יותר מבניית עוד מערכת SaaS ?

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

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

נ.ב. קריאה מעניינת לגבי null ב JavaScript (תורגם מקוריאנית על ידי AI)

https://witch.work/en/posts/javascript-why-typeof-null-is-object

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

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

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

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

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

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

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

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

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

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

בפרוטוקול MCP אנחנו מגדירים יכולות לפי קטגוריות:

1. כלים - יכולות שגורמות לשינוי כלשהו בעולם

2. משאבים - יכולות שקשורות למשיכת מידע לקריאה בלבד

3. פרומפטים - יכולות שקשורות לקיצורי דרך ב UI

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

אפשר לחשוב על "שרת MCP" בתור תוסף לאפליקציית שיחה עם מודל שפה, ומה שיפה בו שהוא מתחבר באותו אופן להרבה מאוד אפליקציות שיחה, בדוגמה שלנו גם Claude Desktop תומך ב MCP אבל גם Cursor ולכן בדיוק באותו פרוטוקול אני יכול לתת ל Cursor אופציה להריץ קוד אוטומטית או לקרוא מידע מבסיס הנתונים.

אל מול גלי ה AI אני מרגיש שחובה להזכיר:

1. אני אוהב לקרוא קוד ולהבין אותו.

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

3. אני אוהב לפתור בעיות שקשורות לייצוג ידע ולהבין איך לייצג את המידע שלי בצורה שתאפשר לי לענות מהר על שאלות מעניינות.

4. אני אוהב לחשוב איך דברים הולכים להשתנות בעתיד, ואיך לארגן את המידע והקוד כדי שיהיה קל להתאים את המערכת לשינויים עתידיים.

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

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

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

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

כדאי לשים לב:

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

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

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

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

קומפוננטות צד שרת ב node יכולות לעשות דברים מופלאים, למשל לקרוא קובץ ממערכת הקבצים ולהציג אותו בקלות על המסך או לקרוא מידע מבסיס הנתונים. הבעיה מתחילה כשנתוני צד השרת האלה מתעדכנים. פעם כשהיתה לנו קומפוננטת צד לקוח שקראה את המידע עם react-query ידענו לרענן את המידע כל כמה שניות או לבנות Web Socket כדי לקבל עדכון מהשרת כשהמידע מתעדכן. בפוסט היום נראה דוגמה קצרה איך לעשות דבר דומה ובקלות בקומפוננטות צד שרת.

יום 7 של Advent Of Code לא היה מסובך והזכיר לי כמה כיף שאפשר ברובי לשנות את המחלקות המובנות בשפה. בואו נראה מה היה שם.