Buka sebuah repository enam bulan setelah sebuah fitur dirilis, dan Anda masih bisa merekonstruksi banyak hal. Anda dapat menelusuri arsitekturnya, memeriksa skemanya, membaca pengujiannya, dan melihat dengan tepat baris mana yang berubah.
Yang biasanya tidak bisa Anda rekonstruksi adalah percakapan yang membuat baris-baris itu perlu ada.
Kode tidak akan memberi tahu Anda bahwa sebuah aturan validasi ada karena satu pelanggan mengirim ekspor yang salah format. Kode juga tidak akan menjelaskan bahwa kebijakan retry yang tampak aneh mencegah transaksi duplikat di sistem downstream. Kode tidak akan menunjukkan bahwa antarmuka yang lebih bersih ditolak setelah uji aksesibilitas, atau bahwa batas layanan mencerminkan pembatasan kontraktual, bukan preferensi engineering.
Git sangat baik dalam menyimpan riwayat kode. Git hanya menyimpan maksud ketika sebuah tim dengan sengaja menuliskan maksud itu dan tetap menghubungkannya dengan implementasi.
Kesenjangan itu selalu menjadi bagian dari software engineering. Alat coding AI membuatnya lebih terlihat. Sebuah sistem dapat membaca setiap file dalam repository, mengikuti setiap simbol, dan menghasilkan patch yang secara teknis meyakinkan, tetapi tetap menyelesaikan masalah yang salah.
Masalahnya bukan karena kodenya menyesatkan. Kode sedang menjawab pertanyaan yang lebih sempit.
Lima lapisan kebenaran engineering
Sebagian besar perubahan software yang bermakna bergantung pada lima lapisan bukti yang berbeda.
- Maksud — Hasil apa yang diminta oleh pengguna, pelanggan, atau bisnis? Ini bisa berada dalam spesifikasi, ticket, percakapan dukungan, atau catatan rapat.
- Batasan — Apa yang tidak boleh rusak? Janji kompatibilitas, batas keamanan, regulasi, kontrak, anggaran, dan tenggat waktu sering kali berada di luar repository.
- Implementasi — Bagaimana sistem bekerja saat ini? Kode, pengujian, skema, dependensi, dan konfigurasi deployment menyediakan lapisan ini.
- Bukti runtime — Apa yang terjadi di sistem nyata? Log, trace, metrik, data produksi, dan laporan insiden dapat bertentangan dengan asumsi yang tampak masuk akal di dalam kode.
- Riwayat keputusan — Mengapa pendekatan saat ini dipilih? Pull request, diskusi desain, alternatif yang ditolak, dan insiden sebelumnya menyimpan jawabannya.
Repository paling kuat pada lapisan ketiga. Repository memang memuat sebagian dari lapisan-lapisan lainnya, tetapi jarang cukup untuk merepresentasikannya secara utuh.
Ini penting karena kegagalan software sering muncul di batas antar lapisan. Implementasinya cocok dengan spesifikasi yang sudah usang. Perbaikannya memenuhi ticket tetapi melanggar batasan operasional. Pengujiannya lulus karena mengodekan asumsi kemarin. Kodenya konsisten secara internal sementara data produksi mengikuti pola yang tidak pernah didokumentasikan siapa pun.
Patch yang benar secara lokal tetap bisa menjadi perubahan yang salah.
Apa yang tidak dapat dijawab oleh repositori dengan sendirinya
Bayangkan seorang pengguna mengedit dokumen lalu mencari kalimat yang telah diperbarui, tetapi yang muncul di hasil justru versi lamanya. “Buat pencarian langsung diperbarui” terdengar seperti permintaan yang jelas. Repositori mengungkap beberapa kemungkinan titik awal, tetapi tidak dapat menentukan perbaikan yang benar dengan sendirinya.
| Pertanyaan | Sumber yang kemungkinan relevan |
|---|---|
| Versi dokumen mana yang menjadi acuan utama? | Dokumen sumber dan riwayat revisi |
| Di mana teks lama masih tertinggal? | Log sinkronisasi, output ekstraksi, indeks pencarian, atau cache |
| Apa arti “langsung” untuk produk ini? | Janji produk atau sasaran layanan |
| Apakah izin dokumen berubah bersamaan dengan isinya? | Izin sumber dan riwayat audit |
| Apakah hasil usang ini terbatas pada satu pengguna, sumber, atau wilayah? | Jejak permintaan dan metrik produksi |
Kode pencarian mungkin menjelaskan bagaimana hasil dikembalikan. Namun, kode itu tidak dapat memberi tahu Anda apakah masalah yang sebenarnya adalah keterlambatan sinkronisasi, ekstraksi yang usang, invalidasi cache, propagasi izin, atau ekspektasi yang tidak pernah didefinisikan oleh produk.
Pembedaan ini menjadi semakin penting dalam sistem yang sudah matang. Sebuah field yang tampak usang mungkin masih mendukung klien lama. Sebuah layanan yang terlihat duplikat mungkin memisahkan data dengan kebutuhan izin yang berbeda. Sebuah pemeriksaan yang tampak berlebihan mungkin merupakan satu-satunya jejak di level kode dari insiden produksi yang tidak pernah dilihat tim saat ini.
Menghapus kompleksitas itu berharga. Menghapus sejarah yang menyamar sebagai kompleksitas itu mahal.
Lebih banyak konteks tetap bisa menghasilkan jawaban yang salah
Solusi yang tampak jelas adalah memberi AI lebih banyak materi: seluruh repositori, setiap tiket, setiap dokumen, setiap pesan, dan setiap log.
Itu menciptakan akses, bukan pemahaman.
Sumber bisa saja usang, saling bertentangan, bersifat spekulatif, atau ditulis untuk audiens yang berbeda. Hasil brainstorming tidak seharusnya mengungguli spesifikasi yang sudah disetujui. Kebutuhan dari enam bulan lalu tidak seharusnya diam-diam menimpa keputusan produk yang dibuat kemarin. Log produksi harus dikaitkan dengan rilis, environment, dan jalur kode yang menghasilkannya. Permintaan pelanggan tidak seharusnya diperlakukan sebagai kebutuhan universal tanpa memeriksa cakupannya.
Karena itu, sistem konteks yang serius membutuhkan lebih dari sekadar retrieval. Sistem itu membutuhkan cara untuk menalar tentang:
- Otoritas: Sumber mana yang berwenang menetapkan requirement?
- Keterkinian: Informasi mana yang masih berlaku, dan mana yang sudah digantikan?
- Asal-usul: Dari mana setiap klaim, batasan, atau kesimpulan berasal?
- Relasi: Issue, rilis, pelanggan, dataset, dan jalur kode mana yang saling terkait?
- Izin: Sumber mana yang boleh digunakan untuk tugas ini dan ditampilkan kepada orang ini?
Konteks bukanlah tumpukan token. Konteks adalah graf dengan waktu, otoritas, dan batasan.
Lebih banyak konteks seharusnya menghasilkan lebih banyak bukti, bukan lebih banyak keyakinan tanpa bukti.
Unit kerja yang sebenarnya adalah perubahan
Editor dan alat coding diatur berdasarkan file karena file adalah yang kita ubah. Tim engineering diatur berdasarkan perubahan.
Sebuah perubahan dimulai dari alasan. Lalu menjadi requirement, menyentuh kode dan data, melewati review, sampai ke produksi, dan menghasilkan bukti baru. Jika tahap-tahap itu tetap terputus, setiap tugas di masa depan akan dimulai lagi dengan putaran arkeologi yang baru.
Sistem AI yang bekerja pada perangkat lunak nyata seharusnya mengikuti siklus hidup itu.
Sebelum implementasi, sistem itu harus mengidentifikasi permintaan, batasan yang relevan, dan sumber yang saling bertentangan. Sistem itu harus tahu apakah ia sedang memperbaiki cacat, mengubah perilaku yang diharapkan, atau memperkenalkan kontrak baru.
Selama implementasi, sistem itu harus menghubungkan setiap pilihan yang bermakna dengan bukti. Mengapa modul ini? Mengapa strategi migrasi ini? Mengapa mempertahankan branch ini? Penjelasannya harus tetap ada melampaui chat yang menghasilkan kode tersebut.
Setelah implementasi, sistem seharusnya melampirkan hasil verifikasi, keputusan review, dan batasan yang baru ditemukan pada perubahan tersebut. Jika tidak, orang berikutnya—atau sesi AI berikutnya—harus menemukannya kembali.
Inilah perbedaan antara alat yang bisa mengedit repositori dan sistem yang bisa berpartisipasi dalam pekerjaan rekayasa.
AI seharusnya mengurangi rekonstruksi, bukan menghilangkan penilaian
Konteks yang lebih baik kadang diposisikan sebagai jalan menuju pengembangan perangkat lunak otonom. Nilai langsungnya tidak sedramatis itu, tetapi lebih berguna: mengurangi biaya untuk merekonstruksi realitas sebelum melakukan perubahan.
AI dapat menghadirkan kebutuhan awal di samping kode yang relevan. AI dapat menampilkan insiden yang menjelaskan adanya pengaman yang tidak biasa. AI dapat menghubungkan metrik yang gagal dengan rilis yang mengubahnya. AI dapat menunjukkan bahwa dua sumber otoritatif saling bertentangan sebelum implementasi dimulai.
Kemampuan-kemampuan itu tidak menghilangkan penilaian rekayasa. Kemampuan-kemampuan itu membuat penilaian menjadi lebih berlandaskan informasi.
Seseorang tetap harus memutuskan tradeoff mana yang dapat diterima, apakah suatu kebutuhan sudah lengkap, dan seberapa besar risiko yang dapat dibawa oleh sebuah rilis. Sistem seharusnya membuat bukti terlihat dan penalarannya dapat diperiksa. Sistem tidak seharusnya menyembunyikan ketidakpastian di balik patch yang tampak rapi.
Standarnya bukan “apakah ia bisa menghasilkan kode?”
Standarnya adalah “apakah ia bisa menjelaskan mengapa ini adalah perubahan yang tepat saat ini?”
Dari sadar repositori menjadi sadar pekerjaan
Asisten coding pertama kali menjadi berguna ketika mampu memahami file di hadapan developer. Kesadaran terhadap repositori adalah langkah besar berikutnya: menemukan kode terkait, menelusuri simbol, dan menerapkan perubahan di seluruh proyek.
Langkah berikutnya adalah kesadaran terhadap pekerjaan di sekitar repositori.
Artinya menghubungkan kode dengan spesifikasi yang memintanya, percakapan yang memperjelasnya, bukti produksi yang menantangnya, dan keputusan yang perlu diingat setelahnya. Ini juga berarti menyingkirkan konteks yang tidak relevan, usang, atau berada di luar izin pengguna.
Saat membangun Dvina, ini adalah salah satu gagasan yang terus kami kembalii. Pekerjaan tidak terjadi di dalam satu file, aplikasi, atau percakapan. Makna hidup dalam hubungan di antara semuanya dan dalam cara hubungan-hubungan itu berubah seiring waktu.
Repositori tetap esensial. Ia adalah sumber kebenaran yang dapat dieksekusi untuk perilaku sistem. Hanya saja, repositori bukan sumber kebenaran yang lengkap untuk maksud produk, realitas operasional, atau memori organisasi.
Keseluruhan cerita mengubah apa yang dibangun
Jika hanya ada kode, pertanyaan alaminya adalah:
Perubahan apa yang cocok untuk sistem ini?
Dengan konteks yang lebih luas, pertanyaannya menjadi:
Perubahan apa yang cocok untuk sistem ini, kebutuhan ini, riwayat ini, dan momen ini?
Pertanyaan kedua itu menangkap kendala sebelum berubah menjadi regresi. Pertanyaan itu memberi peninjau alasan di balik implementasi. Pertanyaan itu membantu anggota tim baru memahami mengapa sistem tampak seperti sekarang. Pertanyaan itu memberi AI peran yang membumi: bukan sebagai oracle di dalam editor, melainkan sebagai peserta yang dapat merangkai bukti dari seluruh pekerjaan.
Repo Anda tidak pernah menceritakan keseluruhan kisahnya.
Peluangnya adalah membangun sistem yang dapat membaca sisanya—dan menunjukkan proses kerjanya.
