תאריך פרסום: 10 בנובמבר 2026
Policybazaar היא אחת מפלטפורמות הביטוח המובילות בהודו, עם יותר מ-97 מיליון לקוחות רשומים. כ-80% מהלקוחות של החנות מבקרים באתר מדי חודש. חברת האם שלה, PB Fintech, השיקה לאחרונה את Pensionbazaar, פלטפורמה מקצה לקצה לתכנון פרישה, שהיא מותג של Paisabazaar Marketing & Consulting Private Limited.
שני הצוותים כבר משתמשים בסוכני תכנות שכותבים קוד במהירות, אבל לא יכולים לראות מה הקוד הזה עושה בדפדפן. הסוכנים השתמשו לעיתים קרובות בתבניות אינטרנט מיושנות, ולא הייתה להם דרך לבדוק אם המסך עבר רינדור בצורה נכונה, כך שהמהנדסים עדיין היו צריכים לאמת הכול באופן ידני.
כדי לפתור את הבעיה, שתי החברות שילבו שני כלים ב-Agentic Workflows שלהן: Modern Web Guidance כדי ללמד את המודלים את הסטנדרטים המודרניים של האינטרנט, וכלי פיתוח ל-Chrome לסוכני AI כדי לתת לסוכנים האלה דפדפן ללא ממשק משתמש (headless) בזמן אמת, שבו הם יכולים לבדוק ולאמת את העבודה שלהם.
זו ההשפעה:
92%
פחות מאמץ בבדיקה ידנית של כ-30 דפי נחיתה של Policybazaar
>90%
קיצור זמני הפיתוח והבדיקה של דפים חדשים ב-Pensionbazaar, מכארבעה ימים לכמה שעות
>90%
פחות באגים בממשק המשתמש במסכים החדשים של Pensionbazaar
האתגר: קוד מהיר, אימות איטי
ב-Policybazaar וב-Pensionbazaar נתקלו בשני צווארי בקבוק שונים, שתהליכי העבודה הרגילים של תכנות באמצעות AI לא הצליחו לפתור ברמת הייצור.
Pensionbazaar: מסכים חדשים עם מחזורי בקרת איכות ארוכים
ב-Pensionbazaar היו צריכים עשרות מסכים חדשים ומורכבים, כמו מחשבון Retirement Freedom Score עם כמה שלבים, תחזיות של הוצאות השקעה בהתאמה אישית ודוחות המלצות אוטומטיים. הצוות פיתח אותם באמצעות סוכני תכנות ושרת ה-MCP של Figma, אבל שתי בעיות גרמו לכך שמחזורי ה-QA נמשכו זמן רב.
קודם כול, הסוכנים תכנתו בלי לדעת מה קורה. מודל בסיס יכול ליצור קוד, אבל הוא לא יכול לראות את הממשק שעבר רינדור, להשוות בין סגנונות מחושבים לבין מפרטי העיצוב, לזהות שינויים בפריסה או לקרוא תרשים Waterfall של הרשת. כך שבעיות קשורות כמו ממשק משתמש חתוך ושינויים בפריסה הגיעו עד לבדיקת איכות ידנית.
שנית, הקוד שנוצר היה תקוע בעבר. בלי להכיר את פלטפורמת האינטרנט המודרנית, הסוכנים השתמשו בפתרונות עקיפים מיושנים, כתבו מודלים כבדים של JavaScript במקום להשתמש ברכיב המובנה <dialog>, הוסיפו polyfills מיותרים והשמיטו רמזים לביצועים כמו fetchpriority.
Policybazaar: 30 דפי נחיתה וביקורת ידנית
צוות ביטוח החיים של Policybazaar מפעיל כ-30 דפי נחיתה למוצרי ביטוח שונים, ולכל דף יכולות להיות וריאציות לקמפיינים שיווקיים שונים. ביחד, הם מקבלים בין 200,000 ל-300,000 מבקרים ביום, וכל דף מקבל עדכונים חודשיים של עיצוב ולוגיקה עסקית. הצוות צריך לשמור על ציונים גבוהים ב-Core Web Vitals ולוודא שכל וריאציה נשארת נגישה ומוצגת בצורה נכונה בכל גודל מסך.
לפני שהתהליך הפך לאוטומטי, מהנדס בדק כל דף באופן ידני:
- מפעילים את PageSpeed Insights כדי לאסוף נתונים ממשתמשים בעולם האמיתי.
- בודקים את הציונים וההמלצות של Core Web Vitals.
- בודקים את גרסת ה-build לפיתוח או ל-staging, מאבחנים את הבעיות שגורמות לציונים הנמוכים ומתקנים את קוד האפליקציה.
התהליך היה איטי, חזר על עצמו ולא היה ניתן להרחבה. היא השאירה מקום לאופטימיזציות שהוחמצו, כיסוי ביקורת לא עקבי, רגרסיות בביצועים שלא זוהו ועיכובים בהשקות.
לפני שהצוותים שינו את תהליך העבודה, הם הציבו לעצמם שלוש מטרות: לצמצם את הזמן שהמפתחים משקיעים בבדיקות ביצועים ביותר מ-80% תוך כדי שמירה על כיסוי רציף של הבדיקות, לקצר את זמן הטיפול ב-QA באמצעות דוחות מאומתים, ולהפחית את מספר הבאגים בממשק המשתמש שנוצרו בגלל שמסך לא תאם ל-wireframe שלו.
הפתרון: לולאת קוד לאימות
ב-Pensionbazaar הצליחו לצמצם את הפער בין כתיבת הקוד לבדיקה שלו. הנציג כותב את הקוד, מפעיל מופע נקי של דפדפן, בודק את הדף באופן פרוגרמטי כדי לוודא שאין הבדלים חזותיים, שגיאות בפריסה, שגיאות במסוף ובעיות בביצועים, ומתקן את הבעיות שהוא מוצא עם התערבות אנושית מינימלית. הסוכן שלהם מקבל את העיצוב מ-Figma MCP, כך שהוא יכול להשוות בין הדף שעבר רינדור לבין מה שהמעצבים התכוונו ליצור.
בסרטון הבא אפשר לראות את הלולאה הזו בפעולה. הסוכן קורא את העיצובים ב-Figma למסך חדש, מטמיע אותו ואז משתמש בכלי הפיתוח ל-Chrome לסוכני AI כדי לבדוק את הדף שעבר רינדור ולתקן את ההבדלים שהוא מוצא.
שלב 1: מבססים את הנציג על תקני אינטרנט מודרניים
הצוות של Pensionbazaar רצה שהקוד שנוצר יפעל לפי השיטות המומלצות העדכניות באינטרנט, ישתמש בתכונות הפלטפורמה הנוכחיות ועדיין יפעל בדפדפנים ישנים יותר. בדיקה ידנית של כל המידע הזה היא משימה מייגעת, והסוכנים לא תמיד מעודכנים לגבי הפלטפורמה. Modern Web Guidance פותר את הבעיה הזו. זו מיומנות של סוכן, שנכתבה ומנוהלת על ידי מומחי אינטרנט מ-Chrome ומקהילת האינטרנט, והיא כוללת יותר מ-200 תרחישי שימוש. הוא מכוון את הסוכנים לממשקי API מודרניים של פלטפורמות אינטרנט ולשיטות מומלצות לביצועים ולנגישות שמתאימות ליעד ה-Baseline שלכם. אם לא מגדירים יעד, ברירת המחדל היא Baseline Widely Available.
אחרי שהסוכן שולף את ההקשר מקובצי Figma, הוא משתמש ב-Modern Web Guidance בזמן כתיבת הקוד. ב-Pensionbazaar, הקוד השתנה בשלוש דרכים:
- רכיבים מותאמים החליפו פתרונות עקיפים ב-JavaScript. הסוכן השתמש ברכיב המובנה
<dialog>וב-Popover API כדי ליצור מודלים של פרטי התוכנית, וב-CSS Grid וב-Flexbox כדי ליצור כרטיסים של סיכום פיננסי. - הסוכן הוסיף רמזים לביצועים שבדרך כלל לא נכללים במודלים בסיסיים.
השינויים האלה כללו את
fetchpriority="high"בתמונות LCP ראשיות, אתloading="lazy"בכרטיסי תוכניות מתחת לקו המשוער של סוף המסך, ותקציב ביצוע מבוסס-זמן עםscheduler.yield()כדי להגן על מהירות התגובה לאינטראקציה באתר (INP). - תכונות מודרניות לא פגעו בדפדפנים ישנים. ב-Pensionbazaar יש תמיכה בגרסאות דפדפן ישנות יותר, שמוגדרות ב-Browserslist. הסוכן השתמש בתכונות כמו המחלקה המדומה (pseudo-class) של CSS
:user-invalidו-autoComplete="one-time-code"בשדה הסיסמה החד-פעמית (OTP). דפדפנים ישנים יותר מתעלמים מהם, והפונקציונליות העיקרית ממשיכה לפעול.
המודלים הבסיסיים לא היו רחוקים מהיעד. מבחינת הביצועים, הצוות מצא שהם תואמים ב-70% בערך לשיטות המומלצות. בדוח של הנציג עצמו צוינו 12 כללים של Modern Web Guidance שסגרו את הפער שנותר. ארבע דוגמאות:
| אזור | הפער במודל הבסיס | הכלל Modern Web Guidance |
|---|---|---|
| התמונה נטענת | הזיות של שילובים סותרים, כמו שילוב של fetchpriority="high" עם loading="lazy". |
אוסר במפורש על שילוב שלהם, ומגביל את מספר התמונות בעדיפות גבוהה לאחת או שתיים בכל דף. |
| יציבות הפריסה | ההצעה content-visibility: auto לשיפור הביצועים, אבל הושמטה contain-intrinsic-size. |
צריך להתאים בין שני המאפיינים כדי למנוע שינויי פריסה חמורים בזמן רינדור התוכן. |
| העברת השליטה ב-thread הראשי | השתמשתם ב-scheduler.yield() באופן כללי בלי תבנית של מועד אחרון. |
אכיפת מועד אחרון קפדני שמבוסס על זמן (performance.now() + 50) כדי להגן על מהירות התגובה לאינטראקציה באתר (INP). |
| שמירה במטמון של Service Worker | לא לקחתם בחשבון שליחת טפסים אופליין. | הסוכן מקבל אזהרה ש-Service Workers לא יכולים לשמור במטמון בקשות שהן לא בקשת GET באופן מקורי. |
ב-Pensionbazaar, העדיפות שלנו הייתה לכתוב קוד איכותי מהיום הראשון כדי להימנע מחוב טכני בהמשך. התכונה Modern Web Guidance הנחתה את סוכן התכנות שלנו לאמץ תקני אינטרנט מודרניים ושיטות מומלצות לשיפור הביצועים, תוך התחשבות ביעדים הספציפיים שלנו לתאימות לדפדפנים. זה הפך את סקרי הקוד של ממשק המשתמש שלנו להרבה יותר קלים ומהירים, ובסופו של דבר שיפר את זמן הפיתוח שלנו.
אמאן סוני, מנהל הנדסה, Policybazaar
שלב 2: נותנים לנציג גישה לדפדפן
כלי הפיתוח ל-Chrome לסוכני AI הם קבוצת כלים, כולל שרת MCP, CLI ומיומנויות של סוכנים, שנותנים לסוכני תכנות גישה בזמן אמת לנתוני ניפוי באגים בזמן ריצה, כמו יומני מסוף, תנועה ברשת, עץ הנגישות ויכולות אחרות של כלי הפיתוח.
הצוות התקין את כלי הפיתוח ל-Chrome לסוכני AI כפלאגין בסוכן התכנות שלו, Claude Code:
# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins
הצוות רצה שכל בדיקה תפעל במופע נקי של הדפדפן, כדי שתוספים מותקנים ל-Chrome לא ישפיעו על התוצאות וכדי שמידע אישי או רגיש לא ידלוף. כדי לקבל את זה, מוסיפים את --isolated למערך args בהגדרות של שרת ה-MCP:
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
אם הבדיקות שלכם דורשות סשן קיים של דפדפן מחובר, השתמשו ב---autoConnect.
שלב 3: מאפשרים לנציג לבדוק ולתקן את העבודה שלו
צוות ההנדסה מפרט את הבדיקות בהוראות של הסוכן, כהנחיה או כמיומנות של הסוכן. ככלל, הסוכן מבצע את הפעולות הבאות:
- בודק את עץ ה-DOM ואת ה-CSS המחושב ומשווה אותם לעיצוב ב-Figma.
- משנה את גודל הדף לאזורי תצוגה בניידים כדי לבדוק את הרספונסיביות.
- מתעד עקבות של ביצועים כדי למצוא פריימים של אנימציה עם טעינה ארוכה (LoAF) שנגרמים על ידי סקריפטים, משאבים שחוסמים רינדור ובעיות אחרות בביצועים.
- הוא משכתב את הקוד כדי לתקן חוסר התאמה בעיצוב, בעיות בביצועים וחריגות במסוף לפני שמהנדס בודק אותו.
בטבלה הבאה מפורט אילו כלים של כלי הפיתוח ל-Chrome לסוכני AI תומכים בכל בדיקה:
| המחאה | כלים |
|---|---|
| בדיקת הרספונסיביות באזורי תצוגה שונים | resize_page משנה את הגודל של חלון הדף למידות מפורשות. emulate מדמה סביבות של מכשירים ספציפיים. take_screenshot מתעד את התוצאה. |
| השוואה בין ה-DOM וה-CSS המחושב לבין העיצוב ב-Figma | הפונקציה take_snapshot מחזירה תמונת מצב של הטקסט בדף על סמך עץ הנגישות. get_css_styles קורא כללי CSS שהוחלו. evaluate_script מריץ פונקציית JavaScript בתוך הדף. |
| איתור בעיות שקשורות ל-LoAF, למשאבים שחוסמים רינדור ול-Core Web Vitals | click ו-drag מדמים אינטראקציות. performance_start_trace ו-performance_stop_trace מתעדים מעקב אחר ביצועים. הפקודה performance_analyze_insight מחזירה אבחון מפורט של התובנות במעקב. list_network_requests ו-get_network_request מציגים את הפעילות ברשת. lighthouse_audit בודק תחומים שלא קשורים לביצועים, כמו SEO ונגישות. |
כשהסוכן מוצא בעיה, כמו טקסט שנקטע במסכים קטנים, flex wrap פגום או תמונה לא אופטימלית שגורמת לשינוי פריסה, הוא מפעיל לולאת תיקון קצרה:
- כלי הפיתוח ל-Chrome לסוכני AI מתעדים את השגיאה המדויקת.
- הנציג מנתח את הנתונים ומשכתב את ה-CSS או ה-JavaScript הבעייתיים.
- הנציג טוען מחדש את הדף כדי לוודא שהבעיה נפתרה.
במסך אחד, הנציג עיבד את הדף וגילה שהפריסה, הריווח וההדרגה של הכותרת לא תואמים לעיצוב. הוא תיקן את קובצי ה-.scss הרלוונטיים. הוא גם ביצע אינטראקציה עם הדף, למשל הרחיב אקורדיונים כדי לבדוק שהמצבים הפתוחים שלהם תואמים לעיצובים.
שלב 4: העברת דוח מאומת לצוות בקרת האיכות
בסיום האימות, הנציג מספק קוד שמוכן לייצור יחד עם דוח ביקורת לצוות בקרת האיכות. הדוח כולל את המידע הבא:
- השוואה חזותית לעיצוב ב-Figma שמדגישה הבדלים בפיקסלים, על סמך צילומי מסך, תמונות מצב של DOM וסגנונות מחושבים.
- צילומי מסך של הדף שעבר רינדור בגדלים שונים של מסכים.
- אבחון של ביצועים ו-Core Web Vitals מ-
performance_start_traceומ-performance_analyze_insight, כמו Speed Index וסה"כ זמן חסימה (TBT). - ציוני Lighthouse בנושא SEO, שיטות מומלצות ונגישות מ-
lighthouse_audit. - בדיקות שעברו או נכשלו לאינטראקציות, כמו כיווץ שורות ומתגים, וגם שגיאות במסוף ושינויים במצב האפליקציה, כמו עריכת שורות, מחיקת שורות ומצבים ריקים.
ליישם את אותה גישה ב-30 דפי קמפיינים
בפלטפורמה הראשית של Policybazaar, החליפו את ההרצות הידניות של PageSpeed Insights בבדיקות שמופעלות דרך כלי הפיתוח ל-Chrome לסוכני AI ב-Kiro. לפני שדף הקמפיין עולה לאוויר, מהנדס מפעיל ביקורת על כתובת ה-URL של סביבת ה-Staging לנייד ולמחשב. הסוכן מריץ בדיקות ביצועים ובדיקות Lighthouse, וכלי הפיתוח ל-Chrome לסוכני AI שולפים באופן אוטומטי נתוני שדות בפועל מהדוח על חוויית המשתמש ב-Chrome (CrUX) לצד נתוני המעבדה. זה החליף לגמרי את השלב של PageSpeed Insights.
לאחר מכן, הסוכן מדווח על ציוני הביצועים, צווארי הבקבוק שהוא מצא ורשימה של שיפורים לפי סדר עדיפויות שהמהנדס צריך לתקן. בבדיקה אחת טרום-השקה, הוא סימן קריאות לא קריטיות ל-API שהופעלו בזו אחר זו במהלך טעינת הדף והתחרו בעבודת רינדור קריטית. הצוות תיקן את הבעיה לפני שהדף עלה לאוויר.
הסוכן משלים עכשיו 12 בדיקות ביצועים בזמן שמהנדס צריך כדי לסיים בדיקה אחת. זו ירידה של 92% בעבודה הידנית.
ביצועי האתר חשובים לנו כדי לשמור על חוויית משתמש טובה, אבל בדיקה ידנית, הערכת תרשימי Waterfall ועקבות בעשרות דפי נחיתה הייתה מייגעת וצוואר בקבוק משמעותי. כלי הפיתוח ל-Chrome לסוכני AI שינו את התהליך הזה וצמצמו את זמן בדיקת הביצועים של המהנדסים שלנו ב-92%, כך שהם יכולים להתמקד במשימות מורכבות יותר.
אמאן סוני, מנהל הנדסה, Policybazaar
השפעה
התכונות "הדרכה לפיתוח אתרים מודרניים" ו"כלי פיתוח ל-Chrome לסוכני AI" הפכו את בדיקות ממשק המשתמש ב-Policybazaar וב-Pensionbazaar מתהליך ידני ותגובתי לתהליך אוטומטי ויזום. בטבלה הבאה מוצגת השוואה בין תהליכי העבודה לפני השינוי ואחריו:
| אזור | לפני: בדיקה ידנית ומודלים בסיסיים | אחרי: Modern Web Guidance וכלי פיתוח ל-Chrome לסוכני AI |
|---|---|---|
| מאמצי ביקורת הביצועים (Policybazaar) | מהנדס הפעיל את PageSpeed Insights, בדק את מדדי Core Web Vitals ויישם תיקונים באופן ידני בכל אחד מ-30 דפי הנחיתה. | 92% פחות עבודה ידנית. הסוכן משלים 12 בדיקות בזמן שמהנדס צריך בשביל בדיקה אחת. |
| היקף הביקורת (Policybazaar) | היקף הבדיקה לא היה עקבי בין הווריאציות של הקמפיין. | 100% כיסוי של בדיקות ביצועים לדפי קמפיינים. |
| New screen turnaround (Pensionbazaar) | כמה ימים מהזנת הקוד ועד להצגת המסך "העסק אומת". | כמה שעות, מהיר יותר ב-90%. |
| באגים שקשורים לחוסר התאמה בעיצוב (Pensionbazaar) | ממשק משתמש חתוך ושינויי פריסה הגיעו לבדיקת איכות ידנית. | מספר הבאגים בממשק המשתמש ירד ביותר מ-90%. |
ההפחתה של 92% עקפה את היעד של הצוות, שעמד על יותר מ-80%. רגרסיות בדפי נחיתה מזוהות לפני שהן מגיעות לסביבת ה-staging או לבדיקות QA. ב-Pensionbazaar, הקוד מגיע כבר אחרי בדיקה עם צילומי מסך של כמה אזורי תצוגה, מה שמצמצם את התקשורת בין העיצוב, ההנדסה והבטחת האיכות.
מסקנות לצוות שלכם
- הסוכן שלכם יתבסס על הנחיות מוסמכות. הנחיות מותאמות אישית כמו Modern Web Guidance מונעות מהסוכנים להשתמש בתבניות מיושנות, ועוזרות לשמור על הקוד בתוך יעדי הבסיס.
- אל תאפשרו לסוכן לסמן משימת ממשק משתמש כ"בוצעה" לפני שהוא בדק את הדף שעבר עיבוד. כלי הפיתוח ל-Chrome לסוכני AI מאפשרים לסוכן לבדוק את הפריסה, אזורי התצוגה ועקבות הביצועים בדפדפן אמיתי.
- הגדירו קריטריונים ברורים ליציאה מהלולאה. הגדירו מגבלות על מספר השלבים ותנאים מפורשים להצלחה ולכישלון, כדי שהנציג לא ייכנס ללולאה ויבזבז טוקנים.
- התחילו עם דפים שמבוססים על תבניות ומתעדכנים בתדירות גבוהה. תהליכי עבודה במעגל סגור משתלמים במיוחד במקרים שבהם מהירות התגובה חשובה.
- הרצת בדיקות בדפדפן נקי כדאי להשתמש ב
--isolatedכדי שתוספים ונתונים שנשמרו במטמון לא ישפיעו על התוצאות או יחשפו מידע אישי.