השלמת פרויקט שנבנה בכלי AI מאב-טיפוס מ-Lovable או Bolt לאפליקציה שעולה לאוויר

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

הביקורת מכסה את מה שמסכן עסק אמיתי: מפתחות API וסודות שנשארו בקוד או בצד הלקוח, התחברות והרשאות, כללי גישה ברמת השורה (RLS) בבסיס הנתונים, אימות קלט, העלאת קבצים, חשיפת מידע אישי ותלויות עם פגיעויות ידועות. מקבלים רשימת ממצאים לפי חומרה ומה תוקן בכל אחד. קוד שנוצר ב-AI משאיר לא פעם בסיס נתונים פתוח לקריאה לכל מי שיודע לשאול, ולכן זה השלב הראשון. כשהאפליקציה מחזיקה מידע אישי, מתחשבים גם בעקרונות תיקון 13. התיקונים נבדקים מחדש אחרי ביצועם כדי לוודא שהפרצה נסגרה.

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

עובדים על כל סטאק, ולא מחייבים אתכם לעבור לטכנולוגיה שלנו. פרויקטים שמגיעים מ-Lovable, Bolt, v0, Replit, Cursor או Base44 בנויים לרוב על React או Next.js עם Supabase או Firebase כשרת, ואנחנו ממשיכים בהם כפי שהם. אם יש סיבה טובה להחליף רכיב, למשל בסיס נתונים שלא מתאים לצמיחה, מציגים אותה בכתב יחד עם החלופות ומחכים להחלטה שלכם. הקוד נשאר במאגר שלכם ובחשבונות שלכם, כך שאפשר להמשיך עם כל מפתח אחר. בסוף השיחה הראשונה תדעו אם המבנה הקיים מתאים להמשך.

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

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