- Di .txt, Codex membuat versi pertama yang berfungsi untuk eksperimen algoritme generasi terstruktur yang sudah tertunda lebih dari setahun hanya dalam beberapa jam, tetapi perubahan intinya bukan pada kecepatan coding individu melainkan pada terlihatnya bottleneck kolaborasi
- Saat agen menangani implementasi, yang memperlambat tim bukan lagi penulis kode, melainkan pembuatan spesifikasi presisi seperti roadmap, kriteria penerimaan, dan dokumen desain yang bisa langsung dieksekusi oleh agen
- Ketika biaya menulis kode menurun, prototipe dan alat internal yang sebelumnya tidak akan dibuat menjadi bertambah; sementara kecepatan yang bisa diserap pengguna tetap sama, sehingga disiplin fokus untuk menentukan apa yang tidak akan dibuat menjadi semakin penting
- Agen dapat mengekstrak keputusan implisit dan konvensi dari Slack, PR, issue, commit, dan dokumen desain untuk membangun basis pengetahuan, tetapi tidak dapat sepenuhnya memulihkan konteks bersama yang dibangun langsung oleh manusia
- Keunggulan dalam 10 tahun ke depan kemungkinan besar akan dimiliki bukan oleh perusahaan dengan model terbaik, melainkan oleh perusahaan yang mampu menjaga konsistensi organisasi yang tetap selaras dengan himpunan keputusan yang makin ringkas bahkan pada skala 50, 200, hingga 2.000 orang
Bottleneck yang Diubah oleh Agen Coding
- Eksperimen yang tertunda lebih dari setahun di .txt adalah pekerjaan untuk menguji algoritme generasi terstruktur dan alternatif open source, serta memeriksa persoalan yang lebih dekat ke “apakah ini menghasilkan distribusi token yang benar” ketimbang sekadar “apakah ini menerima string ini”
- Eksperimen ini terus ada di roadmap, tetapi setelah pendekatannya dijelaskan ke Codex selama sekitar 30 menit, versi pertama yang berjalan dibuat hanya dalam beberapa jam
- Agen coding memang sudah sangat mengubah cara individu menulis kode, tetapi sulit untuk langsung menyimpulkan bahwa peningkatan produktivitas individu otomatis berarti peningkatan kecepatan seluruh industri perangkat lunak
- Perangkat lunak yang berpengaruh sering kali dibuat melalui kolaborasi banyak orang, sehingga unit analisis yang lebih menarik bukan produktivitas individu melainkan kolaborasi
- Perangkat lunak lebih mirip hasil sisa setelah orang-orang bernegosiasi tentang apa yang harus dilakukan sistem; kode itu penting, tetapi merupakan residu dari pekerjaan yang lebih sulit
Roadmap Menjadi Batasannya
- Dalam tim yang implementasinya ditangani agen, yang memperlambat laju adalah pekerjaan membuat spesifikasi yang cukup presisi agar bisa langsung diambil dan dijalankan oleh agen
- Roadmap, kriteria penerimaan, dan “apa yang sebenarnya kita inginkan” harus ditulis dengan jelas dalam bentuk seperti test suite, tiket, dan dokumen desain
- Fitur diimplementasikan sangat cepat, dan alih-alih engineer menunggu engineer lain, muncul situasi di mana mereka menunggu spesifikasi berikutnya yang ditulis dengan benar
- Bottleneck bergeser dari orang yang menulis kode ke orang yang memutuskan kode seperti apa yang harus ada, dan itu pada akhirnya adalah persoalan manajemen
Kode yang Lebih Murah Menuntut Lebih Banyak Kesepakatan
- Saat biaya menulis kode turun, hasilnya bukan kita mengeluarkan 10% usaha untuk hasil yang sama, melainkan kita menginvestasikan usaha yang sama pada hasil yang sebelumnya dianggap tidak layak dibuat
- Prototipe yang tiga bulan lalu mungkin dianggap “buang-buang waktu” kini bisa dibuat dalam satu sore, dan alat internal tanpa permintaan yang jelas bisa dibuat lalu dilupakan
- Kecepatan fitur yang bisa diserap pengguna pada dasarnya tetap sama, entah tim merilis 10 fitur atau 50 fitur
- Seperti yang dikatakan Steve Jobs pada 1997, “fokus adalah mengatakan tidak”, dan Apple memangkas sekitar 70% lini produknya pada tahun itu
- Karena dengan agen rasanya lebih mudah untuk merilis fitur baru, disiplin untuk memutuskan bukan hanya apa yang akan dibuat tetapi juga apa yang tidak akan dibuat menjadi semakin sulit
Konteks Menjadi Sumber Daya Utama
- Negosiasi dan kesepakatan berjalan di atas konteks bersama dalam organisasi
- Konteks mencakup apa yang sedang dibangun, mengapa itu penting, apa yang sudah dicoba, siapa yang memutuskan apa, mana yang inti, dan mana yang hanya jejak sisa
- Manusia dalam tim membangun konteks ini secara alami dengan berada di ruangan yang sama, membaca channel Slack yang sama, dan men-debug insiden yang sama pada pukul 2 dini hari
- Sebagian besar konteks ini tidak terdokumentasi, dan ketika engineer senior berkata dalam review PR, “ini akan merusak migrasi”, sering kali mereka sedang memakai konteks yang tidak pernah ditulis
- Agen tidak bisa menyerap konteks dengan cara seperti itu; ia tidak berada di ruangan, tidak setengah mendengar percakapan perencanaan, dan tidak membawa ingatan tentang insiden sebelumnya
- Konteks yang tidak dimasukkan ke dalam prompt, file tree, tools, atau instruksi eksplisit tidak dimiliki agen secara andal
- Tanpa konteks, agen bisa menghasilkan jawaban yang terdengar meyakinkan untuk pertanyaan yang sedikit keliru
- Di .txt, saat agen melakukan pekerjaan yang berguna, pada praktiknya manusialah yang sudah lebih dulu mengerjakan pekerjaan konteks, dan itu tidak berarti 10 engineer berikutnya otomatis akan memiliki gambaran itu
- Konteks yang selama ini selalu diandalkan organisasi secara implisit kini menjadi input yang membatasi kecepatan, dan manusia cenderung membiarkannya tetap implisit karena sebelumnya tidak ada objek eksplisit yang perlu membacanya
Loop di Mana Agen Memproduksi Konteks
- Membuat konteks yang mudah dikonsumsi manusia adalah pekerjaan yang pada umumnya tidak disukai orang
- Agen unggul dalam membaca tanpa terlewat komentar PR, issue yang sudah ditutup, pesan commit, dokumen desain lama, dan arsip Slack, lalu mengekstrak pola yang tak pernah didokumentasikan siapa pun
- Di .txt, mereka mulai membangun agen yang merayapi codebase, issue, PR, dan thread untuk mengubah keputusan implisit, konvensi, dan “mengapa ini dilakukan” menjadi basis pengetahuan
- Basis pengetahuan ini memuat bukan sekadar “modul ini ada”, tetapi juga konteks seperti “modul ini aneh karena migrasi harus mempertahankan perilaku lama” atau “benchmark ini penting karena optimisasi sebelumnya diam-diam mengubah distribusi”
- Agen lain menggunakan basis pengetahuan ini ketika harus bertindak di dalam codebase
- Osmosis yang sebelumnya dilakukan manusia secara informal dieksternalisasi ke bentuk yang bisa dibaca baik oleh agen maupun manusia
- Agen yang mengonsumsi konteks memerlukan agen yang memproduksi konteks, dan ketika loop ini berjalan, organisasi memperoleh fondasi terdokumentasi yang sebelumnya tidak akan mereka buat sendiri
- Namun, yang dihasilkan loop ini selalu merupakan gambaran yang parsial
- Seperti kata Michael Polanyi, “kita tahu lebih banyak daripada yang bisa kita katakan”, dan sebagian konteks inti ada justru karena tidak pernah dituliskan, bahkan bisa berubah saat dituliskan
- Lapisan osmosis yang dibangun manusia lewat interaksi langsung tidak bisa sepenuhnya direkonstruksi hanya dari hasil samping yang terdokumentasi
- Hasil akhirnya lebih dekat ke titik awal yang berguna daripada pemulihan yang utuh, dan apakah itu cukup untuk menghasilkan efek kumulatif masih menjadi pertanyaan eksperimental
Parit Pertahanan Baru Ada pada Organisasi, Bukan Teknologi
- Pemenang 10 tahun ke depan belum tentu perusahaan yang memiliki model terbaik atau infrastruktur agen terbaik, melainkan kemungkinan besar perusahaan yang bisa menghasilkan output lebih banyak per orang sambil tetap selaras dengan himpunan keputusan yang makin ringkas saat tumbuh menjadi 50, 200, atau 2.000 orang
- Perusahaan seperti itu adalah organisasi yang sudah tahu sejak sebelum agen datang bahwa masalah tersulit mereka adalah konsistensi
- Ini adalah persoalan budaya dan manajemen, dan memang selalu demikian
- Alat generasi sebelumnya seperti IDE, version control, CI, microservices, dan DevOps menjanjikan penyelesaian koordinasi lewat tools yang lebih baik, tetapi pada praktiknya mereka terutama memperbesar konsistensi organisasi yang memang sudah ada
- Tim kecil mendapatkan konsistensi hampir secara cuma-cuma, sehingga efek amplifikasinya umumnya positif; itulah mengapa banyak suara yang sangat mendukung agen datang dari tim kecil, karena dalam konteks mereka hal itu memang kebanyakan benar
- Setelah melewati skala tertentu, konsistensi harus diciptakan dan dipertahankan, dan efek amplifikasi menjadi tajam ke dua arah
- Organisasi yang baik menjadi lebih baik, dan organisasi yang buruk bergerak ke arah rusak lebih cepat
- Agen adalah amplifier yang jauh lebih besar daripada tool sebelumnya; ia terlalu dibesar-besarkan sebagai sarana agar individu menulis kode lebih cepat, dan justru diremehkan sebagai sarana untuk mengeksternalisasi apa yang diketahui organisasi
Agen sebagai Perpanjangan Budaya Perusahaan
- Agen bisa terasa seperti perpanjangan dari cara berpikir kita sendiri, dan sensasi itu sangat kuat
- Tantangan yang lebih sulit adalah menjadikan agen sebagai perpanjangan budaya perusahaan
- Untuk itu dibutuhkan budaya menulis, manajemen yang cukup reflektif untuk mengidentifikasi titik-titik di mana diri mereka masih menjadi bottleneck konteks, serta orang-orang yang memperlakukan konsistensi sebagai output nyata yang harus dipertahankan
- Hal yang baru adalah bahwa sebagian dari semua ini sekarang sudah bisa dibangun
- Loop membaca dan mengekstrak adalah salah satu bentuknya, dan bentuk-bentuk lain mungkin akan muncul
1 komentar
Komentar Hacker News
Sepanjang karierku, para engineer selalu mengeluhkan semua hal yang mengganggu beberapa jam kondisi fokus saat ngoding—yang mereka anggap sebagai aktivitas paling esensial dan suci—seperti rapat tim, ritual agile, pelacak isu, backlog, Slack, email, dan review desain. Lalu ketika mesin mulai menulis kode lebih cepat daripada mereka, tiba-tiba tanpa malu mereka malah berkhotbah tentang pentingnya aktivitas kolaboratif serta betapa remeh kode dan kegiatan ngoding itu.
Bukan berarti itu salah, tetapi tetap mengejutkan melihat kemunafikan terang-terangan dari orang-orang yang sampai setahun lalu hampir selalu jadi pihak paling antisosial dan paling tidak kolaboratif di tim mana pun.
Bagaimanapun, dua hal ini bisa benar secara bersamaan: menulis kode bukan bottleneck sehingga fitur bisa dikembangkan lebih cepat daripada kecepatan deploy yang memungkinkan, dan gangguan saat mengerjakan sesuatu yang butuh konsentrasi mendalam tetap menyebalkan dan memutus alur kerja.
https://en.wikipedia.org/wiki/Group_attribution_error
Rapat yang benar-benar meningkatkan sinkronisasi antara pelanggan dan coder itu langka dan berharga. Di organisasi besar, rapat seremonial sering bertambah karena alasan yang salah. Orang-orang mencoba menyisipkan diri ke dalam proses antara pelanggan dan coder demi menunjukkan keberadaan mereka.
Secara pribadi, aku suka rapat dengan pelanggan, pengguna akhir, desainer UX, dan stakeholder yang nyata. Aku benci rapat dengan orang-orang yang sibuk karena politik kantor dan menghabiskan bandwidth demi pengaruh internal. Tidak perlu ada manajer menengah lain yang menyela di antara aku dan para penggunaku.
Sebaliknya, di dunia baru tempat penulisan kode menjadi sangat cepat, dan bagian yang sulit justru memahami kebutuhan bisnis dan teknis yang harus dicapai, orang yang sama bisa saja memprioritaskan ritual tersebut lebih tinggi dan rela menerima gangguan saat agen AI menulis kode.
Mengubah pendapat ketika fakta situasinya berubah bukanlah kemunafikan.
Ada banyak alasan mengapa kalau kamu mengerjakan proyek kreatif dengan seseorang di luar kantor, yang pertama terlintas bukan Scrum ceremony atau Jira. Menghargai kolaborasi sambil tetap mengkritik hal-hal itu sepenuhnya konsisten.
Tim mengeluh pekerjaan terlalu banyak sampai tidak sanggup mengerjakan apa pun, lalu manajer memasukkanku. Tapi tiba-tiba mereka tidak mau menyerahkan apa pun. Sekarang pun aku sedang tepat di tengah situasi seperti itu.
Tim bilang mereka “benar-benar kewalahan”, tetapi masih punya energi untuk bersikeras bahwa hampir semua pekerjaan yang bisa kutangani tetap paling baik dikerjakan sendiri dan mereka tidak butuh bantuan. Bagiku sih tidak masalah, aku bisa duduk santai sambil tetap dibayar. Tapi baunya sama saja.
A: mereka tidak mau mengakui bahwa mereka bisa digantikan dan pekerjaannya tidak seunik itu, B: mereka juga tidak mau mengakui bahwa bottleneck-nya adalah mereka sendiri, bukan proses atau beban kerja.
Sepertinya para engineer veteran sudah tahu bahwa akar masalah kecepatan selalu lebih banyak ada pada organisasi daripada teknologi.
Ketidakmampuan bisnis mendefinisikan roadmap yang fokus dan produktif sudah lama menjadi masalah dalam software engineering. Terus-menerus melompat ke hal baru yang berkilau dengan ROI nyaris nol, sambil tidak pernah memberi ruang untuk menangani utang teknis sistemik, dalam jangka panjang merusak banyak perusahaan tempat aku pernah bekerja.
Aku tahu engineer junior yang memakai C++ sepanjang tahun tetapi tetap tidak memahami std::unique_ptr, dan orang seperti ini hampir selalu yang paling lambat di seluruh tim.
Dulu ketika menulis evaluasi kinerja untuk engineer junior, performa memang sangat ditentukan oleh kecepatan, kurang lebih diukur dari berapa banyak baris kode bebas bug yang ditulis dalam jangka waktu tertentu. Engineer junior yang bagus menerima fitur yang sudah didefinisikan dengan jelas lalu menulis kode yang baik dengan cepat, sedangkan yang kurang bagus menerima tugas yang sama lalu menulisnya lambat, atau cepat tapi penuh bug, sehingga menciptakan jauh lebih banyak pekerjaan debugging dan penulisan ulang.
Jika justifikasi bisnis, cakupan, input, dan output yang diinginkan dipahami dengan jelas, model data, desain sistem, dan kode biasanya hampir muncul dengan sendirinya, atau setidaknya menjadi jauh lebih jelas.
— Melvin E. Conway, 1967
Pertama-tama perlu dipikirkan dulu apakah kamu benar-benar memahami apa itu scaling law seperti Chinchilla, dan bagaimana reinforcement learning dengan verifikasi bekerja secara fundamental.
Aku sepenuhnya setuju bahwa batas mendasarnya adalah apakah bisnis mampu mengekspresikan dirinya dan strateginya secara konsisten.
Tetapi keuntungannya sekarang adalah kita pada dasarnya bisa membuat prototipe secara gratis. Dulu kita harus sangat hati-hati dalam investasi tenaga engineering, tetapi sekarang kita bisa mencoba jauh lebih banyak hal dalam batas waktu yang sama.
Menentukan fitur dan perbaikan bug mana yang dirilis kapan, serta bagaimana produk secara keseluruhan dikembangkan dan dikelola, selalu menjadi tantangan yang sebenarnya, dan banyak bagian dari strategi itu bergantung pada feedback loop yang tidak bisa dipercepat oleh AI dengan cepat.
Pada saat yang sama, aku juga merasa banyak pemimpin di sisi bisnis yang menjadikan kecepatan engineer sebagai kambing hitam alih-alih bertanggung jawab atas keputusan buruk dari pihak mereka sendiri.
Biasanya bottleneck memang kode, tetapi bukan penulisan kode, melainkan kode itu sendiri. Dalam karierku, ada tak terhitung banyaknya keterlambatan karena aplikasi yang lambat.
Harus memakai editor berbasis Eclipse yang lambat dan secara berkala freeze atau crash. Proses build memakan waktu 15–20 menit. Juga sering menemui web app yang butuh waktu selamanya untuk menyelesaikan hal yang seharusnya selesai maksimal dalam 50ms.
Daftar seperti ini bisa terus berlanjut. Setiap delay adalah gangguan yang menghancurkan fokusku. Sekarang aku ada di posisi manajerial, menangani puluhan orang dan gangguan administratif, tetapi aku masih tetap menulis kode di perusahaan.
Kalau software-nya lambat, itu langsung jadi prioritas terendahku. Aku tidak peduli siapa yang terdampak. Kalau itu benar-benar penting, kita semua tidak akan disandera oleh sirup software lambat ini yang menyeret kita ke bawah.
Kode adalah utang.
Mudah melihat kode sebagai aset, tetapi pada dasarnya ia adalah utang. Beberapa “bottleneck” menuju kode baru ada untuk memastikan output yang dihasilkan lebih besar daripada utang yang ikut bertambah. Agen yang membuat lebih banyak kode lebih cepat berarti juga membuat lebih banyak utang lebih cepat.
Banyak antusiasme dan skeptisisme terhadap agen coding pada dasarnya berkisar pada apakah peningkatan produktivitas langsung—yakni output langsung seperti fitur baru, produk baru, dan pendapatan baru—cukup untuk mengimbangi kenaikan utang jangka panjang. Jawabannya mungkin baru akan terlihat dalam 1–3 tahun ke depan, dan akan berbeda tergantung bidangnya.
Dari sudut pandang ini, upaya memasukkan bottleneck seperti itu langsung ke dalam workflow berbasis agen cukup masuk akal. Memberi agen coding konteks tambahan yang menekankan visi proyek yang konsisten dan bisa menolak fitur baru atau proses tanpa batasan memang bernilai.
Apakah memang ini yang ingin disampaikan tulisan tersebut? Bahwa sebagian agen akan mengambil tanggung jawab product management, menyintesis sebanyak mungkin hal menjadi visi produk yang kohesif, lalu mengingatkan visi itu seketat mungkin kepada agen coding?
Haruskah agen seperti itu meninjau proposal baru dan pull request baru dari sudut pandang “kesesuaian dengan gambaran besar”? Sebut saja itu konteks, visi, atau nama lain apa pun.
Agen seperti ini mungkin sangat baik dalam menyintesis konteks dan menyajikan roadmap yang tampak konsisten secara bahasa dengan nilai dan visi tim. Tapi aku ragu mereka bisa punya daya nilai seperti manajer atau tim yang baik. Menyetujui roadmap tertentu dengan cepat dan meyakinkan bisa jadi justru lebih banyak mudaratnya daripada manfaatnya.
Kode minimum yang diperlukan untuk menyelesaikan kebutuhan bisnis tanpa menambah kompleksitas adalah aset yang datang bersama utang pemeliharaan. Ini seperti traktor petani: aset yang butuh perawatan, dan jika diabaikan akan terdepresiasi karena bit rot.
Kode yang dibuat untuk menciptakan kompleksitas yang tidak perlu adalah utang murni.
Benar, tetapi menulis kode selalu mengajarkan sesuatu.
Aku pernah bekerja di startup seukuran pendiri sampai perusahaan publik bernilai puluhan miliar dolar, dan aku belum pernah melihat spesifikasi produk, pitch deck, atau PRD yang benar-benar menjelaskan solusi yang akan menyelesaikan masalah jika diimplementasikan sesuai dokumen. Saat benar-benar membangunnya, kamu baru belajar bagaimana itu seharusnya bekerja.
Software adalah medium yang kompleks dan interaktif. Satu-satunya cara menghasilkan produk yang bernilai selalu dengan beriterasi di dalam kode bersama orang-orang yang ingin memahami dan menyelesaikan masalah. Rapat dan diagram juga membantu, tetapi sampai software yang berjalan benar-benar ditulis, kita tidak tahu apakah kita benar-benar punya sesuatu.
“Tujuannya adalah menguji algoritme generasi terstruktur kami dan padanan open source-nya, menggantikan pertanyaan naif ‘apakah ini menerima string ini?’ dengan pertanyaan yang lebih dekat ke masalah nyata, ‘apakah ini menghasilkan distribusi token yang benar?’… Bulan lalu aku menjelaskan caranya ke Codex selama 30 menit. Beberapa jam kemudian, versi pertama yang berfungsi sudah ada. Itu saja.”
Ini justru membuktikan bahwa bottleneck-nya memang kode. Hanya saja sekarang AI yang menulis kode itu.
Orang yang berpikir “bottleneck bukanlah kode” sebenarnya sudah pernah mendiskusikan tujuannya dan sudah menatanya secara konsisten di kepala mereka.
Mengatakan kode adalah bottleneck tidak harus berarti “aku ingin fitur ini tapi butuh berbulan-bulan untuk mengodingnya”. Bisa juga berarti “aku sudah ingin fitur ini selama 2 tahun, tetapi terus menundanya karena friksi untuk duduk, menuangkannya ke kode, dan menghabiskan 5–10 hari”.
Kalau kode bukan bottleneck, dia pasti tinggal duduk dan menulisnya sendiri. Tetapi dia tidak ingin mengeluarkan usaha dan waktu untuk mengoding langsung, dan tahu bahwa itu tidak akan sesedikit memakai LLM.
Bahkan ketika spesifikasi akhir belum jelas, eksplorasi lewat penulisan kode, verifikasi, membuang hasil, dan mencoba ulang desain baru tetap lebih cepat dengan LLM. Karena bagian yang tepatnya dipercepat adalah bagian “kode”.
Dengan kata lain, bottleneck-nya memang kode.
Tulisan ini sendiri juga terasa seperti tulisan yang dihasilkan AI dengan instruksi untuk menghindari ungkapan klise, sehingga tetap membosankan untuk dibaca.
Di tulisan itu ada kalimat, “Jevons Paradox: ketika sesuatu menjadi lebih murah, kita tidak menggunakannya lebih sedikit, melainkan lebih banyak,” tetapi itu merusak makna paradoks Jevons.
Kalimat itu bukan paradoks, melainkan efek yang sangat wajar. Kalau sesuatu lebih murah, tentu pemakaiannya meningkat.
Yang sebenarnya dijelaskan paradoks Jevons adalah situasi ketika penggunaan suatu sumber daya menjadi lebih efisien sehingga jumlah yang dibutuhkan untuk tugas tertentu menurun, tetapi total penggunaan sumber daya itu justru meningkat.
Tapi bukankah kalau penggunaan sumber daya menjadi lebih efisien, harga dari “penggunaan” itu juga secara alami menjadi lebih murah?
Jadi karena efisiensi meningkat, pemakaian secara alami naik. Disebut paradoks karena ada orang yang secara naif mengira peningkatan efisiensi adalah cara yang baik untuk mengurangi konsumsi.
Hampir semua hal yang disebut “paradoks” memang sejelas ini.
Atau bahwa ketika suatu proses menjadi lebih efektif, yaitu membutuhkan waktu lebih singkat, kita malah menghabiskan lebih banyak waktu untuk proses itu?
Bottleneck untuk apa? Lebih banyak fitur?
Aku tidak yakin bahwa jumlah software menentukan keberhasilan perusahaan. Aku juga tidak melihat bahwa menangkap jumlah konteks itu begitu penting.
Yang penting adalah kualitas konteks. Seberapa baik manusia bernalar?
Lalu sikap. Seberapa baik manusia merespons situasi buruk?
Lalu pengelolaan sumber daya. Seberapa baik perusahaan mengelola orang dan uang?
Terakhir, keberuntungan. Seberapa banyak faktor di luar kendali yang berpihak pada kita?
Inilah bottleneck perusahaan yang cukup bagus menurutku. Dan rasanya agen tidak akan menyelesaikan hal-hal itu dalam waktu dekat.
Bottleneck dalam membuat aplikasi software yang dipakai bisnis non-software menjadi lebih baik adalah memastikan software itu benar-benar melakukan semua pekerjaan software yang berguna bagi bisnis.
Hal-hal yang menghemat waktu, membuat manusia lebih produktif, mengurangi kesalahan manusia, membuat bisnis lebih efisien, dan meningkatkan margin laba.
Semua ini cukup sulit diprediksi dan diukur. Kita bisa mulai dari ide yang dianggap membantu bisnis, lalu mendesain, membuat prototipe, dan mengujinya. Pada akhirnya kita membangun atau memperbaiki aplikasi software, lalu mencoba mengukur seberapa besar itu membuat bisnis menjadi lebih baik.
Dalam seluruh proses ini, memastikan bahwa software menangani masalah yang tepat dengan cara yang tepat, dan pada akhirnya benar-benar memperbaiki bisnis, adalah masalah yang sulit. Itu tidak berubah hanya karena pembuatan software menjadi lebih cepat dan mudah.
Meski begitu, kecepatan tetap sangat membantu. Kita bisa membuat prototipe, menguji, dan memperbaiki feedback loop.
Dengan AI coding assistant, hal-hal yang dulu dianggap pekerjaan developer junior sekarang bisa diwujudkan lewat prompt cepat dan agen yang berjalan di latar belakang.
Pekerjaan developer junior seperti ini kini hampir bisa diserahkan coding assistant tanpa campur tangan manusia. Backlog berkurang lebih cepat daripada item baru masuk, dan ketika kapasitas eksekusi bukan lagi masalah, item baru pun terus bertambah.
Sekarang tantangannya adalah mengikuti volume perubahan. Kami melihatnya langsung di organisasi kami.
Hanya karena kamu bisa membayangkan bottleneck lain bukan berarti generasi kode bukan bottleneck, atau bukan bottleneck saat ini. Konsep backlog itu sendiri menunjukkan bahwa itulah bottleneck-nya.
“Software adalah sisa setelah sekelompok manusia selesai bernegosiasi satu sama lain tentang apa yang seharusnya dilakukan sistem.”
Aku suka ungkapan itu. Aku terutama setuju soal konteks. Di situlah tim berpengalaman yang bertahan lama benar-benar mendapat imbalannya.
Aku pernah mengelola tim seperti itu selama puluhan tahun. Saat akhirnya departemen kami digabung, engineer dengan masa kerja paling pendek pun sudah 10 tahun.
Kalau tim sudah bersama selama itu, overhead komunikasi turun sampai hampir bisa diabaikan.
Itulah sebabnya budaya masa kerja pendek seperti capung sekarang terasa paling menyedihkan bagiku.
Sekarang aku kebanyakan bekerja sendiri. Produktivitasku sangat tinggi, tetapi cakupannya benar-benar terbatas.
Aku rindu masa ketika menjadi bagian dari tim yang bagus.
Proyek seperti apa sebenarnya yang kalian kerjakan, sampai-sampai bagian sulitnya cuma memahami fitur yang diinginkan manajemen, lalu sisanya tinggal “diketik jadi” atau sekarang diserahkan ke LLM?
Kalau memang itu pekerjaannya, tidak heran banyak orang di HN merasa LLM bisa menggantikan mereka.
Jadi kita kembali lagi berputar di lingkaran yang sama, mengungkapkan kecemasan, saling bicara tidak nyambung, lalu 30 menit kemudian menunggu kesempatan berkomentar berikutnya.
Sebagian besar kualitas kodenya jadi sampah panas akibat siklus offshoring dan PHK.