הזול שעולה ביוקר: למה המודל הסיני המדובר עדיין לא מוכן להחליף את קלוד?

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

ההבטחה הגדולה של המודלים הסיניים החדשים היא שבירת שוק מוחלטת בכל הנוגע לעלויות ה-API. כדי לסבר את האוזן, בסביבת העבודה שלי ב-VS Code (שם עבדתי עם קלוד ועם תוסף CLINIC עבור ה-DeepSeek), מנוי של 20 דולר בקלוד יעניק לכם עבודה עם כ-4 עד 5 מיליון טוקנים. אותה כמות בדיוק תעלה לכם ב-DeepSeek שקלים בודדים.

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

עיוורון ארכיטקטוני ועיצוב שנשאר בעבר

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

מעבר לכך, רמת העיצוב (UI/UX) שהמודל מייצר פשוט לא רלוונטית לשנת 2026. התוצרים שלו מזכירים אתרי אינטרנט או ממשקים מלפני עשור. הבעיה מחריפה כשמדברים על התאמה למובייל – בעולם שבו הכל חייב להיות רספונסיבי, הקוד של המודל פשוט לא נראה טוב על מסכים קטנים ודורש התערבות ידנית מסיבית כדי להתאים אותו לסטנדרט המינימלי המקובל היום.

מהיר אך טועה: חוויית הפיתוח מול "העובד הסיני" המתוכנת

במהלך העבודה נתקלתי בכמה דוגמאות מתסכלות במיוחד שהמחישו את הפער הקיים:

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

2. חוסר מודעות ויזואלית בסיסית: כשביקשתי ממנו להפוך מילה מסוימת בטקסט לקישור (Link), הוא אכן שינה את תג ה-HTML לקישור תקין, אך לא הוסיף שום עיצוב, קו תחתון או שינוי צבע. הקישור הפך לבלתי נראה לחלוטין עבור המשתמש משום שהמודל חסר את ה"הבנה העיצובית" שיש לקלוד.

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

ספירלת התיקונים: איך הזול הופך ליקר

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

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

הנה טבלת השוואת העלויות המדויקת:

המבחן הכבד: אוטומציות עמוקות וקריאת קוד מורכב

כדי לאתגר את ההבטחה הכלכלית עד הקצה, החלטתי לבחון את המודל גם בשילוב בתוך אוטומציות פיתוח עמוקות (תהליכי CI/CD מורכבים) ובקריאת בסיס קוד קיים, כבד ועמוס.

זרקתי אליו מערכת שלמה הכוללת עשרות אלפי שורות קוד, רק כדי לבדוק את יכולת ניתוח ההקשר (Context Window) שלו בפרויקטים אמיתיים. הרצתי פקודה ראשונה ובסיסית ביותר – בקשה לסרוק ולמפות את המערכת כדי להבין את הארכיטקטורה והתלויות הקיימות.

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

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

הכנסת מפתח לא מנוסה לקוד של מפתח מומחה

ברגע ש-DeepSeek התחיל לגעת בבסיס הקוד הקיים, התחושה הייתה זהה לחלוטין להכנסת מפתח מתחיל (ג'וניור) חסר ניסיון לפרויקט מהודק שנכתב על ידי מפתח מומחה. במקום להבין את דפוסי העבודה (Design Patterns) ולשמור על הסטנדרט הגבוה של הפרויקט, המודל התחיל להזריק פקודות לא יעילות, לייצר לוגיקה מסורבלת ולכתוב מידע בצורה שפחות מקובלת היום בתעשייה – תהליך שבסופו של דבר פשוט הרס קוד מיומן ונקי.

הנה כמה דוגמאות בולטות מהשטח:

• שימוש בשיטות מיושנות במקום בסטנדרט מודרני: במקרים שבהם נדרש סינון או מניפולציה על נתונים, במקום להשתמש בפונקציות מערך מובניות, מודרניות ויעילות (כמו map או filter), המודל בחר לכתוב לולאות ארוכות, מסורבלות וקשות לתחזוקה.
  

• שבירת ניהול המצבים (State): במקום להשתמש במערכת ניהול המצבים האלגנטית והמסודרת שכבר הייתה קיימת ומבוססת בקובץ, המודל ניסה לפתור בעיות דרך יצירת משתנים מקומיים או גלובליים מיותרים שעלולים לגרום בקלות להתנגשויות מידע.
  

• זיהום הקוד וסרבול קריאות: במקום לכתוב קוד נקי שמסביר את עצמו (Self-documenting code) כנהוג אצל מפתחים בכירים, המודל נטה לייצר קטעי קוד ארוכים מהנדרש כדי לבצע פעולות פשוטות, מה שהעמיס מאוד על הקריאות ועל היכולת של מפתח אנושי להבין את הלוגיקה במבט מהיר.

מילים ללא נשמה: מבחן התוכן בעברית

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

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

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