Prompt Engineering untuk Developer: Beda dengan Prompt Biasa

Ada mitos yang perlu diluruskan: prompt engineering itu bukan tentang “trik sulap” untuk manipulasi AI. Dan untuk developer, ini bukan hal yang sama dengan cara orang awam pakai ChatGPT untuk menulis email.

Sebagai developer yang pakai AI setiap hari — untuk debug, code review, architecture discussion, sampai generate boilerplate — saya belajar bahwa cara kamu berkomunikasi dengan LLM sangat menentukan kualitas output-nya. Bukan cuma “prompt yang panjang lebih baik”, tapi ada pola yang spesifik untuk kebutuhan teknis.

Mari kita bahas yang benar-benar berguna — bukan teori akademis.

Kenapa Prompt Developer Berbeda?

Ketika orang awam pakai AI, mereka biasanya butuh output yang “cukup baik” — artikel, email, ringkasan. Ada ruang toleransi.

Ketika developer pakai AI untuk coding, toleransinya jauh lebih ketat:

Kode harus bisa dijalankan — bukan hanya kelihatan benar
Harus kompatibel dengan stack dan versi yang sedang dipakai
Harus konsisten dengan konvensi codebase yang sudah ada
Salah sedikit di logic bisa buat bug yang susah dilacak

Ini yang membuat prompt engineering untuk developer butuh pendekatan yang lebih terstruktur.

Teknik 1: Berikan Konteks Stack yang Spesifik

Prompt buruk:

> “Buatkan fungsi untuk handle authentication”

Prompt lebih baik:

> “Buatkan fungsi authentication menggunakan Express.js v4, JWT dengan library jsonwebtoken v9, dan TypeScript. Middleware harus check Authorization header format ‘Bearer token’, verify token, dan attach decoded user ke req.user.”

Perbedaannya bukan cuma panjang — tapi spesifisitas konteks. Dengan prompt kedua, AI tahu:

Framework yang dipakai (Express.js v4)
Library spesifik (jsonwebtoken v9)
Bahasa (TypeScript, bukan JavaScript)
Format yang diharapkan (Bearer token)
Output yang diinginkan (attach ke req.user)

Hasilnya? Kode yang bisa langsung dipakai, bukan yang perlu banyak modifikasi.

Teknik 2: Sertakan Kode yang Ada sebagai Referensi

Ini yang paling sering dilupakan: tunjukkan contoh kode yang sudah ada di codebase kamu.

Misalnya kamu mau generate fungsi baru yang konsisten dengan style tim:

Ini contoh fungsi yang sudah ada di codebase kami:

typescript

async function getUserById(id: string): Promise {

try {

const user = await db.query.users.findFirst({

where: eq(users.id, id)

});

return user ?? null;

} catch (error) {

logger.error(‘Failed to get user’, { id, error });

throw new DatabaseError(‘Failed to fetch user’);

}

Sekarang buatkan fungsi serupa untuk getPostsByUserId yang mengambil semua post milik seorang user, dengan pagination (page, limit).

Dengan memberikan referensi kode nyata, AI akan mengikuti:

Library yang dipakai (Drizzle ORM dalam contoh di atas)
Pattern error handling
Naming convention
Return type pattern

Teknik 3: Definisikan Output Format dengan Jelas

Untuk debugging, bedakan antara minta penjelasan dan minta solusi:

Minta penjelasan:

> “Jelaskan kenapa kode ini throw ‘TypeError: Cannot read properties of undefined’ dan di baris mana masalahnya.”

Minta solusi langsung:

> “Fix bug ini. Berikan hanya kode yang diperbaiki tanpa penjelasan panjang.”

Minta keduanya dengan struktur:

> “Untuk kode ini: [kode]. Format jawaban: 1) Root cause dalam 1-2 kalimat. 2) Kode yang sudah difix. 3) Cara mencegah bug serupa.”

Ini tampak kecil tapi penting. AI akan menyesuaikan output sesuai format yang diminta.

Teknik 4: Role Prompting yang Relevan

Role prompting untuk developer beda dengan “jadilah ahli”. Yang efektif adalah:

> “Kamu senior backend developer dengan spesialisasi di database optimization. Review query SQL ini dan identifikasi bottleneck performance. Anggap table punya 10 juta baris.”

Kuncinya: berikan konteks role yang spesifik termasuk constraints (table size, environment, etc). Ini membantu AI memberikan saran yang lebih realistic.

Teknik 5: Chain of Thought untuk Problem Kompleks

Untuk masalah yang kompleks — misalnya desain arsitektur atau debug issue yang tricky — minta AI untuk berpikir step by step sebelum memberikan jawaban:

> “Saya mau implementasi rate limiting di API Express yang bisa scale horizontal (multiple instances). Sebelum berikan solusinya, pikirkan dulu: apa saja trade-off antara in-memory vs Redis-based rate limiting, dan kapan masing-masing approach lebih cocok?”

Dengan minta AI “berpikir dulu”, output-nya cenderung lebih thoughtful dan mempertimbangkan edge cases.

Teknik 6: Negative Prompting — Bilang Apa yang Tidak Kamu Mau

Developer sering lupa ini. Explicit constraints bisa drastis meningkatkan relevansi output:

> “Buatkan implementasi caching untuk API calls ini. Jangan gunakan library eksternal — hanya pakai built-in Node.js. Jangan implementasi invalidation dulu, fokus ke basic cache dengan TTL. Jangan ubah interface fungsi yang ada.”

Tanpa negative prompting, AI sering menambahkan hal-hal yang tidak kamu butuhkan atau mengubah hal yang tidak boleh diubah.

Teknik 7: Iterasi, Bukan Satu Prompt Ajaib

Ini mindset yang paling penting: tidak ada single prompt yang sempurna.

Workflow yang saya pakai:

Prompt awal — broad, minta solusi umum
Refinement — “Bagus, tapi ubah bagian X supaya Y”
Validation — “Apakah ini handle edge case Z?”
Polish — “Sekarang tambahkan error handling dan TypeScript types”

Ini lebih efisien daripada mencoba buat satu prompt super-panjang yang cover semua hal sekaligus.

Anti-Pattern yang Harus Dihindari

Prompt yang terlalu vague:

“Buatkan API yang bagus”
“Bantu saya dengan database ini”

Copas error tanpa konteks:

Hanya paste stack trace tanpa kode yang relevan

Minta AI “tebak” stack kamu:

Tidak menyebutkan framework, versi, atau library

Percaya output tanpa validasi:

AI bisa confident tapi salah. Selalu test kode yang dihasilkan.

Template Prompt untuk Kebutuhan Umum

Untuk debug:

Environment: [Stack/framework/versi]
Problem: [Deskripsi singkat]
Error message: [Copy paste pesan error]
Kode yang relevan: [kode]
Yang sudah dicoba: [apa yang sudah kamu coba]

Untuk generate feature baru:

Stack: [list stack]
Context codebase: [snippet kode yang relevan]
Feature yang dibutuhkan: [deskripsi detail]
Constraints: [hal-hal yang tidak boleh berubah]

Untuk code review:

Review kode ini untuk: [bug / performance / security / readability]
Context: fungsi ini dipanggil oleh [konteks pemanggil]
Kode: [kode]

Penutup

Prompt engineering untuk developer bukan skill tersendiri yang perlu dipelajari berbulan-bulan. Ini tentang kebiasaan memberikan konteks yang cukup, mendefinisikan output yang diinginkan, dan iterasi secara sistematis.

Mulai dari teknik yang paling mudah: selalu sebutkan stack secara spesifik, dan sertakan kode referensi yang ada. Dua hal ini saja sudah mengubah kualitas output AI secara signifikan.

Mau diskusi lebih dalam soal workflow AI untuk development tim atau project kamu? Atau butuh bantuan membangun sistem yang memanfaatkan LLM secara optimal? Hubungi mafadev — kita ngobrol dan cari solusinya bareng.

Prompt Engineering untuk Developer: Beda dengan Prompt Biasa