Mohammad Sani Suprayogi

Category: Teknologi

  • Claude Science: Solusi Riset Akademik atau Pabrik Paper Instan?

    Sebagai mantan dosen, ada kalanya saya melihat perkembangan teknologi hari ini dengan perasaan campur aduk: antara takjub dan sedikit “iri”.

    Beberapa waktu lalu, Anthropic resmi merilis Claude Science. Platform ini bukan sekadar chatbot biasa yang lihai merangkai kata. Ini adalah sebuah AI workbench yang terintegrasi langsung dengan lebih dari 60 basis data ilmiah global.

    Saya langsung melayang ke masa-masa ketika saya masih mengajar di kampus, membatin: “Seandainya tool ini sudah ada sejak saya masih jadi dosen, mungkin saya sudah menerbitkan buanyakkk paper bereputasi internasional.”

    Dulu, tantangan terbesar dosen bukan hanya menemukan ide, tetapi waktu yang habis untuk hal-hal administratif riset. Kita harus membuka puluhan tab jurnal, mencocokkan data secara manual, hingga menguji validitas formula yang memakan waktu berbulan-bulan.

    Claude Science memangkas semua waktu “administratif” itu secara brutal. Ia membebaskan peneliti untuk fokus pada esensi utama sains: berpikir kritis dan berinovasi.

    Namun…

    Teknologi bagaikan pisau bermata dua. Ketika Claude Science mulai diadopsi secara massal, ada celah moral yang sangat lebar di kalangan akademisi. Alih-alih digunakan sebagai research assistant untuk mempercepat analisis data, saya khawatir alat ini justru akan disalahgunakan menjadi mesin pembuat paper otomatis.

    Bayangkan skenario ini: seorang oknum akademisi yang dikejar tenggat waktu sertifikasi atau kenaikan pangkat, cukup memasukkan beberapa variabel data mentah, lalu membiarkan AI menulis seluruh isi jurnal dari abstrak hingga kesimpulan. Hanya dalam satu malam, sebuah “karya ilmiah” selesai.

    Sains berkembang karena manusia berani mempertanyakan fenomena, mengalami kegagalan di lab, dan melakukan perenungan mendalam. Jika proses “berpikir” itu sepenuhnya didelegasikan kepada Claude Science, maka kita tidak sedang melahirkan ilmuwan, melainkan operator komputer.

  • Sayonara Caveman

    Hari ini saya memutuskan untuk tidak lagi menggunakan Caveman skills di Claude Code karena tidak lagi mendapatkan manfaat yang berarti darinya. Dulu saya menginstall Caveman skill ini demi menghemat penggunaan token supaya saya bisa berinteraksi dengan Claude lebih lama.

    Kemudian saya ingat, dulu install karena masih subs Claude yang versi $20.

    Sekarang saya kan sudah pakai Claude Max, ngapain mikirin penghematan token?

    Rasanya seperti mencekik kemampuan Claude Opus 4.8

    Ini bercanda ya gaes, alasan sebenarnya karena respon yang saya dapatkan ketika menggunakan Caveman itu jadi aneh. Bagaimanapun juga, saya tetap perlu membaca respon dari Claude ketika memberikan prompt tertentu.

    Caveman melakukan tugasnya dengan baik, namun terkadang saya merasa kehilangan konteks ketika berinteraksi. Iya, saya tipe orang yang masih membaca semua respon LLM, sehingga ketika ada sesuatu yang disingkat, saya merasa sedikit kehilangan konteks dan khawatir mempengaruhi dalam pengambilan keputusan.

    Jadilah sekarang menggunakan Claude Code dengan mode penuh, tidak lagi dikurangi dengan Caveman skills.

  • Fable 5 Yang Berbeda

    Saya sempat mencoba Fable 5 selama beberapa hari sebelum Antrophic memutuskan untuk menutupnya sementara akibat permintaan pemerintah Amerika Serikat. Waktu itu saya terpesona dengan kemampuan Fable 5 untuk menyelesaikan masalah pelik (halah) yang sedang dihadapi.

    Fable 5 memberikan output yang membawa saya untuk bersama-sama memecahkan masalah. Tidak seperti Opus 4.8 yang berupaya langsung memecahkan masalah, Fable 5 saat itu mengajak saya untuk melacak permasalahannya secara perlahan namun terarah.

    Dia memberikan beberapa query untuk dicoba dan kami melakukan brainstorming selama beberapa menit. Singkatnya dalam waktu 20 menit solusi tersampaikan dan itu merupakan solusi yang solid.

    Tanggal 1 Juli 2026 lalu akhirnya Fable 5 kembali diaktifkan, saya penasaran apakah kemampuannya masih sama.

    Ternyata Fable 5 sudah berbeda.

    Tidak ada lagi upaya untuk memecahkan masalah bersama, dia hanya seperti Opus 4.8 yang sedikit lebih pintar dan boros.

    Mungkin ini hanya perasaan saya saja, setidaknya itu yang saya rasakan di hari ini.

    Mungkin besok bisa berubah.

  • Hemat Token LLM Dengan Caveman

    Sepertinya sekarang ini salah satu nilai tukar di Internet yang sedang hype adalah token LLM. Claude masih tercatat sebagai pemegang nilai tukar tertinggi bersama Claude Opus.

    Meminta Claude untuk mengurangi harganya sungguh tidak mungkin, sebab biaya research dan resource untuk menjalankan Opus pasti tidak murah, saya tidak tega untuk meminta penurunan harga ataupun diskon.

    Tapi apakah tidak ada yang bisa kita lakukan? Ternyata ada.

    Claude dan LLM lain memiliki 2 jenis token, yaitu input dan output yang memiliki harga berbeda. Namun ada lagi satu bentuk output yang suka membakar uang kita, yaitu respon LLM yang dibuat manusiawi.

    “Kamu benar, pemikiran yang tepat, pertanyaan bagus”, pasti sering dapat repson seperti itu kan? Rasanya seneng ya dipuji oleh AI?

    Padahal itu sebuah pemborosan token.

    Gimana kalau semua itu kita hapus, jadi kita hanya dapat respon yang dingin atau dry text seperti gebetanmu yang bertepuk sebelah tangan itu.

    Mari kita berterima kasih kepada Caveman.

    A Claude Code skill/plugin and Codex plugin that makes agent talk like caveman — cutting ~75% of output tokenswhile keeping full technical accuracy.

    Apakah benar akan bisa mengurangi 75%? saya yakin sih itu gimmick, tapi apapun yang bisa mengurangi kebocoran token dan membuat saya bisa berinteraksi lebih lama di satu sesi, maka itu sudah cukup.

  • Terkesan Dengan Claude Max

    Seharian ini saya mengoptimalkan Claude Max yang beberapa hari lalu saya langganan, saya minta dia untuk melakukan banyak hal sekaligus di berbagai platform, membantu saya memikirkan beberapa hal, dan memperbaiki beberapa bug.

    Singkatnya, saya terkesan.

    Saya menggunakan Opus 4.6 secara penuh hari ini, pengen tau seberapa pintar model ini dan seberapa cepat tokennya habis.

    Ternyata, Opus itu pinter banget dan Claude Max adalah pasangan yang tepat. Saya tidak mengalami kehabisan token seperti saat masih berlangganan Claude Pro, seakan-akan Anthropic ingin mengatakan kalau mau memaksimalkan potensi Claude itu gunakan Claude Max.

    Saya mengkoneksikan Claude di XCode untuk membaca codebase Swift untuk apps Lightio saya. Rasanya menyenangkan ketika bisa ngobrol dengan Claude langsung di GUI yang nyaman, hari ini beberapa bug langsung diberesin sama dia.

    Beberapa pekerjaan yang sudah dikerjakan kemarin, hari ini saya minta Opus untuk mereviewnya. Hasilnya ada beberapa potensi bug dan celah keamanan yang muncul kemudian sekaligus memberikan saran perbaikan, hari ini semuanya telah selesai diperbaiki.

    Bahkan saya juga memulai proyek kecil sebagai awal jalan saya menuju ke Cloud FinOps, yaitu membuat dashboard billing yang mengambil data dari berbagai cloud provider. Hasilnya hari ini sudah bisa membuat prototype dengan data yang sudah terhubung ke API masing-masing vendor.

    Ini adalah pekerjaan sehari yang biasanya perlu saya kerjakan 3 minggu.

    Apakah kita sebagai pekerja tech harus khawatir dengan keberadaan Claude? Tentunya! Jika kita tidak segera mengadopsi cara baru untuk bekerja, maka dalam waktu 2 tahun mendatang maka kita akan usang dan langsung tergantikan.

    Claude, Gemini, ChatGPT adalah sebuah disruptif di tahun ini. Jangan dilawan tapi berenanglah di sisinya, ubah cara pandang kita supaya tidak ketinggalan.

  • Berinvestasi Pada Claude Max

    Akhirnya setelah mempertimbangkan banyak hal, hari ini saya memutuskan untuk berinvestasi pada Claude Max dengan biaya langganan $100/bulan.

    Kenapa? sebetulnya lebih kepada kebutuhan pekerjaan saja sih, saya sedang memerlukan pair brainstorming yang cukup bisa mengimbangi imajinasi saya dan bisa mengeksekusinya dengan lebih akurat, sehingga saya bisa mengalihkan fokus saya ke hal-hal yang lebih strategis.

    Saya sudah mencoba Kimi dan GLM, keduanya memang bagus dan cukup menjanjikan, namun sekali lagi ini hanyalah masalah subjektifitas, Claude Sonnet masih lebih baik dan lebih gegas daripada keduanya.

    Setelah mencoba beberapa saat dan sekalian mengubah model dari Sonnet ke Opus, rasanya seperti masuk ke dunia baru.

    Ada beberapa bug yang sebelumnya susah dibetulin dengan Kimi dan GLM, bisa beres dengan mudah di tangan Opus.

    Memang agak lain..

    Selain itu, dengan memanfaatkan Claude Code dan VSCode saya sekalian install plugin superpowers dan caveman untuk menemani prosesnya. Nanti saya akan buatkan tulisan terpisah mengenai kedua plugin itu.

    Baiklah, mudah-mudahan ini investasi yang baik.

  • MCP Cocoindex Code Untuk Menghemat Token

    Akhir-akhir ini saya sedang banyak berinteraksi dengan Claude Code untuk membangun beberapa tools, akibatnya saya sering kehabisan token dan perlu menunggu beberapa saat supaya bisa menggunakannya lagi.

    Tapi apakah menunggu itu merupakan satu-satunya solusi? Ternyata ada cara lain yaitu menghemat konsumsi token saat kita berinteraksi dengan LLM.

    Seperti yang kita tahu, ketika meminta LLM untuk scanning codebase kita untuk mendapatkan konteks, maka dia akan membaca sebagian besar atau bahkan seluruh codebase untuk kemudian kembali memberikan jawaban. Tentunya ini sangat boros token dan berpotensi kehabisan sebelum sempat mengobrol atau memberikan instruksi.

    Singkat cerita, saya menemukan Cocoindex Code.

    A lightweight, effective (AST-based) semantic code search tool for your codebase. Built on CocoIndex — a Rust-based ultra performant data transformation engine. Use it from the CLI, or integrate with Claude, Codex, Cursor — any coding agent — via Skill or MCP.

    MCP Cocoindex Code Untuk Menghemat Token

    Kalau dari repositorinya, dia klaim bisa menghemat hingga 70% token, apakah benar? saya tidak menghitung secara pasti, tapi memang rasanya respon menjadi lebih cepat karena LLM tinggal menggunakan hasil indexing untuk mencari konteks.

    Saya install ini di Claude Code dan Cline sebagai MCP, sudah bisa index otomatis sehingga ketika ngobrol saya tinggal nyuruh LLM untuk menggunakan cocoindex.

    Hasilnya? LLM lebih cepat mendapatkan konteks dan bisa fokus dengan permintaan saya.

  • Menarik Data Billing Azure Enterprise Agreement (EA) secara Presisi

    Hari ini saya mempelajari hal baru dengan Azure API sewaktu menarik data billing guna keperluan cost monitoring. Saya tidak menyangka proses untuk bisa mendapatkan data billing itu cukup berliku, namun sekarang saya cukup paham bagaimana cara memprosesnya. Kayanya saya sudah bisa ambil sertifikasi FinOps ya haha.

    Berawal dari mengikuti dokumentasi dan tutorial yang menyebutkan saya harus memiliki beberapa key untuk bisa memanggil Azure API. Ini hal standar karena memang semua platform akan memiliki caranya sendiri untuk bisa menggunakan API mereka.

    Ketika skrip sudah berhasil dibuat, saya cukup senang karena berhasil mendapatkan data yang saya butuhkan. Tapiiii saya melihat kok nominal Cost itu bernilai 0. Saya pikir ada yang salah ketika mapping nama kolomnya, tapi setelah melakukan berbagai cara, angkanya tetap saja 0.

    Pasti ada yang salah.

    Benar saja, setelah berkelana ke beberapa tempat dan bertanya ke LLM, saya mendapatkan jawaban yaitu karena tipe akun kami di Azure itu Enterprise Agreement (EA).

    Secara default, melakukan query pada Subscription Scope di akun EA sering kali tidak memunculkan nominal biaya. Hal ini terjadi karena data finansial utama pada EA berada di level Billing Account, bukan di level langganan individu.

    Masalah kedua adalah Unauthorized (401). Meskipun Service Principal sudah dibuat, ia tidak secara otomatis memiliki “kunci” untuk masuk ke brankas billing perusahaan.

    Langkah-langkah yang saya tempuh hingga berhasil menyinkronkan data API dengan portal Azure:

    1. Berpindah ke Billing Account Scope. Dari awalnya menggunakan Subscription Scope, saya beralih menggunakan scope:
      /providers/Microsoft.Billing/billingAccounts/{billingAccountId}. Ini adalah source of truth untuk seluruh biaya di bawah kontrak EA.
    2. Karena Service Principal tidak memiliki akses ke level EA, saya melakukan assign role EnrollmentReader. Tip penting: Pemberian role ini membutuhkan waktu propagasi sekitar 10-15 menit. Kesabaran adalah kunci di sini!

    Hasilnya, sekarang saya sudah bisa mendapatkan data billing dari Azure secara akurat. Saya sudah bandingkan angkanya dengan nilai di Portal Azure juga sudah sesuai.

    Integrasi Azure Billing API pada level Enterprise memang menantang di sisi autentikasi dan scope. Namun, dengan konfigurasi yang tepat, kita bisa mendapatkan visibilitas biaya yang 100% akurat dan otomatis.

  • Memadukan DuckDB dan Python untuk Pivot Table

    Saya dapat saran dari beberapa kawan (thanks kang Zam dan mas Bernard) pada artikel memproses 600 ribu baris data kemarin untuk menggunakan library Pandas dan DuckDB supaya pemrosesan datanya lebih cepat dan efisien.

    Setelah melakukan riset beberapa saat, saya memutuskan untuk mencobanya meskipun baru dilakukan di branch untuk melihat hasilnya terlebih dulu sebelum merge ke master.

    Apa yang saya dapatkan?

    Hasilnya, DuckDB (dengan dikombinasikan dengan Pandas) ini membuat aplikasi saya bisa berjalan dengan lebih cepat. Saya memang tidak melakukan benchmark dengan detil ya, saya cuma membandingkan waktu pemrosesan saja, dimana untuk 600 ribu data ini sekarang bisa diproses 30 detik lebih cepat.

    Ini sangat bagus, karena 600 ribu data ini baru permulaan, nantinya akan bisa bertambah dan saya prediksi di akhir tahun nanti bisa tembus 4 juta baris. Tentunya kalau masih diproses dengan metode streaming aggregation akan membuat OOM lagi.

    Pertanyaan muncul: Haruskah semua logika dilakukan di dalam SQL (DuckDB), ataukah lebih baik menyerahkannya ke Python? Kasusnya sederhana: Saya harus memproses data transaksi (CSV), melakukan filter, agregasi, dan menyajikannya dalam bentuk Pivot Table (per bulan).

    Inilah alasan mengapa strategi “DuckDB untuk Heavy Lifting, Python untuk Reshaping” adalah pemenangnya.

    Saya membagi proses menjadi dua tahap kritis:

    1. Tahap Otot (DuckDB)

    Saya menyerahkan tugas berat ke DuckDB. Mengapa? Karena DuckDB adalah database columnar yang menggunakan eksekusi vektor (C++). Ia sangat cepat dalam memindai ribuan baris.

    • Tugas: Filter data (buang beberapa data yang tidak diperlukan) dan lakukan SUM(total_bill) dengan GROUP BY.
    • Hasil: Data mentah sebanyak 600 ribu baris dipangkas menjadi hanya ~100-500 baris data agregat.

    Sebelum data masuk ke DuckDB, ada satu optimasi lagi yang saya terapkan di level CSV parsing. Alih-alih menggunakan csv.reader bawaan Python lalu menyisipkan baris per baris dengan executemany(), saya menggunakan kombinasi Pandas + Apache Arrow protocol.

    Baca CSV dengan pandas, hanya kolom yang diperlukan

    df = pd.read_csv(
    buffer,
    usecols=[0, 5, 9, 10, 13, 16], # invoice_month, sku, total_bill, source, service_group, bill_org
    dtype=str,
    )

    Bulk insert via Arrow fast-path (zero-copy)

    conn.register("_temp_csv", df)
    conn.execute("INSERT INTO billing SELECT * FROM _temp_csv")

    Apa keuntungannya?

    1. Column Pruning — Dari 17 kolom di CSV, saya hanya membaca 6 kolom yang diperlukan. Kolom lain di-skip sejak awal, menghemat memori dan waktu parsing.
    2. Zero-Copy Transfer — DuckDB menerima DataFrame dari Pandas via Apache Arrow protocol tanpa menyalin data (zero-copy). Ini jauh lebih cepat dibanding executemany() yang melakukan iterasi Python-level untuk setiap baris.
    3. Vectorized Parsing — Parser CSV-nya Pandas ditulis dalam C/Cython, sehingga jauh lebih cepat dari csv.reader murni Python.

    Dengan kombinasi ini, pipeline dari “file CSV di Google Drive” hingga “siap di-query di DuckDB” menjadi sepenuhnya vektorisasi, tidak ada lagi Python-level loop di tahap loading.

    2. Tahap Otak/Fleksibilitas (Python)

    Setelah data menjadi kecil, saya menggunakan Python (defaultdict) untuk melakukan pivoting (mengubah baris menjadi kolom bulan).

    • Tugas: Mengatur ulang data dari bentuk (key, month, total) menjadi struktur {key: {month: total}}.

    Mungkin Anda bertanya, “DuckDB kan punya fungsi PIVOT, kenapa tidak dipakai saja?” Jawabannya adalah Dynamic Columns.

    1. Masalah Compile-Time: SQL PIVOT biasanya perlu tahu nama kolomnya dari awal (misal: Januari, Februari, dst). Jika bulan bertambah, kueri SQL harus diubah secara dinamis. Ini menambah kompleksitas kode (Dynamic SQL generation).
    2. Efisiensi Manusia vs Mesin: Menulis generator SQL yang kompleks hanya untuk menghemat beberapa milidetik pada data yang sudah kecil (~500 baris) tidaklah sebanding. Python jauh lebih fleksibel dalam menangani kunci (bulan) baru secara otomatis.
    3. Maintainability: Menggunakan defaultdict di Python jauh lebih mudah dibaca dan di-debug oleh rekan tim lain dibandingkan kueri SQL yang panjang dan penuh dengan fungsi EXECUTE.

    Kesimpulan: Menemukan “Sweet Spot“

    Analisis saya menyimpulkan bahwa pendekatan ini sudah optimal.

    • Kecepatan: Didapat dari DuckDB yang menghancurkan data besar.
    • Fleksibilitas: Didapat dari Python yang menyusun tampilan akhir tanpa peduli berapa banyak kolom bulan yang muncul.

    Pelajaran bagi kita: Jangan memaksakan satu alat untuk melakukan segalanya. Gunakan database untuk agregasi, dan gunakan bahasa pemrograman untuk formatting.