מה תלמדו

מדריך זה מכסה את Harness Engineering מעקרונות יסוד ועד ליישום מעשי. אתם תבינו מה זה, למה OpenAI הימרה על הפרויקט הפנימי הגדול ביותר שלה על זה, את הדפוסים הארכיטקטוניים הספציפיים שגורמים לזה לעבוד, וכיצד ליישם את העקרונות הללו בתזרימי העבודה של סוכני ה-AI שלכם — בין אם אתם משתמשים ב-Codex, Claude Code, OpenCode, או כל מערכת סוכנים אחרת.

Harness Engineering: המדריך המלא לפיתוח סוכני AI בשנת 2026

אם 2025 הייתה השנה שבה סוכני AI הוכיחו שהם יכולים לכתוב קוד, 2026 היא השנה שבה למדנו שהסוכן הוא לא החלק הקשה — ה-harness הוא החלק הקשה.

צוות Codex של OpenAI פרסם פוסט פורץ דרך בבלוג בפברואר 2026 המתאר כיצד הם בנו אפליקציית Production המכילה בערך 1,000,000 שורות קוד כאשר אפס שורות נכתבו על ידי ידיים אנושיות. הסוד לא היה מודל טוב יותר או prompt חכם יותר. זו הייתה המערכת שהם בנו סביב הסוכן — ה-harness. Source

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

חלק 1: מה זה Harness Engineering?

ההגדרה

Harness Engineering היא הדיסציפלינה של עיצוב הסביבה כולה — scaffolding, לולאות משוב, תיעוד, אילוצים ארכיטקטוניים ותוצרים קריאים למכונה — המאפשרת לסוכני קידוד AI לבצע עבודה אמינה ואיכותית בקנה מידה רחב עם התערבות אנושית מינימלית.

המונח "harness" מגיע מעולם הרכיבה על סוסים (רתמה): מושכות, אוכף, מתג — הסט המלא של הציוד לתיעול חיה עוצמתית אך בלתי צפויה לכיוון הנכון. סוס ללא שליטה הוא מסוכן. סוס רתום (harnessed) בנה תרבויות. אותו דבר חל על סוכני AI. Source

למה זה צץ עכשיו

המעבר מ-Prompt Engineering ל-Harness Engineering משקף התבגרות של נוף פיתוח ה-AI:

Source

התובנה המרכזית שהובילה למעבר הזה: סוכנים הפכו למספיק מוכשרים כך שצוואר הבקבוק עבר מאיכות המודל לאיכות הסביבה. מודל State-of-the-art הפועל בתוך repository בעל מבנה גרוע מפיק תוצאות פחות טובות ממודל בינוני הפועל בסביבת harness בנויה היטב.

חלק 2: הניסוי של OpenAI Codex

קנה המידה

בניסוי פנימי שנמשך 5 חודשים, מהנדסי OpenAI בנו והשיקו מוצר בטא המכיל בערך 1,000,000 שורות קוד. ה-repository משתרע על לוגיקת אפליקציה, תשתית, כלי עבודה, תיעוד וכלי עזר פנימיים למפתחים. לא היה קוד קודם שנכתב על ידי בני אדם כדי לעגן את המערכת. Source

הצוות

הפרויקט התחיל עם 3 מהנדסים בלבד שהפעילו את Codex. במהלך תקופה של 5 חודשים, נפתחו ומוזגו בערך 1,500 pull requests. ככל שהצוות גדל ל-7 מהנדסים, התפוקה גדלה — תוצאה מנוגדת לאינטואיציה שהצביעה על כך שה-harness עצמו היה מכפיל הפרודוקטיביות העיקרי, ולא הכישורים האישיים.

OpenAI מעריכה שהם בנו את המערכת בערך ב-1/10 מהזמן שהיה לוקח לכתוב את הקוד ביד. Source

ה-Scaffold הראשוני

הפרויקט התחיל עם Codex CLI שיצר את ה-scaffold הראשוני באמצעות GPT-5, בהנחיית סט קטן של תבניות קיימות:

• מבנה ה-repository ומוסכמות ספריות
• קונפיגורציית CI/CD
• כללי פורמט קוד ו-linting
• הגדרת מנהל חבילות (Package manager)
• Boilerplate של Application framework

מתוך הזרע הזה, כל השאר צמח דרך פיתוח מונע-סוכנים (Agent-driven development).

בעיית יום שישי

בשלב מוקדם של הניסוי, הצוות גילה בעיה קריטית: הם בילו כל יום שישי — 20% מזמן ההנדסה שלהם — בניקוי מה שהם כינו "AI slop". זה כלל דפוסים לא עקביים, לוגיקה משוכפלת, משתנים בשמות שגויים וסטייה ארכיטקטונית.

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

חלק 3: חמשת עקרונות הליבה

עיקרון 1: Repository-First Knowledge

מנקודת המבט של הסוכן, כל דבר שהוא לא יכול לגשת אליו בתוך ה-context בזמן הריצה למעשה אינו קיים. ידע שחי ב-Google Docs, בשרשורי צ'אט, בהודעות Slack או בראשם של אנשים הוא בלתי נראה למערכת.

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

• קוד — התוצר העיקרי
• תיעוד Markdown — החלטות ארכיטקטורה, מוסכמות, מדריכי Onboarding
• Schemas — חוזי API, סכימות של בסיסי נתונים, הגדרות Type
• תוכניות ברות ביצוע — פירוק משימות שלב-אחר-שלב שהסוכן יכול לעקוב אחריהן
• קונפיגורציה — כללי linter, תהליכי CI, סטנדרטים של פורמט

הצוות למד שהם צריכים לדחוף יותר ויותר context לתוך ה-repo לאורך זמן. בכל פעם שסוכן טעה בגלל מחסור ב-context, התיקון לא היה prompt טוב יותר — אלא הוספת ה-context הזה ל-repository. Source

יישום מעשי:

# ARCHITECTURE.md (lives in repo root)

## Dependency Rules
- UI components may import from Service layer but never from Repo layer
- Service layer may not import from Runtime layer
- All cross-domain communication goes through typed event bus

## Naming Conventions
- React components: PascalCase, suffixed with purpose (UserListPage, UserCard)
- Services: camelCase, suffixed with Service (userService, authService)
- Types: PascalCase, prefixed with domain (UserProfile, OrderItem)

## Testing Requirements
- All Service functions require unit tests
- All API endpoints require integration tests
- Coverage threshold: 80% per package

עיקרון 2: עקרונות זהב (Golden Principles)

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

דוגמאות מהניסוי של OpenAI:

1. העדף חבילות utility משותפות על פני עוזרים שנכתבו ידנית — מרכז את ה-invariants כך שכאשר התנהגות צריכה להשתנות, היא משתנה במקום אחד.
2. אל תחקור נתונים בסגנון YOLO — בצע וולידציה לגבולות או הסתמך על SDKs מוגדרים (typed) כך שסוכנים לא יוכלו לבנות בטעות על צורות נתונים משוערות.
3. קונספט אחד, קובץ אחד — כל קובץ צריך לייצג קונספט יחיד, מה שמקל על סוכנים למצוא ולשנות את המיקום הנכון.
4. מפורש על פני משתמע (Explicit over implicit) — הימנע מהתנהגות "קסומה" שסוכן יצטרך ידע שבטי כדי להבין.

Source

עקרונות אלו אינם רק תיעוד. הם נאכפים על ידי:

• כללי Linter — לינטרים מותאמים אישית (שנוצרו בעצמם על ידי Codex) המסמנים הפרות.
• מבחנים מבניים — מבחנים המאמתים תאימות ארכיטקטונית.
• CI gates — pull requests המפרים את עקרונות הזהב נדחים אוטומטית.

עיקרון 3: ארכיטקטורה שכבתית עם אכיפה מכנית

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

Types → Config → Repo → Service → Runtime → UI

התלויות זורמות בכיוון אחד בלבד. רכיב UI עשוי להיות תלוי ב-Runtime וב-Service, אך Service לעולם לא ייבא מ-UI. Repo עשוי להיות תלוי ב-Config וב-Types, אך לעולם לא ב-Service. Source

אילוצים אלו נאכפים מכנית:

// structural-test.ts — enforces dependency boundaries
import { analyzeImports } from './tools/import-analyzer';

describe('Dependency Layer Enforcement', () => {
  it('Service layer must not import from Runtime', () => {
    const violations = analyzeImports({
      sourceLayer: 'service',
      forbiddenLayers: ['runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });

  it('Repo layer must not import from Service', () => {
    const violations = analyzeImports({
      sourceLayer: 'repo',
      forbiddenLayers: ['service', 'runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });
});

המבחנים המבניים מאמתים תאימות ומונעים הפרות של שכבות מודולריות. זו אינה הצעה — זו אכיפה על ידי CI. כל pull request, בין אם נוצר על ידי אדם או סוכן, חייב לעבור את המבחנים הללו.

עיקרון 4: Automated Garbage Collection

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

1. סורקות סטיות מעקרונות הזהב לאורך כל בסיס הקוד.
2. מעדכנות ציוני איכות עבור כל מודול בהתבסס על ציוני תאימות.
3. פותחות pull requests לביצוע refactoring ממוקד שמתקנים קטגוריות ספציפיות של סטייה.

זה החליף את "ניקוי יום שישי" הידני במערכת שרצה ברציפות. ה-Garbage collector עצמו מופעל על ידי סוכני Codex, מה שיוצר לולאה של תחזוקה עצמית. Source

# .github/workflows/garbage-collection.yml
name: Codebase Garbage Collection
on:
  schedule:
    - cron: '0 2 * * *'  # Run nightly at 2 AM

jobs:
  gc-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run golden principle scanner
        run: npx codex-gc scan --principles ./GOLDEN_PRINCIPLES.md
      - name: Generate refactoring PRs
        run: npx codex-gc fix --auto-pr --max-prs 5

עיקרון 5: תוכניות ברות ביצוע (Executable Plans)

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

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

# Plan: Add user notification preferences

## Objective
Allow users to configure which notification channels (email, SMS, push) they
receive alerts on, with per-category granularity.

## Files to Modify
- src/types/user.ts — Add NotificationPreferences type
- src/repo/userRepo.ts — Add getPreferences/setPreferences methods
- src/service/notificationService.ts — Filter notifications by preferences
- src/ui/pages/SettingsPage.tsx — Add preferences UI section

## Constraints
- Must follow Types → Repo → Service → UI dependency flow
- NotificationPreferences type must be shared, not duplicated
- All new methods require unit tests

## Acceptance Criteria
- [ ] User can toggle email/SMS/push per notification category
- [ ] Preferences persist across sessions
- [ ] Toggling a channel off stops notifications on that channel within 30s

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

חלק 4: לולאת הסוכן של Codex

הבנת האופן שבו לולאת הסוכן של Codex פועלת בתוך ה-harness חיונית עבור Harness Engineering אפקטיבי.

ארכיטקטורת הלולאה

OpenAI פרסמה פירוט מפורט של לולאת הסוכן של Codex בפוסט המשלים שלהם "Unrolling the Codex agent loop". Source הלולאה עוקבת אחר המחזור הבא:

Read Context → Plan → Execute → Validate → Commit (or Retry)

בכל איטרציה:

1. Read Context: הסוכן קורא קבצים רלוונטיים, תיעוד, סכימות ותוכנית המשימה מה-repository.
2. Plan: בהתבסס על ה-context, הסוכן קובע אילו שינויים לבצע.
3. Execute: הסוכן כותב או משנה קוד.
4. Validate: ה-harness מריץ מבחנים, לינטרים ובדיקות מבניות מול השינויים.
5. Commit or Retry: אם האימות עובר, הסוכן מבצע commit. אם הוא נכשל, הסוכן קורא את פלט השגיאה ומנסה שוב.

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

ה-App Server Harness

בפוסט שלהם "Unlocking the Codex harness: how we built the App Server", OpenAI מתארת את התשתית המוחשית שמפעילה את לולאת הסוכן. Source ה-App Server מספק:

• סביבות הרצה מבודדות (Sandboxed) עבור כל משימת סוכן.
• גישה לכלי עבודה מוגדרים מראש (מערכת קבצים, טרמינל, דפדפן).
• הזרקת context אוטומטית מתוצרי ה-repository.
• משוב אימות בסטרימינג כך שסוכנים יכולים לראות כשלי מבחנים בזמן אמת.

חלק 5: יישום Harness Engineering בצוות שלכם

איך מתחילים: ה-Minimum Viable Harness

אתם לא צריכים לשכפל את כל התשתית של OpenAI כדי להפיק תועלת מ-Harness Engineering. התחילו עם רכיבי היסוד הללו:

שלב 1: צרו קובץ ARCHITECTURE.md

תעדו את הכללים הארכיטקטוניים של הפרויקט שלכם בפורמט קריא למכונה בשורש ה-repository. כללו:

• גבולות מודולים ותלויות מותרות
• מוסכמות שמות
• כללי ארגון קבצים
• דרישות בדיקה

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

שלב 2: הוסיפו מבחנים מבניים

כתבו מבחנים המאמתים את הכללים הארכיטקטוניים שלכם. מבחנים אלו אינם בודקים לוגיקה עסקית — הם בודקים שהקוד מאורגן נכון:

// No service file should import from a UI module
test('service layer isolation', () => {
  const serviceFiles = glob('src/services/**/*.ts');
  for (const file of serviceFiles) {
    const imports = extractImports(file);
    const uiImports = imports.filter(i => i.startsWith('../ui/'));
    expect(uiImports).toHaveLength(0);
  }
});

שלב 3: הגדירו אימות CI

ודאו שצינור ה-CI שלכם מריץ מבחנים מבניים, לינטרים ובדיקות types על כל pull request — כולל אלו שנוצרו על ידי סוכנים. הסוכן צריך לראות את אותו פלט אימות שמפתח אנושי היה רואה.

שלב 4: כתבו תוכניות משימה לפני ביצוע הסוכן

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

שלב 5: הגדירו ניקוי אוטומטי

הטמיעו משימת CI שבועית או לילית הסורקת את בסיס הקוד שלכם עבור סטיות מהסטנדרטים המתועדים ויוצרת pull requests ממוקדים ל-refactoring.

בחירת מערכת הסוכנים שלכם

עקרונות Harness Engineering חלים ללא קשר לסוכן שבו אתם משתמשים:

ה-harness חי ב-repository שלכם, לא בסוכן שלכם. זה אומר שאתם יכולים להחליף סוכנים מבלי לאבד את ההשקעה שלכם ב-harness.

צמיחה מסוכן אחד לרבים

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

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

1. בעלות ברורה על מודולים — כל סוכן עובד בתוך גבול מוגדר.
2. ממשקים מוגדרי types בין מודולים — סוכנים יכולים לקודד מול ממשקים מבלי להכיר פרטי מימוש.
3. מניעת קונפליקטים במיזוג — המשימות מוגדרות ב-scope שממזער חפיפת קבצים.
4. אימות מרכזי — כל הסוכנים מגישים לאותו צינור CI.

חלק 6: מכשולים נפוצים ו-Anti-Patterns

Anti-Pattern 1: התייחסות לסוכן כאל ה-Harness

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

Anti-Pattern 2: תיעוד במקום הלא נכון

אם ההחלטות הארכיטקטוניות שלכם חיות ב-Confluence, Notion או Google Docs, סוכנים לא יכולים לראות אותן. התיקון פשוט אך דורש משמעת: העבירו את כל התיעוד הרלוונטי לפיתוח לתוך ה-repository.

Anti-Pattern 3: ניקוי ידני במקום אכיפה אוטומטית

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

Anti-Pattern 4: אילוץ יתר (Over-Constraining)

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

Anti-Pattern 5: התעלמות ממשוב הסוכן

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

חלק 7: העתיד של Harness Engineering

נקודת המבט של Martin Fowler

Martin Fowler פרסם ניתוח של Harness Engineering בבלוג שלו, וציין כי הוא מייצג שינוי יסודי באופן שבו צוותי תוכנה פועלים. הדיסציפלינה שואלת מעשורים של שיטות עבודה מומלצות בהנדסת תוכנה — continuous integration, architecture decision records, dependency injection — אך מתאימה אותם מחדש לעולם מונע-סוכנים. Source

המסגרת של HumanLayer

הצוות ב-HumanLayer פרסם את הניתוח שלהם המכנה את Harness Engineering "בעיית מיומנות" (skill issue) — בטענה שהיכולת לעצב harnesses אפקטיביים תהפוך למבדיל העיקרי בין צוותי הנדסה בעלי ביצועים גבוהים לאלו שנאבקים. Source

מה זה אומר עבור מפתחים

Harness Engineering לא מחליף את כישורי המפתח — הוא מכוון אותם מחדש. במקום לכתוב קוד, מהנדסים בכירים מעצבים את המערכות המאפשרות לסוכנים לכתוב קוד היטב. המיומנויות החשובות עוברות מיישום לארכיטקטורה, מכתיבת קוד לעיצוב מערכות, מכתיבת מבחנים לעיצוב מסגרות בדיקה (test frameworks).

עבור צוותים הבונים אפליקציות, פלטפורמות כמו ZBuild כבר משלבות עקרונות Harness Engineering בתהליכי העבודה של בונה האפליקציות שלהן. במקום לדרוש ממפתחים לעצב harnesses משלהם מאפס, ZBuild מספקת דפוסים ארכיטקטוניים מוגדרים מראש, ניהול תלויות ומערכות אימות המנחות סוכני AI לעבר פלט באיכות גבוהה — מה שמאפשר למפתחים להתמקד בהחלטות מוצר ולא בתשתית.

שלושת האופקים

במבט קדימה, Harness Engineering צפוי להתפתח דרך שלושה שלבים:

1. טווח קצר (2026): צוותים מאמצים תיעוד מבוסס repository תחילה, מבחנים מבניים ועקרונות זהב. פיתוח בסיוע סוכנים הופך לפרקטיקה סטנדרטית עבור פרויקטים בעלי harness טוב.

2. טווח בינוני (2027): יצירת ה-harness עצמו הופכת למונעת-סוכנים. סוכנים מנתחים בסיסי קוד קיימים ומציעים קונפיגורציות harness — כללי linter, מבחנים מבניים, גבולות תלות — בהתבסס על הדפוסים שהם מזהים.

3. טווח ארוך (+2028): ה-Harnesses הופכים לאדפטיביים. במקום כללים סטטיים, הם מתפתחים על סמך התוצאות של קוד שנוצר על ידי סוכנים, מהדקים אוטומטית אילוצים באזורים שבהם סוכנים טועים לעיתים קרובות ומרפים אילוצים באזורים שבהם הם מצליחים בעקביות.

חלק 8: צ'קליסט מעשי

השתמשו בצ'קליסט זה כדי להעריך את בגרות ה-Harness Engineering של הצוות שלכם:

יסודות (התחילו כאן)

• קובץ ARCHITECTURE.md קיים בשורש ה-repository
• פורמט הקוד הוא אוטומטי (Prettier, Black, gofmt)
• Linting רץ על כל pull request
• Type checking נאכף (TypeScript strict, mypy, וכו')

בינוני

• מבחנים מבניים מאמתים גבולות תלות
• עקרונות זהב מתועדים וניתנים לאכיפה מכנית
• תוכניות משימה נכתבות לפני ביצוע הסוכן
• PRs שנוצרו על ידי סוכנים עוברים את אותו CI כמו PRs אנושיים

מתקדם

• Automated Garbage Collection רץ לפי לו"ז
• סוכנים מרובים יכולים לעבוד במקביל ללא קונפליקטים
• דפוסי כישלון של סוכנים מנוטרים ומשמשים לשיפור ה-harness
• ה-harness עצמו מנוהל בגרסאות ונסקר כמו קוד

מומחה

• סוכנים מייצרים חלקים מה-harness (כללי linter, מבחנים מבניים)
• ציוני איכות מוקצים אוטומטית לכל מודול
• שיפורי harness מונעי-נתונים על סמך שיעורי הצלחה של סוכנים
• הצוות מספק יותר קוד לכל מהנדס בכל שבוע מאשר לפני אימוץ הסוכנים

סיכום

Harness Engineering אינו טרנד חולף. זוהי האבולוציה הטבעית של הנדסת תוכנה בעידן שבו סוכני AI מסוגלים מספיק לכתוב קוד Production אך זקוקים לסביבות מובנות כדי לעשות זאת היטב. הניסוי של OpenAI בן מיליון השורות הוכיח את הקונספט בקנה מידה רחב, והעקרונות שהם ניסחו — ידע מבוסס repository תחילה, עקרונות זהב, ארכיטקטורה שכבתית, automated garbage collection ותוכניות ברות ביצוע — ישימים לצוותים בכל גודל.

הצוותים שישלטו ב-Harness Engineering בשנת 2026 ישלחו קוד מהר יותר, ישמרו על איכות קוד גבוהה יותר ויצמחו בצורה יעילה יותר מאלו שמתייחסים לסוכני AI כאל autocomplete משודרג. הסוכן הוא הסוס. ה-harness הוא מה שהופך אותו למועיל.

מקורות

• Harness Engineering: Leveraging Codex in an Agent-First World — OpenAI
• Unlocking the Codex Harness: How We Built the App Server — OpenAI
• Unrolling the Codex Agent Loop — OpenAI
• OpenAI Introduces Harness Engineering — InfoQ
• Harness Engineering — Martin Fowler
• Skill Issue: Harness Engineering for Coding Agents — HumanLayer
• From Prompt Engineering to Harness Engineering — SoftmaxData
• How to Build an Agent Harness — Study Notes
• Harness Engineering — GTCode
• OpenAI Harness Engineering: Ship 1M Lines of Code — The Neuron
• How OpenAI Built 1M Lines of Code Using Only Agents — TonyLee
• Harness Engineering — The New Discipline — CodeNote