AI untuk Dokumentasi: Membantu, Bukan Menggantikan Pemahaman

Sejak AI/LLM jadi alat sehari-hari buat developer, dokumentasi adalah salah satu area yang paling cepat berubah kebiasaannya. Dulu menulis README, panduan deploy, atau catatan arsitektur itu kerjaan yang sering ditunda karena makan waktu. Sekarang, tinggal tempel potongan kode atau config ke chat AI, minta dijelaskan, dan draft dokumentasi jadi dalam hitungan detik. Sebagai orang yang kerja di sistem klinik/rumah sakit dengan tumpukan Laravel, Vue, Filament, dan beberapa layanan Docker yang saling terhubung, saya termasuk yang banyak terbantu cara ini. Tapi ada satu hal yang menurut saya penting dibahas terus terang: kemudahan ini punya jebakan. Kalau dipakai tanpa batas yang jelas, AI bisa bikin dokumentasi kita rapi di permukaan, tapi pemahaman kita sendiri soal sistem justru menipis.

Kenapa ini penting dibahas

Dokumentasi yang baik bukan cuma soal ada tulisannya. Fungsinya adalah representasi dari pemahaman kita terhadap sistem — kenapa sebuah keputusan desain diambil, apa yang akan rusak kalau sebuah asumsi dilanggar, di mana letak bagian yang rapuh. Kalau proses menulis dokumentasi sepenuhnya dipindah ke AI tanpa kita ikut mengecek dan mencernanya, yang tersisa cuma teks yang terlihat benar. Ini berbahaya justru di sistem yang risikonya tinggi seperti aplikasi kesehatan: alur rekam medis, integrasi ke sistem eksternal, atau proses yang menyentuh data pasien — dokumentasi yang salah di area seperti ini bisa lebih berbahaya daripada tidak ada dokumentasi sama sekali, karena orang akan percaya begitu saja pada apa yang tertulis.

Masalahnya bukan pada alatnya. AI genuinely bagus untuk merapikan struktur, menyamakan gaya bahasa, atau menjelaskan potongan kode yang asing bagi orang lain di tim. Masalahnya ada di cara pakainya: apakah kita menggunakannya sebagai asisten penulis yang mempercepat proses menuangkan pemahaman yang sudah kita punya, atau sebagai pengganti proses berpikir itu sendiri.

Batas wajar: AI sebagai asisten penulis, bukan sumber kebenaran

Prinsip yang saya pegang cukup sederhana: AI boleh membantu bagian menulis, tapi bagian memverifikasi kebenaran tetap harus tangan manusia yang paham konteksnya. Beberapa praktik yang biasa saya pakai:

Minta AI merangkum potongan kode jadi draft penjelasan, lalu saya baca ulang baris per baris — kalau ada bagian yang saya sendiri ragu benar atau tidaknya, itu tanda saya belum benar-benar paham bagian itu.
Untuk dokumentasi arsitektur atau alur deploy, saya tulis dulu poin-poin kasar dari kepala sendiri, baru minta AI merapikan struktur dan bahasanya. Kalau urutannya dibalik, saya cuma jadi editor dari asumsi AI, bukan penulis dari pemahaman saya sendiri.
Klaim teknis yang spesifik — versi tool, perilaku default sebuah service, batasan sebuah konfigurasi — selalu saya cek ulang ke sumber aslinya. AI cukup sering percaya diri menjelaskan detail yang sebenarnya sudah berubah di versi terbaru, atau tertukar dengan perilaku tool lain yang mirip.

Contoh ilustrasi: misalkan kita minta AI menjelaskan sebuah script deploy Docker Compose. Hasilnya bisa terlihat meyakinkan. Tapi kalau kita tidak paham kenapa urutan depends_on disusun begitu, atau kenapa satu service perlu restart: unless-stopped sementara yang lain tidak, dokumentasi itu cuma cerita yang terdengar masuk akal — bukan pengetahuan yang bisa dipakai saat production bermasalah jam 2 pagi.

Tanda-tanda kita mulai kehilangan pemahaman

Beberapa sinyal yang saya jadikan alarm pribadi: tidak bisa menjelaskan ulang isi dokumentasi dengan kata-kata sendiri tanpa membuka lagi chat AI-nya; menerima penjelasan AI soal kode orang lain tanpa menjalankan atau membaca kodenya langsung; atau dokumentasi tim mulai berisi istilah yang, kalau ditanya balik, tidak ada satupun anggota tim yang bisa menjelaskan asal-usulnya.

Kalau salah satu dari ini terjadi, saatnya berhenti sebentar dan kembali ke sumber aslinya — baca kodenya, coba jalankan sistemnya, atau diskusi langsung dengan yang mengerjakan bagian itu. AI bagus mempercepat proses menuju pemahaman, tapi bukan pengganti proses itu sendiri, apalagi untuk sistem yang keputusan salahnya berdampak nyata ke orang lain.

Praktik yang saya pakai supaya tetap seimbang

Dokumentasi untuk bagian kritikal (alur data sensitif, integrasi sistem eksternal, keputusan arsitektur besar) selalu ditulis draft manual dulu, baru dibantu AI untuk perapian.
Dokumentasi untuk bagian rutin (cara install dependency, format command, changelog) lebih aman sepenuhnya dibantu AI karena risikonya rendah.
Setiap dokumentasi hasil AI saya anggap draft, bukan final, sampai saya membacanya dengan asumsi harus bisa mempertanggungjawabkan setiap kalimatnya kalau ditanya tim.

Pembagian ini bukan aturan kaku, tapi cara berpikir yang disesuaikan tergantung seberapa besar risiko kalau dokumentasinya salah.

Takeaway

AI sangat membantu mempercepat proses menulis dokumentasi, tapi nilai dokumentasi tetap berasal dari pemahaman manusia yang menulisnya, bukan dari kefasihan bahasa AI yang menyusunnya. Aturan paling sederhana yang bisa dipegang: kalau kita tidak bisa menjelaskan ulang isi dokumentasi itu dengan kata-kata sendiri tanpa membuka chat AI lagi, berarti kita belum selesai memahaminya — dan dokumentasinya juga belum benar-benar selesai, seberapa pun rapinya tampilan teksnya.