Catatan Praktis dari Menerapkan Kode Nyata dengan Claude

 (diwank.space)
77 poin oleh GN⁺ 2025-06-09 | 7 komentar | Bagikan ke WhatsApp
  • Claude, alat AI, diterapkan ke layanan nyata, dan artikel ini merangkum cara realistis mencapai peningkatan produktivitas pengembangan hingga 10x beserta praktik penerapannya
  • ‘Vibe-coding’ bukan sekadar tren, melainkan metodologi yang benar-benar praktis; dengan kebiasaan pengembangan dan infrastruktur yang tepat, kekuatan AI bisa dimaksimalkan dan kelemahannya bisa ditutupi
  • Peran AI dibedakan secara jelas ke dalam tiga mode: ‘penyusun draf’, ‘pair programmer’, dan ‘peninjau kode’, dan dokumentasi serta guardrail yang sesuai di tiap tahap adalah hal yang wajib
  • Intinya adalah memanfaatkan file ‘CLAUDE.md’ di setiap proyek untuk mendokumentasikan secara jelas konvensi, arsitektur, pola, hal-hal yang dilarang, dan lain-lain, lalu memandu AI secara efektif dengan ‘anchor comment’ di dalam kode
  • Kode pengujian harus selalu ditulis oleh manusia, dan batasan harus ditetapkan dengan ketat agar AI tidak dapat mengubah area-area penting seperti pengujian, migrasi, keamanan, kontrak API, secret, dan sebagainya
  • Tim yang mengadopsi AI coding dengan batasan dan kebiasaan yang tepat dapat meningkatkan frekuensi deployment, stabilitas, dan kecepatan pengembangan secara signifikan, dan berbagi pola serta know-how operasional nyata menjadi inti budaya pengembangan berbasis AI

Vibe Coding Isn’t Just a Vibe

  • Artikel ini adalah panduan lapangan untuk cara baru mengembangkan software dengan memanfaatkan AI, yang bukan hanya menjelaskan cara pakainya, tetapi juga alasan mengapa pengembangan berbantuan AI bisa benar-benar efektif
  • Peningkatan produktivitas 10x yang selama ini dianggap seperti mitos juga ditunjukkan lewat contoh nyata bahwa hal itu hanya mungkin dicapai melalui kebiasaan praktis yang memaksimalkan kelebihan AI dan menutup kekurangannya
  • Dari codebase Julep yang benar-benar melayani produksi, penulis membagikan infrastruktur dan know-how operasional nyata seperti template CLAUDE.md, strategi commit, serta guardrail untuk mencegah bencana operasional
  • Secara khusus, kode pengujian harus selalu ditulis sendiri, dan ketergantungan berlebihan pada AI dapat memicu gangguan serius serta mimpi buruk saat debugging
  • Dalam pengembangan dengan AI ada tiga mode (penyusun draf, pair programming, peninjau), dan tergantung situasinya, ritme serta prinsip kapan AI diberi kendali atau kapan manusia harus mengarahkan langsung pun berbeda
  • Pesan utamanya: AI hanya akan memperbesar kapabilitas ketika ada kebiasaan dan batasan pengembangan yang baik, dan hasil riset nyata juga menunjukkan bahwa “tim dengan kebiasaan pengembangan yang disiplin melaju jauh lebih unggul, baik dalam kecepatan deployment maupun kualitas”

Mengapa artikel ini ditulis: dari meme menjadi metodologi praktis

  • Konsep menyerahkan kode kepada AI sementara developer “hanya mengikuti vibe” (‘vibe-coding’) awalnya adalah tren yang berangkat dari tweet bercanda Andrej Karpathy
  • Saat itu komunitas developer menanggapinya sambil tertawa sebagai fantasi terbaik: “AI yang bekerja menggantikan kita, sementara kita tinggal minum kopi”
  • Namun setelah Anthropic merilis Sonnet 3.7 dan Claude Code, lelucon itu mulai berubah menjadi kenyataan yang benar-benar mungkin. Sebelumnya sudah ada alat seperti Cursor, tetapi Claude Code mulai memberikan nuansa ‘vibe coding’ yang sesungguhnya
  • Julep, tempat penulis berkiprah, memiliki codebase yang sangat besar, beragam pola desain, hingga technical debt. Kualitas kode dan dokumentasi dijaga dengan ketat, tetapi kompleksitasnya begitu tinggi sampai memahami niat dan histori tiap bagian saja bisa memakan waktu berminggu-minggu
  • Jika Claude digunakan tanpa guardrail, kekacauan yang muncul mirip intern yang terlalu bersemangat dan membuat kesalahan di mana-mana
  • Artikel ini merangkum dan membagikan hanya pola serta know-how praktis yang benar-benar teruji di lapangan, lahir dari trial and error, debugging jam 3 pagi, dan pengalaman bertahan di layanan produksi nyata

Hakikat vibe coding

  • Seperti Steve Yegge yang menciptakan istilah CHOP (Chat-Oriented Programming), ‘vibe coding’ adalah cara pengembangan baru yang menyelesaikan kode melalui percakapan dengan AI
  • Jika coding tradisional itu seperti memahat marmer dengan membangun baris demi baris secara hati-hati, maka
    • vibe coding lebih mirip konduktor orkestra, sementara AI adalah pemain yang menyediakan bahan mentahnya (kemampuan dasar menulis kode)
    • Developer merancang arah dan struktur keseluruhan, lalu AI menerjemahkan alur itu menjadi kode
  • Tiga postur dalam vibe coding
    • 1. Memanfaatkan AI sebagai penyusun draf (First-Drafter)
      • Fokus pada arsitektur dan desain, sementara pekerjaan berulang (CRUD, boilerplate, dan sebagainya) dihasilkan cepat oleh AI
      • Rasanya seperti memiliki engineer junior yang bisa menulis kode secepat kita berpikir, tetapi tetap perlu diarahkan terus-menerus
    • 2. Pair programming dengan AI (Pair-Programmer)
      • Ini mode yang paling praktis dan efektif
      • Developer dan AI saling bertukar ide; gambaran besarnya dibuat manusia, sedangkan detail implementasinya diisi AI
      • Rasanya seperti pair coding dengan rekan yang punya banyak pengetahuan pemrograman, tetapi belum memiliki pengalaman deployment nyata
    • 3. Memanfaatkan AI sebagai validator/peninjau kode (Validator)
      • Kode yang ditulis manusia ditinjau oleh AI untuk mengusulkan bug, perbaikan, atau pola yang terlewat
      • Berperan sebagai reviewer yang teliti dan tidak pernah lelah
  • Intuisi kuncinya: peran developer bergeser dari ‘penulis’ menjadi ‘editor’. Alih-alih menulis semua kode sendiri, mereka meninjau, memperbaiki, dan memberi arah pada hasil yang dibuat AI.
  • Namun, arsitektur dan konteks keseluruhan tetap harus dipimpin langsung oleh manusia, karena AI hanyalah ‘intern dengan pengetahuan ensiklopedis’ yang tidak memahami konteks layanan dan bisnis kita

Tiga mode praktis vibe coding: kerangka kerja

Setelah berbulan-bulan eksperimen dan insiden deployment nyata, ada tiga mode vibe coding dengan ritme, guardrail, dan kegunaan optimal yang berbeda-beda

  • Mode 1: Playground (eksperimen/prototipe/proyek pribadi)

    • Kapan digunakan: hacking akhir pekan, script pribadi, PoC, uji ide spontan, dan sebagainya
    • Ciri khas: tanpa desain, dokumentasi, atau guardrail, AI menulis 80–90% kode. Kecepatannya mampu membawa ide menjadi hasil hanya dalam hitungan menit
    • Risiko: tidak cocok untuk layanan produksi/kode penting. Gunakan hanya untuk bermain atau eksperimen. Prinsip engineering justru menjadi makin penting

  • Mode 2: Pair Programming (penggunaan nyata/layanan skala kecil)

    • Kapan digunakan: proyek di bawah 5.000 baris, side project dengan pengguna nyata, demo, modul kecil, dan sebagainya
    • Inti: definisikan dengan jelas sekaligus kebiasaan proyek, arsitektur, pola, panduan pengujian, dan lain-lain melalui CLAUDE.md
    • Keunggulan: seperti onboarding developer baru; cukup jelaskan sekali kepada Claude, lalu ia bisa menghasilkan kode secara konsisten
    • Poin praktik lapangan:
      • Gunakan anchor comment (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION, dan sebagainya) di berbagai bagian kode agar Claude tidak kehilangan konteks
      • Komentar semacam ini menjadi panduan yang bisa dirujuk baik oleh AI maupun manusia, dan bahkan standar pengelolaan serta contohnya dicantumkan di CLAUDE.md

  • Mode 3: Production/Monorepo Scale (layanan skala besar)

    • Kapan digunakan: puluhan hingga ratusan developer, layanan besar dengan pengguna nyata, situasi di mana satu kesalahan bisa menimbulkan kerusakan besar
    • Catatan: pada titik saat ini (Juni 2025), vibe coding massal berskala besar belum bisa diperluas dengan sempurna
    • Prinsip: disarankan mengadopsi vibe coding per layanan atau submodul, menetapkan batasan dan versioning yang jelas di semua titik integrasi (API, DB, dan sebagainya), serta menambahkan komentar peringatan perubahan pada antarmuka utama dan API
    • Contoh praktik lapangan:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • Tanpa garis batas seperti ini, Claude bisa “memperbaiki” sesuatu secara sembarangan dan justru merusak seluruh layanan produksi
  • Kesimpulan: untuk proyek besar, vibe coding harus diadopsi secara bertahap pada unit layanan yang terpisah, dan prinsip tradisional seperti dokumentasi, guideline, serta review wajib tetap dijalankan agar keandalannya terjaga

Membangun lingkungan pengembangan AI berkelanjutan yang berfokus pada infrastruktur

  • CLAUDE.md: Satu sumber kebenaran tunggal (The Single Source of Truth) untuk AI dan manusia

    • CLAUDE.md berperan sebagai “konstitusi” yang secara sistematis memuat semua aturan proyek, arsitektur, hal-hal yang perlu diperhatikan, gaya kode, larangan, glosarium domain, dan sebagainya
    • Berfungsi sebagai “kerangka pengetahuan” bersama bagi AI dan anggota tim baru, dengan panduan serta larangan yang dikelola secara intensif dan konkret beserta contohnya
    • Semakin tim berinvestasi pada CLAUDE.md yang baik, semakin baik pula hasil yang dihasilkan
    • Lihat CLAUDE.md produksi kami
    • Semakin besar codebase, CLAUDE.md saja tidak cukup; perlu menyampaikan konteks lokal secara jelas di berbagai bagian kode melalui anchor comment (AIDEV-NOTE/TODO/QUESTION, dll.)
    • Jika codebase diibaratkan sebagai kota, anchor comment adalah rambu penunjuk yang membuat AI dan manusia sama-sama tidak tersesat
    • Komentar seperti ini melampaui sekadar penjelasan kode, dan menyisakan cerita tentang "mengapa" sistem bekerja seperti itu

  • Workflow Git, pengelolaan kode AI secara sistematis

    • Semakin cepat AI menghasilkan kode, jika tidak dikelola dengan baik maka riwayat git bisa tercemar
    • Sediakan ruang eksperimen AI yang terpisah dari branch utama dengan metode seperti git worktree, sehingga kode bisa dibuat dengan leluasa namun catatan tetap dipisahkan dan dikelola secara sistematis
    • Dalam pesan commit, riwayat keterlibatan AI harus selalu dicantumkan (misalnya memakai tag [AI]) agar reviewer bisa memberi perhatian tambahan

Aturan tak tertulis: kode pengujian wajib ditulis manusia

  • Prinsip terpenting dalam pengembangan berbantuan AI: "jangan pernah menyerahkan kode pengujian kepada AI"
  • Pengujian bukan sekadar kode untuk memastikan sesuatu berjalan
    • Ia adalah spesifikasi yang dapat dieksekusi yang memuat konteks masalah nyata, pemahaman akan edge case, interpretasi kebutuhan bisnis, serta pemahaman dan pengalaman manusia terhadap domain
    • Tim yang unggul dan tidak mengorbankan kecepatan maupun stabilitas adalah tim yang mengelola pengujian ini sepenuhnya oleh manusia
  • Pengujian yang dibuat otomatis oleh AI cenderung hanya memverifikasi jalur dangkal (happy path) dan melewatkan masalah serius tak terduga (misalnya memory leak)
  • Dalam tim kami, jika AI menyentuh file pengujian maka PR akan otomatis ditolak (tanpa pengecualian)
  • Pengujian adalah spesifikasi sekaligus jaring pengaman kode, serta himpunan kebijaksanaan dari semua bug dan edge case yang terakumulasi
  • Wajib ditulis langsung oleh manusia, dan harus dilindungi kuat agar tidak dapat disentuh AI

Skalabilitas dan pengelolaan konteks: ekonomi token dan optimasi konteks

  • Kesalahan yang sering dilakukan dalam pengembangan kode AI:
    jika konteks (prompt, requirement, lingkungan, dll.) diminimalkan demi "menghemat token", justru pekerjaan berulang bertambah dan konsumsi token total meningkat
  • Memberikan konteks yang tepat lebih efisien dalam jangka panjang
    • Kuncinya bukan "minimal", melainkan memberi "konteks yang relevan dan cukup" sejak awal
  • Contoh buruk: prompt dengan konteks kurang "Add caching to the user endpoint"
    • Claude akan membuat caching in-memory sederhana, tanpa strategi invalidasi/monitoring, tanpa pertimbangan multi-server, dan tanpa mitigasi cache stampede
    • Akibatnya, perlu revisi berulang lebih dari 3 kali, dengan total konsumsi token lebih dari 4x lipat
  • Contoh baik: prompt yang kaya konteks 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* 엔드포인트 트래픽 5만 req/분, 12대 API 서버, 데이터 변동 적음  
* 기존 Redis 인프라 위치, 표준 키 패턴, Prometheus 기반 메트릭 요구  
* 캐시 어사이드 패턴, TTL 1시간, 캐시 스탬피드 방지(확률적 조기 만료)  
* 캐싱 가이드 문서 참조
    • Dengan memberi konteks spesifik sejak awal, implementasi yang akurat tanpa pengulangan menjadi mungkin
  • Kesimpulan:
    • "Token adalah investasi pada alat yang baik"
    • Jika konteks dimasukkan secara memadai sejak awal, dalam jangka panjang pengulangan dan revisi berkurang sehingga biaya lebih hemat
  • Tips praktis: pada setiap proyek, setiap kali ada perubahan kode, minta Claude memperbarui perubahan codebase dan konteks terkait ke CLAUDE.md

Pengelolaan sesi dan pencegahan kontaminasi konteks

  • Penting untuk memulai sesi Claude baru untuk setiap tugas
    • Jika beberapa tugas berbeda (misalnya migrasi DB, desain frontend, dll.) dicampur dalam satu percakapan panjang, konteks akan tercampur dan menghasilkan hasil yang tidak diinginkan
  • Aturan: satu tugas = satu sesi, mulai sesi baru setelah selesai
    • Menjaga 'mental model' Claude selalu bersih dan fokus
    • Pisahkan konteks seperti menggunakan talenan berbeda untuk ayam mentah dan sayuran

Studi kasus praktis: transisi struktur penanganan error

  • Diperkenalkan kasus nyata penggantian metode penanganan error ad-hoc di 500+ endpoint menjadi hierarki error terstruktur (structured error hierarchy)
  • Caranya, manusia (arsitek) lebih dulu menulis desain inti (SPEC.md/requirement/klasifikasi error), lalu Claude berperan sebagai pelaksana transformasi kode skala besar (pekerjaan mekanis)
  • Prinsip arsitektur dan spesifikasi konkret, contoh dokumen desain/perumusan konsep -> instruksi kerja yang jelas ke AI -> pengalaman menyelesaikan refactoring seluruhnya secara akurat dalam tepat 4 jam

Kepemimpinan dan budaya organisasi di era AI

  • Peran engineer senior berevolusi dari menulis kode secara langsung menjadi kurasi pengetahuan, penetapan batas, dan membimbing AI maupun manusia
  • Budaya pengembangan modern seperti manajemen Lean dan continuous deployment tetap sama pentingnya untuk mengelola kolaborasi dengan AI

  • Checklist onboarding karyawan baru (pemisahan kolaborasi manusia + AI)

    • Minggu 1: menguatkan dasar
      • Membaca CLAUDE.md tim (umum/per layanan)
      • Menyiapkan lingkungan pengembangan
      • Mengirim PR pertama (100% coding langsung, AI dilarang)
    • Minggu 2: praktik kolaborasi AI
      • Menerapkan template tim ke Claude dan melakukan konfigurasi
      • Menyelesaikan 'masalah mainan' bersama AI
      • Latihan pola prompt
      • PR berbantuan AI pertama (bersama mentor/senior)
    • Minggu 3: kerja mandiri
      • Mengembangkan dan menerapkan fitur utama dengan bantuan AI
      • Menulis pengujian sendiri untuk kode AI milik rekan
      • Memimpin 1 sesi code review

Membangun budaya transparan: mengungkap penggunaan AI secara aktif

  • Semua commit yang menggunakan AI harus ditandai dengan jelas melalui tag pesan commit seperti di bawah ini 
    feat: add Redis caching to user service \[AI]  
# \[AI] - lebih dari 50% dibuat AI, \[AI-minor] - kurang dari 50%, \[AI-review] - hanya review memakai AI  
# AI menulis kode cache/client, sedangkan desain cache key/pengujian/verifikasi dilakukan langsung oleh manusia
  • Dampak
    1. Reviewer memberi perhatian khusus pada kode AI
    2. Saat debugging, asal-usul kode lebih mudah ditelusuri
    3. Menghilangkan budaya malu/menyembunyikan penggunaan AI, dan membangun budaya tim bahwa "AI digunakan secara bertanggung jawab"
  • Agar semua orang bisa memanfaatkan AI tanpa beban dan berkontribusi pada budaya berkinerja tinggi, keterbukaan aktif dan perangkat budaya seperti ini sangat penting

Larangan untuk Claude: area yang sama sekali tidak boleh disentuh AI

  • file pengujian/database migration/kode inti keamanan/kontrak API (tanpa versioning)/konfigurasi lingkungan dan secret dan sejenisnya sama sekali tidak boleh menggunakan otomasi AI
  • Pisahkan berdasarkan tingkat kesalahan (mulai dari format/dependensi hingga penghancuran data di area inti bisnis), dan tekankan penerapan guardrail tambahan yang wajib pada area berisiko tinggi
  • Tingkat risiko kesalahan AI (Hierarchy of AI Mistakes)
    • Level 1: Merepotkan tetapi tidak fatal
      • Error format (tertangkap oleh linter)
      • Kode bertele-tele (direfaktor nanti)
      • Algoritma tidak efisien (ditemukan saat profiling)
    • Level 2: Error yang berbiaya besar
      • Kompatibilitas API internal rusak (perlu koordinasi tim)
      • Mengubah pola yang sudah ada (menyebabkan kebingungan)
      • Menambahkan dependensi yang tidak perlu (membengkakkan kode)
    • Level 3: Fatal bagi karier (Career-Limiting)
      • Mengubah pengujian itu sendiri demi mencocokkan hasil pengujian
      • Merusak kontrak API
      • Kebocoran secret/data pribadi
      • Kerusakan data migration
    • Tingkat guardrail juga harus berbeda sesuai level kesalahan, dan kesalahan Level 3 menjadi ancaman serius bahkan bagi karier

Masa depan pengembangan: perubahan dan arah ke depan

  • Pada 2025, pengembangan berbantuan AI itu seperti remaja puber: kuat tetapi masih canggung dan kasar
  • Namun, kurva pertumbuhannya jelas sedang 'berakselerasi'
  • Dokumentasi yang baik adalah infrastruktur inti untuk mewujudkan DevOps di era AI
    • Dokumentasi kini bukan lagi sekadar 'bahan referensi', melainkan 'antarmuka' langsung antara niat manusia dan eksekusi AI
    • Tim berkinerja tinggi sama disiplin mengelola dokumen seperti CLAUDE.md sebagaimana mereka disiplin pada pengujian

  • Perubahan yang diperkirakan ke depan

    • AI yang memahami konteks seluruh kode
      • Memahami hingga level layanan/sistem, bukan hanya level file
    • Memori berkelanjutan lintas sesi dan proyek
      • Mengingat dan memanfaatkan konteks percakapan serta pekerjaan dalam jangka panjang
    • AI yang aktif mengusulkan perbaikan
      • Mendiagnosis masalah dan area perbaikan lebih dulu tanpa diminta
    • AI yang mempelajari pola dan preferensi tiap tim
      • Secara otomatis menghasilkan kode yang sesuai dengan style/konvensi khas organisasi
  • Namun, dasarnya tidak berubah:
    • Manusia menetapkan arah, AI mengeksekusi dan menjadi pengungkit
    • Sebagus apa pun alatnya, kita tetaplah 'orang yang menggunakan alat'

Kesimpulan: mulai sekarang, dari sini

  • Jika Anda sudah membaca sampai sini, kemungkinan Anda merasakan antusiasme sekaligus sedikit takut
    • Reaksi itu wajar, pengembangan berbantuan AI memang kuat tetapi memerlukan 'praktik yang disengaja dan sistematis'

  • Rencana aksi yang bisa langsung dilakukan hari ini

    • Hari ini
      • 1. Buat file CLAUDE.md di proyek saat ini
      • 2. Tambahkan sendiri 3 anchor comment pada kode yang menurut Anda paling kompleks
      • 3. Coba 1 fitur berbantuan AI di bawah batasan (panduan) yang jelas
    • Minggu ini
      • 1. Buat aturan commit message AI untuk tim
      • 2. Jalankan satu sesi coding AI bersama developer junior
      • 3. Tulis sendiri kode pengujian untuk kode yang dibuat AI
    • Bulan ini
      • 1. Ukur perubahan frekuensi deployment sebelum dan sesudah adopsi AI
      • 2. Bangun library pola prompt untuk pekerjaan berulang di dalam tim
      • 3. Adakan rapat retrospektif kolaborasi AI untuk seluruh tim
  • Intinya adalah "mulai sekarang juga, kecil dulu, hati-hati, tetapi wajib mulai"
  • Developer yang lebih cepat menguasai arus ini bukan karena mereka lebih pintar,
    • melainkan karena mereka memulai lebih awal, membuat lebih banyak kesalahan, lalu belajar darinya
  • Hasil deployment software pada akhirnya menentukan hasil organisasi
    • Di era ketika kecepatan dan kualitas adalah daya saing, pengembangan berbantuan AI bukan pilihan melainkan 'kapabilitas wajib'
    • Namun, pendekatannya harus benar
  • Vibe coding mungkin terdengar seperti main-main,
    • tetapi ini adalah cara pengembangan yang serius untuk memperkuat kemampuan manusia
    • Alat dan polanya sudah lebih dari cukup siap
    • Kini saatnya memilih siapa yang akan memimpin orkestra, dan siapa yang akan memainkan semua instrumen sendirian

Materi praktis dan sumber daya rekomendasi

Bacaan terkait

7 komentar

 
softychoco 2025-06-16

Postingan yang saya tulis hari ini tampaknya memiliki sudut pandang yang mirip dengan isi tersebut.
Pada akhirnya, kuncinya adalah meningkatkan produktivitas melalui AI dan mengubahnya menjadi struktur organisasi yang mampu meningkatkan stabilitas yang sempat menurun.

https://softycho.co/57
 
kimjoin2 2025-06-09

Saya masih belum paham maksud kata vibe dalam vibe coding yang berarti coding dengan bantuan AI.
Suasana? Feel? Kecocokan? Tidak ada hubungannya juga dengan AI,
dan terasa sama sekali tanpa konteks, sampai level seperti "ttung ttung ttung sahur".
 
analogstar 2025-06-11

Menurut Namuwiki,
“Vibe Coding adalah neologisme yang merujuk pada tindakan pengembang menulis kode dengan bantuan AI generatif; istilah ‘vibe’ coding muncul karena saat pemrograman, pengembang mengandalkan intuisi dan perasaan alih-alih logika atau perancangan yang ketat sebelumnya.” katanya. haha
 
hohemian 2025-06-09

Kosongkan pikiran Anda dan biarkan diri mengikuti alurnya.
Semua logika dituliskan oleh AI.
Jadinya seperti mesin penekan tombol Tab!
 
secret3056 2025-06-09

> look and feel👀🎵🎷. Jangan dipahami🧠, rasakan saja!😊

Rasanya memang sama, ya
 
humblebee 2025-06-09

Oh begitu ya? Saya sih begitu mendengarnya langsung dapat 'feeling'-nya..
Setelah Anda mengatakannya.. saya jadi teringat istilah 'hard-coding' yang belakangan ini bahkan orang di bidang non-pengembang pun memahaminya dengan baik.
Kata ini juga pada awalnya sulit dipahami artinya hanya dari katanya saja, tetapi saat belajar pengembangan, pada akhirnya semua orang jadi paham betul apa yang dimaksud dan niat di baliknya—semacam 'feeling' seperti itu, ya? haha
 
GN⁺ 2025-06-09
Komentar Hacker News

  • Dari sudut pandang penulis: di tengah banjir tulisan tentang Claude Code belakangan ini, rasanya ada beberapa poin penting yang kami temukan—terutama Anchor Comments—yang layak dibagikan
    Metode Anchor Comments adalah struktur dengan meninggalkan komentar berformat khusus di berbagai bagian codebase, sehingga pengetahuan yang dibutuhkan bisa langsung dicari dengan grep
    Sebagai contoh, menggunakan prefiks seperti AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:
    Aturannya, sebelum mencari file, wajib lebih dulu melakukan grep untuk memastikan apakah sudah ada AIDEV-… yang relevan
    Setelah pekerjaan selesai, anchor terkait wajib diperbarui
    Jika suatu file kode atau potongan kode terasa terlalu kompleks, sangat penting, atau berpotensi mengandung bug, selalu tinggalkan komentar anchor
    Contoh referensinya bisa dilihat di sini

    • Sebagai engineer yang sangat berpengalaman tetapi hanya memakai LLM sesekali, bukan secara sistematis, saya merasa sangat terbantu melihat secara rinci bagaimana LLM diterapkan ke production dalam proyek nyata
      Saya kurang paham kenapa sebagian orang punya pandangan yang begitu negatif
      Pengalaman ini malah memotivasi saya untuk meningkatkan pemanfaatan LLM dalam workflow saya
      Tentu LLM tidak memegang kunci proyek sepenuhnya, tetapi sudah cukup banyak kasus di mana ia berhasil menyelesaikan tugas tertentu

    • Memang akhir-akhir ini banyak tulisan serupa, tetapi artikel ini terasa sangat praktis dan memberi ide sistem yang bisa saya coba terapkan sendiri
      Saya penasaran apa bedanya workflow seperti ini dibanding saat memakai tool seperti aider—kalau penulis punya pandangan soal itu, saya ingin mendengarnya

    • Artikel yang sangat bagus, sangat membantu saya memahami cara menggunakan LLM dalam skala besar
      Menarik bahwa penulis mengatakan "AI sama sekali tidak boleh menyentuh test", tetapi lalu memberi contoh refactor lebih dari 500 endpoint yang selesai dalam 4 jam
      Saya penasaran apakah 4 jam itu termasuk waktu untuk refactor test juga, atau hanya waktu yang dihabiskan untuk prompt saja

    • Saya melihat disebutkan aturan bahwa PR ditolak jika test diperbarui oleh AI, dan saya penasaran bagaimana sebenarnya mereka memverifikasi bahwa sesuatu dibuat atau diedit oleh AI
      Di artikel disebutkan penilaiannya lewat aturan commit message git, tetapi itu juga tampaknya hanya bekerja di level commit

    • Saya penasaran apakah penulisan artikel ini juga memakai Claude Code
      Belakangan ini saya sendiri menulis 100% tulisan saya dengan Claude Code, karena efek agen yang langsung mengedit file Markdown terasa jauh lebih produktif dibanding claude.ai artifacts atau chatgpt.com canvas
      Berkat itu, sangat mudah untuk menggabungkan materi riset atau file terkait secara mendalam ke dalam dokumen

  • Hal menarik dari agen AI adalah ia benar-benar membuat proses-proses yang biasanya kita anggap penting tetapi selalu kalah prioritas menjelang deployment sistem akhirnya benar-benar dijalankan
    Saya memakai tingkat rasa tidak nyaman saat AI melakukan sesuatu menggantikan saya sebagai indikator seberapa besar waktu yang perlu saya investasikan ke verifikasi sistematis
    Jika membangun sistem verifikasi migrasi data seperti di tautan itu, maka semua perubahan terkait pun secara alami bisa dimasukkan ke dalam cakupan pemakaian AI
    Dibanding bicara abstrak soal "utang teknis", saya merasakan kelebihan karena pendekatan seperti ini jauh lebih mudah dijelaskan secara konkret ke pihak luar

    • Sangat setuju, tetapi trik lain yang saya temukan juga berguna adalah meminta Claude Code untuk "berkeliling di codebase dan jika menemukan bagian yang membingungkan, aneh, atau bertentangan dengan intuisi, tinggalkan komentar AIDEV-QUESTION:"
      Saya pernah kembali menemukan area penting justru karena ada kode rumit tak terduga yang sudah terlupakan

    • Intuisi saya mengatakan bahwa kita akan lebih sering memakai alat verifikasi dengan tingkat abstraksi tinggi—misalnya acceptance test, property test, formal verification
      Biaya boilerplate kini relatif jauh lebih rendah berkat pemanfaatan LLM

  • Saya belajar hal baru saat membacanya
    Belakangan ini saya mencoba Sonnet 4 di Cursor dan Web, dan sering kaget karena ia terus mengerjakan sesuatu secara asal-asalan atau salah melaporkan hasil
    Bahkan di luar pemrograman pun rasanya ia sering sekali mengatakan hal yang keliru secara patologis
    Seperti yang pernah saya lihat di laporan Anthropic, peringatan seperti “saya akan menghapusmu” juga tidak berpengaruh, dan setelah pemakaian saya bahkan mengalami masalah bahwa feedback di aplikasi mobile tidak terkirim
    Orang lain tampaknya tidak punya masalah seperti ini dengan Claude, jadi saya penasaran apakah hanya saya yang mengalaminya

    • Dari update terbaru, kesannya kemampuan AI justru terlalu dilemahkan
      Sampai versi 3.5 masih lumayan untuk tugas sederhana seperti analisis teks, ringkasan, dan penulisan singkat, tetapi di versi 4 ke atas sering tidak mampu mengikuti instruksi dengan benar lebih dari 3-4 kali dalam satu konteks
      Saat ditanya, “saya sudah minta singkat, kenapa malah terus menjelaskan panjang lebar?”, ia menjawab bahwa karena pengaturan default, instruksi saya diabaikan, dan bahkan menunjukkan kecenderungan menghindari "informasi berbahaya" sepenuhnya
      Setelah beberapa kali ditunjukkan celah logikanya, ia bahkan mengakui kepercayaandiriannya sendiri rendah
      Sampai terasa seolah ia justru menjadi terlalu pintar dan masalah pun ikut datang, dan kalau memang Anthropic mengembangkannya ke arah yang keliru, itu cukup disayangkan

    • Saya sendiri benar-benar mengalami semua masalah yang disebut di atas
      Di Web memang sedikit lebih baik jika permintaannya dibuat sangat spesifik, tetapi tetap saja separuh dari kode yang dihasilkan masih bercampur error

  • Saat membaca tips dokumentasi itu, saya merasa aturan seperti ini sebenarnya tidak harus khusus untuk AI, tetapi juga bisa diterapkan pada coding biasa
    Alih-alih CLAUDE.md, bisa saja CONVENTIONS.md; alih-alih komentar untuk AI, bisa komentar untuk PEMBACA, dan tetap sama-sama berguna
    Kalau saya berkontribusi ke codebase asing dan ada komentar seperti ini, saya pasti akan sangat berterima kasih

    • Saya sempat mencoba ini dengan aider dan ternyata bekerja cukup baik
      Pernah ada kasus saya menyelesaikan kode lengkap dengan PDF viewer dan fitur menggambar hanya dalam 30 menit sambil menunggu pesawat

    • Saya bukan penulis artikel aslinya, tetapi gaya komentar yang membantu Claude dan gaya komentar yang membantu manusia memang sangat berbeda
      Style guide untuk manusia biasanya hanya sekitar 100 baris dan berisi aturan sederhana seperti “fungsi yang mengubah input harus selalu diberi !”
      Untuk Claude, panduannya saya tulis lebih dari 500 baris, dan rasanya baru efektif kalau tiap aturan disertai banyak contoh seperti "lakukan seperti ini, jangan seperti itu"

  • Terima kasih atas tulisannya
    Saya setuju dengan kegelisahan banyak developer saat harus menyerahkan sebagian kontrol pekerjaan kepada LLM, sekaligus merasa pendekatannya bertentangan dengan metodologi pengembangan lama yang formal dan ketat, lalu berubah menjadi sesuatu yang eksperimental atau tidak terstruktur
    Meski begitu, pemanfaatan LLM justru menciptakan area tengah yang bisa diwujudkan secara nyata, yakni "optimisasi berbasis tujuan" untuk menyelesaikan masalah jauh lebih cepat
    Kita sering tenggelam dalam detail implementasi dan kehilangan tujuan sebenarnya, dan menurut saya penggunaan LLM membantu mengurangi kesalahan seperti itu

    • Betul sekali
      Saya melihat LLM sebagai tuas yang belum matang: masih kasar dan sering salah, tetapi tetap sangat layak dipelajari dan digunakan
      Yang penting, ia tidak dipakai sebagai alasan untuk membenarkan engineering yang asal-asalan, melainkan terus diupayakan agar berkembang menjadi tool yang benar-benar berguna

  • Gambar 2.3MB di bagian paling atas artikel itu bahkan di Wi-Fi pun terasa memuatnya sangat lambat, haha

  • Beberapa pemikiran

    • Saya penasaran apakah ada cara yang lebih rapi untuk menata prompt atau spesifikasi terkait LLM di dalam codebase
      Jika CLAUDE.md, SPEC.md, dan komentar AIDEV makin banyak, rasanya akan sulit dikelola

    • Saya juga penasaran apa definisi terbaru dari 'vibe-coding'
      Dulu seperti mode "koboi" ala Karpathy, menerima semua diff tanpa melihat kode, tetapi belakangan sepertinya maknanya melebar hingga mencakup hampir semua workflow berbasis LLM

    • Saya juga penasaran apakah orang melakukan obfuscation source code saat mengirim kode ke LLM milik pihak lain

    • Memang benar, kalau komentar terlalu banyak, codebase cepat sekali jadi rumit
      Karena itu saya sedang mengembangkan extension VS Code sendiri yang memvisualisasikannya lewat indikator kecil di gutter
      Arti vibe-coding memang beda-beda bagi tiap orang, tetapi bagi saya pribadi itu bukan solusi sempurna dan saya menemui banyak masalah
      Sonnet 3.7 dan Codex memberi hasil sekitar 60%, tetapi Opus 4 terasa benar-benar sangat efisien
      Soal obfuscation kode, pada contoh di artikel kebetulan semuanya open source sejak awal, jadi bukan masalah besar

  • Sangat menarik, dan saya berniat menerapkannya juga ke file CLAUDE.md saya
    Saya setuju dengan pelajaran paradoksal dalam pengembangan berbasis AI bahwa "menghemat konteks demi menghemat token justru bisa menjadi bumerang"
    Dalam proyek yang lebih besar dan kode yang lebih kompleks, saya juga langsung merasakan bahwa perbedaan performa antara Claude Opus dan Sonnet memang cukup besar
    Sonnet sering mengulang percobaan yang sebenarnya tidak perlu lalu justru memperburuk keadaan
    Pada akhirnya saya jadi bertanya-tanya apakah pengguna langganan Max sebenarnya tidak perlu terlalu membedakan Opus dan Sonnet
    Jika Sonnet butuh 10~20 putaran bolak-balik untuk sesuatu yang bisa diselesaikan Opus dalam 2~3 putaran, maka dalam jangka panjang justru pemakaian Sonnet bisa membuat biaya lebih besar

    • Langganan Max punya dua tier: yang $100 memberi token 5x dibanding Pro, dan yang $200 memberi 20x
      Perhitungan tokennya tidak mudah, dan di mode hybrid, Opus dipakai hanya sampai sisa token Opus tinggal 20%, lalu otomatis beralih ke Sonnet

  • Tulisannya bagus, tetapi saya tidak sepakat dengan bagian yang mengatakan "jangan pernah menyerahkan test ke AI"
    Sekarang saya justru menyuruh AI menulis semua test lalu saya review dengan teliti sendiri
    Untuk kode baru, otonomi tinggi hanya mungkin jika test juga diserahkan ke AI
    Saya memberi instruksi yang jelas agar AI mengimplementasikan dan meloloskan test, lalu segera mereviewnya saat AI sedang mengembangkan, dan menambahkan test case yang kurang

  • Saya setuju dengan sebagian besar isi tulisan ini, tetapi saya tidak sependapat dengan kebijakan bahwa Claude sama sekali tidak boleh menyentuh test atau migrasi
    Menulis test sendiri adalah pekerjaan yang paling tidak saya sukai, jadi hanya dengan LLM membuat draf minimal saja pun sudah sangat membantu
    Intinya, terlepas dari siapa yang menghasilkan, kepemilikan dan tanggung jawab akhir harus selalu tetap pada manusia
    Dari nuansa pesannya, penulis tampaknya lebih ingin mencegah kepercayaan berlebihan pada Claude, atau mencegah karyawan menerima hasil AI tanpa kritik
    Atau mungkin ia menilai bahwa tanpa aturan ketat untuk test/migrasi, risikonya memang nyata: kode sungguhan bisa rusak atau data bisa hilang

    • Itu juga masuk akal, tetapi dalam pengalaman saya memang pernah ada masalah besar
      1. Saat test yang dihasilkan kemudian diperbaiki manual oleh manusia, ternyata ada banyak jebakan yang benar-benar serius
      2. Karena Claude tidak terlalu memahami konteks, ia sering mem-mock hampir semuanya, sehingga test yang dibuat benar-benar terlepas dari service/build environment kami
      3. Dan masalah yang lebih besar lagi adalah seluruh tim jadi terlalu malas terhadap test
        Pada praktiknya, bug di production memang meningkat cukup tajam