‫10 הדברים המובילים ש-AI טועה בהם בפיתוח אתרים

Philip Walton

תאריך פרסום: 11 בנובמבר 2026

השבוע השקנו את גרסה 1.0 של Modern Web Guidance, קבוצת מיומנויות שמשלבת מומחיות בפלטפורמות אינטרנט, שיטות מומלצות ונתוני תאימות לדפדפנים ישירות בסוכני התכנות שלכם. המטרה שלנו ב-Modern Web Guidance היא לעזור למפתחים שמשתמשים בסוכני תכנות מבוססי-AI לנצל את מלוא העוצמה והיכולות של פלטפורמת האינטרנט המודרנית, ובסופו של דבר לשפר את חוויית המשתמשים באינטרנט.

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

לצערנו, התשובה היא "לא" – ואנחנו יודעים שהתשובה היא "לא" כי אנחנו בודקים את זה.

כל מדריך ב-Modern Web Guidance מגדיר קבוצה של ציפיות שצריכות להתקיים אם פועלים לפי השיטות המומלצות שבמדריך. לאחר מכן, חבילת ההערכה שלנו בודקת את המדריכים האלה על ידי מתן אותה הנחיה לסוכן שפועל עם Modern Web Guidance (הסוכן עם ההדרכה) ולסוכן אחר שפועל בלי Modern Web Guidance (הסוכן ללא ההדרכה). הפלט של שתי ההרצות נבדק בהתאם לציפיות שמוגדרות במדריך.

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

בממוצע, סוכני תכנות ללא הנחיה עוברים רק כ-50% מהבדיקות בחבילת ההערכה שלנו, בהשוואה לכ-90% כשמשתמשים ב-Modern Web Guidance.

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

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

1. נגישות: מיקוד מקלדת וניהול inert

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

ניהול המיקוד וinert הוא אחד מהפערים הגדולים ביותר בנגישות בהערכות שלנו, ואחד מהתחומים שמשתפרים הכי הרבה בעזרת Modern Web Guidance. הטעויות הנפוצות ביותר כוללות:

• לא מעבירים את המיקוד לתצוגות שנפתחו לאחרונה ושוכחים להחזיר את המיקוד לרכיב המפעיל כשמנווטים חזרה.
• הסתמכות על מלכודות טאב ידניות של JavaScript ו-aria-modal="true" במודלים מותאמים אישית, במקום להשתמש במודל <dialog> או לסמן תוכן ברקע inert.
• חשיפת כל פריט בסרגל כלים או ברשת כיוונית כעצירת טאב נפרדת, במקום להשתמש בעצירת טאב אחת עם tabindex נודד.
• יצירת קווי מתאר מותאמים אישית של :focus-visible שלא עומדים ביחס ניגודיות של 3:1 מול הרקעים הסמוכים.

2. נגישות: תמיכה בתנועה מופחתת

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

מודלי AI בדרך כלל זוכרים לבדוק אם יש prefers-reduced-motion כשהם מוסיפים מעברי CSS רגילים או אנימציות של פריימים מרכזיים. עם זאת, כשמשתמשים בתכונות חדשות יותר כמו גלילה חלקה, מעברי תצוגה או אנימציות מבוססות-גלילה, לעיתים קרובות שוכחים את התנועה המופחתת או עושים טעויות בהטמעה שלה:

• הגדרת scroll-behavior:smooth באופן גלובלי וללא תנאים ברכיב הבסיס.
• שימוש באנימציות CSS מבוססות-גלילה בלי בדיקה של הפחתת תנועה.
• הסרת משכי הזמן של transition בפריטים בקרוסלה כדי לאפשר תנועה מופחתת בזמן הגלילה, אבל שכחה להסיר גם את מאפייני הטרנספורמציה, מה שגורם לפריטים לקפוץ בגודל בזמן הגלילה.
• החלת איפוס גורף של משך הזמן של 0.01ms ב-*, ב-*::before וב-*::after כשהאפשרות "הפחתת תנועה" פעילה, וגם מחיקת כל המעברים החיוניים ללא תנועה (שנדרשים כדי להעביר שינויים במצב של ממשק המשתמש).
• הפעלת מעברים בין מסמכים ללא תנאים ושינוי האנימציות של ::view-transition-* כשהתכונה "הפחתת תנועה" פעילה, במקום רק להגביל את הכלל של @view-transition באמצעות בדיקת הפחתת התנועה.

3. נגישות: אימות טפסים, רמזים לגבי פורמטים ומצבי מילוי אוטומטי

טפסים הם אבן יסוד ברוב חוויות השימוש ההכרחיות (CUJ) באינטרנט. תקלה קטנה בטופס התשלום יכולה להשפיע באופן משמעותי על השורה התחתונה של העסק.

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

• הטמעה מחדש של אימות :user-invalid ב-CSS באמצעות JavaScript blur בהתאמה אישית, שלעיתים קרובות מסמן שדות required שלא נגעו בהם ברגע שהמשתמשים עוברים אותם באמצעות מקש Tab.
• המאפיין aria-invalid לא מסונכרן עם שגיאות גלויות, או שהמאפיין aria-invalid="true" מוגדר מוקדם מדי ב-blur, או שהמאפיין :user-invalid מעוצב ב-CSS בלי לסנכרן את aria-invalid ב-JavaScript.
• הסתמכות על טקסט placeholder שנעלם כדי להציג פורמטים נדרשים (כמו MM/YY בקלט של תאריך תפוגה של כרטיס) במקום רינדור של רמז קבוע שמקושר ל-aria-describedby.
• הצבת רמזים לגבי הפורמט וכללי הסיסמה מתחת ל<input> (במקום מעליו), כך שהם עלולים להיות מוסתרים על ידי מקלדות בנייד וחלונות קופצים של מילוי אוטומטי בדיוק כשהמשתמש צריך לקרוא אותם.
• הדגשת קלט :autofill על ידי שינוי צבע הגבול בלבד, במקום שילוב של צבע עם רמז שאינו צבע שלא משנה את הפריסה (כמו box-shadow פנימי).

4. חוויית המשתמש: תנועות החלקה ומגע

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

אפשר להטמיע הרבה מהאינטראקציות האלה באמצעות CSS וממשקי API מקוריים לגלילה, וכך לאפשר לדפדפן להריץ את הפיזיקה של התנועות מחוץ ל-thread הראשי. עם זאת, בהערכות שלנו, מודלים של AI לעיתים קרובות מתעלמים מהתכונות האלה:

• הטמעה של תנועות החלקה לסגירה או החלקה לחשיפה באמצעות מאזינים מסוג pointermove או touchmove במקום להשתמש ב-CSS Scroll Snap.
• השמטת overscroll-behavior-x:none בממשקים של החלקה בין כרטיסיות, מה שעלול להפעיל בטעות ניווט קדימה או אחורה בדפדפן במהלך החלקה מוגזמת.
• הפעלת אפקטים של התקדמות ההחלקה בשרשור הראשי בקריאות חוזרות (callbacks) של JavaScript במקום להשתמש באנימציות שמופעלות על ידי גלילה.
• אין תמיכה תקינה במיקוד מקלדת בחלוניות של פעולות החלקה שמבוססות על גלילה.

5. חוויית המשתמש: תיבות דו-שיח, חלונות קופצים ומעברים בשכבה העליונה

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

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

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

• יצירת שכבות-על מותאמות אישית של position:fixed עם רכיבי handler ידניים של לחיצה מחוץ לאלמנט כדי לסגור אותו, במקום להשתמש ב-popover.
• יצירת אנימציות כניסה ויציאה על ידי החלפת מחלקות מעבר ב-CSS ותיאום עם מאזינים של requestAnimationFrame() ו-transitionend (עם חלופות של setTimeout()), במקום לעשות זאת ב-CSS טהור עם @starting-style ו-transition-behavior.
• נעילת גלילת הדף מאחורי מודל פתוח על ידי הגדרת overflow:hidden ב-<html> במקום להשתמש ברכיב <dialog> כדי להכיל גלילה מעבר לקצה.
• הוספת מאזינים מסוג popstate כדי לזהות תנועות חזרה ב-Android ולסגור מודלים פתוחים, במקום להשתמש בפונקציונליות הסגירה המקורית של לחצן החזרה של רכיב <dialog> מודלי.

6. חוויית המשתמש: מצב כהה ואמצעי בקרה שמותאמים לעיצוב

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

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

• חסר <meta name="color-scheme" content="light dark"> ב-<head>, ולכן משתמשים במצב כהה רואים הבזק של אזור עריכה לבן בזמן שגיליונות סגנונות חיצוניים נטענים.
• עיצוב של עיצובים כהים או רכיבים עם משטחים כהים באמצעות צבעים בהתאמה אישית בלי להגדיר את color-scheme, כך שפסי הגלילה ופקדי הטפסים המקוריים נשארים תקועים במצב בהיר.
• התעלמות מהפונקציה light-dark() ב-CSS כשמגדירים אסימוני צבע שמותאמים לעיצוב ומשתנים אוטומטית בהתאם ל-color-scheme הפעיל.
• האפליקציה מספקת רק מתג בינארי למצב בהיר או כהה שמגדיר שינוי מפורש ב-localStorage, בלי אפשרות לחזור לברירת המחדל של מערכת ההפעלה.
• שכחתם להוסיף רכיב event listener מסוג storage, ולכן כרטיסיות פתוחות אחרות לא מסתנכרנות כשהמשתמש משנה עיצובים.

7. ביצועים: רספונסיביות וזרימה בזמן ריצה

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

בהערכות שלנו, המודלים בדרך כלל פועלים לפי השיטות המומלצות הקלאסיות לזמן טעינה, שמקודמות בכלים כמו Lighthouse כבר שנים, והם בדרך כלל יודעים להעביר לולאות כבדות ברורות ל-Web Worker. הם מתקשים באופן עקבי בתגובה של ה-thread הראשי, שחיונית לאופטימיזציה של INP: בידוד של עבודת הפריסה, תזמון משימות לפי עדיפות וניצול תכונות חדשות של HTML ו-CSS שמבצעות עבודת רינדור מחוץ ל-thread הראשי.

לדוגמה, לעיתים קרובות אנחנו רואים סוכנים:

• הפעלת תורים מותאמים אישית של setTimeout() לעבודה ברקע או בעדיפות נמוכה, במקום לתעדף משימות שגלויות למשתמשים באמצעות scheduler.postTask() או לנצל את המשך המשימה באמצעות scheduler.yield() כשהדפדפן תומך בכך.
• יצירת פריסות מורכבות (כמו רשתות נתונים צפופות) בלי להחיל את content-visibility:auto ו-contain-intrinsic-size, מה שאומר שעדכונים אחרי אינטראקציות של משתמשים מפעילים עיצוב מחדש של דף מלא.
• הסתרת תצוגות SPA לא פעילות באמצעות display:none (או הסרה שלהן) במקום להשתמש ב-content-visibility:hidden (בשילוב עם inert). האפשרות הראשונה משמידה את מצב הרינדור שנשמר במטמון, כך שהחזרה לתצוגה מפעילה פריסה וצביעה מלאות.
• השהיית אנימציות של <canvas> מחוץ למסך ולולאות ברקע באמצעות קריאות חוזרות (callback) של Intersection Observer במקום התאמה של content-visibility:auto לאירוע contentvisibilityautostatechange (אם זמין), בלי להשתמש בשוליים של העיבוד מראש בדפדפן לפני שגוללים לאלמנטים.
• יצירת רמזים בממשק המשתמש לגבי אפשרויות גלילה באמצעות רכיבי event listener מסוג scroll שמאלצים חישובים רציפים של הפריסה, במקום להשתמש בשאילתות CSS של מצב גלילה כשהן זמינות (עם חלופות של Intersection Observer).

8. ביצועים: שינויים בפריסה והבהובים חזותיים

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

המודלים מוסיפים באופן מהימן מאפייני width ו-height לרכיבי <img> רגילים כדי למנוע שינויים בפריסה, אבל הם מפספסים באופן עקבי מקורות נפוצים אחרים של שינויים בפריסה והבהובים לפני הצביעה מרכיבי <video>, החלפות של גופנים באינטרנט, סרגלי כלים של דפדפנים בנייד וניסויים בצד הלקוח – כל אלה יכולים להשפיע על CLS.

• השמטת מאפייני width ו-height מפורשים ברכיבי <video> (כך שנגנים שלא נטענו מוגדרים כברירת מחדל ל-300×150 ומשנים את הפריסה לאחר טעינת המטא-נתונים), או עיצוב רכיבי wrapper של מדיה במקום להגדיר את aspect-ratio ו-object-fit ישירות ברכיבי מדיה.
• התאמה של גופני אינטרנט לגופני ברירת מחדל של המערכת בלי font-size-adjust, שגורמת לפסקאות ולכותרות לשנות את הפריסה באופן גלוי כשגופני האינטרנט מתחלפים.
• הגדרת הגודל של אזורי Hero ופריסות במסך מלא באמצעות יחידות vh סטטיות במקום יחידות דינמיות או קטנות של אזור תצוגה (dvh,‏ svh), מה שגורם לתוכן לקפוץ כשסרגלי הכלים של הדפדפן בנייד מתרחבים ומתכווצים.
• הסתרת תוכן באמצעות קטעי קוד מדור קודם לטעינה חלקה של opacity:0 או visibility:hidden וזמני קצובים לתפוגה של כמה שניות לבדיקות A/B בצד הלקוח (עיכוב של LCP והשארת רכיבים בלתי נראים שניתן ללחוץ עליהם), במקום להשתמש בסקריפטים עם blocking="render" כשהם זמינים.
• הפעלת מעברים בין תצוגות של מסמכים שונים לפני ניתוח של תגי עיצוב קריטיים בחלק העליון של הדף, במקום להשהות את הרינדור הראשוני באמצעות rel="expect" ו-blocking="render", מה שגורם לרכיבים שנותחו באופן חלקי להופיע באמצע המעבר.

9. אבטחה: הגנות מפני DOM XSS וחיטוי HTML

פגם אחד של פרצת אבטחה XSS‏ (cross-site scripting) מאפשר לתוקף להריץ קוד שרירותי בדפדפנים של המשתמשים, לגנוב נתוני סשן או לבצע פעולות בשמם. לכן חשוב כל כך להשתמש באמצעי הגנה שנאכפים על ידי הדפדפן, כמו הסרת תוכן זדוני או רגיש מ-HTML בטוח, Trusted Types ו-CSP מחמירים.

מודלים לא מתייחסים לעיתים קרובות לחששות האלה בנוגע לאבטחה באופן יזום. לדוגמה, בכל המשימות בחבילת ההערכה המלאה שלנו, המודלים לא הוסיפו כותרת של Content Security Policy‏ (CSP) או של חסימת גישה מדומיינים אחרים בלי הנחיה מפורשת.

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

• כתיבת פונקציות מותאמות אישית להסרת תוכן זדוני או רגיש מרשימת ההיתרים של DOMParser – כחלופה ל-setHTML() או בתוך מדיניות של Trusted Types – במקום להשתמש בספרייה שנבדקה כמו DOMPurify כשאין אפשרות להסרת תוכן זדוני או רגיש באופן מקורי.
• הוספה של DOMPurify לכל טעינת דף במקום להשתמש ב-setHTML() המקורי כשהוא נתמך, וטעינה מדורגת של DOMPurify רק כגיבוי.
• רישום של כללי מדיניות מתירניים של (input) => input מסוג Trusted Types, שפוגעים באכיפה של sink.
• שילוב של Trusted Types בדפים סטטיים עם רשימת מארחים מותרים script-src 'self' של מדיניות אבטחת תוכן (CSP), במקום לנעול סקריפטים מוטבעים באמצעות גיבוב (hash) של SHA-256.
• השמטת 'strict-dynamic' ו-'report-sample' כשמגדירים מדיניות אבטחת תוכן (CSP) מבוססת-nonce ב-script-src.

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

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

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

• המרת Base64URL ידנית של atob() ו-btoa() – כנתיב הראשי או כקוד סטנדרטי מיותר כחלופה – במקום להסתמך על שיטות סריאליזציה מובנות כמו parseCreationOptionsFromJSON(),‏ parseRequestOptionsFromJSON() ו-credential.toJSON().
• השמטת PublicKeyCredential.signalUnknownCredential() במהלך הכניסה כשהשרת מדווח על מזהה פרטי כניסה לא ידוע, והשארת מפתחות גישה שנמחקו או בוטלו במנהלי הסיסמאות של המשתמשים.
• המערכת מדלגת על PublicKeyCredential.getClientCapabilities() לפני עיבוד ממשק המשתמש ליצירה ולניהול של מפתחות גישה.
• השמטת AbortController ו-AbortSignal כשמתחילים בקשות לאימות מחדש באמצעות מפתח גישה משודרג.
• העברת האפשרות mediation:"immediate" של גרסת המקור לניסיון במקום uiMode:"immediate" להצגת הצעות יעילות יותר לכניסה לחשבון.

לסגור את הפערים האלה

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

החדשות הטובות הן ש-Modern Web Guidance נותן מענה לכל הפערים האלה, והוא ימשיך להתפתח יחד עם הפלטפורמה.

כדי להתחיל להשתמש ב-Modern Web Guidance, מריצים את הפקודה הבאה או מחפשים אותה ב-Marketplace של הפלאגינים של הנציג:

npx modern-web-guidance@latest install

האם ראיתם מודלים שטועים במשימות אחרות של פיתוח אתרים? אנו רוצים לשמוע על כך. פתחו בעיה במאגר של Modern Web Guidance ב-GitHub או עזרו לנו לסגור את הפערים האלה בשביל מפתחים אחרים על ידי תרומה לפרויקט.