אנו נמצאים בנקודת מפנה בפיתוח תוכנה. הדיון לעיתים קרובות עוסק ב איזה האם ה-AI כותב את הקוד הטוב ביותר (Claude מול ChatGPT) או איפה איפה ה-AI צריך להימצא (IDE או CLI). אבל זו לא השאלה הנכונה.
הבעיה אינה ה יצירה של הקוד. הבעיה היא ה אימות שלו.
אם נאמץ את ה-AI כ"מאפרי וייב" – שבהם אנו מגדירים את הכוונה וה-AI מבצע את הביצוע – נייצר זרם עצום של תוכנה חדשה. להקת סוכני AI יכולה ליצור בדקה יותר קוד ממה שמפתח בכיר יכול לעבור על פני שבוע. האדם הפך לצוואר הבקבוק.
הפתרון אינו עוד אנשים. הפתרון הוא סמכות העיצוב של ה-AI.
באופן מסורתי "רשות העיצוב" היא קבוצה של ארכיטקטים שנפגשים פעם בשבוע או בחודש כדי לאשר או לדחות עיצוב. בעולם של פיתוח בינה מלאכותית במהירות גבוהה המודל הזה מיושן לחלוטין. הוא איטי מדי ותגובתי מדי.
כאשר נעבור ל"קוד שמתכלה" — תוכנה שאותה לא נמשש מחדש כל הזמן, אלא זורקים ומייצרים מחדש כשהדרישות משתנות — התפקיד שלנו משתנה באופן יסודי. אנחנו לא עוד بناים שמניחים לבן לבן. אנחנו הארכיטקטים של המפעל שמדפיס את הקירות.
אבל מי בודק שהקירות עומדים ישר?
רשות עיצוב מבוססת בינה מלאכותית היא לא אדם, אלא צינור הפעלה. "מחרשה" שכל שורת קוד שנוצרת צריכה לעבור כדי להגיע לייצור. תהליך זה לא מחליף את ביקורת הקוד האנושית ב אין דבר, אלא במשהו טוב יותר.
זה עובד בשלוש שכבות:
1. הסמכות המבצעת (ההולדה)
אנחנו לא מבקשים מ-AI יחיד פתרון; אנחנו מבקשים שלושה. אנחנו משווים בין Gemini 3, GPT-5 ומודל קוד פתוח (כמו Llama) שעובדים במקביל על אותה הבעיה. זה מונע ראיית מנהרה ושובר את ה"עצלות" שלפעמים מודלים שפתיים סובלים ממנה. גישה זו גם נחקרה באופן מדעי ומראה שאפשר למנוע הלוצינציות של AI ולבנות שרשראות ארוכות מאוד בלי שגיאות
2. המסנן הקשיח (החוק)
אין כאן מקום לוויכוח. הקוד חייב להידחס. כלי הלינטרים לא יכולים להתלונן. וחיוני: ה מבחני קופסה שחורה חייבים לעבור. אנחנו לא בודקים אם הפונקציה עובדת פנימית (זה עלול לאפשר מניפולציה של ה-AI), אנחנו בודקים האם המערכת מבחוץ עושה מה שצריך. האם המבחן נכשל? ישר לפח.
3. המסנן הרך (המושבעת של ה-AI)
זוהי החידוש האמיתי. הפתרונות שנותרו מועברים ל"בחירת מצביעים" של AI מתמחה. הסוכן הזה לא כותב קוד, אלא קורא קוד. הוא מאומן על עקרונות הארכיטקטורה שלנו, דרישות אבטחה (OWASP, ISO) וכללי ציות (חוק ה-AI של האיחוד האירופי).
הוא מצביע: "פתרון A מהיר יותר, אבל פתרון B בטוח יותר ועוקב טוב יותר אחרי ארכיטקטורת המיקרו-שירותים שלנו."
המנצח עובר לפרודקשן.
המודל הזה אוכף הפרדת רשויות שחסרה בהרבה צוותים.
project-description.md, rules.md, skills.md en principles.md), הדרישות הקשיחות. הארכיטקט קובע מה מה אנחנו בונים, מי בונה את זה, איך ו למה.
הוא משחרר אותנו מטירנות שגיאות הסינטקס ומאפשר לנו להתמקד במה שאנחנו טובים בו: חשיבה מערכתית. איתור אמת. מבנה וקבלת החלטות.
השאלה אינה אם ה-AI יכול לכתוב את הקוד שלנו. סוגיה זו כבר נסגרה. הקוד יהפוך ברובו למוצר שנזרק.
השאלה היא: האם אתה מעז לוותר על השליטה ב־ קוד להניח, כדי להשיב את השליטה על ה איכות להשיב שוב?
תן לי לדעת