הפחד הקיומי
בואו נדבר על הפיל בחדר.
אתם פותחים LinkedIn וכל פוסט שני מדבר על Devin, Cursor, מודל חדש, או כלי שמבטיח לכתוב קוד טוב יותר מ-Senior Engineer. אתם מסתכלים על העבודה שלכם: selectors, scripts, pipelines, בדיקות regression, ואז עולה מחשבה קרה:
“אולי אני מיותר. בסוף זה רק טקסט. מכונה יכולה לייצר טקסט מהר ממני.”
אם הערך שלכם הוא “אני כותב סקריפטים”, אתם צודקים. אתם בסיכון.
אבל אם אתם מבינים איך enterprise software באמת עובד, אתם יודעים שקוד הוא החלק הקל. החלק הקשה הוא הכאוס.
חפיר הספגטי
אנחנו אוהבים לדבר על clean code, אבל רוב מערכות ה-production הוותיקות אינן מוזיאון של החלטות יפות. הן אתר ארכיאולוגי: תיקונים מהירים, פשרות זמניות שהפכו לקבועות, dependencies שאף אחד לא מעז לעדכן, וסיפורי מלחמה שלא כתובים בשום README.
דמיינו AI Agent שנכנס למערכת legacy. הוא רואה פונקציה ששומרת מידע ב-SessionStorage במקום דרך backend state מסודר.
ה-AI אומר: “זה לא נכון. אני אשפר את זה לקריאה נקייה ל-API.”
ואז production נופל.
למה?
כי ה-AI לא ידע שה-API הזה מכיל race condition ישן שמעולם לא תוקן. הוא לא ידע שה-hack ל-SessionStorage נכתב בגלל באג ספציפי ב-Safari לפני שלוש שנים. הוא לא ידע שהמודול הזה מוגדר אצל הארגון כ”אסור לגעת בלי rewrite מלא”.
AI רואה לוגיקה. הוא לא רואה הקשר.
וההקשר הזה הוא הסיבה שהתפקיד שלכם ממשיך להיות חשוב.
ממי שכותב קוד למי שמבקר סיכון
התפקיד של QA Engineer ושל Test Architect משתנה במהירות.
ב-2020 שילמו לנו כדי לכתוב קוד.
ב-2026 ישלמו לנו כדי לבקר קוד.
אנחנו עוברים מהידיים אל שומרי הסיכון. כאשר AI מסוגל לייצר אלף שורות קוד בדקה, הסיכון לבאגים לוגיים עדינים מזנק. המודל מייצר כמות. אתם אחראים על שער האיכות.
תיאור התפקיד החדש אינו “לכתוב אוטומציה”. הוא:
- Guardrails: להגדיר גבולות קשיחים שבתוכם AI רשאי לפעול.
- Context Injection: להזין למודל את הידע השבטי שלא נמצא בתיעוד.
- האדם שאומר לא: להיות מי שמסוגל לומר “הקוד נראה מושלם, אבל הוא מתעלם ממגבלת business של משתמש מסוג X, ולכן הוא לא נכנס”.
פקטור ה-”אני מניח”
לא מזמן ראיתי קוד עם הערה: “I guess this works because…”
זו אחת ההערות האנושיות ביותר שיש. היא מבטאת אי ודאות, פחד וחוסר ownership.
מודלי AI לא “מנחשים” מתוך פחד. הם מייצרים הסתברות. הם עלולים להזות פתרון שנראה יפה, במיוחד כשהם לא מבינים את המגבלות הרכות של הארגון: פוליטיקה בין צוותים, deadlines, פחד משבירת flow ישן, או workaround שאף אחד לא אוהב אבל כולם תלויים בו.
AI פורח בסביבה סטרילית. הוא טובע בביצה של enterprise IT אמיתי.
ואתם? לכם יש מגפיים.
למה ארכיטקט לא נעלם
אם הערך שלכם הוא “אני יודע לכתוב Playwright syntax”, אתם בבעיה. המודל יכתוב syntax מהר יותר.
אבל אם הערך שלכם הוא:
- להבין ארכיטקטורה.
- לנהל סיכון.
- להגדיר מהו signal ומהו noise.
- להבין מה business באמת צריך.
- לוודא שהפלט של AI מתאים למציאות ולא רק לקומפיילר.
אז אתם עומדים להפוך לאנשים החשובים ביותר בחדר.
AI לא מחליף את ארכיטקט הבדיקות. הוא מגדיל את הצורך בו.
סיכום: להשתדרג או להיעלם
אל תפחדו מ-AI. תנו לו לכתוב boilerplate. תנו לו ליצור selectors. תנו לו להציע refactor.
אבל אל תתנו לו להחזיק את המפתחות לשער.
המפתח לעתיד הוא לא להיות מי שמקליד הכי מהר. המפתח הוא להיות מי שמבין מה אסור לאפשר, איפה הסיכון, ואיזה ראיות צריך לפני שממזגים.
קוד הוא זול.
הקשר הוא המלך.
ואדריכלות היא הכתר.
רוצים להבין איך בונים את השערים האלה בפועל? התחילו מהמדריך שלי על בניית שער איכות לפני מיזוג.
