Startup ini tetap memakai Claude dan Codex, lalu mengalihkan urusan dokumen ke AI lokal

Seorang pengembang meminta agen coding memperbaiki bug pada sebuah layanan. Agen itu mula-mula harus menemukan tiket asli, mengambil sejumlah keputusan produk, dan mencari tahu persyaratan mana yang masih berlaku. Sesudah perbaikan, seseorang perlu mengubah sisa pekerjaan menjadi tiket yang dapat dilihat oleh desainer atau penanggung jawab dukungan. Perubahan kode hanya satu bagian dari pekerjaan itu, tetapi semuanya bisa dibebankan pada model berbayar yang sama.

Grayhat Developers, perusahaan perangkat lunak dengan kurang dari 40 orang, menjelaskan apa yang terjadi ketika mereka memisahkan pekerjaan tersebut dalam sebuah pracetak pada 5 November 2026. Para insinyurnya telah mencoba model yang di-host sendiri untuk pekerjaan pengembangan dan mendapati bahwa mengganti agen coding komersial membuat beberapa tugas repositori lebih lambat atau lebih sulit. Mereka tetap menggunakan agen tersebut untuk perubahan yang rumit, sementara sebagian pengambilan dokumen, persiapan materi, dan sinkronisasi tiket dipindahkan ke layanan lokal.

Pertanyaan yang menarik bagi tim kecil lain adalah bagian mana yang perlu dipindahkan lebih dulu. Pengalaman Grayhat memberi titik awal yang konkret, perkiraan yang layak ditelaah, dan contoh kesalahan saat orientasi pengguna yang bisa menggagalkan uji coba sebelum tim mengetahui apa pun tentang mutu model.

Memperbaiki bug menuntut kerja mencari konteks sebelum menyentuh kode

Grayhat memakai Outline untuk dokumentasi, Plane untuk pelacakan pekerjaan, dan ERPNext untuk informasi organisasi. Tim sudah menjalankan layanan tersebut di komputer kantor dan menghubungkan sistem identitasnya melalui Authentik. Konektor Model Context Protocol, atau MCP, di-host pada komputer yang sama. Komputer kedua menangani inferensi model. Pemisahan tersebut punya alasan praktis. Sistem dokumentasi dan tiket dapat terus melayani antarmuka biasa, sementara proses model memakai sumber daya komputasi di tempat lain.

Proses dalam makalah melibatkan serah terima antarmanusia. Seorang anggota tim memakai model internal untuk mengambil dan meringkas materi dari wiki atau pelacak isu. Bagian yang relevan dapat ditaruh di berkas repositori untuk agen coding. Sesudah mengerjakan repositori, seorang anggota tim bisa membawa langkah berikutnya kembali ke asisten internal, mengubahnya menjadi draf tiket, lalu mengirimkannya ke pelacak. Makalah menyebut komunikasi langsung antaragen sebagai pekerjaan mendatang. Dengan alur saat ini, seseorang sudah bisa melihat informasi yang akan diteruskan dan memutuskan apakah informasi itu layak dikirim.

Titik serah terima dalam alur kerja Grayhat. Ilustrasi orisinal oleh Telli.sh berdasarkan studi kasus 5 November.

Misalnya, seorang pelanggan melaporkan bahwa hasil ekspor mengulang baris. Laporan asli memuat referensi akun pribadi dan transkrip yang tidak berkaitan dengan bug. Asisten lokal dapat menemukan aturan ekspor terbaru, pemilik layanan, dan solusi sementara sebelumnya. Insinyur kemudian bisa menulis ringkasan berisi contoh sintetis dan jumlah baris yang semestinya. Agen coding mendapatkan bahan untuk mereproduksi bug. Informasi sensitif tetap berada dalam sistem internal karena orang yang menangani serah terima memilih sendiri informasi yang boleh diteruskan.

Pertahankan tautan asli pada draf internal. Jika persyaratan bertentangan, peninjau bisa melihat apakah aturan yang diusulkan berasal dari keputusan baru atau solusi sementara lama. Ringkasan lokal yang kehilangan sumbernya tetap menimbulkan masalah serupa dengan yang hendak diatasi. Anggota tim berikutnya harus mencari tahu deskripsi mana yang dapat dipercaya.

Tim membayar kapasitas dan memperkirakan bagian yang dapat dialihkan

Para penulis melaporkan pengeluaran dasar AI komersial sekitar $325 per bulan, terdiri dari sekitar $175 untuk tujuh lisensi Claude, $140 untuk tujuh langganan Codex, dan $10 untuk kredit. Mereka juga melaporkan lebih dari 25,93 miliar token tercatat di berbagai layanan. Makalah itu tidak menunjukkan bahwa token yang tercatat berasal dari periode tagihan yang sama dengan $325. Gunakan setiap angka sesuai dengan apa yang diukurnya. Membagi kedua angka tersebut akan menghasilkan harga token dengan dasar yang belum terbukti.

Tim Grayhat memperkirakan bahwa transfer konteks, dokumentasi, dan koordinasi proyek mencakup 30–40% beban kerja AI komersialnya. Para penulis memperkirakan sistem lokal dapat menangani sekitar 90% pekerjaan dalam kategori itu. Mengalikan perkiraan tersebut menghasilkan 27–36% dari seluruh beban kerja komersial. Jika bagian itu dihitung dari $325, nilainya setara dengan sekitar $88–117 per bulan. Angka ini merupakan perkiraan beban kerja dan nilai setara biaya dari studi kasus 5 November. Makalahnya tidak melakukan eksperimen tagihan terkontrol sebelum dan sesudah perubahan.

Perkiraan Grayhat berawal dari porsi pekerjaan dan menghasilkan nilai setara biaya. Ilustrasi orisinal oleh Telli.sh.

Perbedaan ini penting jika biaya dihitung per pengguna. Jika ketujuh pengembang masih memerlukan langganan untuk pekerjaan yang kompleks, pemakaian yang turun bisa tidak mengubah tagihan berikutnya. Manfaatnya mungkin terlihat sebagai kapasitas untuk mengerjakan rangkaian perbaikan berikutnya, lebih sedikit tekanan karena batas pemakaian, atau lebih sedikit pembelian tambahan. Tim yang membayar per permintaan mungkin melihat perubahan lebih awal, tetapi percobaan berulang dan antrean yang lambat bisa mengikis sebagian penghematan. Jika tim harus membeli GPU dan membayar seseorang untuk memastikan GPU itu tetap tersedia, masukkan biaya tersebut ke dalam perbandingan.

Pilih satuan ukur yang bisa ditinjau. Jumlah tiket yang dibuat mudah dihitung, tetapi tiket yang ditulis ulang dari awal oleh pimpinan proyek memberi sedikit bukti adanya penghematan. Ukur ringkasan dan tiket yang diterima, serta catat penyuntingan yang mengubah makna tugas. Setelah peninjau dapat mengenali keluaran yang layak secara konsisten, catat upaya yang dibutuhkan untuk menghasilkannya.

Antarmuka kedua mengubah siapa yang harus menyiapkan koneksi

Peluncuran awal memakai LobeHub. Insinyur menerima petunjuk untuk menghubungkan antarmuka mereka sendiri dengan alat internal organisasi. Menurut penulis, demo yang menjanjikan tidak berkembang menjadi penggunaan rutin. Pengguna harus mengetahui konektor mana yang dipilih, di mana letaknya, dan bagaimana melakukan autentikasi. Setiap keputusan tambahan memperlambat pengguna mendapatkan jawaban pertama yang berguna.

Alat kerja pada antarmuka kedua Grayhat dikonfigurasi terpusat. Gambar 2 dari “Create Your Own Work Stack” oleh Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz, dan Abdullah Aamir, CC BY 4.0.

Tim beralih ke instalasi LibreChat yang dikonfigurasi terpusat. Pengguna bisa melihat alat yang sudah tersedia dan melakukan autentikasi saat mengaksesnya. Para penulis mencatat delapan komentar terkait penyiapan dan orientasi pengguna dari 11 wawancara terstruktur tentang versi pertama. Versi kedua menghasilkan tiga komentar dalam kategori tersebut melalui umpan balik Discord yang tidak terstruktur. Kedua angka berasal dari cara pengumpulan yang berbeda. Keduanya membantu mengenali masalah orientasi pengguna, tetapi tidak menunjukkan seberapa besar adopsi meningkat atau berapa karyawan yang sudah tidak mengalaminya.

Rancang sesi pertama dengan tugas nyata yang paling sederhana. Seorang pimpinan proyek yang masuk untuk memeriksa kriteria penerimaan sebuah isu semestinya bisa melihat apakah pelacak tersambung dan akun mana yang aktif. Insinyur yang ingin menyusun tiga tiket semestinya dapat meninjaunya sebelum dikirim. Tim yang mengajari orang mengatur konektor sebelum mereka dapat menemukan pekerjaan sendiri berisiko mengukur kesabaran mereka, bukan kegunaan alatnya.

Penyiapan terpusat juga membawa tanggung jawab baru. Seseorang harus memelihara daftar konektor yang disetujui, merotasi kredensial, dan menjelaskan siapa yang berhak mengubah izin. Tanpa pengelolaan ini, kesalahan konfigurasi satu orang dapat berdampak pada semua pengguna. Keuntungannya, tim dapat memperbaiki masalah penyiapan yang berulang sekali saja dan memberikan perbaikan yang sama kepada semua pengguna layanan.

Berikan sistem lokal pekerjaan yang hasilnya punya penanggung jawab jelas

Penyaringan isu menjadi pilihan pertama yang praktis. Asisten internal bisa mengelompokkan laporan duplikat dan mengusulkan ringkasan beserta tautan tiket sumber. Penanggung jawab proyek memutuskan apakah dua laporan benar-benar duplikat dan apakah deskripsi gabungan melewatkan suatu kondisi. Asisten bisa membuat draf komentar yang menjelaskan pengelompokan tersebut. Orang dapat menelusuri tindakan yang diambil karena pembaruan itu memiliki penanggung jawab yang terlihat.

Pemeliharaan dokumentasi adalah pekerjaan yang berbeda. Misalkan suatu perubahan memindahkan pengaturan dari satu layar ke layar lain. Asisten dapat menemukan halaman bantuan yang usang, mengenali edisi produk yang dicakup, dan mengusulkan perbaikan. Editor memeriksa navigasi terbaru dan menerbitkan perubahan yang benar. Model jarak jauh yang lebih kuat memberi sedikit manfaat jika kesulitan utamanya adalah mengakses halaman internal terbaru dan menjaga cakupan setiap artikel.

Pengerjaan kode kompleks memberi contoh sebaliknya. Migrasi basis data mungkin menuntut pemeriksaan kontrak data lama, perubahan di lebih dari satu layanan, dan validasi pemulihan ke versi sebelumnya. Grayhat mendapati konfigurasi lokal yang diuji kesulitan menangani pekerjaan repositori yang lebih besar, khususnya ketika model membutuhkan konteks luas dan inferensi cepat. Studi tersebut menjelaskan perangkat keras, model, serta pengalaman tim. Gunakan temuan itu sebagai dasar untuk menguji beban kerja Anda sendiri secara lokal sebelum memperluas tugas yang diberikan.

Gunakan jalur terbatas untuk tugas yang memadukan pemformatan sederhana dan data sensitif. Mengirim draf ke luar jaringan masih bisa membuka informasi meski alat aslinya berjalan di infrastruktur sendiri. Jika tugas memerlukan serah terima jarak jauh, setujui tujuannya dan siapkan berkas minimal yang sesuai. Jika hasil internal belum disetujui, simpan dalam antrean peninjauan internal. Saat waktu tunggu habis, tampilkan kesalahan agar informasi tidak berpindah tanpa sepengetahuan pengguna.

Uji coba singkat bisa memisahkan pekerjaan berguna dari urusan infrastruktur

1. Tentukan tiga keluaran. Pilih ringkasan dengan tautan tiket, suntingan dokumentasi, dan draf isu. Tulis satu kalimat untuk masing-masing yang menjelaskan siapa yang menerimanya dan bukti apa yang diperlukan. Simpan contoh keluaran yang gagal di samping contoh yang baik, termasuk kekeliruan yang mudah luput.
2. Ukur jalur kerja saat ini. Selama satu pekan kerja biasa, hitung contoh yang selesai, koreksi substantif, dan waktu yang dihabiskan mencari konteks. Catat pemakaian komersial per alur jika memungkinkan. Perhatikan apakah memindahkan pekerjaan itu benar-benar mengubah jumlah lisensi yang ditagih atau biaya kelebihan pemakaian. Catat secara terpisah pekerjaan yang sama sekali tidak dilakukan tim.
3. Sambungkan satu alat internal. Mulai dengan akses baca pada satu proyek yang ditentukan. Pastikan karyawan berwenang bisa mengambil isu yang sudah diketahui dan orang di luar proyek tidak bisa. Batasi uji coba pada sekelompok kecil orang yang telah mengerjakan tugas pilihan. Sediakan cara yang jelas untuk menyelesaikan tugas secara manual saat alat gagal.
4. Bandingkan draf sebelum memberi izin tulis. Minta peninjau yang sama menerima atau menolak keluaran dengan kriteria yang sama. Catat tautan yang mengarah ke isu keliru, fakta usang, dan kesimpulan yang tidak didukung. Tambahkan pratinjau, persetujuan, dan catatan yang tersimpan sebelum mengizinkan asisten memperbarui pelacak yang digunakan tim.
5. Periksa pekerjaan yang beralih. Bandingkan pekerjaan yang diterima, waktu peninjauan, pemakaian aktif, dan tagihan aktual. Masukkan waktu pemeliharaan komputer, gangguan, serta perubahan konektor. Hitung juga bantuan penyiapan yang diberikan langsung kepada pengguna. Aplikasi yang baru berjalan setelah pakar melatih setiap orang selama sepuluh menit masih menimbulkan biaya orientasi.

Jika Anda sudah menjalankan model lokal untuk pengembang, uji alur ini sambil tetap melayani trafik biasa. Antrean muncul ketika beberapa orang mulai bekerja bersamaan. Layanan yang cepat menjawab satu permintaan masih bisa membuat tiga orang menunggu. Beri tugas yang peka terhadap waktu cara untuk menampilkan kemajuan serta pilihan kembali ke cara manual biasa. Dengan begitu, uji coba tetap dapat digunakan sambil tim mempelajari jenis pekerjaan yang cocok.

Lampiran Grayhat memberi gambaran skala untuk perbandingan ini. Komputer alat internal memakai memori sistem 16 GB, sedangkan komputer inferensi terpisah memiliki 32 GB dan RTX 4080 dengan VRAM 16 GB. Tim melaporkan penambahan pemantauan jaringan, penjadwalan, dan catu daya tak terputus ketika kebutuhan operasional mulai terlihat. Itu masukan yang berguna dalam menyusun anggaran uji coba. Temuan ini menggambarkan biaya menjalankan layanan yang diandalkan rekan kerja, di samping biaya membuat model menjawab.

Tentukan untuk apa satu jam kerja AI berikutnya digunakan

Gagasan yang bisa dipakai kembali adalah memisahkan persiapan konteks dari penalaran khusus dan memberi setiap serah terima seorang penanggung jawab. Mulai dengan pekerjaan berulang yang menghasilkan artefak yang sudah biasa ditinjau oleh tim. Ukur upaya untuk menerima hasilnya, kemudian putuskan apakah jalur lokal layak diberi tugas berikutnya. Pengalaman Grayhat memberi cara untuk mengambil keputusan itu sambil mempertahankan alat coding yang masih memberi nilai.

Sumber

• Pracetak Grayhat Developers, 5 November 2026
• Makalah lengkap, termasuk perkiraan beban kerja, infrastruktur, dan Gambar 2
• Gambar 2 asli
• Lisensi CC BY 4.0 untuk gambar di makalah

---

Untuk menyimpan pembahasan di balik serah terima dalam catatan yang dapat dicari, buat akun Telli.sh.