הבלוג של ינון פרק

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

את הדוח עצמו אפשר למצוא כאן: https://www.taasuka.gov.il/media/oauod4pb/hitech_report.pdf

הוא מרתק ומלא בנתונים אבל הנתון היחיד שעניין אותי לא היה שם. מצאתי אותו בסקירה הזו של דה מרקר (דורש מנוי לקריאה):

https://www.themarker.com/career/2026-07-07/ty-article/.premium/0000019f-377d-d07c-af9f-ff7dcc840000?fromLogin=success

זה המשפט:

לפי נתוני הלשכה המרכזית לסטטיסטיקה, כיום מוצעות 13.8 אלף משרות בענף ההייטק, ועוד כ־4,000 משרות "שירותי הייטק", שהן משרות טכנולוגיות בענפים לא-טכנולוגיים.

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

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

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

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

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

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

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

בפרק האחרון של rework דייויד הנסן מדבר על פיתוח משולב AI ב 37 Signals.

https://37signals.com/podcast/ai-challenges-in-software/

אלה הדברים המרכזיים שאני לוקח מהפרק:

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

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

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

4. אם תתנו ל AI לכתוב קוד ללא השגחה התוצאה תהיה בלאגן. או במילים של DHH:

The problem is if you just keep doing that, if you keep asking the monkeypaw for more wishes, you’re going to get a distorted code base.

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

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

נתחיל בעובדות. אפשר לחבר לקלוד שרתי MCP שרצים ברשת דרך מסך ה Connectors בקישור הזה:

https://claude.ai/customize/connectors

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

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

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

1. מישהו כתב איפיון לא מספיק מדויק.

2. סוכן קידוד השלים את הפערים תוך התבססות על הנחת עבודה לא נכונה (שם חייב להיות ASCII תקני).

3. אנשי QA פספסו את הבעיה כשבדקו את המערכת באוויר.

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

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

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

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

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

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

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

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

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

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

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

https://github.com/ynonp/fable-coloring-app

נשים לב-

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

const circlePath = (cx: number, cy: number, r: number) =>
  `M ${cx + r} ${cy} a ${r} ${r} 0 1 1 ${-2 * r} 0 a ${r} ${r} 0 1 1 ${2 * r} 0 Z`;

זה נפלא עד שנזכרים שב SVG יש כבר circle שהיה עובד יותר טוב לבד. עכשיו אני מבין למה הוא כתב את זה ככה - היתה לו אבסטרקציה גרועה שהוא יצר (הפונקציה R שם אם תכנסו להסתכל על הקוד) והוא המשיך איתה את כל התוכנית.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. חפשו מבנה פרויקט שלא מתאים לקוד שרציתם. קובץ אחד איפה שהיה צריך להפריד לכמה קבצים, כל הפונקציות במקום אחד במקום פונקציה בכל קובץ, עיצוב ב CSS במקום בטיילווינד (או בלוק style במקום קובץ CSS). כל פער כזה זו הזדמנות - נוסיף אותו לפרומפט או לקובץ פרומפט קבוע כמו AGENTS.md כדי לשפר את כל הקוד העתידי שניצור.

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

חבר מקשה - "לכתוב קוד היום זה משעמם. אתה רק מבקש משהו מה AI ויש לך את הקוד. עבודה שפעם לקחה זמן וחשיבה היום עושים כלאחר יד. זה לא מעניין".

אז שאלתי בחזרה - "נו אז מה כתבת מעניין עם ה AI"?.

שתיקה.

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

ברור שאפשר לכתוב היום בשעתיים POC שפעם היה דורש כסף זמן ומפתחים.

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

אבל שווה להכיר גם ש 50-70% מהעובדים בחברות לא מנצלים את תקציב הטוקנים שלהם. לא משתמשים בסוכני קידוד כדי להתקדם במהירות שהמנהלים שלהם רוצים שהם יתקדמו. הם אולי נוסעים באוטו אבל עדיין במהירות 15 קמ"ש.

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

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

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

התכונות הטובות של Repid כוללות:

1. משימות אסינכרוניות (כמובן, בשביל זה באנו).

2. תמיכה טובה בבדיקות עם רכיב TestClient.

3. תיעוד ידידותי לסוכנים עם קבצי llms.txt ו llms-full.txt.

4. חיבור מובנה ל pydantic בשביל הגדרת טיפוסים.

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

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

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

2. בסיסי נתונים - מפתחות זרים ו Sequence-ים בבסיסי נתונים מבינים למצב שקשה לי מאוד לשנות היסטוריה אחרי שהיא קרתה. בעתיד אנחנו נצטרך למצוא דרך להוציא "ענף" מגרסה ישנה של בסיס הנתונים ולהלביש את הנתונים החדשים על השינוי שנבצע בהיסטוריה.

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

המשמעות של להוציא את המפתחים מהלופ ולוותר על צוואר הבקבוק של Code Reviews היא היכולת להתחרט ולתקן טעויות של סוכנים. גיט הומצא במקרה ב 2005. הענן של AWS הוקם ב 2002. טרפורם ב 2014. אין סיבה להניח שהכלים האלה יישארו איתנו לעד.