Opini: AI dalam Software Engineering Sebagai Alat Amplifikasi, Bukan Pengganti Kompetensi

Ada dua narasi ekstrem yang mendominasi percakapan tentang AI dalam software engineering. Pertama: AI akan menggantikan programmer, jadi tidak ada gunanya lagi belajar fundamental. Kedua: AI hanyalah hype, tidak mengubah apapun yang substansial dalam cara engineer bekerja. Keduanya salah — dan keduanya berbahaya, tapi dengan cara yang berbeda. Narasi pertama mendorong engineer berhenti membangun kompetensi dasar. Narasi kedua mendorong engineer mengabaikan alat yang, jika digunakan dengan benar, bisa melipatgandakan produktivitas mereka secara nyata. Posisi yang lebih tepat ada di tengah: AI adalah amplifier — alat yang memperbesar apa yang sudah ada, ke arah manapun ia menunjuk.

Cara Kerja AI yang Perlu Dipahami

Sebelum membahas implikasinya, penting untuk punya model mental yang akurat tentang apa yang sebenarnya dilakukan AI ketika ia “membantu” menulis kode. Pemahaman ini bukan sekadar akademis — ia menentukan bagaimana kamu seharusnya memperlakukan output AI.

AI generatif dalam software engineering — baik code completion, chat assistant, maupun agent — bekerja berdasarkan pengenalan pola statistik dari data pelatihan yang sangat besar. Ia tidak memiliki pemahaman kausal tentang mengapa sebuah kode bekerja. Ia tidak punya model mental tentang sistem yang sedang kamu bangun. Ia tidak tahu bahwa aplikasimu berjalan di lingkungan dengan memory constraint ketat, atau bahwa database yang kamu gunakan punya karakteristik locking tertentu yang membuat query yang terlihat baik menjadi bencana di production.

flowchart LR
    subgraph Input
        P[Prompt dari engineer]
        C[Konteks kode]
    end

    subgraph AI["AI Model"]
        PAT[Pengenalan pola statistik]
        GEN[Generasi output]
    end

    subgraph Output
        CODE[Kode yang dihasilkan]
        EXP[Penjelasan]
    end

    subgraph Missing["Yang Tidak Dimiliki AI"]
        B1[Pemahaman sistem secara keseluruhan]
        B2[Konteks bisnis dan constraint]
        B3[Akuntabilitas atas konsekuensi]
        B4[Intuisi terhadap edge case tak terduga]
    end

    Input --> AI
    AI --> Output
    Missing -. tidak ada .-> AI

    style Missing fill:#fff3e0,stroke:#fb8c00
    style AI fill:#e3f2fd,stroke:#1e88e5

Implikasi praktisnya sangat konkret. AI sangat andal di wilayah yang terpola dan banyak dicontohkan dalam data pelatihannya — CRUD operations, implementasi algoritma standar, konversi format data, boilerplate code. Tapi AI menjadi tidak dapat diandalkan di wilayah yang membutuhkan pemahaman konteks spesifik: keputusan arsitektur untuk sistem dengan constraint unik, debugging race condition yang hanya terjadi di production, atau trade-off yang bergantung pada roadmap produk yang hanya timmu yang tahu.

AI Sebagai Amplifier: Apa Artinya Secara Konkret

Amplifier dalam elektronik memperbesar sinyal — tapi ia memperbesar apa yang masuk, baik itu sinyal yang bersih maupun noise. AI bekerja dengan prinsip yang serupa.

flowchart TD
    AI[AI Tool]

    SE["Engineer dengan\nfundamental kuat"] -->|menggunakan| AI
    AI -->|menghasilkan| OUT1["Eksplorasi lebih cepat\nValidasi lebih efisien\nImplementasi lebih produktif"]
    OUT1 --> GOOD["Nilai tinggi untuk\ntim dan organisasi"]

    WE["Engineer dengan\nfundamental lemah"] -->|menggunakan| AI
    AI -->|menghasilkan| OUT2["Output yang terlihat benar\ntapi asumsinya tidak dipahami"]
    OUT2 --> BAD["Technical debt tersembunyi\nBug laten\nRisiko yang tidak terdeteksi"]

    style GOOD fill:#e8f5e9,stroke:#43a047
    style BAD fill:#ffebee,stroke:#e53935
    style AI fill:#e3f2fd,stroke:#1e88e5

Engineer yang memahami concurrency akan menggunakan AI untuk mempercepat implementasi mekanisme locking yang tepat — ia tahu apa yang ia minta, ia tahu cara mengevaluasi hasilnya, dan ia tahu kapan output AI perlu dipertanyakan. Engineer yang tidak memahami concurrency akan menggunakan AI untuk menghasilkan kode yang terlihat menangani concurrency — tapi ia tidak bisa mendeteksi ketika AI menghasilkan solusi dengan race condition subtle, karena ia tidak punya model mental untuk mengevaluasinya.

Hasilnya di permukaan identik. Bedanya terletak pada apa yang terjadi ketika sistem itu dijalankan di production dengan beban nyata.

Risiko untuk Junior Engineer: Ilusi Kompetensi

Junior engineer adalah kelompok yang paling rentan terhadap satu bahaya spesifik: illusion of competence. Kode yang dihasilkan AI sering terlihat sangat profesional — naming konsisten, struktur rapi, pattern yang digunakan terlihat mengikuti best practice. Bagi junior yang belum punya referensi kuat tentang seperti apa kode yang baik, output AI terlihat seperti standar yang harus diikuti, bukan seperti solusi yang harus dievaluasi.

Masalahnya: “terlihat profesional” dan “benar untuk konteks ini” adalah dua hal yang sangat berbeda.

Bahaya yang Terakumulasi Diam-diam

Bayangkan junior engineer yang mengerjakan sebuah fitur dengan bantuan AI. Dalam dua jam ia menghasilkan implementasi yang bekerja di happy path, code review terlihat rapi, dan fitur masuk ke production. Ia merasa produktif. Timnya merasa produktif. Tapi ada beberapa hal yang tidak pernah ia pahami:

mengapa struktur data yang dipilih AI cocok untuk use case ini tapi tidak untuk use case yang akan datang, bagaimana kode itu berperilaku saat ada concurrent request dari ribuan user sekaligus, apa yang terjadi ketika external dependency gagal di tengah proses, dan mengapa ada keputusan arsitektur yang tampaknya tidak perlu di codebase yang sudah ada — padahal keputusan itu dibuat untuk alasan penting.

Setiap pertanyaan yang tidak ditanyakan adalah gap yang terus terakumulasi. Dan karena AI terus mengisi gap itu dengan output yang “cukup berfungsi”, gap itu tidak pernah terasa — sampai suatu saat sistem dihadapkan pada kondisi yang tidak ada presedennya di training data AI manapun.

stateDiagram-v2
    [*] --> MasalahTeknis: Junior menemui masalah

    MasalahTeknis --> TanyaAI: Langsung tanya AI\ntanpa eksplorasi dulu
    TanyaAI --> TerimaOutput: Menerima output\ntanpa evaluasi kritis
    TerimaOutput --> IlusiKompetensi: Kode bekerja di happy path\nMerasa sudah paham
    IlusiKompetensi --> GapMelebar: Fundamental tidak dibangun\nGap pengetahuan melebar
    GapMelebar --> MasalahTeknis: Masalah berikutnya lebih kompleks\ntapi skill tidak berkembang

    MasalahTeknis --> EksplorasiDulu: Pahami masalah\nsebelum tanya AI
    EksplorasiDulu --> TanyaTerarah: Tanya AI dengan\nkonteks yang jelas
    TanyaTerarah --> EvaluasiOutput: Evaluasi dan pertanyakan\noutput AI
    EvaluasiOutput --> PemahamanMendalam: Memahami mengapa\nsolusi ini benar
    PemahamanMendalam --> FundamentalTerbangun: Kompetensi nyata terbentuk
    FundamentalTerbangun --> MasalahTeknis: Siap menghadapi\nmasalah lebih kompleks

Tes Evaluasi Diri

Ada cara sederhana untuk mengecek apakah penggunaan AI sedang membangun atau mengikis kompetensi. Setelah mengimplementasikan sesuatu dengan bantuan AI, jawab pertanyaan-pertanyaan ini tanpa membuka AI lagi.

PEMAHAMAN SOLUSI:
  □ Bisakah kamu jelaskan cara kerja kode ini kepada orang lain?
  □ Bisakah kamu tulis ulang ini tanpa menyalin dari AI?
  □ Apakah kamu paham setiap baris, bukan hanya secara keseluruhan?

PEMAHAMAN TRADE-OFF:
  □ Mengapa solusi ini dipilih dibanding alternatif lain?
  □ Di skenario apa solusi ini tidak cocok digunakan?
  □ Apa konsekuensi jika requirement berubah?

PEMAHAMAN EDGE CASE:
  □ Apa yang terjadi jika input-nya kosong atau null?
  □ Apa yang terjadi jika ada concurrent request?
  □ Apa yang terjadi jika external service gagal?

Jika sebagian besar pertanyaan di atas tidak bisa dijawab, kode itu belum benar-benar dipahami — terlepas dari seberapa rapi tampilannya. Junior engineer yang tidak bisa menjelaskan kode yang ia tulis sendiri adalah sinyal serius — bukan tentang kemampuannya, tapi tentang pola penggunaan AI yang sedang ia bangun. Pola itu, jika tidak diperbaiki lebih awal, akan semakin sulit diubah seiring waktu.

Risiko untuk Senior Engineer: Over-Reliance

Risiko bagi senior engineer berbeda secara fundamental. Bukan ilusi kompetensi — justru sebaliknya: over-reliance yang menggerus ketajaman berpikir yang sudah dibangun selama bertahun-tahun.

Senior engineer yang sudah sering menggunakan AI mulai merasakan satu perubahan yang subtle: ia tidak lagi melatih otot berpikir dari pertama prinsip. Ketika ada masalah baru, refleks pertamanya adalah mendeskripsikan masalah ke AI dan melihat apa yang keluar — bukan duduk sebentar dan membuat model mental tentang masalah itu sendiri terlebih dahulu.

Apa yang Hilang dari Proses Itu

Proses berpikir dari pertama prinsip bukan sekadar menghasilkan solusi — ia melatih kemampuan yang tidak bisa didelegasikan ke AI. Kemampuan mendeteksi bahwa masalah yang terlihat sederhana menyimpan kompleksitas tersembunyi. Intuisi tentang kapan sebuah solusi “terlalu mudah” dan perlu diwaspadai. Sense terhadap konsistensi arsitektur — apakah keputusan ini selaras dengan keputusan-keputusan sebelumnya? Kemampuan-kemampuan ini dibangun dari jam terbang nyata, dari pengalaman duduk dengan masalah sulit dan belajar dari kegagalan.

Tanggung Jawab yang Tidak Bisa Didelegasikan

Senior engineer punya tanggung jawab yang sifatnya berbeda dari junior: ia harus mampu mengatakan tidak pada solusi yang terlihat menarik tapi tidak tepat. Kemampuan ini sangat bergantung pada kedalaman pemahaman yang tidak bisa dikompensasi oleh kecepatan AI.

Tanggung jawab di baris bawah adalah alasan utama senior engineer tidak tergantikan oleh AI — tapi tanggung jawab itu hanya bisa dijalankan dengan baik jika kedalaman teknisnya tetap terjaga.

Ilusi Kesetaraan Skill di Mata Stakeholder

Ada efek sosial dari adopsi AI yang perlu dibahas secara jujur: AI membuat output engineer berbeda level terlihat semakin mirip di permukaan, dan ini menciptakan persepsi berbahaya bagi stakeholder non-teknis.

AI cenderung menghasilkan kode dengan “tampilan” yang konsisten — naming convention yang baik, struktur terorganisir, dokumentasi yang cukup. Seseorang yang tidak bisa membaca kode secara mendalam sulit membedakan mana yang ditulis junior dengan bantuan AI intensif dan mana yang ditulis senior engineer berpengalaman. Dalam jangka pendek, output keduanya bisa sangat mirip: fitur berjalan, demo terlihat baik, deadline terpenuhi.

Perbedaan kompetensi baru menjadi eksplisit dan mahal justru di momen yang paling tidak menguntungkan.

flowchart TD
    Normal["Kondisi Normal\nFitur berjalan, demo bagus"] --> Trigger{Trigger event}

    Trigger -- "Traffic spike 10x" --> P1["Sistem tidak scale\nArsitektur tidak didesain untuk ini"]
    Trigger -- "Dependency eksternal down" --> P2["Cascading failure\nTidak ada fallback mechanism"]
    Trigger -- "Requirement berubah signifikan" --> P3["Refactoring sangat sulit\nCoupling tinggi tidak terdeteksi"]
    Trigger -- "Incident produksi tengah malam" --> P4["Debugging sangat lambat\nTidak ada observability memadai"]

    P1 & P2 & P3 & P4 --> Cost["Biaya perbaikan jauh lebih mahal\ndari biaya pencegahan"]

    style Normal fill:#e8f5e9,stroke:#43a047
    style Cost fill:#ffebee,stroke:#e53935

Masalah yang ditanam oleh kode yang “terlihat benar tapi fundamentalnya lemah” biasanya tidak muncul di sprint pertama atau kedua. Ia muncul tiga bulan kemudian ketika user base tumbuh, atau enam bulan kemudian ketika ada perubahan besar di requirement. Dan pada titik itu, biayanya sudah jauh lebih mahal dari biaya yang dihemat dengan memotong investasi pada kompetensi engineer.

Jika kamu berada di posisi pengambil keputusan non-teknis, ada satu mental model yang berguna: kualitas software tidak diukur dari apa yang berfungsi hari ini, tapi dari seberapa mahal biaya perubahan dan perbaikan enam bulan dari sekarang. AI membantu tim bergerak lebih cepat hari ini, tapi kecepatan yang dibangun di atas fondasi rapuh akan menciptakan perlambatan yang jauh lebih besar di masa depan.

Pola Penggunaan yang Sehat vs Destruktif

Setelah memahami risiko, berikut pola konkret yang membedakan penggunaan AI yang produktif dari yang merusak kompetensi jangka panjang.

// ✗ Pola 1: Copy-paste tanpa evaluasi
Masalah → Tanya AI → Terima output → Paste ke editor → Selesai
Akibat: tidak ada proses evaluasi atau pemahaman

// ✓ Solusi: jadikan AI sebagai second opinion, bukan oracle
Masalah → Buat model mental sendiri → Tanya AI untuk validasi
→ Evaluasi apakah output sesuai konteks → Implementasi dengan pemahaman

// ✗ Pola 2: Gunakan AI untuk menghindari berpikir
"Daripada saya pikirkan sendiri, tanya AI saja lebih cepat"
Akibat: otot berpikir tidak pernah dilatih, kemampuan melemah perlahan

// ✓ Solusi: simpan AI untuk pekerjaan berulang
Boilerplate, konversi format, scaffolding, dokumentasi rutin
→ Waktu yang tersimpan digunakan untuk pekerjaan yang butuh judgment

// ✗ Pola 3: Percaya AI tanpa verifikasi untuk domain kritis
Security implementation, financial calculation, concurrent operations
Akibat: AI bisa salah di domain yang memiliki konsekuensi serius

// ✓ Solusi: review ekstra ketat untuk domain kritis
Implementasi AI di area sensitif selalu melewati review senior engineer
yang memahami domain tersebut secara mendalam

// ✗ Pola 4: Tidak bisa menjelaskan apa yang sudah ditulis
"Saya tidak terlalu paham cara kerjanya, tapi AI bilang ini benar"
Akibat: tidak ada ownership intelektual, debugging di produksi menjadi mimpi buruk

// ✓ Solusi: gunakan AI untuk eksplorasi, keputusan tetap di tanganmu
"Tunjukkan beberapa pendekatan yang mungkin untuk masalah ini"
→ AI memperluas perspektif, engineer memilih dan memahami keputusannya

Ada satu heuristic sederhana untuk mengecek kesehatan penggunaan AI: bisakah kamu debug kode yang kamu tulis dengan bantuan AI jika terjadi masalah di production — tanpa mengandalkan AI lagi? Jika jawabannya tidak, pola penggunaan AI perlu dievaluasi ulang.

Workflow AI yang Sehat dalam Proses Engineering

Di mana sebenarnya AI paling tepat berada dalam workflow seorang engineer? Bukan di awal sebagai pemberi keputusan, dan bukan di akhir sebagai validator — tapi sebagai sparring partner di sepanjang proses, dengan engineer tetap sebagai pengambil keputusan di setiap titik.

sequenceDiagram
    participant E as Engineer
    participant AI as AI Tool
    participant S as Sistem/Codebase

    E->>E: Pahami masalah dan konteks sistem
    E->>AI: Minta eksplorasi opsi yang mungkin
    AI-->>E: Beberapa pendekatan beserta trade-off
    E->>E: Evaluasi opsi berdasarkan konteks nyata sistem
    E->>AI: Minta implementasi pendekatan yang sudah dipilih
    AI-->>E: Draft implementasi
    E->>E: Review, evaluasi, modifikasi sesuai kebutuhan
    E->>AI: Tanya edge case yang mungkin terlewat
    AI-->>E: Daftar edge case potensial
    E->>E: Evaluasi mana yang relevan untuk konteks ini
    E->>S: Implementasi final dengan pemahaman penuh

    Note over E: Engineer tetap sebagai decision maker\ndi setiap tahap — AI hanya mempercepat

Tata Kelola AI di Level Organisasi

Individual engineer tidak bisa menanggung semua beban ini sendiri. Organisasi punya tanggung jawab menciptakan lingkungan di mana AI bisa digunakan dengan sehat — bukan sekadar dimaksimalkan tanpa batas.

Jangan ukur produktivitas hanya dari output yang terlihat. Ketika organisasi mengukur engineer hanya dari jumlah ticket selesai atau fitur yang di-ship, ada insentif implisit untuk memaksimalkan output jangka pendek dengan cara apapun — termasuk bergantung penuh pada AI tanpa membangun pemahaman. Metrik yang lebih sehat mencakup seberapa sering engineer bisa mendeteksi masalah sebelum sampai ke production, dan seberapa mudah codebase diubah ketika requirement berubah.

Pertahankan investasi pada mentoring dan code review. Salah satu risiko terbesar adopsi AI yang tidak dikelola adalah organisasi mulai melemahkan proses yang membuat engineer berkembang. Logikanya terdengar masuk akal — “AI sudah bisa membantu, jadi kita tidak perlu senior engineer sebanyak dulu.” Tapi logika ini mengabaikan kenyataan bahwa AI tidak bisa menggantikan transfer konteks spesifik sistem yang hanya ada di kepala engineer berpengalaman. Senior engineer adalah repositori konteks dan judgment — dan itu harus ditransfer ke generasi berikutnya melalui proses yang tidak bisa dipercepat AI.

Bangun tata kelola AI yang eksplisit. Tanpa aturan yang jelas, setiap engineer akan mengembangkan pola penggunaan AI mereka sendiri — dan pola itu akan sangat bervariasi dalam kualitas.

DOMAIN YANG AI BOLEH DIGUNAKAN SECARA BEBAS:
  ✓ Scaffolding dan boilerplate code
  ✓ Konversi dan transformasi format data
  ✓ Penulisan unit test untuk logika yang sudah dipahami
  ✓ Dokumentasi kode
  ✓ Eksplorasi library atau API yang belum familiar

DOMAIN YANG MEMBUTUHKAN REVIEW EKSTRA KETAT:
  ⚠ Implementasi security dan authentication
  ⚠ Logika financial dan kalkulasi kritis
  ⚠ Concurrent dan async operations
  ⚠ Database query di sistem dengan traffic tinggi
  ⚠ Integrasi dengan sistem eksternal yang kritikal

DOMAIN YANG AI TIDAK BOLEH JADI DECISION MAKER:
  ✗ Keputusan arsitektur utama
  ✗ Trade-off yang memengaruhi roadmap jangka panjang
  ✗ Penilaian risiko keamanan
  ✗ Evaluasi performa engineer

Tata kelola ini bukan tentang membatasi produktivitas — justru sebaliknya. Dengan definisi yang jelas tentang di mana AI bebas digunakan dan di mana ia perlu diawasi ekstra, engineer bisa bergerak lebih cepat di area yang aman tanpa mengorbankan kualitas di area yang kritis.

Ringkasan

• AI adalah amplifier, bukan pendidik — ia memperbesar kapabilitas yang sudah ada. Engineer dengan fundamental kuat bergerak lebih cepat; engineer dengan fundamental lemah menghasilkan output yang terlihat benar tapi tidak dipahami.
• Junior engineer paling rentan terhadap ilusi kompetensi — kode AI terlihat profesional, tapi “terlihat benar” dan “benar untuk konteks ini” adalah dua hal yang berbeda. Jika tidak bisa menjelaskan kode sendiri, pemahaman belum terbentuk.
• Senior engineer berisiko terhadap over-reliance — terlalu cepat mendelegasikan ke AI menggerus kemampuan mendeteksi masalah yang tidak terpola dan berpikir dari pertama prinsip.
• Tanggung jawab senior tidak bisa didelegasikan ke AI — keputusan arsitektur, deteksi risiko tersembunyi, dan konsistensi jangka panjang bergantung pada judgment dari pengalaman nyata.
• Perbedaan kompetensi tidak terlihat hari ini, tapi mahal di kemudian hari — ia muncul saat traffic spike, incident production, atau perubahan requirement besar.
• Pola penggunaan yang sehat selalu dimulai dari pemahaman — pahami masalah dulu, gunakan AI untuk eksplorasi dan validasi, evaluasi output secara kritis, pastikan kamu bisa debug hasilnya tanpa AI.
• Organisasi perlu tata kelola AI yang eksplisit — definisikan jelas domain yang bebas, domain yang butuh review ekstra, dan domain yang AI tidak boleh jadi decision maker.
• Jangan lemahkan mentoring dan code review — proses ini bukan sekadar tentang kualitas kode, tapi tentang transfer konteks sistem yang tidak bisa digantikan AI.