23 poin oleh GN⁺ 2025-06-06 | 1 komentar | Bagikan ke WhatsApp
  • Asisten coding AI dapat meningkatkan produktivitas developer, tetapi kualitas hasilnya sangat bergantung pada prompt engineering
  • Untuk mendapatkan hasil yang efektif, perlu mengikuti aturan seperti konteks yang kaya, tujuan yang spesifik, contoh, pemberian peran, dan perbaikan iteratif
  • Menyediakan pola perancangan prompt dan contoh untuk tugas pengembangan utama seperti debugging, refactoring, dan implementasi fitur baru
  • Prompt yang baik harus memuat informasi spesifik seperti tujuan, bahasa, lingkungan, pesan error, serta contoh input/output
  • Metode perancangan prompt yang bisa diikuti bahkan oleh engineer baru, lengkap dengan perbandingan respons AI nyata dan komentar

Gambaran umum: pentingnya prompt engineering yang sukses

  • Belakangan ini developer menggunakan asisten coding AI untuk mempercepat alur kerja, mulai dari autocomplete fungsi, perbaikan bug, hingga penulisan seluruh modul
  • Namun, kualitas respons AI sangat ditentukan oleh kualitas prompt
  • Prompt yang baik mendorong solusi kode yang jelas dan kreatif, sedangkan prompt yang ambigu atau lemah akan menghasilkan jawaban yang terbatas dan tidak bermakna
  • Playbook ini merangkum secara praktis cara merancang prompt yang efektif untuk tugas pengembangan sehari-hari

Prinsip dasar prompt kode yang efektif

  • Berikan konteks yang kaya: AI tidak mengetahui proyek atau maksud Anda sebelumnya, jadi cantumkan semua informasi yang relevan seperti bahasa yang digunakan, framework, library, pesan error, dan tujuan kode
  • Nyatakan tujuan atau pertanyaan dengan jelas: alih-alih pertanyaan ambigu seperti “Mengapa kodenya tidak jalan?”, jelaskan hasil yang diinginkan dan kondisi saat ini secara jelas
  • Pecah tugas yang kompleks: untuk pengembangan fitur besar dan sejenisnya, jangan meminta semuanya sekaligus; bagi menjadi langkah-langkah kecil dan minta secara bertahap
  • Sertakan contoh input/output atau perilaku yang diharapkan: memberi contoh input/output atau perilaku nyata sangat meningkatkan pemahaman AI ("few-shot prompting")
  • Gunakan peran (persona): berikan peran yang bertanggung jawab seperti “review kode seperti developer senior React” atau “optimalkan sebagai spesialis performa” untuk meningkatkan kualitas respons AI
  • Perbaikan iteratif secara percakapan: berdasarkan jawaban pertama AI, capai hasil yang diinginkan secara bertahap melalui permintaan tambahan atau revisi
  • Jaga konsistensi kode: karena AI merujuk pada style kode, penamaan, dan komentar, selalu pertahankan konsistensi dan kejelasan kode

Pola prompt untuk debugging

Cara merancang prompt debugging yang sistematis

  • Jelaskan masalah dan gejala dengan jelas: berikan informasi yang kaya seperti bahasa, tujuan fitur, perilaku yang diharapkan, pesan error yang sebenarnya, dan cuplikan kode
  • Minta analisis langkah demi langkah atau per baris: untuk error logika atau bug yang halus, arahkan AI melacak variabel satu per satu atau menjelaskan sebagian kode untuk menemukan penyebabnya
  • Gunakan kode reproduksi minimal: alih-alih kode besar yang kompleks, ekstrak unit kode minimum yang memunculkan error agar diagnosis lebih terfokus
  • Ajukan pertanyaan langsung dan permintaan lanjutan: minta umpan balik yang jelas dan bisa diulang seperti “Di mana bug terjadi?” atau “Berikan kode yang sudah diperbaiki”

Contoh: prompt yang buruk vs. prompt yang diperbaiki

Contoh kode bermasalah

function mapUsersById(users) {
  const userMap = {};
  for (let i = 0; i <= users.length; i++) {  
    const user = users[i];
    userMap[user.id] = user;
  }
  return userMap;
}
const result = mapUsersById([{ id: 1, name: "Alice" }]);

Prompt yang buruk:

“Kenapa fungsi mapUsersById tidak bekerja?”

  • Respons AI: memberikan dugaan samar seperti “array mungkin kosong” atau “user mungkin tidak punya id”
  • Hanya menghasilkan saran umum karena kurang konteks dan tidak jelas

Prompt yang diperbaiki:

“Fungsi mapUsersById harus memetakan array pengguna berdasarkan id, tetapi saat input [ {id: 1, name: "Alice"} ] muncul error TypeError: Cannot read property 'id' of undefined. Kodenya sebagai berikut: [sertakan kode] Hasil yang diharapkan adalah { "1": ... } Apa penyebab fenomena ini dan bagaimana solusinya?”

  • Respons AI: menunjukkan bahwa kondisi loop (i <= users.length) melewati batas sehingga pada iterasi terakhir muncul undefined, lalu menyarankan perbaikan menjadi i < users.length
  • Solusi yang akurat diperoleh karena memberikan konteks spesifik, pesan error, dan perilaku yang diharapkan

Strategi prompt debugging tambahan

  • Minta daftar kandidat penyebab bug (“Apa kemungkinan penyebab TypeError?” dan sejenisnya)
  • Jelaskan sendiri logika kerja kode lalu minta ditinjau (“Apakah penjelasan saya benar, tolong cari masalahnya”)
  • Minta test case untuk situasi tak terduga (“Usulkan hanya 2 input yang bisa membuat fungsi ini gagal”)
  • Beri peran sebagai reviewer kode yang teliti (“Tinjau kode ini sambil menjelaskan masalah dan area perbaikannya”)

Pola prompt untuk refactoring/optimasi

Nyatakan tujuan perbaikan dengan jelas

  • “Lakukan refactoring” itu ambigu, jadi nyatakan tujuan spesifik seperti keterbacaan, performa, kemudahan pemeliharaan, atau penghapusan duplikasi kode
  • Berikan keseluruhan kode (atau konteks yang diperlukan), lingkungan, bahasa, dan versi framework secara memadai
  • Minta juga penjelasan atas perubahan yang dilakukan (“Tolong berikan kodenya beserta poin-poin perbaikannya”)
  • Tingkatkan kualitas yang diharapkan dengan pemberian peran seperti “sebagai pakar TypeScript sesuai praktik terbaru”

Contoh: perbandingan prompt refactoring

Kode asli

(mengandung masalah seperti fetch duplikat, struktur data yang tidak efisien, dll.)

async function getCombinedData(apiClient) {
  // Fetch list of users
  const usersResponse = await apiClient.fetch('/users');
  if (!usersResponse.ok) {
    throw new Error('Failed to fetch users');
  }
  // ... (disingkat)
}

Prompt yang ambigu

“Lakukan refactoring pada fungsi getCombinedData”

  • AI bisa mengubah hal-hal seperti fetch paralel atau penggabungan pesan error secara arbitrer (perilakunya tidak dapat diprediksi karena tidak ada requirement)

Prompt dengan tujuan spesifik

“Hapus duplikasi, tingkatkan performa, paralelkan dua fetch, pisahkan pesan error, dan perbaiki penggabungan data dengan cara yang efisien. Sertakan juga komentar dan penjelasan poin-poin perbaikannya”

  • Respons AI: memberikan refactoring yang jelas sesuai tujuan, seperti fetch paralel, pemisahan error, penggunaan struktur map yang efisien, beserta penjelasan detail

Tips refactoring tambahan

  • Minta secara bertahap (“perbaiki keterbacaan → optimalkan algoritme” secara berurutan)
  • Minta pendekatan lain (“tolong implementasikan juga dengan gaya fungsional” dan sejenisnya)
  • Gunakan format kode+penjelasan untuk pembelajaran dan tutorial
  • Minta penambahan test untuk kode hasilnya

Pola prompt untuk implementasi fitur baru

Arahkan pembuatan kode secara bertahap

  • Mulailah dengan penjelasan tingkat tinggi (fitur apa yang ingin dibuat), lalu pecah lebih detail secara bertahap
  • Sampaikan konteks lingkungan kerja seperti kode serupa yang sudah ada, pola proyek, dan library yang digunakan
  • Manfaatkan komentar atau TODO sebagai prompt untuk langsung mengarahkan alur coding AI di IDE
  • Berikan contoh input/output atau test case untuk menetapkan ekspektasi hasil yang jelas
  • Jika hasil pertama kurang memadai, segera tambahkan poin perbaikan yang spesifik atau style kode yang diinginkan lalu ulangi permintaan

Contoh: membuat komponen React ProductList

“Buat komponen fungsional React bernama ProductList. Ambil array produk dari /api/products dan tampilkan sebagai daftar, lalu saat nama produk dimasukkan di kolom input, lakukan filter tanpa membedakan huruf besar-kecil. Perlu juga penanganan loading dan error selama proses pengambilan.”

  • Respons AI: mencakup fetch data dengan useState dan useEffect, penanganan input, filtering, serta implementasi UI untuk error dan loading
  • Jika proyek menggunakan custom hook, instruksi tambahan seperti “refactor agar menggunakan hook useProducts()” dapat diberikan secara berulang

Contoh peningkatan prompt untuk praktik kerja nyata

  • Dapat meminta perluasan fitur secara bertahap seperti “Tambahkan fitur sorting: harus ada dropdown A-Z, Z-A”
  • Dengan memecah alur implementasi kode per langkah dan menggunakan prompt berbeda di tiap tahap, kualitas dan konsistensi kode dapat dijaga

Kesimpulan

  • Untuk memaksimalkan potensi asisten coding AI, perancangan prompt adalah kemampuan inti
  • Untuk menulis prompt yang sukses, selalu pertimbangkan konteks yang spesifik, tujuan, contoh, umpan balik iteratif, dan pemberian peran agar bisa menghasilkan hasil yang efektif
  • Anggap AI sebagai developer junior atau reviewer kode di dalam proyek, lalu arahkan secara rinci ke arah yang diinginkan dan tingkatkan kualitasnya secara bertahap; itulah kunci keberhasilan

1 komentar

 
GN⁺ 2025-06-06
Komentar Hacker News
  • Dari pengalaman saya, rasanya teknik prompt engineering yang benar-benar nyata cuma ada tiga

    • In Context Learning (memberikan contoh di dalam konteks, yaitu pendekatan one-shot atau few-shot dibanding zero-shot)

    • Chain of Thought (menginstruksikan untuk berpikir langkah demi langkah)

    • Structured output (misalnya menentukan format output dengan jelas seperti JSON)
      Di luar itu, mungkin bisa ditambahkan juga Role Prompting seperti yang disebut di tulisan ini
      RAG saya pisahkan sendiri karena modelnya merangkum konteks yang diberikan
      Pada akhirnya sisanya hanyalah ringkasan cara meminta sesuatu yang diinginkan dengan bahasa yang jelas dan sederhana

    • Dalam prompt, konteks adalah elemen yang paling penting
      Misalnya, kalau mulai dengan Typescript lalu bertanya soal data science, saya melihat model tidak bisa menjawab dengan baik
      Kalau pertanyaan yang sama diajukan dengan Python, hasilnya jauh lebih bagus
      Karena LLM masih kesulitan melakukan transfer pengetahuan antar-domain, pengaturan konteks yang sesuai tujuan itu sangat penting

    • Secara pribadi saya juga merasa role prompting itu tidak terlalu berarti
      Mungkin di GPT-3 memang begitu, tapi sebagian besar LLM sekarang sudah paham peran "ahli"
      Terlalu terobsesi dengan "prompt engineering" menurut saya hanya menipu diri sendiri
      Sampaikan kebutuhan dengan jelas, tambahkan contoh bila perlu, periksa hasil atau reasoning trace, lalu kalau hasilnya belum sesuai, sesuaikan dan coba lagi
      Kalau sudah beberapa kali mencoba tetap tidak dapat jawaban, pilihannya ya gunakan reasoning saya sendiri, bukan AI

    • Ada pendapat bahwa masalahnya justru banyak orang "berusaha memasukkan semuanya ke dalam satu prompt sekaligus"
      Daripada melempar satu permintaan raksasa, lebih baik dipecah menjadi beberapa prompt dengan konteks kecil, lalu output terstruktur yang jelas dari masing-masing dihubungkan
      Setiap prompt difokuskan pada tujuan dan contoh, sambil menghindari context overload
      Dengan begitu, tiga metode inti yang disebut di atas akan terpakai secara alami

    • Terkait metode ketiga (structured output), saya dan rekan-rekan pernah membuat studi kasus penerapannya di bidang sains
      Tautan paper

    • Sebagai catatan, tim kami lebih banyak mengandalkan fine-tuning daripada prompt engineering
      Pendekatan few-shot prompt tidak efektif untuk kasus kami

  • Saya sering merasa kalau prompt terlalu panjang atau rumit, performa kognitif model justru menurun
    Prompt yang kompleks memang bisa memberi kesan lebih terkontrol, tapi dalam praktiknya belum tentu menguntungkan
    Karena itu pola penggunaan saya secara alami mengarah ke prompt yang sangat sederhana dan minimal, lalu disempurnakan lewat beberapa iterasi

    • Saya juga mulai memakai pendekatan yang persis sama

      1. Sampaikan hanya konteks, asumsi, dan tujuan yang benar-benar perlu secara singkat
      2. Cek jawabannya lalu revisi prompt awal
        Cara ini juga lebih hemat biaya
        Saya terlalu sering memakai agent lalu membakar $30, codebase jadi berantakan, atau malah kembali ke kode semula
        Saya juga ingin mengingatkan bahwa kalau kita membiarkan AI menulis terlalu banyak kode untuk proyek kita, nanti kode itu tidak benar-benar melekat di kepala kita dan lebih sulit dikelola
    • Ada juga dasar bahwa performa lebih baik jika prompt ditulis memakai istilah para ahli
      Umumnya, lingkungan bahasa sehari-hari menghasilkan akurasi yang lebih rendah, sementara kosakata dari bidang profesional tertentu lebih sering menghasilkan jawaban yang lebih andal
      Data training juga mencerminkan distribusi seperti ini

    • Saya juga punya pengalaman serupa
      Tapi kalau melihat system prompt untuk agent, sering kali panjang dan rumit sekali, jadi saya penasaran
      Saya ingin tahu bagaimana prompt seperti itu benar-benar bekerja
      Tautan contoh system prompt

    • Untuk beberapa tugas, rekan saya memakai prompt yang sangat bertele-tele
      Saat integrasi saya menambahkan CRUD operation, lalu sebagai eksperimen saya ganti jadi sangat singkat seperti "analisis ini dari sudut pandang <profesi>"
      Hasil akhirnya hampir sama di kedua sisi, dan prompt panjang itu malah cenderung membuat sebagian kalimatnya muncul lagi secara verbatim di output
      Hasilnya sendiri cukup bagus, tetapi pada akhirnya modelnya (gemini 2.5) hanya mengambil informasi penting, lalu juga melarutkan bagian-bagian yang tidak perlu ke hasil akhir
      Artinya, setidaknya untuk tugas ini, kesan saya adalah kebertele-telean tidak memberi pengaruh yang menarik pada "cara berpikir" model

    • Saya juga sampai pada kesimpulan yang sama, tetapi penasaran bagaimana seharusnya menafsirkan contoh penggunaan prompt panjang yang diberikan lab AI
      Contoh system prompt Anthropic

  • Saya merasa sebenarnya tidak ada hal terpisah bernama "prompt engineering"
    Sejak kapan menulis kalimat yang benar-benar bermakna dianggap sebagai engineering?
    Bahkan terasa lebih parah daripada "software engineering"
    Meski begitu, agak menyedihkan kalau ke depan hal seperti ini benar-benar menjadi profesi (prompt engineer) dan dianggap sebagai kemampuan khusus dalam menulis kalimat

    • Sebenarnya "kalimat yang benar-benar bermakna" itu masalah yang berubah tergantung banyak variabel
      Dalam praktiknya, begitu mencakup testing, pengelolaan, logging, dan version control, itu sudah menjadi engineering, bukan sekadar insting
      Struktur seperti urutan tertentu, gaya tertentu, dan restatement masalah juga sangat penting
      Saat menangani family model dengan banyak parameter, model berbasis API perlu dicek kompatibilitas prompt lamanya setiap kali ada upgrade versi
      Pemeriksaan dan pengujian semacam itu juga bagian dari prompt engineering
      Menurut saya sering kali orang terlalu bereaksi terhadap tren atau hype sampai melewatkan esensinya

    • Kalau barista di sekitar saya menambahkan gelar coffee engineer pada namanya, saya malah mungkin lebih percaya

    • Mungkin ini juga efek kecanduan algoritma, sampai konsumen sekarang bahkan makin kehilangan kemampuan membaca kalimat secara utuh

    • Saya rasa tidak perlu khawatir soal lowongan "prompt engineer"

    • Para AI sloperators berusaha mati-matian membuat pekerjaan mereka terdengar keren

  • Dari pengalaman saya, kalau LLM memang tidak bisa menyelesaikan suatu masalah, biasanya prompt "engineering" sebanyak apa pun tidak banyak membantu
    Pada akhirnya satu-satunya jalan adalah memecahnya menjadi submasalah lalu membiarkannya maju sedikit demi sedikit
    Kalau ada yang punya pengalaman sebaliknya, saya ingin dengar contohnya

    • Bagian penting dalam memakai LLM adalah punya intuisi tentang bagaimana memecah masalah dengan tepat
      Perlu kemampuan membedakan kapan dan bagaimana harus memecahnya, dan kapan cukup diserahkan begitu saja
      Seperti disebut di artikelnya, know-how seperti ini penting
      Ke depan akan ada lebih banyak cara untuk menata dan memberi komentar pada kode dengan lebih baik agar interaksi dengan LLM meningkat
      LLM sendiri juga akan terus berevolusi ke arah ini, dan saya berharap nantinya bisa sampai ikut menyarankan cara memecah masalah

    • Tujuan prompt engineering adalah mendapatkan solusi yang bagus lebih cepat dan dalam format yang diinginkan
      Pada akhirnya kita tentu ingin modelnya menjawab sendiri, tetapi secara realistis, pertanyaannya pun tetap perlu dioptimalkan

  • Saat menulis prompt, karena kebiasaan lama, menginstruksikan lewat bahasa alami masih terasa agak canggung
    Rasanya seperti seharusnya saya menulisnya seperti argumen yang presisi atau query SQL
    Aneh juga memberi instruksi ke tool seperti sedang mengobrol
    Meski begitu, fakta bahwa tool sekarang bisa memahami instruksi bahasa alami telah meningkatkan aksesibilitas secara dramatis
    Tapi tetap saja saya kadang merasa lucu melihat diri sendiri menulis prompt seolah sedang berbicara dengan manusia

  • Belakangan ini ada sangat banyak panduan prompt
    Tapi saya merasa sebenarnya tidak terlalu diperlukan
    Cukup pakai tool-nya langsung, biasakan diri, dan pelajari cara memakainya, maka kita akan tahu sendiri prompt seperti apa yang bagus

    • Mirip seperti masa Google sedang booming dan semua orang kena FOMO
      Katanya kalau tidak beli buku terkait kita bakal tertinggal seperti manusia purba, padahal sebenarnya ini bidang sederhana yang bisa dipelajari dalam sehari, jadi tidak perlu dipikirkan terlalu rumit

    • Tentu ada juga orang yang benar-benar terbantu oleh panduan atau video tips
      Banyak orang tidak punya kemauan untuk memperbaiki diri sendiri, tetapi hanya dengan sekali melihat panduan atau video dari orang yang jago, kemampuan mereka bisa meningkat
      Saya sendiri juga sering belajar tips dari cara orang lain menggunakan tool atau dari pengalaman komunitas
      Hanya berlatih sendirian ada batasnya kalau ingin mendapatkan tips seperti itu

    • Dulu ada formula dalam "panduan menulis user story" seperti “As a [role], I want to [task] so I can [objective]”
      Baik yang ahli maupun pemula, kebanyakan orang tetap butuh bantuan untuk menyampaikan kebutuhan secara jelas
      Bahkan developer yang sangat hebat pun bisa salah atau salah paham kalau kebutuhannya tidak terstruktur

    • Melihat bagaimana orang lain memperoleh produktivitas dengan tool ini juga cukup membantu
      Saya jadi menemukan ide-ide yang tadinya terlewat
      Sebelum mencoba semuanya sendiri lewat trial and error, lebih efisien kalau bisa belajar sedikit dari pengalaman yang sudah lebih dulu dilakukan orang lain
      Secara pribadi, karena saya tidak punya waktu untuk mencoba semuanya sendiri, saya sangat berterima kasih atas berbagi pengalaman seperti ini

    • Ada juga trik yang memang tidak terlalu kelihatan
      Misalnya, pengalaman bahwa ungkapan sopan seperti “please” di dalam prompt sebenarnya bisa dihilangkan

  • Saat kuliah pascasarjana ilmu komputer dulu, saya pernah menerapkan dengan baik proses verifikasi yang dipelajari di mata kuliah science of programming ke penulisan prompt untuk data engineering
    Misalnya, "beri input(...), asumsi(...), lalu minta dibuatkan kode spark yang memenuhi post-condition(...)"
    Kalau input, asumsi, dan kondisi hasil dinyatakan dengan jelas, model bisa menghasilkan kode yang bagus
    Referensi buku

    1. Science of programming, David Gries
    2. Verification of concurrent and sequential systems
  • Menurut saya terlalu bersemangat soal prompt engineering itu agak berlebihan
    Sekarang model-model terbaru umumnya sudah bisa menangani dengan baik hanya dengan kita copy-paste kode atau error lalu melempar pertanyaan biasa
    Saya tidak merasa perlu menulisnya dengan berbelit-belit

  • Beberapa hari lalu Sergey Brin mengatakan sesuatu yang katanya jarang dibahas di komunitas AI, yaitu bahwa "mengancam secara fisik" membuat performa model lebih baik
    Artikel terkait

    • Ini mengingatkan saya pada lelucon dari vibe coder profesional di YouTube "Programmers are also human" yang selalu menambahkan ".. atau masuk penjara" di akhir perintah ke LLM

    • Jadi ini sebabnya Google diam-diam meninggalkan "Don't Be Evil" ya?

  • Menyebut penulisan prompt sebagai "engineering" terasa sangat tidak serius

    • Dulu saat tren prompt "engineering" sedang ramai, saya pernah dengar analogi lucu

      Menyebut prompt engineer itu sama saja seperti pegawai toko sandwich Subway disebut "sandwich artist"
      Terlepas dari candaannya, kata engineer sendiri sekarang sudah dipakai terlalu luas sampai nyaris kehilangan makna
      Tautan info Sandwich Artist

    • Pada akhirnya perdebatan ini terus berulang setiap kali topik software engineering muncul

    • Mungkin karena imajinasi orang berhenti di level memakai antarmuka chat untuk meminta foto kucing
      Padahal sebenarnya ada juga prompt yang dipakai dalam API dan workflow otomatis, jadi lebih dari itu

    • Di Amerika ada juga jabatan "sales engineer", dan dari pengalaman saya, sering kali orang-orang ini sama sekali tidak paham bagaimana produk yang mereka jual itu bekerja

    • IT adalah tempat di mana kata-kata dan maknanya menghilang
      Sampai rasanya kita harus bertanya apakah sebuah kata memang perlu punya makna aslinya