title: Learn AI-Driven Documentation and Technical Writing Implementation and Usage - Part 001 description: Skill map berbasis The First 20 Hours untuk menguasai AI-driven documentation sebagai engineering capability, bukan sekadar aktivitas menulis dokumen. series: learn-ai-driven-documentation seriesTitle: Learn AI-Driven Documentation and Technical Writing Implementation and Usage order: 1 partTitle: Kaufman Skill Map tags:

• ai
• documentation
• technical-writing
• docs-as-code
• kaufman
• engineering-handbook date: 2026-06-30

Part 001 — Kaufman Skill Map for AI-Driven Documentation

1. Target Pembelajaran

Tujuan part ini adalah membuat peta skill yang jelas sebelum masuk ke implementasi teknis. Kita tidak sedang belajar “cara memakai AI untuk menulis README”. Itu terlalu sempit.

Target seri ini adalah kemampuan untuk:

1. Mendesain sistem dokumentasi yang bisa dipercaya oleh engineer, reviewer, auditor, SRE, product team, dan AI assistant.
2. Menggunakan AI untuk mempercepat drafting, refactoring, summarization, review, dan maintenance dokumentasi tanpa mengorbankan kebenaran teknis.
3. Membangun workflow docs-as-code yang punya source of truth, version control, review, validation, publishing, observability, dan ownership.
4. Mengubah knowledge engineering yang tersebar di code, API spec, issue, PR, incident report, architecture decision record, dan conversation log menjadi dokumentasi yang usable.
5. Menilai kualitas dokumentasi secara objektif: akurat, task-oriented, maintainable, discoverable, searchable, secure, dan tidak overclaiming.

Setelah menyelesaikan part ini, kita ingin punya mental model yang cukup untuk menjawab pertanyaan berikut:

• Skill apa saja yang harus dipelajari agar AI-driven documentation tidak berubah menjadi generator halusinasi?
• Apa batas antara pekerjaan yang boleh diberikan ke AI dan pekerjaan yang tetap harus dimiliki manusia?
• Bagaimana mengukur apakah dokumentasi membantu engineering execution, bukan hanya terlihat rapi?
• Bagaimana merancang latihan 20 jam pertama agar cepat mencapai kemampuan operasional?

2. Prinsip Dasar Kaufman yang Kita Pakai

Josh Kaufman dalam The First 20 Hours menekankan rapid skill acquisition: pilih target performa yang spesifik, pecah skill menjadi sub-skill kecil, pelajari secukupnya untuk bisa mengoreksi diri, singkirkan friction, lalu komit pada praktik terstruktur selama minimal 20 jam.

Untuk konteks kita, interpretasinya seperti ini:

Yang penting: Kaufman bukan menyarankan “belajar dangkal”. Ia menyarankan mengurangi delay menuju praktik. Untuk engineer senior, ini sangat relevan: skill dokumentasi tidak akan tajam hanya dengan membaca style guide. Ia tajam ketika kita berulang kali mengubah sistem kompleks menjadi pengetahuan yang bisa dipakai orang lain.

3. Definisi Kerja: Apa Itu AI-Driven Documentation?

Dalam seri ini, AI-driven documentation berarti sistem dokumentasi yang menggunakan AI di dalam lifecycle dokumentasi, tetapi tetap memiliki kontrol engineering yang jelas.

AI dapat membantu pada aktivitas berikut:

• Mengubah code diff menjadi draft release notes.
• Mengubah PR discussion menjadi architecture decision summary.
• Mengubah OpenAPI/AsyncAPI spec menjadi explanation docs.
• Mengubah incident timeline menjadi postmortem draft.
• Mengidentifikasi bagian dokumentasi yang stale terhadap source of truth.
• Mengusulkan struktur information architecture.
• Melakukan review gaya bahasa, konsistensi istilah, dan missing sections.
• Menjawab pertanyaan pengguna berdasarkan dokumen yang sudah terindeks.

Namun AI tidak boleh menjadi pemilik kebenaran. Dalam sistem yang sehat:

AI boleh mempercepat produksi pengetahuan, tetapi source of truth, judgment, accountability, dan approval tetap berada pada sistem engineering dan manusia yang bertanggung jawab.

Kita akan memakai istilah berikut sepanjang seri:

4. Target “Top 1%” untuk Software Engineer

Top 1% di sini bukan berarti menjadi technical writer profesional penuh waktu. Untuk software engineer, targetnya adalah menjadi orang yang mampu membuat pengetahuan teknis menjadi operationally usable.

Engineer dengan kemampuan dokumentasi kelas atas biasanya punya ciri berikut:

1. Bisa membedakan antara tutorial, how-to, reference, dan explanation.
2. Tidak mencampur motivasi, langkah operasional, detail API, dan opini arsitektur dalam satu dokumen yang sama.
3. Menulis dokumen dari perspektif pembaca yang sedang menyelesaikan tugas, bukan dari perspektif penulis yang ingin menunjukkan semua yang ia tahu.
4. Selalu menautkan dokumentasi ke source of truth.
5. Bisa mendeteksi dokumen yang tampak bagus tetapi sebenarnya tidak aman digunakan.
6. Mendesain dokumentasi sebagai workflow, bukan sebagai file Markdown statis.
7. Menggunakan AI sebagai accelerator, bukan sebagai otoritas.
8. Membangun quality gate untuk mencegah broken links, stale examples, inconsistent terminology, leaking secrets, dan hallucinated claims.
9. Menjadikan dokumentasi sebagai bagian dari delivery lifecycle: design, implementation, release, operation, incident, dan deprecation.
10. Memahami bahwa dokumentasi yang baik mengurangi coordination cost, onboarding time, operational risk, dan dependency pada tribal knowledge.

Sasaran kita bukan “dokumen panjang”. Sasaran kita adalah dokumen yang mengubah perilaku engineering: orang lebih cepat memahami, lebih jarang salah implementasi, lebih mudah debugging, dan lebih percaya pada sistem.

5. Skill Decomposition

AI-driven documentation terdiri dari beberapa sub-skill. Jika salah satu lemah, hasilnya sering gagal.

5.1 Technical Writing

Technical writing bukan “bahasa bagus”. Untuk engineer, technical writing adalah kemampuan membuat pengetahuan teknis menjadi usable under constraints.

Constraint nyata:

• Pembaca tidak punya konteks penuh.
• Pembaca sedang buru-buru.
• Pembaca mungkin sedang incident.
• Pembaca bisa salah menafsirkan istilah.
• Sistem berubah lebih cepat daripada dokumentasi.
• AI bisa membuat draft yang meyakinkan tetapi salah.

Technical writing yang baik punya beberapa invariant:

5.2 Information Architecture

Information architecture adalah cara menata pengetahuan agar pembaca bisa menemukan, memahami, dan menggunakan informasi dengan effort minimal.

Framework penting yang akan kita pakai adalah Diátaxis:

Banyak dokumentasi internal gagal karena mencampur empat tipe ini. Contoh buruk:

• README berisi onboarding, design rationale, API reference, troubleshooting, dan changelog sekaligus.
• Runbook menjelaskan sejarah arsitektur tetapi tidak memberi langkah mitigasi.
• ADR berubah menjadi tutorial.
• API reference berisi opini produk yang tidak bisa diverifikasi.

5.3 Docs-as-Code

Docs-as-code berarti dokumentasi diperlakukan seperti artefak engineering:

• Ditulis dalam plain text markup seperti Markdown/MDX.
• Disimpan di version control.
• Direview lewat pull request.
• Divalidasi dengan automated tests.
• Dipublikasikan lewat pipeline.
• Diobservasi dengan metrics.

Mental modelnya sederhana:

Jika dokumentasi memengaruhi keputusan engineering, maka dokumentasi harus punya lifecycle engineering.

5.4 AI Usage

AI usage adalah kemampuan menggunakan model sebagai partner kerja tanpa menyerahkan judgment.

Skill yang dibutuhkan:

• Menulis prompt yang jelas.
• Memberikan konteks yang cukup tetapi tidak berlebihan.
• Meminta output dalam struktur yang bisa direview.
• Memaksa AI membedakan fakta, inferensi, asumsi, dan gap.
• Melakukan verification loop.
• Menghindari prompt yang mengundang halusinasi.

Contoh prompt buruk:

Buat dokumentasi service ini.

Contoh prompt lebih baik:

Anda membantu membuat draft internal engineering documentation untuk service pembayaran.
Gunakan hanya konteks yang saya berikan.
Pisahkan fakta yang tersedia, inferensi, dan gap.
Output harus berbentuk how-to guide untuk engineer on-call.
Jangan menambahkan endpoint, command, atau environment variable yang tidak muncul di konteks.
Jika informasi tidak cukup, tulis bagian "Unknowns".

5.5 AI Implementation

AI implementation berbeda dari AI usage. Di sini kita membangun sistem:

• Source ingestion.
• Chunking.
• Embedding/indexing.
• Retrieval.
• Prompt assembly.
• Generation.
• Validation.
• Review workflow.
• Publishing.
• Feedback loop.

Kita tidak akan terjebak pada satu vendor atau framework. Yang penting adalah arsitektur, invariant, dan failure mode.

5.6 Source Verification

AI-generated documentation hanya berguna jika bisa diverifikasi.

Kita akan memakai prinsip:

1. Setiap klaim teknis penting harus punya sumber.
2. Source harus punya tingkat otoritas.
3. Source yang stale harus kalah dari source yang lebih baru dan lebih dekat ke runtime.
4. Jika source bertentangan, dokumentasi harus menyatakan konflik, bukan memilih diam-diam.

Contoh hierarchy source:

5.7 Governance

Tanpa governance, AI documentation berubah menjadi knowledge landfill.

Governance menjawab:

• Siapa owner dokumen?
• Dokumen mana yang authoritative?
• Kapan dokumen dianggap stale?
• Siapa yang boleh approve AI-generated docs?
• Apa yang tidak boleh dimasukkan ke prompt?
• Apa yang tidak boleh dipublish?
• Bagaimana menangani conflict antara source?
• Bagaimana mengaudit perubahan dokumentasi?

5.8 Metrics and Feedback

Dokumentasi yang baik harus punya feedback loop.

Metrics yang berguna:

• Freshness: kapan terakhir diverifikasi terhadap source.
• Coverage: area sistem yang sudah terdokumentasi.
• Findability: apakah pembaca menemukan dokumen lewat search/nav.
• Task success: apakah pembaca berhasil menyelesaikan tugas.
• Review latency: berapa lama dokumen menunggu approval.
• Broken links: link internal/eksternal rusak.
• Stale examples: snippet tidak lagi valid.
• Search zero-result rate: query yang gagal menemukan jawaban.
• Incident recurrence: insiden berulang karena knowledge gap.

6. Maturity Model

Kita akan memakai maturity model berikut untuk menilai organisasi atau project.

Tujuan seri ini adalah membawa kita minimal ke Level 4 secara praktis, lalu memahami blueprint Level 5.

7. Documentation Control Plane

Dalam organisasi besar, dokumentasi bukan hanya halaman web. Ia adalah control plane untuk pengetahuan engineering.

Elemen penting:

1. Inputs: code, specs, ADR, incidents, runbooks, issues.
2. Transformations: generation, summarization, normalization, validation.
3. Controls: style guide, ownership, security policy, review gate.
4. Outputs: docs site, handbook, runbook, release notes, API portal.
5. Feedback: usage analytics, broken links, reader feedback, incident learnings.

AI bekerja di transformation layer, bukan sebagai replacement untuk control layer.

8. Batas AI: Drafting vs Ownership

Salah satu kesalahan umum adalah memperlakukan AI sebagai “penulis final”. Untuk sistem engineering, ini berbahaya.

Gunakan matriks berikut:

Rule of thumb:

Semakin tinggi dampak kesalahan dokumen, semakin kuat verification dan approval gate yang dibutuhkan.

9. Failure Modes Awal

Sebelum membangun skill, kita harus tahu bentuk kegagalannya.

10. Rubric Self-Correction

Kaufman menekankan belajar cukup untuk bisa mengoreksi diri. Ini rubric awal kita.

Gunakan skor 0–3.

Target minimal untuk dokumen yang masuk repository engineering: rata-rata 2, tidak ada dimensi kritikal bernilai 0.

Dimensi kritikal:

• Accuracy.
• Source traceability.
• Security.
• Ownership.
• Actionability untuk runbook/how-to.

11. 20-Hour Practice Plan

Ini adalah rencana latihan awal, bukan seluruh seri.

Hour 1–2 — Skill Setup and Baseline

Output:

• Pilih satu service/project nyata.
• Kumpulkan artefak: README, API spec, ADR, incident/runbook, PR terakhir.
• Audit dokumentasi saat ini memakai rubric.
• Catat 10 masalah paling mahal.

Latihan:

Ambil satu README internal.
Nilai dengan rubric 0–3.
Tulis gap berdasarkan audience: new engineer, on-call engineer, API consumer, reviewer.

Hour 3–5 — Information Architecture

Output:

• Pisahkan konten menjadi tutorial, how-to, reference, dan explanation.
• Buat navigation map.
• Tandai duplikasi dan stale sections.

Latihan:

Ambil README yang campur aduk.
Pecah menjadi 4 dokumen:
1. Getting started tutorial
2. Local development how-to
3. Configuration reference
4. Architecture explanation

Hour 6–8 — AI-Assisted Drafting

Output:

• Buat prompt template untuk rewrite docs.
• Buat draft how-to guide dari source yang diberikan.
• Tandai fakta, asumsi, unknowns.

Latihan:

Berikan AI hanya source terbatas: README + config sample.
Minta AI membuat runbook.
Validasi setiap command dan environment variable.

Hour 9–11 — Source Verification

Output:

• Buat source hierarchy.
• Tambahkan citation/source links.
• Identifikasi konflik antara docs dan code/spec.

Latihan:

Bandingkan dokumen API dengan OpenAPI spec.
Tandai endpoint, status code, field, dan contoh response yang berbeda.

Hour 12–14 — Docs-as-Code Quality Gate

Output:

• Tambahkan markdown lint.
• Tambahkan link checker.
• Tambahkan style checklist.
• Tambahkan CODEOWNERS atau owner metadata.

Latihan:

Buat pipeline minimal:
- lint markdown
- check links
- validate frontmatter
- fail CI jika owner kosong

Hour 15–17 — AI Review Workflow

Output:

• Buat AI reviewer prompt.
• Buat review checklist untuk manusia.
• Bandingkan hasil review AI dan reviewer manusia.

Latihan:

Minta AI mereview dokumen berdasarkan rubric.
Tolak semua komentar AI yang tidak punya bukti.
Ubah komentar valid menjadi issue/PR task.

Hour 18–20 — Capstone Mini

Output:

• Satu documentation improvement PR end-to-end.
• Before/after diff.
• Quality score sebelum/sesudah.
• Dokumentasi publishable.

Latihan:

Pilih satu area dokumentasi yang paling mahal jika salah.
Refactor ke struktur Diátaxis.
Tambahkan source verification.
Tambahkan quality gate.
Buat changelog dan reviewer checklist.

12. Working Agreement untuk Seri Ini

Agar seri tetap efisien dan tidak mengulang materi lain, kita pakai batasan berikut:

1. Kita tidak membahas ulang Java internals, API design, event governance, persistence, atau security implementation kecuali dari sisi dokumentasi.
2. Kita tidak menganggap AI output benar tanpa source.
3. Kita tidak membuat template kosong tanpa mental model.
4. Kita tidak mengejar “dokumen lengkap” jika dokumen tidak usable.
5. Kita memprioritaskan workflow yang bisa diterapkan di engineering team nyata.
6. Kita menulis seperti internal handbook: jelas, tegas, operasional, dan bisa direview.
7. Setiap part akan punya checklist, latihan, dan failure modes bila relevan.

13. Minimal Toolchain yang Akan Dipakai Sepanjang Seri

Toolchain dapat berubah sesuai organisasi, tetapi mental modelnya stabil.

Tool tidak penting jika prinsipnya salah. Tool yang bagus di atas proses yang buruk hanya menghasilkan dokumentasi buruk lebih cepat.

14. Checklist Part 001

Sebelum lanjut ke Part 002, pastikan Anda bisa menjawab:

• Apa perbedaan AI-assisted documentation dan AI-owned documentation?
• Apa source of truth untuk dokumentasi teknis?
• Apa empat kategori Diátaxis dan kapan dipakai?
• Apa maturity level dokumentasi project Anda sekarang?
• Apa tiga failure mode paling berbahaya untuk dokumentasi AI di organisasi Anda?
• Apa rubric minimum untuk menilai dokumen engineering?
• Apa output konkret dari 20 jam latihan pertama?

15. Latihan Praktis

Pilih satu repository atau service nyata. Jangan pilih project mainan.

Buat tabel berikut:

Kemudian lakukan:

1. Nilai setiap dokumen dengan rubric 0–3.
2. Tandai dokumen yang AI boleh bantu draft.
3. Tandai dokumen yang wajib human approval.
4. Pilih satu dokumen untuk diperbaiki pada latihan Part 002.

16. Ringkasan

AI-driven documentation adalah engineering capability, bukan sekadar kemampuan menulis prompt. Skill ini menggabungkan technical writing, information architecture, docs-as-code, AI usage, source verification, governance, dan metrics.

Framework Kaufman membantu kita menghindari over-researching. Kita pecah skill, buat rubric self-correction, hilangkan friction, lalu mulai praktik dari artefak engineering nyata.

Prinsip inti part ini:

Dokumentasi yang baik bukan hanya menjelaskan sistem. Dokumentasi yang baik mengurangi risiko, mempercepat keputusan, dan membuat knowledge bisa dipakai ulang oleh manusia maupun AI dengan aman.

References

1. Josh Kaufman, The First 20 Hours: How to Learn Anything... Fast; ringkasan metode rapid skill acquisition juga dijelaskan dalam WIRED UK, “How to learn a new skill in 20 hours”.
2. Diátaxis documentation framework: https://diataxis.fr/
3. Write the Docs, “Docs as Code”: https://www.writethedocs.org/guide/docs-as-code/
4. OpenAI, “Prompt engineering”: https://developers.openai.com/api/docs/guides/prompt-engineering