על סערת קלוד קוד.
(אני הולך לכתוב פה הרבה ״קלוד״ אבל זה נכון בגדול לכל מערכות הוייב קוד למיניהן, קרסור וכו)
אני רוצה רגע לעשות סדר, גם למי שלא מבין קוד וגם למי שכן ועוד לא עלה על הסירה, במה קורה כאן, למה כל הרשת גועשת פתאום, ועל העתיד של מקצוע המתכנת כמו שאני רואה אותו.
לפני זמן רב (פברואר 2025), אנדרי קרפאט׳י המפורסם טבע את המונח Vibe Coding. אני מביא כאן את הציטוט המתורגם לעברית בגרסה מקוצרת:
״יש סוג חדש של קידוד שאני קורא לו "vibe coding", שבו פשוט זורמים עם הווייבים, [...] ושוכחים שבכלל יש קוד. זה אפשרי כי ה-LLMs נהיו טובים מדי. [...] אני מבקש את הדברים הכי מטופשים כמו "להקטין את הריווח בחצי" כי אין לי כוח למצוא את זה. אני תמיד עושה "Accept All", כבר לא קורא מה השינויים. כשיש הודעות שגיאה אני פשוט מעתיק-מדביק אותן בלי שום הסבר, ובדרך כלל המודל פותר את זה. הקוד גדל מעבר למה שאני בדרך כלל מסוגל להבין; [...] לפעמים ה-LLMs לא מצליחים לתקן באג, אז אני פשוט עוקף אותו או מבקש שינויים אקראיים עד שהוא נעלם. זה לא נורא לפרויקטי סופ"ש חד-פעמיים, אבל עדיין די משעשע. אני בונה פרויקט או ווב-אפליקציה, אבל זה לא באמת קידוד — אני פשוט רואה דברים, אומר דברים, מריץ דברים, ומעתיק-מדביק דברים, וזה לרוב עובד.״
בפוסט הזה בX קרפאט׳י מציג את מה שכולם חושבים שהוא vibe coding, מה שמצטלם יפה, אבל בעיני הסיפור הקטן. קרפאט׳י מתאר מצב אוטופי, בו ה״מתכנת״ (שלא באמת ״מתכנת״) מדבר עם המודל בשפה טבעית, רואה את התוצאה בעיניים, משייף ומתקן, עד שהוא משיג את מה שרצה. כפי שכתבתי כאן בעבר, זאת האבולוציה של No Code. אם חברות כמו Wix הפכו אותנו לבוני אתרים בעזרת גרירה של קומפוננטות על מסך, עם הרעיון של וייב-קודינג אמור להיות אפשרי לשחרר את שלשלאות ה״מה שוויקס לא בנו במערכת שלהם אי אפשר לעשות״ ופשוט לעשות.. הכל.
זה גם מה שכל החברות לייצור אפליקציות רוצות לעשות - Lovable, Base44 ודומיהן. לא סתם Wix קנו את Base44, מדובר על שכבה חדשה שמאיימת ישירות על המוצר שלה. אבל הן? הן סתם פלסטר בעיני.
אותם מודלים בעולם בעולם הוייב-קוד, קרי קלוד קוד, קרסור וכו, לא יכולים ללכת לספק הענן (גוגל, אמזון, מייקרוסופט וכו) הקרוב לביתם, להרשם בשמכם, להכניס אשראי, להרים סביבה ולהתחיל לעבוד. בעצם, כל יהבן של אפליקציות כמו Base44 היא שיש להן סט של אינטגרציות קבועות - בסיס נתונים, מערכות העברת הודעות, אחסון, הגנת סייבר, ניהול עומסים ועוד ועוד - כל אלה כדי לתת לAI את ה״מצע״ שעליו הוא יכול באמת לפתח.
אם אתם לא מגיעים מעולם הפיתוח, זה ממש פשוט. יש לכם שורה בקוד שאומרת ״חפש בבסיס הנתונים את המשתמש״. בסיס הנתונים הזה יושב איפשהו. על מכונה. שצריך להרים, ולהתחבר אליה, ולשלם עליה. ולאבטח אותה.
בעצם, ברגע שכל הספקים השונים (ואין לי ספק שזה יקרה) יאפשרו ״הרשמת אייג׳נט״ ואותו קלוד יוכל ללכת לשרתים של אמזון, לפתוח חשבון ולהרים שם סביבה - שם גם ימותו כל חברות האפליקציה-בפרומפט. הכל יכול להתבצע מהמחשב בלי גורם מתווך. גם כאן יש בעיות. האם תסכימו שהאייג׳נט יזרוק את האשראי שלכם במקום שיכול לחייב אתכם ללא תחתית?
זאת אכן מגבלה שעוד צריך לפרוץ ואחלה סייד נוט, אבל מה הסיפור הגדול? על מה כולם מדברים עכשיו?
על סינרגית מתכנת-AI.
מגיע מפתח מנוסה, שעובד על מערכת מורכבת. בואו ניקח משהו שכולנו אוהבים, מערכת להזמנת טיסות כמו Google Flights. נניח ורוצה לעשות משהו פשוט - להוסיף עוד אפשרות סינון, נגיד, ״מטוסים שטסו פחות מ100 טיסות״, לפחדנים.
במקום להתחיל לכתוב קוד, המפתח יכול להגיד לקלוד ״תוסיף באתר את הכפתור לסינון״. קלוד מוסיף. ״צור קונטרולר בשרת שממנו הכפתור יוכל לשאוב מידע, תשאיר את השאיבה ריקה כרגע״. קלוד מוסיף. ״תכתוב שאילתה לטבלה ׳פרטי מטוס׳ שנמצאת בבסיס נתונים ׳מטוסים׳ ששולפת את המידע הרלוונטי״. קלוד מוסיף. ״תוסיף שכבת קאש (זיכרון מהיר) ככה שאם שני אנשים שואלים את אותה שאלה, בפעם השניה זה ישלף מהזיכרון המהיר ולא מהשרת״. וקלוד עושה. וכותב גם את הטסט. ובאמת מבין איך לנווט בקוד הסבוך.
סביר שאם היינו אומרים לקלוד לבנות את הפילטר הזה מ0, בלי כל הוראות הביניים - הוא היה מצליח. אבל אני, בתור מפתח עם אחריות, צריך לבחור מידה של שליטה. אני רואה אותו מסיים שלב ולא מתחיל לקרוא הכל, אלא הולך למקומות הקריטיים שאני יודע שבהם יכולות לצוץ צרות ובודק רק אותם. אני מקבל החלטות על איך דברים צריכים להתבצע מתוך ראיה כללית של המערכת, הצרכים, העלויות והעומסים הצפויים.
יכול להיות שקלוד לא יצליח לבנות את זה בלי השלבים שאתן לו. זה לא כל כך משנה. בכל פעם שהמודלים ישתפרו, ״גודל המשימה״ שהם יצליחו לבצע יגדל. זה אחריות של ״המתכנת כמפקח״ להבין מתי זה גדול עליו.
השילוב של המתכנת שמבין את התמונה המלאה, יודע לקבל החלטות קריטיות ולבדוק מקומות קריטיים יחד עם המודל שמייצר כמויות של שורות קוד במהירות, הוא - הוא מה שכולם מדברים עליו. זה הוייב-קודינג מתכנת-מכונה שמקפיץ את קצב הפיתוח פי כמה עשרות (ולא מה שקרפאט׳י דיבר עליו). זה לא בינארי - זאת סקאלה. בין מוד ״קלוד רץ לבד על הכל״ ל״אני כותב הכל עם המקלדת״ יש ספקטרום רחב שעליו המתכנת שולט, וזה מה שנותן את תחושת המפתח 10x.
יש מתכנתים שהעבודה שלהם היא לפתוח רשימת משימות (״טיקט בג׳ירה״) ולבצע. הכמות של אלה, להערכתי, הולכת לדעוך קיצונית בשנים הקרובות. ״המעמד הבינוני״ של תכנות יכחד. המקצוע של ״מתכנת״ הופך ל״מישהו שיודע how to get the job done״, מה שאפשר מהר עם AI, לעשות AI, מה שצריך לבדוק, לבדוק, מה שצריך פתרון יצירתי, למצוא. אין יותר תירוצים.
וזה, על זה, כולם מדברים.
אולי זה יעזור למישהו: אחד הדברים שממש שיפרו לי את החיים המקצועיים בעבודה זו המדיניות של inbox zero method - כלומר אפס מיילים בתיבת המיילים המקצועית שלי. אפס. כלומר שתיבת המייל שלי רוב הזמן בעבודה ריקה.
איך עושים את זה?
קודם כל עושים archive על כל תיבת המייל הנוכחית. ואז ממשיכים>>
@ketacode מעניין, אז לנו היה חסר לא מעט חוקים שאנחנו משתמשים בהם די הרבה ובגלל ש biome מפוקס יותר 'איכות' ולא 'אכיפה' והיינו לקראת השינוי ל Cursor אז עצרנו עם זה, אשמח לשמוע רשמים על שילוב של biome עם Cursor בהמשך
Introducing MCP UI, the SDK that wires UI components directly into the MCP protocol🤯
Watch the video to see the new phase in AI interaction!
Why browse when you can have universal apps that deliver the right UI to consume any data and perform any action?
Replace cumbersome walls of text with slick interactive components, bringing rich web experiences to MCP-enabled agents such as Claude and Cursor.
Let’s build Jarvis so @kentcdodds doesn’t have to! 🧵>>
יש למישהו ניסיון עם שיתוף של rules ב cursor?
אנחנו רוצים לרכז את החוקים הבסיסיים בריפו אחד ולשתף אותך בין המפתחים.
בנתיים חשבנו על npm pacakge/mcp שמעתיק אותם, נשמח לשמוע רעיונות 🙏🏼
@ketacode חוזר לפה לעדכן, בסוף יצרנו npm pacakge עבור כל ה base rules.
כל המפתחים תורמים, כולם שותפים, כולם משפרים את הסיפרייה.
הוספנו לכל ריפו task בתיקיית VSCode ככה שבכל פעם שפותחים את הפרוייקט אנחנו מעתיקים את ה rules לפרויקט מבלי לפגוע בחוקים שלא נחשבים בסייסים או לא קשורים לספרייה.
בלוגפוסט חדש בבלוג הפיתוח של @Zencityio . הפעם ה Frontend tech lead שלנו @shai_malul כתב https://t.co/wVO1aSOcO2 על מיקרופרונטאנדים ופטרן של reuse בshell app ועל מימוש אלגנטי שלו וגם על טכניקת רפקטורינג שלא הכרתי שמשתמשת בAST בJS. המלצת קריאה גם ללא פרונטיסטים שבינינו