Grok untuk developer

Grok adalah teman diskusi "rubber duck" andal yang bisa diajak bicara balik. Di grok.online, layanan ini gratis dan tidak memerlukan akun: Grok 4.20 bekerja cepat untuk pertanyaan singkat, Grok 4.3 Thinking berpikir mendalam sebelum menjawab dan lebih cocok untuk mengatasi bug, serta Grok 4.7, model terbaru, siap menangani masalah tersulit menggunakan 10 dari 30 kuota pesan harian Anda. Ketiganya dapat membaca tangkapan layar. Berikut tujuh kegunaannya, masing-masing dilengkapi prompt yang bisa langsung Anda buka di chat dan disesuaikan.

Menemukan dan memperbaiki masalah

Sebagian besar waktu debugging habis untuk memahami apa yang sebenarnya terjadi. Prompt berikut membantu mempercepat proses tersebut.

Membaca stack trace

Tempelkan pesan error lengkap, bukan rangkumannya, beserta baris kode yang ditunjuk. Minta penjelasan penyebabnya dalam bahasa sederhana sebelum meminta perbaikan, agar Anda bisa menilainya sendiri.

Saya menggunakan [bahasa dan versi] dengan [framework]. Berikut pesan error lengkap dan stack trace-nya: [tempel error]. Berikut kode yang ditunjuk: [tempel kode]. Jelaskan dengan bahasa sederhana apa yang salah dan alasannya, sebutkan penyebab paling mungkin terlebih dahulu, lalu tunjukkan perubahan paling minimal untuk memperbaikinya.

Buka di chat. Fitur Code Assistant melakukan hal serupa dalam satu panel praktis.

Memahami peta kode buatan orang lain

Mewarisi file tanpa komentar adalah pengalaman yang lazim bagi developer. Sebelum mengubah apa pun, mintalah panduan menyeluruh yang menyoroti bagian-bagian berisiko.

Saya baru saja menerima file [bahasa] ini dan perlu mengubah [fitur]. Berikan penjelasan singkat: apa fungsi utama file ini, fungsi-fungsi penting sesuai urutan eksekusinya, state global atau side effect yang perlu diwaspadai, dan bagian paling aman untuk membuat perubahan: [tempel kode]

Dapatkan penjelasannya, lalu tanyakan tentang fungsi apa pun yang masih tampak janggal.

Mencari bug logika dengan model penalaran

Saat aplikasi tidak crash tetapi hasilnya keliru, Anda perlu penelusuran yang cermat. Grok 4.3 Thinking memeriksa alur kode sebelum membalas, sangat cocok untuk masalah off-by-one dan kondisi logika yang salah.

Fungsi [bahasa] ini seharusnya [perilaku yang diharapkan], tetapi untuk input [input] justru mengembalikan [output aktual] bukan [output yang diharapkan]. Telusuri eksekusinya langkah demi langkah dengan input tersebut, tunjukkan nilai variabel utama di setiap langkah, dan tunjukkan baris persis tempat terjadinya kesalahan: [tempel fungsi]

Telusuri dengan Grok 4.3 Thinking.

Memperbaiki tampilan rusak dari tangkapan layar

Lampirkan tangkapan layar tampilan halaman saat ini, tempelkan HTML dan CSS terkait, lalu jelaskan tampilan yang diinginkan.

Saya melampirkan tangkapan layar halaman dengan masalah [jelaskan masalahnya, mis. sidebar menutupi konten di layar sempit]. Berikut HTML dan CSS untuk bagian tersebut: [tempel kode]. Jelaskan penyebabnya dan berikan CSS yang sudah diperbaiki, dengan perubahan seminimal mungkin.

Buka prompt ini dan lampirkan tangkapan layar Anda.

Merencanakan refactor yang berisiko

Merapikan modul berukuran besar adalah momen tepat untuk memanfaatkan model terbaru dengan kuota harian terbatasnya. Mintalah sebuah rencana bertahap, bukan penulisan ulang instan.

Berikut modul [bahasa] yang sudah mulai sulit diubah: [tempel kode]. Jangan tulis ulang kodenya dulu. Jelaskan tanggung jawab modul ini, dependensi tersembunyi, dan rencana refactoring dalam langkah-langkah kecil agar kodenya tetap berjalan setelah tiap langkah. Sebutkan pengujian mana yang harus saya tambahkan sebelum langkah pertama.

Rencanakan bersama Grok 4.7, lalu jalankan langkah-langkahnya satu per satu menggunakan Grok 4.20.

Menulis kode pendukung

Pengujian, query database, review, dan dokumentasi sering kali terabaikan saat tenggat waktu mendekat.

Membuat pengujian untuk edge case yang terlewat

Mintalah daftar skenario terlebih dahulu, baru kemudian kode pengujiannya. Nilai utama terletak pada daftar skenario tersebut.

Berikut fungsi [bahasa]: [tempel fungsi]. Pertama, buat daftar edge case yang patut diuji, seperti input kosong, batas nilai (boundary), dan tipe data tidak valid, sertakan satu baris alasan untuk masing-masing case. Kemudian buatkan pengujiannya menggunakan [framework pengujian], satu pengujian per case, dengan penamaan yang jelas.

Buat pengujiannya, jalankan, dan simpan pengujian yang gagal dengan alasan yang valid.

Mendapatkan code review ala senior engineer yang perfeksionis

Grok siap berperan sebagai reviewer berpengalaman yang sudah melihat segala jenis bug. Ketat dan blak-blakan bukan masalah; yang penting tidak ambigu, jadi mintalah nomor baris spesifik.

Review diff ini layaknya senior engineer yang tegas namun adil. Tunjukkan bug, penamaan yang membingungkan, penanganan error yang terlewat, dan hal apa pun yang bisa menimbulkan masalah dalam enam bulan ke depan, masing-masing disertai nomor baris dan saran perbaikan. Urutkan masalah berdasarkan tingkat keparahan dan abaikan perdebatan gaya penulisan semata: [tempel diff]

Minta review kodenya sebelum rekan tim Anda melihatnya.

Mengubah skema menjadi SQL dan README

Berikan definisi tabel dan jelaskan kebutuhan Anda dengan kata-kata sederhana, lalu minta penjelasan singkat bersamaan dengan query-nya.

Berikut definisi tabel saya untuk [database, mis. PostgreSQL]: [tempel skema]. Buatkan query yang menghasilkan [kebutuhan Anda dalam kata-kata sederhana]. Jelaskan setiap join dan filter dalam satu baris, dan beri tahu indeks mana yang bisa mempercepatnya saat tabel menampung jutaan baris data.

Buat query-nya, lalu mintalah draf bagian README untuk mendokumentasikan tabel-tabel tersebut.

Hal yang harus dihindari

• Menempelkan data rahasia. API key, kata sandi, token, dan data pelanggan tidak boleh dimasukkan ke dalam chat apa pun. Ganti dengan placeholder.
• Memercayai detail library secara membabi buta. Model memiliki batas pengetahuan dan tidak memiliki akses internet, sehingga fungsi atau opsi tertentu mungkin sudah usang atau hasil halusinasi. Selalu periksa dokumentasi resmi.
• Menerapkan kode tanpa pengujian. Kode yang tampak rapi tetap bisa gagal saat dijalankan. Jalankan, uji, dan periksa kembali.
• Mengirimkan seluruh repositori. Pesan yang terlalu panjang akan dipotong. Kirimkan fungsi yang relevan saja.

Halaman terkait

• Dua puluh ide awal lainnya di prompt coding.
• Panduan kami tentang coding bersama Grok dan penjelasan mengenai model penalaran.
• Ingin membuat aplikasi sendiri? Pelajari selengkapnya tentang Grok API.