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

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

הבעיה חזרה שהיית צריך לעשות שינויים בקוד. היא מעולם לא הייתה בעיה של יכולות, אלא בעיית זיכרון. ה-plan היפה שעשית - נזנח, או כי שכחת לעדכן אותו בכל שינוי מהותי, שכחת להכליל אותו בכל פרומפט או זכרת להכליל אותו אבל חלון הקונטקסט נגמר. מחוללי קוד מוגבלים בטקסט שהם יכולים לעבד. אז התחלת ביום ראשון עם תוכנית סדורה ו-2 בקשות לשינויים, שהפכו ל-20, עכשיו המודל רואה 20 בקשות ואת תוכנית המקור הוא ניקה. מתכנתים הבינו שיש בעיה בחלון אז הם ניסו את ג׳מיני פרו ו-GPT מקס ואז סופר-מקס - פלסטר שלא רק זלל את הטוקנים החודשיים תוך דקות, גם לא פתר שום בעיה - מודלים פשוט דולפים והוזים ככל שיש להם יותר טקסט בזיכרון. זה אולי נסלח כשאתה מבקש תקציר למאמר, אבל בתוכנה זה הרסני.

באותו הזמן בערך, הלכנו כמו כבשים ל-MMMMCP, ספריית כלים שהבטיחה להשאיר אותנו ב-IDE, לגשת בשבילנו לדאטהבייס, ל-figma, לגיטהאב ולהביא לנו עוד קונטקסט. סטנדרט רעשני מאוד, איטי ובזבזני שמילא הרבה מהחלון. כך יצא ש-20 שרתי MCP - תפסו רבע מהחלון רק על הגדרות, וגם בלבלו את המודל בנחיצות שלהם.

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

אבל לקח עוד כמה חודשים להבין איך להסביר ל-Cursor מהי משימה מושלמת, ומהי ה-definition of done. באותו הזמן קלוד קוד, סייען קוד שחי ומריץ פקודות בטרמינל, וגם skills, קובץ הוראות לתהליכים, הפכו מאוד פופולריים. מה אם במקום להקיא עוד ועוד קוד, נבקש מהסייען לכתוב טסט לכל משימה, ורק כשהטסט יעבור, נמשיך למשימה הבאה?

זה פתר שני דברים - גם מילא את הקוד בטסטים שבודקים אוטומטית מקרי קצה, וגם מנע מהסייען ספירלה של טעויות. הטסטים האלה הפכו לחלק מהקודבייס, ונפחו בו ביטחון. המתכנתים הבינו טוב יותר מה הם, כלומר הסייען, כתב, וגם לו - היה עוד קוד להסיק ממנו למשימות הבאות. אפשר להתווכח על האיכות אבל וייב קודינג Made Test Driven Development או TDD, Great Again.

היה מרתק לצפות בריצה של Taskmaster, ועוד חקיינים אחרים, אבל מיקרוסופט הייתה נחושה לנצח במירוץ הזה. עם Github Speckit היא עשתה שני דברים נכון - תמיכה ב-20 סייעני קוד בהתקנה אחת, והכנסה של עוד קצת סדר, אולי יותר מדי סדר, לתהליך. אני מתרגם מה-README: ״במשך עשורים הקוד היה המלך. ה-Specים, ההנחיות ננטשו ברגע שעבודת הקידוד האמיתית החלה. Spec-Driven Development הופך את המשוואה - ההנחיות הופכות להוראות, לעובדות, ומיושמות כלשונן״.

אמרתי אולי קצת יותר מדי סדר. ב-Spec Kit צריך להגדיר Constitution, סט חוקים והחלטות שרלוונטיות לכל הפרוייקט, למשל: חווית משתמש אחידה וריספונסיבית, קוד שיעמוד ברמת אבטחה וביצועים, ושיהיה TDD.

בשלב השני מגדירים Spec. לא לכל הפרוייקט אלא ברמת הפיצ׳ר - מה אתה רוצה להשיג, ולמה, אבל לא איך. למשל - עבור חנות וירטואלית אני רוצה ממשק אדמין עם 3 רמות של הרשאה (מנהל, עוזר מנהל וקופאי), שיוכלו לבצע שינויים, וכל פעולה תישמר לצורך ביקורת, ולכל משתמש יהיה פרופיל עם הגדרות אישיות. Speckit לא רוצה שתגדיר שום דבר טכני כאן, זה שלב שנועד למנהלי מוצר, כזה שישרוד גם החלפה של כל הסטאק הטכנולוגי. הוא אמור להכיל עשרות user stories, ו-acceptance criteria ו-edge cases, אבל אנחנו מתכנתים עסוקים. Speckit יבנה את המסמך הקפדני הזה בשבילך גם אם תזין אותו בכמה פסקאות.

לשלב הזה יש כמה תוצאות: ספריה חדשה תחת specs עם שם הפיצ׳ר וגם branch חדש ב-git, וגם שאלות הבהרה. התשובות שתיתן הופכות להיות חלק מה-spec ומניעות את השלב השלישי - Plan - את האיך. כאן מצופה ממך לצלול כמה שיותר טכנית. איפה מתנהלות הטבלאות? Postgres או Mongo? איך לגשת אליהם? raw או orm? האם להוסיף שכבת קאשינג? האם להשתמש בספריית ספציפית? השלב הזה, ושוב זה בסדר לא לדעת הכל, מייצר עוד כמה קבצים:

קובץ research, שבו המודל מסביר את השיקולים לכל החלטה טכנית שהוא לקח, והאלטרנטיבות שנדחו. קבצי data model שמתארים את החוזים והסכמות שבה יתקשרו שירותים, וקובץ plan שמחבר את ה-user stories עם ההחלטות הטכניות, מסדר גאנט הגיוני של פיתוח, ומוודא שכל ההחלטות (טכניות ולא טכניות) עומדות בקנה אחד עקרונות הפרוייקט, אותה constitution שהגדרנו בשלב הראשון.

השלב הרביעי הוא פריטת התוכנית ל-tasks, ומיספור אוטומטי שלהם ל-1, 2, 3 ואז 3.1 וגם סימון של חלקן עם האות P, מה שיאפשר לשלב הסופי והאחרון, implement, ליישם אותם בצורה מקבילית.

בעצם כל התורה היא שמהלך החשיבה, התכנון וגם הביצוע של המודל, או התערבות שלך בתהליך - ממוסמכת. זה מאפשר לאחרים להבין מה ביקשת שיצר כל כך הרבה קוד, ומה המודל הבין שגרם לו לייצר משימות, ובגלל שזה קבצים בפורמט Markdown, אתה יותר ממוזמן לצפות בהם או לערוך. Spec-Driven הופך מתכנתים לארכיטקטים ומנהלי מוצר, או מנהלי מוצר למתכנתים. הבנתי של-Product Managers יש title חדש והם, כולנו עכשיו, Product Builders.

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

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

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

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

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

גם היישום והבדיקות קורים במחשב שלך. ביקשת לעשות implementation ל-10 משימות, הלכת לקפה וטורטית? יכול להיות שקלוד ייכנס למצב שינה או יחכה לך לאישור. ביטלת את הצורך באישור? קלוד רץ עם הרשאות המשתמש שלך ויש לו גישה למשאבים שלך ושל החברה. זה בסדר אם הוא יעשה drop table ל-postgres מקומי, פחות כיף אם זה יקרה על RDS בפרודקשן.

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

והכי מוזר - אתה מוצא עצמך חי בשלוש מקומות. משרבט הנחיות ב-IDE, מריץ פקודות בטרמינל ועובר על PRים בגיטהאב.

אז בניתי את spec-agent. מערכת שחיה רק בגיטהאב, שהיא ה-single source of truth של הפרוייקט, מעודכנת בזמן אמת לכולם, גם ללא מתכנתים. בלי לדחוף ובלי למשוך. שכל פיצ׳ר הוא בעצם github issue, שכל חבר צוות יכול להוסיף הערות ותמונות, ומתי שמוכנים מוסיפים ל-issue לייבל של plan, מה שמטריג github action שמריץ דוקר קונטיינר בענן.

הקונטיינר הזה לוקח עותק של כל הקודבייס, כולל הקונטקסט מכל ה-issue, כולל תמונות והוא מריץ claude או gemini או codex בדיוק כמו שהייתי עושה בעצמי. הוא ישאל שאלות ואז יפתח sub-tasks, שמקושרים ל-parent issue, ויתייג אותם ב-conventional commits - פיץ׳ ל-feature חדש, fix לתיקון, test לבדיקות, doc לדוקומנטציה. ובגלל שאלו issues חיים ונושמים, אפשר לערוך או לסגור אותם אם לא צריך, או קלטו את זה, להעביר אותם לבן אדם, חי ונושם. כשמוכנים, מוסיפים ל-issue לייבל של work, מה שמטריג שוב קונטיינר, שרץ עם כל התלויות, למשל postgres, בסביבה נקייה ורעננה בכל הרצה, בלי גישה לשום משאב ארגוני.

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

אם זה נשמע לכם כמו Copilot Workspace או Devin או Open SWE (מפרק 19) אז כן. הם בהחלט השראה. אבל Copilot Workspace הספיק כבר להיסגר פעמיים ובאחרים אין שליטה מלאה בספק או במודל. מה שיצרתי בעצם היא שכבה רזה שמעבירה קונטקסט מגיטהאב לכלי טרמינל שהם הטובים בתחומם. הבחירה בקלוד קוד, ג׳מיני CLI או codex היא לרוב בחירה במודל, אבל קידוד מוצלח הוא לא רק מודל, היא הדרך שבה הכלים האלה תוקפים את הבעיה, יודעים לחפש עוד קבצים, מנסים כמה מסלולים, מתווכחים ובודקים את עצמם, ואת היכולות האלה לא מקבלים אם שולחים את הקונטקסט ל-API.

הייתה חשובה לי הגמישות - אפשר להחליט איזה מודל מבצע את ה-plan (למשל claude opus) איזה את ה-work (למשל claude opus), ודרך איזה ספק (למשל AWS Bedrock), וגם השקיפות - כמה טוקנים in ו-out לקחה כל משימה, כמה כסף וכמה זמן, היות וגם גיטהאב גובה גרושים לפי זמן ריצה, בערך 36 סנט, לשעה. יש גם אפשרות לעצור את המשימה כשהיא עלתה מעל תקציב מסוים.

ועוד קצת גמישות - כיוון שכל ה-issues, כל ההרצות, כל האקשנים חיים בגיטהאב, אפשר לתכנת on-the-go, להתקדם במשימות בלי לפתוח מחשב, להוסיף taskים ולערוך taskים בדיוק כמו שהיית מדבר עם הצוות. במייל, אפליקציה או לוח משימות או Kanban תחת Github Projects.

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

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

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

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

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