AI dalam Alur Kerja Data Scientist: Apa yang Perlu Diotomatisasi, Apa yang Jangan Pernah Disentuh

Pertama kali Copilot menghallusinasikan nama kolom pada saya, model tetap terlatih. Pull request melakukan join antara customer_id dengan kolom bernama customer_uuid yang tidak ada di tabel kanan. Pandas melakukan apa yang biasa ia lakukan: menghasilkan NaN untuk setiap baris secara diam-diam, tidak melempar error, dan join tersebut "berhasil." Model downstream tetap fit dengan baik. AUC validasi terlihat normal. Saya baru menyadarinya tiga hari kemudian hanya karena seorang pemangku kepentingan bertanya mengapa suatu kelompok tertentu menghilang dari output.

Tidak ada yang memperingatkan Anda tentang modus kegagalan tersebut. Pemasaran untuk data science berbantuan AI penuh dengan demo di mana model menulis pd.merge yang sempurna terhadap dataset mainan yang bersih. Modus kegagalan yang sebenarnya bersifat diam. Kode berjalan, hasil terlihat masuk akal, dan bug muncul setelah Anda sudah mempresentasikan chart-nya.

Jadi inilah garis yang saya tarik setelah sekitar delapan belas bulan menggunakan alat-alat ini setiap hari, ditulis untuk Data Scientist yang bekerja dan sudah lelah dengan hype maupun penolakan refleksif. Kedua ekstrem itu salah. Ada titik tengah yang membuat Anda merilis lebih cepat tanpa kualitas model yang menurun, dan panduan ini mencoba mendeskripsikannya secara konkret.

Mengapa ini penting sekarang (dan mengapa kebanyakan konten "AI dalam DS" membingungkan)

Ada dua hal yang sama sekali berbeda yang orang maksudkan ketika mereka berkata "AI dalam data science," dan mencampurkan keduanya menghasilkan saran yang tidak koheren.

Yang pertama adalah AI sebagai akselerator alur kerja untuk pekerjaan data science yang sudah ada: kode boilerplate, skrip EDA, docstrings, draf slide. Inilah yang dilakukan oleh Copilot di IDE Anda, Cursor, dan Claude. Pekerjaannya tetap membangun model dan menjelaskannya. AI adalah mesin tik yang lebih cepat.

Yang kedua adalah membangun aplikasi bertenaga LLM: sistem RAG, pipeline agen, harness evaluasi untuk output generatif. Ini adalah pekerjaan yang berbeda. Keterampilannya tumpang tindih (Anda masih membutuhkan statistik, Anda masih perlu memikirkan evaluasi), tetapi modus kegagalan, toolchain, dan pekerjaan sehari-hari berbeda dari melatih model XGBoost.

Ketika pimpinan berkata "tambahkan AI ke alur kerja Anda," mereka biasanya mengacu pada yang pertama. Ketika pimpinan berkata "bangun fitur AI," mereka biasanya mengacu pada yang kedua. Jika Anda tidak memisahkan keduanya, Anda akan menghabiskan satu kuartal mencoba menerapkan pola RAG pada masalah prediksi churn, atau lebih buruk lagi, Anda akan merilis chatbot menggunakan intuisi XGBoost dan bertanya-tanya mengapa evaluasi Anda tidak bekerja.

Sisa panduan ini sebagian besar tentang yang pertama. Ada bagian di dekat akhir tentang yang kedua.

Di mana AI benar-benar membantu (gunakan setiap hari)

Berikut adalah tempat-tempat di mana saya membiarkan AI menulis draf pertama setiap hari, dengan review ringan:

Kode boilerplate. Reshape Pandas yang sudah saya tulis ratusan kali: pivot, melt, rangkaian groupby. Scaffolding Pipeline dan ColumnTransformer dari sklearn. Grid subplot Matplotlib. Hal-hal mekanis di mana strukturnya tetap dan hanya nama kolomnya yang berubah. Cursor atau Copilot akan mendapatkan ini dengan benar 90% dari waktu, dan 10% yang salah mudah dikenali karena Anda sudah tahu seperti apa output yang seharusnya.

Skrip EDA. Plot distribusi pass pertama, hitungan null, heatmap korelasi, value counts pada setiap kategorikal. Fase "beri saya gambaran bentuk dataset ini". AI bagus dalam ini karena polanya bersifat formulaik dan outputnya visual, sehingga Anda akan melihat jika ada yang tampak aneh. Saya tetap menulis EDA pass kedua sendiri, karena di situlah pemikiran sebenarnya terjadi.

Docstrings dan type hints. Ketika Anda sudah mengetahui apa yang dilakukan fungsi tersebut dan Anda hanya perlu mendokumentasikannya. Sorot fungsinya, beri prompt "tulis docstring bergaya numpy dengan contoh," dan review. Menghemat dua puluh menit per modul pada codebase nyata.

Draf slide dan ringkasan untuk pemangku kepentingan. Hanya draf pertama. Saya menulis paragraf poin-poin tentang apa yang dilakukan model dan apa hasilnya, kemudian meminta Claude mengubahnya menjadi tiga slide untuk audiens non-ML. Kemudian saya menulis ulang sekitar 60% darinya. Draf pertama adalah bagian yang membosankan: struktur, transisi, pengulangan untuk penekanan. Penulisan ulang adalah tempat saya menambahkan bagian yang benar-benar penting.

Ringkasan tinjauan literatur. Saya memasukkan lima abstrak makalah dan bertanya "mana dari ini yang relevan untuk memprediksi churn pelanggan dari data event-stream, dan apa metode inti dari masing-masing?" Outputnya adalah daftar triase. Kemudian saya membaca makalah yang benar-benar perlu dibaca. Ini adalah peringkasan, bukan interpretasi, dan berhasil karena dapat diverifikasi. Jika ringkasannya mengatakan makalah ke-3 menggunakan transformer, saya bisa mengeceknya.

Polanya di semua tempat ini: AI bagus pada bagian-bagian di mana Anda sudah tahu seperti apa "benar" itu, sehingga Anda bisa menemukan kesalahan. Ini adalah akselerator pengetikan, bukan pengganti pemikiran.

Di mana AI gagal (jangan pernah didelegasikan)

Berikut adalah bagian-bagian yang tidak akan saya biarkan disentuh AI, dan saya akan menjelaskan alasannya untuk masing-masing:

Inferensi kausal. Confounder, selection bias, strategi identifikasi, pertanyaan apakah koefisien regresi berarti sesuatu yang kausal. LLM dengan senang hati akan menulis model propensity score untuk pertanyaan yang membutuhkan desain difference-in-differences. Mereka tidak mengetahui proses pembangkit data Anda. Mereka tidak tahu variabel mana yang bersifat post-treatment. Mereka tidak tahu bahwa "kelompok kontrol" Anda dipilih berdasarkan outcome. Klaim kausal yang salah namun meyakinkan lebih buruk daripada tidak ada klaim sama sekali, dan AI sangat mahir dalam hal ini.

Keputusan pemodelan. Algoritma mana yang digunakan, fungsi loss mana, skema validasi mana, bagaimana menangani kebocoran data. Ini adalah keputusan penilaian yang bergantung pada konteks bisnis, bentuk data, dan tujuan model. Copilot akan menyarankan random forest untuk segalanya karena random forest paling sering muncul dalam data pelatihan. Ia tidak tahu bahwa masalah Anda memiliki temporal leakage yang merusak setiap skema validasi silang kecuali yang forward-chaining. Anda harus membuat keputusan ini sendiri.

Interpretasi fitur. Apa arti nilai SHAP dalam konteks bisnis ini. AI bisa menghasilkan plot SHAP. Ia bisa mendeskripsikan apa itu nilai SHAP secara abstrak. Ia tidak bisa memberi tahu Anda apakah "tenure memiliki nilai SHAP yang tinggi" berarti tenure penting secara kausal atau hanya bahwa tenure menjadi proxy untuk sesuatu yang tidak Anda ukur. Itu memerlukan pengetahuan tentang bisnis.

Framing bisnis. Menerjemahkan "model mengatakan probabilitas churn adalah 0,73 untuk segmen ini" menjadi "kita harus mengubah jadwal renewal untuk akun di atas $50 ribu." Itu adalah terjemahan pengambilan keputusan, dan salah mengartikannya adalah cara data science kehilangan kredibilitas. LLM tidak tahu apa toleransi risiko perusahaan Anda. Ia tidak tahu pemangku kepentingan mana yang skeptis terhadap pekerjaan data dan membutuhkan bukti tambahan. Ia tidak tahu bahwa terakhir kali Anda mengusulkan intervensi serupa, itu gagal.

Singkatnya: AI baik untuk apa. Jangan pernah menggunakannya untuk mengapa atau apa artinya.

Stack tooling yang benar-benar bekerja

Setelah mencoba sebagian besar dari mereka, inilah stack yang saya gunakan untuk Data Scientist yang bekerja di tahun 2026:

Cursor untuk kode. Ini adalah VS Code dengan integrasi LLM yang lebih baik. Fitur Composer (di mana Anda mendeskripsikan perubahan multi-file dan membiarkannya mengusulkan editan) benar-benar berguna untuk refactoring alur fitur di tiga file. Saya menjaga autocomplete tetap aktif untuk boilerplate dan mematikannya ketika saya memikirkan logika. Pergantian mode itu penting.

Claude (atau setara) untuk code review. Sebelum saya membuka PR, saya menempelkan diff ke Claude dengan prompt seperti: "Tinjau ini untuk kebenaran, bukan gaya. Fokus pada: referensi kolom, kesalahan off-by-one, kebocoran data, API yang sudah deprecated, dan kasus edge pada penanganan null." Ini menangkap masalah. Tidak selalu, tetapi cukup sering sehingga saya tetap melakukannya. Ini adalah sepasang mata kedua yang tersedia pukul 11 malam sebelum deadline.

AI bawaan notebook (Hex Magic, Deepnote AI) dengan tali pendek. Ini bagus untuk pass EDA: "tampilkan distribusi setiap kolom numerik" atau "temukan korelasi di atas 0,7." Saya tidak membiarkan mereka menulis analisis akhir. Tali pendeknya adalah aturan bahwa apa pun yang mereka hasilkan dijalankan ulang dalam notebook yang bersih sebelum meninggalkan laptop saya, dan saya membaca setiap baris SQL yang dihasilkan. Kenyamanannya nyata, kepercayaannya terbatas.

Alasan sepasang alat lebih baik dari satu alat: masing-masing memiliki blind spot yang berbeda. Cursor bagus pada konteks lokal (file yang sedang Anda kerjakan) tetapi buruk dalam memahami seperti apa data Anda sebenarnya. Claude bagus dalam penalaran tingkat tinggi ("apakah ini masuk akal?") tetapi tidak memiliki konteks IDE Anda. Alat notebook bagus untuk melihat data dengan cepat tetapi cenderung menulis kode sekali pakai. Anda menginginkan alat yang berbeda untuk pekerjaan yang berbeda, bukan satu alat yang mencoba melakukan ketiganya dengan buruk.

Perangkap "LLM menulis analisis"

Ini adalah kegagalan yang paling sering saya lihat pada DS junior dan menengah, dan semakin sering pada DS senior yang seharusnya lebih tahu.

Polanya: Anda menyelesaikan pemodelan, Anda memiliki tabel hasil, Anda menempelkannya ke ChatGPT, dan Anda meminta "rangkum temuan utama." Ia menulis narasi yang meyakinkan, jelas, dan terstruktur dengan baik. Anda mengeditnya sedikit, menempelkannya ke laporan, dan merilis.

Masalahnya adalah LLM melakukan pencocokan pola terhadap seperti apa kesimpulan data science biasanya, bukan terhadap apa yang data Anda sebenarnya tunjukkan. Ia akan mengatakan hal-hal seperti "model menunjukkan performa prediktif yang kuat, dengan tingkat penting fitur yang menunjukkan bahwa keterlibatan pelanggan adalah pendorong utama." Kalimat itu benar secara struktural dan mungkin sepenuhnya salah. Model tersebut mungkin berkinerja baik hanya pada fitur yang bocor. "Keterlibatan pelanggan" mungkin memiliki tingkat kepentingan tinggi hanya karena merupakan duplikat hampir dari target.

Ini adalah padanan modern dari p-hacking. P-hacking adalah tentang menemukan cerita yang cocok dengan data melalui pencarian yang cukup. Perangkap analisis LLM adalah tentang mendapatkan cerita yang ditulis untuk data tanpa memeriksa apakah itu benar. Ceritanya masuk akal, prosa bersih, dan klaim yang mendasarinya salah.

Cara mengetahui apakah Anda terjebak: jika Anda tidak bisa, baris per baris, menunjuk ke angka spesifik dalam hasil yang mendukung setiap kalimat dalam ringkasan, Anda terjebak dalam perangkap tersebut. Perbaikannya adalah menulis analisis sendiri, kemudian meminta LLM untuk mengedit untuk kejelasan. Mengedit draf yang Anda tulis pada dasarnya berbeda dari menghasilkan draf dari angka-angka, meskipun jumlah kata akhirnya sama.

AI untuk ML vs membangun aplikasi LLM

Klarifikasi singkat karena ini terus membingungkan percakapan tim.

Seorang Data Scientist yang menggunakan Copilot untuk membangun model churn sedang melakukan ML klasik dengan IDE berbantuan AI. Modelnya adalah XGBoost atau neural network. Evaluasinya adalah AUC, kalibrasi, dampak bisnis. Penerapannya adalah pekerjaan penilaian batch atau API real-time. Modus kegagalannya adalah kebocoran data, penyimpangan model, dan miscalibration.

Seorang Data Scientist yang membangun sistem RAG atau agen LLM sedang melakukan sesuatu yang berbeda. "Model"-nya adalah foundation model yang tidak Anda latih. Evaluasinya kualitatif atau berbasis LLM-judge, bukan AUC. Penerapannya adalah layanan dengan template prompt, indeks retrieval, dan guardrail. Modus kegagalannya adalah hallusinasi, prompt injection, dan biaya yang melonjak.

Keduanya adalah pekerjaan yang sah. Keduanya bisa ada di meja Data Scientist. Tetapi keduanya bukan keterampilan yang sama, dan DS senior yang hebat dalam yang pertama mungkin biasa-biasa saja dalam yang kedua sampai mereka berlatih. Ketika pimpinan berkata "tambahkan AI ke produk," tanya mereka yang mana yang mereka maksud. Jika mereka tidak tahu, itulah percakapan pertama, bukan tugas coding.

Penandaan ACE Framework opsional

Jika tim Anda menggunakan ACE Framework (Ingest, Analyze, Predict, Generate, Execute), sebagian besar pekerjaan DS klasik berada di Analyze dan Predict. Membangun aplikasi LLM berada di Generate. Ini bukan hanya kosakata. Ini adalah cara untuk mendorong balik ketika lingkup meluas. Ketika seorang PM meminta "bisakah Anda menambahkan fitur AI generatif ke model churn," Anda bisa berkata: "model churn adalah kemampuan Predict; apa yang Anda deskripsikan adalah kemampuan Generate, yang merupakan sistem berbeda dengan evaluasi berbeda. Mari kita lingkup keduanya secara terpisah." Framework memberikan Anda kata-kata untuk batasan yang sudah Anda ketahui ada.

Rencana adopsi 30 hari

Inilah rencana yang akan saya jalankan jika saya memulai dari awal, atau saat onboarding DS junior ke pekerjaan berbantuan AI:

Minggu 1: Boilerplate dan docstrings saja. Instal Cursor dan buat akun Claude. Gunakan keduanya hanya untuk penyelesaian kode pada tugas mekanis (reshape pandas, pipeline sklearn) dan untuk menulis docstrings pada fungsi yang sudah Anda tulis. Buat catatan (hanya file teks) setiap kali saran tersebut salah. Pada akhir minggu, Anda harus memiliki sekitar 20 contoh modus kegagalan spesifik untuk codebase Anda. Ini adalah data kalibrasi. Ini memberi tahu Anda kapan harus mempercayai alat dan kapan mengabaikannya.

Minggu 2: Tambahkan bantuan EDA. Pilih satu proyek yang sudah selesai di mana Anda sudah tahu apa yang seharusnya ditunjukkan oleh EDA. Jalankan ulang pass EDA menggunakan bantuan AI dan bandingkan dengan pekerjaan Anda sebelumnya. Catat secara spesifik apa yang AI lewatkan (ia sering melewatkan hal kontekstual, seperti "variabel ini tampak normal tetapi sebenarnya merupakan kebocoran dari masa depan") dan apa yang ia tangkap lebih cepat dari yang Anda lakukan. Pada akhir minggu, Anda harus memiliki aturan tertulis kapan EDA berbantuan AI berguna dan kapan tidak.

Minggu 3: Loop code review. Untuk setiap PR yang Anda buka, tempelkan diff ke Claude terlebih dahulu dengan prompt code review. Catat: berapa banyak PR yang mendapat komentar berguna dari Claude? Berapa banyak bug yang ditangkap Claude yang akan dilewatkan oleh reviewer tim Anda? Berapa banyak false positive? Setelah seminggu Anda akan memiliki gambaran apakah loop ini layak dipertahankan. Bagi saya, iya, tetapi kalibrasinya berbeda per tim.

Minggu 4: Tulis dokumen "di mana kita menggunakan AI / di mana kita tidak" untuk tim Anda. Satu halaman. Daftarkan tugas-tugas di mana AI adalah alat default. Daftarkan tugas-tugas di mana AI dilarang. Daftarkan tugas-tugas di mana AI diizinkan tetapi setiap output mendapat review manusia sebelum digabungkan. Dapatkan persetujuan dari manajer Anda. Tujuan menuliskannya adalah memaksakan percakapan, yang memunculkan ketidaksetujuan yang tidak Anda ketahui ada.

Kesalahan umum

Daftar singkat, diurutkan berdasarkan seberapa sering saya melihatnya meledak dalam produksi:

Mempercayai nama kolom yang dihalusinasikan. Selalu periksa bahwa kolom yang direferensikan dalam kode yang dihasilkan AI ada dalam dataframe. df.columns.tolist() adalah teman Anda.
Menerima rekomendasi model tanpa pendapat kedua. Jika Copilot mengatakan "gunakan random forest di sini," tanya diri Anda mengapa, dan tanya Claude secara terpisah untuk mengkritik pilihan itu. Ketidaksetujuan adalah informasi.
Membiarkan AI menulis ringkasan eksekutif. Sudah dibahas. Jangan.
Menggunakan LLM untuk klaim kausal. Mereka akan memberi Anda jawaban yang meyakinkan. Jawabannya tidak berkorelasi dengan kebenaran.
Melupakan bahwa context window prompt memotong dataframe Anda. Jika Anda menempelkan sampel 50 baris dan bertanya "apakah ada pola outlier," LLM hanya melihat 50 baris. Ia tidak akan mengetahui tentang ekor panjang. Saran yang diberikannya akan salah untuk data penuh.
Menggunakan prompt yang sama di berbagai proyek tanpa penyesuaian ulang. Codebase Anda memiliki konvensi. Prompt code review generik tidak menangkap pola spesifik tim Anda.

Template dan alat

Kit starter yang bekerja:

File aturan Cursor untuk pekerjaan DS. Memberi tahu Cursor tentang konvensi tim Anda: versi sklearn mana yang Anda gunakan, bahwa Anda menggunakan Polars bukan pandas (atau sebaliknya), bahwa semua fitur membutuhkan komentar kebocoran.
Template prompt code review Claude. "Tinjau diff ini untuk: kebenaran referensi kolom, kebocoran data, API yang sudah deprecated, kasus edge pada null, dan konsistensi dengan sisa codebase. Jangan berkomentar tentang gaya."
Kebijakan penggunaan AI satu halaman. Dokumen Google satu halaman literal yang disetujui tim Anda. Tiga kolom: tugas, AI diizinkan?, review diperlukan? Pasang di channel tim Anda.
Daftar periksa verifikasi EDA. Ketika AI menghasilkan EDA, periksa: apakah ia menghitung null dengan benar? Apakah ia menangkap kategorikal dengan 10.000 nilai unik? Apakah ia memperhatikan kolom tanggal dengan masalah timezone? Jika ia melewatkan salah satu dari ini, sisa outputnya patut dicurigai.

Mengukur apakah ini berhasil

Tiga sinyal, diurutkan berdasarkan kepentingan:

Waktu hingga model pertama pada dataset baru turun secara terukur. Jika DS junior biasanya membutuhkan tiga hari untuk mencapai model dasar dan sekarang hanya membutuhkan satu, itulah kemenangan yang Anda cari. Jika waktunya tidak turun, Anda sebenarnya tidak menggunakan AI untuk bagian-bagian di mana ia membantu.
Komentar review PR tentang "kolom salah" atau "API deprecated" turun ke nol. Ini adalah bug yang mudah. Jika masih muncul, loop code review di Minggu 3 tidak menangkapnya.
Tim memiliki kebijakan tertulis dan merujuknya. Bukan hanya dokumen yang ada, tetapi dokumen yang dikutip dalam PR dan design review. "Kita tidak menggunakan AI untuk ini karena bagian 3 dari kebijakan" adalah penanda bahwa batasan itu nyata.

Sinyal negatif yang lebih penting dari semua ini: tidak ada orang di tim yang pernah merilis analisis buatan LLM sebagai pekerjaan mereka sendiri. Jika itu pernah terjadi, dan pada akhirnya akan terjadi, Anda tidak memiliki masalah kebijakan AI, Anda memiliki masalah kredibilitas, dan perbaikannya adalah percakapan, bukan perubahan alat.

Garis antara "AI membantu saya merilis lebih cepat" dan "AI merilis analisis yang salah atas nama saya" lebih tipis dari yang disarankan pemasaran. Tarik garis tersebut secara eksplisit, tuliskan, dan tinjau kembali setiap kuartal seiring alat-alat berubah.

Panduan Praktis Data Scientist