- Agent Skills adalah scaffolding yang memaksa agen coding AI mengikuti prosedur rekayasa senior sebagai alur kerja, sehingga tidak bisa melewati langkah seperti spesifikasi, pengujian, PR yang dapat direview, dan peninjauan batas kepercayaan
- Skill adalah file Markdown dengan frontmatter, dan lebih mirip workflow dengan urutan langkah, bukti checkpoint, dan kriteria selesai daripada dokumen referensi
- 20 skill di repositori ini disusun ke dalam 6 tahap siklus hidup: Define, Plan, Build, Verify, Review, Ship, serta 7 slash command:
/spec, /plan, /build, /test, /review, /ship, /code-simplify
- Prinsip utamanya adalah proses di atas prosa, tabel anti-rasionalisasi, verifikasi sebagai kriteria selesai, progressive disclosure, dan disiplin cakupan;
using-agent-skills hanya mengaktifkan skill yang sesuai dengan tugas
- Bisa digunakan lewat instalasi Claude Code marketplace, memasukkan Markdown ke
.cursor/rules/ di Cursor, Gemini CLI, Codex, Aider, Windsurf, OpenCode, dan alat lain serupa, serta dirilis dengan lisensi MIT
Tujuan dan masalah yang ingin diselesaikan
- Agent Skills adalah scaffolding untuk memaksa agen coding AI menjalankan prosedur rekayasa senior yang biasanya dilewati secara default, dengan menjadikannya workflow
- Saat diminta membuat fitur, agen coding AI biasanya menyelesaikannya lewat jalur tercepat, dan secara default tidak melakukan langkah seperti menulis spesifikasi, mendahulukan tes, meninjau batas kepercayaan, atau menyusun PR yang bisa direview
- Banyak bagian dari kerja engineer senior tidak terlihat di diff
- menampilkan asumsi
- menulis spesifikasi
- memecah pekerjaan ke unit yang bisa direview
- memilih desain yang membosankan tapi aman
- meninggalkan bukti bahwa hasilnya benar
- membatasi perubahan ke ukuran yang benar-benar bisa direview manusia
- Alasan agen melewati langkah-langkah ini mirip dengan engineer junior: sinyal reward disetel ke “tugas selesai”, bukan ke “tugas selesai lengkap dengan dokumen spesifikasinya”
- Repositori Agent Skills sudah melampaui 26K stars, dan tidak hanya membahas README tetapi juga alasan di balik pilihan desain, kaitannya dengan SDLC standar dan praktik engineering publik Google, hingga pola yang bisa diambil tanpa perlu memasangnya
Arti sebenarnya dari skill
- Skill adalah file Markdown dengan frontmatter yang disuntikkan ke konteks agen sesuai situasi, bentuknya berada di antara potongan system prompt dan runbook
- Skill bukan dokumen referensi, dan juga bukan kumpulan pengetahuan seperti “semua yang perlu diketahui tentang testing”
- Skill yang berguna adalah workflow yang benar-benar diikuti agen
- ada urutan langkah
- menghasilkan bukti di checkpoint
- berakhir dengan kriteria selesai yang jelas
- Jika Anda memasukkan esai 2.000 kata tentang praktik terbaik testing ke konteks, agen bisa menghasilkan kalimat yang terdengar meyakinkan lalu tetap melewati testing yang sebenarnya
- Sebaliknya, jika yang dimasukkan adalah workflow yang meminta menulis tes yang gagal terlebih dulu, menjalankannya dan memastikan tes gagal, lalu menulis implementasi minimum agar lolos, memverifikasi kelolosannya, dan melakukan refactor, maka agen memiliki pekerjaan nyata untuk dilakukan dan manusia bisa memverifikasinya
- Pembeda kuncinya adalah proses di atas prosa, workflow di atas referensi, dan langkah dengan kriteria selesai di atas esai tanpa kriteria selesai
- Banyak repositori “AI rules” gagal efektif karena aturannya berhenti sebagai esai, bukan workflow
Struktur SDLC dan slash command
- 20 skill di repositori ini dibangun di atas 6 tahap siklus hidup, lalu 7 slash command diletakkan di atasnya
-
Tahap dan perintah
/spec: tahap Define untuk menentukan apa yang akan dibuat/plan: tahap Plan untuk memecah pekerjaan/build: tahap Build untuk mengimplementasikan dalam vertical slice/test: tahap Verify untuk membuktikan perilaku/review: tahap Review untuk menangkap masalah yang lolos/ship: tahap Ship untuk mengirimkan hasil dengan aman ke pengguna/code-simplify: perintah penyederhanaan yang diterapkan lintas seluruh alur- Struktur ini mengikuti alur SDLC organisasi engineering yang berfungsi dengan baik; yang berbeda antarorganisasi biasanya hanya kosakatanya
- Di Google, ini muncul sebagai alur design doc → review → implementation → readability review → launch checklist; di Amazon, sebagai working-backwards memo dan bar raiser
- Masalah baru pada agen coding AI adalah sebagian besar agen secara default melewati mayoritas tahap ini
- Saat diminta membuat fitur, yang keluar hanya implementasi; spesifikasi, rencana, tes, review, dan checklist rilis tidak dijalankan
- Skill memaksa agen melewati langkah-langkah yang biasanya dipaksakan sendiri oleh engineer senior, dan menyebarkan kode tanpa prosedur itu bisa berujung pada insiden
- Fitur kompleks bisa mengaktifkan 11 skill secara berurutan, sedangkan perbaikan bug kecil mungkin hanya memakai 3 skill
- Router
using-agent-skills menentukan skill mana yang berlaku untuk tugas saat ini, sehingga workflow berkembang mengikuti cakupan nyata, bukan cakupan yang diasumsikan
Prinsip yang menopang cara kerjanya
-
1. Proses di atas prosa
- Workflow bisa diterjemahkan agen menjadi tindakan, sedangkan esai tidak
- Prinsip yang sama berlaku juga untuk tim manusia
- Jika handbook tim panjangnya 200 halaman, dokumen itu tidak akan dibaca saat situasi tertekan; tetapi workflow kecil dengan checkpoint jauh lebih mungkin benar-benar dijalankan
-
2. Tabel anti-rasionalisasi
- Pilihan desain paling unik di Agent Skills, dan yang layak diadopsi tim lain, adalah tabel anti-rasionalisasi
- Setiap skill memuat alasan-alasan umum yang mungkin dipakai agen atau engineer yang kelelahan untuk melewati workflow, beserta bantahan yang sudah ditulis sebelumnya
- Contohnya sebagai berikut
- “Tugas ini terlalu sederhana jadi tidak butuh spesifikasi” → kriteria penerimaan tetap berlaku. 5 baris boleh, 0 baris tidak
- “Tes akan saya tulis nanti” → “nanti” justru masalah utamanya. Tidak ada nanti. Tulis tes yang gagal lebih dulu
- “Tes sudah lolos, jadi mari deploy” → tes yang lolos adalah bukti, bukan pembuktian final. Perlu dicek apakah runtime sudah diverifikasi, perilaku yang terlihat pengguna sudah tervalidasi, dan manusia sudah membaca diff-nya
- LLM sangat mahir dalam rasionalisasi, dan bisa menulis paragraf yang terdengar masuk akal tentang kenapa tugas tertentu tidak perlu spesifikasi atau perubahan tertentu boleh di-merge tanpa review
- Tabel anti-rasionalisasi adalah bantahan yang sudah disiapkan untuk kebohongan yang bahkan belum sempat diucapkan agen
- Pola ini juga efektif untuk tim manusia
- Penurunan kualitas engineering biasanya bukan karena seseorang memutuskan melakukan hal buruk, melainkan karena menerima pembenaran yang terdengar masuk akal untuk melewati prosedur yang tidak ingin dijalani
-
3. Verifikasi tidak bisa dinegosiasikan
- Semua skill berakhir pada bukti yang konkret
- Tes yang lolos, output build yang bersih, runtime trace yang menunjukkan perilaku yang diharapkan, atau persetujuan reviewer menjadi kriteria selesai
- “Terlihat masuk akal” tidaklah cukup
- Ini adalah prinsip yang sama yang membuat harness Anthropic bisa pulih dari kegagalan, pemisahan planner/worker/judge di Cursor benar-benar menangkap bug, dan long-running agent menjadi bisa dipulihkan
- Karena agen adalah generator, perlu ada sinyal terpisah untuk menentukan apakah pekerjaan benar-benar selesai, dan skill menanamkan sinyal itu ke dalam tiap workflow
-
4. Progressive disclosure
- Pada awal sesi, semua 20 skill tidak dimasukkan sekaligus ke konteks
- Hanya skill yang dibutuhkan sesuai tahap saat ini yang diaktifkan
- Meta-skill kecil bernama
using-agent-skills berperan sebagai router yang menentukan skill yang sesuai untuk tugas saat ini
- Ini menerapkan pelajaran dari harness engineering pada level skill
- Setiap token yang dimuat ke konteks akan mengurangi performa di tempat lain, jadi hanya hal relevan yang harus dimuat dan sisanya dibiarkan di disk
- Progressive disclosure adalah cara memasukkan pustaka 20 skill ke slot 5K token tanpa mencemari keseluruhan konteks
-
5. Disiplin cakupan
- Meta-skill mengenkode prinsip yang tidak bisa dinegosiasikan: “hanya sentuh yang diminta”
- Jangan refactor sistem yang berdekatan, jangan menghapus kode yang belum sepenuhnya dipahami, dan jangan memutuskan menulis ulang seluruh file hanya karena melihat TODO
- Agen bisa saja mencoba memodernisasi 3 file yang tidak terkait saat sedang memperbaiki satu bug
- Disiplin cakupan adalah faktor penentu terbesar apakah PR agen bisa di-merge atau justru harus dibatalkan
- Ini juga sejalan dengan norma code review Google, di mana reviewer boleh menahan PR yang mencoba melakukan lebih dari satu hal
Keterkaitan dengan praktik engineering Google
- Agent Skills banyak mencerminkan praktik dari Software Engineering at Google dan budaya engineering Google yang dipublikasikan secara terbuka
- Banyak elemen yang membuat software berskala Google tetap berjalan sudah terdokumentasi secara publik, dan justru bagian inilah yang paling sering dilewati agen
-
Korespondensi antara skill dan praktik
api-and-interface-design: mencerminkan Hyrum’s Law. Semua perilaku API yang bisa diamati pada akhirnya akan diandalkan seseorang, sehingga desain harus mempertimbangkannyatest-driven-development: mencerminkan piramida tes ~80/15/5 dan Beyoncé Rule. Prinsipnya, “kalau kamu menyukainya, seharusnya kamu menambahkan tes”; yang menangkap bug adalah tes, bukan perubahan infrastruktur- DAMP over DRY dalam testing: filosofi testing Google menganggap kode tes harus tetap terbaca seperti spesifikasi, walau sedikit menerima duplikasi. Tes yang terlalu diabstraksikan adalah antipola yang sudah dikenal
code-review-and-quality: mencerminkan ukuran ~100-line PR serta label tingkat keparahan Critical / Nit / Optional / FYI. PR besar cenderung tidak benar-benar direview dan mudah lolos sebagai formalitascode-simplification: mencerminkan Chesterton’s Fence. Jangan menghapus sesuatu sebelum memahami mengapa itu dipasanggit-workflow-and-versioning: mencerminkan trunk-based development dan atomic commitsci-cd-and-automation: mencerminkan Shift Left dan feature flags. Masalah harus ditangkap sedini mungkin, dan deployment perlu dipisahkan dari releasedeprecation-and-migration: mencerminkan code-as-liability. Setiap baris yang dipertahankan harus dirawat selamanya, jadi permukaan yang lebih kecil lebih diutamakan- Konsep-konsep ini bukan hal baru, tetapi tidak tertanam secara default pada agen
- Walaupun frontier model pernah melihat frasa “Hyrum’s Law” di data pelatihannya, itu tidak berarti ia akan otomatis menerapkannya saat merancang API pada pukul 3 pagi
- Skill membuat praktik-praktik ini benar-benar diterapkan agen saat bekerja
Cara penggunaan di dunia nyata
Pola yang bisa diambil tanpa perlu instalasi
-
Jadikan anti-rasionalisasi sebagai praktik tim
- Tim perlu menuliskan kebohongan yang biasa mereka katakan kepada diri sendiri
- Contohnya: “tes akan saya perbaiki setelah rilis”, “perubahan ini terlalu kecil jadi tidak butuh dokumen desain”, atau “kita punya monitoring, jadi aman”
- Tambahkan bantahan untuk tiap kalimat, lalu simpan di
AGENTS.md atau wiki engineering agar perdebatan berkurang dan jalan pintas lelah di Jumat sore bisa dicegah
-
Tulis dokumen internal sebagai proses, bukan prosa
- Jika Anda sedang menulis dokumen 2.000 kata berjudul “bagaimana kami mendekati X”, berarti Anda sedang menulis materi referensi
- Ubah menjadi workflow dengan checkpoint, dan dokumen itu bisa menyusut menjadi 400 kata sekaligus lebih mungkin benar-benar dijalankan
- Prinsip ini berlaku untuk panduan onboarding, runbook, maupun agent skill
-
Jadikan verifikasi sebagai kriteria selesai yang tegas
- Langkah terakhir dari setiap pekerjaan haruslah “menghasilkan bukti”
- Ini berlaku untuk agen, engineer, maupun pekerjaan individual
- Bukti bisa berupa tes hijau, screenshot, log, atau persetujuan review—apa pun yang membuktikan pekerjaan memang selesai
- Tanpa bukti, pekerjaan belum selesai, dan “terlihat masuk akal” tidak menutup loop
-
Terapkan progressive disclosure ke semua buku aturan
- Jangan menulis handbook 50 halaman; tulislah router kecil yang mengarahkan ke bab kecil yang sesuai konteks
- Ini berlaku untuk
AGENTS.md, runbook, playbook respons insiden, dan semua dokumen yang harus dibaca saat kondisi tertekan
-
5 prinsip yang tidak bisa dinegosiasikan untuk dimasukkan ke AGENTS.md
- Asumsi harus ditampilkan sebelum membangun. Asumsi salah yang diam-diam dipertahankan adalah mode kegagalan yang paling umum
- Jika requirement bertabrakan, berhenti dan tanyakan. Jangan menebak
- Jika perlu, harus berani tidak setuju. Agen maupun engineer bukan yes-man
- Pilih solusi yang membosankan dan jelas. Kecerdikan itu mahal
- Hanya sentuh yang diminta
Posisi skill di dalam harness
- Skill adalah satu lapisan dalam perspektif yang lebih besar tentang agent harness engineering
- Harness mencakup model dan semua yang dibangun di sekelilingnya, sedangkan skill adalah potongan workflow reusable yang diungkap secara bertahap ke system prompt
- Skill berada berdampingan dengan
AGENTS.md, hooks, tools, dan session log
AGENTS.md: berfungsi sebagai buku aturan yang terus diperbarui- hooks: lapisan penegakan yang deterministik
- tools: tindakan yang bisa dilakukan agen
- session log: memori yang berkelanjutan
- skills: menangani proses engineering senior
- Skill lebih penting pada long-running agents daripada agen berbasis chat
- Eksekusi panjang memperbesar semua jalan pintas
- Agen yang melewati tes dalam sesi 10 menit mungkin menghasilkan satu bug
- Agen yang melewati tes dalam sesi 30 jam bisa meninggalkan pekerjaan “arkeologi debugging” di akhir eksekusi, saat tak seorang pun lagi mengingat niat awalnya
- Semakin panjang waktu eksekusi, semakin penting scaffolding engineering senior dipaksakan sebagai kewajiban, bukan sekadar saran
- Portabilitas format skill juga penting
- File
SKILL.md yang sama bisa dipakai di Claude Code, Cursor yang menggunakan rules, Gemini CLI, Codex, dan harness lain yang bisa menerima konten system prompt
- Sekali workflow ditulis, runtime bisa memaksakannya, dan inilah kelebihan format Markdown dengan frontmatter dibanding bespoke prompt engineering
Kesimpulan
- Agen coding AI bertindak seperti engineer junior yang sangat mampu, tetapi tanpa naluri untuk pekerjaan yang tidak terlihat di diff
- Tugas engineering senior seperti menampilkan asumsi, mengatur ukuran perubahan, menulis spesifikasi, meninggalkan bukti, dan menolak merge perubahan yang tidak bisa direview akan sangat mungkin dilewati agen jika tidak dipaksa
- Pekerjaan yang semakin penting adalah mengenkode disiplin ini ke bentuk yang tidak bisa dikelabui agen dengan alasan verbal
- Skill adalah salah satu bentuknya, dan inti utamanya adalah tabel anti-rasionalisasi, progressive disclosure, proses di atas prosa, verifikasi sebagai kriteria selesai, serta struktur portabel yang membuat praktik Google yang sudah terbukti bisa dipindahkan
- Repositori Agent Skills tersedia dengan lisensi MIT, dan perspektif scaffolding yang lebih luas berlanjut di Agent Harness Engineering dan Long-running Agents
1 komentar
Komentar Hacker News
Ini nyaris seperti obat mujarab palsu. Layak dibaca dan terlihat meyakinkan, tapi pada akhirnya tetap obat mujarab palsu
Alasannya, model yang seperti mesin slot bisa saja sewaktu-waktu melewatkan persyaratan wajib yang ditulis di
AGENTS.md,memory.md, dan puluhan markdown skill, dan itu pada dasarnya sudah hampir pasti akan terjadiPendekatan harness seperti ini berpura-pura bahwa LLM mengikuti aturan secara ketat dan sempurna, lalu masalahnya cuma karena kita belum menulis aturan yang cukup jelas dan cukup banyak. Ini adalah kekeliruan kognitif yang mendasar tentang cara kerja LLM
Pada akhirnya, satu-satunya pilihan yang tidak bisa sepenuhnya dipercaya tetapi relatif lebih dapat dipercaya adalah peninjauan dan pengawasan manusia, dan kalau bisa dilakukan dua kali berturut-turut
Sisanya semua hanyalah obat mujarab palsu, dan pada titik itu kita sadar bahwa janji peningkatan produktivitasnya juga sama saja. Karena membaca kode dan membangun model mental jauh lebih sulit daripada menuangkannya ke dalam kode saat model mentalnya sudah ada
Membaca kode tergantung pada jenis kodenya, tetapi seperti keterampilan lain, itu jadi mudah dengan latihan. Ini hal yang umum dalam situasi seperti harus menangani codebase besar dan kompleks yang sudah ada sejak lama, ketika kode yang dibaca jauh lebih banyak daripada yang ditulis
Yang membuatnya lebih mudah adalah ketika kita sudah punya model mental tentang kodenya melalui dokumentasi, pengalaman sebelumnya, atau bertanya pada rekan kerja
Dengan agen pun ini bisa dilakukan. Biasanya sebelum memberi prompt ke AI saya sudah cukup paham struktur kodenya, dan jika pekerjaannya dipecah dengan hati-hati, meninjau kode hasil generasi jadi sangat mudah. Rasanya seperti membaca ulang buku yang sudah pernah dibaca, dan kalau jarang ada yang salah biasanya langsung terlihat sehingga sebagian besar bisa ditangkap sejak awal. Apa pun caranya, peningkatan kecepatannya besar
Tapi selama beberapa bulan terakhir saya memakai spec-kit, yaitu cara penggunaan AI seperti ini, dan dalam praktiknya hasilnya sangat mengejutkan bagusnya. Saya membuat hal-hal yang hebat, dan masalah yang diajukan sebagai asumsi itu belum saya alami. Mungkin suatu hari akan terjadi, jadi saya tetap berhati-hati
Tetap saja, setelah cukup lama memakainya sendiri, saya tidak bisa begitu saja menyebutnya obat mujarab palsu. Saya sudah lebih dari 30 tahun bekerja sebagai programmer, dan merasa cukup mampu menilai apa yang benar-benar berhasil dan apa yang tidak
Ke depan saya ingin melihat harness yang menuntut, bukan sekadar meminta. Kalau disuruh berada di mode perencanaan tapi agen tidak mengikuti prosedur perencanaan yang ditetapkan, agen itu dimatikan. Meski tidak sempurna, itu tetap harus lebih baik daripada cara sekarang yang masih mengandalkan campur tangan manusia
Katanya “skill adalah file markdown dengan frontmatter yang disuntikkan ke konteks agen saat relevan”, tapi yang menentukan apakah itu relevan adalah LLM
Katanya ini “serangkaian langkah yang diikuti agen, diakhiri checkpoint yang menghasilkan bukti dan kriteria selesai yang jelas”, tapi yang bisa memutuskan apakah langkah itu diikuti juga adalah LLM
$my-skill, dan kalau begitu skill tersebut benar-benar disuntikkan ke konteks. Setelah itu LLM akan mengikutinya sejauh ia mengikuti prompt, instruksi, dan bagian konteks lainSaya menantikan hari ketika semua orang sadar mereka sudah menghabiskan lebih dari setahun main-main dengan agen dan cuma merasakan produktivitas palsu
Itu sama sekali tidak sesuai dengan pengalaman nyata saya. Saya ingin tahu pengalaman apa yang membuat orang begitu yakin akan keruntuhan tak terelakkan dari coding AI. Apakah ini keyakinan filosofis bahwa AI secara moral buruk, atau memang sudah benar-benar mencoba membuat sesuatu dengan AI, mengeksplorasinya secara cukup, lalu sampai pada kesimpulan yang kuat
Saya sudah menulis kode setiap hari selama lebih dari 30 tahun, dan menjadikannya profesi selama lebih dari 20 tahun. Saya sudah melihat tren datang dan pergi, dan juga melihat beberapa kemajuan nyata yang mengubah cara kita bekerja. Semakin banyak proyek yang saya buat dengan AI, semakin kuat keyakinan saya bahwa ini adalah perubahan yang berkelanjutan dan mendasar dalam cara membuat software dan menggunakan komputer
Saya juga melihat AI terus membaik, dan saya sendiri makin terampil memakainya untuk benar-benar menyelesaikan pekerjaan. Pekerjaan itu sudah diuji oleh beban produksi nyata di dunia nyata. Anda boleh tidak suka dengan apa yang sedang terjadi dan tidak suka rasanya bekerja dengan AI, tapi itu tidak berarti AI tidak memberi nilai nyata pada orang atau tidak benar-benar mengerjakan pekerjaan nyata
Kami sudah sepenuhnya memakai Claude Code sejak sekitar September, dan berhasil melacak peningkatannya. Kami memang meluncurkan fitur yang dipakai di produksi nyata. Untuk infrastruktur, implementasi logika bisnis, frontend, dan backend juga sama
Saya tidak melihat orang-orang membuang waktu sebanyak itu. Tapi saya setuju bahwa sebagian besar tulisan seperti ini omong kosong, termasuk yang ini. Meski begitu, pengembangan berbasis AI sudah terjadi di banyak perusahaan di seluruh dunia
Saya rasa workflow gaya agen belum sampai ke tingkat itu, tapi implementasi skill yang dipanggil manual untuk bekerja berdampingan dengan AI jelas cukup oke. Perusahaan kami belakangan ini sangat fokus pada sandboxing dan skill yang aman
Saya rasa untuk pengembangan fitur masih belum terlalu mantap, tetapi skill review dan skill Grafana yang kami tulis cukup solid
Dulu saya pernah mencoba paket skill agen yang lebih besar, tapi terasa seperti buang-buang waktu karena mencoba melakukan terlalu banyak hal. Seperti Vim, sering kali lebih baik memilih skill dari komunitas daripada memasang satu set skill utuh seperti memasang IDE
Skill berbeda untuk tiap developer dan tim, jadi terlalu personal. Daripada memasang setelan orang lain secara massal, lebih baik memperlakukannya sebagai bahan referensi untuk membuat setelan sendiri
Dari sudut pandang optimasi pencarian atau optimasi LLM, sepertinya kemudahan ditemukan skill seperti ini akan sulit kalau namanya tidak diubah: https://agentskills.io/
Kalau Addy melihat ini, saya penasaran bagaimana dia akan menjelaskannya dibandingkan dengan Superpowers: https://github.com/obra/superpowers
Saya sudah berkecimpung di pengembangan agen sejak sebelum superpowers ada, dan saya khawatir lebih dari 50% proses buatan saya sekarang tampaknya sudah dicakup oleh superpowers
Saya tidak lagi percaya pada GitHub star. Tolong ada yang kasih tahu. Apakah superpowers sekarang benar-benar sudah diadopsi? Kalau memang sangat bernilai, kenapa Boris belum mengintegrasikan konsep itu?
“kalau menurut Anda ada kemungkinan 1% saja suatu skill relevan dengan apa yang sedang Anda kerjakan, Anda wajib memanggil skill itu”
Saya tidak paham kenapa semua orang begitu antusias menghilangkan pekerjaan mereka sendiri
Benda-benda seperti ini atau “skill” tertentu mungkin tidak benar-benar akan melakukannya, tapi secara prinsip ya begitu. Ini terasa seperti alienasi dari kerja dalam skala besar
Sejauh bisa ditelusuri, manusia selalu mengurangi jumlah kerja yang dibutuhkan untuk menghasilkan output tertentu, dan itulah peradaban. Apakah kita harus kembali ke masa bercocok tanam dengan cangkul tangan demi memaksimalkan tenaga yang dipakai? Haruskah kita kembali ke masa menyalakan lampu jalan satu per satu?
Masyarakat yang tertinggal dalam otomasi menjadi lebih miskin dan pada akhirnya mati, karena bahkan orang yang lahir di sana pun pindah ke tempat yang produktivitasnya lebih tinggi. Itu terjadi di Eropa Timur, pada Amish, dan di mana pun ada masyarakat miskin yang memunculkan migrasi. Melakukan lebih banyak dengan lebih sedikit selalu menjadi hal yang menarik
Saya penasaran apakah Anda merasakan hal yang sama terhadap semua otomasi yang dibuat. Ada admin sistem model lama yang melihat perkembangan otomasi infrastruktur seperti ini juga, dan tidak suka ketika pekerjaan yang dulunya manual dialihkan ke skrip dan sistem
Di salah satu pekerjaan, tim kami membuat sistem patch otomatis untuk 30 ribu server, menjalankan patch secara otomatis dan otomatis mengeluarkan serta memasukkan sistem dari produksi. Seluruh proses menjadi tanpa sentuhan tangan, padahal dulu ada tim khusus yang menjalankannya secara manual. Apakah otomasi itu merampas pekerjaan mereka?
Dalam satu makna, ya, tapi tetap ada pekerjaan lain yang perlu dilakukan dan sekarang mereka bisa mengerjakannya
Justru itulah alasan saya suka pemrograman, komputer, dan teknologi: karena semuanya mengerjakan pekerjaan untuk kita. Utopia saya adalah dunia di mana robot melakukan semua pekerjaan berat sehingga manusia bisa melakukan apa yang mereka inginkan. AI membawa kita selangkah lebih dekat ke sana. Daripada berusaha menyisakan cukup banyak pekerjaan yang tidak diinginkan manusia agar semua tetap sibuk, saya lebih ingin fokus pada cara agar manfaat robot yang mengambil pekerjaan itu dinikmati bukan hanya oleh pemilik kaya, melainkan oleh seluruh dunia
Sekarang belum jelas semuanya akan berevolusi ke arah mana, jadi orang-orang sedang menyerahkan data mereka ke agen acak, mencari cara menyimpan dan mengakses konteks, memakai ulang prompt, dan mencoba berbagai cara untuk menangani teknologi ini
Sebagian besar dari ini mungkin akan jadi tidak berguna dalam setahun karena terintegrasi mendalam ke model generasi berikutnya. Meski begitu, mengikuti perkembangan selalu menjadi bagian yang menyenangkan dari bekerja di bidang ini
Saya rasa kubu pro maupun kontra akan agak terkejut jika data jangka panjang menunjukkan bahwa secara rata-rata peningkatan produktivitasnya terbatas, dan bahwa bahkan dengan bantuan model canggih terkini, membuat software berkualitas tetap memerlukan ketelitian dan perhatian manusia
Ini pekerjaan yang sama, hanya saja sekarang punya bor listrik alih-alih obeng. Ada orang yang membangun rumah yang bertahan ratusan tahun, ada juga yang tidak
Belakangan saya terus mendengar hal yang sama. Hal-hal yang baik untuk mengelola tim developer juga baik untuk mengelola LLM
Test case yang bagus, dokumentasi yang jelas dan ringkas, CI/CD, best practice, dan dokumen onboarding termasuk di dalamnya
Mengelola LLM makin mirip dengan mengelola tim manusia
Saya penasaran apa yang lebih baik atau berbeda dari ini dibandingkan spec-kit. Filosofinya tampak sangat mirip, dan saya juga penasaran apakah keduanya bisa dipakai bersama. Atau cuma tumpang tindih saja?
https://github.com/github/spec-kit
Saya kaget beberapa skill ini sepanjang itu. Ada yang sampai beberapa halaman dengan tabel, daftar checkbox, contoh kode, dan sebagainya
Saya penasaran seberapa umum ini. Beberapa skill seperti itu saja rasanya sudah cukup memenuhi banyak konteks
Ada eksperimen yang menarik. Coba minta LLM menulis sesuatu yang samar tapi familier. Misalnya minta “write a fib”, hampir semua LLM karena di-fine-tune pada kode akan menjawab dengan algoritma deret Fibonacci, padahal bagi nonprogrammer itu bisa berarti “tulis kebohongan kecil”
Artinya kompresi memang terjadi. Tanpa menjelaskan secara rinci apa sebenarnya deret Fibonacci itu, hasilnya bisa diungkapkan hanya dengan tiga token ambigu
Jadi kita tahu panjang prompt bukan hal yang penting. Yang penting adalah kata yang tepat, frekuensi, dan urutannya. Prompt dua halaman dan prompt dua kalimat bisa menghasilkan hasil yang sama
Sejauh ini saya berhasil dengan skill yang pendek dan fokus. Saya memperlakukannya seperti potongan konteks yang bisa dipakai ulang, tapi tetap kecil. Misalnya hanya beberapa paragraf tentang bagaimana Python dipakai di proyek saya dan bagaimana menjalankan unit test
Saya juga punya beberapa skill “info” pendek yang tidak memberi instruksi ke agen, hanya berisi informasi konteks yang berguna dan bisa diambil saat perlu
Terlalu banyak skill juga bisa jadi masalah. Karena daftar nama dan deskripsi skill pada akhirnya masuk ke konteks pada titik tertentu
Bahkan pada konteks LLM kecil 128k itu sekitar 10%, dan pada jendela konteks 1M milik model besar nyaris tidak terasa
Mungkin saya terlalu konservatif di sini. Masih banyak yang perlu dieksplorasi
“Sebagian besar pekerjaan engineer senior ada di bagian yang tidak terlihat di diff”
Agent Skills adalah upaya Addy untuk menghilangkan pekerjaan itu juga. Salut, Addy :P