AUTOPILOT

Dari error kritis ke perbaikan yang bisa ditinjau, saat Anda tidur

Autopilot mengubah laporan bug kritis menjadi Pull Request di repositori Anda sendiri. Ia mengusulkan; Anda meninjau, menguji, dan memutuskan versinya.

☰ Di halaman ini

Autopilot mengusulkan. Manusia yang memutuskan. Otonomi bawaan adalah propose: agen mendiagnosis, menulis perbaikan, dan membuka Pull Request. Ia tidak merge, tidak deploy, dan tidak memutuskan versi mana yang rilis. Batas itu keputusan desain, bukan fitur yang belum ada.

Masalah yang diselesaikannya

Error kritis masuk ke issue tracker Anda pukul 02.00. Saat ada yang membacanya, konteksnya sudah dingin: build mana, pelanggan mana, perubahan mana yang menyebabkannya. Satu jam pertama setiap insiden habis untuk menyusun ulang apa yang sebenarnya sudah diketahui mesin.

Autopilot menutup celah itu. Begitu bug kritis mendarat, ia memulai pekerjaan yang akan dimulai seorang developer — membaca laporan, mencari kode yang dicurigai, mengusulkan perbaikan — dan menyerahkan Pull Request yang bisa ditinjau, bukan halaman kosong.

Rantai lengkapnya, ujung ke ujung

Ini jalur nyata, diambil dari cara kami menjalankan IndoHRM terhadap repositori hrm di GitLab.

LangkahSiapaYang terjadi
1Aplikasi AndaError kritis dilaporkan ke issue tracker Oprex — dari error handler, CI, tiket support yang dinaikkan jadi bug, atau seseorang.
2OprexBug dibuat dengan severity, environment, dan versi produk. Bila cocok dengan filter severity dan project yang dikonfigurasi, Autopilot terpicu otomatis. Tidak cocok? Tidak terjadi apa-apa — dan tombol manual selalu bisa dipakai.
3Autopilot (Aidan)Menentukan di mana kodenya hidup — koneksi GitLab yang dikonfigurasi untuk project itu, mis. hrm — lalu membaca berkas sumber yang dicurigai, mendiagnosis akar masalah, dan menyusun perbaikan.
4AutopilotCommit ke cabang baru (autopilot/bug-1284-a91f3c) dan membuka Pull Request yang menjelaskan diagnosis dan apa yang diubah. Run dicatat pada bug — termasuk yang gagal.
5AndaTinjau PR-nya. Terima, ubah, atau tolak. Run yang ditolak dicatat sebagai ditolak — alasannya tidak dibuang.
6AndaJalankan test. Test run di Oprex mencatat apa yang lulus terhadap build mana. Bug tidak tertutup hanya karena mesin merasa yakin.
7AndaPutuskan versinya. Masukkan perbaikan ke rencana rilis, pilih versi, rilis. Catatan rilis menautkan bug, perbaikan, dan versinya.
8OprexRilis yang diterbitkan muncul di changelog dan — untuk produk yang tersambung — sebagai popup di dalam aplikasi bagi pengguna yang belum melihatnya. Cara kerjanya →

Di mana manusia tetap terlibat, dengan sengaja

🛑 Tanpa auto-merge

Otonomi bawaan propose. Otonomi lebih tinggi ada sebagai konfigurasi, tetapi mati — kami lebih suka Anda menyalakannya dengan sadar daripada menemukannya tak sengaja.

🧪 Test adalah gerbang manusia

PR yang lulus bukan berarti perbaikan sudah rilis. Test run adalah tindakan terpisah yang dicatat — catatan itulah yang dibaca auditor nanti.

🏷️ Anda yang memilih versi

Perbaikan masuk rilis mana adalah keputusan produk. Autopilot tidak punya pendapat soal penomoran versi Anda.

Kegagalan dicatat, tidak pernah senyap

Setiap percobaan menjadi catatan run yang menempel pada bug: queued, running, proposed, rejected, atau failed — dengan error yang tersimpan bila gagal. Autopilot tidak pernah melempar error ke jalur permintaan yang membuat bug, jadi agen yang rusak tidak pernah bisa menghalangi bug dilaporkan.

Itu lebih penting daripada kedengarannya. Sistem perbaikan otomatis yang diam-diam tidak melakukan apa pun lebih buruk daripada tidak ada sama sekali, karena Anda berhenti memeriksa.

Yang Anda butuhkan untuk menyalakannya

  • Repositori yang tersambung. GitLab atau GitHub, tertaut ke project Oprex tempat bug-nya berada.
  • AI aktif untuk workspace Anda. Pengaturan → Integrasi. Anda menunjuk penyedia dan kuncinya, jadi inferensi berjalan di penyedia pilihan Anda.
  • Filter yang membuat Anda nyaman. Filter severity dan project menentukan apa yang terpicu otomatis. Mulai dari critical di satu project.

Anda juga bisa memicu run secara manual dari bug mana pun, atau dari agen pengode lewat MCP dengan oprex_trigger_autopilot.

Batas yang jujur

  • Paling andal pada defect dengan reproduksi jelas dan radius ledak kecil — bukan masalah arsitektur.
  • Ia membaca berkas yang dicurigainya. Bug yang penyebabnya tiga layanan jauhnya akan menghasilkan tebakan yang salah, dan PR-nya akan memperlihatkan itu.
  • Auto-merge dan auto-deploy dijaga konfigurasi dan bukan bagian fondasi saat ini. Saat hadir nanti, keduanya juga mati secara bawaan.

Coba di satu project

Sambungkan repositori, aktifkan AI, set filter ke bug kritis, dan lihat Pull Request pertama tiba.

Mulai gratis Tanya soal setup Anda