Workflow Saya untuk Pembuatan Kode dengan LLM

• tldr: brainstorm spesifikasi, susun rencana, lalu eksekusi dengan codegen LLM. Loop iterasi per unit. Lalu keajaiban terjadi
• Saya menggunakan LLM untuk dengan cepat membuat berbagai produk kecil. Menyenangkan, dan berguna
• Namun, jika terjebak dalam pendekatan yang salah, waktu bisa terbuang sangat banyak
• Banyak developer memiliki pendekatan yang kurang lebih mirip, dan di bawah ini adalah workflow saya

  "Saat ini bekerja dengan baik, tetapi 2 minggu lagi bisa jadi tidak bekerja atau justru bekerja dua kali lebih baik"

• Ada 2 cara untuk mengembangkan
  • Greenfield code: memulai proyek baru
  • Legacy modern code: memperbaiki atau memperluas codebase yang sudah ada

Greenfield: memulai dari nol

• Ini adalah proses yang cocok untuk situasi “memulai dari awal”
• Alurnya adalah melakukan brainstorming ide, mendokumentasikannya, menyusun rencana kecil bertahap, lalu menggunakan tool pembuat kode untuk mengimplementasikannya
• Langkah 1: memperjelas ide
  • Sambil menjelaskan ide ke LLM seperti ChatGPT, saya mendorong pertanyaan satu per satu untuk memurnikannya menjadi spesifikasi yang konkret
  • Pada akhirnya, saya membuat spec.md yang detail dan merapikannya dalam bentuk dokumen yang bisa diserahkan ke developer
  • Jika perlu, saya juga bisa mendapatkan materi pendukung untuk ide tersebut dengan tool seperti Deep Research
• Langkah 2: menyusun rencana
  • Berdasarkan spesifikasi, saya meminta model “pemahaman/penalaran” yang lebih kuat untuk menghasilkan blueprint langkah demi langkah yang rinci
  • Baik memakai pendekatan TDD maupun tidak, saya membuat unit kerja kecil untuk tiap tahap dan menyusunnya secara berurutan
  • Melalui proses ini, saya menghasilkan prompt_plan.md dan todo.md
    • prompt_plan.md berisi rancangan prompt yang dibutuhkan untuk pembuatan kode, dan todo.md berisi checklist
  • Penyusunan rencana ini biasanya cukup dalam sekitar 15 menit, dan mudah dirujuk kembali nanti
• Langkah 3: eksekusi
  • Saya menggunakan berbagai tool pembuat kode dan tool bantu seperti Aider, Cursor, Claude, dan lainnya untuk benar-benar menulis kode
  • Contoh utamanya adalah Claude dan Aider
  • Metode Claude
    • Setelah menyiapkan struktur proyek terlebih dahulu (boilerplate, dsb.), saya memasukkan prompt bertahap ke Claude
    • Saya copy-paste kode hasilnya ke IDE lalu menjalankan test
    • Jika muncul masalah, saya mengirim codebase saat ini ke Claude untuk debugging dengan tool seperti repomix
    • Workflow
      • Setup repo (boilerplate, uv init, cargo init, etc)
      • Paste prompt ke Claude
      • copy & paste dari claude.ai ke IDE
      • Jalankan kode, jalankan test, dll
      • …
      • Jika berfungsi, lanjut ke prompt berikutnya
      • Jika tidak berfungsi, kirim codebase ke Claude dengan Repomix untuk debugging
      • Ulangi proses ini (rinse repeat)
  • Metode Aider
    • Di Aider juga, saya memasukkan prompt_plan.md secara berurutan untuk bekerja
    • Tool ini mendukung proses seperti menjalankan test secara otomatis, atau mencari dan memperbaiki error
    • Jika perlu, masalah diselesaikan melalui debugging interaktif
      • Setup repo (boilerplate, uv init, cargo init, etc)
      • Jalankan Aider
      • Paste prompt ke Aider
      • Menonton Aider menari ♪┏(・o･)┛♪
      • Aider bisa menjalankan test atau aplikasi untuk verifikasi
      • Jika berfungsi, lanjut ke prompt berikutnya
      • Jika tidak berfungsi, perbaiki sambil Q&A dengan Aider
      • Ulangi proses ini (rinse repeat)
• Hasil
  • Dengan cara ini, kita bisa mengimplementasikan berbagai proyek seperti script, aplikasi Expo, Rust CLI, dan lainnya dalam waktu singkat
  • Jika ada proyek besar atau kecil yang terus Anda tunda, saya merekomendasikan untuk mencobanya sekali
  • Kelebihannya adalah bisa bereksperimen dengan cepat sambil mempelajari bahasa atau teknologi baru

Non-greenfield: pekerjaan bertahap/iteratif pada kode yang sudah ada

• Ini adalah metode yang digunakan saat menerapkan tugas-tugas kecil secara berulang pada codebase yang sudah ada
• Daripada rencana besar secara keseluruhan, alurnya lebih berupa saling bertukar permintaan dan hasil yang spesifik per unit kerja
• Mengamankan konteks
  • Anda dapat menggunakan tool seperti repomix untuk merangkum codebase dan mengirimkannya ke LLM
  • Dengan mise dan sejenisnya, Anda bisa mengelola konfigurasi berulang dan menyimpan hasil ringkasan ke file bernama output.txt
  • Untuk codebase yang terlalu besar, atur agar hanya bagian yang diperlukan saja yang diringkas
• Contoh workflow
  • Dengan perintah seperti mise run LLM:generate_missing_tests, biarkan LLM mengidentifikasi bagian yang kekurangan test
  • Terapkan usulan tersebut (issue) dengan Claude atau Aider, lalu uji kembali hasilnya
  • Dengan cara ini, codebase yang ada diperbaiki secara bertahap

Contoh prompt utama

• Code review
  “Sebagai developer senior, tolong review kode ini dengan teliti. Sertakan nomor baris dan konteks. Jangan lakukan review yang dangkal, lihatlah secara mendalam”
  “You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
• GitHub Issue generation
  “Sebagai developer senior, tolong tinjau kode ini dan tulis issue utama dalam format Github issue”
  “You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
• Missing tests
  “Sebagai developer senior, tolong tinjau kode ini dan jelaskan secara spesifik test yang hilang atau test yang perlu ada“
  “You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“

Ski ᨒ↟ 𖠰ᨒ↟ 𖠰

• Saat menulis kode dengan cepat menggunakan LLM, pada suatu titik kompleksitas atau konteks akan kusut dan mulai membingungkan
• Akan sangat membantu jika Anda meninjau kembali dokumen tahap perencanaan (misalnya pada proses Greenfield) atau menyiapkan test secara sistematis
• Karena bergerak cepat, penting juga untuk sesekali beristirahat atau meluangkan waktu untuk merapikan pikiran

Saya sangat kesepian (｡•́︿•̀｡)

• Sebagian besar workflow berbasis LLM saat ini dioptimalkan untuk ‘mode solo’
• Saat mencoba coding bersama dalam tim, konflik atau masalah merge menjadi rumit
• Saya berharap lingkungan kolaboratif ‘multiplayer’ tempat banyak orang bisa menggunakan LLM secara bersamaan akan berkembang

Waktu

• Efisiensi penulisan kode memang meningkat besar berkat LLM, tetapi ada ‘downtime’ yang timbul karena waktu tunggu pemrosesan token
• Saya memanfaatkan waktu itu untuk memikirkan ide proyek lain, mendengarkan musik, atau berbincang
• Saya merasakan produktivitas pribadi meningkat jauh dibanding sebelumnya

Haterade ╭∩╮( •̀_•́ )╭∩╮

• Banyak teman bersikap seperti “sialan LLM, ini benar-benar tidak berguna”, dan saya pribadi tidak terlalu memedulikan sudut pandang itu
• Tentu saja saya juga tidak sepenuhnya sependapat dengan posisi tersebut, tetapi kecurigaan kritis memang tetap diperlukan
• Ada sangat banyak alasan untuk tidak menyukai AI, dan yang paling saya khawatirkan adalah konsumsi listrik serta dampaknya terhadap lingkungan
• Tapi tetap saja… "kode harus mengalir" begitu ya… ah sudahlah
• Jika Anda ingin tahu lebih banyak tetapi tidak benar-benar ingin menjadi programmer cyborg, rekomendasi saya adalah “jangan ubah pendapat Anda dulu, bacalah Ethan Mollick, ‘Co-Intelligence: Living and Working with AI’”
  • Buku ini menjelaskan manfaat LLM dengan baik tanpa bumbu berlebihan ala kapitalisme anarko-teknologis
  • Secara pribadi sangat membantu, dan saya juga bisa berdiskusi jauh lebih mendalam dengan teman-teman yang telah membaca buku ini
  • Sangat direkomendasikan

[devs5]

Co-Intelligence: Living and Working with AI karya Ethan Mollick tampaknya dijadwalkan terbit pada bulan Maret dengan judul Dual Brain.

[kipsong133]

Ternyata ada yang namanya Repomix. Selama ini saya selalu copy-paste setiap kali.. hiks

[chugue85]

Terima kasih!

[ahwjdekf]

Apakah LLM juga akan menggantikan menerima omelan yang biasanya diterima dari developer lain?

[aer0700]

Saya masih menggunakan LLM kira-kira seperti Google yang lebih canggih atau Stack Overflow yang ramah, tetapi sepertinya saya perlu memikirkan apakah ada cara untuk memanfaatkannya dengan lebih baik.
Bagi saya, bagaimana cara membuatnya tentu penting, tetapi tampaknya sama pentingnya juga untuk memikirkan bersama AI mengapa itu bekerja. LLM berguna saat mencari dokumen teknis lama atau hal-hal seperti standar.

[GN⁺]

Komentar Hacker News

• LLM adalah alat untuk dengan cepat membuat prototipe proyek baru. Namun, saat melakukan perubahan pada kode yang sudah ada atau proyek yang matang, LLM cenderung menambah kompleksitas atau memasukkan framework yang tidak perlu karena kurangnya konteks. LLM bukan pengganti untuk memahami kode.

• Dalam kolaborasi dengan LLM, penting untuk membangun konteks melalui pertanyaan. Ini lebih efektif daripada mencoba membangun konteks secara langsung.

• Belakangan ini, ada yang mencoba mob programming bersama LLM. Satu LLM menangani implementasi, sementara LLM lain mengkritik dan mengusulkan perbaikan.

• Sebaiknya tidak menambahkan framework yang terlalu opinionated ke dalam proyek. Ini karena hal tersebut memperbesar konteks yang harus dikenali model. Misalnya, alih-alih memakai Plasmo, mereka menyerahkan penyiapan ekstensi browser kepada LLM.

• Ingin mendengar pengalaman orang-orang yang memulai dari Cursor chat lalu berkembang ke workflow yang lebih baik. Apakah waktu yang diinvestasikan untuk perencanaan terasa bermanfaat, apakah halusinasi berkurang, dan apakah secara keseluruhan benar-benar menghemat waktu.

• Artikel ini menjelaskan cara memanfaatkan LLM dengan benar. Banyak orang belum cukup berlatih untuk berkomunikasi secara efektif dengan language model. Penulis telah menguasai komunikasi dengan LLM, dan workflow ini memaksimalkan efisiensi.

• Untuk memaksimalkan efisiensi dalam workflow yang menggunakan LLM, dibutuhkan kecepatan mengetik yang tinggi, penilaian yang tepat, serta pemahaman yang baik tentang kelebihan dan kekurangan tiap model.

• Alat coding berbasis LLM memang menyenangkan, tetapi untuk memastikan apakah benar-benar membantu, perlu menetapkan tujuan yang spesifik dan tenggat waktu. LLM cenderung gagal dalam kondisi seperti ini.

• Banyak programmer junior melupakan bagian spesifikasi dan rencana eksekusi dalam pemrograman. Agar berhasil memakai LLM, mereka harus didorong untuk membuat spesifikasi dan rencana eksekusi.

• Tidak memahami ekspektasi terhadap Claude. Dalam pertanyaan tentang Apache Spark, muncul banyak halusinasi. Ingin memahami mengapa Claude dianggap lebih baik daripada model lain.

• Untuk pengembang individu ini mungkin tidak masalah, tetapi beberapa instance LLM yang menganalisis codebase yang sama dalam tim bisa jadi tidak ekonomis dan berisiko. Ingin tahu apakah ada produk yang menyediakan konteks terpusat untuk tim.