הניסוי שהחלטתי לעשות - ולמה דווקא עכשיו
בשנת 2020, בגונג, ראיתי מקרוב איך קבוצת Research עם אנשים שעשו דוקטורט בעיבוד שפה טבעית מייצרת Edge אמיתי למוצר. באותה תקופה זה לקח יותר זמן, אבל היתרון רק גדל וגדל.
ב-2023 הצוות שלי עבד בשיתוף פעולה לא סטנדרטי עם אותה קבוצת Research. במקום לחכות שהמודל יהיה מוכן ואז לעבוד איתו, עבדנו יחד בסבבים קצרים - גישה שלא הייתה מקובלת באותה תקופה. העלינו את המוצר עם Feature Flag, למדנו לדבר את השפה של דיוק (מה זה אומר 0.71? האם 0.82 מספיק טוב למשתמשים?), ובמקביל לימדנו את אנשי ה-Research לדבר שפה מוצרית.
הקפיצות האלו קרו בחברות שהבינו מוקדם שעם היציאה של מודלים חזקים כמו GPT-3, שילוב של AI ו-Engineering חייב להיות חלק וביחד - לא משהו נפרד שמוגש ואז עובדים איתו.
היום, כמה שנים קדימה, זה מובן מאליו. ולא רק לחברות שזה הלחם והחמאה שלהן, אלא לכל אדם שרוצה לבנות מוצר.
אבל המהפיכה הזו מביאה למצב לא פשוט. חברות עם RnD גדול ומוצר בנוי מוצאות את עצמן מתמודדות עם שאלות קשות: האם להקטין כח אדם? פחות שכבות הנהלה? להחליט שכל דבר - אפיון, עיצוב, פיתוח - קורה קודם כל עם AI? באיזה כלי לעבוד? כמה אמון לתת ל-AI ב-Code Review?
ובינתיים, בילדרים שמתחילים עכשיו זזים מהר יותר. מחיר הטעות שלהם נמוך. הם לא גייסו המון אנשים, לא בנו מוצר שצריך לתחזק, ואין להם המוני משתמשים שצריך לשמור על המערכת שלהם למעלה.
אז החלטתי לעשות ניסוי.
כמישהו שהיה גם מתכנת וגם מנהל פיתוח בחברות תוך כדי המהפיכה בכל השלבים שלה, ראיתי מה קורה בפנים - את הכאבים ואת היתרונות. עכשיו רציתי להיכנס לכובע של בילדר שמקים חברה מדומה בגישת AI-First.
המוצר: BridgeBoard
הקמתי חברה מדומה עם מוצר אמיתי שפותר בעיה שראיתי שוב ושוב בחברות. BridgeBoard מחבר בין צוות Sales לצוות Engineering בתצוגה אחת משותפת. איש ה-Sales מזין עסקאות עם הפיצ׳רים שהלקוח צריך, ההנדסה מזינה את ה-Roadmap שלה, והמערכת מזהה אוטומטית כמה הכנסה בסיכון בגלל פערים בין מה שנמכר למה שנבנה. הפאונדר מקבל דאשבורד שמראה בדיוק איפה כסף נשאר על השולחן.
בחרתי מוצר שמספיק פשוט לבנות ב-MVP אבל מספיק מציאותי - עם כמה פרסונות, לוגיקה עסקית, ותסריטים שקורים בחברות אמיתיות כל יום.
המטרה: לקחת שלבים מה-SDLC - מ-Ideation ו-PRD ועד ארכיטקטורה, פיתוח, טסטים והעלאה לפרודקשן - ולהדגים גישות AI-First. לנסות למדוד. להיות כנה לגבי מה עובד ומה לא.
הפוסט הזה מתמקד בחלק שלפני שנכתבה שורת קוד אחת - התכנון. ואני חושב שדווקא החלק הזה הוא הכי מעניין.
למה תכנון ולא ישר Vibe Coding?
ראיתי הרבה אנשים שמספרים איך העלו מוצר ב-24 שעות עם Vibe Coding, ואז אחרי שבוע הסתבכו ועכשיו צריכים אנשים טכנים שיעזרו להם. זה מגניב ורואים תוצר, אבל לתקן אחר כך - אמאל׳ה ואבאל׳ה.
תכנון שלוקח שעה-שעתיים יכול לחסוך המון כאב בהמשך. וזו אולי אחת התובנות הכי חשובות של הניסוי הזה: תכנון עם AI לא לוקח הרבה זמן - ובמיוחד לא הרבה זמן לעומת פעם. הוא לא מרגיש בירוקרטי, הוא מרגיש כמו שיחה עם קולגה חכם.
אז עוד לפני שהתחלתי לבנות, ישבתי עם Claude ותכננתי. בואו נצלול.
שלב 0: תכנון הניסוי עצמו - לפני שמתחילים בכלל
לפני שהתחלתי לבנות PRD או לגעת בארכיטקטורה, ישבתי עם Claude ותכננתי את הניסוי עצמו ברמה גבוהה. מה השלבים? מה סדר העבודה? אילו סקריפטים ופרומפטים אצטרך בכל שלב?
החלק המעניין: ביקשתי מ-Claude גם להכווין אותי איפה בעיניו יהיה חשוב שאני כ-Human אכנס לעצור, לבדוק, ולהחליט לפני שממשיכים. כלומר - תכננתי מראש את נקודות ה-Human In The Loop. לא חיכיתי שמשהו ישתבש כדי לגלות שהייתי צריך להסתכל. מראש הגדרתי: "פה אתה עוצר ובודק, פה אתה מאשר, פה אתה מאתגר."
התוצר: תכנית עבודה עם שלבים מוגדרים, פרומפטים מוכנים לכל שלב (שהייתי יכול לשנות אחרי אם צריך), ונקודות שיח וביקורת מתוכננות מראש. זה לקח אולי חצי שעה - ונתן לי מסגרת ברורה לרוץ איתה.
שלב 1: בניית PRD - אפיון מוצר עם AI
התחלתי בשיח עם Claude על BridgeBoard. לא נתתי לו prompt חד-פעמי של ״תבנה לי PRD״ - ניהלתי שיח, הוספתי קונטקסט, ניווטתי.
התוצאה: אפיון מפורט בשפה מוצרית, מחולק לפרסונות, עם Flows עבור כל אחת. כל Context שהוספתי - פידבקים של משתמשים, באגים מג׳ירה, שיקולים ביזנסיים - תרם לאפיון והפך אותו למדויק יותר.
מה עבד מצוין
הגשר בין פרודקט לאנג׳ינירינג. באפיון שנוצר, איש הפרודקט מקבל שפה טכנית שקרובה יותר למתכנתים - מבנה API מוצע, מבנה דאטה, קשרים בין ישויות. ברור שבסוף האחריות על המתכנת, אבל היכולת לתת משהו באפס זמן שמסביר טוב יותר את הכוונה - מורידה חיכוך. ומהצד השני, מתכנתים שמדברים שפה ביזנסית יכולים פתאום לייצר שיח מוצרי לפני שהם מתחילים לפתח.
מהירות עדכון. ברגע שמשתנה החלטה או מגיע מידע חדש - קל מאוד לעדכן את האפיון. חלוקה אחרת לסלייסים? Flow שונה? שאלה על מה יהיה ב-MVP? Claude עזר להתייעץ, להסביר, ולדייק. וזה עוד בלי להכניס קונטקסט ארגוני שבטוח היה תורם עוד יותר.
ביקורת עצמית. ביקשתי מ-Claude לבקר את האפיון שלו עצמו, להעלות שאלות קשות ולאתגר את ההחלטות. זה עובד. עולות שאלות שאני אישית לא תמיד חושב עליהן - כמו קולגה שמבקש לאתגר אותך, רק פי כמה יותר יעיל לפעמים.
איך זה נראה בפועל?
הנה דוגמה ממשית מה-PRD שנוצר. שימו לב לרמת הפירוט - User Stories עם Acceptance Criteria ברורים, מחולקים לפרסונות:
Story 3: Founder Dashboard
As a founder, I want to see total pipeline revenue, revenue at risk, and the specific feature gaps causing that risk, so I can make informed prioritization decisions.
Acceptance Criteria:
- Metric Cards Row (top of page): Total Pipeline: sum of all deal revenue. At-Risk Revenue: sum of revenue for deals where at least one required tag has no matching roadmap item. Coverage: percentage of deals that are fully covered.
- Gap Table: Feature name, Deals Needing It (count), Revenue at Stake. Only shows tags that have NO matching roadmap item. Sorted by Revenue at Stake descending.
ויותר מזה - ה-PRD כלל גם חלוקה ל-Release Slices עם זמנים ו-Ship Gates ברורים. העיקרון: לשחרר ערך עסקי מוקדם, ולהוסיף תשתית אחר כך.
Slice 1 - Mocked Dashboard (1.5h): כל שלושת הדפים עם דאטה מדומה. אפס דאטהבייס, אפס API. רק React סטטי שאפשר לשתף עם Design Partners כדי לבדוק אם הרעיון עובד - לפני שמשקיעים עוד 5 שעות בבנייה.
Slice 2 - Sales Pipeline Live (2h): הבקאנד עולה, Sales יכולים להזין עסקאות, הדאשבורד מתעדכן עם דאטה אמיתי.
Slice 3 - Full Loop (1.5h): גם Engineering מזינים Roadmap Items. הלולאה המלאה עובדת: הזן עסקה → ראה סיכון → הזן פיצ׳ר ב-Roadmap → הסיכון נעלם.
Key insight: אחרי שעה וחצי כבר יש מה להראות. אחרי שלוש וחצי שעות יש מוצר שאפשר להשתמש בו.
ה-PRD המלא כלל גם Data Model, הגדרות API מפורטות, Out of Scope ברור, ו-Success Criteria. הכל נוצר בשיח אחד, עם אתגורים הדדיים.
מה פחות עבד
אפיון ענק שקשה לעכל. Claude ייצר אפיון מפורט מדי. בדיעבד, עדיף להתחיל בחתיכות, לאשר כל אחת, ולחבר בהדרגה - קצת כמו קוד. ככה גם מרגישים שהאפיון באמת שלכם, וגם מוודאים שהרעיונות והפרטים נכונים.
שלב ה-Review עדיין קריטי. אנחנו עדיין לא ב-100% אמון שהאפיון שנוצר הוא מה שהיינו עושים. צריך לקרוא, לשאול, לאתגר - ואולי זה אפילו לוקח יותר זמן מ-Review רגיל, כי הכמות גדולה יותר.
הערה חשובה: בניסוי הזה דילגתי על שלבים שלגמרי קיימים ונכונים בתהליך אמיתי - שיחות עם משתמשים, ניתוח דאטה מ-Pendo או MixPanel, עבודה עם מעצב על Wireframes ב-Miro, שימוש ב-Figma Make. המטרה כרגע היא להתמקד בחלק ההנדסי. בניסויים הבאים אכנס גם לעומק של החלקים האלו.
שלב 2: ארכיטקטורה - כשהתמונה הגדולה נבנית מהר (אולי מהר מדי)
אחרי שהאפיון היה מוכן, ביקשתי מ-Claude לייצר ארכיטקטורה. אם חשבתי שהאפיון גדול - הארכיטקטורה הייתה פי כמה. פיצול להגדרות של אנשי צוות, כל אחד עם המון פירוט על מה שהוא עושה, חלופות טכנולוגיות, דיאגרמות.
מה עבד מצוין
הבנת חלופות בזמן אפס. היכולת להגיע ולהבין חלופות טכנולוגיות הרבה יותר מהר, לשאול שאלות ולקבל הסברים - זה משנה את המשחק. גם איש פרודקט יכול לשאול שאלות טכניות ולבוא לשיחה עם הצוות מוכן הרבה יותר.
POC מיידי לחלופות. כשקשה להחליט בין חלופות, אפשר לקחת צוות של Agents ולבקש מהם לבנות מיני-גרסה של כל אחת ולהשוות. פעם היינו מקדישים ימים עד שבוע+ לזה. כאן בפחות מיום אפשר להחליט החלטה ארכיטקטונית טובה יותר.
דיאגרמות אוטומטיות. אין צורך לצייר מאפס. הכל מצויר, בצורה מובנת, ואני יכול לייצר גרסה לאנשים טכנים יותר או פחות.
שוב - הגשר. הפרסונות של פרודקט ומתכנת מתקרבות. כל אחת מרגישה בנוח יותר עם התוצר של הצד השני.
איך זה נראה בפועל?
מסמך הארכיטקטורה לא היה סתם רשימת טכנולוגיות. לכל בחירה טכנולוגית היה הסבר ברור למה היא נבחרה - ולמה האלטרנטיבות לא:
Backend Framework: Fastify (over Express, Hono, NestJS)
Why Fastify over Express: Fastify gives us schema-based validation out of the box. For a 1-day build with parallel agents, this matters - the backend agent can define request/response schemas that double as both runtime validation AND documentation.
Why not NestJS: Massive overhead for a 5-endpoint API. NestJS's decorators, modules, providers, and DI container would triple the file count and confuse AI agents with boilerplate.
ORM: Drizzle ORM (over Prisma, Knex, raw pg)
Why Drizzle over Prisma: Drizzle schemas are TypeScript files - no separate
.prismaschema language, no code generation step. The backend agent writes aschema.tsfile and immediately has full type inference. Prisma requiresnpx prisma generateafter every schema change, which breaks AI agent flow.
שימו לב: ההחלטות הטכנולוגיות לא נבחרו רק לפי מה ש-״הכי טוב״ באופן כללי, אלא לפי מה שמתאים לבנייה מהירה עם AI Agents - שיקול שבדרך כלל לא נמצא בארכיטקטורה קלאסית. זה מבט חדש שכדאי להתחיל לחשוב עליו.
בנוסף, מסמך הארכיטקטורה כלל Component Tree מפורט, DB Schema מלא עם הסברים, וחלוקה ברורה של מי עובד על מה - כבר בהכנה לשלב ה-Agent Teams.
מה פחות עבד
אותה בעיה - ענק מדי. גם כאן עדיף לעבור שלב שלב, לוודא שמבינים, שלמים עם ההחלטה, ויודעים מה הערך שלה. עבודה הדרגתית ואישור כל שלב לפני שרואים את החיבור.
סכנה למי שפחות מנוסה. אם אני לא מתכנת מנוסה ו-Claude נותן לי חלופות שלא בהכרח נכונות - אני עלול לעשות בחירה מסוכנת. הניסיון וההבנה של בחירה ארכיטקטונית חשובים כאן ועוזרים לפחות להבין מה המחיר שמשולם. אין קיצורי דרך בהבנה.
שלב 3: חלוקת עבודה - Work Tracks
כאן לקחתי את האפיון והארכיטקטורה וביקשתי מ-Claude לייצר תיאור וסדר עבודה ברור. המטרה: שבהמשך אוכל להנחות צוות של Agents (או כל פתרון אחר) כשהכל ברור - מי תלוי במי, מי עובד במקביל, מי אחראי על מה, ואיפה יש קונטקסט משותף.
למה זה חשוב במיוחד
בסטארטאפים קטנים, לייצר סדר עבודה מסודר עם תלויות וסיכונים זה בדרך כלל בירוקרטי מדי. רוצים לרוץ מהר. אבל כשהעלות של לייצר את זה כמעט אפסית - אין סיבה לא לעשות את זה. ושווה להשקיע.
איך זה נראה בפועל?
מסמך ה-Work Tracks חילק את העבודה לשלושה Tracks מקבילים - Backend, Frontend ו-Tests - עם הגדרה ברורה של מה כל Agent עושה, באיזה סדר, ומה ה-Context המשותף ביניהם. הנה דוגמה של המבנה:
Backend Agent Frontend Agent Tests Agent
────────────── ────────────── ───────────
B1: Setup F1: Setup T1: Setup
B2: DB Schema F2: Mock client T2: Tag parser tests
B3: Tag parser F3: Shared components T3: Risk engine tests
B4: Risk engine F4: Nav + router T4-T7: API tests
B5-B10: API routes F5: Dashboard page T8: Component tests
B11: Seed script F6: Sales page
B12: Static serving F7: Engineering pageהנקודה הקריטית: ה-Frontend Agent שולח Slice 1 (UI שלם עם Mock Data) לפני שה-Backend בכלל מוכן. אפס תלות. הם נפגשים רק ב-Slice 2. זו חשיבה שצריך לתכנן מראש - ושחוסכת המון זמן.
בנוסף, לכל Agent הודבק Shared Context Document בתחילת העבודה עם הנחיות ברורות: אל תיגע בקבצים שלא שלך, תעבוד לפי הטיפוסים המשותפים, ותתעד מה עשית. כמו צוות אמיתי שיושב בחדר אחד - רק שכל אחד יודע בדיוק מה לעשות בלי לחכות לאף אחד.
מה עבד
Alignment בעלות נמוכה. היכולת לוודא שאנחנו מיושרים בין האפיון, הארכיטקטורה וסדר העבודה - בלי תחושה בירוקרטית. פשוט עובד.
קבצי Markdown כ-Context. שמרתי הכל כקבצי Markdown - אפיון, ארכיטקטורה, סדר עבודה - שנורא קל לשים כ-Context לפרויקט. כל מסמך נוסף משפר את העבודה הבאה ואת הדיוק שלה. קל לגלות פערים בין אפיון לארכיטקטורה שלפעמים מתגלים רק תוך כדי עבודה, או יותר גרוע - כשהמוצר מגיע למשתמשים.
החלטות מהירות על שינויים. כשראיתי שיש תלות גדולה מדי או חלק שייקח יותר מדי זמן - יכולתי להחליט על סדר עבודה שונה. למשל: החלטתי לוותר על DB של PostgreSQL ולעבוד עם LocalStorage בצורה הכי פשוטה, רק כדי לבדוק את המוצר. שדרוג יגיע אחר כך.
שקיפות מלאה על החלטות. הרגשתי בטוח בכך שאני שומר את ה-PRD, ארכיטקטורה והמסמך עבודה בנפרד ויכול תמיד לשנות אותם. זה לא Vibe Coding של ״תבנה לי מערכת כזו וכזו״. אני יכול להגיע לפירוט של כל החלטה, על מה היא מבוססת, ולשנות את הבסיס שלה בלי שהכל מתפרק.
מה פחות עבד
בכנות? כאן הרגשתי שהשלב עבד ממש טוב. סידר את הדברים, לא לקח הרבה זמן, וכרגע אין לי משהו רע להגיד.
שורות תחתונות
1. תכנון AI-First לא מרגיש כמו בירוקרטיה - הוא מרגיש כמו שיחה
מ-PRD ועד סדר עבודה מפורט עם תלויות - כל השלב הזה לקח כמה שעות. לא ימים, לא שבועות. ומה שיצא הוא מספיק מפורט כדי שצוות של Agents (או אנשים) יוכל לרוץ איתו.
2. הגבולות בין תפקידים נמחקים - וזה דבר טוב
פרודקט מגיע לשפה טכנית, מתכנתים מדברים שפה מוצרית, ארכיטקטורה מובנת לכולם. ה-Fullstack Product Engineer שמדברים עליו? עם AI זה כבר לא רק חלום - זה מתחיל לקרות. ווואו כמה בעתיד זה עוד הולך להתחבר עם עוד תפקידים וזה ממש מרגש בעיניי!
3. ההשקעה בתכנון משתלמת פי כמה
שעה-שעתיים של תכנון הצילו אותי מבלאגנים שבדרך כלל מתגלים רק בשלבים מתקדמים. ועם AI, התכנון עצמו הופך לנכס - קבצי Markdown שמשמשים כ-Context לכל העבודה הבאה.
4. AI מצוין באתגור עצמי - אם מבקשים
הבקשה מ-Claude לשאול שאלות קשות ולאתגר את עצמו - הייתה אחד הדברים הכי אפקטיביים. עולות שאלות שלא חשבתי עליהן, בדיוק כמו קולגה טוב שמאתגר אותך.
5. ״מהיר״ לא אומר ״חופשי מטעויות״
כמעט כל התוצרים דורשים Review של בן אדם. אפיון מפורט מדי שקשה לעכל, ארכיטקטורה עם חלופות שלא בהכרח נכונות, החלטות שדורשות ניסיון - ה-Human In The Loop חייב להיות שם. השאלה היא מתי בדיוק לעצור ולבדוק, ולא להתעצל.
מה הלאה?
בפוסט הבא אספר על מה שקרה אחרי ששורות הקוד כן התחילו להיכתב - בניית צוות Agents עם Claude Code, איך כל אחד קיבל תפקיד ומשימות ברורות, מה קרה כשהם רצו לבד, השגיאות, התיקונים, והרגע שהפרויקט עלה ורץ. כולל חווית Deploy ל-Vercel, צוות Reviewers מתמחים (Security, Performance, Test Coverage, Code Quality) - ואיך כל זה מרגיש כשאתה בקושי ביום הראשון של הניסוי.
ספוילר קטן: שהמוצר יעלה, יהיו גם תסריטים אמיתיים - איש Sales שמגיע עם חברה שמוכנה לשלם 2M$ ARR במידה ונפתח, Incidents בפרודקשן, טיקטים מ-Support, בקשות מפרודקט. בדיוק כמו חברה אמיתית.
דברים שהייתי עושה אחרת (רטרו מהיר)
כמה דברים שלא עשיתי בהחלטה מודעת בניסוי המהיר הזה ושבדיעבד היו תורמים:
Claude.md - לא הכנתי מראש. סביר שהיה חוסך זמן ומייצר עבודה יותר מדויקת.
Skills ו-Hooks - לא התעסקתי ביצירה או שימוש בקיימים. השקעה קטנה בהתחלה שכנראה משתלמת.
MCP Tools - לא התייחסתי לזה כדרישה. שווה לחשוב מראש על זה בתכנון.
אופטימיזציית Tokens - לא תכננתי. זה צריך להיות חלק מתכנון פרויקט עם Claude Code, במיוחד עם Agent Teams שמשתמשים בהרבה טוקנים.
בחירת פלטפורמת Deploy מראש - לא החלטתי על Vercel מהתחלה, וזה גרם לבזבוז טוקנים וזמן ב-Deploy.
GitHub Spec Kit - נתקלתי ב-Toolkit הזה ל-Spec-Driven Development שמפרמל פלואו דומה למה שעשיתי כאן. מעניין שהגעתי לגישה דומה באופן אורגני. באחד הסבבים הבאים אנסה אותו ואשווה תוצאות.
כל אלה - חומר מצוין לסבב הבא של הניסוי. וזה בדיוק היתרון של בילדר שמתחיל: אפשר ״לזרוק לפח״ עבודה של כמה ימים ולהתחיל מחדש. בחברה גדולה זה פשוט לא מקובל.
רוצים ליישם גישת AI-First בארגון או בצוות? אשמח לשיחה קצרה - מלאו פרטים ואחזור אליכם.
קבעו שיחת הכרותהפוסט הזה הוא חלק מסדרת ניסוי AI-First Company שאני מריץ ומתעד תוך כדי תנועה. עוקבים אחריי כאן וב-chenfeldman.io לפירוט מלא - בעברית שיהיה הכי נגיש שיש.