Kenapa Programmer Harus Takut Pada GitHub Copilot - CRUDPRO
Home  ›  Others

Kenapa Programmer Harus Takut Pada GitHub Copilot

Written By Thursday, May 11, 2023
Kenapa Programmer Harus Takut Pada GitHub Copilot

GitHub Copilot ialah alat pendampingan otomatis kode memiliki tenaga AI yang diperkembangkan oleh OpenAI bekerjasama dengan GitHub dan Microsoft. Itu dibuat di atas GPT dan sebagai anakan dari ChatGPT. Ini memberikan dukungan beragam bahasa pemrograman terhitung Python dan JavaScript.

Artikel ini tidak didasari pada survey besar pada beberapa ribu programmer. Ini malah didasari pada pengalaman seorang programmer — yakni, saya . Maka, mengambil ringkasan saya bukan sebagai perkiraan yang optimis dan kuantitatif, tapi lebih sebagai peringatan yang bumpy dan kualitatif.

Dua jenis pemrograman

Saat saya menulis kode, saya lakukan dua tipe hal: yang hendak saya berikan cap beberapa hal "artistik", dan beberapa hal "drab". Atau Tipe-A dan Tipe-B.

  • Pengkodean tipe-A mengikutsertakan pembikinan beberapa hal baru, atau beberapa cara baru saat melakukan beberapa hal lama. Saya memakai dunia "artistik" karena mereka mengikutsertakan kreasi bawaan.
  • Beberapa hal tipe-B mengikutsertakan pekerjaan mekanis, yang tidak begitu menarik, tapi harus dilaksanakan. Misalkan, menulis unittest dapat sedikit mekanis. Anda ketahui input dan output, dan Anda perlu pastikan jika tiap lajur pemrosesan tercakup.

Pengkodean tipe-A dan Tipe-B tend to mix.

Bagaimana saya bekerja dengan Copilot

Pengalaman kerja saya dengan Copilot selama ini, mengikuti skema berikut ini:

While Programming Tasks is not complete:
    Nuwan codes some Type-A stuff.
    Copilot “completes” the related Type-B stuff.
    Nuwan checks what Copilot completed.

Misalkan, saya bisa membuat kode class, dan Copilot membereskan class unittest yang tepat. Atau dalam scenario yang lebih lokal, saya mengawali for-loop, dan Copilot menambah body.

Saat sebelum Copilot, saya menghabiskan sekitaran 80% waktu pengkodean saya untuk pekerjaan Tipe-B, dengan 20% bekasnya untuk Tipe-A. 100% yang diterangkan di sini hanya "waktu pengkodean"; bukan "membuat waktu" atau "waktu berpikiran" . Maka secara teknis, keseluruhan waktu untuk Tipe-A lebih banyak.

Maknanya, saat yang diperlukan untuk membikin kode menyusut sampai 80%. Atau sebagai alternative, di saat yang sama, saya membereskan 5x lebih beberapa hal.

Why should programmers be afraid

Sebagian besar pemrogram bisa melakukan pekerjaan Tipe-A dan Tipe-B. Tetapi ada beberapa variasi atau seberapa banyak.

Misalkan, melihat sebuah organisasi ekstrim yang mempunyai lima pemrogram. Satu cuma melakukan tugas Tipe-A, sementara empat yang lain cuma lakukan tugas Tipe-B. Saat ini bagaimana Copilot akan memengaruhi organisasi semacam itu? Pemrogram pertama segera dapat lakukan apa yang mereka kerjakan seperti awalnya, karena Copilot tidak bisa lakukan apa yang mereka kerjakan. Tetapi empat container akan diganti oleh Copilot.

Sama seperti yang saya ucapkan, ini ialah kasus ekstrim, tapi semua organisasi akan mempunyai beberapa versi di atas.

No
Ringkasan dan cara di depan
1
 Mayoritas tugas pengkodean saat ini ialah Tipe-B. Mengakibatkan, mayoritas pemrogram habiskan mayoritas saatnya untuk tugas Tipe-B; kemungkinan lebih tidak seimbang, karena programmer Tipe-B tambah murah, dan semakin banyak. Tugas ini akan mengalir ke Copilot . Maka, bila kita ialah programmer Tipe-B, kita betul-betul perlu pastikan jika kita awali memperoleh dan lakukan semakin banyak tugas Tipe-A, apabila kita tidak paham triknya, kita harus coba dan belajar.
2
 Sementara keproduktifan keseluruhannya akan bertambah secara berarti, keuntungan akan dirasa secara benar-benar tidak imbang. Perusahaan yang menghasilkan intellectual property (IP) berharga tinggi akan memperoleh keuntungan paling besar. Perusahaan yang melakukan peningkatan type BPO (telah menyusut) akan betul-betul hancur. Bila kita terhitung dalam kelompok yang paling akhir ini, kita perlu menukar persneling untuk membuat jenis produk berharga tinggi awalnya, dan menukar persneling dengan cepat sekali.
3
 Bila kita ialah sebuah organisasi, kita harus coba dan mengaryakan lebih beberapa orang Tipe-A. Telah ada kekurangan mereka, dan selanjutnya, kekurangan itu cuma bertambah kronis.
4
 Kita perlu menemukan langkah untuk membikin semakin banyak pemrogram Tipe-A. Program gelar yang menghasilkan Periset Computer dan aliran suplai yang lain akan memerlukan reformasi yang berarti. Sayang nya ini tidak bisa terjadi dalam satu malam, dan reformasi apa akan memerlukan minimal 2-4 tahun untuk memulai berbuah hasil, serta lebih lama kembali untuk mencapai kekuatan penuh.
5
 Dalam periode pendek, bakal ada permainan zero-sum, di mana kenaikan keinginan akan memburu suplai programmer Tipe-A yang terbatas. Kasus terjelek ialah seperti perlombaan senjata penerimaan.