Czego się nauczysz

Ten przewodnik obejmuje Harness Engineering od podstawowych zasad po praktyczną implementację. Zrozumiesz, czym on jest, dlaczego OpenAI postawiło na niego swój największy wewnętrzny projekt, jakie konkretne wzorce architektoniczne sprawiają, że on działa, oraz jak zastosować te zasady we własnych przepływach pracy agentów AI — niezależnie od tego, czy używasz Codex, Claude Code, OpenCode czy jakiegokolwiek innego systemu agentowego.

Harness Engineering: Kompletny przewodnik po rozwoju agentów AI w 2026 roku

Jeśli 2025 był rokiem, w którym agenci AI udowodnili, że potrafią pisać kod, to 2026 jest rokiem, w którym dowiedzieliśmy się, że agent nie jest najtrudniejszą częścią — najtrudniejszy jest harness (uprząż).

Zespół Codex z OpenAI opublikował przełomowy wpis na blogu w lutym 2026 roku, opisujący, jak zbudowali aplikację produkcyjną zawierającą około 1,000,000 linii kodu, z których zero linii nie zostało napisanych ludzką ręką. Sekretem nie był lepszy model ani mądrzejszy prompt. Był nim system, który zbudowali wokół agenta — harness. Źródło

Ten przewodnik rozkłada na czynniki pierwsze każdą zasadę, wzorzec i praktyczną technikę z tego eksperymentu oraz szerszego ruchu Harness Engineering, który wokół niego powstał.

Część 1: Czym jest Harness Engineering?

Definicja

Harness Engineering to dyscyplina projektowania całego środowiska — rusztowań, pętli zwrotnych, dokumentacji, ograniczeń architektonicznych i artefaktów czytelnych dla maszyn — które pozwala agentom kodującym AI wykonywać niezawodną, wysokiej jakości pracę na dużą skalę przy minimalnej interwencji człowieka.

Termin "harness" (uprząż) pochodzi od rzędu końskiego: wodze, siodło, wędzidło — kompletny zestaw sprzętu do kierowania potężnym, ale nieprzewidywalnym zwierzęciem we właściwym kierunku. Nieokiełznany koń jest niebezpieczny. Koń w uprzęży budował cywilizacje. To samo dotyczy agentów AI. Źródło

Dlaczego pojawił się teraz

Przejście od prompt engineering do Harness Engineering odzwierciedla dojrzewanie krajobrazu rozwoju AI:

Źródło

Kluczowe spostrzeżenie, które doprowadziło do tej transformacji: agenci stali się na tyle zdolni, że wąskie gardło przesunęło się z jakości modelu na jakość środowiska. Najnowocześniejszy model działający w słabo ustrukturyzowanym repozytorium daje gorsze wyniki niż przeciętny model działający w dobrze przygotowanym środowisku typu harness.

Część 2: Eksperyment OpenAI Codex

Skala

W pięciomiesięcznym wewnętrznym eksperymencie inżynierowie OpenAI zbudowali i wydali produkt w wersji beta zawierający około 1,000,000 linii kodu. Repozytorium obejmuje logikę aplikacji, infrastrukturę, narzędzia, dokumentację i wewnętrzne narzędzia programistyczne. Nie było wcześniej żadnego kodu napisanego przez człowieka, na którym system mógłby się oprzeć. Źródło

Zespół

Projekt rozpoczął się od zaledwie 3 inżynierów prowadzących Codex. W ciągu pięciu miesięcy otwarto i scalono około 1,500 pull requests. Gdy zespół powiększył się do 7 inżynierów, przepustowość wzrosła — co było sprzecznym z intuicją wynikiem sugerującym, że to sam harness był głównym mnożnikiem produktywności, a nie indywidualne umiejętności.

OpenAI szacuje, że zbudowali system w około 1/10 czasu, jaki zajęłoby ręczne napisanie kodu. Źródło

Początkowe rusztowanie

Projekt rozpoczął się od Codex CLI generującego początkowe rusztowanie przy użyciu GPT-5, kierowanego przez niewielki zestaw istniejących szablonów:

• Struktura repozytorium i konwencje katalogów
• Konfiguracja CI/CD
• Zasady formatowania kodu i linting
• Konfiguracja menedżera pakietów
• Szablon frameworka aplikacji

Z tego ziarna wyrosło wszystko inne dzięki rozwojowi sterowanemu przez agentów.

Problem piątku

Na początku eksperymentu zespół odkrył krytyczny problem: spędzali każdy piątek — 20% swojego czasu inżynieryjnego — na sprzątaniu tego, co nazwali „AI slop” (bałaganem AI). Obejmowało to niespójne wzorce, powieloną logikę, błędnie nazwane zmienne i dryf architektoniczny.

To się nie skalowało. Rozwiązaniem było zakodowanie ich standardów w samym harness, aby agenci od samego początku produkowali czystszy wynik, oraz zbudowanie zautomatyzowanych systemów czyszczących dla pozostałego dryfu.

Część 3: Pięć głównych zasad

Zasada 1: Wiedza przede wszystkim w repozytorium

Z perspektywy agenta wszystko, do czego nie może uzyskać dostępu w kontekście podczas pracy, skutecznie nie istnieje. Wiedza, która znajduje się w Google Docs, wątkach czatów, wiadomościach Slack lub w głowach ludzi, jest niewidoczna dla systemu.

Oznacza to, że cała wiedza musi istnieć jako lokalne w repozytorium, wersjonowane artefakty:

• Kod — główny artefakt
• Dokumentacja Markdown — decyzje architektoniczne, konwencje, przewodniki wdrożeniowe
• Schematy — kontrakty API, schematy baz danych, definicje typów
• Plany wykonywalne — krok po kroku rozpisane zadania, które agent może realizować
• Konfiguracja — reguły linter, potoki CI, standardy formatowania

Zespół nauczył się, że z czasem musi przesyłać coraz więcej kontekstu do repozytorium. Za każdym razem, gdy agent popełniał błąd z powodu braku kontekstu, rozwiązaniem nie był lepszy prompt — było nim dodanie tego kontekstu do repozytorium. Źródło

Praktyczna implementacja:

# 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

Zasada 2: Złote zasady (Golden Principles)

Złote zasady to narzucone, mechaniczne reguły zakodowane bezpośrednio w repozytorium, które utrzymują bazę kodu czytelną i spójną dla przyszłych przebiegów agentów. Nie są to aspiracyjne wytyczne — to wymuszone ograniczenia.

Przykłady z eksperymentu OpenAI:

1. Preferuj współdzielone pakiety narzędziowe nad ręcznie tworzonymi pomocnikami — centralizuje niezmienniki, dzięki czemu gdy zachowanie musi się zmienić, zmienia się w jednym miejscu.
2. Nie badaj danych w stylu YOLO — waliduj granice lub polegaj na typowanych SDK, aby agenci nie mogli przypadkowo budować na zgadywanych kształtach danych.
3. Jeden koncept, jeden plik — każdy plik powinien reprezentować pojedynczy koncept, co ułatwia agentom znalezienie i zmodyfikowanie właściwego miejsca.
4. Jawne nad dorozumianym — unikaj magicznych zachowań, do których zrozumienia agent potrzebowałby wiedzy plemiennej.

Źródło

Te zasady to nie tylko dokumentacja. Są one wymuszane przez:

• Reguły linter — niestandardowe lintery (same wygenerowane przez Codex), które flagują naruszenia.
• Testy strukturalne — testy sprawdzające zgodność z architekturą.
• Bramki CI — pull requests naruszające złote zasady są automatycznie odrzucane.

Zasada 3: Architektura warstwowa z mechanicznym egzekwowaniem

Każda domena biznesowa w projekcie OpenAI jest podzielona na stały zestaw warstw z rygorystycznie sprawdzanymi kierunkami zależności:

Types → Config → Repo → Service → Runtime → UI

Zależności przepływają tylko w jednym kierunku. Komponent UI może zależeć od Runtime i Service, ale Service nigdy nie może importować z UI. Repo może zależeć od Config i Types, ale nigdy od Service. Źródło

Ograniczenia te są wymuszane mechanicznie:

// 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([]);
  });
});

Testy strukturalne sprawdzają zgodność i zapobiegają naruszeniom modularnego warstwowania. To nie jest sugestia — to jest wymuszane przez CI. Każdy pull request, niezależnie od tego, czy został utworzony przez człowieka, czy agenta, musi przejść te testy.

Zasada 4: Zautomatyzowane odśmiecanie (Garbage Collection)

Nawet przy złotych zasadach i egzekwowaniu strukturalnym, kod generowany przez agentów dryfuje w czasie. Zespół OpenAI rozwiązał to, wdrażając zautomatyzowane odśmiecanie (Garbage Collection) — cykliczne zadania w tle, które:

1. Skanują w poszukiwaniu odchyleń od złotych zasad w całej bazie kodu.
2. Aktualizują oceny jakości dla każdego modułu na podstawie wyników zgodności.
3. Otwierają ukierunkowane pull requests refaktoryzacyjne, które naprawiają określone kategorie dryfu.

Zastąpiło to ręczne „piątkowe sprzątanie” systemem, który działa w sposób ciągły. Sam proces odśmiecania jest napędzany przez agentów Codex, tworząc samonaprawiającą się pętlę. Źródło

# .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

Zasada 5: Plany wykonywalne

Zanim agenci napiszą kod, piszą plany. Te plany nie są nieformalnymi notatkami — są ustrukturyzowanymi, wykonywalnymi dokumentami, które określają:

• Cel: Co zadanie ma osiągnąć.
• Pliki do modyfikacji: Jawna lista plików, które agent dotknie.
• Zależności: Inne zadania lub moduły, od których ta praca zależy.
• Kryteria akceptacji: Jak zweryfikować, czy praca jest ukończona.
• Ograniczenia: Zasady architektoniczne, które nie mogą zostać naruszone.

# 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

Plany żyją w repozytorium jako pliki markdown, są wersjonowane i mogą być przeglądane przed wykonaniem — co daje ludziom punkt kontrolny między intencją a implementacją.

Część 4: Pętla agenta Codex

Zrozumienie sposobu działania pętli agenta Codex w ramach harness jest niezbędne do skutecznego uprawiania Harness Engineering.

Architektura pętli

OpenAI opublikowało szczegółowy opis pętli agenta Codex w towarzyszącym wpisie na blogu „Unrolling the Codex agent loop”. Źródło Pętla przebiega według następującego cyklu:

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

Każda iteracja:

1. Read Context: Agent odczytuje odpowiednie pliki, dokumentację, schematy i plan zadań z repozytorium.
2. Plan: Na podstawie kontekstu agent decyduje, jakie zmiany wprowadzić.
3. Execute: Agent pisze lub modyfikuje kod.
4. Validate: Harness uruchamia testy, lintery i sprawdzenia strukturalne wobec zmian.
5. Commit or Retry: Jeśli walidacja przejdzie pomyślnie, agent zatwierdza zmiany (commit). Jeśli nie, agent odczytuje komunikat o błędzie i próbuje ponownie.

Rolą harness jest sprawienie, aby kroki 1 i 4 były jak najbardziej bogate w informacje. Im więcej kontekstu odczyta agent, tym lepszy będzie jego plan. Im bardziej szczegółowa informacja zwrotna z walidacji, tym szybciej zbiegnie się on do działającego rozwiązania.

App Server Harness

W swoim poście „Unlocking the Codex harness: how we built the App Server”, OpenAI opisuje konkretną infrastrukturę zasilającą pętlę agenta. Źródło App Server zapewnia:

• Piaskownice (Sandboxed execution environments) dla każdego zadania agenta.
• Skonfigurowany dostęp do narzędzi (system plików, terminal, przeglądarka).
• Automatyczne wstrzykiwanie kontekstu z artefaktów repozytorium.
• Strumieniową informację zwrotną z walidacji, aby agenci mogli widzieć niepowodzenia testów w czasie rzeczywistym.

Część 5: Zastosowanie Harness Engineering w Twoim zespole

Jak zacząć: Minimalny opłacalny Harness (MVH)

Nie musisz replikować całej infrastruktury OpenAI, aby czerpać korzyści z Harness Engineering. Zacznij od tych fundamentalnych elementów:

Krok 1: Utwórz ARCHITECTURE.md

Udokumentuj zasady architektoniczne swojego projektu w formacie czytelnym dla maszyn w katalogu głównym repozytorium. Uwzględnij:

• Granice modułów i dozwolone zależności.
• Konwencje nazewnictwa.
• Zasady organizacji plików.
• Wymagania dotyczące testów.

Ten jeden plik radykalnie poprawia jakość wyników agenta, ponieważ agenci czytają go przed wprowadzeniem zmian.

Krok 2: Dodaj testy strukturalne

Napisz testy, które walidują Twoje zasady architektoniczne. Te testy nie sprawdzają logiki biznesowej — sprawdzają, czy kod jest poprawnie zorganizowany:

// 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);
  }
});

Krok 3: Skonfiguruj walidację CI

Upewnij się, że Twój potok CI uruchamia testy strukturalne, lintery i sprawdzanie typów przy każdym pull request — w tym tych utworzonych przez agentów. Agent powinien widzieć te same wyniki walidacji, które widziałby ludzki programista.

Krok 4: Pisz plany zadań przed wykonaniem przez agenta

Zanim poprosisz agenta o zaimplementowanie funkcji, napisz ustrukturyzowany dokument planu określający pliki do modyfikacji, ograniczenia do przestrzegania i kryteria akceptacji. Przechowuj te plany w swoim repozytorium.

Krok 5: Skonfiguruj automatyczne sprzątanie

Wdróż tygodniowe lub nocne zadanie CI, które skanuje bazę kodu pod kątem odchyleń od udokumentowanych standardów i tworzy ukierunkowane pull requests refaktoryzacyjne.

Wybór systemu agentowego

Zasady Harness Engineering mają zastosowanie niezależnie od tego, którego agenta używasz:

Harness żyje w Twoim repozytorium, a nie w Twoim agencie. Oznacza to, że możesz zmieniać agentów bez utraty inwestycji w harness.

Skalowanie od jednego agenta do wielu

Eksperyment OpenAI wykazał, że Harness Engineering umożliwia równoległe wykonywanie zadań przez agentów. Ponieważ harness wymusza granice architektoniczne, wielu agentów może pracować nad różnymi częściami bazy kodu jednocześnie bez tworzenia konfliktów.

Kluczowe wymagania dla równoległego wykonywania agentów:

1. Jasna własność modułów — każdy agent pracuje w obrębie zdefiniowanej granicy.
2. Typowane interfejsy między modułami — agenci mogą kodować pod interfejsy bez znajomości szczegółów implementacji.
3. Zapobieganie konfliktom scalania — zadania są zakresowane tak, aby zminimalizować nakładanie się plików.
4. Scentralizowana walidacja — wszyscy agenci przesyłają prace do tego samego potoku CI.

Część 6: Typowe pułapki i anty-wzorce

Anty-wzorzec 1: Traktowanie agenta jako harness

Agent nie jest harness. Harness to środowisko, w którym działa agent. Proszenie mądrzejszego modelu o skompensowanie słabo ustrukturyzowanego repozytorium to błędne podejście. Napraw środowisko, a nie prompt.

Anty-wzorzec 2: Dokumentacja w niewłaściwym miejscu

Jeśli Twoje decyzje architektoniczne żyją w Confluence, Notion lub Google Docs, agenci ich nie widzą. Rozwiązanie jest proste, ale wymaga dyscypliny: przenieś całą dokumentację istotną dla rozwoju do repozytorium.

Anty-wzorzec 3: Ręczne sprzątanie zamiast automatycznego egzekwowania

Jeśli spędzasz znaczną ilość czasu na sprzątaniu kodu wygenerowanego przez agenta, potrzebujesz lepszego egzekwowania, a nie więcej sesji sprzątania. Każde powtarzające się zadanie sprzątania powinno stać się regułą linter, testem strukturalnym lub automatycznym zadaniem refaktoryzacyjnym.

Anty-wzorzec 4: Nadmierne ograniczanie

Harness, który jest zbyt sztywny, uniemożliwia agentom znajdowanie kreatywnych rozwiązań. Celem jest ograniczenie architektury, a nie implementacji. Powiedz agentom, które moduły mogą modyfikować i jakie zależności są dozwolone, ale pozwól im zdecydować, jak zaimplementować logikę w tych granicach.

Anty-wzorzec 5: Ignorowanie informacji zwrotnej od agenta

Gdy agent wielokrotnie zawodzi przy określonych zadaniach, niepowodzenie zwykle wskazuje na lukę w harness, a nie na ograniczenie agenta. Śledź wzorce niepowodzeń i używaj ich do poprawy dokumentacji, testów strukturalnych lub ograniczeń architektonicznych.

Część 7: Przyszłość Harness Engineering

Perspektywa Martina Fowlera

Martin Fowler opublikował analizę Harness Engineering na swoim blogu, zauważając, że reprezentuje on fundamentalną zmianę w sposobie działania zespołów oprogramowania. Dyscyplina ta czerpie z dekad najlepszych praktyk inżynierii oprogramowania — continuous integration, architecture decision records, dependency injection — ale nadaje im nowy cel w świecie sterowanym przez agentów. Źródło

Framework HumanLayer

Zespół HumanLayer opublikował analizę nazywającą Harness Engineering „problemem umiejętności” (skill issue) — argumentując, że zdolność do projektowania skutecznych harnessów stanie się głównym wyróżnikiem między zespołami inżynieryjnymi o wysokiej wydajności a tymi borykającymi się z trudnościami. Źródło

Co to oznacza dla programistów

Harness Engineering nie zastępuje umiejętności programisty — przekierowuje je. Zamiast pisać kod, starsi inżynierowie projektują systemy, które pozwalają agentom pisać kod dobrze. Umiejętności, które mają znaczenie, przesuwają się z implementacji na architekturę, z kodowania na projektowanie systemów, z pisania testów na projektowanie frameworków testowych.

Dla zespołów budujących aplikacje, platformy takie jak ZBuild już włączają zasady Harness Engineering do swoich przepływów pracy buildera aplikacji. Zamiast wymagać od programistów projektowania własnych harnessów od zera, ZBuild dostarcza wstępnie skonfigurowane wzorce architektoniczne, zarządzanie zależnościami i systemy walidacji, które prowadzą agentów AI ku wysokiej jakości wynikom — pozwalając programistom skupić się na decyzjach produktowych, a nie na infrastrukturze.

Trzy horyzonty

Patrząc w przyszłość, Harness Engineering prawdopodobnie będzie ewoluować w trzech fazach:

1. Krótkoterminowa (2026): Zespoły przyjmują dokumentację typu repository-first, testy strukturalne i złote zasady. Rozwój wspomagany przez agentów staje się standardową praktyką w dobrze przygotowanych projektach.

2. Średnioterminowa (2027): Samo generowanie harnessów staje się sterowane przez agentów. Agenci analizują istniejące bazy kodu i proponują konfiguracje harness — reguły linter, testy strukturalne, granice zależności — na podstawie zaobserwowanych wzorców.

3. Długoterminowa (2028+): Harnessy stają się adaptacyjne. Zamiast statycznych reguł, ewoluują one na podstawie wyników kodu generowanego przez agentów, automatycznie zaostrzając ograniczenia w obszarach, w których agenci często popełniają błędy, i poluzowując je tam, gdzie konsekwentnie odnoszą sukcesy.

Część 8: Praktyczna lista kontrolna

Użyj tej listy kontrolnej, aby ocenić dojrzałość Harness Engineering w swoim zespole:

Fundamenty (Zacznij tutaj)

• ARCHITECTURE.md istnieje w katalogu głównym repozytorium
• Formatowanie kodu jest zautomatyzowane (Prettier, Black, gofmt)
• Linting uruchamia się przy każdym pull request
• Sprawdzanie typów jest wymuszane (TypeScript strict, mypy, itp.)

Średniozaawansowany

• Testy strukturalne walidują granice zależności
• Złote zasady są udokumentowane i możliwe do wymuszenia przez maszyny
• Plany zadań są pisane przed wykonaniem przez agenta
• PR-y generowane przez agentów przechodzą przez to samo CI, co PR-y ludzkie

Zaawansowany

• Zautomatyzowane odśmiecanie (Garbage Collection) działa zgodnie z harmonogramem
• Wielu agentów może pracować równolegle bez konfliktów
• Wzorce niepowodzeń agentów są śledzone i używane do ulepszania harness
• Sam harness jest wersjonowany i przeglądany jak kod

Ekspert

• Agenci generują części harnessu (reguły linter, testy strukturalne)
• Oceny jakości są automatycznie przypisywane do każdego modułu
• Ulepszenia harnessu są oparte na danych dotyczących wskaźników sukcesu agentów
• Zespół dostarcza więcej kodu na inżyniera tygodniowo niż przed wdrożeniem agentów

Podsumowanie

Harness Engineering nie jest chwilową modą. To naturalna ewolucja inżynierii oprogramowania w erze, w której agenci AI są wystarczająco zdolni, by pisać kod produkcyjny, ale potrzebują ustrukturyzowanych środowisk, by robić to dobrze. Milionliniowy eksperyment OpenAI udowodnił tę koncepcję na dużą skalę, a sformułowane przez nich zasady — wiedza repository-first, złote zasady, architektura warstwowa, zautomatyzowane odśmiecanie i plany wykonywalne — mają zastosowanie w zespołach każdej wielkości.

Zespoły, które opanują Harness Engineering w 2026 roku, będą dostarczać kod szybciej, utrzymywać wyższą jakość kodu i skalować się skuteczniej niż te, które traktują agentów AI jako ulepszone autouzupełnianie. Agent jest koniem. Harness jest tym, co czyni go użytecznym.

Źródła

• 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