Sekarang jam 4 sore, dan sejak makan siang ada tiga agen coding yang mengerjakan repository yang sama. Satu memperbaiki pembulatan total keranjang belanja, satu menambahkan kode diskon, satu lagi menulis test. Ketiganya bilang "done". Sebelum apa pun menyentuh main, kamu ingin tahu dua hal: apakah ada dua agen yang menulis ulang fungsi yang sama, dan apakah ketiga perubahan itu masih lolos test kalau digabung?
Tiga layar untuk satu codebase
osFoundry adalah aplikasi desktop yang menyatukan chat, agen, file, dan tools dalam satu jendela, dan untuk urusan kode ada tiga layar yang saling terhubung. Code adalah tempat kamu membagikan tugas ke beberapa agen sekaligus: setiap run punya branch Git dan folder kerjanya sendiri (worktree), lalu kamu me-review, menguji, dan melihat pratinjau merge sebelum memutuskan apa pun. Tidak ada yang ter-merge dengan sendirinya. IDE adalah editor kode untuk folder lokal, lengkap dengan explorer, source control, terminal, panel Problems dan Tests, serta kolom asisten yang bisa melihat file yang sedang kamu buka. Wiki membaca repository di komputermu dan menulis halaman dokumentasi yang mengutip path:line, lalu menandai halaman itu ketika kode yang dikutip berubah. Code dan Wiki ada sebagai tab di samping Maestro, Model chat, Multi chat, dan Research; IDE punya item sendiri di sidebar. Kalau kamu terbiasa dengan VS Code dan panel Git-nya, IDE ini akan terasa familier. Code lebih mirip inbox pull request, bedanya penulisnya adalah agen-agenmu dan branch-nya tidak pernah keluar dari laptopmu.
Melihat tab Code
Yang kamu lihat di layar ini (run-nya adalah data contoh):
- Banner di bagian atas kolom. "3 agents finished · they disagree on 1 file" menyebutkan nama file-nya, di sini
src/cart.js, bahkan sebelum kamu membuka satu diff pun. Tombol Review together memulai review bersama. - Kolom run. Run dikelompokkan berdasarkan apa yang mereka butuhkan darimu: Ready to review, Needs attention, dan History yang dilipat. Setiap baris menampilkan tugas, jumlah baris yang ditambah dan dihapus, berapa lama agen bekerja, dan branch-nya.
- Percakapan di tengah. Klik sebuah run dan kamu bisa membaca apa yang diminta dari agen dan apa yang ia katakan selama bekerja.
- Panel kanan. Tab Changes, Files, Commits, Review, dan PR menampilkan diff asli setiap run, dimulai dari pekerjaan yang belum di-commit, lalu apa yang sudah di-commit ke branch-nya.
- Merge station di kanan bawah. Pilih run yang sudah selesai, dan di sinilah kamu menguji serta melihat pratinjau saat semuanya di-merge bersama.
Contoh kasus: tech lead dengan tiga agen di satu repo
Dana memimpin tim web kecil dan membagi sprint checkout ke tiga run agen: memperbaiki pembulatan total keranjang, menambahkan kode diskon di checkout, dan menulis test untuk formatter harga. Setiap run dimulai dari New run dengan tugas satu baris dan agen yang dipilih khusus untuknya, jadi masing-masing punya branch dan folder sendiri, dan tidak ada yang bisa mengganggu file milik yang lain selama bekerja.
Saat banner bilang mereka berbeda pendapat, ia mencentang ketiga run dan mengklik Review together. Panel Merge menampilkan "3 runs · conflicts not checked yet · 3 not yet tested", sebuah "kami belum tahu" yang jujur, bukan lampu hijau. Di bawahnya, src/cart.js ditandai contested, dan hunk dari setiap branch ditampilkan berdampingan: perbaikan pembulatan dan kode diskon sama-sama menulis ulang total().
Berikutnya ia menekan test di setiap run. Test berjalan di dalam worktree milik run itu sendiri, jadi checkout miliknya tidak pernah tersentuh. Secara default berlaku "Tests must pass before a branch can merge", dan aturan itu bisa diubah di Settings. Ketiganya lolos, tapi lolos sendiri-sendiri tidak sama dengan lolos bersama, jadi ia menekan Preview combined merge. Aplikasi lebih dulu me-merge branch-branch itu di salinan sementara lalu melaporkan hasilnya: dua ter-merge dengan bersih, satu konflik.
Ia me-merge dua branch yang bersih ke branch-nya saat ini. Baru pada saat itulah branch-nya berubah. Branch kode diskon tetap ada, sehingga agen bisa mengulang perubahannya di atas perbaikan pembulatan. Seandainya ia ingin mengambil bagian terbaik dari tiap percobaan alih-alih branch utuh, Combine into a branch memungkinkannya mencentang hunk satu per satu dan membuat branch baru dari situ.
Satu detail lagi yang penting di hari-hari panjang: kalau aplikasi berhenti saat sebuah run sedang bekerja, run itu kembali dengan status Interrupted, bukan "running", disertai catatan bahwa branch-nya tetap disimpan.
Contoh kasus: developer solo yang refactoring dengan asisten
Kenji mengurus front end sebuah toko online seorang diri. Pagi ini ia perlu mengubah formatPrice, dan ia tidak yakin siapa saja yang memanggilnya. Ia membuka folder proyek di IDE dari sidebar. Tata letak editornya seperti biasa: Explorer dan Source Control di kiri, tab di tengah, Terminal, Output, Problems, dan Tests di bawah, dan Assistant di kanan, tempat ia bisa memulai chat yang disinkronkan atau chat lokal yang tetap di perangkat.
Ia klik kanan pada formatPrice dan memilih Show Code Graph. Panel ini menampilkan Callers dan Calls. Titik penuh berarti pemanggilan itu dibaca langsung dari kodenya; titik kosong berarti hasil inferensi, jadi yang itu sebaiknya dicek manual. Impact of change menelusuri pemanggil dari pemanggil dan, dalam contoh ini, menampilkan "15 symbols · 14 files · 3 tests". Mengklik sebuah baris akan melompat ke baris tersebut, dan Send to chat mengirim seluruh graf ke asisten sebagai konteks.
Belakangan, asisten mengedit sebuah file konfigurasi untuknya. Di Source Control file itu tampil sebagai modified, dan saat dibuka, ikon robot kecil dan status line menunjukkan bahwa file itu terakhir ditulis oleh AI, lengkap dengan model dan alasan yang diberikannya. Review membuka diff berdampingan terhadap salinan yang disimpan tepat sebelum penulisan itu, jadi ia hanya melihat perubahan tersebut. Di sini terlihat timeout dipangkas dari 30 detik menjadi 3, tepat di bawah komentar yang bilang upload besar butuh 20 detik atau lebih. Ia menangkapnya sebelum commit.
Kalau ada agen yang menulis ke sebuah file sementara ia masih punya editan yang belum disimpan di file itu, editor memberi tahu bahwa file berubah di disk selama ia mengedit dan menawarkan Keep mine atau Use the disk version, bukannya diam-diam memilih salah satunya.
Contoh kasus: support engineer yang perlu memahami kode, bukan mengubahnya
Priya bekerja di customer support dan sering ditanya bagaimana perilaku suatu bagian produk. Ia bisa membaca kode, tapi tidak mau grep ke sana kemari di repository yang bukan miliknya. Di Wiki ia memakai Open a folder (atau Clone a public repository dengan URL https atau git@), lalu aplikasi membaca struktur proyek di komputernya.
Sebelum menulis apa pun ke dalam proyek, Wiki bertanya dulu. Sebuah dialog menyebutkan folder persis yang akan dibuatnya di dalam repo, dan kalau ia mengklik Not now, tidak ada yang ditulis. Setelah ia setuju, ia memakai Generate pages atau Write a page untuk satu topik. Pengaturan menentukan seberapa banyak source code yang dipakai untuk menulis setiap halaman (Depth: Quick, Standard, atau Deep) dan berapa banyak klaim yang diperiksa (Verification: Off, Sample, atau Full, di mana Full kira-kira menggandakan biayanya). Biaya ditampilkan sebelum halaman dibuat.
Setiap halaman mengutip path:line, dan mengklik kutipan akan membuka baris itu di IDE. Sebulan kemudian, sebuah halaman di kolom ditandai karena "a file this page cites has changed since it was written", yang memberi tahu dia untuk membuat ulang halaman itu sebelum memercayainya. Untuk pertanyaan cepat sekali jalan, ia memakai chat di samping halaman, yang jawabannya juga mengutip path:line dari proyek itu, dan di situ ia juga bisa meminta halaman baru dengan bahasa biasa, misalnya "write a page about the retry policy". Halaman-halamannya sendiri berupa file markdown di dalam repository, jadi tim bisa me-review-nya di pull request yang sama dengan kodenya.
Titik serah terima antara Code, IDE, dan Wiki
Ketiga layar ini saling mengoper pekerjaan, juga ke bagian lain aplikasi. Kutipan di Wiki membuka IDE tepat di baris yang dikutip, dan IDE punya tombol Wiki for this folder untuk arah sebaliknya. Assistant di IDE dan chat di samping halaman Wiki dibangun di atas Maestro, asisten yang sama yang kamu pakai di bagian lain osFoundry, jadi bertanya di sana bekerja sama seperti di chat Maestro mana pun. Untuk mencari di codebase berdasarkan makna, bukan kata yang persis sama, Indexes membangun indeks pencarian lokal yang bisa dipakai Maestro. Dan ketika sebuah run di Code siap keluar dari laptopmu, Open PR membuka pull request untuk branch-nya.
Halaman produk menampilkan demo interaktif masing-masing: Code dan IDE.
Pertanyaan yang paling sering muncul duluan
Apakah saya perlu aplikasi desktop?
Ya. Code, IDE, dan Wiki bekerja dengan folder lokal, Git worktree, shell, dan language server, jadi semuanya berjalan di aplikasi desktop osFoundry.
Apakah agen bisa me-merge ke branch saya sendiri tanpa izin?
Tidak. Run bekerja di branch dan folder masing-masing. Branch kamu saat ini hanya berubah ketika kamu menekan merge, dan secara default hanya untuk branch yang test-nya lolos.
Apakah Wiki itu wiki tim seperti Notion?
Bukan. Wiki menulis dokumentasi dari repository kode, mengutip file dan baris, dan menandai halaman ketika kode itu berubah. Fungsinya untuk dokumentasi codebase, seperti gambaran umum arsitektur atau catatan onboarding.
Apa yang terjadi pada branch yang konflik?
Branch itu tetap di tempatnya. Kamu bisa me-merge branch yang bersih sekarang dan membiarkan agen mengulang yang konflik di atasnya, atau memilih hunk satu per satu dengan Combine into a branch.
Aplikasi desktopnya bisa diunduh gratis di osfoundry.io/id/download.
