AI, Judgment, dan Arsitektur Software
Bagian ini membahas: AI, Ambang Kompetisi, dan Capacity Expansion; Dari Programmer ke Engineer ke Architect; Hal yang Tetap Membutuhkan Judgment Manusia; Lingkungan Kerja AI; Brief, Review, dan Evidence untuk AI-Assisted Work; Arsitektur Software di Era AI.
6 bab · 45 artikel
Bab 13: AI, Ambang Kompetisi, dan Capacity Expansion
menjelaskan perubahan besar di era AI: ambang untuk bersaing turun. Perusahaan kecil yang sejak awal berbasis AI bisa melakukan analysis, design, coding, testing, dokumentasi, support, dan operasi dengan biaya lebih rendah. Perusahaan besar yang hanya memakai AI untuk cost reduction bisa tetap berada di posisi lama. Organisasi yang memperlengkapi manusia dengan AI dapat mengubah cost reduction menjadi capacity expansion.
Dulu Butuh Tim, Sekarang Butuh Ide
Bayangkan Anda punya ide untuk sebuah aplikasi yang bisa membantu tim operasional di perusahaan Anda melacak pengaduan pelanggan. Ide ini se
Startup Kecil, Langkah Besar
Setelah ambang turun, muncul pertanyaan: siapa yang paling diuntungkan? Mari kita lihat bagaimana startup kecil bisa bergerak lebih cepat.
Efisiensi Saja Tidak Cukup
Tapi bagaimana dengan perusahaan besar yang sudah mapan? Apakah mereka otomatis kalah? Jawabannya tergantung pada bagaimana mereka memakai A
Bukan Ganti Manusia, Tapi Perkuat Kapasitas
Mari kita lihat kasus yang berbeda. Sebuah perusahaan logistik menengah memiliki tim verifikasi layanan yang terdiri dari empat puluh orang.
Budaya Belajar sebagai Syarat Transformasi
Ketika perusahaan logistik itu mulai memperlengkapi tim verifikasi layanannya dengan AI, hasil awalnya tidak langsung mulus. Beberapa orang
AI Bukan Urusan IT Saja
Budaya belajar ini tidak hanya berlaku untuk IT. Semua fungsi perlu belajar koeksis dengan AI. Saya sering melihat kesalahan klasik di perus
Dari Programmer ke Engineer ke Architect
Ketika semua fungsi mulai belajar, peran manusia pun ikut bergeser. Programmer naik menjadi engineer, engineer berpikir seperti solution arc
Pertanyaan Strategis: Berapa Banyak Lagi yang Bisa Kita Kejar?
Semua pergeseran ini bermuara pada satu pertanyaan strategis: berapa banyak inisiatif tambahan yang bisa dikejar karena cost per inisiatif t
Bab 14: Dari Programmer ke Engineer ke Architect
memberi peta perkembangan peran. Programming tetap menjadi fondasi penting. Di era AI, fondasi itu perlu diperluas menjadi kemampuan memahami sistem, keputusan, value, dan konsekuensi agar AI bisa dipakai sebagai pengungkit.
Kode Itu Mudah, Software Itu Sulit
Bayangkan Anda punya ide untuk membuat aplikasi catatan harian. Anda duduk di depan laptop, membuka AI assistant, dan mengetik: “Buatkan say
Dari Instruksi ke Produk: Programmer dan Developer
Kembali ke aplikasi catatan harian tadi. Anda sudah punya kode yang berfungsi. Tapi coba lihat lebih dekat: apa yang sebenarnya Anda hasilka
Engineer: Bukan Sekadar Jalan, Tapi Jalan yang Teruji
Setelah fitur dan produk, muncul tuntutan yang lebih berat: bagaimana memastikan software bisa berjalan andal di berbagai kondisi dan peruba
Architect: Bentuk Sistem dan Arah Keputusan
Bayangkan Anda bekerja di sebuah perusahaan yang sudah memiliki sepuluh aplikasi. Masing-masing dibuat oleh tim berbeda, di waktu berbeda, d
Titel vs Kemampuan: Jangan Tertipu Label
Anda pasti pernah bertemu orang seperti ini: di LinkedIn, jabatannya Senior Software Engineer di perusahaan teknologi besar. Portfolionya pe
Mulai dari Meja Kerja: Cara Berpikir Arsitektural
Kembali ke pertanyaan di akhir subbab sebelumnya: jika label tidak menjamin kemampuan, lalu bagaimana seseorang bisa mulai berpikir seperti
AI sebagai Pengungkit Naik Kelas
Tiga pertanyaan dari subbab sebelumnya memberi arah: apa yang terjadi jika gagal, siapa yang terdampak, dan bagaimana keputusan ini dirawat
Bab 15: Hal yang Tetap Membutuhkan Judgment Manusia
menjelaskan area yang tetap membutuhkan judgment manusia. AI berguna jika diberi context, constraint, tujuan, dan evidence. Pemahaman masalah, prioritas, judgment, dan keputusan yang menyentuh manusia, organisasi, uang, data, compliance, dan reputasi tetap perlu dipimpin manusia.
AI Butuh Konteks, Bukan Sekadar Perintah
Bayangkan Anda meminta seseorang mengerjakan tugas tanpa memberi tahu latar belakangnya. Anda hanya berkata, “Buatkan laporan.” Orang itu ak
Memilah Konteks: Mana yang Penting, Mana yang Bisa Dibuang
Seorang kepala produk datang dengan ide baru. Ia ingin timnya membangun fitur rekomendasi produk berbasis AI. Ia sudah menyusun brief panjan
Constraint: Batasan yang Membantu AI Memberi Jawaban Lebih Tajam
Setelah konteks terpilih, langkah berikutnya adalah merumuskan constraint yang membatasi solusi. Seorang arsitek yang saya kenal pernah berc
Membandingkan Opsi dengan Aturan yang Sama
Seorang arsitek yang saya dampingi pernah menghadapi situasi menarik. Ia harus memilih platform untuk aplikasi data analytics perusahaan. Ti
Evidence: Apa yang Membuat Keputusan Bisa Dipertanggungjawabkan
Setelah opsi dibandingkan, manusia perlu memutuskan. Tapi keputusan itu harus didasarkan pada evidence, bukan sekadar opini.
Dokumentasi sebagai Jembatan antara Manusia dan AI
Seorang arsitek yang saya kenal pernah mendapatkan tugas mengevaluasi ulang arsitektur sistem yang sudah berjalan tiga tahun. Ia datang deng
Keputusan Tetap di Tangan Manusia
Seorang kepala operasi pernah bercerita tentang pengalamannya menggunakan AI untuk membantu memilih vendor logistik. Ia sudah memberikan kon
Bab 16: Lingkungan Kerja AI
memperkenalkan AI sebagai bagian dari lingkungan kerja, bukan daftar produk. AI bisa hadir di editor, terminal, repository, review process, dokumentasi, platform internal, operasi, support, legal, HR, finance, dan knowledge work. Fokusnya adalah kapabilitas dan pola adopsi, bukan vendor.
AI Datang ke Meja Kerja, Bukan ke Panggung
Bayangkan seorang engineer bernama Rina. Pagi itu ia membuka editor kodenya seperti biasa. Sebuah file lama terbuka — kode yang ditulis enam
Editor yang Mengerti Konteks
Rina membuka file lama itu di editor. Kode berisi tiga kelas yang saling memanggil, satu utility function yang dipakai di beberapa tempat, d
Terminal dan Repositori yang Bisa Diajak Bicara
Rina sudah memahami file yang ia buka. Tapi bug yang dilaporkan tidak hanya melibatkan satu file. Ia harus melihat bagaimana fungsi itu dipa
AI sebagai Asisten Arsitek
Kemampuan memahami codebase ini membuka jalan bagi AI untuk membantu tugas yang lebih strategis: mendokumentasikan keputusan arsitektur. Rin
AI untuk Semua Fungsi, Bukan Hanya IT
Arsitek bukan satu-satunya peran yang terbantu. Fungsi bisnis lain juga bisa memanfaatkan AI untuk pekerjaan knowledge mereka. Ketika Rina m
Kontrol Kerja: Permission, Data, dan Audit
Semakin luas AI digunakan, semakin penting untuk memiliki kontrol kerja yang jelas agar penggunaannya tetap aman dan dapat dipertanggungjawa
Memilih Pendekatan Tooling yang Tepat
Rina dan timnya sekarang sudah punya pengalaman menggunakan AI di berbagai area: editor, terminal, repositori, hingga pembuatan artefak arsi
Peta Kapabilitas AI untuk Organisasi
Setelah memilih pendekatan tooling, Rina dan timnya mulai menyadari sesuatu: AI tidak hanya membantu di satu tempat. Ia hadir di editor saat
Bab 17: Brief, Review, dan Evidence untuk AI-Assisted Work
menjelaskan cara mengendalikan AI dengan judgment arsitektural. Prompt bukan perintah pendek, tetapi brief kerja. Output AI tidak dinilai dari rapi atau cepat, tetapi dari kesesuaian dengan brief, boundary, contract, evidence, dan tujuan.
Dari Prompt Pendek ke Brief Kerja
Seorang engineer duduk di depan layar. Ia mengetik: “buatkan REST API untuk user registration.” Dalam hitungan detik, AI mengeluarkan kode l
Anatomi Brief Kerja untuk AI
Brief kerja bukan sekadar prompt yang lebih panjang. Brief kerja adalah dokumen mini yang memuat semua informasi yang dibutuhkan AI agar out
Menentukan Area Kerja AI: Boleh, Perlu Persetujuan, atau Ditangani Manusia
Brief kerja sudah siap, tetapi sebelum meminta AI membuat kode, kita perlu menentukan area mana yang boleh disentuh AI. Ini adalah keputusan
Minta Opsi, Bukan Satu Jawaban
Setelah area kerja jelas, langkah berikutnya adalah meminta AI memberikan opsi implementasi, bukan langsung satu solusi. Ini adalah titik di
Audit Output AI: Apa yang Sering Salah
Setelah opsi dipilih dan AI mulai bekerja, kita perlu mengaudit outputnya sebelum menerima. Langkah ini sering dilewati karena output AI ter
Evidence Minimum Berdasarkan Jenis Perubahan
Audit menemukan masalah, tetapi kita perlu bukti bahwa output benar-benar siap dipakai. Di sinilah evidence dibutuhkan.
Siklus Evidence: Sebelum Merge, Sebelum Release, Setelah Release, Setelah Alur Pengetahuan
Seorang arsitek baru saja selesai mereview output AI untuk modul integrasi pembayaran. Ia sudah mengumpulkan evidence sesuai jenis perubahan
Template AI Working Brief dan Checklist Evidence
Setelah membaca tujuh subbab sebelumnya, Anda mungkin merasa: ini semua masuk akal, tapi bagaimana cara memulainya? Saya perlu sesuatu yang
Bab 18: Arsitektur Software di Era AI
menjelaskan bahwa AI lebih berguna pada sistem yang boundary-nya jelas. Arsitektur software yang baik membuat AI lebih mudah diberi konteks, lebih mudah dibatasi, lebih mudah diverifikasi, dan lebih mudah dipakai tanpa membuat sistem kacau.
AI Butuh Batas yang Jelas
Bayangkan Anda meminta seorang asisten baru untuk mengurus administrasi kantor. Anda memberinya akses ke semua file, semua email, semua data
Modularitas: Membuat Perubahan Terkendali
Bayangkan Anda bekerja di sebuah perusahaan yang memiliki satu aplikasi raksasa. Semua fitur ada di dalam satu codebase yang sama. Logika bi
API dan Contract sebagai Perjanjian
Setelah Anda membagi sistem menjadi modul-modul yang terpisah, pertanyaan berikutnya adalah: bagaimana modul-modul ini berbicara satu sama l
Data dan State: Jangan Biarkan AI Bermain Sendiri
API dan contract hanya sebagian dari cerita; data dan state juga perlu diatur dengan jelas agar AI tidak membuat kekacauan.
Security dan Reliability sebagai Desain Awal
Bayangkan Anda telah membangun sistem pemesanan tiket dengan modul-modul yang rapi, API yang jelas, dan data yang terkelola dengan baik. Kem
Refactor sebagai Investasi untuk AI
Bayangkan Anda mewarisi sebuah kode yang sudah berjalan tiga tahun. Fungsinya benar, tidak ada bug yang dilaporkan, dan bisnis berjalan lanc
AI sebagai Alat Eksplorasi, Manusia sebagai Penjelas
Setelah Anda merapikan kode melalui refactor, sistem menjadi lebih mudah dipahami dan dimodifikasi. Tapi pertanyaan yang lebih dalam muncul: