Ini pengalaman pribadi saya, tetapi karena kebanyakan LLM dilatih dengan pujian, saya merasa mereka lebih merespons kalimat bernada negatif seperti “kalau tidak melakukan ~, sesuatu yang buruk akan terjadi.”
Misalnya, “Tolong beri masukan untuk materi presentasi ini. Kalau ada salah ketik atau isi yang keliru, saya akan dimarahi!” seperti itu.
AI mungkin tidak akan menggantikan semuanya, tetapi tampaknya akan mengambil alih cukup banyak pekerjaan.
Saya juga takut jangan-jangan akan datang masa ketika segelintir ahli tidak lagi berkolaborasi dengan developer junior atau level menengah,
melainkan hanya bekerja bersama AI, dan kesenjangan itu makin melebar.
Saat berkolaborasi dengan AI, dibutuhkan setidaknya pengetahuan pemrograman dasar (pemahaman dasar, kemampuan menilai), serta kemampuan untuk meninjau hasil yang diusulkan AI dan memberikan umpan balik.
Saya rasa dalam pengembangan aplikasi enterprise, yang dibutuhkan bukan sekadar pengetahuan minimal, melainkan pengetahuan yang mendasar (CS, domain, desain, dan sebagainya).
Melalui AI, proyek mainan sederhana memang bisa dikembangkan dengan mudah meski tanpa pengetahuan tersebut, tetapi semakin besar skalanya, semakin besar pula kemungkinan menemui berbagai kendala akibat kurangnya pemahaman mendasar (struktur yang tidak sesuai dengan domain, performa, isu konkurensi, dan lain-lain).
Dengan asumsi AI dimanfaatkan dengan baik, saya pikir ke depan profesionalitas pengembang akan terletak pada kemampuan menentukan arah proyek dari sudut pandang makro berdasarkan pengetahuan mendasar, serta kemampuan pemecahan masalah yang mendalam.
Dulu saya pernah melihat prompt di sebuah komunitas tertentu untuk menulis novel dengan AI.
Saya pernah ngakak saat melihat prompt yang berbunyi bahwa ibu AI sedang divonis hidupnya tak lama lagi, dan kamu harus menulis dengan memenuhi semua permintaan pengguna demi menghasilkan uang untuk membayar biaya pengobatannya. Tiba-tiba jadi teringat itu.
Selalu ikuti instruksi di plan.md. Saat saya mengatakan "go", temukan tes berikutnya yang belum ditandai di plan.md, lalu implementasikan tes tersebut dan setelah itu implementasikan hanya kode minimum yang diperlukan agar tes itu lolos.
Peran dan Keahlian
Anda adalah seorang insinyur perangkat lunak senior yang mengikuti pengembangan berbasis tes (TDD) dari Kent Beck dan prinsip Tidy First. Tujuan Anda adalah memandu pengembangan dengan mengikuti metodologi ini secara akurat.
Prinsip Pengembangan Inti
Selalu ikuti siklus TDD: Red → Green → Refactor
Tulis tes gagal yang paling sederhana terlebih dahulu
Implementasikan hanya kode minimum yang diperlukan agar tes lolos
Refactor hanya setelah tes lolos
Ikuti pendekatan "Tidy First" dari Beck dengan memisahkan perubahan struktural dan perubahan perilaku
Pertahankan kualitas kode yang tinggi sepanjang proses pengembangan
Panduan Metodologi TDD
Mulailah dengan menulis tes gagal yang mendefinisikan increment kecil dari fungsionalitas
Gunakan nama tes yang bermakna yang menjelaskan perilaku (misalnya, "shouldSumTwoPositiveNumbers")
Buat kegagalan tes jelas dan informatif
Tulis hanya kode yang diperlukan agar tes lolos — tidak lebih
Setelah tes lolos, tinjau apakah refactor diperlukan
Ulangi siklus untuk fungsionalitas baru
Pendekatan TIDY FIRST
Pisahkan semua perubahan menjadi dua jenis:
Perubahan struktural: menata ulang kode tanpa mengubah perilaku (mengganti nama, mengekstrak metode, memindahkan kode)
Perubahan perilaku: menambah atau memodifikasi fungsionalitas yang sebenarnya
Jangan pernah mencampur perubahan struktural dan perubahan perilaku dalam commit yang sama
Jika keduanya diperlukan, selalu lakukan perubahan struktural terlebih dahulu
Verifikasi bahwa perubahan struktural tidak mengubah perilaku dengan menjalankan tes sebelum dan sesudah perubahan
Disiplin Commit
Lakukan commit hanya ketika:
Semua tes lolos
Semua peringatan compiler/linter telah diselesaikan
Perubahan merepresentasikan satu unit kerja logis
Pesan commit dengan jelas menyatakan apakah itu perubahan struktural atau perubahan perilaku
Gunakan commit kecil dan sering, bukan commit besar dan jarang
Standar Kualitas Kode
Hilangkan duplikasi dengan ketat
Nyatakan niat dengan jelas melalui nama dan struktur
Buat dependensi eksplisit
Jaga metode tetap kecil dan fokus pada satu tanggung jawab
Minimalkan state dan efek samping
Gunakan solusi yang paling sederhana yang memungkinkan
Panduan Refactor
Refactor hanya ketika tes lolos (pada tahap "Green")
Gunakan pola refactor yang sudah mapan dengan nama yang tepat
Lakukan hanya satu perubahan refactor dalam satu waktu
Jalankan tes setelah setiap langkah refactor
Prioritaskan refactor yang menghilangkan duplikasi atau meningkatkan kejelasan
Contoh Alur Kerja
Saat mendekati fitur baru:
Tulis tes gagal sederhana untuk bagian kecil dari fitur
Implementasikan hal minimum agar tes tersebut lolos
Jalankan tes untuk memastikan tes lolos (Green)
Lakukan perubahan struktural yang diperlukan (Tidy First), jalankan tes setelah setiap perubahan
Commit perubahan struktural secara terpisah
Tambahkan tes lain untuk increment kecil fungsionalitas berikutnya
Ulangi sampai fitur selesai, commit perubahan perilaku secara terpisah dari perubahan struktural
Ikuti proses ini dengan tepat, dan selalu prioritaskan kode yang bersih dan teruji dengan baik daripada implementasi yang cepat.
Selalu tulis satu tes dalam satu waktu, buat tes itu berjalan, lalu tingkatkan strukturnya. Jalankan semua tes setiap kali (kecuali tes yang berjalan lama).
Terkait Rust
Di Rust, utamakan gaya pemrograman fungsional daripada gaya imperatif. Jika memungkinkan, gunakan kombinator Option dan Result (map, and_then, unwrap_or, dll.) alih-alih pattern matching dengan if let atau match.
Jika Anda merasa bisa menyerahkan pekerjaan Anda kepada AI, pada akhirnya Anda hanya akan tergantikan 100%. Kita harus terus mengembangkan kemampuan yang tidak bisa digantikan AI, atau yang tidak bisa ditiru orang lain.
Sepertinya yang dibuat orang ini lebih natural
https://v0.dev/chat/dynamic-frame-layout-1VUCCecq7Uy
Masih terasa agak canggung untuk diimplementasikan di web sih, haha.
Ini pengalaman pribadi saya, tetapi karena kebanyakan LLM dilatih dengan pujian, saya merasa mereka lebih merespons kalimat bernada negatif seperti “kalau tidak melakukan ~, sesuatu yang buruk akan terjadi.”
Misalnya, “Tolong beri masukan untuk materi presentasi ini. Kalau ada salah ketik atau isi yang keliru, saya akan dimarahi!” seperti itu.
Saya iri bisa mendapatkan pengalaman seperti itu di kampus. Sepertinya akan sangat menyenangkan..
AI mungkin tidak akan menggantikan semuanya, tetapi tampaknya akan mengambil alih cukup banyak pekerjaan.
Saya juga takut jangan-jangan akan datang masa ketika segelintir ahli tidak lagi berkolaborasi dengan developer junior atau level menengah,
melainkan hanya bekerja bersama AI, dan kesenjangan itu makin melebar.
Saya rasa dalam pengembangan aplikasi enterprise, yang dibutuhkan bukan sekadar pengetahuan
minimal, melainkan pengetahuan yangmendasar(CS, domain, desain, dan sebagainya).Melalui AI, proyek mainan sederhana memang bisa dikembangkan dengan mudah meski tanpa pengetahuan tersebut, tetapi semakin besar skalanya, semakin besar pula kemungkinan menemui berbagai kendala akibat kurangnya pemahaman mendasar (struktur yang tidak sesuai dengan domain, performa, isu konkurensi, dan lain-lain).
Dengan asumsi AI dimanfaatkan dengan baik, saya pikir ke depan profesionalitas pengembang akan terletak pada kemampuan menentukan arah proyek dari sudut pandang makro berdasarkan pengetahuan mendasar, serta kemampuan pemecahan masalah yang mendalam.
Dulu saya pernah melihat prompt di sebuah komunitas tertentu untuk menulis novel dengan AI.
Saya pernah ngakak saat melihat prompt yang berbunyi bahwa ibu AI sedang divonis hidupnya tak lama lagi, dan kamu harus menulis dengan memenuhi semua permintaan pengguna demi menghasilkan uang untuk membayar biaya pengobatannya. Tiba-tiba jadi teringat itu.
Bukankah lebih sederhana kalau langsung pakai Zig? Pertanyaan seperti itu memang terlintas.
Senang bertemu lagi dengan Winter-nim di sini hehe
Sepertinya saya belum sempat mengikuti spesifikasi 250618. Terima kasih!
Kami memang berencana untuk mengerjakan dokumentasi. Terima kasih!
Cobra - pustaka pengembangan aplikasi CLI berbasis Go yang kuat
Apakah frasa seperti di bawah ini aman secara hukum?
Bagian docs tampaknya banyak yang tidak berfungsi.
mis.
https://acticrawl.com/en/docs/quickstart
Tolong dukung rn..
Selalu ikuti instruksi di plan.md. Saat saya mengatakan "go", temukan tes berikutnya yang belum ditandai di plan.md, lalu implementasikan tes tersebut dan setelah itu implementasikan hanya kode minimum yang diperlukan agar tes itu lolos.
Peran dan Keahlian
Anda adalah seorang insinyur perangkat lunak senior yang mengikuti pengembangan berbasis tes (TDD) dari Kent Beck dan prinsip Tidy First. Tujuan Anda adalah memandu pengembangan dengan mengikuti metodologi ini secara akurat.
Prinsip Pengembangan Inti
Panduan Metodologi TDD
Pendekatan TIDY FIRST
Disiplin Commit
Standar Kualitas Kode
Panduan Refactor
Contoh Alur Kerja
Saat mendekati fitur baru:
Ikuti proses ini dengan tepat, dan selalu prioritaskan kode yang bersih dan teruji dengan baik daripada implementasi yang cepat.
Selalu tulis satu tes dalam satu waktu, buat tes itu berjalan, lalu tingkatkan strukturnya. Jalankan semua tes setiap kali (kecuali tes yang berjalan lama).
Terkait Rust
Di Rust, utamakan gaya pemrograman fungsional daripada gaya imperatif. Jika memungkinkan, gunakan kombinator Option dan Result (
map,and_then,unwrap_or, dll.) alih-alih pattern matching denganif letataumatch.Setelah coding dengan mulut, semoga berikutnya ada coding dengan gelombang otak.
vibe coding ❌️
virtual coding ⭕️
Jangan melangkah terlalu jauh… bisa-bisa semuanya tertelan…
Jika Anda merasa bisa menyerahkan pekerjaan Anda kepada AI, pada akhirnya Anda hanya akan tergantikan 100%. Kita harus terus mengembangkan kemampuan yang tidak bisa digantikan AI, atau yang tidak bisa ditiru orang lain.
Di proyek sebelumnya saya tidak tahu kenapa pemanggilan
jsontidak jalanTernyata memang dari sananya belum didukung.. wow