Memang kalau LLM merekomendasikan open source tertentu, saya jadi kepikiran buat mencobanya,
Tapi kalau sampai merekomendasikan produk untuk belanja, rasanya malah makin ingin diabaikan karena jadi ragu apakah benar bisa dipercaya.
Yah, mungkin suatu saat nanti ini juga akan berubah.
Learning curve-nya tidak masuk akal. Karena menjamin reproducibility, tingkat yang dituntut juga tinggi.
Bahkan kalau memakai flake, tetap rumit.
Selain itu, sepertinya secara internal menggunakan sqlite, dan performanya juga naik-turun, jadi ada sedikit fluktuasi pada waktu yang dibutuhkan untuk mereproduksi ulang lingkungan sekali.
Untuk memasukkan sudut pandang paradoks Jevons, pertama-tama kita harus menetapkan apa yang dimaksud sebagai sumber daya.
Karena ini adalah tulisan yang menganalisis prospek permintaan developer, maka sumber daya dalam tulisan ini tentu haruslah developer.
Industri yang biasanya dijelaskan oleh paradoks Jevons (mesin uap <-> batu bara) dan industri perangkat lunak memiliki banyak perbedaan.
Barang digital adalah barang non-rival dan merupakan industri dengan biaya marginal yang nyaris 0. Artinya, ini adalah industri yang berpusat pada biaya tetap.
Dalam industri seperti ini, peningkatan produktivitas umumnya berjalan ke arah pengurangan atau pembekuan tenaga kerja serta penguatan leverage tenaga kerja yang ada.
Agar paradoks Jevons berlaku, permintaan harus sangat sensitif terhadap harga, dan penurunan biaya harus langsung mengarah pada ledakan permintaan.
Pengembangan perangkat lunak tidak dilakukan oleh developer sendirian. Hambatannya bukan "biaya coding", melainkan biaya perencanaan, risiko, operasional, organisasi, dan regulasi.
Selama ini, kebanyakan perangkat lunak bukan tidak dibuat karena biayanya mahal, melainkan karena “tidak diperlukan / ROI tidak keluar / tidak mampu dioperasikan”.
Ada ilusi dalam metrik produktivitas.
Metrik yang digunakan dalam tulisan tersebut (kenaikan jumlah kode yang dihasilkan, kenaikan PR, kenaikan jumlah deployment) semuanya adalah metrik “volume aktivitas”.
Bertambahnya jumlah kode tidak berarti nilainya meningkat. Kenaikan PR berujung pada peningkatan biaya review/verifikasi, dan kode AI meningkatkan risiko kualitas/keamanan.
Artinya, kode AI justru dapat meningkatkan utang teknis, biaya debugging, dan kompleksitas operasional.
Karena itu, peningkatan produktivitas mungkin tidak akan meningkat sedramatis metrik volume aktivitas.
Mengakui adanya “jurang junior” sambil tetap mempertahankan optimisme adalah hal yang kontradiktif.
Developer, tidak seperti batu bara, tumbuh dari junior menjadi senior.
Jika jumlah junior berkurang, maka jumlah senior di masa depan juga akan berkurang. Karena itu, dalam jangka menengah hingga panjang, pool developer secara keseluruhan akan menyusut.
Pertumbuhan ukuran pasar dan pertumbuhan lapangan kerja bukanlah hal yang sama.
Khususnya AI adalah industri padat modal, bukan “industri yang memakai lebih banyak orang”, melainkan “industri yang menciptakan skala lebih besar dengan tenaga kerja yang lebih sedikit”.
Developer adalah manusia, dan upah manusia memiliki karakteristik yang berbeda dari harga batu bara.
Di pasar tenaga kerja, upah tidak turun secara sepenuhnya fleksibel, sehingga penurunan biaya tidak cukup diteruskan menjadi penurunan harga.
Upah pada kenyataannya memiliki kekakuan ke bawah. Ini disebabkan oleh upah minimum, hukum ketenagakerjaan, struktur kontrak, keadilan internal organisasi, moral, dan risiko turnover.
Artinya, ketika produktivitas meningkat, perusahaan bukan menurunkan upah, melainkan mengurangi perekrutan.
Saya setuju dengan kutipan, “Masalahnya adalah ketika itu membuat kita salah mengira vibe yang samar sebagai abstraksi yang presisi.” Pada akhirnya, abstraksi hanya benar-benar mungkin bagi orang-orang yang memahami level rendah secara bottom-up.
Saya sempat membukanya, dan ternyata tertulis
This project is no longer actively maintained....Oh... begitu ya!
Ngomong-ngomong, R.I.P. Firebase Studio :(
Firebase Studio juga menggunakan Nix
Aduh, semuanya akan mati
Jumlah responden dari negara kita ternyata jauh lebih banyak dari yang saya kira.
Saya sedang mencobanya... tapi kurang yakin.
Mungkin masalahnya ada pada prompt saya yang aneh... tapi font dan desainnya agak kurang bagus..
Memang kalau LLM merekomendasikan open source tertentu, saya jadi kepikiran buat mencobanya,
Tapi kalau sampai merekomendasikan produk untuk belanja, rasanya malah makin ingin diabaikan karena jadi ragu apakah benar bisa dipercaya.
Yah, mungkin suatu saat nanti ini juga akan berubah.
Yang tahu, diam-diam sudah memakainya juga wkwkwk
Setup yang dapat direproduksi, diimplementasikan dengan bahasa deklaratif fungsional
Tolong banyak cintai RollerCoaster Tycoon.
Learning curve-nya tidak masuk akal. Karena menjamin reproducibility, tingkat yang dituntut juga tinggi.
Bahkan kalau memakai
flake, tetap rumit.Selain itu, sepertinya secara internal menggunakan sqlite, dan performanya juga naik-turun, jadi ada sedikit fluktuasi pada waktu yang dibutuhkan untuk mereproduksi ulang lingkungan sekali.
Apa itu pemimpin, manajer, dan anggota tim yang baik? Terkadang, seseorang yang menjadi manajer juga merupakan anggota tim bagi orang lain...
Syukurlah sudah dinormalkan dengan Electron...
Setiap hari proyek baru terus bermunculan; kalau saja ada tangkapan layar, rasanya saya bakal langsung tertarik dan mencobanya.
Ternyata, di mana pun, kehidupan orang-orang kurang lebih sama saja. :)
Karena Linux tidak didukung 😭
Iya~ maksudnya sudah cukup tersampaikan hanya dengan tulisan yang dibuat dari perdebatan seperti ini
IDE dan PR sudah mati semua, tapi kode malah hidup lagi?
Untuk memasukkan sudut pandang paradoks Jevons, pertama-tama kita harus menetapkan apa yang dimaksud sebagai sumber daya.
Karena ini adalah tulisan yang menganalisis prospek permintaan developer, maka sumber daya dalam tulisan ini tentu haruslah developer.
Saya setuju dengan kutipan, “Masalahnya adalah ketika itu membuat kita salah mengira vibe yang samar sebagai abstraksi yang presisi.” Pada akhirnya, abstraksi hanya benar-benar mungkin bagi orang-orang yang memahami level rendah secara bottom-up.
Terima kasih, Canary.