Penjelasan Terbaik tentang Kode Anda Terkubur dalam Log Obrolan

Anda menghabiskan empat puluh lima menit dengan Claude merancang sebuah retry circuit. Anda menjelaskan mode kegagalannya, menolak exponential backoff karena menyembunyikan tekanan berjenjang, memutuskan untuk menggunakan token-bucket rate limiting dengan jitter, dan menghasilkan implementasi yang berfungsi. Penjelasannya jelas, alasannya masuk akal, dan kodenya benar-benar lulus uji.

Lalu Anda menutup tab tersebut.

Dua minggu kemudian seorang rekan kerja bertanya mengapa logika retry menggunakan jitter alih-alih exponential backoff. Anda membuka sesi Claude baru dan merekonstruksi argumen tersebut dari ingatan. Penjelasan baru itu mirip, tetapi tidak identik. Anda telah menciptakan tradisi lisan kedua yang sedikit berbeda. Tidak satu pun dapat ditemukan melalui pencarian. Tidak satu pun dapat ditinjau dalam pull request. Keduanya akan hilang ketika Anda meninggalkan perusahaan.

Ini bukan masalah tooling. Ini adalah kesalahan kategori. Kita memperlakukan percakapan LLM sebagai scratchpad pribadi padahal sebenarnya itu adalah yang paling mendekati literate programming yang pernah dialami oleh kebanyakan engineer.

Apa yang Dimaksud Knuth, dan Mengapa LLM Secara Tidak Sengaja Menyediakannya

Donald Knuth mendefinisikan literate programming pada tahun 1984 sebagai aktivitas menulis program sebagai karya sastra. Kode dan dokumentasi dijalin bersama dalam satu narasi. Pembaca mengikuti penalaran penulis, melihat alternatif yang dipertimbangkan, dan memahami mengapa bentuk akhirnya ada.

Selama empat puluh tahun, literate programming tetap menjadi praktik khusus. Alat seperti WEB dan CWEB memerlukan disiplin. Sebagian besar pengembang menulis kode dalam satu file dan dokumen dalam file lain, dan keduanya segera berbeda.

Percakapan LLM adalah literate programming secara tidak sengaja. Anda menyatakan masalah dalam prosa. Model mengajukan pertanyaan klarifikasi. Anda memperhalus constraints. Model mengusulkan kode. Anda menolak usulan tersebut dan menjelaskan alasannya. Model merevisi. Artefak akhirnya bukan hanya blok kode. Melainkan seluruh thread: pendekatan yang dibuang, trade-off, asumsi domain.

Masalahnya adalah mediumnya bersifat fana. Antarmuka chat dirancang untuk penyelesaian tugas, bukan pelestarian pengetahuan. Setelah sesi berakhir, narasi tersebut membeku dalam ambar, tidak dapat dicari, tidak memiliki versi, dan dimiliki oleh vendor.

Mengapa Log Obrolan Mengalahkan Dokumentasi Tradisional untuk Keputusan Kompleks

Dokumentasi tradisional menggambarkan keadaan akhir. Itu menjawab “apa”. Log obrolan yang baik menjawab “mengapa”, yang merupakan pertanyaan yang lebih sulit dan yang paling cepat usang.

Pertimbangkan sebuah architecture decision record yang khas. Ia mungkin berkata: “Kami memilih PostgreSQL daripada DynamoDB untuk layanan inventori karena persyaratan konsistensi yang kuat.” Itu adalah kesimpulan. Ia tidak memberi tahu Anda apa pun tentang query yang terlalu lambat, lag replikasi yang masih dapat diterima, atau vendor lock-in yang diperdebatkan dan ditolak.

Sebuah thread Claude berisi semua itu. Ia berisi iterasi skema yang gagal, query plan yang mengejutkan Anda, dan momen ketika Anda menyadari bahwa composite index harus mencakup filter status. Itu adalah decision record dengan konteks lengkap.

Masalahnya adalah konteks tersebut terjebak dalam format percakapan. Menggulir melalui thread seratus turn untuk menemukan satu wawasan tentang desain index sangatlah menyakitkan. Pengetahuannya ada, tetapi tidak dapat diakses.

Tiga Mode Kegagalan Chat-as-Docs

Memperlakukan log obrolan mentah sebagai dokumentasi gagal dengan cara yang dapat diprediksi. Setiap mode kegagalan memiliki perbaikan, tetapi Anda harus melakukannya dengan sengaja.

Hallucination drift. Claude menemukan API, mengutip makalah yang tidak ada, dan dengan percaya diri mengusulkan desain yang mengabaikan constraints Anda yang sebenarnya. Log obrolan yang dilestarikan sebagai dokumentasi menyimpan hallucinations bersama dengan kebijaksanaan. Jika Anda tidak menandai bagian mana yang telah diverifikasi dan bagian mana yang spekulatif, pembaca berikutnya memperlakukan semuanya sebagai kebenaran mutlak.

Narrative sprawl. Percakapan yang baik berkelana. Anda menjelajahi jalan buntu, terganggu oleh edge case, dan kembali lagi. Kelanaan itu berharga untuk pemahaman, tetapi buruk untuk referensi. Seorang engineer baru yang membutuhkan retry policy tidak perlu membaca penyimpangan dua puluh menit ke TCP congestion control.

Vendor lock-in. Dokumentasi Anda berada dalam database Anthropic, di balik antarmuka pencarian mereka, tunduk pada kebijakan retensi mereka. Jika akun habis masa berlakunya atau antarmuka berubah, dokumen Anda menghilang. Dokumentasi yang tidak dapat Anda grep bukanlah dokumentasi.

Cara Mengekstrak Dokumen yang Tahan Lama dari Obrolan yang Fana

Solusinya adalah memperlakukan chat sebagai draf pertama, bukan artefak akhir. Anda mengekstrak, memverifikasi, dan menerbitkan. Alur kerjanya sederhana dan memakan waktu sekitar sepuluh menit untuk setiap keputusan yang signifikan.

Langkah satu: tandai turn-nya. Selama percakapan, tandai keputusan kuncinya. Saya menggunakan konvensi sederhana. Ketika Claude menghasilkan blok kode yang ingin saya simpan, saya membalas dengan KEEP: <alasan satu baris>. Ketika ia mengusulkan sesuatu yang saya tolak, saya membalas dengan REJECT: <alasan>. Tag ini membuat ekstraksi menjadi sepele.

Langkah dua: ekstrak ke markdown. Setelah sesi, salin thread ke file markdown dan hapus kebisingannya. Hapus sapaan, pengisi “biarkan saya berpikir”, dan turn di mana Anda berdua bingung. Pertahankan pernyataan masalah, alternatif yang dipertimbangkan, keputusan akhir, dan kode yang telah diverifikasi. Hasilnya harus dibaca seperti catatan teknis, bukan transkrip.

Berikut adalah skrip yang mengotomatiskan ekstraksi jika Anda menggunakan API Claude atau mengekspor percakapan Anda sebagai JSON:

#!/usr/bin/env python3
"""
Extract a readable technical note from a Claude conversation export.
Expects Anthropic's conversation JSON format.
"""

import json
import argparse
from pathlib import Path


def extract_note(conversation_path: Path, output_path: Path) -> None:
    with open(conversation_path) as f:
        data = json.load(f)

    turns = data.get("chat_messages", [])
    lines = []

    for turn in turns:
        sender = turn.get("sender", "unknown")
        text = turn.get("text", "").strip()

        if not text:
            continue

        # Skip pleasantries and meta-turns
        if any(phrase in text.lower() for phrase in [
            "hello", "how can i help", "you're welcome", "glad i could help"
        ]):
            continue

        if sender == "human":
            lines.append(f"**Q:** {text}\n")
        else:
            lines.append(f"**A:** {text}\n")

    with open(output_path, "w") as f:
        f.write("# Technical Note: Extracted from Claude Session\n\n")
        f.write("\n".join(lines))


if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("--input", type=Path, required=True)
    parser.add_argument("--output", type=Path, required=True)
    args = parser.parse_args()
    extract_note(args.input, args.output)

Langkah tiga: verifikasi setiap blok kode. Jalankan kode yang diekstrak. Jika tidak dikompilasi atau tidak lulus uji, perbaiki di markdown dan catat koreksinya. Dokumen yang diekstrak harus menjadi sumber kebenaran, bukan transkrip percakapan yang mungkin mengandung kesalahan.

Langkah empat: commit ke repository. Simpan markdown di docs/decisions/ atau docs/notes/ di samping kode yang dijelaskannya. Berikan nama file yang bermakna: retry-circuit-jitter-over-exponential.md, bukan claude-chat-july-19.md. Tambahkan ke pull request yang sama dengan perubahan kode, atau buat PR tindak lanjut segera. Jika dokumen tidak dalam kontrol versi, dokumen tersebut tidak ada.

Kapan Ini Berfungsi dan Kapan Tidak

Pendekatan ini unggul untuk keputusan yang kompleks dan ambigu di mana penalaran sama pentingnya dengan hasilnya. Desain circuit, strategi migration skema, kebijakan API versioning, dan trade-off kinerja semuanya adalah kandidat yang baik.

Ini tidak berfungsi untuk dokumentasi referensi. Log obrolan tentang cara mengautentikasi dengan API internal adalah pengganti yang buruk untuk spec OpenAPI terstruktur dan contoh cURL. Gunakan alat yang tepat untuk pekerjaannya.

Ini juga tidak berfungsi tanpa kurasi. Membuang log obrolan mentah ke wiki bukanlah dokumentasi. Itu adalah penimbunan. Sepuluh menit ekstraksi dan pengeditan tidak dapat dinegosiasikan. Jika Anda melewatkannya, Anda menghasilkan sampah yang dapat dicari.

Titik Awal yang Praktis

Anda tidak memerlukan alat baru. Anda memerlukan kebiasaan.

Lain kali Anda memiliki sesi yang panjang dan produktif dengan Claude tentang keputusan desain yang non-trivial, ekspor thread tersebut sebelum Anda menutup tab. Habiskan sepuluh menit untuk mengeditnya menjadi catatan markdown yang menjawab tiga pertanyaan: Masalah apa yang sedang kami selesaikan? Alternatif apa yang kami pertimbangkan dan tolak? Apa yang kami putuskan dan mengapa?

Commit catatan itu ke repo Anda. Tautkan dari komentar kode di atas fungsi yang dijelaskannya. Engineer berikutnya yang menyentuh kode itu akan berterima kasih, dan mereka tidak perlu membuka Claude untuk merekonstruksi penalaran Anda.

Obrolan Anda dengan Claude bisa menjadi dokumentasi. Ia hanya membutuhkan Anda untuk memperlakukannya seperti kode: diekstrak, diverifikasi, diberi versi, dan dipelihara.