Cara meningkatkan kemampuan pemrograman dengan memanfaatkan AI

• Ingin menggunakan alat coding AI agar pekerjaan konversi yang biasanya memakan waktu 1–2 jam oleh manusia bisa dipangkas menjadi sekitar 15–20 menit untuk tahap review
• Namun saat ini, kualitas kode yang dihasilkan AI bahkan tidak mencapai 90% dari kode yang ditulis sendiri, sehingga rasanya belum benar-benar membantu secara praktis
• Karena itu, muncul pertanyaan tentang bagaimana memanfaatkan AI agar produktivitas dan kualitas kode bisa meningkat secara bersamaan

Kumpulan tips praktis untuk meningkatkan efisiensi dan kualitas pemrograman dengan AI

1. Fokuskan penggunaan AI hanya pada pekerjaan yang bisa diulang

• AI paling efektif saat mengerjakan tugas dengan pola serupa secara berulang
• Untuk pertama kalinya, manusia sebaiknya mengimplementasikan sendiri dengan kualitas terbaik, lalu menjadikannya contoh acuan
• Setelah itu, serahkan pekerjaan dengan pola yang sama kepada AI untuk diproses dalam jumlah besar
• Untuk pekerjaan yang membutuhkan pemikiran dan penilaian, efisiensi yang diharapkan turun sangat tajam

2. Wajib membuat rencana sebelum mulai coding

• Jangan langsung menghasilkan kode; tulis dulu rencana penyelesaiannya
• Pada tahap perencanaan, tampilkan semua bagian yang ambigu dan semua pertanyaan yang perlu dijawab
• Jika rencananya belum memuaskan, jangan lanjut ke tahap eksekusi
• Kualitas hasil lebih ditentukan oleh kejelasan dokumen rencana daripada prompt

3. Pecah unit kerja sekecil mungkin

• Ajukan permintaan per satu file, satu komponen, atau beberapa fungsi
• Permintaan seperti “refactor seluruhnya” atau “perbaiki agar lebih idiomatic” punya kemungkinan gagal yang tinggi
• Desain struktur dikerjakan manusia, sementara implementasi berulang diserahkan ke AI

4. Jangan menumpuk konteks; sering-sering reset

• Semakin panjang percakapan, kepatuhan terhadap aturan dan kualitas akan turun drastis
• Satu sesi sebaiknya hanya menangani satu pekerjaan
• Jika arahnya berubah, mulai lagi dari sesi baru
• Untuk pekerjaan jangka panjang, simpan status dalam dokumen (plan.md dan sejenisnya) lalu masukkan kembali

5. Buat dokumen aturan yang singkat dan mekanis

• Pertahankan CLAUDE.md / AGENTS.md dalam kisaran 500–1000 token
• Alih-alih instruksi deklaratif, tulis aturan yang konkret dan bisa diverifikasi
• Catat seminimal mungkin, hanya untuk hal-hal yang sering salah
• Selebihnya dipaksa lewat kode dan pemeriksaan otomatis

6. Gunakan test, linter, dan build sebagai loop umpan balik

• Alih-alih mengatakan “tolong buat dengan baik”, jelaskan syarat lulusnya secara tegas
• Tetapkan target berupa semua test lolos, build berhasil, dan 0 error linter
• AI hanya bisa melakukan konvergensi sendiri jika ada loop umpan balik
• Test yang memverifikasi perilaku yang sudah ada sangat menurunkan tingkat kesulitan refactoring

7. Jangan mengubah di tengah eksekusi; perbaiki rencana lalu jalankan ulang

• Jika hasilnya tidak memuaskan, jangan terus mengulang permintaan revisi kode
• Ubah dokumen rencana terlebih dahulu, lalu jalankan lagi dalam sesi baru
• Jika arah diubah pada tahap eksekusi, kualitas akan cepat runtuh

8. Ajarkan gaya lewat contoh

• Instruksi abstrak seperti “kode yang bagus” hampir tidak efektif
• Sertakan contoh Before / After
• Tunjukkan dengan jelas mana contoh yang baik dan mana yang buruk
• Kembangkan aturan dengan berpusat pada contoh

9. Jangan menyerah untuk memahami, dan jelaskan batas tanggung jawab

• Kode yang dihasilkan AI wajib dipahami dan direview oleh manusia
• Selain prototipe dan kode berisiko rendah, penggunaan tanpa review tidak boleh dilakukan
• Pada kode yang berkaitan dengan keamanan, operasional, dan pemeliharaan jangka panjang, pemahaman adalah prasyarat kualitas

10. Periksa dulu apakah pekerjaan ini memang cocok untuk AI

• Pekerjaan tanpa jawaban pasti dan dengan pertimbangan estetika atau struktur yang besar kurang cocok untuk AI
• Refactoring UI yang sulit diverifikasi otomatis lewat hasil visual sangat menantang
• Jika diperlukan:
  • Tahap 1: transformasi mekanis dengan tujuan mempertahankan perilaku
  • Tahap 2: manusia melakukan quality refactoring

11. Mulai ekspektasi dari “peningkatan 10%”

• Jangan berharap 10x sejak awal
• Strategi mengakumulasi perbaikan kecil lebih efektif dalam jangka panjang
• Kuncinya adalah tidak mengorbankan desain dan standar kualitas

[GN⁺]

Komentar Hacker News

• Saya Boris dari tim Claude Code. Saya ingin berbagi beberapa tips

  1. Bagian yang sering salah atau tidak dipahami oleh Claude sebaiknya ditulis di CLAUDE.md. Claude membaca file ini secara otomatis
  2. Gunakan mode Plan (Shift+Tab dua kali) secara aktif; jika menyusun rencana lebih dulu lalu mengeksekusinya, untuk tugas sulit hasilnya bisa 2–3 kali lebih baik
  3. Sebaiknya berikan cara untuk memverifikasi pekerjaan. Misalnya di Svelte, Anda bisa memakai server Puppeteer MCP agar ia memeriksa hasilnya di browser
  4. Saya merekomendasikan model Opus 4.5. Rasanya jelas satu tingkat lebih baik daripada Sonnet 4.5
     Semoga membantu
  • Saya juga merasakan peningkatan produktivitas besar berkat mode Plan. Namun di versi terbaru muncul bug di mana mode Plan terus merujuk hanya pada rencana pertama di sesi itu, sehingga workflow saya jadi rusak. Saya penasaran apakah saya memakainya dengan cara yang tidak lazim
  • Setelah mengoreksi Claude saat bekerja, sebaiknya jalankan prompt self-reflection. Proses ini otomatis memasukkan hal-hal yang sebelumnya dirapikan secara manual ke CLAUDE.md
  • Saya setuju dengan saran di atas. Terutama feedback loop pada poin (3) adalah kuncinya. Model harus bisa memperbaiki sendiri lalu memeriksa hasilnya. Membiarkannya menyimpan file log, atau menyuruhnya membuat rencana pseudocode, juga membantu menyelesaikan masalah kompleks dengan cepat
  • Opus 4.5 benar-benar game changer. Sangat membantu saat merefaktor proyek React lama. Jika prompt ditulis dengan presisi dan CLAUDE.md disetel dengan baik, efeknya besar
  • CLAUDE.md bekerja dengan baik hanya sampai sekitar 4–5 kali, lalu melupakan instruksi. Misalnya, meski disuruh memanggil saya “Mr. bcherny”, ia segera lupa
  • Dibandingkan Google Jules, Claude Code terasa jauh lebih seperti developer profesional. Namun Claude Code Web tidak punya fitur proyek, dan saya diberi jawaban untuk memakai file .clinerules; saya ingin tahu bedanya dengan CLAUDE.md
  • Satu fitur berguna di CLAUDE.md adalah @import. Jika menambahkan @ di depan nama file, file itu bisa dipaksa masuk ke konteks. Namun kalau terlalu banyak dipakai jadi tidak efisien

• Jika memakai input suara, model lebih akurat memahami niat. Saya menyampaikan prompt sekitar 500 kata lewat suara. Saat berbicara, alur pikiran terasa lebih alami daripada saat mengetik.
  Jika mengatakan, “buat rencana dan tanyakan kalau ada pertanyaan,” Claude benar-benar akan bertanya. Menyuruhnya meniru gaya kode sebelumnya juga efektif

  • Saya juga hampir seluruhnya membuat laboratory.love dengan suara. Saya sering memakai shortcut untuk kalimat “analisis masalah dan kebutuhan sebelum menulis kode, lalu tanyakan bagian yang ambigu”
  • Bicara cepat bukan berarti bicara tanpa berpikir. Justru masalahnya bisa jadi berbicara dengan terlalu sedikit berpikir
  • Agak canggung berbicara ke AI saat ada orang lain yang mendengar, tetapi untuk kalimat panjang saya juga memasukkannya lewat suara
  • Saya penasaran layanan pengenalan suara apa yang dipakai

• Anda perlu memasukkan kondisi loop (loop condition) ke dalam prompt. Contoh: “ulangi sampai yarn test lolos”.
  Pada akhirnya LLM adalah agen yang berulang kali menjalankan alat, jadi harus diperlakukan seperti itu
  Referensi: Prompting the Agent Loop

• Saya merekomendasikan konfigurasi nori-profiles yang saya buat.
  Dari hasil eksperimen selama 4 bulan, performa Claude Code meningkat secara nyata.
  Tulisan terkait: Averaging 10 PRs a Day with Claude

  • Saya penasaran apa bedanya dibandingkan skills milik Claude Code

• Di perusahaan saya menangani codebase Golang skala besar. Saya sudah mencoba berbagai alat seperti Cursor, Claude Code, Gemini CLI, dan lainnya, tetapi kebanyakan kewalahan oleh jumlah kode.
  Namun aider jauh lebih mudah dikendalikan dan akurasinya tinggi. Menambahkan file memang manual, tetapi akurasinya nyaris 100%.
  Jika dipakai bersama Claude Sonnet terbaru atau Gemini 2.5 Pro, hasilnya paling akurat

  • Keunggulan aider adalah bukan agen penuh. Kita mengelola konteks secara manual sehingga tidak ada file yang salah diubah. Ini juga menguntungkan dari sisi penghematan token dan kecepatan

• Saat bekerja dengan Cursor, mula-mula saya menyuruhnya membuat file aturan sambil merefaktor satu route. Setelah itu, di route lain cukup mengatakan “refactor” saja

  • Jangan takut pada prompt yang panjang. Inilah yang disebut context engineering. Riwayat percakapan sendiri memperkaya konteks.
    Sebaiknya selalu sadar dengan sisa kapasitas konteks, dan bila perlu lakukan context clear lebih awal

• Penting untuk punya sudut pandang memperlakukan agen seperti rekan tim. Kita perlu mengamati kekuatan dan kelemahan masing-masing lalu menyesuaikan cara kolaborasi.
  Saya memusatkan kekuatan agen pada masalah yang bisa diverifikasi atau kode untuk eksperimen.
  Saya tidak terlalu paham Svelte, tetapi tampaknya bagus untuk mendorong rewrite dengan disposable test bergaya TDD.
  Kadang yang terbaik adalah membuang konteks salah sebelumnya lalu memulai lagi di workspace baru

  • Akan bagus kalau Anda bisa membagikan ringkasan teks tentang “gaya kognitif dan teamwork” itu

• Saya melihat LLM sebagai searcher. Jika pertanyaan dibuat kecil dan spesifik, pencarian jadi lebih mudah, dan makin jauh dari data latih, makin tinggi kemungkinan error.

  1. Buka proyek di Zed
  2. Hubungkan salah satu dari Gemini CLI, Qwen code, atau Claude
  3. Minta ia mengubah file lalu uji
  4. Jika gagal, coba di Grok atau Gemini 3 Chat
  5. Jika masih gagal, selesaikan secara manual
     Untuk proyek baru, prompt one-shot pun sering kali sudah cukup
  • Namun prompt yang terlalu kecil bisa menimbulkan masalah underspecification. Memang menurunkan biaya komputasi, tetapi dari sisi kualitas justru merugikan

• Toolset Claude Code yang paling sering saya pakai adalah superpowers

  1. Mulai dengan sesi brainstorming untuk menjelaskan fitur
  2. Claude menulis dokumen desain dan rencana implementasi lalu menyimpannya ke disk
  3. Di jendela Claude baru, jalankan perintah Execute Plan untuk eksekusi bertahap dan commit
  4. Setiap tiga tahap, saya minta ia melakukan review sendiri untuk meningkatkan kualitas kode
     Saya sudah memakainya dua minggu dan hampir tidak pernah gagal

• Prinsip saya dalam AI programming sederhana

  1. One-shot gagal
  2. Pecah pekerjaan menjadi unit-unit yang bisa diverifikasi
  3. Susun seluruh rencana dalam file Markdown
  4. Jalankan tiap tahap di sesi baru, lalu review dan commit
     Kuncinya adalah “Less is more”. Jendela konteks makin segar makin baik, dan sekitar 500–750 kata itu ideal. Semua tahap harus bisa diverifikasi

• Untuk pekerjaan terkait Java, Claude terus mengubah arah atau memberi saran yang saling bertentangan. Menurut saya ChatGPT jauh lebih baik

  • Jika memberi instruksi yang lebih spesifik di prompt, mungkin hasilnya bisa membaik
  • Saya penasaran apakah Anda sudah mencoba versi Claude Code

• Jika menginginkan “idiomatic code”, Anda harus lebih dulu mendefinisikan secara rinci gaya yang Anda maksud. Bagi contoh baik/buruk menjadi potongan kecil, lalu masukkan ke mode Plan di Opus 4.5 untuk menyusun rencana sebelum eksekusi. Jika belum sempurna dalam sekali jalan, ubah dokumen rencananya lalu coba lagi. Kalau Anda mencoba membimbingnya terlalu rinci seperti junior developer, justru jadi tidak efisien

  • Orang lain berbagi pengalaman bahwa “model zaman sekarang tidak harus selalu memulai sesi baru”; dengan refactoring inline pun hasilnya cukup stabil