Dari Software Engineer ke Domain Engineer: Evolusi Profesi di Era AI

Pernah menonton Tom and Jerry ketika Tom digantikan oleh robot bernama Mechano milik Mammy Two Shoes?"

Saat itu, Tom kehilangan pekerjaannya karena robot dianggap lebih cepat, lebih patuh, dan tidak pernah lelah. Adegan tersebut mungkin terdengar seperti komedi. Namun, beberapa tahun terakhir, banyak orang mulai mengaitkannya dengan perkembangan AI. Pertanyaannya, apakah Software Engineer juga akan mengalami nasib yang sama?

Sejak kemunculan AI coding assistant dan AI agent seperti GitHub Copilot, Cursor, Claude Code, hingga Codex, diskusi mengenai masa depan profesi software engineer semakin menguat. Di media sosial, khususnya komunitas developer, muncul kekhawatiran bahwa kemampuan AI menghasilkan kode secara otomatis akan mengurangi kebutuhan terhadap software engineer. Kekhawatiran tersebut juga diperkuat oleh berbagai prediksi, opini, dan pernyataan sejumlah pelaku industri yang memicu perdebatan mengenai apakah AI benar-benar akan menggantikan profesi ini, atau justru mengubah cara software dikembangkan.

Kekhawatiran itu semakin menguat setelah sejumlah tokoh industri AI menyampaikan prediksi yang cukup agresif mengenai masa depan software engineering. CEO Anthropic, Dario Amodei, misalnya, menggambarkan industri saat ini berada dalam centaur phase, yaitu fase ketika manusia dan AI bekerja bersama dalam proses pengembangan perangkat lunak. Di saat yang sama, ia juga memperingatkan bahwa perubahan tersebut dapat berlangsung sangat cepat dan berpotensi memberikan dampak besar, terutama bagi pekerjaan level awal [1].

Di sisi lain, berbagai laporan juga menunjukkan bahwa respons para software engineer tidak seragam. Sebagian melihat AI sebagai alat yang mampu meningkatkan produktivitas, sebagian lainnya mengkhawatirkan keamanan pekerjaan, sementara kelompok lain memilih beradaptasi sambil menunggu arah perkembangan teknologi ini. Perdebatan tersebut menunjukkan bahwa AI tidak lagi dipandang sekadar sebagai alat bantu pemrograman, melainkan sebagai teknologi yang mulai mengubah cara profesi software engineer dipahami[2].

Namun, di balik seluruh perdebatan tersebut, ada satu pertanyaan yang menurut saya jarang dibahas: bagaimana jika AI tidak benar-benar menggantikan software engineer, melainkan mengubah abstraksi pekerjaannya? Jika selama ini software engineer bertugas menerjemahkan kebutuhan bisnis menjadi kode, maka di era AI, peran tersebut mulai bergeser menjadi menerjemahkan konteks bisnis menjadi spesifikasi yang dapat dipahami AI. Pergeseran inilah yang saya sebut sebagai evolusi dari Software Engineer menuju Domain Engineer.

Apa Itu Domain Engineer

Perlu dicatat: Istilah Domain Engineer dalam artikel ini merupakan sebuah hipotesis atau konsep yang saya gunakan untuk menggambarkan kemungkinan evolusi peran Software Engineer di era AI. Istilah ini bukan merupakan jabatan resmi maupun standar industri pada saat artikel ini ditulis, melainkan sebuah sudut pandang mengenai bagaimana AI berpotensi mengubah fokus pekerjaan seorang engineer di masa depan.

Dalam hipotesis ini, Domain Engineer adalah evolusi dari Software Engineer yang berfokus pada pemahaman domain bisnis, penyusunan konteks, serta penerjemahan kebutuhan bisnis menjadi spesifikasi yang dapat dipahami oleh AI. Jika selama ini software engineer menerjemahkan business requirement menjadi implementasi kode secara langsung, maka Domain Engineer lebih banyak menerjemahkan business requirement menjadi konteks, aturan bisnis, batasan sistem, dan spesifikasi yang kemudian digunakan AI untuk menghasilkan implementasi teknis.

Perubahan tersebut didorong oleh semakin berkembangnya kemampuan AI dalam menghasilkan kode. Aktivitas implementasi yang sebelumnya memerlukan waktu berjam-jam kini dapat diselesaikan AI dalam hitungan menit. Akibatnya, nilai utama seorang engineer tidak lagi hanya terletak pada kemampuan menulis sintaks, tetapi pada kemampuannya memahami bagaimana bisnis bekerja, mengidentifikasi kebutuhan pengguna, mendefinisikan aturan bisnis, serta memastikan implementasi yang dihasilkan AI benar-benar sesuai dengan tujuan organisasi.

AI-Native Engineer

Konsep ini sebenarnya memiliki kemiripan dengan istilah AI-Native Engineer yang mulai banyak dibahas dalam komunitas teknologi. AI-Native Engineer menggambarkan engineer yang menjadikan AI sebagai bagian utama dalam proses pengembangan perangkat lunak. AI tidak lagi hanya digunakan untuk membantu menyelesaikan tugas tertentu, tetapi menjadi partner yang terlibat dalam penulisan kode, debugging, pengujian, hingga dokumentasi.

Namun, hipotesis yang saya ajukan dalam artikel ini memiliki sudut pandang yang sedikit berbeda. Menurut saya, evolusi profesi engineer tidak hanya ditentukan oleh seberapa mahir seseorang menggunakan AI, tetapi juga oleh perubahan nilai yang dibawa seorang engineer ke dalam proses pengembangan perangkat lunak.

Jika AI-Native Engineer berfokus pada cara seorang engineer bekerja bersama AI, maka Domain Engineer berfokus pada apa yang diberikan engineer kepada AI. Dalam hipotesis ini, seorang Domain Engineer bertanggung jawab memahami domain bisnis, menerjemahkan kebutuhan pengguna, menyusun aturan bisnis, menentukan batasan sistem, dan menyediakan konteks yang lengkap agar AI dapat menghasilkan implementasi yang tepat.

Dengan kata lain, AI-Native Engineer menjawab pertanyaan “bagaimana membangun software menggunakan AI?”, sedangkan Domain Engineer menjawab pertanyaan “konteks bisnis apa yang harus diberikan agar AI dapat membangun software yang benar?”

Hipotesis ini juga berangkat dari asumsi bahwa kemampuan AI dalam menghasilkan kode akan terus meningkat. Ketika proses implementasi semakin terotomatisasi, kemampuan menulis kode bukan lagi menjadi pembeda utama antar engineer. Sebaliknya, pemahaman terhadap domain bisnis, kemampuan menganalisis kebutuhan pengguna, serta kemampuan menerjemahkan kebutuhan tersebut menjadi spesifikasi yang dapat dipahami AI akan menjadi kompetensi yang semakin bernilai.

Context Engineering

Saya melihat Domain Engineer bukan sebagai pengganti Software Engineer maupun AI-Native Engineer, melainkan sebagai kemungkinan evolusi berikutnya, di mana fokus pekerjaan bergeser dari menulis kode menjadi membangun konteks bisnis yang mampu menghasilkan solusi melalui AI.

Hipotesis ini juga sejalan dengan munculnya konsep Context Engineering yang mulai diperkenalkan oleh Anthropic. Dalam artikel resminya, Anthropic menjelaskan bahwa context engineering merupakan evolusi dari prompt engineering. Jika prompt engineering berfokus pada cara menulis instruksi kepada AI, maka context engineering berfokus pada bagaimana menyusun, mengelola, dan menyediakan seluruh informasi yang dibutuhkan AI agar dapat menghasilkan keluaran yang tepat. Informasi tersebut tidak hanya berupa prompt, tetapi juga mencakup riwayat percakapan, dokumentasi, aturan bisnis, memori, data eksternal, hingga tools yang dapat digunakan AI.

Menurut saya, konsep tersebut justru memperkuat hipotesis mengenai Domain Engineer. Jika Context Engineering menjelaskan bagaimana konteks dibangun untuk AI, maka Domain Engineer menjelaskan siapa yang bertanggung jawab membangun konteks tersebut dari sisi bisnis. Seorang Domain Engineer tidak hanya memahami cara kerja AI, tetapi juga memahami proses bisnis, kebijakan perusahaan, aturan domain, serta kebutuhan pengguna yang kemudian diterjemahkan menjadi konteks yang dapat dipahami AI.

Dengan kata lain, Context Engineering adalah disiplin atau pendekatan, sedangkan Domain Engineer dalam hipotesis ini adalah peran yang menjalankan disiplin tersebut. AI dapat menghasilkan kode dengan sangat baik, tetapi kualitas hasilnya tetap bergantung pada kualitas konteks yang diberikan. Semakin lengkap dan akurat konteks bisnis yang disusun, semakin besar kemungkinan AI menghasilkan implementasi yang sesuai dengan kebutuhan organisasi. [3]

Aspek	Software Engineer	AI-Native Engineer	Domain Engineer (Hipotesis)
Fokus utama	Mengembangkan aplikasi dengan menulis kode	Mengembangkan aplikasi bersama AI	Menerjemahkan domain bisnis menjadi konteks yang dapat dipahami AI
Peran AI	Alat bantu (assistant)	Partner dalam proses development	Mesin implementasi berdasarkan konteks bisnis
Aktivitas utama	Coding, debugging, testing	Coding, prompting, review, debugging bersama AI	Memahami domain bisnis, menyusun konteks, mendefinisikan aturan bisnis, memvalidasi hasil AI
Nilai utama	Kemampuan implementasi teknis	Kemampuan berkolaborasi dengan AI	Pemahaman domain bisnis dan kemampuan menyusun konteks
Output utama	Source code	Source code yang dihasilkan bersama AI	Business context, spesifikasi, aturan bisnis, serta implementasi yang dihasilkan AI
Kompetensi penting	Programming language, algoritma, framework	AI workflow, prompting, agent, code review	Domain knowledge, business analysis, context engineering, system thinking
Pertanyaan utama	“Bagaimana saya membangun fitur ini?”	“Bagaimana AI membantu saya membangun fitur ini?”	“Konteks bisnis apa yang harus diberikan agar AI membangun fitur yang benar?”

Studi Kasus : Dari Source Code ke Domain Bisnis

Untuk memahami hipotesis ini, mari melihat sebuah skenario yang umum terjadi dalam proses pengembangan perangkat lunak.

Misalkan sebuah perusahaan ingin mengubah aturan perhitungan ongkos kirim pada fitur checkout. Perubahan tersebut biasanya diawali dari Product Requirements Document (PRD) atau requirement yang disusun oleh tim produk berdasarkan kebutuhan bisnis.

Pada workflow yang banyak digunakan saat ini, seorang Software Engineer umumnya akan memulai pekerjaannya dengan membuka IDE, mencari file yang berkaitan dengan fitur tersebut, melakukan tracing terhadap alur source code, kemudian menganalisis dampak perubahan terhadap modul lain. Setelah memahami bagaimana implementasi saat ini bekerja, barulah perubahan mulai dilakukan.

Dengan kata lain, source code menjadi pintu masuk untuk memahami bagaimana sebuah proses bisnis diimplementasikan.

Dalam hipotesis yang saya ajukan, alur tersebut berpotensi berubah seiring meningkatnya kemampuan AI dalam memahami codebase. Seorang Domain Engineer tidak lagi memulai analisis dari source code, melainkan dari requirement dan domain bisnis yang ingin dicapai.

Alih-alih melakukan tracing secara manual, Domain Engineer dapat memanfaatkan AI untuk membaca repository, menjelaskan hubungan antar modul, mengidentifikasi aturan bisnis yang sudah ada, serta melakukan impact analysis terhadap perubahan yang diusulkan. Dari hasil analisis tersebut, engineer kemudian menyusun konteks yang lengkap sebelum meminta AI menghasilkan implementasi teknis.

Pada pendekatan ini, source code tidak lagi menjadi titik awal analisis, tetapi menjadi salah satu sumber informasi untuk membangun business context. Fokus utama engineer bergeser dari menemukan di mana kode harus diubahmenjadi memahami mengapa perubahan tersebut diperlukan dan bagaimana AI harus mengimplementasikannya tanpa melanggar aturan bisnis yang sudah ada.

Jika hipotesis ini terjadi, maka nilai seorang engineer tidak lagi hanya ditentukan oleh kemampuannya menulis kode, tetapi oleh kemampuannya memahami domain bisnis, menghubungkan requirement dengan implementasi yang sudah ada, serta membangun konteks yang cukup agar AI dapat menghasilkan solusi yang tepat.

Singkatnya, jika sebelumnya seorang Software Engineer membaca source code untuk memahami bisnis, maka seorang Domain Engineer justru memulai dari bisnis untuk menjelaskan kepada AI bagaimana source code seharusnya dibangun.

Perubahan tersebut juga menunjukkan bahwa peran engineer tidak lagi cukup jika hanya berfokus pada implementasi teknis. Kemampuan menulis kode akan tetap penting, tetapi bukan lagi satu-satunya kompetensi yang membedakan seorang engineer. Ketika AI semakin mampu menghasilkan implementasi secara otomatis, nilai tambah engineer bergeser pada kemampuannya memahami mengapa sebuah sistem dibangun, aturan bisnis apa yang harus dipenuhi, serta dampak setiap perubahan terhadap proses bisnis.

Dalam konteks tersebut, engineer tidak lagi dapat hanya menjadi pelaksana task atau sekadar menyelesaikan tiket pengembangan. Setiap perubahan yang dilakukan harus dipahami dalam konteks yang lebih luas, mulai dari tujuan bisnis, kebutuhan pengguna, regulasi, hingga keterkaitan dengan fitur lain di dalam sistem. Tanpa pemahaman tersebut, AI mungkin mampu menghasilkan kode yang benar secara teknis, tetapi belum tentu benar secara bisnis.

Sebagai contoh, sebuah perubahan sederhana pada proses checkout mungkin terlihat hanya menyentuh beberapa file. Namun di balik perubahan tersebut bisa terdapat aturan mengenai promosi, pajak, ongkos kirim, stok barang, metode pembayaran, hingga kebijakan pengembalian dana. Semua aturan tersebut merupakan bagian dari domain bisnis yang harus dipahami sebelum implementasi dilakukan.

Karena itu, saya berpendapat bahwa engineer di era AI perlu menjadi bagian dari bisnis, bukan hanya bagian dari proses pengembangan perangkat lunak. Semakin dalam pemahaman seorang engineer terhadap domain bisnis, semakin baik pula konteks yang dapat diberikan kepada AI, dan semakin besar kemungkinan implementasi yang dihasilkan benar-benar menyelesaikan permasalahan yang ingin dipecahkan.

Pada akhirnya, kode bukan lagi tujuan utama, melainkan hasil akhir dari pemahaman terhadap bisnis. Engineer yang mampu menghubungkan kebutuhan bisnis dengan kemampuan AI diperkirakan akan memiliki peran yang semakin penting, karena nilai mereka tidak hanya terletak pada kemampuan menghasilkan kode, tetapi pada kemampuan memastikan teknologi benar-benar memberikan solusi bagi organisasi.

Apakah Metrik Engineer Berubah?

Jawabannya, belum tentu.

Sebagian besar perusahaan kemungkinan masih menggunakan indikator yang sama untuk menilai performa seorang engineer. Misalnya:

Task selesai sesuai sprint.
Tidak menghasilkan bug di production.
Pull Request selesai tepat waktu.
Perubahan tidak mengganggu sistem lain.
Target delivery tercapai.

Artinya, AI tidak otomatis mengubah cara perusahaan menilai performa engineer. Yang berubah adalah bagaimana engineer mencapai KPI tersebut.

Sebagai contoh, misalkan terdapat dua engineer dengan KPI yang sama.

Engineer A (Sebelum AI)

Engineer A menerima satu task dari Jira untuk menambahkan aturan baru pada fitur checkout.

Workflow yang dilakukan kurang lebih sebagai berikut:

Membaca task.
Membuka IDE.
Mencari file yang berkaitan.
Tracing source code.
Mencari dependency.
Melakukan impact analysis.
Menulis implementasi.
Testing.
Membuat Pull Request.

Hasil akhirnya:

✅ Task selesai.
✅ Tidak ada bug.
✅ Pull Request disetujui.
✅ Sprint selesai tepat waktu.

Engineer A memenuhi KPI.

Engineer A (Dengan AI)

Engineer yang sama menerima task yang sama.

Namun workflow yang dilakukan berubah.

Membaca PRD atau requirement bisnis.
Menggunakan AI untuk memahami codebase yang relevan.
Meminta AI menjelaskan dependency dan aturan bisnis yang terpengaruh.
Memvalidasi hasil analisis AI.
Menyusun konteks yang lengkap.
Meminta AI menghasilkan implementasi.
Melakukan review, testing, dan validasi.
Membuat Pull Request.

Hasil akhirnya tetap sama.

✅ Task selesai.
✅ Tidak ada bug.
✅ Pull Request disetujui.
✅ Sprint selesai tepat waktu.

KPI Engineer A tetap sama.

Yang berubah adalah bagaimana KPI tersebut dicapai.

Sebelum AI, sebagian besar waktu engineer digunakan untuk membaca source code, melakukan tracing, dan menulis implementasi. Setelah AI mampu membantu memahami codebase dan menghasilkan implementasi awal, engineer memiliki lebih banyak waktu untuk memahami requirement, menganalisis dampak perubahan terhadap bisnis, serta memastikan solusi yang dibangun benar-benar sesuai dengan kebutuhan organisasi.

Dalam hipotesis Domain Engineer, perubahan inilah yang menjadi inti evolusi profesi. Engineer tidak dinilai berdasarkan seberapa banyak kode yang ditulis, tetapi berdasarkan kemampuannya menghasilkan solusi yang benar. AI membantu pada aspek implementasi, sementara engineer memberikan nilai melalui pemahaman domain bisnis, analisis, dan pengambilan keputusan.

Catatan Penting

Salah satu hal yang menurut saya perlu dipahami adalah bahwa AI sendiri belum tentu menjadi keunggulan kompetitif bagi sebuah perusahaan. Ketika hampir semua perusahaan memiliki akses terhadap model AI, coding assistant, maupun AI agent yang serupa, penggunaan AI akan menjadi standar baru dalam industri.

Dalam kondisi tersebut, pertanyaannya bukan lagi “Apakah perusahaan menggunakan AI?”, melainkan “Bagaimana perusahaan memanfaatkan AI?”

AI dapat mempercepat proses pengembangan perangkat lunak, tetapi AI tidak secara otomatis meningkatkan revenue maupun mempercepat perusahaan memasuki pasar. Jika seluruh kompetitor menggunakan teknologi yang sama, maka percepatan tersebut akan dinikmati oleh semua pihak. Pembeda sesungguhnya terletak pada bagaimana perusahaan membangun proses kerja, memahami domain bisnis, dan memanfaatkan AI untuk menghasilkan solusi yang lebih tepat.

Di sinilah peran engineer juga ikut berubah. Engineer tidak lagi hanya bertugas menghasilkan kode, tetapi menjadi pihak yang memastikan AI memahami konteks bisnis, aturan organisasi, serta tujuan produk yang sedang dikembangkan. Semakin baik konteks yang diberikan, semakin besar peluang AI menghasilkan implementasi yang benar dan memberikan nilai bagi bisnis.

Apakah Software Engineer Akan Digantikan oleh AI?

Jawaban saya adalah tidak, setidaknya berdasarkan hipotesis dan pembahasan dalam artikel ini.

AI memang mampu menghasilkan kode, melakukan analisis terhadap codebase, membantu debugging, hingga mempercepat proses implementasi. Namun, AI tetap membutuhkan konteks yang benar agar dapat menghasilkan solusi yang sesuai dengan kebutuhan bisnis. Di sinilah peran engineer tetap memiliki nilai yang sulit digantikan.

Yang lebih mungkin terjadi bukanlah hilangnya profesi Software Engineer, melainkan evolusi cara seorang engineer bekerja. Fokus pekerjaan akan semakin bergeser dari aktivitas implementasi menuju pemahaman domain bisnis, penyusunan konteks, analisis dampak perubahan, serta pengambilan keputusan yang tidak dapat dilakukan hanya berdasarkan source code.

Menurut saya, risiko terbesar justru bukan datang dari AI, melainkan dari ketidakmampuan beradaptasi dengan AI. Engineer yang tetap mengandalkan cara kerja lama tanpa memanfaatkan AI berpotensi tertinggal dibanding engineer yang mampu menggabungkan pemahaman bisnis dengan kemampuan memanfaatkan AI secara efektif.

Fenomena ini sebenarnya bukan hal baru dalam dunia pengembangan perangkat lunak. Perubahan serupa sudah beberapa kali terjadi. Dulu banyak engineer menulis seluruh kode secara manual. Kemudian muncul fitur autocomplete, dilanjutkan dengan code snippet generator, IDE yang semakin pintar, hingga berbagai alat otomasi yang mengurangi pekerjaan berulang. Kini, AI menjadi tahap evolusi berikutnya.

Setiap fase tersebut tidak menghilangkan profesi Software Engineer. Sebaliknya, setiap fase mengubah ekspektasi terhadap seorang engineer. Aktivitas yang sebelumnya dianggap sebagai keahlian utama perlahan menjadi standar, sementara nilai seorang engineer bergeser ke kemampuan yang lebih tinggi.

Karena itu, pertanyaan yang lebih relevan bukan lagi:

“Apakah AI akan menggantikan Software Engineer?”

Melainkan:

“Bagaimana Software Engineer berevolusi agar tetap memberikan nilai di era AI?”

Dalam artikel ini, saya mengajukan sebuah hipotesis bahwa salah satu kemungkinan evolusi tersebut adalah lahirnya peran yang saya sebut sebagai Domain Engineer. Bukan sebagai profesi resmi yang sudah ada saat ini, melainkan sebagai gambaran mengenai bagaimana fokus seorang engineer dapat bergeser dari menulis kode menjadi memahami bisnis, membangun konteks, dan mengarahkan AI untuk menghasilkan solusi yang tepat.

Pada akhirnya, perusahaan tidak membeli baris-baris kode. Perusahaan membeli solusi atas masalah bisnis. Selama tujuan tersebut tidak berubah, engineer yang mampu memahami bisnis sekaligus memanfaatkan AI secara efektif akan tetap menjadi bagian penting dalam proses pengembangan perangkat lunak.