מ-Figma לקוד ב-2026: הכלים, ה-workflow ומה דורש מפתח
מדריך מלא ל-design to code ב-2026: Figma Make, Anima, Builder.io, Locofy ו-MCP. מה מייצר קוד פרודקשן אמיתי, מה זריק, ואיפה עדיין צריך מפתח.
למי זה מתאים: אם יש לכם עיצוב מוכן ב-Figma ואתם רוצים להבין כמה ממנו אפשר להפוך לקוד אוטומטית, זה המדריך. אעבור על המצב האמיתי של Figma לקוד ב-2026: Figma Make, Anima, Builder.io, Locofy והגישה החדשה של לתת ל-Cursor או Claude לקרוא את ה-Figma דרך MCP. אגיד בכנות מה מייצר קוד פרודקשן שאפשר לשלוח, מה מייצר קוד שזורקים אחרי יומיים, ואיפה מפתח עדיין חובה. הדגש על React ועל הבעיות ב-RTL שאף כלי לא פותר לבד.
מ-2022 ועד היום עברתי מהשלב של ״כל כלי design to code מוציא זבל שצריך לזרוק״ לשלב הרבה יותר מעניין: חלק מהכלים באמת מוציאים קוד שאפשר לעבוד איתו. אבל הפער בין מה שמבטיחים בדף הנחיתה לבין מה שיוצא בפועל עדיין ענק, ובעברית/RTL הוא אפילו יותר גדול. במדריך הזה אני מפרק את המעבר מ-Figma לקוד לפי הניסיון האמיתי שלי על פרויקטים של לקוחות.
1. מה השתנה ב-2026 (ולמה זה רגע מעניין)
עד לא מזמן ״Figma לקוד״ היה בעיקר plugins שלוקחים פריים ומקיאים HTML עם המון position: absolute. זה נראה זהה לעיצוב בדסקטופ ונשבר ברגע שמישהו פתח את זה בטלפון. ב-2026 קרו שלושה דברים שמשנים את התמונה.
ראשון, Figma עצמה נכנסה לתחום ברצינות. Figma Make כבר לא רק מייצר קוד מתוך קנבס; בבטא מוגבלת של 2026 הוא יכול לייבא repo קיים מ-GitHub, לתת לערוך אותו ויזואלית על הקנבס, ולפתוח Pull Request עם השינויים. זאת הכוונה, אבל בהמשך אסביר למה הבטא הזאת עדיין מאוד מוגבלת ולמה לא הייתי בונה עליה היום.
שני, MCP. במקום לתת לכלי לצלם תמונה של הפריים ולנחש, היום Cursor, Claude Code, VS Code, Windsurf ו-Codex יכולים לקרוא את ה-Figma ישירות דרך Figma MCP server: עץ ה-nodes, ה-variants, ה-constraints, ה-design tokens וה-assets. זה ההבדל בין ״תראה לי תמונה ותכתוב קוד״ לבין ״קרא את המבנה האמיתי ותכתוב קוד״.
שלישי, הכלים הוותיקים (Anima, Locofy, Builder.io) השתפרו והוסיפו תמיכה ב-Tailwind, shadcn/ui ו-TypeScript, וחלקם הוסיפו שכבת AI שמאפשרת לעבד את הפלט בשפה טבעית. הם כבר לא מוציאים רק div-ים עם inline styles.
מה לא השתנה: אף אחד מהם לא הופך עיצוב למוצר. הם הופכים עיצוב ל-UI סטטי. כל מה שזז, נשמר, נקרא מ-API או צריך לוגיקה עדיין עליכם. נחזור לזה בהרחבה.
2. שתי גישות שונות לחלוטין
לפני שנכנס לכלים ספציפיים, חשוב להבין שיש שתי משפחות, והבלבול ביניהן גורם לאנשים לבחור לא נכון.
גישה א׳: Plugin שמייצר קוד (Anima, Locofy, Builder.io)
אתם בוחרים פריים ב-Figma, לוחצים export, מקבלים קוד. הכלי ״מתרגם״ את שכבות העיצוב לאלמנטים. היתרון: דטרמיניסטי יחסית, אותו פריים מוציא בערך אותו קוד בכל פעם. החיסרון: הכלי תרגם את מה שראה, וזה תלוי לחלוטין בכמה ה-Figma שלכם ״נקי״. שימו לב שגם המשפחה הזאת כבר לא תרגום טהור, חלק מהכלים הוסיפו שלב AI שמשנה את הפלט בין הרצות.
גישה ב׳: סוכן AI שקורא את ה-Figma (Figma Make, Cursor/Claude דרך MCP)
אתם נותנים לסוכן גישה לפריים ומבקשים ממנו לבנות. הוא לא מתרגם 1:1, הוא ״מבין״ ובונה קומפוננטות, לפעמים משתמש בקומפוננטות קיימות שלכם. היתרון: קוד הרבה יותר אנושי. החיסרון: לא דטרמיניסטי, שתי הרצות יכולות לתת מבנה שונה, ולפעמים הוא ״ממציא״ דברים שלא היו בעיצוב.
| היבט | Plugin (Anima/Locofy) | סוכן AI (Make/MCP) |
|---|---|---|
| איכות קוד | בינונית-גבוהה (Locofy/Anima במצב AI) | גבוהה, אנושית |
| דטרמיניסטי | יחסית | לא |
| משתמש בקומפוננטות קיימות | מוגבל | כן (עם Code Connect) |
| תלוי בניקיון ה-Figma | קריטי | פחות, אבל עדיין משפיע |
| מתאים ל | ייצוא מהיר, מוקאפים | פיתוח מתמשך בקודבייס |
| RTL | חלש מאוד | חלש (אבל ניתן להנחיה) |
| תמחור | טוקנים/קרדיטים | קרדיטים (Make) או מנוי הסוכן |
אם אתם מפתחים שעובדים בקודבייס קיים, גישה ב׳ כמעט תמיד עדיפה. אם אתם צריכים לייצא הרבה מסכים מהר ולמסור ללקוח, גישה א׳ יכולה לחסוך זמן. אם אתם בכלל מתלבטים אם לכתוב קוד בעצמכם או לתת ל-AI לבנות מאפס, יש לי על זה מדריך נפרד על vibe coding ומתי כדאי להשתמש בו.
3. הכלים אחד-אחד — מה כל אחד באמת מוציא
Anima
עד לא מזמן Anima היה התרגום הכי ״מילולי״ של העיצוב: כל אלמנט קיבל מיקום מוחלט או חצי-מוחלט, וה-HTML יצא שטוח, כמעט בלי היררכיה סמנטית. ב-2026 התמונה השתנתה חלקית. Anima הוסיף מצב AI שמאפשר לעבד את הקוד בשפה טבעית, ומייצר קומפוננטות shadcn + Tailwind שהם מתארים כ-״production-ready״, עם תמיכה ב-React, Vue, TypeScript ו-Next.js, וייצוא ישיר ל-GitHub. גם ייבוא מרובה-מסכים עם ניווט עובד בין הדפים.
זה שיפור אמיתי, אבל הזהירות שלי נשארת: ברגע שמדלגים על מצב ה-AI ומייצאים פריים ישר, עדיין מקבלים מבנה שטוח שתלוי לגמרי בכמה ה-Figma מסודר. מצב ה-AI עוזר, אבל הוא לא קסם, והפלט שלו לא דטרמיניסטי יותר.
מתי כן: מוקאפ שצריך להראות ללקוח מהר, landing page שלא תתחזקו לאורך שנים, או צוות שכבר בנה עם shadcn ורוצה התחלה מהירה. מתי לא: מערכת מורכבת שתחיה ותתפתח לאורך זמן, שם אעדיף MCP.
Locofy
Locofy מוציא את מבנה הקומפוננטות הכי נקי מבין הפלאגינים הקלאסיים. הוא מייצר קומפוננטות עם שמות שתואמים בערך לשמות השכבות שלכם, משתמש ב-flexbox בעקביות, ומוציא קוד שמפתח junior יכול לקרוא ולתחזק. תומך ב-React, Vue, Angular, Next.js, Gatsby, HTML-CSS, React Native ו-Flutter. התמחור מבוסס טוקנים (Locofy קוראים להם LDM tokens): מסלול חינמי עם 600 טוקנים, Starter ב-$33.30 לחודש (כ-1,489 טוקנים), Pro ב-$99.90 לחודש (כ-5,995 טוקנים), Enterprise בהתאמה, ו-pay-as-you-go ב-$0.40 לטוקן.
מניסיון, Locofy הכי קרוב ל-״קוד שאפשר לעבוד איתו״ מבין הפלאגינים, בתנאי שה-Figma בנוי נכון עם Auto Layout. אם ה-Figma שלכם הוא בלגן של שכבות חופשיות, גם Locofy ייכשל.
Builder.io
Builder.io הוא הכי הרבה ״פלטפורמה״ ולא ״פלאגין״: יש בו headless CMS ויזואלי ו-editor שיושב מעל הקודבייס הקיים, כך שצוותי שיווק ותוכן יכולים לגרור סקשנים, להריץ A/B testing ולנהל תוכן בלי לפתוח כל פעם טיקט לפיתוח. הוא הופך עיצובי Figma לקומפוננטות React/Next.js לשימוש חוזר, עם SDK רשמי ל-React, Next.js ו-Shopify (פופולרי בעיקר ל-headless Shopify). התמחור: מסלול חינמי, מסלול בתשלום מ-כ-$19-24 לחודש למשתמש, ו-Enterprise לפי הצעת מחיר (לא מפורסם מחיר קבוע). לייצוא קוד טהור הוא לא הבחירה הראשונה שלי, הוא נותן את התמורה הכי טובה כשמשתמשים גם בשכבת ה-CMS.
Figma Make
זה השחקן שהכי השתנה ב-2026, אבל גם זה שהכי קל להגזים לגביו. Make מייצר אפליקציות עובדות מתוך prompt או מתוך עיצוב, ופעם נדחפו ממנו רק repos חדשים. החידוש: בטא מוגבלת שמאפשרת לייבא repo קיים, לערוך אותו ויזואלית, ולפתוח ממנו Pull Request.
ועכשיו ההסתייגויות שדף הנחיתה לא מדגיש, ושכדאי לדעת לפני שבונים עליהן workflow:
- זאת בטא ל-Mac בלבד. דורשת את אפליקציית ה-Figma Beta לדסקטופ; תמיכה ב-Windows ו-Linux ״תגיע בהמשך״ בלי לוח זמנים.
- הזרימה חד-כיוונית. שינויים זורמים מ-Make ל-GitHub, לא להפך. אם מהנדס ערך קוד ישירות ב-IDE ואז מעצב דוחף מ-Make, השינויים של המהנדס נדרסים.
- ניהול branches מוגבל נכון לבטא.
המשמעות המעשית: ה-PR review של Git עדיין שומר על שער איכות, אבל בקודבייס פרודקשן עם מספר מפתחים, הזרימה החד-כיוונית מסוכנת. הייתי משתמש ב-Make היום בעיקר לפרוטוטייפים ולפרויקטים קטנים עם מעצב יחיד, לא כצינור הראשי לפרודקשן.
תמחור: Make רץ על AI credits של Figma. מסלול Professional כולל גישה מלאה ל-Make עם כ-3,000 קרדיטים בחודש למושב Full ($16 למשתמש לחודש), Organization 3,500 קרדיטים ($55), ו-Enterprise 4,250 ($90). מושבי Dev/Collab/View מוגבלים ל-500 קרדיטים בחודש בלבד, מה שכמעט חוסם בהם שימוש רציני ב-Make. מ-18 במרץ 2026 Figma אוכפת מגבלות קרדיטים ברמת המושב, אז כדאי לעקוב אחרי הצריכה. קרדיטים נוספים: מנוי מ-$120 לחודש ל-5,000 קרדיטים נוספים, או pay-as-you-go ב-$0.03 לקרדיט.
Cursor / Claude Code דרך Figma MCP
זאת הגישה שאני הכי אוהב לפרויקטים אמיתיים. מתקינים את ה-Figma plugin הרשמי (שמגדיר את ה-MCP server וכולל Agent Skills למשימות נפוצות), בוחרים פריים, ומבקשים מהסוכן לממש. במקום screenshot הוא מקבל את עץ ה-nodes, variants, layout constraints, design tokens ואת ה-assets. עם Code Connect הוא אפילו יכול להשתמש בקומפוננטות האמיתיות שלכם במקום לשכפל אותן, מה שמשפר דרמטית את עקביות הקוד.
יש שתי גרסאות של ה-server: remote (המומלץ לרוב המשתמשים, עם הכי הרבה יכולות) ו-desktop (לארגונים עם צרכים ספציפיים). זה לא קסם, אם תבקשו ״תבנה את כל הדף״ תקבלו בלגן. אבל אם תעבדו קומפוננטה-קומפוננטה ותגידו לו באילו קונבנציות להשתמש (Tailwind, shadcn, logical properties ל-RTL), זה הכלי שהכי קרוב לקוד שהייתם כותבים בעצמכם.
4. ה-workflow המעשי — איך אני עובד בפועל
זה לא ״מייצא ומסיים״. הנה ה-handoff שאני משתמש בו, שלב-שלב.
שלב 1: לתקן את ה-Figma לפני שמייצאים
הטעות הכי גדולה היא לצפות שהכלי יתקן עיצוב מבולגן. כל כלי, גם הכי חכם, מוציא קוד טוב יותר מ-Figma מסודר:
- Auto Layout בכל מקום. בלי זה כל כלי נופל ל-
position: absolute. זה הדבר היחיד שמשנה הכי הרבה. - שמות שכבות אמיתיים.
CardProduct, לאGroup 47. הכלי משתמש בשמות כשמות קומפוננטות ו-classes. - Components ו-Variants. מה שהוא component ב-Figma הופך לקומפוננטה בקוד. אם שכפלתם 8 כפתורים ידנית, תקבלו 8 בלוקים כפולים.
- Variables ל-design tokens. צבעים ומרווחים כ-variables הופכים ל-tokens במקום ערכים קשיחים. זה גם מה שמאפשר ל-MCP לקרוא את ה-tokens ולהשתמש בהם נכון.
שלב 2: לייצר רק חלק, לבדוק, להמשיך
אל תייצאו את כל הדף בבת אחת. קחו קומפוננטה אחת (כרטיס, navbar), ייצרו, בדקו את הקוד, תקנו את ההנחיות, ואז המשיכו. זה מונע מצב שבו אתם מגלים אחרי 40 מסכים שכל הקוד בנוי לא נכון. מבחינת חיסכון קרדיטים/טוקנים זה גם זול יותר: קל יותר לתקן הנחיה אחרי קומפוננטה אחת מאשר אחרי דף שלם.
שלב 3: לחבר ל-design system קיים
הקוד שיוצא משתמש בערכים גולמיים. החלק האנושי הוא למפות אותם למערכת שלכם: להחליף צבעים ב-tokens, מרווחים ב-scale, ולהשתמש בקומפוננטות הקיימות. אם אתם על Tailwind + shadcn (מה שאני ממליץ לרוב הפרויקטים), כתבתי מדריך נפרד על Tailwind, shadcn/ui ועברית/RTL שמתאר בדיוק איך מגדירים את זה נכון מההתחלה.
שלב 4: code review אנושי
אף פעם לא מ-merge ישירות. הקוד צריך לעבור עין אנושית: נגישות, RTL, responsive, ושמות שיהיו ברורים בעוד חצי שנה. עם Figma Make זה נכפה דרך ה-PR review; עם פלאגינים זה עליכם לאכוף.
// טיפוסי: מה שיוצא מ-export גולמי
<div style={{ position: 'absolute', top: '24px', right: '16px', width: '320px' }}>
<div style={{ fontSize: '18px', color: '#1B4DFF' }}>כותרת</div>
</div>
// מה שצריך אחרי החיבור ל-design system + RTL
<article className="rounded-2xl p-4">
<h3 className="text-lg text-brand">כותרת</h3>
</article>
הנוסח הזה לא רק קצר יותר, הוא responsive ו-RTL-aware: ה-p-4 מתורגם ל-padding לוגי, וה-text-brand מצביע ל-token במקום לערך קשיח, כך ששינוי צבע מותג קורה במקום אחד.
5. הבעיה הגדולה של RTL ועברית
כאן כל הכלים נופלים, וזה החלק שאף דף נחיתה לא יספר לכם. כלי design to code מתרגמים את מה שהם רואים, וה-Figma שלהם נבנה לראש שמאל-לימין. אז גם אם העיצוב שלכם בעברית, הקוד יוצא עם הנחות LTR.
הבעיות הקלאסיות שאני רואה:
- מיקום פיזי במקום לוגי. הכלי מוציא
margin-left,padding-right,left: 0. ב-RTL אלה הופכים את הכל. צריךmargin-inline-start,padding-inline,inset-inline-start, properties לוגיים. - כיוון טקסט וזרימה. העיצוב נראה תקין בקנבס, אבל בלי
dir="rtl"בשורש ובליtext-alignנכון הכל זוחל שמאלה. - אייקונים שצריכים להתהפך. חץ ״הבא״ צריך להצביע שמאלה בעברית. אף כלי לא יודע את זה אוטומטית, צריך
transform: scaleX(-1)ידני (וזהירות לא להפוך אייקונים שאסור להפוך, כמו לוגו או שעון). - ערבוב עברית-אנגלית ומספרים. טלפונים, מיילים ומחירים בתוך טקסט עברי דורשים טיפול ב-bidi (למשל עטיפה ב-
<bdi>אוunicode-bidi: isolate) שאף כלי לא נותן.
הפתרון המעשי: אל תצפו שהכלי יפתור RTL. עם Cursor/Claude דרך MCP פשוט תוסיפו להנחיה משהו כמו:
השתמש ב-logical CSS properties בלבד (margin-inline, padding-block, inset-inline).
הגדר dir="rtl" בשורש. אל תשתמש ב-left/right/margin-left/padding-right פיזיים.
עטוף מספרים, טלפונים ומיילים בתוך טקסט עברי ב-<bdi>.
עם פלאגינים: תייצאו, ואז תרוצו על הקוד ותחליפו ידנית, או תעבירו אותו דרך סוכן AI שיתקן. מי שרוצה להעמיק, יש לי מדריך נפרד על נגישות ו-RTL בעברית שמכסה גם את חוק הנגישות הישראלי.
6. מה מייצר קוד פרודקשן ומה זריק
זאת השאלה האמיתית. הנה החלוקה מהניסיון שלי.
קוד שאפשר לשלוח (עם עבודה)
- Cursor/Claude דרך MCP, קומפוננטה-קומפוננטה, עם הנחיות ברורות. אחרי code review וחיבור ל-design system, כן, זה הולך לפרודקשן.
- Locofy מ-Figma נקי עם Auto Layout מלא. קוד קריא שמפתח יכול לתחזק.
- Anima במצב AI עם shadcn, על קומפוננטה ממוקדת. הפלט שופר משמעותית; עדיין דורש מעבר אנושי, אבל הוא נקודת התחלה סבירה.
קוד שכמעט תמיד זורקים
- Anima export גולמי של דף שלם (בלי מצב AI). מבנה שטוח, absolute positioning, לא responsive באמת. טוב למוקאפ, רע למוצר.
- כל ״ייצוא דף שלם בלחיצה״ בלי code review. לא משנה הכלי, דף שלם בבת אחת מייצר בלגן.
- קוד מ-Figma מבולגן. garbage in, garbage out. שום כלי לא מתקן עיצוב לא מסודר.
הכלל שלי: אם זה מוקאפ או הצעת מחיר, ייצוא מהיר זה מצוין. אם זה הולך לחיות ולהתפתח, MCP עם סוכן, או Locofy/Anima מ-Figma נקי.
7. איפה מפתח עדיין חובה
זה החלק שמרגיע את מי שחושש, ומפכח את מי שחושב שהוא ייפטר מהמפתח. כל מה שמתחת אף כלי design to code לא נותן:
- לוגיקה ו-state. טפסים, ולידציה, ניהול state, מה קורה בלחיצה, הכלי מוציא UI סטטי, לא התנהגות.
- חיבור ל-data ו-API. העיצוב מראה ״רשימת מוצרים״; מאיפה הם נטענים, caching, error states, עליכם.
- Responsive אמיתי. הכלים מוציאים את ה-breakpoint שעיצבתם, לא את ההיגיון של למה הגריד עובר משלוש עמודות לאחת.
- נגישות, ביצועים, RTL. סמנטיקה, ARIA, ניווט מקלדת, lazy loading ו-RTL, כולם עבודה אנושית. כדאי לוודא שהתוצאה עומדת ב-Core Web Vitals של 2026, שאף כלי ייצוא לא דואג להם בשבילכם.
- אינטגרציה לקודבייס. routing, auth, env, deploy, מחוץ לתחום של כל הכלים האלה.
במילים אחרות: הכלים חתכו את הזמן שלי על ה-UI הסטטי בערך בחצי. הם לא נגעו בחצי השני, הלוגיקה, שהוא ממילא החלק הקשה.
8. ההמלצה שלי לפי תרחיש
| תרחיש | הכלי שאני בוחר | למה |
|---|---|---|
| מפתח בקודבייס React קיים | Cursor/Claude דרך Figma MCP, קומפוננטה-קומפוננטה | הכי קרוב לקוד שהייתם כותבים, משתמש בקומפוננטות קיימות |
| אגנציה שמייצרת הרבה מסכים ללקוחות | Locofy מ-Figma נקי | התמורה הכי טובה לייצוא קוד נקי וקריא |
| צוות שצריך גם CMS ו-A/B testing | Builder.io | שווה את המחיר רק אם משתמשים בשכבת ה-CMS |
| מעצב/לא-מפתח שרוצה פרוטוטייפ עובד | Figma Make | מהיר, אבל בטא מוגבלת ל-Mac, חד-כיוונית, לא לפרודקשן רב-משתמשים |
| מוקאפ או הצעת מחיר מהירה | Anima | מהיר, ויזואלי, וזורקים אחר כך בלי בעיה |
צריך גם נכסים ויזואליים לעיצוב עצמו, תמונות, אייקונים, רקעים? כתבתי על יצירת תמונות AI לעסקים שמשתלב יפה לפני שלב ה-Figma. ואם אתם שוקלים בכלל לדלג על Figma ולתת ל-AI לבנות מאפס, השוו את כלי ה-vibe coding ל-2026.
שאלות נפוצות
האם אפשר להפוך עיצוב Figma לקוד React אמיתי לפרודקשן?
כן, אבל לא בלחיצה אחת על דף שלם. הדרך שעובדת היא קומפוננטה-קומפוננטה, דרך Cursor/Claude עם Figma MCP או Locofy/Anima מ-Figma נקי, ואז code review וחיבור ל-design system. הקוד הגולמי שיוצא הוא נקודת התחלה טובה, לא מוצר מוגמר.
מה ההבדל בין Figma Make ל-Anima?
Anima הוא plugin שמתרגם פריים לקוד, ובמצב ה-AI החדש שלו מייצר קומפוננטות shadcn + Tailwind. Figma Make הוא סוכן AI שבונה אפליקציות עובדות ויכול לייבא repo, לערוך ולפתוח PR, אבל הזרימה הזאת היא בטא מוגבלת ל-Mac וחד-כיוונית. Make מתאים לפרוטוטייפים, Anima לייצוא מהיר של מסכים.
האם כלי design to code מטפלים נכון ב-RTL ועברית?
לא, אף אחד מהם לא מטפל ב-RTL כמו שצריך. כולם מוציאים properties פיזיים (margin-left, left) במקום לוגיים, לא מהפכים אייקונים, ולא מטפלים בערבוב עברית-אנגלית. צריך לתקן ידנית, או להנחות סוכן AI להשתמש ב-logical properties ו-dir=rtl מההתחלה.
כמה עולה Figma Make ב-2026?
Make רץ על AI credits. מסלול Professional כולל כ-3,000 קרדיטים בחודש למושב Full ($16 למשתמש), Organization 3,500 קרדיטים ($55), ו-Enterprise 4,250 ($90), בעוד מושבי Dev/Collab/View מוגבלים ל-500 קרדיטים. מ-18 במרץ 2026 Figma אוכפת מגבלות קרדיטים ברמת המושב, וקרדיטים נוספים עולים מ-$120 לחודש או $0.03 לקרדיט ב-pay-as-you-go.
האם Figma MCP טוב יותר מ-plugin רגיל?
לרוב כן, לפיתוח אמיתי. דרך MCP הסוכן קורא את המבנה האמיתי, node tree, variants, constraints ו-design tokens, במקום לנחש מ-screenshot. התוצאה קוד הרבה יותר אנושי, ועם Code Connect הוא משתמש בקומפוננטות הקיימות שלכם במקום לשכפל אותן.
האם אפשר לעבוד עם Figma Make על repo קיים בפרודקשן?
זהירות. ב-2026 יש בטא שמאפשרת לייבא repo קיים ולדחוף ממנו PR, אבל היא ל-Mac בלבד, חד-כיוונית (שינויים של מהנדס ב-IDE נדרסים אם מעצב דוחף מ-Make), וניהול ה-branches מוגבל. לקודבייס פרודקשן עם כמה מפתחים אני עדיין מעדיף MCP בתוך ה-IDE.
האם design to code מבטל את הצורך במפתח?
לא. הכלים חותכים את הזמן על ה-UI הסטטי, אבל לוגיקה, state, חיבור ל-API, responsive אמיתי, נגישות ו-RTL עדיין דורשים מפתח. הם כלי שמאיץ את החלק הקל, לא מחליף את החלק הקשה.
לסיכום
ב-2026 ״Figma לקוד״ באמת עובד, חלקית. הצעדים המעשיים: נקו את ה-Figma (Auto Layout, שמות, components, variables) לפני שמתחילים; בחרו גישה לפי התרחיש (MCP לקודבייס קיים, Locofy/Anima לייצוא, Make לפרוטוטייפים); עבדו קומפוננטה-קומפוננטה ולא דף שלם; הנחו במפורש להשתמש ב-logical properties ו-dir=rtl; ותמיד תעשו code review לפני merge. אל תצפו שהכלי יבנה לכם מוצר, הוא בונה UI סטטי, וכל מה שזז, נשמר ונקרא מ-API נשאר עבודה אנושית. אם אתם מתלבטים בין לבנות מ-Figma לבין לתת ל-AI לבנות מאפס, המדריך מתי כדאי להשתמש ב-vibe coding יעזור להחליט.