Di Korea juga, karena masalah pensiun, pada akhirnya mau tidak mau harus terus memperpanjang usia pensiun (..).
Kalau terus dinaikkan dan dinaikkan, titik tipping point-nya mungkin saat itu melampaui harapan hidup rata-rata.
(Sepertinya Rusia sudah jadi seperti itu.. )
Meski pesan penulis cenderung terasa agak keras, jika dibaca baik-baik, ini bukan berarti "jangan gunakan AI". Ada usulan tentang bagaimana memanfaatkannya, dan intinya adalah bahwa pengembang sendiri tidak boleh kekurangan kemampuan.
Kalau dilihat kenapa pesan penulis terasa kuat, itu karena pesannya dibentuk sebagai sudut pandang yang menanggapi pandangan bahwa pengembangan akan menjadi mungkin dengan copilot (nuansa ketergantungan pengembangan yang tinggi pada copilot). Karena itu, pesannya digiring dalam bentuk "jangan mengambil posisi yang merusak nilai keberadaan kalian sendiri" kepada para pengembang.
Karena penulis juga bukan menyampaikan pesan "jangan gunakan AI", pada akhirnya jika AI dimanfaatkan, kemungkinan akan jatuh pada suatu titik kompromi di antaranya, jadi secara garis besar pesan Anda barusan tampaknya menjadi mirip dengan pesan itu.
Namun, di antara isi yang Anda tulis pada awalnya, saya sulit setuju dengan bagian yang menyebutnya sebagai 'sudut pandang yang bias', jadi saya menjawab terlebih dahulu.
Membuat itu baru permulaan, dan kalau mengoperasikan layanan selama sekitar 10 tahun, di tengah jalan pasti akan terjadi berbagai macam hal; untuk bisa bertahan di sana, kita perlu fondasi yang kuat... Kita harus belajar.
Pertama, dalam konteks "memanfaatkan AI di dalam domain" yang saya sebutkan, tentu saja perancangan dan koordinasi dilakukan oleh manusia...
Sebenarnya, kalau dulu mungkin lain ceritanya, tetapi sekarang ketika semua orang sudah mengetahui keterbatasan LLM, ini sudah menjadi hal yang terlalu wajar sampai rasanya tidak perlu disebutkan lagi.
Berikutnya, soal orang awam yang tidak punya pengetahuan pengembangan menggunakan LLM,
sepertinya baik artikel utamanya, Hacker News, maupun saya sendiri tidak pernah mengatakan hal itu, tetapi bagaimanapun juga, bahkan dalam kasus ini pun kualitasnya sudah mencapai tingkat yang cukup memuaskan bagi para pengguna.
Kalau bukan begitu, rasanya Bolt.new, v0, dan Cursor tidak akan mendapat penilaian seperti sekarang.
Sulit untuk mengambil keputusan sampai sejauh mana harus menemukan kembali sesuatu, dan sampai sejauh mana harus mengandalkan dependensi eksternal.
Apa pun kasusnya, memilih dependensi itu demi menghemat waktu karena saya sebenarnya bisa membuatnya sendiri, dan menjadi terikat pada dependensi karena tanpa itu saya tidak bisa membuat layanannya, adalah dua hal yang sama sekali berbeda.
Mungkin tidak memungkinkan untuk semua kode (misalnya sistem operasi), tetapi sebisa mungkin bergerak ke arah yang pertama dan berusaha seperti itu akan membantu dalam memahami sistem.
Saya rasa ada sedikit kesalahpahaman dalam memahami maksud yang ingin disampaikan penulis.
Penulis berfokus pada performa proyek yang ia kelola, stabilitas, serta arsitektur yang mudah dipelihara dan konsistensi kode, dan khususnya arsitektur serta konsistensi kode adalah salah satu bidang yang memang sangat tidak dikuasai LLM saat ini.
Khususnya di web, karena arus masuk developer sangat besar dan pola pikir "yang penting jalan" sangat kuat, ada sangat banyak kode berkualitas rendah yang terlanjur dipublikasikan. Dan karena LLM dilatih berdasarkan hal-hal seperti itu, kualitas hasil keluarannya jatuh sampai tingkat yang absurd.
Coba saja minta ke GPT, tolong implementasikan algoritma quicksort dalam js, buat dipakai di web front-end. Kalau Anda tidak bisa menemukan masalah pada hasil keluarannya, saya rasa percakapan ini tidak akan terlalu bermakna.
Melihat postingan lama penulis, sepertinya dia seorang pengembang game
Pengetahuan atau materi pengembangan game tidak banyak dipelajari oleh LLM, jadi berbeda dengan kasus aplikasi CRUD, tampaknya penulis artikel ini lebih kuat merasakan keterbatasan LLM
Saya membacanya sampai selesai, dan pada akhirnya saya pikir penulis punya sudut pandang yang agak bias karena hal ini.
Tentu saja, seperti isi artikel, apa yang disarankan itu hampir seperti nasihat yang sangat baku, jadi memang benar.
Namun, saya rasa AI sudah cukup bagus untuk CRUD dan frontend, yang punya banyak materi untuk dipelajari.
Sepertinya kita perlu memanfaatkannya semaksimal mungkin di dalam domain kita sendiri.
Poin nomor 1 benar-benar seperti mimpi buruk, perubahan yang sama sekali tidak ingin saya terima. Jadinya pelacakan riwayat kode sumber pun kehilangan makna.
Saya meminta bot AI GN mengekstrak skrip YouTube lalu merangkumnya, dan ternyata performanya cukup bagus.
Ada terlalu banyak video yang harus ditonton sampai melelahkan, jadi ini sepertinya sangat membantu.
Peribahasa itu punya makna yang terkandung di dalamnya, tapi makin banyak orang yang menafsirkannya hanya dari kata-katanya saja
Kalau argumen seperti itu jadi tren lagi, ruang rapat bakal berantakan lagi seolah tidak ada apa-apa
Para tukang paperwork bakal kegirangan dan mengamuk, lalu kegagalan yang sama diulang lagi setiap tahun
Ini sangat terkait dengan standar hukum ketenagakerjaan tiap negara.. banyak perusahaan di Amerika biasanya cukup menjalankannya secara bergiliran, dan kalau ada periode yang tidak memungkinkan, urutannya ditukar. Karena memang cukup berat.. ada juga perusahaan yang punya tim khusus on-call.
Di Eropa, hampir selalu ada kompensasi terpisah dengan alasan tugas berubah atau karena itu termasuk kerja lembur.
Di Korea, karena jebakan sistem gaji all-inclusive, biasanya dilakukan sekadarnya. Padahal on-call jelas merupakan kerja, tetapi dibungkus seolah tunjangan untuk jam tersebut adalah semacam fasilitas kesejahteraan.
Sebenarnya, memakai semua layanan itu saja sudah terasa berat, jadi keberadaan MCP adalah keunggulan besar.
Ke depannya, kalau pemeliharaan API-nya tetap bagus, sepertinya ini akan sangat berguna
Perangkat keras Apple memang hebat, tetapi perangkat lunaknya penuh dengan niat untuk mengekang pengguna.
Bahkan jika Anda hanya ingin menjalankan aplikasi yang Anda buat dan build sendiri di perangkat milik Anda, tetap perlu berlangganan seharga $100.
Kalau Anda adalah pengembang yang memakai aplikasi open source skala kecil hingga menengah dan membangunnya sendiri untuk dipakai,
daripada harus melakukan sideload dengan memanfaatkan celah di perangkat Apple sampai perlu jailbreak, lebih mudah pakai Android saja.
Di tempat kami, untuk tugas siaga dibayar setengah dari upah per jam, ada dukungan biaya komunikasi, dan jam saat benar-benar diminta membantu dihitung sebagai lembur 1,5x.
Di Korea juga, karena masalah pensiun, pada akhirnya mau tidak mau harus terus memperpanjang usia pensiun (..).
Kalau terus dinaikkan dan dinaikkan, titik tipping point-nya mungkin saat itu melampaui harapan hidup rata-rata.
(Sepertinya Rusia sudah jadi seperti itu.. )
Ringkasnya,
Penulis: pengembang harus meningkatkan dan mempertahankan kemampuannya sendiri. Bahkan AI pun tidak terlalu berhasil.
crawler: Hah? Saya sih berhasil dengan baik?
superscv: Banyak masalah...
crawler: Harus dipakai dengan penyesuaian yang tepat
superscv: Sepertinya ini sudah terlalu jauh dari pesan yang sejak awal ingin disampaikan penulis..
Meski pesan penulis cenderung terasa agak keras, jika dibaca baik-baik, ini bukan berarti "jangan gunakan AI". Ada usulan tentang bagaimana memanfaatkannya, dan intinya adalah bahwa pengembang sendiri tidak boleh kekurangan kemampuan.
Kalau dilihat kenapa pesan penulis terasa kuat, itu karena pesannya dibentuk sebagai sudut pandang yang menanggapi pandangan bahwa pengembangan akan menjadi mungkin dengan copilot (nuansa ketergantungan pengembangan yang tinggi pada copilot). Karena itu, pesannya digiring dalam bentuk "jangan mengambil posisi yang merusak nilai keberadaan kalian sendiri" kepada para pengembang.
Karena penulis juga bukan menyampaikan pesan "jangan gunakan AI", pada akhirnya jika AI dimanfaatkan, kemungkinan akan jatuh pada suatu titik kompromi di antaranya, jadi secara garis besar pesan Anda barusan tampaknya menjadi mirip dengan pesan itu.
Namun, di antara isi yang Anda tulis pada awalnya, saya sulit setuju dengan bagian yang menyebutnya sebagai 'sudut pandang yang bias', jadi saya menjawab terlebih dahulu.
Membuat itu baru permulaan, dan kalau mengoperasikan layanan selama sekitar 10 tahun, di tengah jalan pasti akan terjadi berbagai macam hal; untuk bisa bertahan di sana, kita perlu fondasi yang kuat... Kita harus belajar.
Pertama, dalam konteks "memanfaatkan AI di dalam domain" yang saya sebutkan, tentu saja perancangan dan koordinasi dilakukan oleh manusia...
Sebenarnya, kalau dulu mungkin lain ceritanya, tetapi sekarang ketika semua orang sudah mengetahui keterbatasan LLM, ini sudah menjadi hal yang terlalu wajar sampai rasanya tidak perlu disebutkan lagi.
Berikutnya, soal orang awam yang tidak punya pengetahuan pengembangan menggunakan LLM,
sepertinya baik artikel utamanya, Hacker News, maupun saya sendiri tidak pernah mengatakan hal itu, tetapi bagaimanapun juga, bahkan dalam kasus ini pun kualitasnya sudah mencapai tingkat yang cukup memuaskan bagi para pengguna.
Kalau bukan begitu, rasanya Bolt.new, v0, dan Cursor tidak akan mendapat penilaian seperti sekarang.
Sulit untuk mengambil keputusan sampai sejauh mana harus menemukan kembali sesuatu, dan sampai sejauh mana harus mengandalkan dependensi eksternal.
Apa pun kasusnya, memilih dependensi itu demi menghemat waktu karena saya sebenarnya bisa membuatnya sendiri, dan menjadi terikat pada dependensi karena tanpa itu saya tidak bisa membuat layanannya, adalah dua hal yang sama sekali berbeda.
Mungkin tidak memungkinkan untuk semua kode (misalnya sistem operasi), tetapi sebisa mungkin bergerak ke arah yang pertama dan berusaha seperti itu akan membantu dalam memahami sistem.
Saya rasa ada sedikit kesalahpahaman dalam memahami maksud yang ingin disampaikan penulis.
Penulis berfokus pada performa proyek yang ia kelola, stabilitas, serta arsitektur yang mudah dipelihara dan konsistensi kode, dan khususnya arsitektur serta konsistensi kode adalah salah satu bidang yang memang sangat tidak dikuasai LLM saat ini.
Khususnya di web, karena arus masuk developer sangat besar dan pola pikir "yang penting jalan" sangat kuat, ada sangat banyak kode berkualitas rendah yang terlanjur dipublikasikan. Dan karena LLM dilatih berdasarkan hal-hal seperti itu, kualitas hasil keluarannya jatuh sampai tingkat yang absurd.
Coba saja minta ke GPT,
tolong implementasikan algoritma quicksort dalam js, buat dipakai di web front-end. Kalau Anda tidak bisa menemukan masalah pada hasil keluarannya, saya rasa percakapan ini tidak akan terlalu bermakna.Saya membacanya sampai selesai, dan pada akhirnya saya pikir penulis punya sudut pandang yang agak bias karena hal ini.
Tentu saja, seperti isi artikel, apa yang disarankan itu hampir seperti nasihat yang sangat baku, jadi memang benar.
Namun, saya rasa AI sudah cukup bagus untuk CRUD dan frontend, yang punya banyak materi untuk dipelajari.
Sepertinya kita perlu memanfaatkannya semaksimal mungkin di dalam domain kita sendiri.
Apakah perusahaan adalah tempat untuk belajar? Atau tempat untuk menciptakan kembali nilai dengan mengambil roda yang dibuat orang lain?
https://id.news.hada.io/topic?id=21091
Setelah membaca tulisan ini, saya jadi bertanya-tanya apakah ini benar.
Poin nomor 1 benar-benar seperti mimpi buruk, perubahan yang sama sekali tidak ingin saya terima. Jadinya pelacakan riwayat kode sumber pun kehilangan makna.
Saya meminta bot AI GN mengekstrak skrip YouTube lalu merangkumnya, dan ternyata performanya cukup bagus.
Ada terlalu banyak video yang harus ditonton sampai melelahkan, jadi ini sepertinya sangat membantu.
Itu karena belum pernah ketemu tim yang jago pakai Electron ~
... kayaknya sih begitu ya wkwk
Peribahasa itu punya makna yang terkandung di dalamnya, tapi makin banyak orang yang menafsirkannya hanya dari kata-katanya saja
Kalau argumen seperti itu jadi tren lagi, ruang rapat bakal berantakan lagi seolah tidak ada apa-apa
Para tukang paperwork bakal kegirangan dan mengamuk, lalu kegagalan yang sama diulang lagi setiap tahun
Ini sangat terkait dengan standar hukum ketenagakerjaan tiap negara.. banyak perusahaan di Amerika biasanya cukup menjalankannya secara bergiliran, dan kalau ada periode yang tidak memungkinkan, urutannya ditukar. Karena memang cukup berat.. ada juga perusahaan yang punya tim khusus on-call.
Di Eropa, hampir selalu ada kompensasi terpisah dengan alasan tugas berubah atau karena itu termasuk kerja lembur.
Di Korea, karena jebakan sistem gaji all-inclusive, biasanya dilakukan sekadarnya. Padahal on-call jelas merupakan kerja, tetapi dibungkus seolah tunjangan untuk jam tersebut adalah semacam fasilitas kesejahteraan.
Sebenarnya, memakai semua layanan itu saja sudah terasa berat, jadi keberadaan MCP adalah keunggulan besar.
Ke depannya, kalau pemeliharaan API-nya tetap bagus, sepertinya ini akan sangat berguna
Perangkat keras Apple memang hebat, tetapi perangkat lunaknya penuh dengan niat untuk mengekang pengguna.
Bahkan jika Anda hanya ingin menjalankan aplikasi yang Anda buat dan build sendiri di perangkat milik Anda, tetap perlu berlangganan seharga $100.
Kalau Anda adalah pengembang yang memakai aplikasi open source skala kecil hingga menengah dan membangunnya sendiri untuk dipakai,
daripada harus melakukan sideload dengan memanfaatkan celah di perangkat Apple sampai perlu jailbreak, lebih mudah pakai Android saja.
Di tempat kami, untuk tugas siaga dibayar setengah dari upah per jam, ada dukungan biaya komunikasi, dan jam saat benar-benar diminta membantu dihitung sebagai lembur 1,5x.
Di tengah-tengah ada kubu C# yang bersembunyi.
> Terus terang, saat ini mengembangkan Java pun sebenarnya tidak harus memakai produk JetBrains
Bagian ini... agak sulit buat saya setujui, hiks...