WEBVTT

00:00:00.000 --> 00:00:03.980
מה אם לצוות פיתוח התוכנה שלכם היה חבר צוות נוסף, כזה שלעולם לא מתעייף,

00:00:04.140 --> 00:00:07.720
לומד מהר יותר מכל מי שאתם מכירים, ומבצע את העבודה המשעממת בלי תלונות?

00:00:07.900 --> 00:00:10.580
זהו בדיוק מה שבינה מלאכותית סוכנתית הולכת להיות.

00:00:10.820 --> 00:00:14.440
בסרטון הזה, נגדיר תחילה מה המשמעות האמיתית של בינה מלאכותית סוכנתית,

00:00:14.680 --> 00:00:17.800
נראה כיצד היא באה לידי ביטוי בתהליכי עבודה אמיתיים ב-net וב-azure,

00:00:17.960 --> 00:00:21.100
ולבסוף נבחן את ההשפעה שלה על הפרודוקטיביות של הצוות שלכם.

00:00:21.100 --> 00:00:25.240
עד הסוף, תדעו על ניסוי קטן אחד שאפשר לנסות בצינור הנט שלכם עוד השבוע.

00:00:25.360 --> 00:00:32.540
אבל לפני שנגיע ליישומים ולתוצאות, עלינו לבחון מה באמת הופך בינה מלאכותית סוכנתית לשונה מכלי ההשלמה האוטומטית שכבר ראיתם.

00:00:32.680 --> 00:00:34.920
מה הופך בינה מלאכותית סוכנתית לשונה?

00:00:35.080 --> 00:00:38.640
ובכן, מה שמייחד בינה מלאכותית סוכנתית הוא לא רק היכולת שלה ליצור קוד,

00:00:38.640 --> 00:00:42.100
אלא העובדה שהיא פועלת יותר כמו מערכת של חברי צוות עם יכולות מוכנו.

00:00:42.100 --> 00:00:47.440
כדי להבין זאת, נחלק זאת לשלוש תכונות מפתח, הדרך שבה כל סוכן שומר הקשר וזיכרון,

00:00:47.680 --> 00:00:53.300
הדרך שבה סוכנים מרובים מטעמים פעולה כצוות, וההבדל בין אוטומציה פשוטה לאוטונומיה מסתגלת אמיתי.

00:00:53.440 --> 00:00:58.400
ראשית, בואו נבחן מה הופך סוכן בודד לייחודי, הקשר, זיכרון ומכיוונות מטרה.

00:00:58.400 --> 00:01:04.400
השלמה אוטומטית מסורתית חוזה את המילה או השורה הבאה, אך היא שוכחת כל דבר אחר ברגע שהתחזית בוצעה.

00:01:04.460 --> 00:01:05.560
סוכן בינה מלאכותית.

00:01:05.560 --> 00:01:08.440
לעומת זאת, נושא איתו הבנה של הפרויקט הרחב יותר.

00:01:08.640 --> 00:01:13.700
הוא זוכר מה כבר נושא, יודע היכן נמצא הקוד, ומתאים את הפלט שלו כאשר משהו משתנה.

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

00:01:20.640 --> 00:01:23.320
ההבדל המרכזי כאן הוא בין חיזוי לבין תכנון.

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

00:01:28.640 --> 00:01:31.440
הבא בתור הוא האופן שבו סוכנים מרובים עובדים יחד.

00:01:31.580 --> 00:01:36.760
אי הבנה גדולה היא לחשוב על בינה מלאכותית סוכנתית כעל סקריפט פיתוח או מקרו שרק ממקן משימות חזרתיות.

00:01:36.940 --> 00:01:40.420
אבל בפרויקטי תוכנה אמיתיים, העבודה מפוצלת בין תפקידים שונים.

00:01:40.420 --> 00:01:48.240
אדריכלים, סוכרים, בודקים, מפעילים סוכנים יכולים לשקף את החלוקה הזו, כשכל אחד מטפל בחלק ממחזור החיים בדיוק מושלם ועקביות.

00:01:48.240 --> 00:01:54.860
דמיינו סוכן אחד שמוקדש לייצוב מערכות ומציע דפוסי ארכיטקטורה ותשתיות שמתאימים ליעדים העסקיים.

00:01:55.100 --> 00:01:59.900
אחר סוכר שינויי קוד, מאתר בעיות תוך שהוא מודע להיסטוריה המלאה של הפרויקט.

00:01:59.900 --> 00:02:06.080
שלישי יכול להרחיב את כיסוי הבדיקות בהתבסס הנתוני משתמשים וליצור מקרי בדיקה מבלי שתצטרכו לבקש אותם.

00:02:06.200 --> 00:02:12.620
כל סוכן הוא מתמחה, אך הם מטעמים פעולה כצוות, זמינים תמיד, עקביים תמיד וניתנים להרחבה בקלות בהתאם לעומס העבודה.

00:02:12.620 --> 00:02:18.480
במקום שבו בני אדם מאבדים אנרגיה, הקשר או ריכוז, סוכנים נשארים יציבים וזוכרים פרטים בדיוק רב.

00:02:18.640 --> 00:02:21.640
החלק האחרון הוא ההבחנה בין אוטומציה לאוטונומיה.

00:02:21.780 --> 00:02:24.020
אוטומציה קיימת מזמן בעולם הפיתוח.

00:02:24.020 --> 00:02:27.080
חישבו על סקריפטים, צינורות C, CD ותבניות.

00:02:27.240 --> 00:02:28.740
אלו נוקשים מעצם תכנונם.

00:02:28.900 --> 00:02:33.800
הם עוקבים אחרי הוראות מדויקות צעד אחר צעד, אך הם נשברים כשתנאים משתנים באופן בלתי צפוי.

00:02:33.940 --> 00:02:35.720
אוטונומיה נוקטת בגישה אחרת.

00:02:35.720 --> 00:02:43.880
סוכני AI יכולים להגיב לשינויים תוך כדי תנועה, להתאים את עצמם כשגרסת לוט משתנה או לשקול מחדש בחירת שירות כשמגבלות עלות נכנסות לתמונה.

00:02:44.060 --> 00:02:48.180
במקום לבצע נתיבים מוגדרים מראש, הם מקבלים החלטות בתנאים דינמיים.

00:02:48.180 --> 00:02:51.560
זהו מעבר מביצוע סטטי לפתרון בעיות אדפטיבי.

00:02:51.660 --> 00:02:55.540
ההשפעה ארוכת הטווח היא שסוכנים אלו אינם רק מחכים לפקודות.

00:02:55.540 --> 00:03:02.960
הם יכולים להציע פתרונות כשמתעוררות בעיות, להדגיש סיכונים לפני שהם מגיעים ליצור ולנסח תוכניות שחוסכות שעות של עבודת הגדרה.

00:03:02.960 --> 00:03:14.480
אם הג'יפאב קופיילוט של היום יכול להשלים קטעי קוד, הגרסה של מחר תפעל יותר כמו תורם לפרויקט, תתווה מפות דרכים, תציע אסטרטגיות שחרור ואפילו תטריע על החלטות ארכיטקטוניות שעלולות לגרום לבעיות בעתיד.

00:03:14.480 --> 00:03:24.940
זה לא אומר שכל פריסה תרוץ ללא כלת אנושי, אך זה יכול להפחית משמעותית התערבות חוזרת ולתת למפתחים יותר זמן להתמקד בחלקים היצירתיים ובעלי הערך של הפרויקט.

00:03:24.940 --> 00:03:40.980
כדי להבהיר ניסוח מוקדם יותר בתחום זה, במקום לומר מה קורה כשאספקת משאבי Azure לא דורשת אדם בתהליך כלל, הצהרה מדויקת יותר תהיה, כלים אלו יכולים לצמצם את כמות ההגדרה הידנית הנדרשת תוך שמירה על גדרות בטיחות מרכזיות בשליטה אנושית.

00:03:40.980 --> 00:03:46.100
התוצאה עדיין טרנספורמטיבית מבלי לרמוז שהפיקוח האנושי נעלם לחלוטין.

00:03:46.100 --> 00:03:51.540
ההבנה הגדולה יותר היא ש-AI סוכני הוא לא רק עוד תוסף שמזרז משימה כזו או אחרת.

00:03:51.660 --> 00:03:59.980
הוא מתחיל לתפקד כמו חבר צוות אמיתי, מטפל בעבודת רקע כך שהמפתחים לא תקועים במרדף אחרי פרטים שיכלו להיות מנותרים על ידי אמית שתמיד זמין.

00:04:00.120 --> 00:04:06.080
היכולת של הצוות כולו מועצמת מכיוון שתחומים מרכזיים כוללים סוכנים דיגיטליים שעובדים לצד מומחים אנושיים.

00:04:06.080 --> 00:04:11.020
הבנת התיאוריה חשובה, אך מה שבאמת משנה זה איך זה בא לידי ביטוי בסביבות מוכרות.

00:04:11.040 --> 00:04:12.540
אז, הנה פער הסקרנות.

00:04:12.760 --> 00:04:16.780
מה באמת משתנה ביום הראשון של פרויקט חדש כשהסוכנים פעילים מההתחלה?

00:04:16.940 --> 00:04:24.600
בהמשך, נסתכל על תרחיש מוחשי בתוך העקו סיסטם של נט, שבו השינויים האלה מתחילים להופיע עוד לפני שכתבת את שורת הקוד הראשונה שלך.

00:04:24.740 --> 00:04:27.500
דמיון מחדש של תהליך העבודה של המפתח בנט.

00:04:27.500 --> 00:04:32.260
בפיתוח בנט, השינוי הנראה לעין מתחיל בדרך שבה פרויקטים יוצאים לדרך.

00:04:32.440 --> 00:04:36.760
דמיון מחדש של תהליך העבודה של המפתח כאן מסתכם בשלושה יתרונות טקטיים.

00:04:36.940 --> 00:04:42.700
פיגום ארכיטקטוני מהיר יותר, ביקורת ברמת הפרויקט תוך כדי תנועה וירידה מורגשת בעייפות ההגדרה.

00:04:42.840 --> 00:04:44.200
הראשון הוא פיגום מועץ.

00:04:44.380 --> 00:04:51.800
במקום לפתוח את Visual Studio ולבהות בפתרון REC, סוכן בינה מלאכותית יכול להציע אפשרויות ארכיטקטורה שמתאימות לתרחיש השימוש הספציפי שלך.

00:04:51.800 --> 00:04:58.800
בתכנון API לאינטרנט עם עדכונים בזמן אמת, הסוכן מציע עיצוב שכבות נקי ומצביע על האופן שבו סיגנלור משתלב באופן טבעי בזרימה.

00:04:58.920 --> 00:05:05.980
עבור אפליקציה פיננסית, הוא יכין מראש Entity Framework עם בטיחות טיפוסים חזקה ושילוב Azure Active Directory עוד לפני שיצרת תיקייה אחת.

00:05:06.060 --> 00:05:10.860
מה שבדרך כלל דורש סבבי דיונים או שעות של מחקר, מתומצת לכמה נקודות התחלה מותאמות אישית.

00:05:11.000 --> 00:05:13.040
אלו אינן תוכניות עבודה סופיות עם זאת.

00:05:13.160 --> 00:05:13.960
אלו הן טיוטות.

00:05:13.960 --> 00:05:17.340
צוותים צריכים לאמת כל הצעה על ידי הרצת צ'קליסט מהיר.

00:05:17.460 --> 00:05:18.860
האם האימות עומד בדרישות?

00:05:18.980 --> 00:05:21.140
האם הרישום, לוגינג, מחובר כראוי?

00:05:21.240 --> 00:05:22.960
האם קיימים מקרי בדיקה בסיסיים?

00:05:23.160 --> 00:05:26.440
משילות קלה זו מבטיחה שמהירות לא תבוא על חשבון יציבות.

00:05:26.580 --> 00:05:28.800
היתרון השני הוא ביקורת מתמשכת.

00:05:29.160 --> 00:05:33.540
חשוב על זה פחות כהשלמת קוד ויותר כיועץ שמשגיח על התאמה עיצובית.

00:05:34.180 --> 00:05:39.840
אם תקים תבנית Repository לגישה לנתונים, הסוכן יסמן אם אתה סוטה מעקרון הפרדת האחריות.

00:05:39.840 --> 00:05:46.000
אוסף בקר, קונטרולר, חדש והוא יציע בדיקות יחידה תואמות או ידגיש חוסר עקביות מול שאר הפרויקט.

00:05:46.080 --> 00:05:52.020
במקום להשאיר עוד חימקוד תבניתי, הוא דוחף את מבנה המערכת שלך לעבר תבניות ברות תחזוקה עם קול קומית.

00:05:52.240 --> 00:05:57.840
לצורך ניסוי מעשי, נסה להפעיל את Copilot ב-Visual Studio על אב טיפוס קטן של ASP NetCore.

00:05:58.500 --> 00:06:02.400
לאחר מכן, השווה כמה זמן לוקח לך להגיש את הבקשה המשמעותית הראשונה,

00:06:02.400 --> 00:06:05.880
Endpoint 1 עם עימות ושמירת נתונים לעומת ביצוע הכל ידני.

00:06:06.100 --> 00:06:14.100
זו לא ערובה לחיסכון בזמן, אך ביצוע התרגיל זה לצד זה בסביבה שלך הוא לרוב הדרך המהירה ביותר לעמוד אם לסוכנים האלה יש השפעה מהותית.

00:06:14.280 --> 00:06:17.740
היתרון השלישי הוא הפחתת ההגדרה הראשונית והאומס הקוגניטיבי.

00:06:17.860 --> 00:06:20.380
חלק גדול מהעבודה המוקדמת בפרויקט הוא חזרתי.

00:06:20.640 --> 00:06:26.400
חיבור תובכת עימות, משיכת חבילות נוגט, הגדרת רישום עם Application Insights וכתיבת צינורות YML.

00:06:26.400 --> 00:06:32.060
סוכן יכול ליצור את השלד של החלקים האלה באופן מיידי, כולל בדיקות אינטגרציה זמניות שמכירות את התלויות הקיימות.

00:06:32.180 --> 00:06:35.580
זה לא מסיר ממך את השליטה, זה משנה את המקום אליו האנרגיה שלך מופנה.

00:06:35.700 --> 00:06:41.240
במקום להיאבק בגבצי הגדרות במשך יום, אתה מבלה את הזמן הזה במימוש הלוגיקה העסקית שבאמת חשובה.

00:06:41.360 --> 00:06:47.120
העייפות מעבודת ההקמה הנעלמת ומותירה רוחב פס להחלטות עיצוב יצירתיות במקום למשימות מכניות.

00:06:47.120 --> 00:06:50.340
היכן שזה מרגיש שונה מאוטומציה מסורתית זה בגמישות.

00:06:50.500 --> 00:06:53.000
תבנית פרויקט נותנת לך ברירות מחדל סטטיות.

00:06:53.260 --> 00:06:56.780
סוכן מתאים את השלד שלו בהתבסס על היעד העסקי המוצהר שלך.

00:06:56.940 --> 00:07:04.080
אם אתה בונה אפליקציית שיתוף פעולה, אסטרטגיות מתמון כמו Redis וייצוב מונחי אירועים עם Azure Service Bus יופיעו בתוכנית השלד.

00:07:04.200 --> 00:07:08.660
אם תעבור לעבר רומסי עבודה מתוזמנים, שירותי רקע ואיבוד תורים יופיעו במקום זו.

00:07:08.660 --> 00:07:16.720
ההיענות הזו היא שמבדילה בינה מלאכותית סוכנת מסקריפטים פשוטים, שכן היא מציעה המלצות המשקפות את תפקידו של חבר צוות בכיר המנחי החלטות מוקדמות.

00:07:16.900 --> 00:07:19.200
הניגוד לשימוש הנוכחי בקופילות ברור.

00:07:19.360 --> 00:07:24.060
כרגע, רוב המפתחים רואים בו דרך להאיץ כתיבת תחביר נפוץ או קוד תבניתי.

00:07:24.240 --> 00:07:26.800
הם שואלים שאלה, והכלי משלים את השורה.

00:07:26.800 --> 00:07:34.880
עם יכולות סוכנות, הכלי מתחיל לייעץ ברמת המערכת, מציע חלופות מודעות להקשר ומציף קשרות מוקדם במחזור הפיתוח.

00:07:35.380 --> 00:07:39.100
הקפיצה היא מיצירת מקטעי קוד לעוצרות של תכנונים יסימים.

00:07:39.300 --> 00:07:45.820
וזה משנה לא רק את האופן שבו קוד נכתב, אלא את האופן שבו צוותים מגבשים את הפתרון כולו לפני שהם מתחייבים לכיוון אחד.

00:07:46.000 --> 00:07:48.900
שום דבר מזה לא מייתר את הצורך בשיקול דעת אנושי.

00:07:49.040 --> 00:07:53.700
סוכנים יכולים להציע תשתית, תלויות ושיטות עבודה, אך עם אותם עדיין מוטל על הצוות.

00:07:53.700 --> 00:07:56.320
התייחסו לכל המלצה כאל תיוטת הצעה.

00:07:56.400 --> 00:08:02.260
קבלו את החלקים שתואמים לסטנדרטים שלכם, תקנו את אלו שלא, והפיקו לקחים עבור מחזור הפרויקט הבא.

00:08:02.380 --> 00:08:08.120
הבינה המלאכותית מטפלת בעבודה הקשה והחוזרת, ועוד חברי הצוות נשארים ממוקדים בהתאמת בחירות טכנולוגיות לאסטרטגיה.

00:08:08.260 --> 00:08:12.160
עד כה בחנו כיצד סוכנים מעצבים מחדש את חוויית הקידוד בתוכנת.

00:08:12.180 --> 00:08:16.580
אך מעורבות סוכנים אינה מסתיימת בתכנון פתרונות או בהקמת תשתית פרויקט.

00:08:16.580 --> 00:08:24.240
ברגע שהיסודות מונחים, אותה אינטליגנציה מתחילה להתרחב אל עבר הקצאה, פריסה וניהול של התשתית שעליה מסתמכים היישומים הללו.

00:08:24.420 --> 00:08:29.280
שם מתגבש שינוי משמעותי נוסף, והוא אינו מוגבל לזרימת העבודה של המפתח המקומי.

00:08:29.400 --> 00:08:31.520
מדובר בסביבת הענן שעוטפת אותה.

00:08:31.660 --> 00:08:34.360
סוכני ענן שמריצים את Azure על טייס אוטומטי.

00:08:34.360 --> 00:08:39.480
אז בואו נעביר את המיקוד למה שקורה כשניהול Azure עצמו מתחיל לפעול על טייס אוטומטי בעזרת סוכנים.

00:08:39.640 --> 00:08:43.220
הדרך המקורית שבה מוצג הדיון הזה נשמעת לעתים קרובות כמו מדע בדיוני.

00:08:43.400 --> 00:08:47.260
מה קורה כשהקצאת משאבי Azure לא דורשת בכלל מעורבות אנושית בתהליך?

00:08:47.980 --> 00:08:49.960
דרך טובה יותר לחשוב על זה היא כזו.

00:08:50.260 --> 00:08:54.840
מה קורה כשמטלות הקצאה שגרתיות וזיהויסטיות דורשים פחות התערבות ידנית,

00:08:54.840 --> 00:08:58.520
כיוון שסוכנים מנהלים משימות חוזרות תחת גבולות גזרה מוגדרים?

00:08:58.920 --> 00:09:04.800
השינוי הזה חשוב כי הוא לא עוסק בהחלפת אנשים, אלא בהורדת עומס של עבודה חוזרת תוך שמירה על פיקוח.

00:09:04.800 --> 00:09:09.440
אם אי פעם בניתם סביבת Azure רצינית, אתם כבר יודעים עד כמה זה הופך למבולגן.

00:09:09.580 --> 00:09:13.140
אתם מלהטטים בין תבניות, סקריפטים וYML של צינורות פיתוח,

00:09:13.400 --> 00:09:16.840
תוך מעבר בין פקודות CLI למהירות לבין הפורטל למקרים חריגים.

00:09:16.980 --> 00:09:19.760
כל קיצור דרך הופך לחוב טכני שמחכה לצוף.

00:09:19.760 --> 00:09:22.380
מכונה וירטואלית שנותרה דולקת מחוץ לשעות הפעילות,

00:09:22.520 --> 00:09:25.780
עלויות שצומחות ללא התראה או חשבון נחסון חשוף כשלא אמור להיות כזה.

00:09:25.780 --> 00:09:29.420
ובפעולות ענן, אפילו מעידות קטנות יוצרות כאבי ראש גדולים.

00:09:29.580 --> 00:09:32.460
חשבוניות שמזנקות, עזורים שפוגעים בחוסן המערכת,

00:09:32.600 --> 00:09:35.320
או פערים בתאימות שמתגלים בזמן הגרוע ביותר האפשרי.

00:09:35.480 --> 00:09:38.080
זוהי השגרה שרוב הצוותים רוצים להשתחרר ממנה,

00:09:38.320 --> 00:09:41.000
וכאן סוכן מתחיל להרגיש כמו מהנדס פריסה אוטונומי.

00:09:41.000 --> 00:09:42.020
הרעיון פשוט.

00:09:42.160 --> 00:09:48.340
אתה מספק יעדים עסקיים, דרישות ביצועים, צירכי התאוששות, כללי ציות ומגבלות תקציב,

00:09:48.340 --> 00:09:51.560
והסוכן מתרגם את הכוונה הזו להגדרות תשתית.

00:09:51.640 --> 00:09:54.900
במקום לעבור בין קונסולות מרובות או לחבר מזהים ידנית,

00:09:55.180 --> 00:09:58.340
אתה רואה תבניות ISC שכבר מותאמות ליעדים שהגדרת.

00:09:58.540 --> 00:10:01.960
משם, אותו סוכן שומר על ערנות, מריץ בדיקות ציות,

00:10:01.960 --> 00:10:07.700
מדמי הגדרות שגויות אפשריות ומכיל תיקונים מוצאים לפני שבעיות מסלימות בסביבת הייצור.

00:10:07.860 --> 00:10:10.960
ההבדל מאוטומציה קיימת תמון ביכולת ההסתגלות.

00:10:11.120 --> 00:10:15.840
צינור C, CD רגיל, מתייחס להגדרות ה-YML שלך כאל תורה מסיני.

00:10:15.840 --> 00:10:18.560
הן עובדות עד שהמציאות משתנה עדכון תלויות,

00:10:18.760 --> 00:10:21.320
עלייה פתאומית בביקוש או דרישת ציות חדשה,

00:10:21.460 --> 00:10:27.000
ואז ההוראות הסתיות הללו נשברות או דוחפות משהו שנראה תקין אך לא עונה על הצרכים העסקיים.

00:10:27.000 --> 00:10:29.440
צינור המונה על ידי סוכן פועל אחרת.

00:10:29.620 --> 00:10:33.900
הוא מתייחס להגדרות הללו כאל בסיס, אך מעדכן אותן כשהתנאים משתנים.

00:10:34.520 --> 00:10:38.020
במקום לחכות שאדם ירחיב שירות או יתאים הפצה אזורית,

00:10:38.020 --> 00:10:42.720
הוא מזהה דפוסי אומס, חוזה ספים סבירים ומקצה קיבולת נוספת מראש.

00:10:43.260 --> 00:10:46.960
יכולת ההסתגלות הזו הופכת תרחישים לפחות מועדים לטעויות בפועל.

00:10:47.080 --> 00:10:50.380
דמיין אפליקציית נט, המשרתת תעבורה בעיקר בארצות הברית.

00:10:50.380 --> 00:10:53.020
שבוע לאחר מכן, משתמשים חדשים מופיעים באירופה.

00:10:53.120 --> 00:10:56.720
השיית הזמן גדלה, אך איש לא לקח בחשבון אזור נוסף ב-YML המקורי.

00:10:56.840 --> 00:10:58.660
אוטומציה מסורתית מתעלמת מכך.

00:10:58.800 --> 00:11:01.440
אתה מבחין בכך רק לאחר שהתלונות והיומנים מצטברים.

00:11:01.440 --> 00:11:07.360
לעומת זאת, סוכן מסמן את הדפוס, פורס עותק אירופי ומגדיר ניתוב דרך Azure Front Door באופן מיידי.

00:11:07.460 --> 00:11:11.280
הוא לא רק פורס ועוזב, ומתאים את המשאבים לכוונתך ללא הרף.

00:11:11.400 --> 00:11:14.420
כמעט כמו מפעיל 24 שביעיות שלעולם לא מתאייף.

00:11:14.420 --> 00:11:16.980
התועלת האמיתית מסתרת מעבר להרחבה.

00:11:17.100 --> 00:11:19.220
אבטחה וציות מוטמעים בתוך הלולאה.

00:11:19.380 --> 00:11:23.200
זה עשוי להיראות כמו סוכן שמבחין במקולת איחסון שנחשפה בטעות,

00:11:23.200 --> 00:11:28.700
נועל אותה אוטומטית או מזהה חריגה בבסיס העדכונים של מכונה וירטואלית ומחזיר אותה למסלול.

00:11:28.860 --> 00:11:34.660
אלו הן משימות בתדירות גבוהה ונראות נמוכה שבני אדם בדרך כלל תופסים מאוחר יותר ורק לאחר מאמץ.

00:11:34.660 --> 00:11:39.100
על ידי דחיפתן למחזור הרציף, אתה לא מסיר מפעילים, אתה משחרר אותם.

00:11:39.220 --> 00:11:43.780
במקום להשקיע אנרגיה בחיבוי שריפות, הם מתמקדים בתכנון ואסטרטגיה ברמה גבוהה יותר.

00:11:44.000 --> 00:11:45.100
וזה ניואנס חשוב.

00:11:45.300 --> 00:11:46.920
הפיקוח האנושי לא נעלם.

00:11:46.920 --> 00:11:51.500
התפקיד שלך משתנה מסימון תיבות שורה אחר שורה להגדרת הנחיות מראש.

00:11:51.920 --> 00:11:56.560
אילו אזורים מותרים, אילו עלויות מקובלות ואילו תקני ציוט אסור להפר.

00:11:56.880 --> 00:12:01.860
צעד מעשי לכל צוות שסיקרן לבחון זאת הוא להגדיר גבולות מדיניות מוקדם.

00:12:02.020 --> 00:12:05.940
קבע תקרות עלות, ציין אזורים מאושרים והוסף גבולות ציוט.

00:12:06.440 --> 00:12:09.580
הסוכן פועל אז כהוקף, לא כמפעיל ללא הגבלות.

00:12:09.800 --> 00:12:10.960
זהו העיקרון המנחה.

00:12:10.960 --> 00:12:15.920
אתם נשארים בשליטה על הכיוון האסטרטגי בזמן שהסוכן מבצע את פעולות ההגנה בהיקף נרחב.

00:12:16.080 --> 00:12:19.580
זה גם לא אומר שתפקידו את סביבת הייצור בידי הסוכן כבר מהיום הראשון.

00:12:19.720 --> 00:12:22.840
אם אתם נמנעים מסיכונים, התחילו בסביבת בדיקות מבוקרת.

00:12:23.020 --> 00:12:28.100
חישפו את הסוכן לאומס עבודה לא קריטי או בחרו שירות בודד כמו תשתית תכסון או רישום,

00:12:28.420 --> 00:12:30.240
ותנו לו לנהל שם סחיפה והקצאה.

00:12:30.240 --> 00:12:34.760
כך תבנו אמון בדרך שבה הוא מפרש את גבולות הגזרה לפני שתרחיבו את פעילותו.

00:12:34.880 --> 00:12:38.920
חישבו על זה כעל הרצת פרויקט פיילוט עם היקף מוגדר היטב וסיכון נמוך,

00:12:39.180 --> 00:12:42.220
בדיוק כפי שרוב שיטות הדבופס האמינות מבשילות בכל מקרה.

00:12:42.400 --> 00:12:47.360
בבסיסו, גישה סוכנית ל-Azure IRC נראית פחות כמו כתיבת עשרות סקריפטים סטטיים,

00:12:47.500 --> 00:12:49.460
ויותר כמו ניהול רשימת תיוג דינמי.

00:12:49.640 --> 00:12:52.120
צרו תבניות, הריצו בדיקות לפני פריסה,

00:12:52.120 --> 00:12:56.300
עקבו אחר סחיפה והציעו תיקונים, הכל תחת הגבולות שאתם מגדירים.

00:12:56.480 --> 00:12:58.140
זה מובנה מספיק כדי לעורר אמון,

00:12:58.380 --> 00:13:00.940
אך גמיש מספיק כדי להתפתח כשהתנאים משתנים.

00:13:01.140 --> 00:13:04.860
כמובן, הקצאה והרחבת תשתית הן רק צד אחד של מהימנות.

00:13:05.000 --> 00:13:07.580
הבעיה הקשה יותר מגיעה לעיתים קרובות מאוחר יותר,

00:13:07.840 --> 00:13:12.000
כשצריך לוודא שהקוד שאתם פורסים על הסביבה הזו אכן מחזיק מעמד בתנאים אמיתיים.

00:13:12.000 --> 00:13:13.860
ושם מתחיל להופיע האתגר הבא,

00:13:13.860 --> 00:13:18.380
השאלה איך לתפוס בגים שבני אדם פשוט לא רואים עד שהם כבר בסביבת הייצור.

00:13:18.540 --> 00:13:21.240
בדיקות אוטונומיות, בגים שבני אדם מפספסים.

00:13:21.440 --> 00:13:25.480
בדיקות מכסות רק את מה שבני אדם יכולים לחשוב עליו, וזו מגבלת הליבה.

00:13:25.620 --> 00:13:28.280
רוב כשלא ריא הייצור אינם נובעים ממה שצפוי,

00:13:28.500 --> 00:13:30.380
אלא ממה שחומק מהדמיון האנושי.

00:13:30.380 --> 00:13:35.020
סוכני בדיקה אוטונומיים נכנסים לפער הזה ומתמקדים במקרי קצה ובתנאים דינמיים

00:13:35.020 --> 00:13:37.360
שלעולם לא היו נכנסים לחבילת בדיקות טיפוסית.

00:13:43.860 --> 00:13:48.360
הולך בדיקת מאמץ מתוכננת, אך הוסיפו אירועי הרחבה מופעים חדשים שעולים תוך כדי תנועה

00:13:48.360 --> 00:13:50.140
ופתאום מופיעות שגיאות בטיפול במפגשים.

00:13:50.340 --> 00:13:54.520
אלא אם כן מי שהוא תכנן בדיקה במיוחד עבור החפיפה הזו, היא נשארת לא מורגשת.

00:13:54.640 --> 00:13:59.460
סוכן אוטונומי מזהה את האנומליה, מבודד אותה ומייצר בדיקת רגרסיה חדשה סביב התנאי הזה.

00:13:59.460 --> 00:14:02.660
בפעם הבאה שהרחבה מתרחשת, אמצעי ההגנה הזה כבר קיים,

00:14:02.660 --> 00:14:05.020
והופך את מה שהיה סיכון נסתר לתרחיש מנותר.

00:14:05.200 --> 00:14:06.980
דוגמה נוספת היא מוטציית כלת.

00:14:07.160 --> 00:14:10.740
בודקים אנושיים מתכננים בדרך כלל עם נתונים בטוחים או צפויים בראש.

00:14:10.940 --> 00:14:15.800
שמות משתמש תקינים, הודעות API נכונות או מקרי קצה ברורים כמו מחרוזות ריקות.

00:14:15.920 --> 00:14:20.460
סוכן, לעומת זאת, מתחיל להתנסות בווריאציות שמפתחים לא היו חושבים לחסות.

00:14:20.460 --> 00:14:24.900
בקשות גדולות מדי, קידודים מוזרים, עיכובים קלים בין קריאות רב-שלביות.

00:14:25.080 --> 00:14:29.120
על ידי כך, הוא יכול לעורר קשלים שחבילות בדיקה ידניות יחמיצו לחלוטין.

00:14:29.280 --> 00:14:31.380
הערך אינו רק במהירות, אלא בגיוון.

00:14:31.600 --> 00:14:36.760
סוכנים חוקרים פינות מוזרות במרחבי קלט מהר יותר ממה שאי פעם יוכלו לעשות מקרים שנכתבו בידי אדם.

00:14:36.900 --> 00:14:41.040
מה שהופך את המעבר הזה לשונה מאוטומציה מסורתית הוא האופן שבו חבילת הבדיקות מתפתחת.

00:14:41.040 --> 00:14:44.460
חבילת רגרסייה שתוכננה על ידי בני אדם נותרת סטטית יחסית.

00:14:44.460 --> 00:14:48.120
היא משקפת את הידע וההנחות של הצוות בנקודת זמן מסוימת.

00:14:48.340 --> 00:14:50.320
סוכנים הופכים זאת לתהליך מתמשך.

00:14:50.480 --> 00:14:55.160
הם מרחיבים את החבילה ככל שהמערכת משתנה ותמיד מחפשים מצבים שלא נלקחו בחשבון.

00:14:55.320 --> 00:14:59.040
במקום שמפתחים יעדכנו בעמל רב סקריפטים שבירים אחרי כל ליטרציה,

00:14:59.040 --> 00:15:03.220
מקרים חדשים נוצרים באופן דינמי מתצפיות אמיתיות על התנהגות המערכת.

00:15:03.380 --> 00:15:05.060
עם זאת, יש הסתייגות חשובה.

00:15:05.220 --> 00:15:08.720
לא כל בדיקה שנוצרה על ידי סוכן ראויה להיקלל בחבילה הקבועה שלך.

00:15:08.720 --> 00:15:13.800
בדיקות לא יציבות או לא רלוונטיות עלולות להצטבר במהירות, לבזבז זמן ולהרער את האמון באוטומציה.

00:15:13.940 --> 00:15:15.440
לכן משילות היא דבר חשוב.

00:15:15.640 --> 00:15:17.260
צוותים זקוקים לתהליך סקירה.

00:15:17.260 --> 00:15:24.880
מפתחים או מהנדסי QA צריכים לאמת כל בדיקה מוצעת עבור יציבות ורלוונטיות עסקית לפני העברתה לחבילת הרגרסיה היציבה.

00:15:25.000 --> 00:15:31.140
כמו בכל אוטומציה, פיקוח מבטיח שהכלים הללו יגבירו את האמינות במקום להטביע את הצוותים ברעש.

00:15:31.140 --> 00:15:35.300
תפיסה שגויה נוספת שכדאי להבהיר היא הרעיון שסוכנים מתקנים בגים.

00:15:35.460 --> 00:15:38.380
הם לא כותבים מחדש קוד ייצור או מתקנים פגמים בעצמם.

00:15:38.380 --> 00:15:43.140
מה שהם עושים בצורה יוצאת מן הכלל הוא להציף תרחישים ניתנים לשחזור עם פירוט הבחנתי ברור.

00:15:43.280 --> 00:15:48.720
עבור מפתח, קבלת סט צעדים שתועדו על ידי סוכן עושה את ההבדל בין שעות של ניחושים לבין פתרון מהיר.

00:15:48.880 --> 00:15:52.680
במקרים מסוימים, סוכנים יכולים להציע תיקון אפשרי המבוסס על תפוסים מוכרים,

00:15:52.680 --> 00:15:55.380
אך ההחלטה הסופית והשינוי נשארים בידיים אנושיות.

00:15:55.500 --> 00:15:58.140
כשמסתכלים על זה כך, חלוקת העבודה הופכת לנקיעה יותר.

00:15:58.140 --> 00:16:01.560
המכונות מבצעות את הגילוי, בני האדם מבצעים את השיפוט והתיקון.

00:16:01.680 --> 00:16:04.040
ההשפעה העסקית כאן היא פחות קיבוי שריפות.

00:16:04.240 --> 00:16:06.540
צוותים רואים פחות כרטיסי תמיכה בלילה,

00:16:06.740 --> 00:16:11.760
פחות רגרסיות שחוזרות אחרי שחרורים וירידה מורגשת בזמן שעובד על שחזור צעדים.

00:16:11.760 --> 00:16:17.380
מוזרויות בביצועים נתפסות בסביבות מבוקרות במקום לעלות לראשונה אמול משתמשי הקצה.

00:16:17.380 --> 00:16:22.800
שלים בהבטחה נחשפים במהלך בדיקות פנימיות, לא אחרי שריקת תאימות או תרגיל חדירות.

00:16:22.980 --> 00:16:27.580
השינוי הזה פותח מקום לקיוע להתמקד בשאלות ברמה גבוהה יותר, כמו שימושיות,

00:16:27.800 --> 00:16:32.360
זרימת עבודה חלקה ונגישות, תחומים שאף מנוע אוטונומי לא יכול לשפוט בצורה משמעותית.

00:16:32.540 --> 00:16:35.820
עבור בעלי מקצוע שמעוניינים לבדוק את השטח, התחילו בקטן.

00:16:35.820 --> 00:16:40.820
הריצו סוכן בדיקות אוטונומי מול סביבת סטייג'ינג או פרי-פרודקשן לפרק זמן מוגדר.

00:16:40.820 --> 00:16:44.260
השבו את רשימת הבעיות שהוא חושף עם הבקלוג הנוכחי שלכם.

00:16:44.400 --> 00:16:46.320
התייחסו לתרגיל כאל איסוף נתונים.

00:16:46.520 --> 00:16:48.180
האם הממצאים החדשים מועילים באמת?

00:16:48.380 --> 00:16:49.740
האם הם חופפים בדיקות קיימות?

00:16:49.920 --> 00:16:52.480
האם הם חושפים נקודות טורפה שחשובות לעסק שלכם?

00:16:52.620 --> 00:16:58.040
כאשר מציגים זאת כך, אתם מודדים החזר על השקעה ולא מאמרים על איכות השחרור שלכם בטכניקה לא מוכחת.

00:16:58.040 --> 00:17:01.980
וכאשר צוותים אכן מריצים סוגים כאלו של פיילוטים, דפוס מסוים מתגלה.

00:17:01.980 --> 00:17:05.180
התועלת האמיתית לטווח ארוך אינה רק בעיתור בגים נוספים,

00:17:05.440 --> 00:17:09.200
אלא במהירות שבה ניתן להזין את הלקחים הללו חזרה למחזור הפיתוח הרחב.

00:17:09.340 --> 00:17:14.420
כל חריגה שנלכדה וכל תובנה שתועדה מייצגות ידע שאסור שיעלם עם סיום הספרינג.

00:17:14.600 --> 00:17:18.520
השאלה היא כיצד הבינה הזו נשמרת, משותפת ומועברת הלאה,

00:17:18.520 --> 00:17:22.160
כדי שאותן טעויות לא יחזרו על עצמן תחת שמות פרויקטים שונים.

00:17:22.500 --> 00:17:24.360
סגירת מעגל הבינה בדבופס

00:17:24.360 --> 00:17:29.220
בדבופס, אחת הבעיות הקשות ביותר לפתרון היא המהירות שבה ידע דוהה בין ספרינטים.

00:17:29.420 --> 00:17:31.480
בעיות מתועדות וסיכומי אירועים נכתבים,

00:17:31.720 --> 00:17:35.800
אך כשמתחיל הפרויקט הבא, רבים מהלקחים הללו אינם חוזרים לתוך זרימת העבודה.

00:17:36.020 --> 00:17:39.320
סגירת מעגל הבינה בדבופס נועדה לעצור את מעגל העובדן הזה

00:17:39.320 --> 00:17:42.340
ולוודא שמה שצוותים לומדים אכן משפר את מה שיבוא בהמשך.

00:17:42.460 --> 00:17:47.020
בינה מלאכותית סוכנת, אג'נטיק AI, תומכת בכך על ידי חיבור למקומות שבהם ידע כבר זורם.

00:17:47.180 --> 00:17:50.420
נקודת האינטגרציה הראשונה היא קליטת יומנים ונתונים טלמטריים.

00:17:50.620 --> 00:17:53.980
במקום לדרוש מהמהנדסים לסרוק לוחות מכוונים או אירועים מעורכבים,

00:17:54.180 --> 00:17:57.580
סוכנים סורקים ללא הרך מדדים, שיעורי שגיאות ועקבות ביצועים,

00:17:57.760 --> 00:17:59.780
ומקשרים בין חריגות לאורך גרסאות שונות.

00:17:59.780 --> 00:18:03.800
השנייה היא ניתוח היסטוריית בקשות משיכה, פול רכווסטס וסקירות קוד.

00:18:03.940 --> 00:18:06.500
החלטות שהתקבלו בהערות מכילות לעתים קרובות,

00:18:06.580 --> 00:18:09.500
הקשר על פשרות או סיכונים שלעולם לא מגיעים לתיעוד הרשמי.

00:18:09.620 --> 00:18:12.900
על ידי עיבוד השיחות הללו, סוכנים משמרים את הסיבה למה שקרה,

00:18:13.160 --> 00:18:14.420
ולא רק את מה שאוחד לקוד.

00:18:14.580 --> 00:18:17.920
השלישית היא מיפוי כשלים שנצפו להמלצות ארכיטקטוניות.

00:18:17.940 --> 00:18:21.180
אם אסטרטגיות מתמון מסוימות יוצרות שוב ושוב עומס זיכרון,

00:18:21.180 --> 00:18:23.440
או אם דפוסי הרחבה גורמים לזמני קצבה,

00:18:23.700 --> 00:18:27.660
תובנות אלו מועלות במהלך התכנון לפני שאותן טעויות חוזרות במערכת חדשה.

00:18:27.820 --> 00:18:32.400
יחד, נקודות אינטגרציה אלו משפרות את הזיכרון הארגוני מבלי להבטיח שלמות.

00:18:32.540 --> 00:18:35.460
הערך אינו בכך שסוכנים זוכרים כל פרט בצורה מושלמת,

00:18:35.700 --> 00:18:39.200
אלא בכך שהם מעלים את הסיכוי של לקחים מהעבר יצוצו בזמן הנכון.

00:18:39.360 --> 00:18:40.960
פיקוח אנושי עדיין חיוני.

00:18:40.960 --> 00:18:44.300
מפתחים צריכים לאמת את הרלוונטיות של התובנות שעלו,

00:18:44.300 --> 00:18:50.680
וארגונים צריכים לתזמן ביקורות תקופתיות על מה שהסוכנים לוכדים כדי למנוע זליגת רעשים אוסטיות למערכת.

00:18:50.860 --> 00:18:54.480
עם סקירה קפדנית, הבינה הופכת לברת ביצוע במקום למציפה.

00:18:54.580 --> 00:18:57.680
ממשל, גווורננס, הוא נדבך נוסף שאי אפשר לדלג עליו.

00:18:57.800 --> 00:19:02.780
הזנת יומנים, בקשות משיכה ותוצאות פריסה למערכת סוכנים מעלה שאלות סביב פרטיות,

00:19:02.780 --> 00:19:04.180
שמירת נתונים ותעימות.

00:19:04.340 --> 00:19:09.040
לא כל פריט מידע צריך לחיות לנצח, ולא כל נתון צריך להיות נגיש לכל תפקיד.

00:19:09.040 --> 00:19:14.260
לפני התמאת שכבת זיכרון כזו, צוותים צריכים להגדיר מגבלות ברורות לשמירת נתונים,

00:19:14.580 --> 00:19:18.320
לקבוע מדיניות גישה ולוודא שינתונים רגישים מתוהרים או מוסתרים.

00:19:18.540 --> 00:19:23.360
ללא גבולות אלו, קיים סיכון ליצירת מאגר צל לא מנוהל של היסטוריית החברה,

00:19:23.580 --> 00:19:25.540
שמסבך ביקורות במקום לתמוך בהן.

00:19:25.540 --> 00:19:29.400
עבור מפתחים, ההשפעה המורגשת ביותר מתרחשת במהלך תחילת פרויקט.

00:19:29.400 --> 00:19:34.180
במקום זיכרונות מאורפלים על מה השתבש בפעם הקודמת, תובנות מופיעות ישירות בתוך ההקשר.

00:19:34.400 --> 00:19:37.380
התחילו נט-וויב-אפי-אי חדש והמערכת עשויה להציע.

00:19:37.600 --> 00:19:41.560
בשנה שעברה, ספריית הקאצ'ינג הזו גרמה לדליפות זיכרון תחת אומס.

00:19:41.740 --> 00:19:45.540
שקלו חלופה, או במהלך התכנון, היא עשויה לציין שדפוסי הזרקת תלויות,

00:19:45.540 --> 00:19:48.040
דפנדנסי אינג'קשון, מסוימים יצרו חוסר יציבו.

00:19:48.040 --> 00:19:53.040
התזכורות מגיעות בזמן, לא בדיעבד, ולכן הן מעבירות את המיקוד מתגובה לי ואיות לי מניעתן.

00:19:53.180 --> 00:19:57.580
כך האינטליגנציה של הפרויקט מצטברת במקום להתאפס בכל פעם שמתחיל ספרינט חדש.

00:19:57.760 --> 00:19:59.900
זה גם משנה את האופי של רטרוספקטיבות.

00:20:00.100 --> 00:20:04.060
רטרוספקטיבות מסורתיות אוספות משוב בנקודת זמן אחת ואז ממשיכות הלאה.

00:20:04.060 --> 00:20:07.140
אם סוכנים בתוך הלופ, הידע הזה לא נשמר בצד.

00:20:07.240 --> 00:20:10.240
הוא משולב באופן רציף חזרה לתוך מחזור הפיתוח.

00:20:10.240 --> 00:20:17.920
לוגים מהחודש הזה, אנומליות בסקאלינג מהרבעון האחרון, או רגרסיות בביצועים שצוינו לפני שנתיים, כולם מעצבים את ההמלצות שניתנות היום.

00:20:18.060 --> 00:20:23.640
על ידי הפיכת כל גרסה לחלק מילוק אימון מתמשך, צוותים מפחיתים את הסיכוי לכשלים חוזרים דז'אבו.

00:20:23.800 --> 00:20:26.820
עם זאת, את התוצאות יש למדוד, לא להניח כמובנות מעליהן.

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

00:20:33.120 --> 00:20:36.420
אחר כך חישבו, האם הסוכן הציף דפוסים שלא הבחנתם בהם?

00:20:36.520 --> 00:20:39.660
האם הדפוסים האלה הובילו לשינויים אמיתיים בקוד או בתשתית?

00:20:39.800 --> 00:20:42.120
והאם איכות הגרסאות השתפרה באופן מדיד?

00:20:42.300 --> 00:20:47.060
אם התשובה היא כן, אז הרחבה להיסטוריית פי-אר או למיפוי ארכיטקטוני היא הגיוני.

00:20:47.060 --> 00:20:53.420
אם לא, הניסוי עצמו חושף מה דורש התאמה, בין אם במקורות המידע, בממשל או בתהליכי הבדיקה.

00:20:53.640 --> 00:20:55.540
לאורך זמן, התגמול מצטבר.

00:20:55.540 --> 00:21:04.980
על ידי שיפור הזיכרון הארגוני, מהירות הגרסאות מתייצבת, הארכיטקטורה הופכת לחסינה יותר, ופחות אנרגיה הנדסית מתבזבזת על גילוי מחדש של מהמורות עבר.

00:21:05.180 --> 00:21:09.740
ידע מפסיק לחמוק בין הסדקים, ובמקום זאת מצטבר כמשאב שימושי שצוותים יכולים לסמוך עליו.

00:21:09.740 --> 00:21:13.320
ובנקודה הזו, התפקיד של בינה מלאכותית סוכנית, אג'נטיק AI, נראה אחרת.

00:21:13.420 --> 00:21:15.480
היא לא רק עוזרת בשלב אחד של הפיתוח.

00:21:15.480 --> 00:21:20.280
היא מתחילה לחבר את התהליך כולו, מעבירה לקחים קדימה במקום לתת להם להתפוגג.

00:21:20.420 --> 00:21:29.320
הרציפות הזו היא שמשנה את הדבופס מאוסף משימות מבודדות למחזור חיים מחובר יותר, ומכינה את הקרקע לשינוי הרחב שקורה כעת בצוותי תוכנה.

00:21:29.920 --> 00:21:33.100
בינה מלאכותית, סוכנית מסמנת שינוי פרקטי בפיתוח.

00:21:33.300 --> 00:21:39.060
קונספט, זו לא עוזרת כתיבת קוד, אלא מערכת שנושאת זיכרון, הקשר ויעדים לאורך כל מחזור החיים.

00:21:39.060 --> 00:21:48.580
יישום, נקודות הכניסה הברורות ביותר עבור צוותי, נט ואז'ר, הן בניית תשתית לפרויקטים חדשים, מתן אפשרות לסוכנים לטפל בפרוויזיינינג שגרתי, וניסויים ביצירת טסטים אוטומטי.

00:21:48.680 --> 00:21:56.160
השפעה, אם נעשה זאת בזהירות, זה מייעל תהליכי עבודה, מפחיד תקורה בהקמה, ומוריד את הסיכוי לכשלים חוזרים על פני פרויקטים שונים.

00:21:56.380 --> 00:21:59.240
הצעד הבא הטוב ביותר הוא לבדוק זאת בסביבה שלכם.

00:21:59.240 --> 00:22:06.880
נסו להפעיל את Copilot על אבטיפוס קטן או להריץ סוכן בסביבת בדיקות, ויקבו אחר מדד אחד, זמן שנחסך, בגים שהתגלו או מניעת סחיפה.

00:22:06.980 --> 00:22:12.360
אם נתקלתם באתגר DevOps חוזר שמעט את הצוות שלכם, שתפו בתגובות כדי שאחרים יוכלו להשוות.

00:22:12.480 --> 00:22:18.260
ואם אתם רוצים עצות מעשיות נוספות על Net, Azure ואימוץ בינה מלאכותית, הרשמו לערוץ לידכונים נוספים.

00:22:18.260 --> 00:22:22.960
הרווחים נראים קטנים בהתחלה, אך הם מצטברים עם ניהול נכון, פיקוח ואיתרציות עקביות.