Harness engineering: מה נשבר כש-OpenAI נתנו ל-Codex לכתוב מיליון שורות

סוף אוגוסט 2025: ריפו ריק ושלושה מהנדסים

סוף אוגוסט 2025. צוות פנימי ב-OpenAI דוחף commit ראשון לריפו ריק. את ה-scaffold כותב Codex CLI עם GPT-5: מבנה תיקיות, CI, כללי פורמט, package manager, framework. אפילו את AGENTS.md, הקובץ שמסביר ל-agent איך לעבוד בריפו, כתב Codex. לצוות היה חוק אחד: אף בן אדם לא כותב שורת קוד. לא באפליקציה, לא בטסטים, לא ב-CI ולא בתיעוד.

חמישה חודשים אחר כך יש בריפו בערך מיליון שורות ובסביבות 1,500 PRs ממוזגים. הצוות גדל משלושה מהנדסים לשבעה. הקצב עמד על 3.5 PRs למהנדס ביום, ועלה כשהצוות גדל, לא ירד. ההערכה שלהם היא שזה לקח עשירית מהזמן שהיה לוקח לכתוב ביד. ריאן לופופולו פרסם את זה בפברואר 2026, ומאז כולם מדברים על harness engineering.

אבל זה לא סיפור הצלחה נקי. החלק ששווה ללמוד ממנו הוא מה נשבר בדרך.

כמה חודשים פנימה: Codex מעתיק את עצמו

בגדול, Codex לומד מהריפו שהוא עובד בו. יש בריפו pattern? הוא ישכפל אותו, גם את הטובים וגם את הגרועים. בריפו ש-agents כתבו בו כל שורה אין קוד ותיק שמישהו כתב בזהירות ושמחזיק את הסגנון. כל קיצור דרך שנכנס פעם אחת הופך לתבנית שה-agent הבא מעתיק, ואז ה-agent שאחריו.

בירגיטה בקלר מ-ThoughtWorks כתבה ב-martinfowler.com על אותה תופעה אצל צוותים אחרים. עוזרי קוד בלי מגבלות שוכחים קונבנציות, חוזרים על אותן טעויות, ושוחקים לאט את העקביות של הקוד. זה לא באג ספציפי של OpenAI. ככה זה נראה בכל מקום שנותנים ל-agent לכתוב הרבה.

מבחוץ הכל ירוק

וזה החלק המעצבן. הקוד מתקמפל, הטסטים עוברים, וגרף ה-PRs נראה מעולה. אף alert לא קופץ כשהארכיטקטורה מתפרקת לאט. ב-Habitat Thinking, שמתעדים את הרעיון של בקלר, ניסחו את זה בשני משפטים: “The code continues to compile and pass tests. The degradation is quiet.”

המספרים מבחוץ מספרים אותו סיפור. דו״ח DORA מצא שיותר אימוץ AI הולך יחד עם יותר throughput בהעברת תוכנה, וגם עם יותר חוסר יציבות. Apiiro ספרו יותר מ-10,000 ממצאי אבטחה חדשים בחודש בקוד ש-AI כתב עד יוני 2025, פי 10 מדצמבר 2024. בקיצור, הקצב עולה והאיכות נשחקת, וה-dashboard מראה רק את הקצב.

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

התיקון הראשון: יום שישי של ניקיון

התגובה הראשונה של הצוות הייתה אנושית לגמרי. כל יום שישי, 20% מהשבוע, הם ניקו ידנית את מה שהם קראו לו AI slop. זה לא החזיק. אחרי 3.5 PRs ביום למהנדס, יום ניקיון בשבוע הוא דלי מול צינור פרוץ.

התיקון השני היה לכתוב יותר הוראות. AGENTS.md אחד גדול, עם כל הכללים. גם זה נפל, והם תיארו בדיוק למה: הקובץ אוכל את ה-context, כשהכל מסומן כחשוב שום דבר לא חשוב, והוא מתיישן מהר יותר ממה שמישהו מעדכן אותו.

רגע, למה שזה בכלל יעבוד? Augment ניסחו את זה טוב: לכתוב ל-agent ״תעקוב אחרי ה-coding standards שלנו״ זה ציות הסתברותי. לחבר linter שחוסם את ה-PR זו אכיפה דטרמיניסטית. שני התיקונים הראשונים של OpenAI נשארו בצד ההסתברותי.

הסיבה האמיתית: מה שה-agent לא רואה, לא קיים

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

אז הם הזיזו את הכללים פנימה. AGENTS.md התכווץ לבערך 100 שורות שמשמשות מפה לתיקיית docs/, וה-docs/ הפכה למקור האמת. את הגבולות בין השכבות אוכפים linters מותאמים, ש-Codex כתב בעצמו, והודעות השגיאה שלהם כוללות הוראת תיקון. ככה ה-agent קורא את השגיאה ומתקן לבד. מעל זה רצות משימות Codex ברקע, שסורקות את הריפו מול רשימת עקרונות שכתובה בריפו ופותחות PRs קטנים של refactor. זה garbage collection במקום יום שישי.

הם עצמם ניסחו את השינוי בתפקיד ככה:

what changes when a software engineering team’s primary job is no longer to write code, but to design environments, specify intent, and build feedback loops that allow Codex agents to do reliable work. — OpenAI, Harness engineering: leveraging Codex in an agent-first world

את הכלל שמאחורי זה מייחסים למיטשל השימוטו (HashiCorp, Terraform), שכתב בפברואר 2026 שכל טעות של agent מקבלת תיקון קבוע בסביבה, כדי שאותה טעות לא תחזור. אדי אוסמני נותן את הקרדיט על השם לויב טריוודי. זה שעדיין מתווכחים מי המציא את השם זה סימן טוב, לא רע.

מה לבדוק אצלכם השבוע

לא צריך מיליון שורות כדי להגיע לאותה נקודה. מספיק agent שפותח PRs כמה שבועות. הנה מה לבדוק:

• wc -l AGENTS.md CLAUDE.md. אם יצא יותר מ-150 שורות, תפצלו לקבצים ב-docs/ ותשאירו בקובץ הראשי רק מפה.
• תעברו על 20 הערות ה-review האחרונות שלכם על PRs של agents. כל הערה שחוזרת פעמיים היא check שעוד לא כתבתם.
• כל הודעת שגיאה של linter או של CI צריכה שורת FIX ושורת WHY שמפנה לדוק. ה-agent קורא את ההודעה, אז הוראות בתוכה יעבדו יותר טוב משורה ב-prompt.
• תריצו פעם בשבוע job מתוזמן שמבקש מה-agent למצוא סטיות מ-docs/principles.md ולפתוח עד שלושה PRs קטנים. לא יותר, אחרת אתם רק מעבירים את יום שישי ל-review.

זה linter הגבולות הכי פשוט שיש. הוא חוסם גישה ישירה ל-DB מחוץ לשכבה המותרת, ואומר ל-agent מה לעשות במקום:

import pathlib, re, sys

IMPORT_DB = re.compile(r'^\s*(from|import)\s+app\.db\b', re.M)
ALLOWED = ('app/repo/', 'app/db/')

bad = [p for p in pathlib.Path('app').rglob('*.py')
       if not str(p).startswith(ALLOWED) and IMPORT_DB.search(p.read_text())]

for p in bad:
    print(f'{p}: direct import of app.db outside the repo layer.\n'
          '  FIX: add a function in app/repo/ and call it from here.\n'
          '  WHY: docs/architecture.md#data-access')
sys.exit(1 if bad else 0)

תחברו אותו ל-pre-commit ול-CI, ותבדקו כמה PRs הוא תופס בשבוע הראשון. החלק המעניין בקובץ הזה הוא לא ה-regex, אלא שלוש השורות שמסבירות ל-agent מה לעשות אחרי שנחסם.