Mengapa Perusahaan Masih Membutuhkan Pengembang Manusia, Bahkan Dengan Kode Buatan AI

Alat pengkodean AI apa pun dapat menghasilkan kode yang benar secara sintaksis saat Anda memberikannya perintah. Namun bisakah mereka membangun perangkat lunak perusahaan? Dan pertanyaan sebenarnya adalah, apakah kita memerlukan pengembang perangkat lunak lagi?

Pengembangan perangkat lunak selalu lebih dari sekadar desain dan kode. Hal ini melibatkan keamanan, memahami apa yang diminta oleh GDPR, SOC 2, dan kebijakan internal perusahaan, serta mengetahui siapa yang bertanggung jawab jika terjadi kegagalan.

Hal ini membutuhkan pertimbangan kasus dan pengetahuan institusional yang tidak dapat ditawarkan oleh teknologi apa pun. Perangkat lunak perusahaan memerlukan seseorang untuk membuat penilaian arsitektur dan menyusun rencana tentang bagaimana sistem harus disusun dari waktu ke waktu.

Namun AI telah mengubah cara kerja developer.

Peran developer telah bergeser dari menulis kode menjadi memvalidasi, mengatur, dan memiliki hasil.

Dan perubahan itulah yang menjadi alasan mengapa perusahaan enterprise masih membutuhkan pengembang perangkat lunak, meskipun AI yang menulis kodenya.

Apa Arti Sebenarnya "Kode Penulisan AI" di Lingkungan Perusahaan

Saat kami mengatakan AI menulis kode, yang kami maksud sebenarnya adalah ini:Anda memberikan perintah bahasa alami, dan alat tersebut mengembalikan keluaran yang benar secara sintaksis. Ia menangani boilerplate, pengujian unit, dan fungsi standar dengan andal.

Namun bukan berarti ia memahami sistem Anda.

Ia tidak mengetahui arsitektur Anda, persyaratan kepatuhan Anda, atau logika bisnis yang telah berkembang selama bertahun-tahun. Di lingkungan perusahaan, itulah kesenjangan antara alat produktivitas yang berguna dan sesuatu yang dapat membangun perangkat lunak produksi.

Sistem perusahaan berada jauh di luar batas-batas prompt. Kode produksi membawa akumulasi logika selama bertahun-tahun, integrasi non-standar, batasan peraturan, dan keputusan arsitektur yang dibuat jauh sebelum tugas saat ini ada. Konteks tersebut jarang terjadi di satu tempat, dan tidak pernah tercakup dalam satu pesan pun.

Model modern melakukan lebih dari sekadar pencocokan pola murni. Mereka menunjukkan kemampuan penalaran yang nyata. Namun perangkat lunak perusahaan bergantung pada perilaku sistem spesifik Anda, batasan pengoperasiannya, dan cara tim memeliharanya dari waktu ke waktu. Tidak ada alasan yang dapat menutup kesenjangan tersebut tanpa konteks.

AI dapat menghasilkan kode yang benar secara terpisah. Perangkat lunak perusahaan harus benar dalam konteksnya:dalam sistem tertentu, berdasarkan aturan tertentu, dikelola oleh tim nyata.

Mengapa Pembuatan Kode AI ≠ Pengembangan Perangkat Lunak Perusahaan

Pembuatan kode menggunakan AI dilengkapi secara otomatis dalam skala besar. Pengembangan perangkat lunak perusahaan dinilai berada di bawah tekanan. Yang penting adalah mengetahui apa yang harus dibangun, mengapa bangunan tersebut tetap menyatu secara arsitektural, dan siapa yang menjawab ketika bangunan tersebut rusak pada pukul 2 pagi.

AI dapat menghasilkan kode, namun tidak dapat memiliki sistem, keputusan, atau konsekuensi, setidaknya untuk saat ini.

Kesenjangan ini menjadi lebih jelas ketika Anda melihat apa yang sebenarnya terlibat dalam pengembangan perusahaan selain penulisan kode:merancang sistem, memiliki hasil produksi, dan beroperasi dalam batasan yang tidak dapat dilihat oleh AI.

Mari kita uraikan.

1. Menulis Kode

Pembuatan kode sangat mengesankan pada tingkat lini dan fungsi. Dengan cakupan prompt yang baik, model dapat menghasilkan apa saja mulai dari endpoint API yang berfungsi hingga kueri database, seringkali lebih cepat daripada teknisi senior yang mengetik dari awal.

Namun menulis kode baru ternyata hanya merupakan bagian kecil dari pekerjaan seorang pengembang. Laporan IDC tahun 2024 menemukan bahwa pengembangan aplikasi menghabiskan sekitar 16% waktu pengembang. Pengamatan Robert C. Martin yang dikutip secara luas menyebutkan rasio membaca dan menulis lebih dari 10 berbanding 1.

Selebihnya melibatkan pembacaan kode yang ada, memahami maksud, menelusuri kegagalan, menegosiasikan trade-off, dan melakukan panggilan yang tidak memiliki jawaban yang jelas.

2. Merancang Sistem

Desain sistem adalah saat kompleksitas perusahaan menjadi tak kenal ampun. Sebuah prompt tidak dapat memberi tahu AI hal-hal seperti:

• Layanan pembayaran dibangun oleh tim yang sudah tidak ada lagi, dan perubahan apa pun memerlukan koordinasi antara tiga tim kepatuhan
• Perusahaan memilih konsistensi tiga tahun lalu karena alasan kinerja, dan membatalkan keputusan tersebut sekarang berarti memigrasi ulang 400 juta data
• Layanan mikro baru yang Anda buat akan dimiliki oleh tim di zona waktu berbeda dengan rotasi panggilan berbeda

Sistem perusahaan bukanlah sistem yang ramah lingkungan. Mereka mempunyai utang teknis dari keputusan yang ditunda, dan integrasi yang terjadi hanya karena dua sistem dipaksa bersatu setelah akuisisi.

Rancangan sistem yang baik dalam kondisi ini memerlukan konteks historis (mengapa trade-off di masa lalu dilakukan), pemetaan kendala (batas peraturan, kontrak, dan operasional yang tidak dapat dinegosiasikan), penalaran mode kegagalan (“Bagaimana hal ini bisa gagal, dan seberapa parah?”), dan kesadaran organisasi (siapa yang bergantung pada hal ini, dan siapa yang akan hancur jika mengubahnya).

Kode penghasil LLM tidak memiliki semua ini. Ini mempertimbangkan kode di depannya, bukan sistem di belakangnya.

3. Memiliki Hasil dalam Produksi

Produksi bukanlah lingkungan pengujian. Dalam perangkat lunak perusahaan, bug bukanlah pengujian unit yang gagal. Hal ini dapat berupa peristiwa pendapatan, insiden kepatuhan, kegagalan kepercayaan pelanggan, atau, dalam industri yang diatur, paparan hukum.

Kerugian akibat kegagalan produksi diukur dalam pelanggaran SLA, laporan insiden, dan pemeriksaan mayat dengan visibilitas eksekutif.

Dalam lingkungan perusahaan, kepemilikan berarti:

• Anda bertanggung jawab jika sistem berperilaku tidak terduga
• Anda membawa konteks kegagalan masa lalu dan menggunakannya untuk merancang kegagalan ini secara berbeda
• Anda mengambil keputusan atas suatu trade-off tanpa jawaban yang sempurna, dan Anda mendukungnya
• Andalah yang akan melakukan debug pada jam 2 pagi saat peringatan pemantauan diaktifkan

Pembuatan kode menghasilkan keluaran. Hal ini tidak menghasilkan akuntabilitas. Ia tidak memiliki kepentingan dalam kebenaran selain dari perintah, tidak ada memori tentang pemadaman terakhir, dan tidak ada kemampuan untuk melakukan halaman.

4. Pengganda Perusahaan

Semua ini diperparah oleh skala. Perangkat lunak perusahaan berarti:

• Kepemilikan terdistribusi: beberapa tim bekerja sama dengan standar dan insentif mereka sendiri
• Luas permukaan peraturan: Kepatuhan terhadap GDPR, SOX, HIPAA, dan PCI-DSS dimasukkan ke dalam keputusan arsitektur
• Persyaratan umur panjang: sistem yang akan beroperasi dan berkembang selama 10 hingga 20 tahun
• Kepadatan integrasi: bukan tiga layanan yang berbicara satu sama lain, namun ratusan, sering kali melintasi batasan organisasi dan vendor

Dalam lingkungan ini, ilusi berbahaya adalah salah mengira keluaran kode sebagai penilaian teknik. Developer junior yang menghasilkan fitur yang berfungsi dengan bantuan AI belum secara otomatis mengembangkan kapasitas untuk merancang sistem yang digunakannya, mengantisipasi kegagalannya, atau mengetahui apa yang akan terjadi jika sistem tersebut gagal.

Kode adalah bagian yang mudah. Perusahaan adalah bagian yang sulit. Dan AI, pada kenyataannya, hanya membantu salah satu dari hal tersebut.

Perusahaan Apa yang Masih Membutuhkan Pengembang Perangkat Lunak

Perusahaan masih membutuhkan pengembang karena perangkat lunak yang berjalan dalam skala besar memiliki tanggung jawab hukum dan tidak boleh gagal. Hal ini membutuhkan penilaian manusia, ingatan institusional, dan akuntabilitas, yang tidak ada satupun yang dapat diwujudkan atau didelegasikan ke suatu model.

1. Arsitektur Sistem dan Desain Jangka Panjang

Arsitektur adalah serangkaian keputusan yang tidak dapat diubah yang dibuat berdasarkan informasi yang tidak lengkap.

Pengembang tidak hanya memilih pola; mereka memasukkan batasan organisasi ke dalam batasan layanan, kepemilikan data, dan keputusan gabungan yang akan memberikan keuntungan atau menarik pajak untuk dekade berikutnya.

AI dapat menghasilkan layanan. Perusahaan tidak dapat memutuskan di mana batasan layanan tersebut seharusnya berada, atau mengapa batasan tersebut masih masuk akal ketika perusahaan bertambah besar, mengubah arah, atau mengakuisisi pesaing.

2. Keamanan, Kepatuhan, dan Akuntabilitas

Keamanan adalah properti arsitektur, bukan lapisan fitur.

Pemodelan ancaman terjadi pada waktu desain, dan dalam lingkungan yang diatur (SOX, HIPAA, PCI-DSS), setiap keputusan menciptakan jejak hukum dan finansial yang harus dimiliki dan dipertahankan oleh manusia yang disebutkan namanya.

Data mendukung kekhawatiran ini. Laporan Keamanan Kode GenAI Veracode tahun 2025 menemukan bahwa kode yang dihasilkan AI mengandung 2,74x lebih banyak kerentanan daripada kode yang ditulis manusia, diuji di 100+ LLM dan empat bahasa pemrograman. Studi terpisah pada tahun 2026 menemukan bahwa satu dari empat sampel kode AI mengandung kerentanan keamanan yang terkonfirmasi, dengan 45% menunjukkan 10 kelemahan teratas OWASP.

Jika regulator bertanya mengapa data pelanggan ditangani dengan cara tertentu, “model menyarankan pola ini” bukanlah jawabannya. Kode yang dihasilkan AI tidak memiliki kedudukan hukum, tidak ada tanggung jawab, dan tidak ada kesadaran mengenai dampak sebenarnya dari ketidakpatuhan.

3. Penanganan Pengecualian dan Kasus Edge

Jalan yang diharapkan mudah. Kegagalan pada persentil ke-99 adalah saat sistem perusahaan mendapatkan kredibilitasnya.

Di sinilah waktu gateway pembayaran habis di tengah transaksi, saat sistem downstream mengirimkan respons yang salah saat beban puncak, dan saat failover database terjadi selama migrasi langsung.

Pengembang berpengalaman mengetahui kegagalan ini secara langsung. Mereka tidak hanya melakukan kode defensif terhadap kasus-kasus edge. Mereka telah melaluinya.

Mereka mengetahui API pihak ketiga yang berbohong tentang kode kesalahannya dan kesalahan yang menyebabkan kegagalan secara serempak. Ini tidak ada dalam data pelatihan apa pun.

4. Integrasi Sistem Lama

Sebagian besar perangkat lunak perusahaan hidup berdampingan dengan sistem yang dibangun dengan teknologi yang sudah ada sebelum tim saat ini, terkadang hingga beberapa dekade:proses batch COBOL yang memberi makan API modern, sistem ERP dengan efek samping yang tidak terdokumentasi, model data mainframe yang diabstraksi di balik lapisan layanan yang rapuh.

Pekerjaan ini sepenuhnya tentang apa yang tidak didokumentasikan. Pengembang yang melakukan hal ini memiliki kendala historis dari integrasi sebelumnya, mengetahui risiko yang tidak terdokumentasi, dan memahami asumsi mana yang secara diam-diam akan dilanggar jika dilanggar. AI hanya melihat apa yang ditampilkan.

5. Keandalan, Pemantauan, dan Respons Insiden

Kode pengiriman adalah awalnya. Pekerjaan sebenarnya adalah menjaganya tetap berjalan:merancang kegagalan yang terlihat, mengkalibrasi peringatan yang memberi sinyal alih-alih menambah kebisingan, dan membuat dasbor yang memberi tahu teknisi panggilan apa yang rusak dan alasannya dalam hitungan detik.

Ketika insiden terjadi, developer akan menyelidikinya, memutuskan apakah akan melakukan rollback atau patch forward, memberi tahu pemangku kepentingan, dan melakukan pemeriksaan mayat untuk mencegah terulangnya insiden tersebut.

Siklus perancangan, pengamatan, kegagalan, dan pembelajaran ini memiliki konsekuensi yang tidak dapat dihasilkan oleh pembuat kode.

Apa yang Salah Ketika Perusahaan Terlalu Mengandalkan Kode yang Ditulis AI

Ketergantungan yang berlebihan pada kode yang ditulis AI tidak akan menyebabkan kegagalan besar. Ini gagal secara bertahap. Sistem menumpuk utang secara diam-diam, dan kesenjangan tersebut hanya muncul ketika ada tekanan:saat terjadi insiden, audit, atau pelanggaran keamanan.

1. Hutang Teknis

AI menghasilkan kode yang berfungsi untuk prompt, bukan untuk sistem. Tanpa penilaian arsitektur yang memandu setiap keluaran, basis kode akan mengakumulasi pola yang tidak konsisten dan abstraksi berlebihan yang masuk akal secara lokal namun mahal secara global.

Dan itu terjadi dengan cepat. Hutang yang diciptakan dengan kecepatan AI akan datang lebih cepat daripada yang dapat diserap oleh tim mana pun.

Tim yang terburu-buru melakukan pengiriman tanpa memiliki keputusan desain akan berakhir dengan basis kode yang tidak sepenuhnya dipahami oleh siapa pun, yang membutuhkan biaya lebih besar untuk melakukan refaktorisasi dibandingkan biaya untuk menulis.

2. Kegagalan Senyap

Kode yang dihasilkan AI cenderung menangani jalur bahagia dengan baik dan jalur kegagalan dengan buruk. Kasus Edge yang tidak ada dalam prompt tidak akan ditangani, dan tidak seperti kesalahan sintaksis, mode kegagalan yang hilang tidak akan muncul dengan sendirinya hingga kondisi benar-benar salah.

Kegagalan diam-diam adalah jenis bug perusahaan yang paling berbahaya. Pembayaran yang diproses dua kali, catatan yang ditulis sebagian, peringatan yang tidak pernah diaktifkan:hal ini tidak muncul dalam pengujian.

Mereka tidak memicu pemantauan. Hal ini ditemukan melalui konsekuensi hilir, biasanya lama setelah kerusakan terjadi.

3. Risiko Keamanan

Model menghasilkan kode dari pola dalam data pelatihannya, yang mencakup pola yang tidak aman, pustaka yang ketinggalan jaman, dan pendekatan yang tidak digunakan lagi. Tanpa pengembang yang secara aktif memodelkan ancaman pada output, kerentanan akan muncul bersamaan dengan fitur:injeksi SQL muncul, rahasia di-hardcode, validasi input dilewati.

Risiko yang lebih halus adalah kepercayaan palsu.

Kode AI yang lolos peninjauan kode dan pemindaian otomatis masih dapat mengandung kerentanan arsitektur:melanggar batas kepercayaan, membuka rute eskalasi hak istimewa, paparan data yang dimasukkan ke dalam desain. Hal ini memerlukan alasan keamanan manusia, bukan linting.

4. Hilangnya Pemahaman Sistem

Risiko terbesar bukanlah risiko teknis. Ini bersifat organisasi.

Saat developer menggunakan AI untuk menghasilkan kode, mereka tidak sepenuhnya membaca, berdebat, dan memiliki pengetahuan institusional tentang cara kerja sistem tidak lagi terakumulasi.

Seiring waktu, pengembang kehilangan kemampuan untuk memikirkan sistem secara keseluruhan. Hasilnya adalah basis kode yang tidak dapat dipahami oleh siapa pun dan tidak dapat diubah dengan aman oleh siapa pun.

Beberapa perusahaan sudah menerapkan tindakan pencegahan:tinjauan pemahaman kode wajib, memasangkan pemrograman dengan alat AI, standar PR yang lebih ketat.

Namun tanpa upaya yang disengaja, hal ini akan tetap menjadi kerapuhan struktural yang berkembang secara diam-diam hingga ada sesuatu yang memaksa tim untuk menghadapinya.

Perubahan Peran Pengembang Perusahaan

Peran pengembang perusahaan berkembang dari menulis kode hingga mengelolanya, dan dari implementasi manual hingga orkestrasi yang dibantu AI, yang didasarkan pada penilaian dan akuntabilitas yang hanya dapat dilakukan oleh manusia.

1. Dari Menulis hingga Memvalidasi

Output utama dari pengembang bukan lagi baris kode; itu keputusan tentang kode. Hal ini berarti membaca keluaran yang dihasilkan AI secara kritis dan mengidentifikasi apa yang hilang atau sedikit salah, hanya menyetujui apa yang sesuai untuk sistem produksi yang memiliki konsekuensi nyata, dan mengetahui celah keamanan, kelalaian kasus tepi, dan ketidakselarasan arsitektur sebelum dikirimkan.

Hal ini membutuhkan lebih banyak penilaian, bukan lebih sedikit. Pengembang yang tidak bisa menulis kode tentu tidak mampu memvalidasinya.

2. Dari Implementasi hingga Orkestrasi

Pengembang semakin bertanggung jawab untuk menyusun sistem dari komponen yang dihasilkan AI, layanan pihak ketiga, dan platform internal. Pekerjaan pelaksanaan berkurang; kerja integrasi dan koordinasi meningkat.

Hal ini berarti mengelola kontrak dan antarmuka antar komponen yang dirakit, memastikan perilaku yang koheren di seluruh sistem yang dibangun dari sumber yang berbeda, mengendalikan kegagalan pada bagian di mana komponen bertemu dan asumsi dilanggar, dan melakukan koordinasi antar tim, vendor, dan platform, bukan membuat setiap lapisan.

Karyanya beralih dari kepengarangan ke arsitektur, dan dari eksekusi ke desain.

3. Dari Kecepatan hingga Keamanan dan Ketahanan

AI meningkatkan kecepatan produksi kode. Beban yang ditanggung pengembang perusahaan adalah memastikan bahwa kecepatan tidak membahayakan keselamatan. Itu berarti memiliki:

• Kemampuan Observasi :instrumentasi dan logging dibuat sesuai desain, bukan dipasang
• Kemampuan untuk dipulihkan :jalur rollback dan batas kegagalan ditentukan sebelum diperlukan
• Defensibilitas :keputusan arsitektural yang masih dalam pengawasan peraturan atau pemeriksaan post-mortem
• Kecepatan :mengetahui kapan harus memperlambat karena profil risiko menuntutnya

Proposisi nilai pengembang dalam lingkungan yang dilengkapi AI bukanlah kecepatan. Keputusan itulah yang menjaga kecepatan agar tidak menjadi tanggung jawab.

Ketika AI Harus Membantu Pengembang, Bukan Menggantikannya

AI memberikan pengaruh nyata ketika beroperasi sebagai alat di bawah arahan manusia. Saat perusahaan diperlakukan sebagai pengambil keputusan dalam bidang arsitektur, keamanan, atau kepatuhan, perusahaan telah menggantikan akuntabilitas dengan otomatisasi dan penilaian dengan probabilitas.

Di mana AI Memberikan Manfaat

AI sangat bermanfaat dalam bagian-bagian pembangunan yang bervolume tinggi dan berisiko rendah pada upaya pertama. Kasus penggunaan yang kuat meliputi:

• Pembuatan boilerplate: scaffolding, operasi CRUD, pola berulang di seluruh layanan
• Ujian menulis :menghasilkan kasus uji unit dan integrasi dari tanda tangan fungsi yang ada
• Dokumentasi :menyusun komentar sebaris, dokumen API, dan konten README dari konteks kode
• Bantuan peninjauan kode :memunculkan masalah yang nyata, pola yang tidak konsisten, dan pelanggaran gaya
• Dukungan pemfaktoran ulang :merestrukturisasi kode yang dipahami dengan baik dengan maksud sebelum/sesudah yang jelas
• Akselerasi debug :mempersempit sumber kesalahan dan menyarankan kandidat perbaikan
• Pembuatan Prototipe :mengeksplorasi dengan cepat seperti apa solusi sebelum melakukan suatu pendekatan

Dalam semua hal ini, AI mempersingkat waktu. Pengembang tetap memiliki hasilnya tetapi mencapainya lebih cepat.

Ketika Penilaian Manusia Tidak Dapat Dinegosiasikan

Ada serangkaian keputusan yang jelas bahwa menghilangkan manusia tidak hanya menimbulkan risiko. Hal ini menghilangkan struktur akuntabilitas yang menjadi sandaran perusahaan:

• Desain sistem dan batasan layanan: keputusan yang akan membatasi basis kode selama bertahun-tahun
• Arsitektur keamanan :pemodelan ancaman, batasan kepercayaan, desain hak istimewa
• Keputusan kepatuhan: data apa yang dikumpulkan, cara penyimpanannya, siapa yang dapat mengaksesnya
• Insiden produksi :diagnosis, eskalasi, panggilan kembalikan di bawah tekanan
• Integrasi lama :menavigasi perilaku tidak terdokumentasi dan meminimalkan radius ledakan
• Resolusi trade-off :memilih antara kendala yang bersaing tanpa jawaban yang jelas
• Post-mortem dan pembelajaran :mengekstraksi pengetahuan institusional dari kegagalan

Ini bukanlah tugas yang dilakukan AI dengan buruk. Ini adalah tugas yang tindakan manusia dalam mengambil keputusan merupakan bagian dari apa yang dibutuhkan perusahaan.

Mengapa Human-in-the-Loop Penting dalam Perusahaan

Dalam perangkat lunak konsumen, keputusan buruk yang dihasilkan AI menghasilkan bug. Dalam perangkat lunak perusahaan, hal ini dapat mengakibatkan pelanggaran kepatuhan, insiden keamanan, atau pemadaman listrik dengan konsekuensi kontrak. Taruhannya mengubah isi loop.

Human-in-the-loop dalam konteks perusahaan berarti tidak ada kode yang dihasilkan AI yang memasuki produksi tanpa persetujuan pengembang. Artinya, keputusan arsitektur mendahului implementasi yang dibantu AI, bukan sebaliknya.

Setiap keputusan sistem ditelusuri kembali ke seorang insinyur bernama yang memahami dan mendukungnya. Keluaran AI diperlakukan sebagai rancangan, bukan hasil. Dan pemantauan, peringatan, dan respons terhadap insiden tetap dirancang dan dilaksanakan oleh manusia.

Tujuannya bukan untuk memperlambat AI. Hal ini dilakukan untuk memastikan kecepatan yang diberikan AI tidak memutuskan hubungan antara keputusan dan konsekuensi, yang merupakan hubungan yang mendasari perangkat lunak perusahaan, regulasi, dan kepercayaan organisasi.

Kesimpulan

Tim perangkat lunak tetap penting karena bagian tersulit dalam membangun teknologi (arsitektur, akuntabilitas, memori institusional) selalu memerlukan pengambilan keputusan oleh manusia.

Kenyataan barunya sangat jelas:tingkatkan alat yang tersedia bagi pengembang, jangan menggantinya. Gunakan AI untuk mempertajam pemikiran, bukan menggantikannya. Dan terapkan dengan pemahaman bahwa pada akhirnya seseoranglah yang akan menentukan hasilnya.

Organisasi yang membuat perangkat lunak paling tahan lama dalam dekade mendatang tidak akan menghasilkan kode terbanyak. Merekalah yang akan memadukan kecepatan AI dengan penilaian manusia, dan tahu persis di mana batasan antara keduanya.

Jika Anda membutuhkan mitra yang realistis untuk membantu Anda mengetahui di mana AI merupakan hal positif dalam organisasi teknis Anda dan di mana AI menimbulkan risiko, tim di Imagination dapat membantu Anda membuat peta jalan tersebut.

Mari kita bicara.