מומחה AI לפיתוח: האדם שמחבר בין קוד, תשתיות, אבטחה ומוצר שעובד

הקוד נהיה מהיר. האחריות לא

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

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

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

סקר המעסיקים של רשות החדשנות ל־2026 ממחיש את הפער. 52% מחברות ההייטק שהשתתפו דיווחו על הטמעה משמעותית של AI בתהליכי עבודה טכנולוגיים, אך רק 13% דיווחו על הטמעה רוחבית מלאה בארגון. 42% כבר מעסיקות עובדים בתפקידי AI ייעודיים. כלומר, השאלה כבר אינה האם להשתמש ב־AI, אלא מי יודע להפוך שימוש נקודתי ליכולת הנדסית וארגונית אמינה.

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

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

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

נקודת המבט שממנה נכתב המאמר

הדברים שאני כותב כאן מבוססים על כ־20 שנה של עבודה בתשתיות ובפיתוח, כולל ניהול של מעל 2,000 אתרים, יישומים ושרתים. במהלך השנים עבדתי עם WordPress, PHP, TypeScript, Python, PostgreSQL, Docker ו־Kubernetes, ובשנים האחרונות אני בונה מערכות AI שמתחברות לתהליכים עסקיים אמיתיים.

הניסיון הזה לימד אותי שוב ושוב שהדגמות מרשימות עם AI מתפרקות לעיתים קרובות ברגע שהן פוגשות משתמשים אמיתיים, כסף או מידע רגיש. לכן השאלה המרכזית בעיניי אינה ״באיזה מודל נשתמש?״, אלא ״איך בונים מערכת שאפשר לסמוך עליה לאורך זמן?״

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

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

משתמש AI, וייב קודר, מפתח ומומחה מערכת — לא אותו תפקיד

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

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

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

פיתוח בהנחיה טבעית הוא מאיץ אדיר — אבל אינו תחליף להנדסה

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

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

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

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

אילו שפות תכנות וכלים צריך להכיר?

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

TypeScript ו־Node.js

TypeScript ו־Node.js מתאימות מאוד למוצרי רשת מודרניים, לממשקי תכנות, למערכות בזמן אמת ולפיתוח מקצה לקצה עם טיפוסים משותפים. בשילוב Next.js ו־React אפשר לבנות ממשק, שכבת שרת וחיבורים לשירותים בשפה מרכזית אחת.

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

Python

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

לעיתים נכון שכל המערכת תהיה ב־Python. במקרים אחרים עדיף להשתמש בה בשירות ממוקד שמתחבר למוצר שנכתב ב־TypeScript, PHP, Java או .NET. אין סיבה להכניס את כל המערכת לשפה מסוימת רק משום שהרכיב שמפעיל את המודל נכתב בה.

PHP, WordPress ו־Laravel

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

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

SQL, PostgreSQL ו־pgvector

SQL ו־PostgreSQL הם לעיתים הלב האמיתי של המוצר. מודל מרשים לא מפצה על מבנה נתונים חלש, הרשאות שגויות או שאילתות שלא מחזיקות עומס.

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

שפות וכלים תפעוליים

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

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

הארכיטקטורה חשובה יותר מהמודל

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

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

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

במערכת אמיתית מתכננים גם את המצבים הלא יפים:

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

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

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

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

בחירת ספק AI היא החלטת ארכיטקטורה ופרטיות

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

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

לפני בחירה אני בודק:

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

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

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

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

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

אבטחה אינה בדיקה בסוף — היא דרך התכנון

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

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

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

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

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

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

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

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

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

כך נראה תהליך פיתוח נכון מקצה לקצה

1. מתחילים מהבעיה ומהמדד

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

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

2. ממפים תהליך, מידע וסיכון

מתעדים מאיפה מגיע המידע, מי הבעלים שלו, מה רמת הרגישות, לאילו מערכות צריך להתחבר ומי רשאי לבצע כל פעולה.

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

3. מתכננים ארכיטקטורה ובוחרים ספקים

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

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

4. בונים אב־טיפוס עם תנאי הצלחה ותנאי עצירה

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

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

5. הופכים את האב־טיפוס למוצר

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

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

6. בונים מערך בדיקות והערכות

לצד בדיקות תוכנה רגילות יוצרים סט מקרים קבוע לבדיקת איכות המודל:

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

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

7. מבצעים פריסה מבוקרת

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

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

8. מטמיעים בתוך העבודה האמיתית

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

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

9. מפעילים, מודדים ומשפרים

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

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

מה חייבים לראות בסביבת ייצור?

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

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

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

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

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

איך בוחרים מומחה AI לפיתוח?

אל תתחילו מרשימת סמלי הטכנולוגיות באתר שלו. בקשו לראות איך הוא חושב.

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

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

כדאי לבדוק גם מי מבצע בפועל:

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

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

השורה התחתונה

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

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

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