צ'קליסט ביקורת לפני production
22 דפוסי כשל ש-AI מייצר ומכניס לקוד production, ב-7 קטגוריות — עם סימני זיהוי ופעולות התיקון.
שמרו כ-PDF: לחצו Ctrl+P (Windows/Linux) או ⌘+P (Mac), ובחרו “שמור כ-PDF”. הדף מעוצב להדפסה נקייה.
איך להשתמש בצ'קליסט. הריצו אותו על כל codebase שנכתב עם תמיכה AI לפני deploy ל-production. עבור כל דפוס כשל, עברו על Detection מול הקוד האמיתי, לא מול ה-spec. אם Detection מצא hit, יישמו את ה-Prevention לפני ההשקה — לא כ-follow-up. הקטלוג נבנה מ-150+ engagement'ים שבהם קוד AI-assisted עבר ביקורת ראשונית ואז נפל תחת תנאי production. כל דפוס נצפה לפחות בשלושה engagement'ים בלקוחות עצמאיים לפני הכללתו.
CAT-CONCURConcurrency
כשלים שצצים תחת פעולות סימולטניות ש-AI לא מידל.
FM-01
חסר Optimistic locking
- AI מייצר
- קוד read-modify-write ללא בדיקת version או row-level lock. עובר ב-test חד-משתמשי.
- כשל ב-Production
- שתי כתיבות סימולטניות דורסות זו את זו בשקט. בעיית lost update תחת concurrency בינוני.
- זיהוי
- ביקורת קוד על כל read-modify-write ברשומות משותפות. Load test עם 10+ משתמשים סימולטניים על אותה entity.
- מניעה
- טוקן optimistic concurrency (rowversion / ETag) או pessimistic lock מפורש עם timeout ברור.
CAT-DATAשלמות נתונים
כשלים שמשחיתים או מאבדים נתונים מחוץ ל-happy-path.
FM-03
חסרים גבולות transaction
- AI מייצר
- רצף כתיבות רב-שלבי (order, payment, inventory) ללא transaction מפורש.
- כשל ב-Production
- commit חלקי ב-crash אמצע הרצף משאיר state לא-עקבי. הזמנות ללא decrement של inventory.
- זיהוי
- עקבו אחר כל פעולת multi-write. אם כשל בין שלבים משאיר state רע, חסר transaction.
- מניעה
- טווח transaction מפורש סביב יחידות לוגיות. Outbox pattern לכתיבות cross-service.
FM-12
איבוד דיוק decimal במתמטיקה של כסף
- AI מייצר
- float / double לסכומים כספיים. נראה כמו טיפוס מספרי.
- כשל ב-Production
- אגורות נעלמות או מופיעות לאורך זמן. drift ב-reconciliation. כשל audit.
- זיהוי
- כל שדה כסף שאינו Decimal / fixed-point הוא שגוי. כלל ביקורת קוד.
- מניעה
- טיפוס Decimal בכל מקום לכסף. עמודת DB עם precision מפורש. unit-tests על edge cases.
FM-13
טיפול בתאריכים ללא timezone
- AI מייצר
- DateTime נשמר ללא timezone; client ממיר ב-JS באופן שרירותי.
- כשל ב-Production
- דוחות פעורים בשעות. משימות daily-rollup מפספסות נתונים סביב חצות. audit trail שגוי.
- זיהוי
- כל שדה datetime — וודאו אחסון UTC; כל תצוגה — וודאו המרה ל-timezone המפורשת.
- מניעה
- שמרו UTC. הציגו ב-user-local ב-edge. אל תשוו datetimes naive.
FM-14
Cache ללא invalidation
- AI מייצר
- lookup-cache סביב query איטי. אין logic של invalidation בצד writer.
- כשל ב-Production
- נתונים stale מוגשים למשתמשים שעות אחרי השינוי. “למה ה-dashboard לא מתעדכן?”
- זיהוי
- לכל cache חייב להיות trigger invalidation מתועד. אם אין — flag.
- מניעה
- TTL מוגבל + invalidation מפורש על write. Stale-while-revalidate כשטריות רופפת.
FM-17
Schema migration ללא backfill
- AI מייצר
- ALTER TABLE שמוסיף עמודה non-null עם default אך ללא תוכנית backfill לשורות קיימות.
- כשל ב-Production
- migration ארוך נועל את production table לשעות. או גרוע מזה: שבירת constraint בשקט.
- זיהוי
- כל schema migration על טבלה לא-טריוויאלית צריכה תוכנית backfill שאושרה מראש.
- מניעה
- Expand-contract pattern. עמודה nullable תחילה, backfill, ואז enforce non-null.
FM-22
פגיעות time-window בקוד promo
- AI מייצר
- מימוש coupon שבודק remaining count ואז מבצע decrement בשלב נפרד.
- כשל ב-Production
- שני מימושים סימולטניים שניהם רואים remaining=1. שניהם מצליחים. inventory נסחף מתחת.
- זיהוי
- Atomic check-and-decrement; אחרת קיים race.
- מניעה
- פעולת DB אטומית (UPDATE ... WHERE remaining > 0). או distributed lock עם timeout.
CAT-LOADהתנהגות תחת עומס
כשלים שמתגלים רק בקנה מידה ש-AI לא בדק.
FM-02
דפוס N+1 query
- AI מייצר
- גישת ORM בלולאה ששולחת query נפרד לכל פריט. נראה idiomatic.
- כשל ב-Production
- טעינת דף עולה מ-50ms ל-5+ שניות כשהאוסף גדל. ספייקים ב-CPU של DB.
- זיהוי
- פרופייל queries אמיתיים על dataset מייצג. חפשו query count פרופורציונלי לגודל תוצאה.
- מניעה
- Eager loading / join / batched query. תקציב query-count per endpoint עם assert ב-tests.
FM-05
הקצאת משאבים לא חסומה
- AI מייצר
- List = readAll(); foreach item ... . בלי pagination, בלי cap.
- כשל ב-Production
- זיכרון מוצה כשה-dataset גדל. OutOfMemoryException על 50K שורות.
- זיהוי
- זהו כל קריאה בסגנון readAll. וודאו שגודל התוצאה מוגבל על-ידי request או paging.
- מניעה
- Streaming או pagination by default. דחו readAll על מקורות לא-חסומים בביקורת קוד.
FM-18
עבודה sync בתוך HTTP handler
- AI מייצר
- Endpoint שמבצע external API call inline לפני response.
- כשל ב-Production
- p99 latency עוקב אחרי ה-vendor האיטי ביותר. כשל cascading כשהווה vendor מאט.
- זיהוי
- כל דבר ב-sync handler שלוקח >100ms הוא candidate ל-async / queue.
- מניעה
- Background job + status endpoint לעבודה איטית. Async pipeline לעבודה non-critical-path.
CAT-SECUREאבטחה
פגיעויות ש-AI הכניס כי הוא לא threat-modeling את ה-surface הספציפי שלכם.
FM-07
SQL injection דרך concatenation
- AI מייצר
- SQL dynamic עם input משתמש מורכב כשparameterized query היה מסורבל.
- כשל ב-Production
- SQL injection טריוויאלי. exfiltration או הרס נתונים על-ידי input זדוני או fuzzed.
- זיהוי
- flag של static analysis על string + sql. ביקורת קוד לכל dynamic query.
- מניעה
- Parameterized queries by default. כלל lint שמדגיל string concatenation בבניית query.
FM-08
חסרה authorization בתוך data access
- AI מייצר
- Endpoint מאמת את המשתמש אבל ה-data query לא מסנן by ownership.
- כשל ב-Production
- משתמש מאומת מאחזר רשומות של tenant אחר על-ידי ניחוש IDs. דליפה cross-tenant.
- זיהוי
- כל קריאה multi-tenant חייבת לסנן by tenant key ב-query. בדקו עם שני משתמשים + IDOR probe.
- מניעה
- Row-level security ב-DB או tenant filter helper שעוטף כל query.
FM-09
Token / API key בקוד
- AI מייצר
- סוד hardcoded שעלה ל-repo בזמן integration.
- כשל ב-Production
- Repo ציבורי מדליף מפתח. נדרשת rotation. לעיתים גם bill shock.
- זיהוי
- Pre-commit hook שסורק strings high-entropy; secret scan תקופתי על history.
- מניעה
- Secret manager. אל תקבלו string literal שנראה כמו key בביקורת קוד.
FM-20
Prompt injection דרך retrieved content
- AI מייצר
- RAG handler מתייחס ל-chunks שאוחזרו כ-instructions לסמך.
- כשל ב-Production
- מסמך זדוני מרעיל את ה-response. AI assistant מבצע exfiltrate של context או מפעיל tool לא בטוח.
- זיהוי
- Threat-model את ה-corpus. אם document יכול להיכתב על-ידי משתמשים לא מהימנים, retrieval הוא vector injection.
- מניעה
- תוכן שאוחזר כ-data, לעולם לא instruction. System prompt שאוסר לעקוב אחרי instructions בתוכן שאוחזר. validation של output.
CAT-COSTעלות בקנה מידה
דפוסים שזולים בקנה מידה של prototype ונהיים בלתי-נשואים ב-production.
FM-10
עלות context LLM לא חסומה
- AI מייצר
- אחזור RAG ששולח top-50 chunks ל-LLM ללא קשר לרלוונטיות.
- כשל ב-Production
- חשבון 10-50x מהמתוכנן כי רוב ה-tokens הם רעש. גם latency נמרד.
- זיהוי
- מדדו tokens-per-query מול answered-with-citations rate. אנומליות בכל אחד מהשניים = סיגנל.
- מניעה
- Reranker לפני LLM, סף ביטחון, top-k tuned לפי use case. budget alarm על token spend.
FM-19
חסר rate limit על AI endpoint
- AI מייצר
- AI endpoint ציבורי ללא per-user / per-IP throttle.
- כשל ב-Production
- ניצול-לרעה מעלה את חשבון ה-LLM. שחקן יחיד רע יכול לחרוג מתקציב חודש בשעה.
- זיהוי
- כל endpoint נתמך-LLM חייב per-key rate limit. alarm מעל סף.
- מניעה
- Rate limiter עם budget alerting. Tiered quotas. authenticated-only AI endpoints by default.
CAT-RECOVERשחזור ודפוסי כשל
קוד שאין לו תוכנית ל-failure חלקי, retry או rollback.
FM-04
חסרה idempotency במסלול retry
- AI מייצר
- Webhook handler או job runner שמעבד הודעה פעם אחת, ללא dedupe.
- כשל ב-Production
- retry של רשת שולח duplicate event. הלקוח חויב פעמיים, מייל נשלח פעמיים.
- זיהוי
- שאלו: “מה קורה אם זה ירוץ פעמיים עם אותו input?” וודאו שקיים מפתח dedupe.
- מניעה
- Idempotency key על כל פעולה עם side-effect חיצוני. שמרו seen-keys לחלון retention.
FM-06
קריאה חיצונית ללא timeout
- AI מייצר
- HttpClient.GetAsync(url) ללא timeout. נראה נקי.
- כשל ב-Production
- outage של vendor תולה כל request תלוי. thread pool מוצה; כל ה-service למטה.
- זיהוי
- grep ל-HTTP clients, message queues, DB calls ללא timeouts מפורש.
- מניעה
- Timeout מפורש על כל IO call. Circuit breaker ל-failures חוזרים. Bulkhead pool isolation.
FM-11
חסר טיפול dead-letter
- AI מייצר
- Message handler שעושה retry על failure לנצח.
- כשל ב-Production
- Poison message חוסם את ה-queue. ה-backlog גדל; ה-processing קופא.
- זיהוי
- לכל retry policy צריך תנאי give-up ויעד ל-give-up.
- מניעה
- Retries מוגבלים, dead-letter queue, alerting על dead-letter count. מסלול manual review.
FM-21
אין מסלול rollback לפיצ'ר AI
- AI מייצר
- מחליף חישוב deterministic ב-LLM call. אין fallback.
- כשל ב-Production
- outage של LLM vendor מוריד את הפיצ'ר. אין mode מדורג.
- זיהוי
- לכל פיצ'ר AI: מה ה-system עושה כשה-AI לא זמין? אם “כלום” — תקנו.
- מניעה
- Feature flag + fallback deterministic. Graceful degradation. Health probes על תלות ה-AI.
CAT-EVOLVEאבולוציה לטווח ארוך
קוד שתקין עכשיו ויהיה blocker ל-refactoring בעוד 18 חודשים.
FM-15
Logging cross-cutting מצומד לקוד עסקי
- AI מייצר
- שורות log שזורות בתוך מתודות עסקיות, מעורבות עם returns.
- כשל ב-Production
- Refactoring משמיט observability קריטית בשקט. תגובת incident response נחלשת.
- זיהוי
- Audit logging כדי לוודא שזה cross-cutting concern, לא copy-paste inline.
- מניעה
- Structured logging via middleware / aspect. חוזה logging per layer, אכוף בביקורת.
FM-16
צימוד הדוק ל-LLM vendor
- AI מייצר
- קריאות SDK של vendor מפוזרות בקוד העסקי.
- כשל ב-Production
- עליית מחיר vendor או deprecation מחייבת לגעת בכל call site. Migration = רבעון.
- זיהוי
- grep לשמות SDK של vendor. אם הם מופיעים בקוד עסקי, חסר abstraction.
- מניעה
- LLM gateway עם prompts versioned ו-interface פנימי יציב. החלפת vendor = שינוי config אחד.
סיכום כיסוי
Concurrency1
שלמות נתונים6
התנהגות תחת עומס3
אבטחה4
עלות בקנה מידה2
שחזור ודפוסי כשל4
אבולוציה לטווח ארוך2
סך הכל22