Dari Software Engineer ke AI Orchestrator: Kenapa Saya Tidak Coding Sendiri Lagi

Saya sudah 17 tahun di dunia software engineering. Mostly .NET, mostly enterprise, mostly healthcare. Saya tahu cara kerja dependency injection, kapan pakai vertical slice vs clean architecture, kenapa eventual consistency lebih masuk akal untuk sistem tertentu.

Tapi sekarang, saya hampir tidak menulis kode sendiri lagi.

Dan output saya justru lebih produktif dari sebelumnya.


Yang Berubah Bukan Skill — Tapi Cara Pakainya

Dulu workflow saya klasik: terima requirement, design arsitektur, buka IDE, tulis kode, debug, deploy. Semua tangan sendiri.

Sekarang? Saya masih design arsitektur. Masih decide pattern mana yang tepat. Masih review hasilnya. Tapi yang menulis kodenya adalah AI.

Bukan karena saya tidak bisa. Tapi karena saya sadar: value saya bukan di keystroke — value saya di keputusan.

Contoh nyata: saya sedang build sistem POS (Point of Sale). Saya yang decide:

  • Offline-first architecture — semua read dari IndexedDB, sync periodik ke server
  • Server-first checkout — coba POST ke API dulu, fallback ke local kalau offline
  • Vertical slice di backend — satu feature, satu file, tidak perlu layer abstraksi berlebihan

AI yang implementasi semuanya. Tapi tanpa keputusan arsitektur di atas, AI akan build sesuatu yang technically works tapi architecturally wrong.


17 Tahun Belajar Konsep, Bukan Syntax

Ini yang saya sadari belakangan: selama 17 tahun, yang paling berharga bukan hafalan syntax C# atau API framework tertentu. Yang berharga adalah:

Tahu kapan pakai apa. Kapan relational database lebih tepat dari document store. Kapan background job lebih baik dari real-time processing. Kapan denormalisasi data itu trade-off yang worth it.

Tahu kenapa sesuatu gagal. Kalau AI generate kode yang error, saya bisa langsung bilang: “Ini race condition” atau “Ini N+1 query problem” — tanpa harus baca line by line.

Tahu pattern yang proven. Circuit breaker untuk external calls. Retry with exponential backoff. CQRS kalau read dan write pattern-nya beda jauh. Ini semua bukan dari baca dokumentasi — ini dari pengalaman gagal di production.

AI tahu syntax lebih baik dari saya. AI bisa generate boilerplate lebih cepat. Tapi AI tidak punya 17 tahun konteks tentang apa yang bisa salah di production.


Cara Kerja Saya Sekarang

Workflow saya sekarang lebih mirip seorang director daripada programmer:

1. Saya define “apa” dan “kenapa”

“Butuh transaction history page. Data dari IndexedDB — local first. User bisa filter by date dan search. Pagination client-side, jangan hit server untuk setiap page.”

2. AI yang implement “bagaimana”

AI tulis komponen React, hook untuk IndexedDB, filter logic, pagination. Biasanya 80-90% benar di percobaan pertama.

3. Saya review dan redirect

“Sync interval 30 detik terlalu agresif untuk mobile. Ganti 5 menit. Dan tambah online event listener supaya sync langsung saat reconnect.”

Ini bukan “AI menggantikan developer.” Ini developer yang tahu cara leverage AI.


Kenapa Tidak Semua Developer Bisa Langsung Jadi Orchestrator

Ada miskonsepsi bahwa siapapun bisa “pakai AI untuk coding.” Secara teknis, ya. Siapapun bisa minta ChatGPT generate kode.

Tapi ada perbedaan besar antara:

  • Minta AI bikin todo app → dan dapat todo app
  • Minta AI bikin production POS system → dan dapat sesuatu yang benar-benar bisa dipakai

Perbedaannya? Kemampuan menilai output.

Kalau saya minta AI bikin endpoint API, saya langsung tahu:

  • Apakah error handling-nya cukup
  • Apakah ada security hole
  • Apakah query-nya akan lambat dengan data besar
  • Apakah arsitekturnya konsisten dengan bagian lain

Tanpa pengalaman, kamu tidak tahu apa yang kamu tidak tahu. AI akan kasih kode yang jalan, tapi belum tentu kode yang benar.


Skill yang Makin Penting

Kalau dulu yang penting adalah “bisa menulis kode yang bersih,” sekarang yang penting:

Komunikasi yang presisi. Bagaimana menjelaskan requirement ke AI tanpa ambigu. Ini mirip skill menulis technical spec — dan ternyata itu skill yang sudah saya latih selama bertahun-tahun sebagai engineer.

Arsitektur dan system design. Semakin AI handle implementasi detail, semakin critical kemampuan melihat big picture. Bagaimana komponen saling berinteraksi, di mana bottleneck potensial, bagaimana sistem scale.

Judgment. Kapan AI benar, kapan salah. Kapan solusi AI “cukup baik” dan kapan harus di-refactor. Ini hanya bisa datang dari pengalaman.


Untuk Senior Developer yang Skeptis

Saya paham skeptisisme-nya. Saya juga sempat berpikir: “Kalau AI yang coding, terus saya ngapain?”

Jawabannya: hal yang sama yang sudah kamu lakukan — tapi tanpa bagian yang repetitif.

Kamu masih yang design. Masih yang decide. Masih yang bertanggung jawab kalau production down jam 3 pagi. AI tidak bisa disalahkan saat incident. Kamu yang bisa.

Bedanya, sekarang dari ide ke implementasi bisa jauh lebih cepat. Sesuatu yang dulu butuh 2 minggu sprint, sekarang bisa selesai dalam hitungan jam. Bukan karena kualitasnya turun — tapi karena bagian yang paling time-consuming (menulis boilerplate, setup konfigurasi, implementasi CRUD yang ke-100) sekarang didelegasikan.

Dan waktu yang tersisa? Dipakai untuk hal yang benar-benar butuh otak manusia: arsitektur, product decisions, dan memastikan semuanya make sense untuk user.


Penutup

Saya tidak berhenti jadi software engineer. Saya masih engineer — hanya tools-nya yang berubah.

Dulu tools saya Visual Studio dan keyboard. Sekarang tools saya adalah AI yang saya arahkan dengan 17 tahun pengalaman.

Dan honestly? Ini fase paling produktif dalam karir saya.

Anjar Priantoro, Yogyakarta