13.7 Dari Programmer ke Engineer ke Architect

Ketika semua fungsi mulai belajar, peran manusia pun ikut bergeser. Programmer naik menjadi engineer, engineer berpikir seperti solution architect. Ini bukan sekadar perubahan gelar di kartu nama. Ini adalah pergeseran cara kerja yang didorong oleh AI.

Bayangkan seorang programmer bernama Andi. Dulu, hari-harinya diisi dengan menulis kode dari spesifikasi yang sudah disiapkan orang lain. Ia menerima dokumen berisi daftar fitur, lalu duduk berjam-jam menerjemahkannya ke dalam baris kode. Pekerjaannya sangat teknis, sangat dekat dengan syntax dan logika per baris.

Sekarang, dengan AI assistant yang bisa menulis kode dasar, menerjemahkan logika, dan bahkan menyarankan perbaikan, pekerjaan Andi berubah. Ia tidak lagi menghabiskan delapan jam untuk menulis kode yang bisa diselesaikan AI dalam beberapa menit. Pertanyaan yang muncul di benaknya bukan lagi "bagaimana cara menulis fungsi ini?", tetapi "apakah fungsi ini perlu ada?", "bagaimana fungsi ini terhubung dengan sistem lain?", dan "apa yang terjadi jika inputnya berbeda dari yang diharapkan?"

Itulah pergeseran dari programmer ke engineer. Seorang engineer tidak hanya menulis kode, tetapi memahami sistem tempat kode itu berjalan. Ia tahu bagaimana data mengalir, di mana titik kegagalan bisa terjadi, dan bagaimana satu perubahan mempengaruhi bagian lain. AI mengambil alih pekerjaan repetitif, dan yang tersisa adalah pemahaman sistem yang lebih dalam.

Pergeseran selanjutnya terjadi ketika engineer mulai bertanya: "Apakah solusi ini yang paling tepat untuk masalah bisnisnya?" Di sinilah seorang engineer mulai berpikir seperti solution architect. Ia tidak lagi hanya menerima spesifikasi, tetapi ikut mempertanyakan apakah spesifikasi itu menjawab kebutuhan nyata. Ia melihat batas solusi, siapa yang terdampak, dan bagaimana solusi itu bisa berkembang.

Seorang solution architect membaca situasi. Ia tahu bahwa kadang solusi terbaik bukanlah membuat sistem baru, tetapi mengubah alur kerja yang ada. Ia bisa membedakan antara kebutuhan yang harus dipenuhi dan keinginan yang bisa ditunda. Ia melihat value bukan dari seberapa banyak kode yang dihasilkan, tetapi dari seberapa besar masalah yang terselesaikan.

Di level yang lebih tinggi, para leader—baik itu kepala departemen, direktur, atau pemilik produk—mulai membaca value dan capability. Mereka tidak perlu tahu detail arsitektur teknis, tetapi mereka harus bisa menjawab: "Apakah organisasi kita punya kemampuan untuk menjalankan inisiatif ini?" dan "Apa nilai yang akan kita dapatkan?"

AI mempercepat pergeseran ini. Ketika biaya menulis kode turun drastis, programmer yang hanya bisa menulis kode menjadi kurang bernilai. Yang naik kelas adalah mereka yang bisa membaca sistem, merancang solusi, dan menghubungkan teknologi dengan kebutuhan bisnis. Inilah mengapa di zaman AI, menjadi programmer saja tidak cukup. Tetap kuasai code, tetapi latih cara berpikir yang lebih utuh: melihat masalah, sistem, value, keputusan, dan konsekuensi seperti seorang architect.

Diagram berikut merangkum pergeseran fokus di setiap level peran:

flowchart TD P["Programmer"] --> E["Engineer"] E --> A["Architect"] P --> P1["Fokus: syntax & instruksi"] P --> P2["Menulis kode dari spesifikasi"] P --> P3["Menerjemahkan fitur ke baris kode"] E --> E1["Fokus: sistem & reliability"] E --> E2["Memahami aliran data & titik gagal"] E --> E3["Mempertanyakan dampak perubahan"] A --> A1["Fokus: solusi bisnis & batasan"] A --> A2["Membedakan kebutuhan vs keinginan"] A --> A3["Mengukur nilai dari masalah terselesaikan"]