ExecCritic 2026: Arsitektur Test-Verify-Revise Scaffold, Fail-Closed Harness Qualification, dan Role-Specific Reinforcement Learning pada Autonomous Coding Agents

Dalam lanskap pengembangan software engineering berbasis AI, mengeksekusi tes di dalam sandbox adalah pilar utama bagi agen otonom untuk memvalidasi perbaikan kode. Namun, riset frontier arXiv:2609.09133 (Leitian Tao et al., Microsoft Research & UW-Madison, 8 September 2026) membongkar sebuah paradoks kritis: ketika satu agen yang sama diminta menulis kode perbaikan sekaligus menulis unit test verifikasinya, agen tersebut mengalami halusinasi simetris (symmetric hallucinations) dan rasa percaya diri palsu (false confidence).

1. Anatomi Kegagalan: Jebakan Halusinasi Simetris & Nilai Negatif Test Feedback

Pada platform open coding agents konvensional (seperti SWE-agent, OpenHands, atau agen berbasis CLI umum), agen beroperasi dalam trajectory monolitik: membaca deskripsi GitHub issue, mencari file, merekayasa fungsi sumber, lalu menulis script tes singkat untuk mengecek apakah kodenya berjalan sebelum melakukan git commit dan submission.

Masalah fatal muncul karena evaluator resmi (official test suite) sengaja disembunyikan di balik black-box test harness. Agen harus merumuskan ekspektasi pengujiannya sendiri. Perhatikan skenario bug nyata pada Django (#14765) yang dianalisis dalam paper:

Ketika satu model yang sama merancang hipotesis perbaikan dan hipotesis pengujian dalam memori konteks yang sama, blind spot kognitif yang memicu kesalahan pada patch juga secara simetris membentuk kekurangan pada unit test. Akibatnya, tes yang salah mengonfirmasi patch yang salah, memupuk false confidence yang menghentikan proses iterasi debugging secara prematur.

Secara empiris, fenomena ini menimbulkan efek yang sangat mencengangkan: menambahkan unit test berkualitas rendah justru lebih buruk daripada tidak melakukan tes sama sekali. Pada eksperimen SWE-bench Verified menggunakan backbone Qwen-3.5-35B-A3B:

2. Arsitektur Decoupled Test-Verify-Revise & Fail-Closed Harness

ExecCritic memutus rantai halusinasi simetris dengan memisahkan proses menjadi dua tahapan peran independen yang dihubungkan oleh Fail-Closed Qualification Harness:

Fail-Closed Base Gate: Formula Kualifikasi Bersih

Agar sebuah paket tes diizinkan masuk ke fase Repair, harness menerapkan gerbang fail-closed yang ketat. Misalkan $R_B$ adalah repository Base awal (yang memiliki bug), dan $B_x(b) \in \{0, 1\}$ adalah indikator eksekusi paket tes $b$ pada $R_B$:

Jika dalam batas kuota pencarian Test Agent tidak menghasilkan paket dengan $B_x(b) = 1$, instance langsung ditandai sebagai Base-gate failure. Dalam kondisi ini, sistem secara cerdas tidak meluncurkan iterasi Repair, melainkan langsung menggunakan patch awal $p_0$ (Round 0) untuk menghindari polusi feedback yang merusak performa.

3. Role-Specific Reinforcement Learning: Learn to Test & Test to Improve

Kedua agen dilatih menggunakan backbone model yang sama, yaitu Qwen-3.5-35B-A3B, namun dengan target reward dan dinamika optimasi Group Relative Policy Optimization (GRPO) yang dipisahkan secara terisolasi.

Fase 1: Learn to Test (ϕ)

Tujuan dari Test Agent adalah menghasilkan unit test yang memiliki daya diskriminasi perilaku (behavioral discrimination): tes harus menolak implementasi yang mengandung bug ($B_x(b) = 1$) dan menerima implementasi yang benar secara ground-truth ($G_x(b) = 1$, diuji pada Gold repository $R_G$).

Tingkat keberhasilan Base-to-Gold diformulasikan sebagai:

Penting dicatat: repositori Gold $R_G$ hanya digunakan dalam lingkungan simulasi tertutup saat komputasi reward RL; model tidak pernah melihat patch Gold maupun outcome Gold dalam state konversinya. Selain itu, reward Test Agent diperkaya dengan akurasi terbobot seimbang (balanced accuracy) terhadap sekumpulan kandidat patch yang berlabel benar dan salah.

Fase 2: Test to Improve (θ)

Repair Agent dilatih melalui interaksi multi-round (hingga 5 putaran revisi) terhadap unit test yang telah dibekukan. Formulasi reward Repair Agent mengintegrasikan:

• Direct-Solve Bonus: Memberikan reward lebih tinggi (+1.5) jika patch $p_0$ langsung berhasil menyelesaikan masalah di Round 0 tanpa memerlukan revisi, guna mencegah ketergantungan pasif pada feedback.
• Revision Resolution (+1.0): Diberikan jika patch revisi $p_t$ berhasil meloloskan seluruh rangkaian pengujian resmi setelah mendapatkan feedback error dari tes.
• Zero Tolerance on Test Tampering: Jika agen mencoba memodifikasi file tes untuk meloloskan assert secara curang, episode langsung dihentikan dengan penalti reward 0.

4. Analisis Benchmark Empiris & Temuan Kunci SWE-bench Verified

Evaluasi komprehensif pada SWE-bench Verified mengungkap beberapa wawasan fundamental mengenai dinamika pembelajaran agen koding:

Wawasan Eksperimental Krusial:

• Dampak CoT Visibility pada Trajectory Guru: Pelatihan SFT menggunakan demonstrasi guru dengan Chain-of-Thought (CoT) yang terlihat (DeepSeek-V4-Flash) menghasilkan lompatan performa pasca-RL yang dramatis (62.2%) dibandingkan jika CoT disembunyikan (36.2%). Memahami *mengapa* guru memilih file uji tertentu menentukan kemampuan generalisasi kebijakan RL murid.
• Generalisasi Cross-Language Tanpa Pelatihan Lanjutan: Meskipun post-training Test Agent dilakukan 100% pada repository Python, model menunjukkan transferabilitas tinggi pada bahasa lain: mampu menggenerasikan unit test berbasis Cargo/Rust dan Jest/TypeScript dengan clean Base failure rate mencapai 54.1%.

5. Implementasi Type-Safe: ExecCritic Harness & Gate Controller

Berikut adalah arsitektur produksi kernel kontrol ExecCritic yang mengisolasi Base Gate dan memastikan immutabilitas rangkaian uji sebelum diserahkan ke agen perbaikan kode:

// ExecCritic Decoupled Test-Verify-Revise Scaffold & Fail-Closed Gate
// Berdasarkan Prinsip Arsitektur Riset arXiv:2609.09133 (September 2026)
// Pemisahan Ketat: Test Agent Role vs Repair Agent Role + Immutable Test Suite

export interface IssueContext {
  issueId: string;
  repo: string;
  baseCommit: string;
  problemStatement: string;
}

export interface TestBundleSubmission {
  testPatchDiff: string;      // Perubahan diff hanya pada test directory
  testCommand: string;        // Perintah eksekusi deterministik (cth: pytest tests/test_state.py)
  behaviorContract: {        // Kontrak perilaku JSON (κb)
    targetClassOrModule: string;
    expectedFailureType: string;
    assertionSemantics: string;
  };
}

export interface ExecutionTrace {
  returnCode: number;
  stdout: string;
  stderr: string;
  durationMs: number;
  failedTestNodes: string[];
  passedTestNodes: string[];
}

export interface RepairPatchSubmission {
  round: number;
  repairPatchDiff: string;    // Perubahan kode hanya pada modul sumber (src/)
  commitMessage: string;
}

export type BaseGateStatus = 'CLEAN_BASE_FAIL' | 'BASE_PASS_DISQUALIFIED' | 'SYNTAX_OR_CRASH_DISQUALIFIED';

/**
 * 1. Base Gate: Fail-Closed Test Qualification Harness
 * Mengharuskan test bundle mengalami kegagalan bersih (clean failure) pada Base repository.
 * B_x(b) = 1 jika dan hanya jika test gagal karena assertion/ekspektasi issue, bukan syntax error.
 */
export class FailClosedBaseGate {
  public qualifyTestBundle(
    bundle: TestBundleSubmission,
    baseTrace: ExecutionTrace
  ): { qualified: boolean; status: BaseGateStatus; reason: string } {
    // Larang perubahan di luar folder pengetesan
    if (this.containsSourceCodeModification(bundle.testPatchDiff)) {
      return {
        qualified: false,
        status: 'SYNTAX_OR_CRASH_DISQUALIFIED',
        reason: 'Violation: Test patch must not touch production source files.',
      };
    }

    // Jika pada Base repo test justru lolos (PASS), maka test tidak menangkap bug isu
    if (baseTrace.returnCode === 0 && baseTrace.failedTestNodes.length === 0) {
      return {
        qualified: false,
        status: 'BASE_PASS_DISQUALIFIED',
        reason: 'Disqualified: Test suite passed on unpatched Base checkout. B_x(b) = 0.',
      };
    }

    // Periksa apakah kegagalan adalah kegagalan asersi yang bersih
    const isCleanAssertionFailure = baseTrace.failedTestNodes.length > 0 &&
      !baseTrace.stderr.includes('SyntaxError') &&
      !baseTrace.stderr.includes('ImportError') &&
      !baseTrace.stderr.includes('IndentationError');

    if (!isCleanAssertionFailure) {
      return {
        qualified: false,
        status: 'SYNTAX_OR_CRASH_DISQUALIFIED',
        reason: 'Disqualified: Failure caused by runtime environment error or syntax crash, not behavioral assertion.',
      };
    }

    return {
      qualified: true,
      status: 'CLEAN_BASE_FAIL',
      reason: 'Qualified: Test bundle produced clean failure on Base repository. B_x(b) = 1.',
    };
  }

  private containsSourceCodeModification(diff: string): boolean {
    const lines = diff.split('\n');
    for (const line of lines) {
      if (line.startsWith('--- a/') || line.startsWith('+++ b/')) {
        const filePath = line.substring(6);
        if (!filePath.startsWith('tests/') && !filePath.includes('test_') && !filePath.endsWith('_test.py')) {
          return true;
        }
      }
    }
    return false;
  }
}

/**
 * 2. Immutable Test-Verify-Revise Loop Controller
 * Mengunci test bundle secara mutlak agar Repair Agent tidak dapat melemahkan asersi.
 */
export class DecoupledRepairOrchestrator {
  private frozenTestBundle: TestBundleSubmission;
  private maxRevisionRounds: number;

  constructor(qualifiedBundle: TestBundleSubmission, maxRounds = 5) {
    // Deep freeze agar bundle tidak dapat diubah (immutable)
    this.frozenTestBundle = Object.freeze({ ...qualifiedBundle });
    this.maxRevisionRounds = maxRounds;
  }

  public evaluateRepairPatch(
    patch: RepairPatchSubmission,
    executeInSandbox: (repoPatch: string, testPatch: string, cmd: string) => Promise
  ): Promise<{ resolved: boolean; trace: ExecutionTrace; feedbackForRevision: string }> {
    // Verifikasi bahwa repair patch sama sekali tidak menyentuh test files
    if (this.modifiesTestFiles(patch.repairPatchDiff)) {
      throw new Error('Security Breach: Repair agent attempted to mutate the immutable test suite.');
    }

    return executeInSandbox(
      patch.repairPatchDiff,
      this.frozenTestBundle.testPatchDiff,
      this.frozenTestBundle.testCommand
    ).then((trace) => {
      const allPassed = trace.returnCode === 0 && trace.failedTestNodes.length === 0;
      let feedback = '';

      if (allPassed) {
        feedback = 'SUCCESS: All qualification test nodes passed without errors.';
      } else {
        feedback = `FAILURE in Round ${patch.round}: ${trace.failedTestNodes.length} test node(s) failed.\nTrace snippet: ${trace.stdout.slice(-500)}`;
      }

      return {
        resolved: allPassed,
        trace,
        feedbackForRevision: feedback,
      };
    });
  }

  private modifiesTestFiles(diff: string): boolean {
    return diff.includes('+++ b/tests/') || diff.includes('test_');
  }
}

6. Panduan Praktis untuk Arsitektur AI Coding Agents di Production

Bagi tim engineering yang membangun atau mengoperasikan autonomous coding agents di lingkungan enterprise, temuan ExecCritic memberikan panduan desain yang dapat langsung diterapkan:

1. Hentikan Trajectory Tunggal Penulisan Kode dan Tes: Jangan pernah membiarkan agen yang sama menghasilkan patch lalu langsung menulis unit test verifikasinya di dalam satu sesi memori konteks yang sama. Gunakan agen penilai (critic) yang terisolasi.
2. Terapkan Base Gate yang Fail-Closed: Unit test lokal hanya berharga jika terbukti gagal secara bersih pada kode yang belum diperbaiki ($B_x(b) = 1$). Jika unit test lolos pada kode yang masih rusak, buang tes tersebut dan jangan gunakan untuk memandu proses perbaikan.
3. Bekukan Rangkaian Tes (Test Immutability): Kunci direktori tes di tingkat container/sandbox selama agen perbaikan bekerja. Agen perbaikan dilarang keras memodifikasi kode asersi agar tidak terjadi kompromi mutu.