שיטות הבדיקה לקוד שנכתב על ידי בינה מלאכותית: על פי Uncle Bob

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

Uncle Bob Martin @unclebobmartin

I'm significantly older than you. I started coding in the late 60s. My current strategy is to not read any of the code written by my agents. That's the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, test coverage, and a plethora of others. In the end, I have very high confidence in the code they produce because they've had to run the gauntlet of all of my constraints and tests.

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

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

מי כותב ומי בודק

בתגובה ל-@brunocalza ולפומרנץ, הוא פירט אודות תהליך העבודה בצורה ישירה:

Uncle Bob Martin @unclebobmartin

My agents write the unit tests. I don't review those. They also write the gherkin acceptance tests and the QA procedures. I review those. Sometimes thoroughly, and sometimes as a spot check, depending on criticality. I also, periodically, do a final manual test.

ובטבלה פשוטה:

תוצר (Artifact)	מי כותב אותו	מי בודק אותו (Review)
קוד יישום (Implementation)	סוכן (Agent)	אף אחד, בכוונה תחילה
בדיקות יחידה (Unit tests)	סוכן	אף אחד, בכוונה תחילה
בדיקות קבלת Gherkin	סוכן	מרטין — משתנה בהתאם לחשיבות
נהלי QA	סוכן	מרטין — משתנה בהתאם לחשיבות
בדיקה ידנית סופית	—	מרטין, באופן מדגמי/תקופתי

אז זה לא אומר לסמוך על הסוכן "על עיוור" אבל זה גם לא לבדוק כל שורה.

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

מדוע להגדיר אילוצים מראש, ולא לתקן אחרי?

בתגובה ל-@m0nkeypatch (חלק מאותו שרשור), מרטין הסביר מדוע הוא לא פשוט נותן לסוכנים לכתוב מה שהם רוצים ומתקן את זה מאוחר יותר:

Uncle Bob Martin @unclebobmartin

I think it matters still, and I think it matters a lot. Messy code slows my agents down. I've seen them wrangle with their own messes without resolution. I finally had to step in and untangle their own mess. So I don't let them create those tangles. I constrain the hell out of function sizes, cyclomatic complexity, and test coverage. That seems to keep them moving smoothly.

הוא צפה בסוכנים נתקעים בלולאות בניסיון לתקן את הקוד המסובך של עצמם ונכשלים, והפתרון לא היה סוכן חכם יותר — אלא מניעת היווצרות התסבוכת מלכתחילה. לעוקב אחר הוא הוסיף שהוא קובע גם מגבלות על גודל הפונקציה, מורכבות וספי כיסוי (coverage thresholds), ולא משאיר אותם לשיקול דעתו של הסוכן.

האם עומס הבדיקות באמת משתלם ותמיד חייב לבצע אותם?

בפוסט נפרד, מרטין כתב:

Uncle Bob Martin @unclebobmartin

I've been pushing very hard on overloading with tests. Gherkin test unit test QA test mutation test gherkin mutation test. It's easy to make the AI's do these things. But just because we can do them doesn't mean we actually should.

Lots of times I just use unit tests and crap evaluation. That seems to work pretty well. For larger projects I can imagine that gherkin testing is pretty useful and so is QA testing. I'm checking that now.

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

מה שאומר ש**"העמסת" בדיקות היא משימה די קלה לאוטומציה, אבל לא תמיד שווה או מצדיקה את המשימה.**

תגובות הקהל ברשת

הציוצים הופצו והפכו לויראלים (נכון לכתיבת שורות אלו זה כ-4.8 מיליון צפיות לציוץ!). בין התגובות, רבים אישרו את שיטתו: "ככה גם אני עושה את זה. אני עדיין עובר על הקוד כי ממש אכפת לי, אבל קודם כל זה עובר את מסלול המכשולים (gauntlet) שלי."

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

אז איך מיישמים את זה?

• ב-GitHub, פרויקט של המשתמש swingerman, בשם engineering-agentic-disciplined — מתואר במפורש כ-"Acceptance Test Driven Development (פיתוח מונחה בדיקות קבלה) עבור Claude Code", בהשראת גישתו של Uncle Bob. מתאים למפתחים עם ניסיון: github.com/swingerman/disciplined-agentic-engineering
• מאמר מיוני 2026 ב-Medium מאת אדריאן ביילדור מתאר גרסה רשמית של אותו רעיון כולל יישומים.

מגבלות

האם זה תקף גם למפתחים חסרי ניסיון?

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

האם תמיד חייב לעשות המון בדיקות?

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