17-5 · Bab 17 · 3 menit baca

Audit Output AI: Apa yang Sering Salah

Setelah opsi dipilih dan AI mulai bekerja, kita perlu mengaudit outputnya sebelum menerima. Langkah ini sering dilewati karena output AI terlihat rapi. Kodenya terstruktur, komentar ditulis dengan bai

17.5 Audit Output AI: Apa yang Sering Salah

Ada pola kesalahan yang berulang pada output AI. Pola pertama adalah asumsi tersembunyi. AI tidak bertanya ketika ragu. Ia memilih asumsi yang paling mungkin berdasarkan data latihnya. Contohnya, saat diminta membuat fungsi validasi email, AI bisa berasumsi bahwa validasi cukup dengan mengecek karakter @. Padahal di sistem yang sudah ada, validasi email harus memanggil API verifikasi eksternal. AI tidak tahu ini, dan ia tidak akan bertanya. Ia akan menghasilkan kode yang terlihat benar, tetapi tidak sesuai dengan konteks sistem.

Berikut contoh output AI yang mengandung tiga pola kesalahan sekaligus, untuk membantu Anda mengenali bentuk nyatanya:

# Permintaan: tambahkan validasi email di fungsi register_user

def register_user(email, password):
    # Asumsi tersembunyi: validasi email hanya dengan cek '@'
    if '@' not in email:
        return {'error': 'Email tidak valid'}

    # Perubahan terlalu luas: AI mengubah tabel 'users' dan 'profiles'
    db.execute("ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT FALSE")
    db.execute("ALTER TABLE profiles ADD COLUMN last_login TIMESTAMP")

    # Boundary salah: AI mengubah konfigurasi service B (di luar scope)
    config_service_b['rate_limit'] = 100

    # Hallucinated API: method 'send_verification' tidak ada di library versi 2.x
    email_service.send_verification(email)

    return {'status': 'ok'}

Pola kedua adalah perubahan terlalu luas. AI sering tidak bisa membedakan mana yang perlu diubah dan mana yang harus tetap. Misalnya, Anda meminta AI menambahkan satu field ke tabel user. Outputnya bisa berupa file migrasi database yang mengubah tiga tabel lain, menambahkan index yang tidak diminta, dan mengubah tipe data kolom yang sudah ada. Semua perubahan itu mungkin masuk akal secara teknis, tetapi tidak sesuai dengan brief. Perubahan yang terlalu luas berbahaya karena sulit dideteksi saat review cepat.

Pola ketiga adalah boundary salah. AI kadang melanggar batas yang sudah ditentukan di brief. Ini terjadi karena boundary tidak cukup eksplisit, atau AI menganggap batas itu terlalu restriktif. Contoh nyata: Anda meminta AI menambahkan logging ke service A, tetapi outputnya juga mengubah konfigurasi di service B karena AI menganggap itu "lebih baik". Tanpa audit, perubahan di service B bisa lolos dan menyebabkan regresi.

Pola keempat adalah hallucinated API, field, config, behavior, atau dependency. Ini paling berbahaya karena outputnya terlihat meyakinkan. AI bisa memanggil method yang tidak ada di library versi Anda. Bisa menambahkan field yang tidak terdefinisi di skema database. Bisa mengubah konfigurasi dengan key yang tidak dikenal. Bisa menambahkan dependency ke package yang sudah deprecated. Semua ini terjadi karena AI tidak menjalankan kode, ia hanya memprediksi teks yang paling mungkin.

Checklist audit praktis untuk menangkap pola-pola ini sederhana. Pertama, baca output AI seperti Anda membaca kode dari junior engineer yang tidak pernah bertanya. Kedua, bandingkan setiap perubahan dengan boundary di brief. Ketiga, cek apakah ada perubahan di file yang tidak disebut di scope. Keempat, verifikasi setiap API call, field name, dan config key terhadap dokumentasi resmi. Kelima, jalankan diff yang bersih: hanya apa yang diminta, tidak lebih.

Berikut diagram yang merangkum keempat pola kesalahan dan langkah audit yang sesuai:

flowchart TD A[Output AI] --> B{Pola Kesalahan?} B --> C[Asumsi Tersembunyi] B --> D[Perubahan Terlalu Luas] B --> E[Boundary Salah] B --> F[Hallucinated API/Field/Config] C --> G[Baca seperti kode junior tanpa konteks] D --> H[Bandingkan setiap perubahan dengan brief] E --> I[Cek file di luar scope] F --> J[Verifikasi API call & config key ke dokumentasi] G --> K[Audit Selesai] H --> K I --> K J --> K

Audit bukan berarti tidak percaya pada AI. Audit adalah bagian dari verification plan yang sudah ditentukan di brief. Semakin jelas brief-nya, semakin mudah auditnya. Dan semakin rajin audit dilakukan, semakin besar kepercayaan yang bisa diberikan ke AI di tugas berikutnya.

Setelah output lolos audit, langkah selanjutnya adalah memastikan evidence yang cukup sebelum perubahan itu diterima. Evidence inilah yang membedakan antara "sepertinya benar" dan "terbukti benar".