Tukang Ketik vs Software Engineer: Kenapa AI Hanya Membunuh Programmer Permukaan

Gue sering nemu junior developer yang bangga banget bisa nulis sintaks kompleks tanpa liat dokumentasi. Dulu, itu keahlian yang bagus. Sekarang? Gak ada harganya. AI bisa nulis sintaks Regex paling ribet atau higher-order function di JavaScript cuma dalem hitungan milidetik.

Perbedaan mendasar dari keduanya ada di cara pandang:

• Tukang Ketik Sintaks: Pokoknya fitur jalan, status code 200 OK, tampilan sesuai Figma, commit, push, merge. Masa bodoh sama memory leak, race condition, atau struktur query SQL yang membengkak.
• Software Engineer: Mikirin trade-off. “Kalau gue pake pola ini, throughput-nya kuat gak pas flash sale?”, “Gimana kalau service sebelah down?”, “Berapa biaya query ini kalau tabelnya udah dapet 10 juta baris?”

AI itu pinter banget bikin boilerplate code, tapi bloon banget kalau disuruh mikirin konteks bisnis jangka panjang dan arsitektur sistem yang abu-abu.

---

Kodingan AI Kelihatan Bagus… Sampai Kena Production

Biar ada gambaran nyata, mari kita ambil contoh kasus sederhana: Fitur Potong Saldo User (Deduct Balance).

Gue minta AI generik buat bikin fungsi potong saldo pake Node.js & Prisma ORM. Hasilnya? Kelihatan bersih banget.

Kode Versi AI (Tukang Ketik Style)

// AI Output: Tampak bersih, tapi bahaya di production
export async function deductBalance(userId: string, amount: number) {
  const user = await prisma.user.findUnique({
    where: { id: userId }
  });

  if (!user || user.balance < amount) {
    throw new Error("Saldo tidak cukup");
  }

  const updatedUser = await prisma.user.update({
    where: { id: userId },
    data: { balance: user.balance - amount }
  });

  return updatedUser;
}

Kalau lu liat kode di atas dan mikir “Ini mah udah bener, siap deploy!”, fix lu masih ada di kategori tukang ketik.

Kenapa kode di atas bencana di production?

1. Race Condition (Concurrency Bug): Kalau user nge-hit API ini 2 kali secara bersamaan (misal karena double click atau robot bot), kedua request bakal ngebaca user.balance yang sama sebelum request pertama sempat ke-update. Hasilnya? Saldo user bisa terpotong sekali padahal transaksi terjadi dua kali (atau sebaliknya, negative balance).
2. Tanpa Database Transaction: Gak ada penguncian (locking) data pas proses baca-tulis.

Kode Versi Software Engineer (Production-Ready)

Seorang engineer yang paham database primitive gak bakal terima kode di atas gitu aja. Kita butuh pessimistic locking atau setidaknya atomic update di level DB.

// Production-grade implementation
export async function deductBalanceEngineered(userId: string, amount: number) {
  return await prisma.$transaction(async (tx) => {
    // 1. Eksekusi raw query untuk memanfaatkan database row-level locking (FOR UPDATE)
    const [user] = await tx.$queryRaw<Array<{ balance: number }>>`
      SELECT balance FROM "User" 
      WHERE id = ${userId} 
      FOR UPDATE
    `;

    if (!user) {
      throw new Error("User tidak ditemukan");
    }

    if (user.balance < amount) {
      throw new Error("Saldo tidak cukup");
    }

    // 2. Atomic update dalam transaksi yang sama
    const updatedUser = await tx.user.update({
      where: { id: userId },
      data: {
        balance: {
          decrement: amount // Menggunakan operasi atomic decrement dari DB
        }
      }
    });

    return updatedUser;
  });
}

[!NOTE] AI bisa nulis kode versi kedua KALAU lu mendikte instruksinya secara spesifik: “Bikin fungsi potong saldo pake Prisma, wajib pake database transaction dan row-level locking FOR UPDATE buat cegah race condition.”

Pertanyaannya: Siapa yang ngasih tahu AI buat pake FOR UPDATE kalau bukan lu yang paham teori concurrency?

---

Skill yang Bikin Lu Tetep Laku 10 Tahun Lagi

Kalau sintaks udah murah harganya, terus apa nilai jual kita sebagai dev?

1. System Design & Distributed Systems

Gimana cara ngatur microservices biar gak cascading failure? Kapan harus pake Postgres, kapan harus pake Redis, kapan harus lempar ke Kafka? AI bisa ngasih saran, tapi keputusan akhir—beserta risiko biayanya—tetep ada di tangan manusia.

2. Domain Knowledge & Context

AI gak paham business rule unik di perusahaan lu yang udah menumpuk selama 5 tahun. AI gak tahu kalau “User tipe X gak boleh dapet diskon kalau mendaftar via partner Y di hari libur nasional”. Konteks ini cuma ada di kepala tim dan dokumen bisnis internal.

3. Debugging & Observability

Pas aplikasi crash di jam 2 pagi, CPU usage naik 100%, dan log cuma keluar UnhandledPromiseRejection, lu gak bisa sekadar copy-paste 100 ribu baris log ke ChatGPT. Lu butuh intuisi engineering: ngecek metrics di Grafana, analisis distributed tracing, dan nemuin akar masalahnya.

---

Cara Adaptasi Sekarang

Gue gak melarang pake AI. Gue sendiri pake GitHub Copilot dan Claude tiap hari. Tapi cara pakainya yang harus diubah:

1. Pikirkan AI sebagai Intern Cerdas: Jangan pernah blindly trust kodingan dari AI. Anggap aja itu kodingan dari anak magang yang pinter tapi belum paham security & scale.
2. Perdalam Fundamentals: Pelajari lagi Operating System, Networking (TCP/UDP, HTTP headers, DNS), Database Indexing, dan Data Structure. Sintaks framework bisa berganti tiap 2 tahun, tapi fundamental CS gak pernah basi.
3. Belajar “Auditing”, Bukan Cuma “Writing”: Kemampuan paling krusial di masa depan adalah membaca kodingan AI, nemuin celah keamanannya, dan ngelakuin refactoring biar masuk ke standar codebase tim.

---

Catatan Akhir

Industri software engineering itu gak mati, industri ini cuma lagi pembersihan. Era di mana lu cuma bisa HTML, CSS, sedikit JavaScript terus dapet gaji dua digit tanpa paham cara kerja web dasar… emang udah selesai.

Tapi era buat mereka yang suka memecahkan masalah kompleks pake teknologi? Ini justru masa-masa paling seru. Kita bisa ngebangun aplikasi jauh lebih cepat karena urusan ngetik boilerplate udah diambil alih sama mesin.

Jadi, lu mau tetep jadi tukang ketik yang cemas tiap ada update model AI baru, atau mau naik kelas jadi Software Engineer yang mengendalikan AI itu sendiri? Choice is yours.