Prompt AI untuk Coding: Dapatkan Kode yang Berfungsi

Prompt untuk coding adalah sebuah spesifikasi. Model belum pernah melihat proyekmu, tidak tahu versi bahasa mana yang kamu jalankan, dan tidak bisa bertanya apa yang harus terjadi ketika input-nya kosong. Apa pun yang tidak dicantumkan prompt, diisi model dengan pilihan yang paling umum dari data pelatihannya, dan pilihan yang paling umum sering kali bukan pilihanmu. Prompt-prompt di bawah ini memberi model lebih sedikit hal untuk ditebak.

Tulis spesifikasinya sebelum kodenya

Blok di bawah ini meminta fungsi Python yang kecil. Setiap bagian prompt-nya menjawab pertanyaan yang kalau tidak akan dijawab model untukmu. Matikan bagian-bagiannya satu per satu dan bayangkan balasannya tanpa bagian itu: tanpa batasan, kamu mungkin mendapat library pihak ketiga; tanpa konteks, model harus menebak apa yang dianggap input valid; tanpa format, kamu mungkin tidak mendapat tes.

Fungsi dari spesifikasi

EditCopy

Fill inversi

PartsRoleTaskContextConstraintsFormat

Role

Kamu adalah developer Python yang teliti dan menulis fungsi-fungsi kecil yang teruji.

Task

Tulis fungsi `parse_duration(text)` yang mengubah string durasi menjadi jumlah detik.

Context

Input yang valid terlihat seperti "1h30m", "45m", "2h", dan "90s": jam, menit, dan detik, masing-masing opsional, selalu dalam urutan itu. "1h30m" mengembalikan 5400. Selain itu, termasuk string kosong, tidak valid.

Constraints

Python 3.11, hanya standard library. Munculkan ValueError untuk input yang tidak valid, dengan input-nya di dalam pesan error. Jangan terima desimal seperti "1.5h".

Format

Berikan fungsinya dulu, lalu tes pytest yang mencakup setiap contoh di atas ditambah tiga input yang tidak valid. Tanpa penjelasan selain satu kalimat.

Try it

Example replyReplies vary between models and runs.

Fungsi ini mencocokkan tiga bagian opsional secara berurutan dan menolak kecocokan di mana ketiganya kosong.

import re

_PATTERN = re.compile(r"(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?")

def parse_duration(text: str) -> int:
    match = _PATTERN.fullmatch(text)
    if not match or not any(match.groups()):
        raise ValueError(f"invalid duration: {text!r}")
    hours, minutes, seconds = (int(g) if g else 0 for g in match.groups())
    return hours * 3600 + minutes * 60 + seconds

import pytest
from duration import parse_duration

@pytest.mark.parametrize("text, expected", [
    ("1h30m", 5400), ("45m", 2700), ("2h", 7200), ("90s", 90),
])
def test_valid(text, expected):
    assert parse_duration(text) == expected

@pytest.mark.parametrize("text", ["", "1m1h", "1.5h"])
def test_invalid(text):
    with pytest.raises(ValueError):
        parse_duration(text)

Ada empat detail di prompt itu yang melakukan sebagian besar pekerjaannya:

• Contoh beserta jawabannya. "1h30m mengembalikan 5400" adalah tes yang bisa dipakai model untuk mengecek kodenya sendiri, dan menghilangkan keraguan soal satuannya.
• Versi bahasa dan library yang boleh dipakai. Tanpa itu, kamu mungkin mendapat library yang belum kamu instal atau sintaks yang lebih baru dari interpreter-mu.
• Apa yang dianggap tidak valid, dan apa yang harus terjadi saat itu. Penanganan error mudah dilewatkan model kalau tidak ada yang memintanya.
• Tes di dalam jawaban. Tes mengubah "terlihat benar" menjadi sesuatu yang bisa kamu jalankan. Kalau sebuah tes gagal, kamu menempel balik kegagalannya, dan itu pesan susulan yang jauh lebih baik daripada "tidak jalan".

Pengecekan any(match.groups()) juga layak diperhatikan: pola itu sendiri cocok dengan string kosong, karena setiap bagiannya opsional. Baris di prompt tentang string kosong itulah yang membuat kasus itu muncul di kode dan di tesnya.

Sebutkan versi, stack, dan apa yang sudah ada

Model cenderung memakai gaya yang paling umum di data pelatihannya. Untuk JavaScript, itu bisa berarti require CommonJS di proyek yang memakai ES modules; untuk Python, bisa berarti API library yang sudah berubah (Pydantic 1 versus 2 adalah kasus yang umum); dan untuk framework apa pun yang berkembang cepat, bisa berarti pola dari dua versi mayor sebelumnya. Satu baris biasanya sudah memperbaikinya: "Node 22, ES modules, tanpa TypeScript" atau "React 19, function component, CSS modules biasa".

Saat kamu menambahkan sesuatu ke proyek yang sudah ada, model perlu melihat bagian-bagian yang akan disentuh kode barunya. Tempel signature fungsi yang harus dipanggilnya, bentuk data yang akan diterimanya, dan satu file yang sudah ada yang menunjukkan konvensimu. "Pakai helper db.query(sql, params) dari file di bawah ini" menghasilkan kode yang cocok; tanpa itu, kamu mungkin mendapat koneksi database baru yang ditulis dari nol. Jangan sertakan file-file yang tidak ada hubungannya dengan perubahan itu, karena setiap baris yang tidak berkaitan adalah sesuatu yang mungkin dicoba dipakai ulang oleh model.

Minta satu langkah kecil dalam satu waktu

Kegagalan paling umum dalam "vibe coding", yaitu membangun aplikasi dengan menjelaskannya kepada AI, adalah meminta seluruh aplikasi sekaligus. Model harus memilih framework, database, struktur folder, dan selusin fitur dalam satu balasan, dan satu balasan jarang bisa memuat kode yang berfungsi untuk semua itu, jadi yang sering kembali adalah kerangka. Bandingkan kedua tab ini.

Seluruh aplikasi sekaligusSatu langkah kecil

EditCopy

Buatkan aku aplikasi todo dengan akun pengguna, database, pengingat, dan mode gelap.

Try it

Example replyReplies vary between models and runs.

Berikut aplikasi todo full-stack yang memakai React, Node.js dengan Express, dan MongoDB.

Struktur proyek

todo-app/
  client/   (React front end)
  server/   (Express API, auth, reminders)

server/index.js

const express = require("express");
const mongoose = require("mongoose");
const app = express();
app.use(express.json());
// ... auth routes, todo routes and the reminder scheduler go here

Untuk autentikasi, kamu bisa menambahkan JWT dengan jsonwebtoken, dan untuk pengingat, scheduler seperti node-cron. Beri tahu aku kalau kamu ingin aku melengkapi bagian-bagian ini.

Balasan pertama tidak salah, tapi hanya berupa kerangka: balasan itu memilihkan tiga teknologi untukmu dan meninggalkan pekerjaan sebenarnya sebagai komentar. Balasan kedua cukup pendek untuk dibaca, langsung berjalan begitu kamu membuka file-nya, dan memberimu dasar yang berfungsi untuk langkah 2 ("sekarang simpan list-nya di localStorage supaya tetap ada setelah reload"). Setiap langkah cukup kecil sehingga ketika ada yang rusak, kamu tahu perubahan mana yang merusaknya.

Inilah prompt chaining yang dilakukan secara manual: output dari satu permintaan menjadi titik awal permintaan berikutnya. Tempel versi terbaru file-nya di setiap langkah baru, supaya model mengedit kode yang benar-benar kamu punya, bukan kode yang diingatnya pernah ditulis.

Minta rencana sebelum perubahan besar

Untuk apa pun yang lebih besar dari satu fungsi, minta rencananya dulu dan kodenya kemudian: "Sebutkan file-file yang akan kamu ubah dan apa yang dilakukan setiap perubahan. Jangan tulis kode dulu." Rencana cepat dibaca dan cepat dikoreksi. Kalau rencananya mengusulkan dependency baru yang tidak kamu inginkan atau melewatkan file yang kamu tahu terlibat, kamu memperbaikinya dengan satu kalimat alih-alih menemukannya di tengah tiga ratus baris kode.

Cek apa yang kembali

Kode buatan model gagal dengan beberapa cara yang bisa diperkirakan, dan masing-masing punya kebiasaan prompt yang bisa menangkapnya:

• API karangan. Model bisa memanggil fungsi atau meng-import package yang tidak ada, karena namanya terdengar masuk akal. Cek import yang tidak kamu kenal sebelum menginstalnya; halusinasi AI menjelaskan kenapa ini terjadi.
• Kasus tepi yang terlewat diam-diam. Kode yang berjalan di jalur normal tapi crash pada list kosong. Menyebutkan kasus-kasus tepi di prompt, dan meminta tes, adalah perbaikan yang paling murah.
• Perubahan diam-diam. Saat kamu meminta perbaikan di file yang panjang, model mungkin juga mengganti nama atau menata ulang kode yang tidak kamu minta. Tambahkan "ubah hanya yang perlu dan sebutkan setiap perubahan yang kamu buat".

Ketika kodenya berjalan tapi perilakunya salah, beralihlah ke prompt untuk debugging: prompt untuk debugging membahas apa yang perlu ditempel. Sebelum kamu me-merge sesuatu yang penting, putaran kedua dengan prompt untuk code review bisa menangkap masalah yang tidak terpikir untuk ditanyakan oleh prompt penulisannya.