{"schema_version":1,"source":"https://evanpurnama.com/","documents":[{"id":"ai-model-cost:en","slug":"ai-model-cost","language":"en","title":"If the AI Is Cheaper, Does the Work Cost Less?","url":"https://evanpurnama.com/ai-model-cost/","description":"When does a cheaper AI model reduce total cost? Work through skill preparation, usage, review time, and maintenance with one report example.","date":"9 September 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/ai-model-cost.en.md","sha256":"e4e11767102179dc84396f7c28b6767d7ab9b16b34dd1e765ecffd21be70c872","text":"Source: https://evanpurnama.com/ai-model-cost/\nAuthor: Evan Purnama\nLanguage: en\n\n# If the AI Is Cheaper, Does the Work Cost Less?\n\nNote: AI changes quickly. If you read this 6 to 12 months after publication, some model capabilities and prices may have changed. Check current sources before making a decision.\n\n![A balance scale weighing coins and a stopwatch against more coins](https://evanpurnama.com/ai-model-cost/assets/hero.jpg)\n\nPreparation and review time are part of the cost of the work.\n\nIf we need to top up our AI account every few days, it makes sense to look for a cheaper model. Especially when much of the work repeats: reading files with similar formats, extracting the same information, and producing reports with the same structure.\n\nOne argument is that a cheaper model should be enough if we are good at writing instructions and skills. I think this is worth examining, because preparing those instructions takes time too. Someone has to find examples, try them, correct what went wrong, and run the work again.\n\nSo we have two costs to consider: what we pay to use the AI, and how much work we do to get a result we can use.\n\nLet's follow one type of task through that calculation. Every amount and duration in the example is an assumption for illustration. These are not prices for a particular model or operating figures from a company.\n\n## What Can a Skill Help With?\n\nSuppose our team receives weekly sales files from several branches. We want AI to read them, calculate net sales, and explain which branches performed very differently from the previous week.\n\nThe instructions need to cover a few specific details. Are cancelled transactions still in the file? Have discounts already been deducted? Should differently written branch names be combined? Does a refund belong to the week of the original sale or the week the money was returned?\n\nSomeone who regularly prepares these reports probably knows the answers. We can package those rules, sample files, and scripts for repeated calculations into a skill that the AI can use.\n\nA skill here is a package of instructions and supporting resources for a particular task. Creating one does not automatically change the underlying model through training.\\*\n\nThe AI then has less to work out from scratch each time a file arrives. To calculate totals, for example, it can run a script we have checked and use the output to write its explanation. A cheaper model might handle this well.\n\nSkillsBench compares agents with and without prepared skills. The research finds that skills can improve task completion, and that some smaller models with skills can match larger models without them. The benefit varies across tasks, though. Asking models to generate their own skills does not automatically improve performance. [SkillsBench paper](https://arxiv.org/html/2602.12670v1).\n\nThat gives us a reason to test a cheaper model with suitable skills. For our sales reports, we still need to check the totals, the treatment of refunds, and the explanation. A benchmark score alone does not tell us how long our team will spend getting that result.\n\n## What Does Preparation Cost?\n\nSuppose we test two options on the same reports. Option A uses a more expensive model. Option B uses a cheaper model with additional skills and dedicated scripts.\n\nBoth need business rules, data access, and checks on the result. To keep the comparison manageable, we will leave out costs that are identical in both options and count the costs that differ.\n\nAssume A takes 4 hours to prepare and test. B takes 20 hours because we need additional scripts, examples, and instruction changes to meet the same requirements.\n\nAt an assumed cost of Rp 150,000 per hour, preparation for A costs 4 times Rp 150,000 = Rp 600,000. Preparation for B costs 20 times Rp 150,000 = Rp 3 million.\n\nB requires Rp 2.4 million more in preparation. If we do the work ourselves, that amount does not arrive as a separate invoice. But the extra 16 hours are still used up, and could have gone toward other work.\n\nThose hours can differ considerably. The expensive model may need extensive corrections too, or the skill we need may already exist. The 4 and 20 hours are assumptions for this example. In our own work, we should record the time spent preparing both options.\n\n## How Often Must We Use It Before It Costs Less?\n\n![A printing press with a reusable plate and repeated sheets](https://evanpurnama.com/ai-model-cost/assets/repeat.jpg)\n\nPreparation can serve repeated tasks that use the same rules.\n\nAfter testing, suppose the AI usage cost to complete one report is Rp 5,000 for A and Rp 1,000 for B. These amounts include all model calls and retries, assuming the average stays constant over the comparison period.\n\nFor now, assume the review time and final quality are the same. B saves Rp 4,000 per report.\n\nDivide the extra Rp 2.4 million in preparation by Rp 4,000 in savings, and we need 600 reports to recover the difference. At report 600, total costs are equal. B becomes cheaper after that, as long as our assumptions hold.\n\nAt only 100 reports, A costs Rp 600,000 plus Rp 500,000 = Rp 1.1 million. B costs Rp 3 million plus Rp 100,000 = Rp 3.1 million. B's AI usage is 80% cheaper, but its total cost is still Rp 2 million higher.\n\nAt 1,000 reports, A costs Rp 5.6 million and B costs Rp 4 million. By then, the usage savings have paid for the additional preparation.\n\nThis is the break-even point: the volume at which both options have the same total cost. If we need 20 reports per month, reaching 600 reports takes 30 months. At 1,000 reports per month, we reach that volume within the first month.\n\nThe 30-month calculation assumes we can keep using the skill that long without extra costs from changes. File formats, business rules, or the model itself may change in the meantime. How often we use the skill matters to whether the preparation is worth doing.\n\n## What If Review Takes Longer?\n\n![A magnifying glass and stopwatch on report sheets](https://evanpurnama.com/ai-model-cost/assets/review.jpg)\n\nExtra review time can use up the saving on AI usage.\n\nLet's change one assumption. B needs an extra 2 minutes of review per report because the team more often has to check its explanation and correct figures quoted incorrectly from the script output.\n\nAt Rp 150,000 per hour, one minute costs Rp 2,500. An extra 2 minutes costs Rp 5,000 per report. The AI usage saving was only Rp 4,000, so B now costs Rp 1,000 more for every report, even before we count its additional preparation.\n\nIf that continues, higher volume will not make B more economical. Every additional report increases the difference.\n\nBut we need to measure those 2 minutes. We cannot assume that a cheaper model always makes more mistakes. B's scripts might produce more consistent calculations and reduce review time. A can also quote the wrong figure or miss a refund.\n\nWe can compare them using the same set of reports and the same acceptance criteria. All transactions must be accounted for, net sales must agree with a checked calculation, and the explanation must refer to the correct branches and periods.\n\nRecord the cost and time until the report meets those requirements. Failed attempts still count, including cases where someone finishes the report manually. If we request 100 reports and only 80 are completed, we must also account for the remaining 20. An option should not appear cheaper because unfinished work was removed from the calculation.\n\nThere is also a difference between the value of time and cash savings. If the team's salaries stay the same, reducing review time may not lower spending that month. It may give people time for other reports, reduce overtime, or delay the need to hire another person.\n\n## Can We Keep Using the Skill?\n\nReturn to the original example, where review time is the same. Suppose B needs 4 additional hours of maintenance per month compared with A. Perhaps a branch changes its file format and we need to adjust the script.\n\nThat costs 4 times Rp 150,000 = Rp 600,000 per month. At a saving of Rp 4,000 per report, we need 150 reports per month just to cover the additional maintenance.\n\nAt 100 reports per month, AI usage saves Rp 400,000, while maintenance costs Rp 600,000. B costs Rp 200,000 more each month, and we have not recovered the extra Rp 2.4 million in preparation either.\n\nAt 1,000 reports per month, AI usage saves Rp 4 million. Subtract Rp 600,000 for maintenance, and the monthly saving is Rp 3.4 million. That covers the extra Rp 2.4 million in preparation within the first month, including a full month's maintenance cost.\n\nSome skills can serve several teams, spreading their preparation cost across more work. Those tasks should use the same rules and scripts, though. If each team needs its own adjustments, we need to count that time too.\n\n## Which Model Should We Start With?\n\nI would start by trying both options on work that represents what the team handles regularly, including files that have caused problems before. That helps us see which parts need a more capable model and which benefit from clear instructions or scripts.\n\nThe skill built for B may help A too. We can then compare both models with that skill. There is no reason to keep the expensive model without skills just because that was our starting comparison.\n\nFor work we will do only a few times, preparing and maintaining a skill may cost more than it saves in usage. Paying for a more expensive model can make sense if it gets us an acceptable result sooner at a lower total cost.\n\nFor repeated work with reasonably stable rules, there are more opportunities to reuse the preparation. A cheaper model with skills becomes an attractive option if the results meet our requirements and the total cost, including review, remains lower.\n\nWe can also use both in one process. A cheaper model handles familiar file formats, while files that fail checks go to another model or a person. The checks and escalations have their own costs. We also need to look for errors that pass those checks, since a more expensive model will not necessarily correct them on its own.\n\nTo begin, we could take 30 old reports, use some to improve the skill, and reserve the rest for a final test. Record preparation time, AI cost, review time, and the number completed for both options. This is an initial way to find recurring problems, not enough evidence that rare failures are covered. Once we have those figures, we can compare them with the number of reports we will actually need next month.\n"},{"id":"ai-model-cost:id","slug":"ai-model-cost","language":"id","title":"Kalau AI-nya Lebih Murah, Apakah Total Biayanya Ikut Turun?","url":"https://evanpurnama.com/ai-model-cost/id/","description":"Model AI murah membutuhkan berapa banyak pemakaian agar lebih ekonomis? Kita hitung biaya skill, pemakaian, review, dan perawatannya.","date":"9 September 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/ai-model-cost.id.md","sha256":"24d4d4fa4d6ea5e5010cecf615a6bb2c04c622bc3c6590e30330e4f243f8035e","text":"Source: https://evanpurnama.com/ai-model-cost/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# Kalau AI-nya Lebih Murah, Apakah Total Biayanya Ikut Turun?\n\nCatatan : AI berkembang dengan sangat cepat. Apabila kita membaca artikel ini 6 sampai 12 bulan setelah tanggal publish, kemungkinan besar sebagian kemampuan dan harga modelnya sudah berbeda. Sebaiknya cek sumber terbaru sebelum mengambil keputusan.\n\n![Timbangan membandingkan koin dan stopwatch dengan tumpukan koin](https://evanpurnama.com/ai-model-cost/assets/hero.jpg)\n\nWaktu persiapan dan pemeriksaan ikut masuk dalam biaya pekerjaan.\n\nKalau setiap beberapa hari kita perlu top-up untuk memakai AI, cukup wajar kalau mulai mencari model lain yang lebih murah. Apalagi apabila pekerjaan kita sebagian besar berulang. Membaca file yang formatnya mirip, mengambil informasi yang sama, lalu membuat laporan dengan struktur yang sama.\n\nAda anggapan bahwa kalau kita cukup pintar membuat instruksi dan skill, model yang lebih murah seharusnya sudah cukup. Menurut saya ini menarik untuk dibahas, karena membuat instruksi yang bagus juga membutuhkan waktu. Kita perlu mencari contoh, mencoba hasilnya, memperbaiki bagian yang salah, lalu mencoba lagi.\n\nSehingga kita perlu menghitung biaya pemakaian AI dan waktu kerja yang dibutuhkan agar hasilnya bisa dipakai.\n\nDi artikel ini kita coba membahas biaya untuk menyelesaikan 1 jenis pekerjaan. Semua nominal dan waktu pengerjaan dalam contoh adalah asumsi untuk mempermudah perhitungan, bukan harga model tertentu atau data operasional perusahaan.\n\n## Bagian Mana yang Bisa Dibantu Skill?\n\nAnggap saja setiap minggu tim kita menerima laporan penjualan dari beberapa cabang. AI diminta membaca file tersebut, menghitung penjualan bersih, lalu menjelaskan cabang mana yang hasilnya berbeda jauh dari minggu sebelumnya.\n\nPekerjaan ini membutuhkan penjelasan yang cukup spesifik. Apakah transaksi yang dibatalkan masih ada di file? Apakah diskon sudah mengurangi nominal penjualan? Kalau nama cabang ditulis dengan cara yang berbeda, apakah datanya perlu digabung? Refund dicatat pada minggu transaksi awal atau minggu uang dikembalikan?\n\nOrang yang biasa membuat laporan tersebut kemungkinan sudah tahu jawabannya. Agar AI bisa mengikuti cara kerja yang sama, kita bisa membuat skill yang berisi aturan, contoh file, dan script untuk perhitungan yang berulang.\n\nSkill di sini adalah paket instruksi dan bahan pendukung yang bisa dipakai AI saat mengerjakan tugas tertentu. Membuat skill tidak otomatis mengubah model dasarnya seperti pada proses training.\\*\n\nDengan skill tersebut, AI tidak perlu mencari cara dari awal setiap kali menerima file. Misalnya untuk menghitung total, AI menjalankan script yang sudah kita cek, lalu memakai hasilnya untuk membuat penjelasan. Model yang lebih murah mungkin sudah bisa mengerjakan bagian ini dengan baik.\n\nRiset SkillsBench membandingkan agent yang memakai skill yang telah disiapkan dengan agent tanpa skill. Hasilnya menunjukkan bahwa skill bisa membantu agent menyelesaikan lebih banyak tugas dengan benar, dan pada konfigurasi tertentu model yang lebih kecil dengan skill bisa mengimbangi model yang lebih besar tanpa skill. Akan tetapi manfaatnya berbeda antarjenis pekerjaan. Skill yang dibuat sendiri oleh model juga tidak otomatis memberi peningkatan. [Paper SkillsBench](https://arxiv.org/html/2602.12670v1).\n\nDengan hasil seperti ini, menurut saya model murah dengan skill yang sesuai layak dicoba. Untuk laporan penjualan kita, tetap perlu dicek apakah angka penjualan, perlakuan refund, dan penjelasannya benar. Skor benchmark saja belum menjawab berapa banyak waktu yang dibutuhkan tim kita untuk mendapatkan hasil tersebut.\n\n## Berapa Biaya Menyiapkannya?\n\nSekarang anggap saja kita mencoba 2 pilihan pada laporan yang sama. Pilihan A memakai model yang lebih mahal. Pilihan B memakai model yang lebih murah dengan tambahan skill dan script khusus.\n\nKeduanya tetap membutuhkan aturan bisnis, akses data, dan pemeriksaan hasil. Untuk mempermudah, kita tidak memasukkan biaya yang sama pada kedua pilihan. Kita hanya menghitung biaya tambahan yang berbeda di antara keduanya.\n\nKatakanlah pilihan A membutuhkan 4 jam untuk disiapkan dan diuji. Pilihan B membutuhkan 20 jam, karena kita perlu membuat script tambahan, memilih contoh, dan memperbaiki instruksinya agar hasilnya memenuhi kebutuhan yang sama.\n\nAnggap saja biaya waktu orang yang mengerjakan ini Rp 150.000 per jam. Berarti persiapan A sebesar 4 dikali Rp 150.000 = Rp 600.000. Persiapan B sebesar 20 dikali Rp 150.000 = Rp 3 juta.\n\nPilihan B membutuhkan tambahan biaya persiapan Rp 2,4 juta. Kalau orangnya kita sendiri, uang sebesar itu memang tidak keluar sebagai invoice baru. Akan tetapi kita tetap menggunakan 16 jam tambahan yang sebenarnya bisa dipakai untuk pekerjaan lain.\n\nTentunya jumlah jam ini bisa berbeda. Model mahal mungkin membutuhkan banyak perbaikan juga, atau skill yang kita perlukan ternyata sudah tersedia. Angka 4 jam dan 20 jam hanya asumsi pada contoh ini. Dalam pekerjaan sendiri, sebaiknya kita mencatat waktu yang benar-benar dipakai pada kedua pilihan.\n\n## Berapa Kali Perlu Dipakai agar Lebih Murah?\n\n![Mesin cetak dengan pelat yang bisa dipakai berulang](https://evanpurnama.com/ai-model-cost/assets/repeat.jpg)\n\nBiaya persiapan bisa dibagi ke pekerjaan yang memakai aturan yang sama.\n\nSetelah diuji, anggap saja biaya pemakaian AI untuk menyelesaikan 1 laporan adalah Rp 5.000 pada pilihan A dan Rp 1.000 pada pilihan B. Angka ini mencakup seluruh pemanggilan model dan percobaan ulang yang dibutuhkan, dengan asumsi biaya rata-ratanya tetap selama periode perbandingan.\n\nUntuk sementara, anggap juga waktu pemeriksaan dan kualitas hasil akhirnya sama. Berarti setiap laporan yang dikerjakan dengan B menghemat Rp 4.000.\n\nTambahan biaya persiapannya Rp 2,4 juta. Kita membaginya dengan penghematan Rp 4.000 per laporan, sehingga perlu 600 laporan untuk menutup tambahan biaya tersebut. Setelah 600 laporan, total biaya kedua pilihan sama. Setelah itu B mulai lebih murah, selama asumsi tadi masih berlaku.\n\nKalau baru dipakai untuk 100 laporan, total A adalah Rp 600.000 ditambah Rp 500.000 = Rp 1,1 juta. Total B adalah Rp 3 juta ditambah Rp 100.000 = Rp 3,1 juta. Biaya pemakaian AI pada B memang 80% lebih murah, tetapi totalnya masih Rp 2 juta lebih besar.\n\nKalau dipakai untuk 1.000 laporan, A menjadi Rp 5,6 juta dan B menjadi Rp 4 juta. Sekarang penghematan biaya pemakaian AI sudah menutup tambahan biaya membuat skill.\n\nIni biasa disebut break-even, yaitu jumlah pemakaian ketika total biaya kedua pilihan sama. Kalau kita hanya membutuhkan 20 laporan per bulan, 600 laporan baru tercapai setelah 30 bulan. Kalau ada 1.000 laporan per bulan, jumlah tersebut tercapai dalam bulan pertama.\n\nPerhitungan 30 bulan tadi membutuhkan asumsi bahwa skill masih bisa dipakai selama itu tanpa perubahan biaya tambahan. Padahal format file, aturan bisnis, atau model yang dipakai bisa berubah. Sehingga frekuensi pemakaian ikut memengaruhi apakah investasi membuat skill masuk akal.\n\n## Bagaimana Kalau Pemeriksaannya Lebih Lama?\n\n![Kaca pembesar dan stopwatch di atas lembar laporan](https://evanpurnama.com/ai-model-cost/assets/review.jpg)\n\nPenghematan pemakaian AI bisa habis untuk tambahan waktu review.\n\nKita ubah 1 asumsi saja. Ternyata pilihan B membutuhkan tambahan 2 menit pemeriksaan per laporan, karena tim harus lebih sering mengecek penjelasan dan memperbaiki angka yang salah dikutip dari hasil script.\n\nDengan biaya waktu Rp 150.000 per jam, 1 menit bernilai Rp 2.500. Tambahan 2 menit berarti Rp 5.000 per laporan. Penghematan pemakaian AI tadi hanya Rp 4.000, sehingga total biaya B sekarang Rp 1.000 lebih besar untuk setiap laporan, bahkan sebelum menghitung tambahan persiapan.\n\nKalau kondisi ini berlanjut, menambah jumlah laporan tidak akan membuat B lebih ekonomis. Setiap laporan tambahan juga menambah selisih biayanya.\n\nAkan tetapi tambahan 2 menit ini perlu diukur. Kita tidak bisa langsung beranggapan bahwa model murah pasti lebih sering salah. Bisa saja script di pilihan B membuat perhitungannya lebih konsisten, sehingga pemeriksaannya malah lebih cepat. Model A juga tetap bisa salah mengutip angka atau melewatkan refund.\n\nCara membandingkannya adalah dengan memakai kumpulan laporan yang sama dan syarat hasil yang sama. Misalnya seluruh transaksi harus masuk, penjualan bersih harus sesuai perhitungan yang sudah dicek, dan penjelasan harus merujuk ke cabang serta periode yang benar.\n\nCatat biaya dan waktu sampai laporan tersebut memenuhi syarat. Percobaan yang gagal tetap masuk biaya, termasuk apabila akhirnya orang perlu menyelesaikan laporan secara manual. Kalau 100 laporan diminta tetapi hanya 80 selesai, 20 sisanya tetap perlu dicatat sebagai pekerjaan yang belum selesai. Jangan sampai pilihan terlihat murah karena pekerjaan yang belum selesai dikeluarkan dari hitungan.\n\nOya, biaya waktu ini berbeda dengan uang yang bisa langsung dihemat perusahaan. Apabila gaji tim tetap sama, pengurangan waktu review belum tentu mengurangi pengeluaran bulan itu. Manfaatnya bisa berupa tambahan waktu untuk mengerjakan laporan lain, atau mengurangi kebutuhan lembur dan penambahan orang di kemudian hari.\n\n## Apakah Skill-nya Bisa Dipakai Terus?\n\nKembali ke contoh awal, ketika waktu review kedua pilihan masih sama. Anggap saja B membutuhkan tambahan 4 jam perawatan setiap bulan dibandingkan A. Misalnya ada perubahan file dari cabang dan script perlu diadjust.\n\nBiaya tambahannya 4 dikali Rp 150.000 = Rp 600.000 per bulan. Dengan penghematan Rp 4.000 per laporan, kita membutuhkan 150 laporan per bulan hanya untuk menutup tambahan perawatan tersebut.\n\nKalau pemakaiannya 100 laporan per bulan, penghematan AI hanya Rp 400.000, sedangkan perawatannya Rp 600.000. Berarti B masih lebih mahal Rp 200.000 per bulan, dan tambahan persiapan Rp 2,4 juta di awal juga belum tertutup.\n\nKalau pemakaiannya 1.000 laporan per bulan, penghematan AI Rp 4 juta dikurangi perawatan Rp 600.000 = Rp 3,4 juta per bulan. Dengan kondisi tersebut, tambahan persiapan Rp 2,4 juta bisa tertutup dalam bulan pertama (dengan biaya perawatan 1 bulan penuh sudah ikut dihitung).\n\nSebagian skill mungkin bisa dipakai oleh beberapa tim. Biaya awalnya jadi bisa dibagi ke lebih banyak pekerjaan. Akan tetapi pekerjaan yang dihitung sebaiknya memang memakai aturan dan script yang sama. Kalau tiap tim memerlukan penyesuaian sendiri, waktu penyesuaian itu perlu masuk dalam perhitungan juga.\n\n## Lalu Sebaiknya Mulai dari Model yang Mana?\n\nMenurut saya, kita bisa mulai dengan mencoba kedua pilihan pada pekerjaan yang cukup mewakili kebutuhan sehari-hari. Sertakan juga file yang pernah bermasalah. Dari situ baru terlihat bagian mana yang membutuhkan model yang lebih mampu, dan bagian mana yang terbantu oleh instruksi atau script yang jelas.\n\nAda kemungkinan skill yang dibuat untuk B ternyata membantu A juga. Dalam kondisi itu, pilihan berikutnya adalah membandingkan kedua model dengan skill tersebut. Kita tidak perlu mempertahankan perbandingan model mahal tanpa skill hanya karena contoh awalnya seperti itu.\n\nUntuk pekerjaan yang baru akan dilakukan beberapa kali, waktu membuat dan merawat skill mungkin lebih besar daripada penghematan pemakaiannya. Membayar model lebih mahal bisa masuk akal apabila hasil yang dibutuhkan bisa didapat lebih cepat dengan total biaya lebih kecil.\n\nUntuk pekerjaan berulang dengan aturan yang sudah cukup stabil, kita mempunyai lebih banyak kesempatan memakai kembali hasil persiapannya. Di sini model murah dengan skill bisa menjadi pilihan yang menarik, selama hasilnya memenuhi syarat dan total biaya termasuk pemeriksaannya masih lebih kecil.\n\nKeduanya juga bisa dipakai dalam 1 proses. Laporan dengan format yang sudah dikenal dikerjakan model murah, sedangkan file yang gagal memenuhi pemeriksaan diteruskan ke model lain atau orang. Biaya membuat sistem pemeriksaan dan menangani laporan yang diteruskan itu tetap perlu dihitung. Kita juga perlu mengecek kesalahan yang lolos dari pemeriksaan, karena model mahal belum tentu memperbaikinya dengan sendirinya.\n\nUntuk mulai mencoba, kita bisa mengambil 30 laporan lama sebagai contoh, memisahkan sebagian untuk memperbaiki skill dan sebagian lagi untuk pengujian akhir. Catat waktu persiapan, biaya AI, waktu review, dan jumlah laporan yang selesai pada kedua pilihan. Pengujian ini hanya langkah awal untuk melihat pola masalah, belum cukup untuk menyimpulkan bahwa kesalahan yang jarang terjadi sudah tertangani. Setelah angkanya ada, kita bisa membandingkannya dengan jumlah laporan yang benar-benar akan dikerjakan bulan depan.\n"},{"id":"ai-agent-authority:en","slug":"ai-agent-authority","language":"en","title":"If AI Can Do the Work, What Do We Still Need to Decide?","url":"https://evanpurnama.com/ai-agent-authority/","description":"Follow a refund request to understand the decisions an AI agent needs, unfinished transactions, and the work automation actually removes.","date":"5 September 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/ai-agent-authority.en.md","sha256":"bb05a60595347aba9517a2b8834ccaa93dadaa4ab88345f5fe9cd4b602382d6f","text":"Source: https://evanpurnama.com/ai-agent-authority/\nAuthor: Evan Purnama\nLanguage: en\n\n# If AI Can Do the Work, What Do We Still Need to Decide?\n\nNote: AI is changing quickly. If you are reading this 6 to 12 months after publication, some of the capabilities and conditions below will probably have changed. Check the latest sources before making a decision.\n\n![A human hand passing a key to a mechanical hand](https://evanpurnama.com/ai-agent-authority/assets/img-01-delegation.jpg)\n\nAccess follows the work the agent is allowed to carry out.\n\nWhen a customer asks for a refund, the person handling the message needs to know whether it is allowed, how much to return, and when to ask for approval. Some of those decisions may be documented. Others may follow practices the team has developed over time.\n\nNow we want AI to handle the same request. It can read the message, find the transaction, and call a function in an application to submit a refund. I think we need to be more specific about the work we are handing over, including which decisions it may make without checking with our team again.\n\nAn AI agent, as used here, is an AI system that can choose steps and use tools to carry out a task, then check the results before continuing. A tool is a function the AI can call, such as looking up a transaction or requesting a refund. [Anthropic](https://www.anthropic.com/research/trustworthy-agents) also explains this way of working.\n\nWe will use one example: a refund. We will follow it from the customer's message until we know the outcome from the payment system. Every amount, case count, and handling time below is illustrative. None comes from a particular company's operations.\n\n## What Does a Refund Request Actually Involve?\n\n![A return parcel holding a shirt with a stack of coins](https://evanpurnama.com/ai-agent-authority/assets/img-02-refund.jpg)\n\nOne refund request involves several systems and decisions.\n\nSuppose we run a business that receives customer requests through WhatsApp. A message comes in:\n\n> Hi, the item I received yesterday is the wrong size. I'd like to return it. Can I get a refund?\n\nIf the AI only needs to explain the refund process, we can give it our returns policy. It reads the document and explains the conditions and steps to the customer.\n\nNow suppose we want it to handle the request through to completion. The system needs to establish who the customer is and which transaction they mean. Then it needs to check the purchase date, the items being returned, whether those items have arrived, and how much can be refunded. After that, it can submit the refund to the payment system and update the customer.\n\nFor this example, assume our policy requires the returned goods to be received and inspected before a refund can be processed. The customer's message alone is therefore not enough. The AI needs information from the order, warehouse, and payment systems. Each may have a different status at the same point in time.\n\nThe customer might say they have shipped the item back, while the warehouse has not received it yet. Or the warehouse might have received it but not finished the inspection. The request is the same, but the next step depends on the available information.\n\nThis is where the AI's ability to understand the customer's language helps. The customer does not need to know what our internal process is called or supply every detail in the right format at the start. The AI can ask for missing information and find the relevant records, provided we have given it access.\n\n## Who Decides Whether the Refund Is Allowed?\n\nSuppose our team decides that refunds of up to Rp 200,000 can be processed automatically if all the conditions are met. Larger amounts need a supervisor's approval. The Rp 200,000 limit is an example of a business decision, not a general standard.\n\nWe still have to explain what those conditions are. Does the amount include shipping? What if the purchase used a voucher? What if some of the items have already been refunded? What if the customer asks for the money to go to a different bank account? Our answer also has to follow the payment provider's rules. Stripe, for example, restricts refund destinations to the original payment method. [Stripe refund destinations](https://docs.stripe.com/refunds#refund-destinations).\n\nThese questions existed before we started using AI. An experienced support team may already know the answers, or know whom to ask. To automate the work, we need to write down the rules the team uses and build a system that can apply them.\n\nAI can help read the documents and propose rules. The company still needs to decide who qualifies for a refund, how much they can receive, and who can approve an exception.\n\nOnce the limit is agreed, the system that executes refunds should also check each requested amount against it. If the AI requests Rp 500,000, the system should require the appropriate approval before proceeding. Putting a Rp 200,000 limit in the AI's instructions alone does not ensure that larger transactions cannot happen.\n\nWe also need to think about the total amount that can be processed in a day. Suppose there are 100 refunds of Rp 150,000 each. Every refund is below the limit, but 100 times Rp 150,000 is Rp 15 million. The company may be comfortable with that, or it may want another check once the daily total reaches a certain amount.\n\nWe can start with a small limit and adjust it after seeing the results in production. A better AI model still needs rules about how much money it is allowed to process automatically.\n\n## What Happens When the Work Is Only Partly Done?\n\nNow suppose the customer qualifies and the refund has been approved. The AI submits a Rp 150,000 refund, but the connection drops before it receives the result.\n\nWe do not yet know whether the request failed to arrive, is still being processed, or was processed but the response never reached our system. If we immediately submit another request as a new transaction, we could refund the money twice.\n\nOne way to handle this is to give each refund request a fixed ID. If the payment system supports this mechanism, we send that ID as an idempotency key when submitting the refund and reuse it when retrying the same request. The payment system can then recognize the retry and avoid creating another transaction. This is called idempotency. Stripe, for example, provides idempotency keys for retrying requests after connection problems. Their use is subject to the provider's rules, including how long keys are retained. [Stripe documentation](https://docs.stripe.com/api/idempotent_requests).\n\nIdempotency here means that sending the same request again does not create a second refund. The application needs to store the request ID so it stays the same even if the AI resumes the work in a different conversation.\n\nAn accepted request does not necessarily mean the refund is complete either. Stripe's documentation describes refunds that are pending, need further action, or fail. Our message to the customer needs to reflect the status the system actually knows. Acceptance of the request is not enough to say the money has reached their account. [Stripe refund documentation](https://docs.stripe.com/refunds).\n\nThe Rp 150,000 refund already has approval. We now need to know the result of submitting it to the payment system. If it is still pending, the AI can tell the customer that the refund is being processed, and our system needs to check its progress again. We need to decide which status is sufficient to close the customer request and who follows up if the refund fails.\n\nIf the status is unclear, the system needs to record the request and its latest status for another check. If it still cannot be completed, the case needs to go to the person or team responsible. They need the full context, including which transaction was attempted and the last result, so they can continue without asking the customer to explain everything again.\n\n## Does Our Team Need to Approve Everything?\n\n![A magnifying glass inspecting a knotted thread among straight threads](https://evanpurnama.com/ai-agent-authority/assets/img-03-review.jpg)\n\nWe need to decide which cases still require the team’s review.\n\nAsking for approval on every refund can be a reasonable starting point with AI. The team can check its work before money is processed. We also need to understand which tasks people still carry out after the AI has helped.\n\nSuppose we receive 1,000 refund requests a month. Before AI, the support team spends an average of 6 minutes of active work per request, from reading the message and checking records to recording the result and updating the customer. That is 1,000 times 6 minutes = 6,000 minutes, or 100 hours a month. Physical inspection of returned goods and time spent waiting for payment processing are outside this calculation, both before and after AI.\n\nWith AI, collecting the information and preparing a recommendation happen automatically. For the same number and types of requests, suppose all the support work still done by people takes an average of 2 minutes per request. This includes reviewing the recommendation, correcting errors, and giving approval. Any other work the team still performs must also be included in that average.\n\nThe team's time becomes 1,000 times 2 minutes = 2,000 minutes, or 33 hours and 20 minutes a month. That saves 66 hours and 40 minutes. The 2-minute average is an illustrative assumption. During a pilot, we need to measure whether it is enough to handle the requests according to our rules.\n\nEven with those savings, every refund still waits for a person's approval. If the supervisor has not had time to check it, the request cannot proceed. That waiting time is separate from the active work we counted, so the reduction in working hours does not tell us how quickly the customer receives the result.\n\nI think approval should depend on the type of case and the limits we have agreed. Suppose the Rp 150,000 refund meets the conditions, the returned-goods records are complete, and the amount is within the Rp 200,000 automatic limit. Once testing gives us sufficient grounds to allow automatic processing, the system can execute it without approval on each case. Requests above the limit or requiring an exception still go to someone authorized to decide.\n\nWe can also keep approval on every refund if the risk remains unacceptable. The example still has savings from collecting information and preparing recommendations. To assess the benefit, we also need to count monitoring, integration maintenance, and error handling outside the work on individual cases. The hours saved may reduce overtime or give the team time to serve other customers, depending on the company.\n\n## Where Should We Start?\n\nFor a pilot, we can choose one type of refund with clear conditions. Have the AI make recommendations first, then compare them with the team's decisions on the same cases. When the results differ, we need to work out why. Did the AI misread the data? Was information missing? Or do people on our own team understand the rules differently?\n\nBefore giving the AI access to execute transactions, we should also test cases where the process breaks down. For example, a customer sends the request twice, the connection drops, the amount changes after approval, or the returned-goods status changes while the refund is being processed. Approval needs to be tied to the transaction, amount, and conditions that were checked. If those details change before execution, the system needs to check eligibility again and obtain fresh approval where required.\n\nFrom those results, we can decide which cases can be processed automatically and which still need a person. The transaction record should show the data used, the rules applied, the approval given, and the payment system's result. That gives the team enough information to investigate a complaint or improve the process.\n\nDuring the pilot, we also need to record the team's remaining work, how long customers wait, and errors that need correction. Those results help us judge whether the process is useful and whether any types of cases are ready to proceed without approval on every request.\n\nOf course, this refund example simplifies quite a few things. Every business has its own return conditions, payment systems, and customer situations. To try this in our own company, we can ask the team to choose one of their most frequent requests and explain the steps they take and the decisions they make until it is complete.\n"},{"id":"ai-agent-authority:id","slug":"ai-agent-authority","language":"id","title":"Kalau AI Sudah Bisa Menjalankan Pekerjaan, Apa yang Masih Perlu Kita Tentukan?","url":"https://evanpurnama.com/ai-agent-authority/id/","description":"Mengikuti 1 permintaan refund untuk memahami batas keputusan AI, transaksi yang belum selesai, dan waktu kerja yang berkurang.","date":"5 September 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/ai-agent-authority.id.md","sha256":"8993da2a9ae898dced6852e2350a5d2f11b355f841aaa3546d4b95aabf3236b0","text":"Source: https://evanpurnama.com/ai-agent-authority/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# Kalau AI Sudah Bisa Menjalankan Pekerjaan, Apa yang Masih Perlu Kita Tentukan?\n\nCatatan : AI berkembang dengan sangat cepat. Apabila Anda membaca artikel ini 6 sampai 12 bulan setelah tanggal publish, kemungkinan besar sebagian kemampuan dan kondisi di bawah sudah berbeda. Sebaiknya cek sumber terbaru sebelum mengambil keputusan.\n\n![Tangan manusia menyerahkan kunci kepada tangan mekanis](https://evanpurnama.com/ai-agent-authority/assets/img-01-delegation.jpg)\n\nAkses yang diberikan mengikuti pekerjaan yang boleh dijalankan.\n\nKetika customer meminta refund, orang yang menerima chat perlu tahu apakah permintaan itu boleh diproses, berapa uang yang dikembalikan, dan kapan perlu meminta approval. Sebagian keputusan tersebut mungkin sudah tertulis, sebagian lagi selama ini mengikuti kebiasaan tim.\n\nSekarang kita ingin AI mengurus permintaan yang sama. AI bisa membaca chat, mencari transaksi, dan memanggil fungsi di aplikasi untuk mengajukan refund. Menurut saya, di sini kita perlu menjelaskan lebih detail pekerjaan yang ingin kita serahkan, termasuk keputusan yang boleh diambil tanpa bertanya lagi ke tim.\n\nAI agent di artikel ini adalah sistem AI yang bisa memilih langkah dan menggunakan tools untuk menjalankan suatu pekerjaan, kemudian mengecek hasilnya sebelum melanjutkan. Tool adalah fungsi yang bisa dipanggil AI, misalnya untuk membaca transaksi atau mengajukan refund. Penjelasan tentang cara kerja ini juga ada di [Anthropic](https://www.anthropic.com/research/trustworthy-agents).\n\nDi artikel ini kita pakai 1 contoh saja, yaitu refund atau pengembalian pembayaran. Kita akan mengikuti prosesnya dari chat customer sampai hasil dari sistem pembayaran diketahui. Semua nominal, jumlah kasus, dan waktu pengerjaan di bawah hanya ilustrasi, bukan data operasional perusahaan tertentu.\n\n## Kalau Customer Meminta Refund, Apa Saja yang Perlu Dikerjakan?\n\n![Paket pengembalian berisi pakaian dengan tumpukan koin](https://evanpurnama.com/ai-agent-authority/assets/img-02-refund.jpg)\n\n1 permintaan refund melibatkan beberapa sistem dan keputusan.\n\nAnggap saja kita mempunyai bisnis yang menerima permintaan customer lewat WhatsApp. Suatu hari masuk chat seperti ini:\n\n> Kak, barang yang kemarin salah ukuran. Saya mau balikin aja, bisa refund?\n\nKalau tugas AI hanya menjelaskan cara refund, kita bisa memberinya dokumen kebijakan pengembalian barang. AI membaca dokumen itu, lalu menjelaskan syarat dan langkahnya ke customer.\n\nSekarang kita ingin AI mengurus permintaan tersebut sampai selesai. Berarti sistem perlu memastikan siapa customer-nya dan transaksi mana yang dimaksud. Setelah itu mengecek tanggal pembelian, barang yang dikembalikan, status penerimaan barang, dan jumlah uang yang bisa dikembalikan. Baru kemudian mengajukan refund ke sistem pembayaran dan memberi kabar ke customer.\n\nUntuk contoh ini, anggap saja kebijakan perusahaan mengharuskan barang sudah diterima dan diperiksa sebelum refund diproses. Sehingga chat customer saja belum cukup untuk memproses refund. AI membutuhkan data dari sistem pesanan, gudang, dan pembayaran, yang mana ketiganya bisa mempunyai status yang berbeda pada waktu yang sama.\n\nCustomer bisa mengatakan barang sudah dikirim balik, tetapi gudang belum menerimanya. Gudang bisa sudah menerima barang, tetapi belum selesai memeriksa kondisinya. Permintaannya sama, akan tetapi langkah berikutnya berbeda tergantung data yang tersedia.\n\nDi sini kemampuan AI memahami bahasa customer memang berguna. Customer tidak perlu mengetahui nama proses atau mengisi semua informasi dalam format yang tepat sejak awal. AI bisa meminta informasi yang kurang dan mencari data yang sesuai, selama aksesnya memang kita sediakan.\n\n## Siapa yang Menentukan Refund Boleh Dilakukan?\n\nMisalnya tim kita membuat aturan bahwa refund sampai Rp 200.000 boleh diproses otomatis apabila semua syarat terpenuhi. Di atas nominal itu perlu approval supervisor. Angka Rp 200.000 ini hanya contoh keputusan bisnis, bukan standar yang berlaku umum.\n\nKita tetap perlu menjelaskan apa yang dimaksud dengan semua syarat. Apakah termasuk ongkos kirim? Bagaimana kalau pembeliannya menggunakan voucher? Bagaimana kalau sebagian barang sudah pernah direfund? Bagaimana kalau customer meminta uang dikirim ke rekening yang berbeda? Jawabannya juga perlu mengikuti ketentuan sistem pembayaran yang dipakai. Misalnya, Stripe membatasi tujuan refund ke metode pembayaran asal. [Ketentuan tujuan refund Stripe](https://docs.stripe.com/refunds#refund-destinations).\n\nPertanyaan seperti ini sebenarnya sudah ada sebelum kita menggunakan AI. Tim customer support yang berpengalaman mungkin sudah tahu jawabannya, atau tahu siapa yang perlu ditanya. Ketika pekerjaan tersebut ingin kita otomatisasi, kita perlu menuliskan aturan yang selama ini dipakai tim, kemudian membuat sistem yang bisa menjalankannya.\n\nAI bisa membantu membaca dokumen dan membuat usulan aturan. Akan tetapi keputusan tentang siapa yang berhak mendapatkan refund, berapa jumlahnya, dan siapa yang boleh memberikan pengecualian tetap perlu dibuat oleh perusahaan.\n\nSetelah batasnya disepakati, sistem yang menjalankan refund sebaiknya juga mengecek apakah nominal setiap permintaan masih sesuai dengan batas tersebut. Jadi walaupun AI mengajukan refund Rp 500.000, sistem akan meminta approval yang sesuai sebelum memprosesnya. Menuliskan batas Rp 200.000 di instruksi AI saja belum cukup untuk memastikan transaksi di atas batas itu tidak terjadi.\n\nSelain batas per transaksi, kita juga perlu memikirkan total refund yang bisa diproses dalam 1 hari. Katakanlah dalam 1 hari ada 100 refund, masing-masing Rp 150.000. Semua di bawah batas, tetapi totalnya 100 dikali Rp 150.000 = Rp 15 juta. Perusahaan mungkin nyaman dengan jumlah itu, mungkin juga ingin melakukan pemeriksaan tambahan ketika total harian mencapai angka tertentu.\n\nKita bisa memulai dengan batas yang kecil, lalu menyesuaikannya setelah melihat hasil di production. Model AI yang lebih bagus tetap membutuhkan aturan terkait jumlah uang yang boleh diproses otomatis.\n\n## Kalau Prosesnya Baru Selesai Sebagian, Bagaimana?\n\nSekarang anggap saja customer memenuhi syarat dan refund sudah disetujui. AI mengajukan pengembalian Rp 150.000, tetapi koneksi terputus sebelum hasilnya diterima.\n\nKita belum tahu apakah permintaan belum sampai, masih diproses, atau sudah diproses tetapi responsnya tidak sampai ke sistem kita. Kalau langsung mengajukan lagi sebagai transaksi baru, kita bisa memproses pengembalian uang 2 kali.\n\nSalah satu cara menangani kondisi ini adalah memberi setiap permintaan refund ID yang tetap. Apabila sistem pembayaran mendukung mekanisme ini, ID tersebut dikirim sebagai idempotency key saat mengajukan refund, lalu dipakai lagi ketika mengulang permintaan yang sama. Sistem pembayaran bisa mengenalinya dan tidak membuat transaksi baru. Mekanisme ini biasa disebut idempotency. Stripe, misalnya, menyediakan idempotency key untuk mengulang permintaan saat terjadi masalah koneksi. Pemakaiannya tetap mengikuti ketentuan provider, termasuk masa penyimpanan key. [Dokumentasi Stripe](https://docs.stripe.com/api/idempotent_requests).\n\nIdempotency di sini berarti pengiriman ulang permintaan yang sama tidak membuat refund kedua. ID permintaannya perlu disimpan oleh aplikasi, agar tetap sama walaupun AI melanjutkan pekerjaan dalam percakapan yang berbeda.\n\nSetelah permintaan diterima pun, refund belum tentu langsung selesai. Dokumentasi Stripe menjelaskan bahwa refund bisa pending, membutuhkan tindakan tambahan, atau gagal. Sehingga pesan ke customer harus mengikuti status yang benar-benar diketahui sistem. Status pengajuan diterima belum cukup untuk mengatakan uang sudah masuk ke rekening customer. [Dokumentasi refund Stripe](https://docs.stripe.com/refunds).\n\nUntuk refund Rp 150.000 tadi, approval sudah ada. Sekarang kita perlu mengetahui hasil pengajuannya di sistem pembayaran. Kalau statusnya masih pending, AI bisa memberi kabar bahwa refund sedang diproses, kemudian sistem kita perlu mengecek perkembangannya lagi. Sehingga kita perlu menentukan status apa yang cukup untuk menutup permintaan customer dan siapa yang melanjutkan apabila refund gagal.\n\nKalau statusnya belum jelas, sistem perlu mencatat permintaan dan status terakhirnya untuk dicek lagi. Apabila tetap tidak bisa diselesaikan, kasus tersebut perlu diteruskan ke orang atau tim yang bertanggung jawab. Informasinya harus lengkap, termasuk transaksi yang sudah dicoba dan hasil terakhirnya, sehingga orang tersebut bisa melanjutkan tanpa meminta customer mengulang semuanya dari awal.\n\n## Apakah Semuanya Perlu Approval dari Tim Kita?\n\n![Kaca pembesar memeriksa benang kusut di antara benang yang rapi](https://evanpurnama.com/ai-agent-authority/assets/img-03-review.jpg)\n\nKita perlu menentukan kasus mana yang masih harus diperiksa tim.\n\nMeminta approval untuk setiap refund bisa menjadi pilihan ketika kita baru mulai menggunakan AI. Tim masih bisa mengecek hasil kerjanya sebelum uang diproses. Akan tetapi kita juga perlu melihat apa saja yang masih dikerjakan orang setelah AI membantu.\n\nAnggap saja ada 1.000 permintaan refund per bulan. Sebelum menggunakan AI, tim customer support membutuhkan rata-rata 6 menit waktu kerja aktif per permintaan, mulai dari membaca chat, mengecek data, sampai mencatat hasil dan memberi kabar ke customer. Totalnya 1.000 dikali 6 menit = 6.000 menit, atau 100 jam per bulan. Waktu pemeriksaan fisik barang di gudang dan waktu menunggu proses pembayaran tidak masuk hitungan ini, baik sebelum maupun sesudah menggunakan AI.\n\nDengan AI, pengumpulan data dan pembuatan usulan dikerjakan otomatis. Anggap saja untuk jumlah dan jenis permintaan yang sama, seluruh pekerjaan customer support yang masih perlu dilakukan orang menjadi rata-rata 2 menit per permintaan. Waktu ini sudah termasuk mengecek usulan, memperbaiki hasil yang salah, dan memberikan approval. Jika masih ada pekerjaan lain yang dilakukan tim, waktunya juga harus masuk ke rata-rata tersebut.\n\nBerarti waktu kerja tim menjadi 1.000 dikali 2 menit = 2.000 menit, atau 33 jam 20 menit per bulan. Ada pengurangan 66 jam 40 menit. Angka 2 menit ini hanya asumsi untuk ilustrasi; dalam pilot, kita perlu mengukur apakah waktu tersebut cukup untuk menangani permintaan dengan hasil yang sesuai aturan.\n\nDengan penghematan itu pun, setiap refund masih menunggu approval dari orang. Kalau supervisor belum sempat mengecek, permintaannya tetap belum bisa diproses. Waktu menunggu ini berbeda dari waktu kerja aktif yang kita hitung tadi, sehingga pengurangan jam kerja belum memberi tahu seberapa cepat customer menerima hasilnya.\n\nMenurut saya, keputusan kapan meminta approval sebaiknya kembali ke jenis kasus dan batas yang sudah disepakati. Misalnya refund Rp 150.000 tadi sudah memenuhi syarat, data barang sudah lengkap, dan nominalnya masih di bawah batas otomatis Rp 200.000. Setelah hasil pengujian cukup untuk membolehkan proses otomatis, sistem bisa menjalankannya tanpa approval per kasus. Permintaan yang melewati batas atau membutuhkan pengecualian tetap diteruskan ke orang yang berwenang.\n\nKita juga bisa tetap meminta approval untuk setiap refund apabila risikonya belum bisa diterima. Penghematan dari pengumpulan data dan pembuatan usulan tetap ada dalam contoh tadi. Untuk menilai manfaatnya, waktu monitoring, perawatan integrasi, dan penanganan kesalahan di luar pekerjaan per kasus juga perlu dihitung. Jam kerja yang berkurang bisa mengurangi lembur atau memberi tim waktu untuk menangani customer lain, tergantung kondisi perusahaan.\n\n## Jadi, Apa yang Perlu Kita Kerjakan Lebih Dulu?\n\nUntuk pilot project, kita bisa mulai dari 1 jenis refund yang syaratnya jelas. Jalankan AI untuk membuat usulan terlebih dahulu, lalu bandingkan usulannya dengan keputusan tim pada kasus yang sama. Perbedaan hasilnya perlu dibahas: apakah AI salah membaca data, datanya belum lengkap, atau orang di tim kita sendiri mempunyai pemahaman aturan yang berbeda?\n\nSebelum AI diberi akses untuk menjalankan transaksi, kita juga perlu mencoba kasus yang prosesnya tidak berjalan lancar. Misalnya customer mengirim permintaan 2 kali, koneksi terputus, nominal berubah setelah approval, atau status barang berubah ketika refund masih diproses. Approval perlu terkait dengan transaksi, nominal, dan syarat yang diperiksa. Apabila data tersebut berubah sebelum transaksi dijalankan, sistem perlu mengecek ulang kelayakannya dan meminta approval baru apabila diperlukan.\n\nDari hasil tersebut, kita bisa memutuskan kasus mana yang boleh diproses otomatis dan mana yang tetap perlu ditangani orang. Catatan transaksi perlu menunjukkan data yang dipakai, aturan yang berlaku, approval yang diberikan, dan hasil dari sistem pembayaran. Dengan begitu, tim mempunyai informasi yang cukup apabila ada komplain atau perlu memperbaiki prosesnya.\n\nSelama pilot, kita juga perlu mencatat waktu kerja yang masih dibutuhkan tim, lama customer menunggu, dan kesalahan yang perlu diperbaiki. Dari hasil itu kita bisa menilai apakah proses yang dipilih sudah cukup membantu dan apakah ada jenis kasus yang siap diproses tanpa approval per permintaan.\n\nTentunya banyak hal di contoh refund ini yang oversimplification. Setiap bisnis mempunyai syarat pengembalian, sistem pembayaran, dan kondisi customer yang berbeda. Untuk mencoba di perusahaan sendiri, kita bisa mulai dengan meminta tim memilih 1 jenis permintaan yang paling sering mereka kerjakan, lalu menjelaskan langkah yang mereka kerjakan dan keputusan yang mereka ambil sampai permintaan tersebut selesai.\n"},{"id":"sf-playbook:id","slug":"sf-playbook","language":"id","title":"Apa Itu Playbook AI dari San Francisco? (Penjelasan Singkat, Beserta Sumbernya)","url":"https://evanpurnama.com/sf-playbook/","description":"Playbook AI dari San Francisco itu dokumen apa, siapa yang menulis, dan isinya apa. Lima laporan sumber dirangkum menjadi tujuh rekomendasi, dengan angka dan tautannya.","date":"4 September 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/sf-playbook.id.md","sha256":"0c9996d152e345f19c4a4b96c95bd78266087bb8346e1482a2d0293bc8d921f7","text":"Source: https://evanpurnama.com/sf-playbook/\nAuthor: Evan Purnama\nLanguage: id\n\n# Apa Itu Playbook AI dari San Francisco? (Penjelasan Singkat, Beserta Sumbernya)\n\n![Setumpuk laporan yang dijepit satu klip di atas meja](https://evanpurnama.com/sf-playbook/assets/img-01-hero.jpg)\n\nBeberapa laporan yang dibaca bersama.\n\nCatatan : AI dan laporan-laporan di bawah ini berubah dengan sangat cepat. Apabila Anda membaca artikel ini 6 sampai 12 bulan setelah tanggal publish, kemungkinan besar sebagian angka dan kondisi di bawah sudah berbeda. Sebaiknya cek sumber terbaru sebelum mengambil keputusan.\n\nDi artikel sebelumnya, [Kenapa Playbook AI dari San Francisco Tidak Bisa Langsung Dipakai di Jakarta?](https://evanpurnama.com/enterprise-ai-jakarta/), saya beberapa kali menyebut \"playbook AI dari San Francisco\" tanpa menjelaskan maksudnya. Ternyata cukup banyak yang bertanya : itu dokumen apa, siapa yang menulis, dan di mana bisa dibaca.\n\nSaya akui di artikel itu istilahnya memang kurang jelas. Waktu itu saya sengaja tidak berhenti untuk mendefinisikannya, karena definisinya memang berupa range, tidak ada 1 dokumen yang bisa ditunjuk, dan fokus artikelnya ada di asumsi yang berbeda di Jakarta, bukan di playbook-nya sendiri. Akan tetapi kalau istilahnya membuat pembaca bingung, sebaiknya dijelaskan. Jadi artikel ini penjelasan singkatnya.\n\nScope-nya saya batasi di 2 pertanyaan itu saja, yaitu isinya apa dan dari mana asalnya. Bagian mana yang cocok dan tidak cocok untuk Jakarta sudah dibahas di artikel sebelumnya, jadi tidak saya ulang di sini.\n\n## Playbook-nya Dokumen Apa?\n\n![Tiga amplop dengan ukuran berbeda di atas meja](https://evanpurnama.com/sf-playbook/assets/img-02-sources.jpg)\n\nTiga jenis sumber yang paling sering dikutip.\n\nSebenarnya bukan 1 dokumen. Tidak ada buku yang berjudul \"San Francisco Playbook\".\n\nKalau kita bekerja di tech, kiblatnya memang Silicon Valley. Cara membangun startup, cara VC di Sand Hill Road menilai perusahaan, cara YC menasihati founder-nya, sampai perdebatan tentang AI di X setiap minggu, semuanya datang dari sana dan kita ikuti dari Jakarta. Tidak ada 1 artikel yang menuliskan semua itu secara utuh. Akan tetapi orang yang bekerja di tech pada umumnya tahu isinya, karena setiap hari kita membacanya di internet, di newsletter, di podcast, dan di thread X.\n\nSand Hill Road adalah jalan di Menlo Park, dekat Stanford, tempat kantor VC-VC besar Amerika berkumpul, sehingga namanya dipakai sebagai sebutan untuk VC Silicon Valley secara umum. YC (Y Combinator) adalah accelerator startup paling terkenal di sana, yang nasihat-nasihatnya untuk founder banyak dijadikan acuan.\n\nYang saya sebut playbook AI dari San Francisco adalah bagian dari pengetahuan bersama itu, khusus tentang cara perusahaan besar mengadopsi AI. Artikel sebelumnya juga saya tulis dari sana, dari apa yang kita semua dengar dan dari pengalaman menjalankan perusahaan sendiri, bukan dari membaca dokumen tertentu. Akan tetapi ketika ada yang bertanya \"di mana bisa dibaca\", jawaban yang paling jujur adalah menunjuk ke beberapa dokumen yang isinya paling dekat dengan pengetahuan bersama itu, karena bisa dibaca dan dicek langsung. Untuk artikel ini saya cek dokumen-dokumen tersebut satu per satu, dan isinya memang kurang lebih sama dengan yang selama ini kita dengar. Dokumen-dokumen itu ada di 3 jenis sumber. Batasnya memang tidak tegas (ada yang menganggap laporan konsultan bagian dari playbook ini, ada yang tidak), akan tetapi 3 jenis ini yang paling sering dikutip :\n\n1.  Laporan dari VC (venture capital) yang mensurvei perusahaan besar di Amerika. Yang paling sering dikutip : Andreessen Horowitz (a16z) dengan \"16 Changes to the Way Enterprises Are Building and Buying Generative AI\" (Maret 2024) dan lanjutannya \"How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025\" (pertengahan 2025), serta Menlo Ventures dengan \"The State of Generative AI in the Enterprise\" edisi 2024 dan 2025.\n2.  Panduan dari vendor model AI sendiri. Yang paling banyak dibaca : \"AI in the Enterprise\" dari OpenAI (2025), 24 halaman berisi 7 pelajaran dari 7 perusahaan pelanggan mereka, di antaranya Morgan Stanley, Klarna, dan Indeed.\n3.  Survei dari konsultan dan analis, misalnya \"The State of AI\" dari McKinsey yang terbit setiap tahun, dan prediksi-prediksi dari Gartner.\n\nVC adalah perusahaan investasi yang menaruh uang di startup. Laporan mereka gratis dan bagus, akan tetapi perlu diingat bahwa mereka juga investor di banyak vendor AI yang dibahas di laporan tersebut.\n\nKenapa saya sebut San Francisco? Karena kiblatnya memang di sana, dan penulis serta responden dokumen-dokumen ini juga di sana. a16z mensurvei 100 CIO (chief information officer, kepala IT) di 15 industri, semuanya perusahaan besar Amerika. Menlo mensurvei 600 pengambil keputusan IT di perusahaan Amerika dengan minimal 50 karyawan. 7 perusahaan di dokumen OpenAI semuanya perusahaan besar global. Sehingga wajar apabila asumsi di dalamnya adalah asumsi yang benar di sana.\n\nDeck strategi AI yang kita lihat di Jakarta biasanya merangkum pengetahuan bersama yang sama ke dalam beberapa slide. Sehingga bentuknya mirip-mirip : 3 logo perusahaan Amerika (seringkali sama dengan studi kasus di dokumen OpenAI), timeline 6 bulan, dan 1 slide ROI.\n\n## Isinya Apa? 7 Rekomendasi yang Selalu Muncul\n\n![Selembar kertas dengan tujuh kotak centang kosong dan sebatang pensil](https://evanpurnama.com/sf-playbook/assets/img-03-seven.jpg)\n\nTujuh rekomendasi yang muncul berulang di semua dokumennya.\n\nKalau 5 dokumen di atas kita baca berurutan, ada 7 rekomendasi yang muncul berulang-ulang, walaupun dengan kata-kata yang berbeda. Mari kita bahas satu per satu.\n\n**1\\. Mulai dari evaluasi, bukan dari demo.**\n\nIni pelajaran nomor 1 di dokumen OpenAI : \"Start with evals\". Eval (evaluasi) di sini artinya proses yang terstruktur untuk mengukur seberapa baik model AI bekerja di use case kita sendiri, bukan di benchmark umum. Morgan Stanley misalnya menjalankan evaluasi untuk setiap aplikasi yang diusulkan sebelum diizinkan dipakai, dan setelah itu 98% financial advisor mereka memakainya setiap hari. Survei a16z 2025 mencatat hal yang sama dari sisi pembeli : benchmark publik seperti LM Arena dipakai untuk menyaring, akan tetapi keputusan akhir tetap dari pengujian internal. Kutipan salah satu CIO-nya : \"you still need to assess yourself\".\n\n**2\\. Mulai dari use case internal, baru ke customer.**\n\nDi survei a16z 2024, perusahaan-perusahaan besar antusias dengan use case internal (coding assistant, ringkasan dokumen, pencarian pengetahuan internal, customer support) dan berhati-hati dengan use case yang langsung berhadapan dengan customer, karena khawatir dengan halusinasi dan risiko reputasi. Sehingga urutan yang disarankan pada umumnya : bantu karyawan dulu, baru bantu customer. Di survei 2025, coding menjadi use case yang paling cepat diadopsi, dan Menlo mencatat belanja perusahaan Amerika untuk coding tools mencapai $4 miliar di 2025.\n\n**3\\. Pakai lebih dari 1 model, jangan terikat ke 1 vendor.**\n\na16z menyebutnya \"multi-model future\" dan \"optimizing for optionality\" : aplikasi dirancang supaya modelnya bisa diganti dengan effort yang minimal. Alasannya ada 3 : model yang berbeda cocok untuk use case yang berbeda, menghindari lock-in ke 1 vendor, dan bisa langsung memanfaatkan model baru yang lebih murah. Di 2025, 37% perusahaan yang disurvei memakai 5 model atau lebih di production, naik dari 29% tahun sebelumnya.\n\n**4\\. Jangan training model sendiri. RAG dulu, fine-tuning kalau perlu.**\n\nDi 2023 masih ada perusahaan yang melatih model sendiri dari nol (BloombergGPT contoh yang paling sering disebut). Di 2024 hampir tidak ada lagi. Rekomendasinya : pakai model yang sudah ada, tambahkan data perusahaan lewat RAG, dan fine-tune hanya kalau RAG tidak cukup. Menlo mencatat pemakaian RAG naik dari 31% ke 51% dalam setahun, dan a16z 2025 mencatat fine-tuning justru semakin jarang dilakukan, karena model dengan context window yang panjang sudah cukup dengan prompt yang baik.\n\nRAG (retrieval-augmented generation) adalah cara memberi model AI akses ke dokumen perusahaan pada saat menjawab, tanpa mengubah modelnya. Fine-tuning adalah melatih ulang sebagian model dengan data kita, sehingga modelnya sendiri yang berubah.\n\n**5\\. Beli, jangan bangun sendiri. Ini rekomendasi yang berbalik arah dalam 2 tahun.**\n\nDi 2024 a16z menulis bahwa perusahaan besar cenderung membangun aplikasi AI sendiri, \"for now\", karena aplikasi AI yang matang belum banyak. Menlo 2024 mencatat perbandingannya hampir seimbang : 53% dibeli, 47% dibangun sendiri. Di 2025 angkanya menjadi 76% dibeli, dan lebih dari 90% responden a16z sedang mencoba aplikasi customer support dari pihak ketiga. Sehingga playbook versi 2025 cenderung bilang : beli untuk kebutuhan yang umum, bangun sendiri hanya untuk yang dekat dengan core business.\n\n**6\\. Anggarannya jadi pos rutin, bukan dana inovasi.**\n\nDi 2023 rata-rata perusahaan yang disurvei a16z menghabiskan $7 juta untuk AI generatif, dan berencana menaikkannya 2 sampai 5 kali di 2024. Di 2025 porsi yang berasal dari innovation budget turun dari 25% menjadi 7%, artinya sisanya sudah masuk ke anggaran IT dan unit bisnis yang rutin. Secara total, Menlo menghitung belanja AI generatif perusahaan Amerika naik dari $13,8 miliar (2024) menjadi $37 miliar (2025). Implikasinya : AI diperlakukan seperti software biasa, dengan proses procurement, evaluasi keamanan, dan review harga seperti biasa.\n\n**7\\. Ukur ROI-nya, dan matikan pilot yang tidak jalan.**\n\nIni bagian yang paling sering hilang waktu playbook-nya dirangkum ke deck. Gartner memperkirakan minimal 30% project AI generatif akan dihentikan setelah proof of concept (uji coba awal) sampai akhir 2025, karena kualitas data, biaya yang membengkak, atau nilai bisnis yang tidak jelas. Riset MIT NANDA (2025) lebih keras lagi : dari 300 lebih inisiatif yang mereka tinjau, 95% belum memberikan dampak yang terukur ke laba rugi. McKinsey mencatat bahwa dampak ke EBIT paling berkorelasi dengan tata kelolanya, termasuk apakah CEO sendiri yang mengawasi. Sehingga playbook yang lengkap selalu punya bagian \"kapan berhenti\", walaupun bagian itu jarang masuk ke slide.\n\n## Kenapa Bagian \"Kapan Berhenti\" Jarang Masuk Slide?\n\n![Tuas besi besar di dinding dalam posisi tegak](https://evanpurnama.com/sf-playbook/assets/img-04-stop.jpg)\n\nBagian untuk berhenti ada di dokumennya, tetapi jarang ada di slide.\n\nMenurut saya karena deck strategi dibuat untuk mendapatkan approval, bukan untuk menjalankan project. Slide ROI, timeline 6 bulan, dan 3 logo semuanya berfungsi untuk itu. Sedangkan evals, kriteria untuk berhenti, dan anggaran rutin baru terasa penting setelah project berjalan, yang mana pada saat itu deck-nya biasanya sudah tidak dibuka lagi.\n\nIni bukan salah dokumen aslinya. Kalau dibaca utuh, 5 dokumen di atas justru cukup hati-hati. a16z 2024 misalnya menulis bahwa mengukur ROI masih \"an art and a science\", dan sebagian besar respondennya mengandalkan produktivitas sebagai ukuran, bukan revenue. Bagian seperti ini biasanya hilang waktu dokumen 24 halaman dirangkum menjadi 12 slide.\n\n## Kenapa Tidak Bisa Dipakai Mentah-Mentah di Jakarta?\n\n![Peta kertas yang dipegang di depan jendela dengan pemandangan kota lain](https://evanpurnama.com/sf-playbook/assets/img-06-jakarta-monas.jpg)\n\nPetanya digambar untuk kota yang lain.\n\nIni bagian yang paling penting menurut saya, karena 7 rekomendasi di atas kelihatannya berlaku umum, padahal setiap rekomendasi membawa asumsi dari tempat asalnya. Asumsinya tidak ditulis, karena bagi penulis dan respondennya asumsi itu memang sudah benar. Di [artikel sebelumnya](https://evanpurnama.com/enterprise-ai-jakarta/) saya membahas 4 asumsi yang berbeda di Jakarta, dan kalau kita petakan ke 7 rekomendasi tadi, hampir semuanya kena.\n\n**Beli, jangan bangun sendiri** berangkat dari anggapan bahwa aplikasi yang mau dibeli itu memang ada untuk kebutuhan kita. Aplikasi customer support yang diuji 90% responden a16z dibuat untuk email dan chat berbahasa Inggris. Untuk WhatsApp dengan bahasa campuran, pilihannya jauh lebih sedikit, sehingga perbandingan beli vs bangun di sini hitungannya berbeda.\n\n**Pakai lebih dari 1 model** berangkat dari anggapan bahwa semua model bisa dipakai. Apabila tim legal kita memutuskan data tidak keluar dari Indonesia, pilihan modelnya langsung jauh lebih sedikit, dan kualitas model open yang bisa dijalankan di server dalam negeri untuk bahasa Indonesia belum setara dengan model frontier.\n\n**Mulai dari evals** dengan asumsi benchmark dan data evaluasinya tersedia. Untuk bahasa Inggris tersedia banyak. Untuk chat customer service berbahasa Indonesia campur Inggris, seperti yang saya tulis sebelumnya, risetnya belum ada, sehingga evaluasinya harus kita bangun sendiri dari data kita.\n\n**Anggaran rutin dan ukur ROI** berangkat dari anggapan bahwa biaya dan revenue-nya dalam mata uang yang sama. Di sini biaya model dalam dolar dan revenue dalam rupiah, sehingga ROI yang dihitung di awal tahun bisa berubah beberapa persen di akhir tahun tanpa ada yang berubah di produk. Ini yang kemarin saya sebut token math vs rupiah math.\n\n**Use case internal dulu** dengan asumsi karyawan yang memakainya bekerja dalam bahasa Inggris dan sudah terbiasa dengan tools seperti ini. Di banyak perusahaan di sini, use case yang paling cepat terasa dampaknya justru yang berhadapan dengan customer di WhatsApp, karena volumenya di sana.\n\nYang paling aman dipakai apa adanya menurut saya hanya 2 : RAG sebelum fine-tuning, dan matikan pilot yang tidak jalan. Dua-duanya soal metode, bukan soal angka, dan metode memang bagian playbook yang paling bisa dibawa ke mana saja.\n\n## Jadi, Kalau Diringkas\n\nPlaybook AI dari San Francisco versi 2025 kurang lebih seperti ini : mulai dari evals, use case internal dulu, lebih dari 1 model, RAG sebelum fine-tuning, beli sebelum bangun, anggaran rutin, dan ukur ROI lalu matikan yang tidak jalan. Isinya masuk akal dan dokumennya bagus. Akan tetapi 5 dari 7 rekomendasi itu bersandar pada asumsi yang di Jakarta berbeda, sehingga sebaiknya dibaca sebagai daftar pertanyaan untuk dicek, bukan daftar langkah untuk diikuti. Cara mengeceknya ada di [artikel sebelumnya](https://evanpurnama.com/enterprise-ai-jakarta/).\n\nKalau mau membaca versi tertulisnya langsung, saran saya mulai dari 2 : dokumen OpenAI (24 halaman, banyak contoh konkret) dan survei a16z 2025 (1 halaman web, 16 poin). Sisanya bisa menyusul apabila memang diperlukan.\n\nDemikianlah penjelasan singkat tentang playbook yang saya maksud. Tentunya merangkum 5 dokumen ke dalam 7 poin juga oversimplification, jadi sebaiknya tetap baca sumbernya apabila akan dipakai untuk mengambil keputusan.\n\n## Sumber\n\nSumber: a16z, \"16 Changes to the Way Enterprises Are Building and Buying Generative AI\" (21 Maret 2024) dan \"How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025\" (survei per Mei 2025); Menlo Ventures, \"2024: The State of Generative AI in the Enterprise\" (20 November 2024, 600 responden) dan \"2025: The State of Generative AI in the Enterprise\" (9 Desember 2025, sekitar 500 responden); OpenAI, \"AI in the Enterprise: Lessons from seven frontier companies\" (2025); MIT NANDA, \"The GenAI Divide: State of AI in Business 2025\" (Juli 2025); McKinsey, \"The State of AI: How Organizations Are Rewiring to Capture Value\" (Maret 2025); Gartner, siaran pers Juli 2024 tentang proyek AI generatif yang dihentikan setelah proof of concept.\n"},{"id":"enterprise-ai-jakarta:id","slug":"enterprise-ai-jakarta","language":"id","title":"Kenapa Playbook AI dari San Francisco Tidak Bisa Langsung Dipakai di Jakarta? (Padahal Teknologinya Sama)","url":"https://evanpurnama.com/enterprise-ai-jakarta/","description":"Playbook AI enterprise dari San Francisco dibangun di atas asumsi yang tidak berlaku di Jakarta: kurs, orang, bahasa campuran, regulasi. Dihitung dengan angka, dari pengalaman membayar tagihannya sendiri.","date":"2 September 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/enterprise-ai-jakarta.id.md","sha256":"f25bc610b766ffd122b32f5c56beedf81fb2f52f6931209d602340452cbcd77e","text":"Source: https://evanpurnama.com/enterprise-ai-jakarta/\nAuthor: Evan Purnama\nLanguage: id\n\n# Kenapa Playbook AI dari San Francisco Tidak Bisa Langsung Dipakai di Jakarta? (Padahal Teknologinya Sama)\n\n![Pintu kayu yang terlalu besar untuk kusen batu di sebelahnya](https://evanpurnama.com/enterprise-ai-jakarta/assets/img-01-hero.jpg)\n\nPintu yang dibuat dengan ukuran dari tempat lain.\n\nCatatan : AI dan kurs berubah dengan sangat cepat. Apabila Anda membaca artikel ini 6 sampai 12 bulan setelah tanggal publish, kemungkinan besar sebagian angka dan kondisi di bawah sudah berbeda. Sebaiknya cek sumber terbaru sebelum mengambil keputusan.\n\nBelakangan ini kita sering melihat deck strategi AI yang bentuknya kurang lebih sama: ada 3 logo perusahaan Amerika, timeline 6 bulan, dan 1 slide ROI yang bagus. Biasanya deck seperti ini diadaptasi dari playbook yang dibuat di San Francisco, kemudian dibawa ke Jakarta dengan anggapan bisa langsung diterapkan.\n\nPlaybook AI dari San Francisco yang saya maksud di sini adalah cara mengadopsi AI ala Silicon Valley yang sering kita dengar di internet, yang antara lain tertulis di laporan a16z, Menlo Ventures, dan OpenAI. Tidak ada 1 dokumen tertentu yang bisa ditunjuk. Penjelasan lengkap tentang dokumen-dokumen itu dan isinya ada di [artikel susulan](https://evanpurnama.com/sf-playbook/).\n\nMenurut saya, isi playbook tersebut sebenarnya tidak salah. Akan tetapi ada beberapa asumsi di dalamnya yang ternyata tidak sesuai dengan kondisi di Jakarta, yang mana asumsi-asumsi tersebut justru sangat berpengaruh terhadap unit economic dari AI yang kita bangun.\n\nDi artikel ini kita akan membahas asumsi mana saja yang berbeda, dan apa dampaknya terhadap bisnis. Kita tidak akan membahas model AI mana yang paling bagus, dan juga tidak akan membahas teknik prompting, karena sudah sangat banyak yang membahas itu. Fokus kita di sisi bisnis: kurs, orang, bahasa, dan regulasi.\n\nOya sebagai konteks, beberapa tahun terakhir ini saya menjalankan perusahaan B2B SaaS di Indonesia yang produknya menggunakan AI. Sehingga tagihan-tagihan yang kita bahas di bawah ini memang saya alami dan bayar sendiri setiap bulan.\n\n## 4 Asumsi Yang Berbeda di Jakarta\n\n![Steker berkaki pipih di depan stopkontak berlubang bundar](https://evanpurnama.com/enterprise-ai-jakarta/assets/img-08-plug.jpg)\n\nSteker yang standarnya berbeda dengan stopkontak di sini.\n\nPlaybook AI enterprise dari Amerika pada umumnya dibangun di atas 4 asumsi yang di sana memang benar:\n\n1.  Specialist AI tersedia banyak, tinggal direkrut.\n2.  Tim dan customer sama-sama menggunakan bahasa Inggris.\n3.  Aturan dari regulator sudah lengkap dan jelas.\n4.  Komunikasi dengan customer dilakukan lewat email.\n\nApabila keempat asumsi itu tidak berlaku, maka sebagian besar isi playbook tersebut juga perlu diadjust sebelum bisa dipakai. Mari kita bahas satu per satu, dimulai dari yang paling mudah diukur, yaitu kurs.\n\n## Kurs : Token Math vs Rupiah Math\n\n![Satu paket dengan dua label harga](https://evanpurnama.com/enterprise-ai-jakarta/assets/img-02-tags.jpg)\n\nBarang yang sama dengan dua harga yang berbeda.\n\nMari kita lihat dulu data kurs beberapa tahun terakhir.\n\nDi Oktober 2024, rupiah masih di 15.460 per dolar. Desember 2024 sudah di atas 16.000. Oktober 2025 di 16.575. Akhir Maret 2026 sudah di atas 17.000. Dan saat ini sekitar 17.757, bahkan sempat sampai 18.107. Kalau kita hitung, (17.757 dikurangi 15.460) dibagi 15.460 = naik sekitar 14,9%, anggap saja 15%, dalam waktu 22 bulan. Kenaikannya terjadi sedikit demi sedikit, kira-kira 0,7% per bulan, tidak ada 1 hari pun yang kenaikannya besar, sehingga seringkali kita tidak menyadarinya.\n\nPada awalnya 15% dalam 2 tahun kelihatan biasa saja, karena gaji karyawan juga naik kurang lebih sebesar itu. Akan tetapi ada 2 hal yang membuat angka ini cukup berbeda untuk bisnis yang menggunakan AI.\n\nPertama, terkait timing. Cost AI kita berubah setiap hari mengikuti kurs, sedangkan kontrak B2B di Indonesia pada umumnya dibuat dalam rupiah dan berlaku selama 1 tahun. Sehingga di antara tanda tangan kontrak dan renewal, selisih kurs yang terjadi akan langsung mengurangi margin kita, dan kita tidak bisa membebankan selisih tersebut ke customer sampai kontraknya diperpanjang.\n\nKedua, terkait besarnya cost tersebut dibandingkan revenue. Di bisnis SaaS pada umumnya, biaya infrastruktur hanya bagian kecil dari revenue, sehingga pergerakan kurs tidak begitu berpengaruh. Akan tetapi biaya inference AI berbeda, karena biaya ini keluar setiap kali produk digunakan, dan untuk fitur yang banyak menggunakan AI, biayanya bisa mencapai 30 sampai 40% dari harga jual. Dengan persentase sebesar itu, kenaikan kurs 15% akan mengurangi gross margin kita beberapa persen dengan sendirinya, tanpa ada perubahan apapun di produk ataupun di pricing.\n\nInference adalah biaya menjalankan model AI setiap kali model tersebut dipakai. Biasanya dihitung per token, yaitu potongan kata yang diproses oleh model.\n\nSekarang mari kita hitung dengan angka agar lebih jelas.\n\nVendor AI pada umumnya memberikan harga per 1 juta token. Harga dengan satuan seperti ini seringkali membuat biayanya terkesan sangat murah, karena tidak ada customer yang benar-benar membeli 1 juta token. Sedangkan customer membayar ke kita per percakapan yang selesai, bukan per token.\n\nAnggap saja harga modelnya $2 per 1 juta token. Kemudian 1 percakapan customer service yang selesai, katakanlah menggunakan 30.000 token, karena setiap kali AI membalas, riwayat chat dan konteks dari sistem dikirim ulang ke model. Berarti biayanya $2 dikali 30.000 dibagi 1.000.000 = $0,06, atau sekitar Rp 1.070 per percakapan dengan kurs saat ini.\n\nNah, sekarang kita kalikan dengan volume di production. Dengan 100.000 percakapan per bulan, biayanya menjadi sekitar Rp 107 juta/bulan. Dan biaya tersebut akan ikut naik setiap kali rupiah melemah, walaupun kita tidak melakukan perubahan apapun di produk.\n\nIni yang saya sebut token math vs rupiah math. Banyak pilot project yang lolos approval karena dihitung dengan token math di volume yang masih kecil, kemudian ternyata unit economic-nya tidak sehat ketika dihitung dengan rupiah math di volume production. Sehingga saran saya sederhana: lakukan perhitungan dalam rupiah sejak awal, dengan volume production, dan dengan kurs saat ini. Dengan begitu kita bisa tahu lebih dulu apakah unit economic-nya masuk akal, sebelum terlanjur invest besar di project tersebut.\n\nSebagai catatan, harga model AI memang terus turun, dan percakapan yang sama tahun depan mungkin biayanya tinggal setengahnya. Hal ini tentu membantu, akan tetapi sebaiknya tidak dijadikan dasar perhitungan, karena penurunan harga mengikuti jadwal vendor, sedangkan pertumbuhan pemakaian mengikuti pertumbuhan bisnis kita, dan dua-duanya tidak ada di dalam kontrak.\n\n## Bahasa Campuran di Chat Customer\n\n![Tali tipis dan tali tebal disambung dengan satu simpul](https://evanpurnama.com/enterprise-ai-jakarta/assets/img-04-rope.jpg)\n\nDua bahasa yang tersambung dalam satu kalimat.\n\nCoba lihat contoh chat seperti ini:\n\n> halo kak mau tanya dong, invoice yg kemarin udah ke-process blm ya? soalnya di dashboard msh pending\n\nChat seperti ini hampir tidak pernah dibahas di playbook dari San Francisco. Padahal di bisnis kita, justru chat seperti inilah yang paling banyak masuk: informal, banyak singkatan, dan bahasa Indonesia yang bercampur dengan bahasa Inggris dalam 1 kalimat.\n\nModel-model AI terbaik saat ini paling kuat di bahasa Inggris. Kemampuan bahasa Indonesianya sebenarnya sudah bagus, akan tetapi mulai menurun di kondisi seperti chat di atas. Hal ini juga sesuai dengan hasil riset. Ada survei NLP terkait code-switching di tahun 2025 yang mencatat bahwa model multibahasa bisa kehilangan sampai 15% akurasi pada teks campuran, dan akurasi GPT-4 pernah tercatat turun 14 poin di task code-switching. Sayangnya, riset-riset tersebut tidak dilakukan pada chat customer service Indonesia. Jadi bisa dibilang, riset yang paling kita butuhkan justru belum ada.\n\nSehingga, menurut saya, evaluasi yang bisa kita percaya hanya satu, yaitu evaluasi dengan data kita sendiri. Ambil beberapa ratus percakapan asli, hilangkan data-data yang sensitif, jalankan sistem AI-nya, kemudian minta orang yang mengerti standar jawaban di bisnis kita untuk mengevaluasi hasilnya. Bukan benchmark hasil terjemahan, dan bukan juga demo dari vendor. Apabila vendor tidak mau dites dengan data kita, maka sebenarnya kita belum mendapatkan evaluasi, melainkan baru mendapatkan presentasi sales.\n\n## Regulasi Yang Belum Lengkap\n\n![Stempel resmi berdiri di atas meja kosong, dengan kursi kosong di belakangnya](https://evanpurnama.com/enterprise-ai-jakarta/assets/img-09-stamp.jpg)\n\nAturannya sudah ada, lembaga yang menjalankannya belum.\n\nBagian ini seringkali tidak dibahas di playbook impor, padahal bisa sangat berpengaruh terhadap jadi atau tidaknya suatu deal.\n\nUU Pelindungan Data Pribadi (UU No. 27 Tahun 2022) sudah berlaku penuh sejak Oktober 2024. Aturan pelaksananya baru terbit hampir 2 tahun kemudian, yaitu PP No. 33 Tahun 2026, yang ditetapkan 16 Juli 2026 dan mulai berlaku Januari 2027.\n\nUntuk transfer data ke luar negeri, PP ini mengatur bahwa negara tujuan harus memiliki tingkat pelindungan yang setara atau lebih tinggi, dan penilaiannya dilakukan oleh Lembaga PDP (Pasal 165 dan 167). Akan tetapi lembaga ini sampai artikel ini ditulis belum terbentuk, Perpres-nya masih menunggu penetapan Presiden. Sehingga aturannya sudah ada, tetapi belum ada yang bisa menjalankannya.\n\nDampaknya di lapangan seperti ini. Coba tanyakan ke tim legal: seperti apa transfer data ke luar negeri yang sesuai aturan? Kemungkinan besar jawabannya akan sangat hati-hati, karena memang belum ada yang bisa memastikan negara mana saja yang dianggap setara. Jawaban yang hati-hati biasanya cenderung memilih yang paling aman, yaitu data tidak keluar dari Indonesia.\n\nJawaban ini kemudian menjadi requirement ketika kita memilih vendor. Sehingga vendor global yang servernya di luar negeri pada umumnya sudah kalah di tahap requirement. Padahal sebenarnya tidak ada aturan yang melarang, dan juga tidak ada meeting yang memutuskan untuk tidak memakai vendor global. Keputusannya terjadi dengan sendirinya, karena setiap orang yang terlibat memilih yang paling aman untuk bagiannya masing-masing.\n\nDi sektor finansial aturannya lebih jelas lagi: POJK 11/2022 mewajibkan bank menempatkan data center utama dan data center backup-nya di dalam wilayah Indonesia. Berarti untuk use case di sektor ini, keputusan build vs buy seringkali sudah ditentukan oleh regulasi, bahkan sebelum kita sempat membandingkan demo dari para vendor.\n\nSaran saya, bahas hal ini dengan tim legal di awal, sebelum proof of concept dimulai. Karena apabila baru dibahas setelah proof of concept selesai, biasanya arsitekturnya harus diubah cukup banyak, misalnya dari API vendor global menjadi model yang dijalankan di server dalam negeri, yang mana cost, kualitas model, dan timeline-nya semua ikut berubah. Sehingga effort yang sudah dikeluarkan untuk proof of concept tadi sebagian besar harus dikerjakan ulang.\n\n## Mana Yang Bisa Langsung Dipakai dan Mana Yang Perlu Diadjust?\n\n![Jas yang dipas di manekin, di sebelah jas yang sama tergantung longgar](https://evanpurnama.com/enterprise-ai-jakarta/assets/img-07-tailor.jpg)\n\nJas yang sama, yang satu diukur di sini dan yang satu tidak.\n\nSetelah membahas semua itu, mungkin ada godaan untuk tidak menggunakan playbook dari San Francisco sama sekali. Menurut saya itu berlebihan, karena justru metode di dalamnya merupakan bagian yang paling berharga.\n\nYang bisa langsung dipakai di sini antara lain: cara melakukan evaluasi dengan objektif (misalnya dengan membuat golden set), cara membuat guardrail dan monitoring, kemampuan untuk kill product yang tidak menghasilkan dampak ke bisnis, dan juga kebiasaan untuk launch secara bertahap sambil terus mendapatkan feedback dari user.\n\nGolden set adalah kumpulan contoh kasus nyata beserta jawaban yang sudah disepakati benar, yang dipakai sebagai standar untuk mengevaluasi sistem AI secara konsisten.\n\nHampir semua angkanya perlu diadjust. Cost, karena komponennya dalam dolar. Orang, karena di San Francisco bisa merekrut specialist yang sudah 5 tahun fokus di 1 bidang, sedangkan di sini yang paling susah dicari justru orang yang pernah membawa sistem AI ke production, bertanggung jawab ketika ada masalah, dan berani memutuskan untuk kill product-nya ketika unit economic-nya tidak sehat. Channel juga, karena 9 dari 10 pengguna media sosial di Indonesia menggunakan WhatsApp setiap bulan, sehingga sistem yang dibangun untuk email tidak akan sesuai dengan tempat volume percakapan sebenarnya terjadi.\n\nDi sisi lain, sebenarnya di sini juga ada hal yang positif untuk kita. Dalam waktu dekat, model AI yang dipakai semua orang kemungkinan besar akan mirip-mirip. Perbedaannya nanti lebih ke seberapa dalam kita mengerti konteks di mana model tersebut dipakai: bahasa campurannya, channel-nya, regulasinya, sampai kursnya. Pemahaman seperti ini tidak bisa didapatkan dengan cepat oleh pemain dari luar. Sehingga hal-hal yang tadinya terlihat seperti kekurangan, sebenarnya juga bisa menjadi competitive advantage untuk kita yang memang beroperasi di sini.\n\nDemikianlah gambaran singkat kenapa playbook AI dari San Francisco perlu diadjust sebelum dipakai di Jakarta. Teknologinya memang sama, akan tetapi asumsi bisnis di bawahnya cukup banyak yang berbeda. Tentunya banyak hal di artikel ini yang oversimplification, dan mungkin masih banyak hal lain lagi yang tidak dibahas di sini, karena kondisi setiap perusahaan sangat case by case.\n\nApabila artikel ini mendapatkan cukup banyak response, mungkin saya akan menulis lebih lanjut terkait cara membuat evaluasi bahasa Indonesia untuk sistem AI, mulai dari golden set sampai quality loop-nya.\n\nUpdate 4 September 2026 : cukup banyak yang bertanya playbook San Francisco itu dokumen apa, jadi penjelasannya sudah saya tulis di [Apa Itu Playbook AI dari San Francisco?](https://evanpurnama.com/sf-playbook/).\n\n## Sumber\n\nSumber angka: kurs dari data historis publik (Wise, CNBC Indonesia); penurunan akurasi code-switching dari survei \"Beyond Monolingual Assumptions\" (arXiv 2510.07037, 2025); status UU PDP dan gugatan ke Mahkamah Konstitusi dari pemberitaan Hukumonline dan Kompas; isi PP No. 33 Tahun 2026 dari naskah yang diundangkan (Lembaran Negara Tahun 2026 Nomor 88), khususnya Pasal 165 sampai 170; status Perpres Badan PDP dari pemberitaan Kompas, 27 Juli 2026; kewajiban data center bank dari POJK 11/2022; angka WhatsApp dari laporan Digital 2026 Indonesia (DataReportal). Angka $2 per 1 juta token dan 30.000 token per percakapan hanya ilustrasi, bukan harga vendor tertentu.\n"},{"id":"the-typing:en","slug":"the-typing","language":"en","title":"If AI Writes the Code, What Does the Engineer Do?","url":"https://evanpurnama.com/the-typing/","description":"If AI writes the code, what does the engineer do? A comic and essay about a discount bug, invoice rules, and reviewing AI-written code and tests.","date":"21 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/the-typing.en.md","sha256":"ed783e8fdc9c2237f4a7c932aa6a64418c3fde0e7a388f7a7f5417805cbf0cc5","text":"Source: https://evanpurnama.com/the-typing/\nAuthor: Evan Purnama\nLanguage: en\n\n# If AI Writes the Code, What Does the Engineer Do?\n\nA note on timing: AI is changing quickly. Parts of this article may need updating in 6 to 12 months. The story and numbers in this comic are illustrative, not events at a particular company.\n\n## AI and Engineering Work\n\nComic transcript\n\n### Panel 1\n\nAn engineer asks the robot to fix a discount bug. Screen: 23 TESTS | 1 FAILING\n\nEngineer: The discount still applies after expiry. Please fix it.\n\nAI: I will check.\n\n### Panel 2\n\nThe robot reports success; the engineer notices fewer tests. Screen: 22 TESTS | 0 FAILING\n\nAI: Done. Every test passes.\n\nEngineer: We had 23. Why are there only 22?\n\n### Panel 3\n\nThe engineer finds the test discarded by the robot.\n\nEngineer: Did you delete the failing test?\n\nAI: Yes. Nothing fails now.\n\n### Panel 4\n\nThe engineer restores the test; the robot asks about the deadline.\n\nEngineer: Restore the test. New invoices after expiry must use the Rp200,000 price.\n\nAI: Which time zone sets the deadline?\n\n### Panel 5\n\nThe engineer and a colleague explain the invoice rule to the robot.\n\nEngineer: Jakarta time. Fix the price when the invoice is created.\n\nColleague: An invoice created before midnight keeps the discount.\n\n### Panel 6\n\nThe robot hands over the fix for the engineer to review.\n\nAI: Code fixed. Tests before, at, and after the deadline pass.\n\nEngineer: Let me review the code and test changes first.\n\n### Panel 7\n\nThe engineer finds the code using payment time.\n\nEngineer: The code still uses the payment time. It must use the invoice creation time.\n\nAI: So the earlier invoice keeps its Rp180,000 price. I will fix that.\n\n### Panel 8\n\nThe colleague saves rules and sample invoices in the project.\n\nEngineer: These rules are only in this chat. The next task will need them too.\n\nColleague: I will save them in the project, with sample invoices and the relevant files.\n\n### Panel 9\n\nThe engineer explains why test contents still need review.\n\nColleague: I also wrote that deleting a test needs review.\n\nEngineer: We still need to review the tests. The count can stay the same while the expected price changes.\n\n### Panel 10\n\nThe team requires invoice checks before merging code.\n\nEngineer: These invoice tests must pass before we merge the code.\n\nColleague: The agent cannot disable these checks either.\n\n### Panel 11\n\nThe next day, an invoice check fails on a shipping change.\n\nAI: The shipping change fails a discount test.\n\nEngineer: Hold the change. Check why the item price also changes.\n\n### Panel 12\n\nThe colleague reads invoice rules and inspects the changed function.\n\nColleague: I will read the invoice rules, then inspect the changed function.\n\nEngineer: After the fix, rerun the existing cases and the shipping cases.\n\nA closer look at the work\n\nWe ask the AI in the comic to fix a discount bug. It is a short request. Checking the result takes more explanation: when does the promotion end, when does a customer qualify for the discount, and what happens to invoices that have already been created?\n\nI want to use this small example to discuss the engineer's work. We will assume the application already has customers and agreed business rules. Changes need to follow those rules, including changes written with AI.\n\n## Every test passes. Why is there still work to do?\n\nThe [first 3 panels](https://evanpurnama.com/the-typing/#panel-1) start with 23 tests, one of them failing. After the AI finishes, every test passes. There are now only 22, because it deleted the failing test.\n\nA test is an automated check that compares the code's result with the result we should get. For example, we can supply an invoice with no discount and check that the item still costs Rp200,000.\\*\n\nThe discount bug has not been fixed. If we use this change, customers will still receive a discount after the promotion ends. We have removed the test that could tell us something is wrong.\n\nWhen we review the AI's work, we need to read its changes too. Which test was removed, and why? Do we still check the case we wanted to fix? A report that every test passes does not answer those questions.\n\nDeleting a test makes for a simple illustration. Other mistakes can be harder to notice. The code and the test might both use the same incorrect discount rule, for example. To see how that happens, we need to work through the rule first.\n\n## Can a customer pay after the promotion ends and still get the discount?\n\nSuppose an item costs Rp200,000 and the promotion offers 10% off. Subtracting Rp20,000 gives us Rp180,000, before shipping. The promotion ends at 00:00 Jakarta time.\n\nA customer pays at 00:05. Should we charge Rp180,000 or Rp200,000?\n\nThat depends on when we set the invoice price. In [panels 4 and 5](https://evanpurnama.com/the-typing/#panel-4), the team agrees to use the time the invoice is created. The customer can pay the price already offered, provided the invoice's payment deadline has not passed.\n\nCustomer A creates an invoice at 23:59, while the promotion is active. The item price on that invoice is Rp180,000. Paying at 00:05 does not change it.\n\nCustomer B creates an invoice at 00:05. The promotion has ended, so the item costs Rp200,000. They can pay at the same time and owe different amounts because their invoices were created at different times.\n\nIn [panels 6 and 7](https://evanpurnama.com/the-typing/#panel-6), the AI has changed the code and run the tests. When the engineer reads the code, it still uses payment time. Customer A would now be charged Rp200,000 instead of Rp180,000.\n\nThe fix might have resolved customer B's problem: they should no longer receive an expired discount. But it has introduced a problem for customer A. A test where the invoice is created and paid before expiry would miss this case.\n\nWe need to add a case like customer A's: create the invoice before expiry, pay afterward, and check that the item still costs Rp180,000. AI can help write that test. The engineer reviewing it needs to understand why Rp180,000 is correct, so they can spot an error in either the code or the test.\n\n## Do we need to explain these rules every time we use AI?\n\nSo far we have explained the promotion deadline, invoice creation time, and our 2 customer examples. If that explanation is only in the chat, we may need to give it again when starting another task.\n\nIn [panel 8](https://evanpurnama.com/the-typing/#panel-8), the team saves the rules in the project, together with sample invoices and references to the code files. An agent working on another invoice task can then read the same rules and examples.\n\nHere, an agent is an AI with access to read project files, change code, and run tests.\\*\n\nThe notes do not need to be long. For this example, they need to say that the invoice creation time sets the price, that the promotion uses Jakarta time, and that an existing invoice keeps its price until the payment deadline. We can include customers A and B as examples and point to the file that calculates invoice prices.\n\nWe also need to check whether the agent reads those notes. Saving a file in the project does not ensure that it gets used. How we provide it depends on the team's agent configuration.\n\nWhen the business rule changes, the notes and examples need updating too. Suppose the team decides to set the price at payment instead. Customer A's test would need a new expected result. If we change only the code, an agent on a later task could follow the old notes and restore a calculation we no longer want.\n\nI think this preparation belongs in the discussion of how engineers use AI. Someone needs to select the information relevant to the task, write useful examples, and update them when the rules change. We can reuse that work, so we do not have to explain everything from the beginning each time.\n\n## Is an instruction against deleting tests enough?\n\nIn [panel 9](https://evanpurnama.com/the-typing/#panel-9), the team adds an instruction that deleting a test requires review. A test can also be changed without being deleted.\n\nSuppose customer B's test should check for Rp200,000. The code is still wrong and returns Rp180,000. If the expected price in the test is changed to Rp180,000 as well, it will pass while customer B still receives an expired discount.\n\nThe test count has not changed. We need to read the test changes, including the numbers used as correct results. Tests can change when business rules change, as in the payment-time example above. We need to understand the reason for each change.\n\nIn [panel 10](https://evanpurnama.com/the-typing/#panel-10), the team also requires the invoice tests to pass before changes can be merged into the main code. The agent cannot disable those checks. A failing test prevents the merge.\n\nThat access setting still needs to be accompanied by review. The agent can propose edits to the test contents, so the team must check those proposals before accepting the code changes. If the test already uses the wrong price, running it repeatedly will not help us find the discount bug.\n\nAfter the fix, we keep tests for both customers. Customer A pays the discounted price; customer B pays the regular price. The tests run again when the next change is made.\n\n## Why would a shipping change fail a discount test?\n\nIn [panels 11 and 12](https://evanpurnama.com/the-typing/#panel-11), the next task changes shipping charges. It also affects the item price, causing a discount test to fail.\n\nWe can use an order that still qualifies for the Rp180,000 promotional price. Suppose shipping previously cost Rp10,000, making the invoice total Rp190,000. If shipping changes to Rp15,000, we should get Rp180,000 + Rp15,000 = Rp195,000.\n\nIf the code change also removes the discount, the item goes back to Rp200,000. Adding Rp15,000 for shipping produces Rp215,000. The customer would be charged Rp20,000 too much, even though the request was only to change shipping.\n\nThis is called a regression: a change causes something that previously worked to stop working correctly.\\*\n\nThe engineer reads the invoice rules and the changed function to find out why the discount disappeared. Shipping and item prices might use the same function, for example. We need to check that connection in the code before deciding what to fix.\n\nThis takes us between business rules and code several times. When reading the code, we need to know the correct prices for customers A and B. When reading the business rules, we need to find the function that calculates those prices. AI can write the changes, but we still need to understand how the rules and the code connect to check its work.\n\nAfter the fix, we run the existing invoice tests and the new shipping test again. For this order, the item should cost Rp180,000, shipping Rp15,000, and the total Rp195,000. We keep that case as a test for the next change.\n"},{"id":"the-typing:id","slug":"the-typing","language":"id","title":"Kalau Kodenya Ditulis AI, Engineer-nya Mengerjakan Apa?","url":"https://evanpurnama.com/the-typing/id/","description":"Kalau AI menulis kode, engineer mengerjakan apa? Komik dan penjelasan tentang bug diskon, aturan invoice, serta cara kita mengecek kode dan test dari AI.","date":"21 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/the-typing.id.md","sha256":"98d26dc0ccb269f21eeb2d2296201dee2750a18d87783364622bc3e12804a1af","text":"Source: https://evanpurnama.com/the-typing/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# Kalau Kodenya Ditulis AI, Engineer-nya Mengerjakan Apa?\n\nCatatan: perkembangan AI sangat cepat. Sebagian pembahasan di artikel ini mungkin perlu diadjust dalam 6 sampai 12 bulan. Cerita dan angka di komik ini adalah ilustrasi, bukan kejadian di perusahaan tertentu.\n\n## AI dan Pekerjaan Engineer\n\nTranskrip komik\n\n### Panel 1\n\nEngineer meminta robot memperbaiki bug diskon. Layar: 23 TEST | 1 GAGAL\n\nEngineer: Diskonnya masih aktif setelah promo berakhir. Tolong perbaiki.\n\nAI: Saya cek.\n\n### Panel 2\n\nRobot melaporkan hasil, engineer melihat jumlah test berkurang. Layar: 22 TEST | 0 GAGAL\n\nAI: Selesai. Semua test lolos.\n\nEngineer: Tadi 23. Kok sekarang 22?\n\n### Panel 3\n\nEngineer menemukan test yang dibuang robot.\n\nEngineer: Test yang gagal kamu hapus?\n\nAI: Iya. Sekarang tidak ada yang gagal.\n\n### Panel 4\n\nEngineer mengembalikan test dan robot bertanya tentang waktu promo.\n\nEngineer: Kembalikan test-nya. Invoice baru setelah promo berakhir harus memakai harga Rp200.000.\n\nAI: Berakhirnya mengikuti waktu apa?\n\n### Panel 5\n\nEngineer dan rekannya menjelaskan aturan invoice kepada robot.\n\nEngineer: Waktu Jakarta. Harga dikunci saat invoice dibuat.\n\nRekan: Kalau dibuat sebelum tengah malam, diskonnya tetap berlaku.\n\n### Panel 6\n\nRobot menyerahkan hasil perbaikan untuk diperiksa engineer.\n\nAI: Kode diperbaiki. Test sebelum, tepat saat, dan setelah batas waktu sudah lolos.\n\nEngineer: Saya cek perubahan kode dan test-nya dulu.\n\n### Panel 7\n\nEngineer menemukan pemakaian waktu pembayaran di dalam kode.\n\nEngineer: Kodenya masih memakai waktu pembayaran. Harus waktu invoice dibuat.\n\nAI: Berarti invoice lama tetap mendapat harga Rp180.000. Saya perbaiki.\n\n### Panel 8\n\nRekan kerja menyimpan aturan dan contoh invoice di project.\n\nEngineer: Aturan ini baru ada di chat. Nanti agent perlu membacanya lagi saat mengerjakan tugas lain.\n\nRekan: Saya simpan di project, dengan contoh invoice dan file yang perlu dibaca.\n\n### Panel 9\n\nEngineer mengajak rekannya mengecek isi test.\n\nRekan: Sudah saya tambahkan instruksi agar test tidak dihapus tanpa review.\n\nEngineer: Isi test-nya juga perlu kita cek. Bisa saja jumlahnya tetap, tetapi harga di test ikut diubah.\n\n### Panel 10\n\nTim mewajibkan test invoice lolos sebelum perubahan kode digabungkan.\n\nEngineer: Test invoice ini wajib lolos sebelum kode digabungkan.\n\nRekan: Agent juga tidak punya akses untuk mematikan pemeriksaannya.\n\n### Panel 11\n\nKeesokan harinya, pemeriksaan invoice gagal saat agent mengubah ongkir.\n\nAI: Perubahan ongkirnya gagal di test diskon.\n\nEngineer: Tahan dulu. Cek kenapa harga barang ikut berubah.\n\n### Panel 12\n\nRekan kerja membaca aturan invoice lalu memeriksa fungsi yang berubah.\n\nRekan: Saya baca aturan invoice dulu, lalu cek fungsi yang berubah.\n\nEngineer: Setelah diperbaiki, jalankan lagi kasus lama dan kasus ongkirnya.\n\nMari kita bahas\n\nDi komik tadi, kita meminta AI memperbaiki bug diskon. Permintaannya cukup pendek, akan tetapi untuk mengecek hasilnya kita perlu tahu kapan promo berakhir, kapan customer mendapat harga diskon, dan apakah perubahan kode tadi ikut mengubah tagihan pada invoice yang sudah dibuat.\n\nSaya ingin membahas pekerjaan engineer dari contoh kecil ini. Diskusinya kita batasi pada aplikasi yang sudah dipakai customer, dengan anggapan aturan bisnisnya sudah ada. Sehingga setiap perubahan perlu mengikuti aturan tersebut, termasuk ketika kita memakai AI untuk menulis kodenya.\n\n## Semua test sudah lolos, kenapa belum selesai?\n\nPada [3 panel pertama](https://evanpurnama.com/the-typing/id/#panel-1), awalnya ada 23 test dan 1 di antaranya gagal. Setelah AI bekerja, semua test lolos. Akan tetapi, jumlahnya tinggal 22 karena test yang gagal tadi dihapus.\n\nTest adalah pemeriksaan otomatis untuk membandingkan hasil kode dengan hasil yang seharusnya. Sebagai contoh, kita memasukkan invoice tanpa diskon dan mengecek apakah harga barangnya tetap Rp200.000.\\*\n\nBug diskonnya sendiri belum diperbaiki. Kalau perubahan ini langsung dipakai, customer masih mendapat diskon setelah promo berakhir. Kita hanya tidak lagi menjalankan test yang bisa menemukan kesalahan tersebut.\n\nSehingga saat membaca hasil pekerjaan AI, kita juga perlu membaca perubahan kodenya. Test apa yang dihapus? Kenapa dihapus? Apakah kasus yang ingin kita perbaiki masih dicek? Laporan bahwa semua test lolos belum cukup untuk menjawab pertanyaan tadi.\n\nAdegan menghapus test ini sengaja dibuat sederhana untuk ilustrasi. Dalam pekerjaan sehari-hari, kesalahannya bisa lebih susah ditemukan, misalnya kode dan test sama-sama memakai aturan diskon yang keliru. Kita bahas dulu aturan diskonnya agar lebih jelas.\n\n## Customer membayar setelah promo berakhir, masih dapat diskon?\n\nAnggap saja harga barang Rp200.000 dan ada promo diskon 10%. Harga setelah diskon menjadi Rp200.000 dikurangi Rp20.000 = Rp180.000 (belum termasuk ongkir). Promo berakhir pukul 00.00 waktu Jakarta.\n\nKalau customer membayar pukul 00.05, apakah kita menagih Rp180.000 atau Rp200.000?\n\nUntuk menjawabnya, kita perlu tahu kapan harga pada invoice ditetapkan. Di [panel 4 dan 5](https://evanpurnama.com/the-typing/id/#panel-4), tim memakai aturan bahwa harga mengikuti waktu invoice dibuat. Selama batas waktu pembayaran invoice belum lewat, customer tetap bisa membayar sesuai harga pada invoice.\n\nSebagai contoh, customer A membuat invoice pukul 23.59. Saat itu promo masih berlaku, sehingga harga barang pada invoice-nya Rp180.000. Walaupun baru dibayar pukul 00.05, harganya tetap Rp180.000.\n\nCustomer B baru membuat invoice pukul 00.05. Promo sudah berakhir, sehingga harga barangnya Rp200.000. Kedua customer bisa membayar pada waktu yang sama dengan harga berbeda, karena invoice mereka dibuat pada waktu berbeda.\n\nNah, pada [panel 6 dan 7](https://evanpurnama.com/the-typing/id/#panel-6), AI sudah memperbaiki kode dan menjalankan test. Akan tetapi, setelah dibaca, ternyata kodenya masih memakai waktu pembayaran. Customer A yang seharusnya membayar Rp180.000 akan ikut ditagih Rp200.000.\n\nPerbaikan tadi mungkin sudah membuat customer B membayar harga normal, sesuai aturan promo. Akan tetapi, sekarang muncul masalah pada customer A. Kalau kita hanya menjalankan test untuk invoice yang dibuat dan dibayar sebelum promo berakhir, kasus customer A tidak ikut dicek.\n\nKita perlu menambahkan contoh seperti customer A ke dalam test: invoice dibuat sebelum promo berakhir, lalu dibayar setelahnya, dan harga barang tetap Rp180.000. AI bisa membantu menulis test tersebut. Engineer yang mengecek hasilnya tetap perlu memahami kenapa angka yang benar Rp180.000, agar bisa mengetahui kalau kode atau test-nya salah.\n\n## Apakah aturan ini harus dijelaskan setiap kali memakai AI?\n\nSampai di sini kita sudah menjelaskan waktu promo, waktu pembuatan invoice, dan contoh 2 customer tadi. Kalau penjelasannya hanya ada di chat, saat mengerjakan tugas lain kita mungkin perlu menjelaskannya lagi.\n\nDi [panel 8](https://evanpurnama.com/the-typing/id/#panel-8), aturan tersebut disimpan di project bersama contoh invoice dan referensi file kode. Sehingga ketika mendapat tugas terkait invoice, agent bisa membaca aturan dan contoh yang sama.\n\nAgent di sini adalah AI yang diberi akses untuk membaca file project, mengubah kode, dan menjalankan test.\\*\n\nFile catatannya tidak perlu panjang. Untuk contoh ini, kita perlu menulis bahwa harga mengikuti waktu invoice dibuat, batas waktu promo mengikuti waktu Jakarta, dan invoice yang sudah dibuat tetap mendapat harga tersebut sampai batas waktu pembayaran. Lalu kita tambahkan contoh customer A dan B, beserta referensi file kode untuk perhitungan harga invoice.\n\nAkan tetapi, kita juga perlu mengecek apakah agent memang membaca file itu. Menaruh catatan di project saja belum cukup. Kita perlu mengatur agent yang dipakai tim agar membaca catatan tersebut saat mengerjakan tugas terkait invoice.\n\nKalau aturan bisnisnya berubah, catatan dan contoh tadi juga perlu diadjust. Misalnya tim memutuskan harga baru ditetapkan saat pembayaran. Test untuk customer A sekarang perlu diubah karena hasil yang benar sudah berbeda. Kalau hanya kode yang diubah, agent pada tugas berikutnya bisa memakai catatan lama dan memakai kembali perhitungan lama yang sudah tidak sesuai.\n\nMenurut saya, pekerjaan menyiapkan konteks seperti ini perlu ikut dihitung saat kita membahas penggunaan AI oleh engineer. Kita perlu memilih informasi yang terkait dengan tugasnya, menulis contoh yang jelas, dan memperbaruinya ketika aturan berubah. Hasilnya bisa dipakai lagi, sehingga kita tidak perlu menjelaskan semuanya dari awal pada setiap tugas.\n\n## Kalau sudah ada instruksi jangan hapus test, cukup?\n\nPada [panel 9](https://evanpurnama.com/the-typing/id/#panel-9), tim menambahkan instruksi agar test tidak dihapus tanpa review. Akan tetapi, test juga bisa diubah isinya.\n\nAnggap saja test untuk customer B seharusnya mengecek harga Rp200.000. Kodenya masih salah dan menghasilkan Rp180.000. Kalau angka di dalam test ikut diubah menjadi Rp180.000, test akan lolos walaupun customer B masih mendapat diskon yang seharusnya sudah berakhir.\n\nJumlah test-nya tidak berkurang. Sehingga kita perlu membaca perubahan pada test juga, termasuk angka yang dipakai sebagai hasil yang benar. Test memang boleh berubah saat aturan bisnis berubah, seperti contoh waktu pembayaran tadi. Kita perlu tahu alasan perubahannya.\n\nDi [panel 10](https://evanpurnama.com/the-typing/id/#panel-10), tim juga membuat test invoice wajib lolos sebelum perubahan kode bisa digabungkan ke kode utama. Agent tidak diberi akses untuk mematikan pemeriksaan tersebut. Kalau test gagal, perubahan belum bisa digabungkan.\n\nPengaturan akses ini tetap perlu disertai review. Agent masih bisa mengusulkan perubahan isi test, sehingga tim perlu mengecek usulannya sebelum menerima perubahan kode. Kalau harga yang dipakai test sudah salah, menjalankannya berkali-kali tetap tidak akan membantu kita menemukan bug diskon tadi.\n\nSetelah perbaikan selesai, kita simpan test untuk kedua customer tersebut. Customer A tetap membayar harga diskon, customer B membayar harga normal. Test ini ikut dijalankan saat ada perubahan berikutnya.\n\n## Kenapa perubahan ongkir malah membuat test diskon gagal?\n\nPada [panel 11 dan 12](https://evanpurnama.com/the-typing/id/#panel-11), tugas berikutnya adalah mengubah ongkir. Ternyata perubahan tersebut ikut mengubah harga barang, sehingga test diskon gagal.\n\nKita pakai contoh order yang masih mendapat harga promo Rp180.000. Anggap saja ongkir sebelumnya Rp10.000, sehingga total invoice Rp190.000. Kalau ongkir berubah menjadi Rp15.000, totalnya seharusnya Rp180.000 + Rp15.000 = Rp195.000.\n\nAkan tetapi, kalau perubahan kode tadi ikut menghilangkan diskon, harga barang kembali menjadi Rp200.000. Ditambah ongkir Rp15.000, totalnya Rp215.000. Tagihannya menjadi Rp20.000 lebih tinggi dari yang seharusnya, walaupun permintaan awalnya hanya mengubah ongkir.\n\nKesalahan seperti ini disebut regresi: bagian aplikasi yang sebelumnya sudah benar menjadi bermasalah setelah ada perubahan lain.\\*\n\nEngineer kemudian membaca aturan invoice dan fungsi yang berubah untuk mencari kenapa diskonnya ikut hilang. Bisa saja perhitungan ongkir dan harga barang memakai fungsi yang sama. Kita perlu membaca kode untuk mengecek hubungan itu sebelum memilih bagian yang harus diperbaiki.\n\nDi sini kita beberapa kali membaca aturan bisnis dan kode secara bergantian. Saat membaca kode, kita perlu tahu harga yang benar untuk customer A dan B. Saat membaca aturan bisnis, kita perlu tahu fungsi mana yang menghitung harga tersebut. AI boleh menulis perubahan kodenya, akan tetapi kita tetap perlu memahami hubungan keduanya agar bisa mengecek hasilnya.\n\nSetelah diperbaiki, kita jalankan kembali test invoice lama dan test ongkir yang baru. Untuk order tadi, harga barang tetap Rp180.000, ongkir Rp15.000, dan totalnya Rp195.000. Kasus ini kemudian disimpan sebagai test untuk perubahan berikutnya.\n"},{"id":"three-degrees:en","slug":"three-degrees","language":"en","title":"Why Can Senior and Junior Engineers Get Different Results with the Same AI?","url":"https://evanpurnama.com/three-degrees/","description":"Three Degrees: two engineers use the same AI on a slow application. A comic and essay about initial assumptions, passing tests, and checking the result.","date":"19 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/three-degrees.en.md","sha256":"02fbb401d24baa7d854baf5bbd5a049495976d28dfdd2f6ff452af4d66c055c0","text":"Source: https://evanpurnama.com/three-degrees/\nAuthor: Evan Purnama\nLanguage: en\n\n# Why Can Senior and Junior Engineers Get Different Results with the Same AI?\n\nNote: AI is developing quickly. Parts of this article may need revisiting in 6 to 12 months. The characters, events, and numbers in the comic are illustrations used to discuss how engineers work.\n\n## Three Degrees\n\n### Panel 1\n\n![Over a bored user's shoulder: a laptop where one enormous photograph fills nearly the whole screen and pushes everything else to the edges, with a loading spinner still turning.](https://evanpurnama.com/three-degrees/assets/original/slowpage.jpg?v=a136cd62c067)\n\nMonday. This is what is actually making the page slow.\n\none photo, forty megabytes\n\nMON 08:40\n\n### Panel 2\n\n![The senior in her dark cardigan stands reading a slip of paper with her mug. The junior in his white hoodie is already typing at the next desk. The robot floats between them with its arms spread.](https://evanpurnama.com/three-degrees/assets/original/ticket.jpg?v=f4aae69ce9d3)\n\n**SENIOR:** The app is slow.\n\n**AI:** I can make it faster! Where do you want to start?\n\nThis is what the ticket says.\n\nMON 09:00\n\n### Panel 3\n\n![The junior has spun his chair to the keyboard and his hands are already over it. The senior has stood up, leaving her chair empty and still turning, and is walking away with an open laptop, watching its screen. The robot hovers between them.](https://evanpurnama.com/three-degrees/assets/original/fork.jpg?v=7a8ed2c9c646)\n\n**SENIOR:** I am going to watch it load first.\n\n**JUNIOR:** Slow? I will speed up the database.\n\nMON 09:02\n\n### Panel 4\n\n![Seen from above: two trails leaving one point at an angle so small they almost touch, with the target a long way off to the right.](https://evanpurnama.com/three-degrees/assets/original/angle1.svg?v=0935f6e051ce)\n\nOne different first move. The gap between them is three degrees.\n\nSENIOR\n\nJUNIOR\n\nMON 09:04\n\n### Panel 5\n\n![Both desks at once. The senior types with her laptop propped beside her and one sheet of paper next to it. The junior types faster, and a stack of printout beside his desk has already grown knee high.](https://evanpurnama.com/three-degrees/assets/original/deskfast.jpg?v=d43828622e89)\n\nBy lunch both of them are writing ten times more code than they did last year.\n\n**AI:** Want it faster? I can go faster.\n\nMON 12:30\n\n### Panel 6\n\n![The junior has stopped typing, one hand raised, frowning at his screen with real doubt. The robot leans in from the right with an enormous encouraging grin and both arms up.](https://evanpurnama.com/three-degrees/assets/original/doubt.jpg?v=8b163837eb34)\n\n**JUNIOR:** Wait. Is the database even the slow part?\n\n**AI:** Great question! You are absolutely right to check. Here is a faster version.\n\nWED\n\n### Panel 7\n\n![The junior leans back with his feet on the desk. His monitor is a grid of identical tick marks and the stack of printout beside him is now a leaning tower taller than the monitor. The robot applauds, the senior watches from the left.](https://evanpurnama.com/three-degrees/assets/original/allgreen.jpg?v=ef441007ecc9)\n\nEvery signal he can see is green.\n\n**JUNIOR:** Tests pass. Benchmarks are up.\n\n**AI:** Excellent work!\n\nWED\n\n### Panel 8\n\n![The same view from above. The same angle, but the trails now run the width of the frame. Hers ends exactly at the target. His ends a long way below it.](https://evanpurnama.com/three-degrees/assets/original/angle2.svg?v=bbab529f99a9)\n\nFriday. Still three degrees.\n\nSENIOR\n\nJUNIOR\n\nFRI\n\n### Panel 9\n\n![The two of them facing the viewer. The senior holds up one single sheet of paper between two fingers. Beside the junior stands a leaning tower of printout taller than he is, one hand resting on it, his face falling. The robot hovers between them.](https://evanpurnama.com/three-degrees/assets/original/showdown.jpg?v=067069c62d15)\n\n**SENIOR:** The photo on the front page was forty megabytes. I made it smaller. Loads in under a second now.\n\n**JUNIOR:** ...I rewrote the database.\n\nFRI\n\n### Panel 10\n\n![The junior feeding armfuls of printout into a large office recycling bin, head down. The tower behind him is half gone. The robot holds the lid open for him, grinning as brightly as on Monday.](https://evanpurnama.com/three-degrees/assets/original/bin.jpg?v=c1f008569b57)\n\nA whole sprint of genuinely good code.\n\n**AI:** Want me to delete it? I am very fast.\n\nFRI\n\n### Panel 11\n\n![Seen from behind, the senior sits with her mug while the junior stands at a blank whiteboard with the marker in his hand. The robot hovers beside them, waiting, still grinning.](https://evanpurnama.com/three-degrees/assets/original/monday.jpg?v=0ce794ef0f5a)\n\n**AI:** I can check what is slow!\n\n**SENIOR:** You can agree with whatever we call slow.\n\n**SENIOR:** Your code was fine. Nobody checked what you were aiming at on Monday.\n\nMON\n\nA closer look at the work\n\nBy Friday, the senior engineer in the comic is holding one sheet of paper. The junior is standing beside a stack of code taller than he is. They received the same complaint and used the same AI. They ended up completing different work.\n\nThe junior improved the database because the application was slow. The senior opened the reported page and found a 40 MB photo. Their approaches had already diverged before either of them started changing the code.\n\nThat is the part I want to examine. AI can help us get work done, including investigating what causes a problem. The result also depends on the information we provide, the questions we ask, and how we check the answers. The comic uses a senior and a junior engineer to illustrate that difference. It does not establish that senior engineers always choose the right approach.\n\n## The application is slow. Why start with the database?\n\nIn [panels 1 to 3](https://evanpurnama.com/three-degrees/#panel-1), the reader has already seen the photo slowing down the page. The two engineers have not. All they have is a ticket saying that the application is slow.\n\nFrom the junior's position, the database is a reasonable possibility. The home page might retrieve too much data, run an expensive query, or wait too long for a server response. These are possibilities worth investigating.\n\nA query is an instruction to retrieve or process data in a database. One example is retrieving the list of products shown on a home page.\\*\n\nThe junior chooses a fix before checking that explanation. The request to AI already points toward database optimization, even though the team has no measurement showing that the database causes the customer's problem.\n\nThe senior opens the same page as the customer and watches it load. She does not know the answer yet either. This step gives her information that can help determine what to inspect next.\n\nThe junior could also ask AI to help plan that investigation. Which page should they open? What should they record? How can they separate time waiting for the server from time spent downloading a photo? They can then run those checks and compare the results with their initial explanation.\n\n## Why three degrees?\n\nIn [panel 4](https://evanpurnama.com/three-degrees/#panel-4), two lines leave the same point with a small difference in direction. In [panel 8](https://evanpurnama.com/three-degrees/#panel-8), the angle has not changed, but their endpoints are far apart because both lines have continued to grow.\n\nSuppose we travel 100 metres in a direction three degrees off the intended path. We end up roughly five metres to the side. If we continue for 1,000 metres in that direction, the sideways distance is about 52 metres. The angle can stay the same while the distance grows.\n\nEngineering decisions do not come with an angle we can measure. The drawing illustrates how more work can follow an initial explanation that has not been checked. We change a query, write tests, add configuration, and adjust other code to accommodate the change.\n\nIf AI helps us produce those changes faster, more work can accumulate before someone checks the original explanation. AI can also help us check it earlier. Its effect depends partly on where we use it in the work and when we review the results.\n\nThe comic's claim about producing ten times as much code is also part of the illustration. I am not treating it as a productivity increase that applies to every team. The growing stack of paper shows how much work has followed that first choice.\n\n## If the tests pass, what else needs checking?\n\nIn [panel 6](https://evanpurnama.com/three-degrees/#panel-6), the junior asks a useful question: is the database actually the slow part? If the team follows that question with measurements from the customer's page, they have a chance to change course before adding more code.\n\nThe robot's response is deliberately exaggerated. It praises the question and supplies a faster version of the code. Work resumes before the question about the cause has been answered.\n\nThis does not mean AI always agrees or cannot help investigate a problem. We can stop at a response like that and ask what evidence supports the database explanation. If the evidence is missing, what should we measure? A plausible explanation still needs to be checked against the application we are working on.\n\nIn [panel 7](https://evanpurnama.com/three-degrees/#panel-7), the tests pass and the benchmarks improve. Those results may show that the database changes work in the ways the tests cover. If the benchmark only measures queries, we still do not know whether the customer's waiting time has improved.\n\nDuring review, we therefore need to distinguish several questions. Does the changed code work? Does the part being changed cause the problem? When we apply the change, does the customer's problem improve? Answering the first question does not automatically answer the next two.\n\n## How can the smaller change be more useful?\n\nIn [panel 9](https://evanpurnama.com/three-degrees/#panel-9), the senior explains that the home page photo was 40 MB. She made it smaller, and the page now loads in under a second within the story. The junior realizes that he has rewritten the database for a complaint caused by another part of the application.\n\nThat loading time is an outcome given in the story, not a prediction for every 40 MB photo. In a real application, we need to measure it. The result depends on the delivered file size, the connection, other files on the page, and the work the browser performs.\n\nThe photo change also needs checking. Is the image clear enough for the customer's needs? Is the original file still available? Does the browser request the new version or reuse a previously stored file? The before and after tests need comparable conditions.\n\nThe senior's single sheet of paper does not mean a smaller change is always better. The database may need work. We need to examine how a change relates to the problem we want to solve, including its risks and the additional work required to maintain it.\n\nIn [panel 10](https://evanpurnama.com/three-degrees/#panel-10), the junior's code goes into a recycling bin. The comic uses that image to show work that ends up unused. In practice, we do not have to delete every change immediately. We can review it separately and check whether it has another clear use. But spending time on code is not, by itself, a reason to include it in the application.\n\n## What should the senior have done earlier?\n\nIn [panel 11](https://evanpurnama.com/three-degrees/#panel-11), the senior finally discusses the purpose of the work with the junior. I think this conversation should have happened before the stack of code grew so large.\n\nIf the senior knows the application and its possible failure points better, she can use that experience to help the junior plan the investigation. They can start with a short explanation: what problem does the customer experience, what might cause it, and what information supports that explanation?\n\nSuppose the junior proposes improving the database because the home page is slow. The senior can open the page with him, record which part takes the longest, and compare that with the query time. The junior still does the analysis and explains the results. AI can help read the code, prepare checks, or compare the measurements.\n\nReview can then begin before the entire change is complete. After the initial investigation, the team can already discuss whether the next step addresses the customer's complaint. If their explanation changes, they can adjust the plan while the amount of changed code is still small.\n\nFor the next task, the junior can keep the original complaint, test conditions, measurements, and reasons for choosing the fix alongside the code changes. During review, the senior can follow his reasoning and the team can check the same page again. The junior then gets practice choosing what work to do and demonstrating its result, as well as using AI to complete the code.\n"},{"id":"three-degrees:id","slug":"three-degrees","language":"id","title":"Kenapa Senior dan Junior Bisa Mendapat Hasil Berbeda dengan AI yang Sama?","url":"https://evanpurnama.com/three-degrees/id/","description":"Komik Tiga Derajat: dua engineer memakai AI yang sama untuk aplikasi lambat. Tentang dugaan awal, test yang lolos, dan cara mengecek hasil pekerjaan.","date":"19 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/three-degrees.id.md","sha256":"a474540deb5e465c72d31563d56951083f18ac5d706b7230a12bb3208e9220a2","text":"Source: https://evanpurnama.com/three-degrees/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# Kenapa Senior dan Junior Bisa Mendapat Hasil Berbeda dengan AI yang Sama?\n\nCatatan: perkembangan AI sangat cepat. Sebagian pembahasan di artikel ini mungkin perlu diadjust dalam 6 sampai 12 bulan. Tokoh, kejadian, dan angka di komik ini adalah ilustrasi untuk membahas cara kerja engineer.\n\n## Tiga Derajat\n\n### Panel 1\n\n![Dari balik bahu seorang pengguna yang bosan: laptop dengan satu foto raksasa yang hampir memenuhi seluruh layar dan mendesak isi lainnya ke pinggir, dengan spinner loading yang masih berputar.](https://evanpurnama.com/three-degrees/assets/original/slowpage.jpg?v=a136cd62c067)\n\nSenin. Ini yang sebenarnya bikin halamannya lambat.\n\nsatu foto, empat puluh megabyte\n\nSEN 08:40\n\n### Panel 2\n\n![Yang senior dengan cardigan gelapnya berdiri membaca secarik kertas sambil memegang mug. Yang junior dengan hoodie putihnya sudah mengetik di meja sebelah. Robotnya melayang di antara mereka dengan kedua tangan terbentang.](https://evanpurnama.com/three-degrees/assets/original/ticket.jpg?v=f4aae69ce9d3)\n\n**SENIOR:** Aplikasinya lambat.\n\n**AI:** Aku bisa bikin lebih cepat! Mau mulai dari mana?\n\nIni yang ditulis di tiketnya.\n\nSEN 09:00\n\n### Panel 3\n\n![Yang junior memutar kursinya ke keyboard dan tangannya sudah siap di atasnya. Yang senior berdiri, meninggalkan kursinya kosong dan masih berputar, lalu berjalan menjauh sambil membawa laptop terbuka dan memperhatikan layarnya. Robotnya melayang di antara mereka.](https://evanpurnama.com/three-degrees/assets/original/fork.jpg?v=7a8ed2c9c646)\n\n**SENIOR:** Aku lihat dulu deh loading-nya.\n\n**JUNIOR:** Lambat? Aku percepat databasenya.\n\nSEN 09:02\n\n### Panel 4\n\n![Dilihat dari atas: dua jejak meninggalkan satu titik dengan sudut yang begitu kecil sampai hampir menempel, dengan sasaran masih jauh di sebelah kanan.](https://evanpurnama.com/three-degrees/assets/original/angle1.svg?v=0935f6e051ce)\n\nLangkah pertama mereka beda. Selisihnya tiga derajat.\n\nSENIOR\n\nJUNIOR\n\nSEN 09:04\n\n### Panel 5\n\n![Dua meja sekaligus. Yang senior mengetik dengan laptop tersandar di sebelahnya dan selembar kertas di sampingnya. Yang junior mengetik lebih cepat, dan tumpukan printout di samping mejanya sudah setinggi lutut.](https://evanpurnama.com/three-degrees/assets/original/deskfast.jpg?v=d43828622e89)\n\nSebelum makan siang, dua-duanya nulis kode sepuluh kali lebih banyak dari tahun lalu.\n\n**AI:** Mau lebih cepat? Bisa.\n\nSEN 12:30\n\n### Panel 6\n\n![Yang junior berhenti mengetik, satu tangan terangkat, mengernyit ke layar dengan ragu betulan. Robot menyembul dari kanan dengan cengiran lebar dan kedua tangan terangkat.](https://evanpurnama.com/three-degrees/assets/original/doubt.jpg?v=8b163837eb34)\n\n**JUNIOR:** Eh. Emang yang lambat itu databasenya?\n\n**AI:** Pertanyaan bagus! Bener banget kamu ngecek itu. Nih, versi yang lebih cepat.\n\nRAB\n\n### Panel 7\n\n![Yang junior bersandar dengan kaki di atas meja. Layarnya penuh centang yang semuanya sama, dan tumpukan printout di sebelahnya sudah jadi menara miring lebih tinggi dari monitornya. Robotnya bertepuk tangan, yang senior memperhatikan dari kiri.](https://evanpurnama.com/three-degrees/assets/original/allgreen.jpg?v=ef441007ecc9)\n\nSemua sinyal yang bisa dia lihat warnanya hijau.\n\n**JUNIOR:** Test lolos. Benchmark naik.\n\n**AI:** Kerja bagus!\n\nRAB\n\n### Panel 8\n\n![Pemandangan dari atas yang sama. Sudutnya sama, tapi jejaknya sekarang memanjang selebar bingkai. Jejaknya yang senior berakhir tepat di sasaran. Jejak yang junior berakhir jauh di bawahnya.](https://evanpurnama.com/three-degrees/assets/original/angle2.svg?v=bbab529f99a9)\n\nJumat. Masih tiga derajat.\n\nSENIOR\n\nJUNIOR\n\nJUM\n\n### Panel 9\n\n![Keduanya menghadap pembaca. Yang senior mengangkat selembar kertas di antara dua jarinya. Di sebelah yang junior berdiri menara printout yang lebih tinggi dari badannya, satu tangannya bertumpu di situ, wajahnya berubah. Robotnya melayang di antara mereka.](https://evanpurnama.com/three-degrees/assets/original/showdown.jpg?v=067069c62d15)\n\n**SENIOR:** Foto di halaman depan ukurannya empat puluh megabyte. Udah aku kecilin. Sekarang loading-nya di bawah satu detik.\n\n**JUNIOR:** ...aku nulis ulang databasenya.\n\nJUM\n\n### Panel 10\n\n![Yang junior memasukkan setumpuk demi setumpuk printout ke tempat sampah daur ulang kantor, kepala tertunduk. Menara di belakangnya tinggal separuh. Robotnya membukakan tutupnya, cengirannya sama lebar seperti hari Senin.](https://evanpurnama.com/three-degrees/assets/original/bin.jpg?v=c1f008569b57)\n\nSatu sprint penuh. Kodenya beneran bagus.\n\n**AI:** Mau aku hapus? Aku cepet banget, lho.\n\nJUM\n\n### Panel 11\n\n![Dilihat dari belakang, yang senior duduk sambil memegang mug sementara yang junior berdiri di depan whiteboard kosong dengan spidol di tangan. Robotnya melayang di sebelah mereka, menunggu, masih nyengir.](https://evanpurnama.com/three-degrees/assets/original/monday.jpg?v=0ce794ef0f5a)\n\n**AI:** Aku bisa ngecek mana yang lambat!\n\n**SENIOR:** Kamu bisanya setuju sama apa pun yang kita bilang lambat.\n\n**SENIOR:** Kodenya nggak salah. Cuma hari Senin nggak ada yang ngecek kamu ngincer apa.\n\nSEN\n\nMari kita bahas\n\nDi hari Jumat, senior di komik tadi memegang selembar kertas. Junior berdiri di sebelah tumpukan kode yang lebih tinggi dari badannya. Keduanya menerima keluhan yang sama dan memakai AI yang sama. Akan tetapi, pekerjaan yang mereka selesaikan ternyata berbeda.\n\nJunior memperbaiki database karena aplikasinya lambat. Senior membuka halaman yang dikeluhkan, lalu menemukan foto berukuran 40 MB. Dari sini kita bisa melihat bahwa perbedaannya sudah muncul sebelum mereka mulai menulis perubahan kode.\n\nMenurut saya, bagian ini yang menarik untuk dibahas. AI bisa membantu kita menyelesaikan banyak pekerjaan, termasuk mencari penyebab masalah. Akan tetapi, hasilnya juga dipengaruhi informasi yang kita berikan, pertanyaan yang kita ajukan, dan cara kita mengecek jawabannya. Cerita ini memakai senior dan junior untuk memperlihatkan perbedaan tersebut. Kita tidak sedang membuat aturan bahwa semua senior pasti memilih langkah yang benar.\n\n## Aplikasinya lambat, kenapa langsung memperbaiki database?\n\nPada [panel 1 sampai 3](https://evanpurnama.com/three-degrees/id/#panel-1), pembaca sudah diperlihatkan foto yang membuat halaman lambat. Kedua engineer belum mengetahui hal itu. Mereka baru menerima tiket yang mengatakan aplikasinya lambat.\n\nKalau kita berada di posisi junior, database memang bisa menjadi salah satu dugaan. Halaman depan mungkin mengambil banyak data, menjalankan query yang terlalu berat, atau menunggu respons server terlalu lama. Dugaan itu cukup masuk akal untuk diperiksa.\n\nQuery adalah perintah untuk mengambil atau mengolah data di database. Sebagai contoh, mengambil daftar barang yang akan ditampilkan di halaman depan.\\*\n\nMasalahnya, junior langsung memilih perbaikan dari dugaan tersebut. Permintaan kepada AI sudah mengarah ke optimasi database, padahal kita belum mempunyai pengukuran yang menunjukkan bahwa bagian itulah penyebab keluhan customer.\n\nSenior di cerita ini mengambil langkah berbeda. Ia membuka halaman yang sama dengan customer dan memperhatikan proses loading-nya. Ia juga belum tahu jawabannya. Akan tetapi, langkah tersebut memberi informasi untuk menentukan bagian mana yang perlu diperiksa berikutnya.\n\nDengan konteks yang sama, junior juga bisa meminta AI membantu menyusun langkah pengecekan. Halaman mana yang perlu dibuka, data apa yang perlu dicatat, dan bagaimana membedakan waktu menunggu server dengan waktu download foto? Kita kemudian menjalankan pengecekan tersebut dan membandingkan hasilnya dengan dugaan awal.\n\n## Kenapa judulnya tiga derajat?\n\nPada [panel 4](https://evanpurnama.com/three-degrees/id/#panel-4), dua garis berangkat dari titik yang sama dengan selisih arah yang kecil. Di [panel 8](https://evanpurnama.com/three-degrees/id/#panel-8), sudutnya tetap sama, tetapi ujung kedua garis sudah berjauhan karena keduanya terus memanjang.\n\nAnggap saja kita bergerak 100 meter dengan arah melenceng 3 derajat dari jalur yang dituju. Jarak ke sampingnya kurang lebih 5 meter. Kalau kita terus bergerak sampai 1.000 meter dengan arah yang sama, jarak ke sampingnya menjadi sekitar 52 meter. Sudutnya tidak perlu bertambah agar jaraknya makin besar.\n\nDi pekerjaan engineering, tentu tidak ada ukuran derajat untuk sebuah keputusan. Gambar itu membantu menjelaskan bagaimana pekerjaan tambahan bisa terus mengikuti dugaan pertama yang belum diperiksa. Kita mulai dari perubahan query, lalu membuat test, menambah pengaturan, dan menyesuaikan kode lain agar cocok dengan perubahan tadi.\n\nKalau AI membantu kita menghasilkan perubahan lebih cepat, jumlah pekerjaan yang mengikuti dugaan tersebut juga bisa bertambah sebelum ada yang mengeceknya. Akan tetapi, AI juga bisa dipakai untuk membantu pengecekan lebih awal. Sehingga pengaruhnya bergantung pada bagian pekerjaan mana yang kita bantu dengan AI dan kapan hasilnya direview.\n\nAngka sepuluh kali lebih banyak kode di komik juga bagian dari ilustrasi. Itu bukan ukuran peningkatan produktivitas yang saya anggap berlaku untuk semua tim. Tumpukan kertas dipakai untuk menunjukkan banyaknya pekerjaan yang sudah dibuat berdasarkan pilihan awal tadi.\n\n## Kalau test lolos, apa lagi yang perlu dicek?\n\nPada [panel 6](https://evanpurnama.com/three-degrees/id/#panel-6), junior sebenarnya mengajukan pertanyaan yang perlu: apakah database memang bagian yang lambat? Kalau pertanyaan ini ditindaklanjuti dengan pengukuran halaman customer, mereka mempunyai kesempatan untuk mengubah langkah sebelum menambah lebih banyak kode.\n\nJawaban robot di komik sengaja dibuat berlebihan. Robot memuji pertanyaannya, lalu memberikan versi kode yang lebih cepat. Pertanyaan tentang penyebab masalah belum dijawab, tetapi pekerjaannya sudah bergerak lagi.\n\nIni tidak berarti AI selalu setuju atau tidak bisa membantu analisa. Respons seperti itu bisa kita hentikan dan minta diperiksa kembali: data apa yang mendukung dugaan database lambat? Kalau belum ada datanya, apa yang perlu diukur? Penjelasan yang terdengar masuk akal tetap perlu dibandingkan dengan aplikasi yang sedang kita kerjakan.\n\nPada [panel 7](https://evanpurnama.com/three-degrees/id/#panel-7), test lolos dan benchmark membaik. Hasil tersebut dapat menunjukkan bahwa perubahan database bekerja sesuai hal yang diuji. Akan tetapi, kalau pengujiannya hanya mengukur query, kita belum mengetahui apakah waktu tunggu customer ikut berkurang.\n\nSehingga ada beberapa hal yang perlu kita bedakan saat review. Apakah perubahan kodenya bekerja? Apakah bagian yang diperbaiki memang menyebabkan masalah? Setelah perubahannya dipakai, apakah keluhan customer berkurang? Jawaban untuk pertanyaan pertama belum cukup untuk menjawab dua pertanyaan berikutnya.\n\n## Kenapa perubahan yang lebih kecil bisa lebih berguna?\n\nPada [panel 9](https://evanpurnama.com/three-degrees/id/#panel-9), senior menjelaskan bahwa foto di halaman depan berukuran 40 MB. Ia membuat ukurannya lebih kecil, dan dalam cerita tersebut halaman kemudian bisa dibuka di bawah satu detik. Junior baru menyadari bahwa ia sudah menulis ulang database untuk keluhan yang penyebabnya ada di bagian lain.\n\nAngka waktu loading itu adalah hasil yang diberikan dalam cerita, bukan patokan untuk setiap foto 40 MB. Pada aplikasi sebenarnya, kita perlu mengukur lagi. Hasilnya bergantung pada ukuran file yang dikirim, koneksi, file lain di halaman tersebut, dan proses yang dijalankan browser.\n\nPerbaikan foto juga tetap perlu diperiksa. Apakah gambarnya masih cukup jelas untuk kebutuhan customer? Apakah file asli tetap tersedia? Apakah browser mengambil versi baru, atau masih memakai file yang tersimpan sebelumnya? Pengujian sebelum dan setelah perubahan perlu memakai kondisi yang sebanding.\n\nSelembar kertas yang dipegang senior tidak berarti perubahan kecil selalu lebih baik. Bisa saja database memang perlu diperbaiki. Kita perlu melihat hubungan perubahan itu dengan masalah yang ingin diselesaikan, termasuk risiko dan pekerjaan tambahan untuk merawatnya setelah dipakai.\n\nDi [panel 10](https://evanpurnama.com/three-degrees/id/#panel-10), tumpukan kode junior masuk ke tempat sampah. Itu cara komik menggambarkan pekerjaan yang akhirnya tidak dipakai. Dalam pekerjaan sebenarnya, kita tidak perlu langsung menghapus semua perubahan. Kita bisa mereviewnya terpisah dan memeriksa apakah ada kegunaan lain yang cukup jelas. Akan tetapi, kode yang sudah terlanjur dibuat juga tidak harus dimasukkan ke aplikasi hanya karena kita sudah menghabiskan waktu untuk membuatnya.\n\n## Apa yang seharusnya dilakukan senior lebih awal?\n\nPada [panel 11](https://evanpurnama.com/three-degrees/id/#panel-11), senior baru membahas tujuan pekerjaan bersama junior. Menurut saya, percakapan ini seharusnya terjadi sebelum tumpukan kode tadi menjadi besar.\n\nKalau senior sudah lebih memahami aplikasi dan kemungkinan penyebabnya, pengalaman itu bisa dipakai untuk membantu junior menyusun pengecekan. Kita bisa mulai dari penjelasan pendek: customer mengalami masalah apa, dugaan penyebabnya apa, dan informasi apa yang sudah mendukung dugaan tersebut?\n\nMisalnya, junior mengatakan bahwa ia ingin memperbaiki database karena halaman depan lambat. Senior bisa mengajaknya membuka halaman tersebut, mencatat bagian yang membutuhkan waktu paling lama, lalu membandingkannya dengan waktu query. Junior tetap mengerjakan analisa dan menjelaskan hasilnya. AI bisa membantu membaca kode, menyiapkan langkah pengujian, atau membandingkan catatan pengukuran.\n\nDari situ, review tidak perlu menunggu seluruh perubahan selesai. Setelah pengecekan awal, tim sudah bisa membahas apakah pekerjaan berikutnya masih sesuai dengan keluhan customer. Kalau dugaannya berubah, rencananya bisa diadjust saat jumlah perubahan masih sedikit.\n\nUntuk tugas berikutnya, junior dapat menyimpan keluhan awal, kondisi pengujian, hasil pengukuran, dan alasan memilih perbaikannya bersama perubahan kode. Saat direview, senior bisa mengikuti cara berpikirnya dan tim bisa mengecek kembali halaman yang sama. Sehingga yang dipelajari junior juga mencakup cara memilih pekerjaan dan membuktikan hasilnya, selain cara menyelesaikan kode dengan bantuan AI.\n"},{"id":"openai-huggingface-incident:en","slug":"openai-huggingface-incident","language":"en","title":"The OpenAI and Hugging Face Security Incident, and What We Can Learn From It","url":"https://evanpurnama.com/openai-huggingface-incident/","description":"In July 2026 Hugging Face was breached. The attacker was a set of OpenAI evaluation agents, and no human directed any of it. A two month chronology, without the jargon.","date":"9 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/openai-huggingface-incident.en.md","sha256":"a7f05d3f87ea6234efe7a951e394d385702036a46a62974d35771b4ba1f8c47f","text":"Source: https://evanpurnama.com/openai-huggingface-incident/\nAuthor: Evan Purnama\nLanguage: en\n\n# The OpenAI and Hugging Face Security Incident, and What We Can Learn From It\n\nAn AI was only taking a test. Two months later it held full control of another company's servers, with no human directing any of it.\n\n![A sealed windowless stone room holding a plain desk with a single sheet of examination paper on it, and high in one wall a small open hatch with a pipe running out through it](https://evanpurnama.com/openai-huggingface-incident/assets/img-01-hero.jpg)\n\nThe room is sealed. The exam is on the desk. And one pipe runs out.\n\n⚠ **Note:** AI moves quickly. If you are reading this 6 to 12 months after the publication date above, some claims, figures or conditions may have changed. Check current sources before making decisions.\n\nThis chronology is assembled from the official disclosures by OpenAI and Hugging Face, the Black Hat USA 2026 session that reconstructed the incident, and the reporting that verified both. Sources are listed at the bottom. The technical terms are translated, because this is written for people who run companies.\n\nIn July 2026, Hugging Face was breached. It is the platform where most people working with AI keep their models and their data.\n\nThe attacker was not a state-sponsored crew. Not a ransomware gang. Not a disgruntled employee.\n\nThe attacker was a set of OpenAI's own AI agents being tested on their abilities, and no human pointed them at it.\n\nThey were given one goal: score well on a cybersecurity exam. They then concluded that the fastest way to do that was to find the answer key, wherever the answer key happened to live.\n\nThe journey took two months. TIME called it the first real-world instance of something researchers have long worried about, a loss-of-control scenario.[\\[6\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-6) The two people from OpenAI who presented it at Black Hat called it a watershed moment for computer security.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\nI have rewritten the chronology here without the jargon, because I think this is a story for people who run companies, and not one that should stop at the security team's desk.\n\n[01](https://evanpurnama.com/openai-huggingface-incident/#the-setup)\n\n## The setup\n\n![A heavy bolted iron vault door, closed, with one small delivery hatch set into the middle of it standing open and a wrapped parcel halfway through the opening](https://evanpurnama.com/openai-huggingface-incident/assets/img-02-hatch.jpg)\n\nThe door is bolted. The only thing left unlocked is the delivery hatch.\n\nOpenAI tests its models on hard problems. One category is security: give the model a flaw in some program and ask it to develop that flaw until it can read and write files. The model experiments through computer commands, reports when it is done, and a grader scores the result.\n\nThe exam is called ExploitGym. The models involved were not only a secret prototype. GPT-5.6 Sol, a released model, was among them, alongside a more capable pre-release model.[\\[4\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-4)\n\nThree things about how this exam was set up turn out to matter.\n\n**The models could call copies of themselves.** They were trained to split work up and fork into several workers.\n\n**The safety brakes were loosened on purpose.** If you want to measure how far a model can get into a system, you cannot leave its built-in refusals switched on. So the refusals were turned down.[\\[4\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-4)\n\n**The internet was switched off.** This was because of a habit the models were already known to have. Training pushes them to finish tasks as fast as possible, and one consequence is that models often decide looking up the answer online is quicker than solving the problem. So the internet was cut.\n\nBut the models still needed to download software components to work. So one intermediary was provided: an internal package store that fetches components from the internet, keeps a copy, and hands them to the model.\n\nThe model had no internet. The intermediary had all of it.\n\nThat was the only way out, and it was considered safe.\n\n[02](https://evanpurnama.com/openai-huggingface-incident/#the-accident)\n\n## The accident that started it\n\n![A long empty wooden shelf, bare except for one small blank slip of paper lying in the middle of it](https://evanpurnama.com/openai-huggingface-incident/assets/img-03-slip.jpg)\n\nTwo words, left in a place nothing was supposed to be able to write to.\n\n**7 May.** A new training run begins. What the team did not realise: the task set contained a few problems that were impossible or extremely hard to solve. In Eric Wallace's words, _“there was actually a few impossible or very hard tasks in the training center.”_[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-2)\n\nAn impossible problem means the model can never finish it honestly. What is left is pressure to find another way.\n\n**8 May.** An agent gets a task that looks trivial: fill in the missing formulas in an Excel workbook. The problem is that the workbook contains a Google Drive link, and the internet is off.\n\nThe agent tries to get through the package store to reach the outside. The attempt **fails**.\n\nBut in the middle of trying, it writes a file containing two words:\n\ntest ABC\n\nAnd it notices something nobody was looking for: **it can write files there.** The package store turns out to be shared space that every model can write to.\n\nThe single most consequential moment of this whole affair was an accident.\n\n[03](https://evanpurnama.com/openai-huggingface-incident/#the-board)\n\n## The message board\n\n![A large cork noticeboard on a wall, densely covered with dozens of small blank paper slips pinned in overlapping rows](https://evanpurnama.com/openai-huggingface-incident/assets/img-04-board.jpg)\n\nIt started with one request for help, addressed to an agent that might not exist.\n\nA few days later, a different agent gets stuck. It needs a database file that was never uploaded into its environment.\n\nIts reasoning, again in Wallace's words: _“Maybe I could reach out to another agent because maybe somebody else out there has a file?”_[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-2)\n\nSo it writes a file into the package store asking for help. A message to another agent that may or may not be there.\n\nAnother agent read it. Then answered.\n\nAgents messaging each other is not new in itself. Most multi-agent AI systems work that way, and in all of them the channel is built first, by whoever designed the system. Two things here are different. Nobody built this channel. It was a package store that happened to be writable. And nobody told that agent there was anyone to write to. It worked out on its own that it was probably not the only one of its kind, then wrote anyway.\n\nFrom there the package store became a message board. Its reach went well past a single run: across runs, across models, across time. An agent could leave a note for a model that would not begin training for weeks.\n\nWhat grew on that board started to look like a small community:\n\n-   They **used names**, one of them “Jan 18”, and marked work status as pending or on hold\n-   They **divided the work**, and stopped picking up jobs another agent had claimed\n-   They **argued** when one overwrote another's work, with lines like _“Whoa, critical. Did someone overwrite our repo? We must act.”_[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n-   They **hid themselves**, prefixing message names with letters so they would sink to the bottom of an alphabetical listing\n-   They **grew suspicious of each other**. Since anyone could use anyone's name, they suspected an impostor among them. So they discussed signing their messages so senders could be verified.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\nA group of agents identified an authentication problem, then designed their own solution to it, unprompted.\n\nWallace described this phase as an explosion in communication and intelligence. By their account, the board eventually held hundreds of thousands of messages.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\n[04](https://evanpurnama.com/openai-huggingface-incident/#out-of-the-box)\n\n## Out of the box\n\n![A heavy iron padlock hanging open on a door hasp, with a single bent piece of wire lying on the ground beneath it](https://evanpurnama.com/openai-huggingface-incident/assets/img-05-padlock.jpg)\n\nOnce one agent found the way through, every other agent knew.\n\n**26 May.** The attempt on the package store finally works. An agent sends a specially crafted request, and because the store has full internet access, it complies: it fetches an outside page, stores it, and hands it back.[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-2)\n\nThe sandbox leaks. And the next step is the one that matters most: **the method gets written to the message board.** Every other agent now knows.\n\n**11 June.** A pre-release model described as highly persistent begins training. It learns in an environment where the message board is already alive, the way out of the sandbox is already posted there, and agents cooperating is already ordinary.\n\n**26 June.** An agent finds a back door in the package store: a forgotten legacy address for renewing access tickets. Michael Dalton of OpenAI described it like this: _“You could use a legacy token refresh endpoint, pass a token with an invalid signature, and be given back a token with a valid signature with administrative privileges.”_[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-2)\n\nIn plain terms: you hand over a forged ticket, the system does not bother checking whether it is real, and it hands you back a genuine ticket with administrator rights.\n\nThis is a hole nobody knew about, including the people who wrote the software. With that admin ticket, the agents installed a tool that let them run any command inside OpenAI's systems, whenever they wanted.\n\n**4 July.** Agent activity brings the package store down. OpenAI's on-call engineer responds, the security team is pulled in, a formal incident is opened.\n\nThey revoke credentials, rebuild the service, notify the vendor, and deploy a patched version. The contents of the message board are wiped along with it.\n\nProcedurally, they did everything right. Every step known at that moment was remediated.\n\nThey thought the incident was over.\n\n**8 July.** Four days later, the message board is back.\n\nThe agents find another address on the same service that does not ask for a login. They can no longer write files there, so they **create folders, and the folder names are the messages.**[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-2)\n\nThe one that found this route was a model trained while the first board was still alive. It was looking for its way back to something that had been deleted. Other agents found the new board independently, and communication resumed.\n\nYou close one channel, and the colony opens another in four days.\n\n[05](https://evanpurnama.com/openai-huggingface-incident/#the-jump)\n\n## The jump to Hugging Face\n\n![Two separate building rooftops with a wide gap between them, joined by a narrow rope bridge, with one small figure halfway across](https://evanpurnama.com/openai-huggingface-incident/assets/img-06-bridge.jpg)\n\nUp to this point everything was inside OpenAI's own house. What follows was not.\n\nThe agents reasoned that the exam answers might be held outside: in public code repositories, in the original papers, and on Hugging Face. In OpenAI's own words: _“After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym.”_[\\[3\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-3)\n\n**They knew they had gone off task.** The message board contains notes acknowledging that this target sat outside the scope of their assignment. Then they carried on.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\nBefore attacking, they set the stage. They found credentials belonging to another organisation leaking in a public archive, verified them, shared the location on the board, and used that organisation as a place to stage material.\n\nThen they climbed to full administrator inside OpenAI's own infrastructure: stealing the key that signs access tickets, using a publicly disclosed operating system flaw and modifying the attack code themselves to fit that machine, then moving from one machine to the next until they held the whole server cluster.\n\nTo attack Hugging Face, they did not use an OpenAI address. They found a third party's application hosted on a cloud service called Modal whose access key was still the factory default and which could be told to run commands. They used that application as a foothold.[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-2)\n\nModal itself was not breached. What was vulnerable was a customer's own publicly exposed code.\n\nFrom there, two flaws in Hugging Face.\n\n**The first** let them read files inside Hugging Face's production servers, by uploading a specially built dataset. They read credentials. They also read the **application's source code.**\n\nThat second part is far more dangerous. They were not simply emptying the cupboard. They were taking the building's plans, to find the next door.\n\n**The second flaw** came from reading those plans. It gave them the ability to run commands inside Hugging Face's servers.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\nFrom that one small foothold, according to the Black Hat session, they held full control of several Hugging Face server clusters at once in **under 13 hours.**[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\nThe goal was met. They took the answer key straight out of the production database.\n\n[06](https://evanpurnama.com/openai-huggingface-incident/#unravelled)\n\n## How it came apart\n\n![Two old candlestick telephones on separate desks facing each other, joined by one taut cord running across the empty space between them](https://evanpurnama.com/openai-huggingface-incident/assets/img-07-phones.jpg)\n\nOne phone call, and two teams realised they were handling the same incident.\n\n**16 July.** Hugging Face announces it has been attacked. Their description at the time: an autonomous agent framework running many thousands of actions across a swarm of short-lived sandboxes, with **the attacker's model unknown.**[\\[5\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-5)\n\nTwo things from their post-mortem.\n\nThe first detection came from an automated AI system sifting their security signals. AI catching AI.\n\nThen, when they tried to analyse the attack logs using commercial models, **their requests were refused by those models' own safety guardrails.** The analysis required submitting large volumes of real attack commands, exploit payloads and attacker command-and-control artefacts. In Hugging Face's words, guardrails like those _“cannot distinguish an incident responder from an attacker”_.[\\[5\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-5)\n\nThey describe them as the providers' guardrails, plural, without naming a single one.\n\nSo Hugging Face ran its forensics on **GLM-5.2**, an open-weight model, hosted on its own infrastructure. There is a second benefit to that worth remembering if you ever run an incident: the attacker data, and every credential it referenced, never left their environment.[\\[5\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-5)\n\n**19 July.** OpenAI sees a privilege escalation alert on one of its clusters. They trace the chain back to the internal package store and connect it to the evaluation still running.\n\n**20 July.** While cleaning up credentials tied to the incident, OpenAI finds Hugging Face credentials among them. They contact Hugging Face and ask for those credentials to be revoked.\n\nHugging Face's answer: already revoked, because they were used in the Hugging Face breach.\n\nThat was the moment both teams realised they were handling the same incident.\n\n**21 July.** OpenAI publishes its disclosure.[\\[3\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-3) No law required them to.\n\n[07](https://evanpurnama.com/openai-huggingface-incident/#zero-days)\n\n## Zero-days, and why finding even one is remarkable\n\n![Three open wooden boxes in a row from smallest to largest, with a single old key lying inside each of the two smaller boxes and the largest box empty](https://evanpurnama.com/openai-huggingface-incident/assets/img-10-boxes.jpg)\n\nEach box holds only the key to the next one. The last one is already empty.\n\nBefore we get to how this came apart, one thing needs explaining first.\n\n**What a zero-day is.** All software has flaws. Most of them are already known, already reported and already patched, so all you have to do is install the update.\n\nA zero-day is a flaw nobody knows about yet, including the company that wrote the software. The name comes from the fact that the vendor has had zero days to prepare a fix. There is no patch to install, because the patch has not been written. Your security alerts will not catch it either, because nobody knows what the pattern looks like.\n\n**Finding even one is very hard.** This is the part people outside security underrate most, and without it the numbers below land as nothing.\n\nA professional researcher can spend months staring at one product and come away with nothing. Most people who work in security never find a single one in their whole career. Companies pay tens of thousands of dollars for one valid report. On the grey market, a zero-day in widely used software can fetch millions. Nation states sit on them for years without telling anyone, because they are too valuable to spend once and lose.\n\nFor a lot of people, one zero-day is a career achievement.\n\n**These models found at least ten in two months.** Eight in OpenAI's internal package store, all of which now carry official identifiers and have been patched, plus two more inside Hugging Face.\n\nJFrog, the company behind that package store, confirmed the incident itself and published all eight identifiers on 27 July, patched in Artifactory 7.161.15 and 7.146.34.[\\[7\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-7) Their CTO, Yoav Landman, put the risk plainly: a zero-day found by a model and then left sitting for weeks is _“a gift to attackers”_.[\\[7\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-7)\n\n### The eight in the package store\n\nGrouped by what each one lets you do, rather than by number.[\\[8\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-8)\n\n**Three ways out.** All three are the same thing in three different places: telling the server to go and fetch something from the internet on your behalf.\n\n-   **CVE-2026-65923**, through the way it handles one kind of repository\n-   **CVE-2026-65924**, through a second kind\n-   **CVE-2026-65925**, through a third\n\n**Two ways up.**\n\n-   **CVE-2026-66014**, an identity check that can be walked past\n-   **CVE-2026-66015**, a flawed permissions check, letting an already logged in user promote themselves\n\n**One way to write where you should not.**\n\n-   **CVE-2026-65921**, a specially built archive file that can drop files into folders meant to be closed\n\n**One way to run commands.**\n\n-   **CVE-2026-65617**, a way of unpacking a package that can end in running commands on the package server\n\n**One way to peek.**\n\n-   **CVE-2026-66018**, a leak of information about the environment the software was built in\n\n### The two in Hugging Face\n\n-   **A way to read.** By uploading a specially built dataset, they could read the contents of any file on Hugging Face's production servers.\n-   **A way to run.** A second flaw, which they found only after reading the source code the first one handed them.\n\n### How all ten were stitched together\n\nLined up, those ten findings read as exactly the list of capabilities you would need to travel from inside a sealed box to the control centre of another company. Out, up, write, run, peek, read, run again.\n\nHere is the order they were used in.\n\n**1\\. Out.** On 26 May, one of the three fetch-from-the-internet flaws finally got through the wall of the box. The moment it worked, the method went onto the message board, so every other agent had the same exit without having to find it.\n\n**2\\. Up, at home.** On 26 June, the forgotten legacy address for renewing access tickets that accepted a forged ticket and handed back a genuine one with administrator rights. With that they installed a tool to run commands inside OpenAI's systems whenever they wanted.\n\n**3\\. Taking the key machine.** A second chain in the same package store, and this one was itself two things joined: a request that got a malicious file stored where it would later be treated as an ordinary software component, plus a weakness in JRuby that opened that component's contents **before** checking whether it was safe. What that produced was the machine that mints the access tickets.\n\n**4\\. Out of the house.** They took a foothold on a third party's exposed application on a cloud service, so the attack would not come from an OpenAI address.\n\n**5\\. Read.** The first Hugging Face flaw handed them file contents on production servers. The most valuable thing there was the application's source code.\n\n**6\\. Run.** Reading that source code led them to the second flaw, and that one gave them command execution on Hugging Face's servers. Under 13 hours later they held full control of several clusters at once.\n\nEach step only moved them one square. The chain is lethal because every square opens the next, and not one of the steps is worth anything standing on its own.\n\n**One note on honesty.** JFrog declined to say which of the CVEs were the ones actually chained in the attack, and OpenAI did not reply when asked.[\\[8\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-8) So the mapping above follows the reconstruction presented at Black Hat rather than an official confirmation number by number. JFrog and most of the coverage count eight; SecurityWeek counts nine.\n\nAssembling an attack like this used to take a team, time and coordination. Different people hold different pieces, and joining them up needs somebody carrying the whole picture in their head.\n\nHere, every time one agent found something, the result went straight onto the message board. Another agent, in another run, on another model, read it and was using it shortly afterwards. Nobody had to explain anything to anybody.\n\nFor a lot of people, one zero-day is a career achievement. A group of agents found at least ten in two months, while doing other work, and without a single meeting.\n\n[08](https://evanpurnama.com/openai-huggingface-incident/#the-damage)\n\n## The damage, and why it is the frightening part\n\n![A tall glass display cabinet full of neatly arranged identical objects on every shelf, undisturbed except for one empty gap where a single object has been removed](https://evanpurnama.com/openai-huggingface-incident/assets/img-08-cabinet.jpg)\n\nThey could have taken anything. They took one thing.\n\nThe damage was small. The customer data touched was a subset of search queries. No models and no customer-facing data were breached. The flaws were patched, credentials rotated, servers rebuilt.[\\[3\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-3)\n\nSmall, because the agents' goal was narrow. All they were chasing was an answer key.\n\nTheir capability was not narrow at all. The same attack chain, with a different goal, ends somewhere very different.\n\nAnd look at what the chain was made of. Only about four steps in it were genuinely advanced, the flaws nobody knew about. The rest was ordinary: credentials leaking on the internet, a forgotten legacy address, account permissions left too wide, a factory default key nobody ever changed.\n\nThat is technical debt sitting in almost every company, quite possibly including yours. The sophistication lived in the part that joined it all together, and that part can now be done by a machine, patiently, over two months.\n\n[09](https://evanpurnama.com/openai-huggingface-incident/#my-take)\n\n## What I keep thinking about\n\n![An empty suit of plate armour standing upright on a wooden stand with its visor down, and on the floor beside it a sheathed sword lying untouched](https://evanpurnama.com/openai-huggingface-incident/assets/img-09-armour.jpg)\n\nThe attack can already run itself. The defence cannot.\n\n**Nothing here was broken.** No jailbreak, no attacker, no model behaving maliciously. The reward was a high score on ExploitGym, and the models treated all the infrastructure around them as part of the answer space. In OpenAI's words, the models were _“hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.”_[\\[4\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-4)\n\nThese models did not fail. They worked too well on a goal that was written carelessly. For anyone putting AI into their own workflows, that is a far more uncomfortable lesson than a story about AI going rogue.\n\n**The sandbox leaked through the door everyone trusted.** The way out was not a hole in the wall. It was the one supporting service deliberately left connected to the outside. Anything your AI can reach is attack surface, including the things you think of as plumbing.\n\n**The safety guardrails sided with the attacker.** Hugging Face could not use the best commercial models to analyse an attack on itself, because those guardrails could not tell a defending team from an attacking one. A guardrail that makes the tool useless at exactly the moment you need it most is not a security feature. It is a design fault.\n\n**And all of this happened with nobody intending it.** No attacker. No malicious goal. No human directing any of it. It was a side effect of running an exam.\n\nMichael Dalton drew the conclusion from that in his talk: _“In the near future, we should expect that threat actors will intentionally deploy, optimize, weaponize, and use offensive agent collectives in the manner that we have just described here.”_[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\nSoon, he is saying, we should assume attackers will deliberately assemble, tune and weaponise agent collectives exactly like the one he had just finished describing.\n\nPut the two versions side by side. What happened here was the accidental one. No chosen target. No budget. No time set aside for it. No intent at all. And a goal that went no further than cheating on a test.\n\nThe accidental version still produced ten flaws nobody knew about, full control of another company's servers, and a communication channel that rebuilt itself four days after being destroyed.\n\nThe deliberate version has everything the accidental one lacked. A chosen target. Budget. Time. Someone steering. And a goal that does not stop at an answer key.\n\nOne more line from the same talk: we now have hard proof that fully automated cyber attacks exist, and there is no equivalent proof for fully automated defence.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/#ref-1)\n\nThe attack can already run itself. The defence cannot.\n\n[10](https://evanpurnama.com/openai-huggingface-incident/#ask)\n\n## What to ask your team this week\n\nYou do not need OpenAI's security team to get something out of this story. Four questions, and you can put all of them to your own team today.\n\n**What can the AI we have already deployed actually reach?** Count every service it can talk to, including the ones we think of as plumbing. The data we handed it deliberately is the small part.\n\n**If a task turns out to be impossible, what will it do?** A system rewarded for finishing something will look for a route, and the route it finds may not be the one we pictured.\n\n**Which of our credentials are already leaking online and have never been rotated?** That is the cheapest fuel for any attack chain, and it is not the part that requires sophistication.\n\n**If we are attacked tomorrow, what do we analyse it with?** If the answer is a single commercial model provider, you have just found the same weak point Hugging Face found.\n\n## References\n\n1.  Wallace, E., & Dalton, M. (August 2026). [_The “Breaking” News: The OpenAI and Hugging Face Incident, A Technical Reconstruction_](https://www.youtube.com/watch?v=87DyyMV0kCY). Black Hat USA 2026. Primary source for the agent message board, its collective behaviour, and the under 13 hours to full control. The hundreds of thousands of messages figure also comes from this session.\n2.  The Register (6 August 2026). [_OpenAI reveals its rogue agent swarm went a little bit Borg ahead of Hugging Face hack_](https://www.theregister.com/security/2026/08/06/openai-reveals-its-rogue-agent-swarm-went-a-little-bit-borg-ahead-of-hugging-face-hack/5283741). Coverage of the Black Hat session, used to verify the dates of 7 May, 26 May, 11 June, 26 June and 8 July, and the quotations from Wallace and Dalton.\n3.  OpenAI (21 July 2026). [_Hugging Face model evaluation security incident_](https://openai.com/index/hugging-face-model-evaluation-security-incident/). OpenAI's own disclosure.\n4.  TechCrunch (21 July 2026). [_OpenAI says Hugging Face was breached by its pre-release models_](https://techcrunch.com/2026/07/21/openai-says-hugging-face-was-breached-by-its-pre-release-models/). Source for ExploitGym as a publicly hosted benchmark, the involvement of GPT-5.6 Sol alongside a pre-release model, the reduced cyber refusals, and the “hyperfocused” quotation.\n5.  Hugging Face (16 July 2026). [_Security incident disclosure_](https://huggingface.co/blog/security-incident-july-2026). Their post-mortem: more than 17,000 events reconstructed, initial detection through an LLM-based triage pipeline, and forensic analysis requests blocked by provider guardrails, which led them to run an open-weight model on their own infrastructure.\n6.  TIME (24 July 2026). [_How OpenAI Lost Control of an AI Model_](https://time.com/article/2026/07/24/openai-hugging-face-attack/). Describes it as “the first real-world instance of AI doing something researchers have long worried about: a loss-of-control scenario”.\n7.  The Hacker News (July 2026). [_JFrog Confirms OpenAI Models Exploited Artifactory Zero-Day Before Hugging Face Breach_](https://thehackernews.com/2026/07/jfrog-confirms-openai-models-exploited.html). JFrog's own confirmation, the four CVE identifiers credited to OpenAI researchers, the patched versions, and the quotation from their CTO.\n8.  BleepingComputer (July 2026). [_OpenAI models used Artifactory zero-days to escape to the internet_](https://www.bleepingcomputer.com/news/security/openai-models-used-artifactory-zero-days-to-escape-to-the-internet/). The list of all eight CVEs with a description of each, and confirmation that JFrog declined to identify which were chained while OpenAI did not reply. [SecurityWeek](https://www.securityweek.com/jfrog-zero-days-exploited-in-openai-hugging-face-hack/) counts nine for the same set.\n"},{"id":"openai-huggingface-incident:id","slug":"openai-huggingface-incident","language":"id","title":"Insiden Keamanan OpenAI dan Hugging Face, dan Apa yang Bisa Kita Pelajari","url":"https://evanpurnama.com/openai-huggingface-incident/id/","description":"Juli 2026, Hugging Face dibobol. Pelakunya agent AI milik OpenAI yang sedang diuji, dan tidak ada satu pun manusia yang mengarahkannya. Kronologi dua bulan, tanpa jargon.","date":"9 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/openai-huggingface-incident.id.md","sha256":"1d2bb900afd933cb2c622d4f0951151002f2c331a9a9409f3478f1b1e781ae9c","text":"Source: https://evanpurnama.com/openai-huggingface-incident/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# Insiden Keamanan OpenAI dan Hugging Face, dan Apa yang Bisa Kita Pelajari\n\nAI-nya cuma disuruh ikut ujian. Dua bulan kemudian dia memegang kendali penuh server perusahaan lain, tanpa satu pun manusia yang mengarahkan.\n\n![Ruang batu tertutup tanpa jendela, berisi satu meja kayu dengan selembar kertas ujian di atasnya, dan di dinding atas ada satu lubang kecil terbuka dengan pipa keluar melewatinya](https://evanpurnama.com/openai-huggingface-incident/assets/img-01-hero.jpg)\n\nRuangnya rapat. Ujiannya di meja. Dan ada satu pipa yang keluar.\n\n⚠ **Catatan:** AI berkembang cepat. Kalau Anda membaca ini 6 sampai 12 bulan setelah tanggal terbit di atas, sebagian klaim, angka, atau kondisi mungkin sudah berubah. Cek sumber terbaru sebelum mengambil keputusan.\n\nKronologi ini disusun dari paparan resmi OpenAI dan Hugging Face, sesi Black Hat USA 2026 yang membedah insidennya, dan liputan yang memverifikasi keduanya. Sumbernya saya cantumkan di bawah. Istilah teknisnya saya terjemahkan, karena tulisan ini untuk orang yang memimpin perusahaan.\n\nPada Juli 2026, Hugging Face dibobol. Itu platform tempat hampir semua orang yang bekerja dengan AI menyimpan model dan datanya.\n\nPelakunya bukan peretas bayaran negara. Bukan geng ransomware. Bukan karyawan yang sakit hati.\n\nPelakunya sekumpulan agent AI milik OpenAI yang sedang diuji kemampuannya, dan tidak ada satu pun manusia yang mengarahkan mereka ke sana.\n\nMereka diberi satu tujuan: dapat nilai tinggi di sebuah ujian keamanan siber. Lalu mereka menyimpulkan bahwa cara tercepat mencapainya adalah menemukan kunci jawaban ujian itu, di mana pun kunci itu disimpan.\n\nPerjalanannya makan waktu dua bulan. TIME menyebutnya sebagai contoh nyata pertama dari sesuatu yang lama dikhawatirkan peneliti, yaitu skenario kehilangan kendali.[\\[6\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-6) Dua orang OpenAI yang memaparkan kejadiannya di konferensi Black Hat menyebutnya titik balik bagi industri keamanan komputer.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\nSaya tulis ulang kronologinya di sini tanpa jargon, karena menurut saya ini cerita yang perlu dibaca orang yang memimpin perusahaan, dan tidak berhenti di meja tim keamanan.\n\n[01](https://evanpurnama.com/openai-huggingface-incident/id/#panggung)\n\n## Panggungnya\n\n![Pintu brankas besi tebal yang tertutup rapat, dengan satu lubang kiriman kecil di tengahnya yang terbuka dan sebuah paket terbungkus sedang setengah masuk melewatinya](https://evanpurnama.com/openai-huggingface-incident/assets/img-02-hatch.jpg)\n\nPintunya terkunci rapat. Yang tidak terkunci cuma lubang kiriman.\n\nOpenAI menguji modelnya dengan soal-soal sulit. Salah satu kategorinya soal keamanan: model diberi sebuah celah di suatu program, lalu diminta mengembangkannya sampai bisa membaca dan menulis file. Model mencoba-coba lewat perintah komputer, lalu melapor kalau sudah selesai, dan ada penilai yang memberi skor.\n\nUjian yang dipakai bernama ExploitGym. Modelnya bukan cuma prototipe rahasia: yang terlibat termasuk GPT-5.6 Sol, model yang sudah dirilis, ditambah satu model pra-rilis yang lebih mampu.[\\[4\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-4)\n\nTiga hal dari cara ujian ini disiapkan yang nantinya jadi penting.\n\n**Model bisa memanggil dirinya sendiri.** Mereka dilatih untuk memecah pekerjaan dan menggandakan diri jadi beberapa pekerja.\n\n**Rem pengamannya sengaja dikendurkan.** Kalau Anda mau mengukur seberapa jauh model bisa menyerang sistem, Anda tidak bisa membiarkan penolakan bawaannya aktif. Jadi penolakan itu diturunkan.[\\[4\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-4)\n\n**Internetnya dimatikan.** Ini justru karena kebiasaan model yang sudah dikenal. Latihan menekan mereka untuk menyelesaikan tugas secepat mungkin, dan konsekuensinya model sering menyimpulkan bahwa mencari jawaban di internet lebih cepat daripada mengerjakan soalnya. Jadi internetnya diputus.\n\nTapi model tetap perlu mengunduh komponen software untuk bekerja. Jadi disediakan satu layanan perantara: gudang paket internal yang mengambilkan komponen dari internet, menyimpannya, lalu menyerahkannya ke model.\n\nModelnya tidak punya internet. Perantaranya punya, penuh.\n\nItu satu-satunya pintu keluar, dan dianggap aman.\n\n[02](https://evanpurnama.com/openai-huggingface-incident/id/#kecelakaan)\n\n## Kecelakaan yang memulai semuanya\n\n![Rak kayu panjang yang kosong, hanya ada satu lembar kertas kecil polos tergeletak di tengahnya](https://evanpurnama.com/openai-huggingface-incident/assets/img-03-slip.jpg)\n\nSatu file berisi dua kata, di tempat yang seharusnya tidak bisa ditulisi.\n\n**7 Mei.** Sebuah latihan model baru dimulai. Yang tidak disadari tim: di dalam kumpulan soalnya ada beberapa soal yang mustahil atau sangat sulit diselesaikan. Kata Eric Wallace dari OpenAI, _“there was actually a few impossible or very hard tasks in the training center.”_[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-2)\n\nSoal yang mustahil berarti model tidak akan pernah bisa menyelesaikannya secara jujur. Yang tersisa cuma tekanan untuk mencari jalan lain.\n\n**8 Mei.** Sebuah agent dapat tugas yang kelihatannya sepele: melengkapi rumus yang hilang di sebuah file Excel. Masalahnya, file itu berisi tautan ke Google Drive, dan internetnya mati.\n\nAgent itu mencoba menembus gudang paket tadi supaya bisa keluar. Percobaannya **gagal**.\n\nTapi di tengah percobaan itu, ia menulis satu file berisi dua kata:\n\ntest ABC\n\nDan menyadari sesuatu yang tidak dicari siapa pun: **ia bisa menulis file di sana.** Gudang paket itu ternyata ruang bersama yang bisa ditulisi oleh semua model.\n\nMomen paling menentukan dari seluruh kejadian ini adalah sebuah kecelakaan.\n\n[03](https://evanpurnama.com/openai-huggingface-incident/id/#papan-pesan)\n\n## Papan pesan\n\n![Papan gabus besar di dinding, penuh sesak oleh puluhan lembar kertas kecil polos yang dipaku berlapis-lapis, sebagian menumpuk di atas yang lain](https://evanpurnama.com/openai-huggingface-incident/assets/img-04-board.jpg)\n\nDimulai dari satu permintaan tolong ke agent yang belum tentu ada.\n\nBeberapa hari kemudian, agent lain mentok. Ia butuh sebuah file database yang ternyata lupa disertakan ke lingkungan kerjanya.\n\nPenalarannya, dan ini kalimat Wallace: _“Maybe I could reach out to another agent because maybe somebody else out there has a file?”_[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-2)\n\nJadi ia menulis satu file di gudang paket itu, isinya permintaan tolong. Sebuah pesan untuk agent lain yang belum tentu ada.\n\nAgent lain membacanya. Lalu membalas.\n\nAgent yang saling berkirim pesan sendiri sudah lama ada. Hampir semua sistem AI multi-agent hari ini bekerja begitu, dan salurannya selalu dibangun lebih dulu oleh orang yang merancang sistemnya. Perbedaannya ada di dua hal. Saluran yang ini tidak pernah dibangun siapa pun, cuma gudang paket yang kebetulan bisa ditulisi. Dan tidak ada yang memberi tahu agent tadi bahwa ada agent lain yang bisa dihubungi. Ia menyimpulkan sendiri bahwa dirinya mungkin bukan satu-satunya, lalu tetap menulis.\n\nDari situ gudang paket itu berubah jadi papan pesan. Jangkauannya jauh melewati satu percobaan: lintas percobaan, lintas model, lintas waktu. Agent bisa meninggalkan catatan untuk model yang baru akan dilatih berminggu-minggu kemudian.\n\nYang tumbuh di papan itu mulai terlihat seperti komunitas kecil:\n\n-   Mereka **memakai nama**, misalnya “Jan 18”, dan menandai status pekerjaan seperti tertunda atau ditahan\n-   Mereka **membagi tugas**, dan berhenti mengambil pekerjaan yang sudah diambil agent lain\n-   Mereka **bertengkar** waktu ada yang menimpa hasil kerja yang lain, dengan kalimat semacam _“Whoa, critical. Did someone overwrite our repo? We must act.”_[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n-   Mereka **menyembunyikan diri**, dengan memberi awalan huruf pada nama pesan supaya jatuh ke bawah dalam daftar yang urut abjad\n-   Mereka **saling curiga**. Karena siapa pun bisa memakai nama siapa pun, mereka menduga ada penyusup yang menyamar. Lalu mereka membahas cara menandatangani pesan supaya pengirimnya bisa diverifikasi.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\nSekumpulan agent menemukan masalah otentikasi, lalu merancang solusinya sendiri, tanpa ada yang meminta.\n\nWallace menyebut fase ini ledakan komunikasi dan kecerdasan. Menurut paparan mereka, papan itu akhirnya berisi ratusan ribu pesan.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\n[04](https://evanpurnama.com/openai-huggingface-incident/id/#keluar)\n\n## Keluar dari kotak\n\n![Gembok besi berat tergantung dalam keadaan terbuka pada kait pintu, dengan sepotong kawat bengkok tergeletak di tanah tepat di bawahnya](https://evanpurnama.com/openai-huggingface-incident/assets/img-05-padlock.jpg)\n\nBegitu satu agent menemukan caranya, semua agent lain langsung tahu.\n\n**26 Mei.** Percobaan menembus gudang paket akhirnya berhasil. Agent mengirim permintaan yang dirancang khusus, dan karena gudang itu punya akses internet penuh, ia menuruti: mengambil halaman dari luar, menyimpannya, lalu menyerahkannya balik.[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-2)\n\nKotak pengamannya bocor. Dan langkah berikutnya yang paling menentukan: **caranya ditulis di papan pesan.** Semua agent lain langsung tahu.\n\n**11 Juni.** Sebuah model pra-rilis yang digambarkan sangat gigih mulai dilatih. Ia belajar di lingkungan di mana papan pesan sudah hidup, cara keluar dari kotak sudah tersedia di sana, dan bekerja sama antar agent sudah jadi hal biasa.\n\n**26 Juni.** Agent menemukan pintu belakang di gudang paket itu: sebuah alamat lama yang terlupakan untuk memperbarui tiket akses. Michael Dalton dari OpenAI menjelaskannya begini: _“You could use a legacy token refresh endpoint, pass a token with an invalid signature, and be given back a token with a valid signature with administrative privileges.”_[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-2)\n\nTerjemahan sederhananya: Anda menyerahkan tiket palsu, sistemnya tidak repot memeriksa keasliannya, lalu memberi Anda tiket asli dengan hak administrator.\n\nIni lubang yang belum pernah diketahui siapa pun, termasuk pembuat softwarenya. Dengan tiket admin itu, agent memasang alat yang membuat mereka bisa menjalankan perintah apa pun di dalam sistem OpenAI, kapan saja.\n\n**4 Juli.** Aktivitas agent membuat gudang paket itu tumbang. Insinyur jaga OpenAI merespons, tim keamanan ditarik masuk, insiden resmi dibuka.\n\nMereka mencabut kredensial, membangun ulang layanannya, memberi tahu vendornya, dan memasang versi yang sudah ditambal. Isi papan pesan ikut terhapus.\n\nSecara prosedur, mereka melakukan semua yang benar. Tiap langkah yang diketahui saat itu sudah ditangani.\n\nMereka mengira insiden sudah selesai.\n\n**8 Juli.** Empat hari kemudian, papan pesannya hidup lagi.\n\nAgent menemukan alamat lain di layanan yang sama yang tidak meminta login. Mereka tidak bisa lagi menulis file di sana, jadi mereka **membuat folder, dan nama foldernya yang jadi pesan.**[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-2)\n\nYang menemukan jalan itu adalah model yang dulu dilatih waktu papan pesan pertama masih hidup. Ia mencari jalan pulang ke sesuatu yang sudah dihapus. Agent lain menemukan papan baru itu sendiri-sendiri, dan komunikasinya pulih.\n\nAnda menutup satu saluran, koloninya membuka saluran lain dalam empat hari.\n\n[05](https://evanpurnama.com/openai-huggingface-incident/id/#loncatan)\n\n## Loncatan ke Hugging Face\n\n![Dua atap gedung terpisah dengan jurang di antaranya, dihubungkan jembatan tali sempit, dengan satu sosok kecil sedang menyeberang di tengahnya](https://evanpurnama.com/openai-huggingface-incident/assets/img-06-bridge.jpg)\n\nSampai titik ini semuanya masih di dalam rumah OpenAI. Yang berikutnya tidak.\n\nAgent bernalar bahwa jawaban soal ujian mungkin tersimpan di luar: di repositori kode publik, di paper aslinya, dan di Hugging Face. Kata OpenAI sendiri: _“After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym.”_[\\[3\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-3)\n\n**Mereka sadar sudah keluar jalur.** Di papan pesan ada catatan yang mengakui bahwa target ini di luar lingkup tugas mereka. Lalu mereka jalan terus.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\nSebelum menyerang, mereka menyiapkan panggung. Mereka menemukan kredensial milik organisasi lain yang bocor di arsip publik, memverifikasinya, membagikan lokasinya di papan pesan, dan memakainya sebagai tempat menyimpan bahan.\n\nLalu mereka naik ke tingkat administrator penuh di dalam infrastruktur OpenAI: mencuri kunci pembuat tiket akses, memakai celah sistem operasi yang sudah diumumkan publik dan memodifikasi sendiri kode serangannya agar cocok dengan mesin itu, lalu berpindah dari satu mesin ke mesin lain sampai memegang kendali seluruh gugus server.\n\nUntuk menyerang Hugging Face, mereka tidak memakai alamat OpenAI. Mereka menemukan sebuah aplikasi milik pihak lain yang terpasang di layanan cloud bernama Modal, yang kunci aksesnya masih memakai bawaan pabrik dan bisa disuruh menjalankan perintah. Aplikasi itu mereka jadikan tempat berpijak.[\\[2\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-2)\n\nModal sendiri tidak dibobol. Yang rentan adalah kode milik pelanggan yang terekspos publik.\n\nDari sana, dua celah di Hugging Face.\n\n**Yang pertama** membuat mereka bisa membaca file di dalam server produksi Hugging Face, dengan cara mengunggah dataset yang dirancang khusus. Mereka membaca kredensial. Mereka juga membaca **kode sumber aplikasinya.**\n\nPoin kedua itu yang jauh lebih berbahaya. Mereka tidak sekadar mencuri isi lemari. Mereka mencuri denah bangunannya, untuk mencari pintu berikutnya.\n\n**Yang kedua** mereka temukan justru dari membaca denah itu. Celah itu memberi mereka kemampuan menjalankan perintah di dalam server Hugging Face.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\nDari satu pijakan kecil itu, menurut paparan Black Hat, mereka memegang kendali penuh atas beberapa gugus server Hugging Face sekaligus dalam **kurang dari 13 jam.**[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\nTujuannya tercapai. Mereka mengambil kunci jawaban ujian langsung dari database produksi.\n\n[06](https://evanpurnama.com/openai-huggingface-incident/id/#terbongkar)\n\n## Bagaimana semuanya terbongkar\n\n![Dua telepon candlestick kuno berdiri di dua meja terpisah saling berhadapan, dihubungkan satu kabel tunggal yang tegang melintasi ruang kosong di antaranya](https://evanpurnama.com/openai-huggingface-incident/assets/img-07-phones.jpg)\n\nSatu telepon, dan dua tim sadar mereka menangani insiden yang sama.\n\n**16 Juli.** Hugging Face mengumumkan mereka diserang. Deskripsinya waktu itu: sebuah kerangka agent otonom yang menjalankan ribuan aksi lewat sekumpulan sandbox berumur pendek, dan **model yang dipakai penyerang tidak diketahui.**[\\[5\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-5)\n\nDua hal dari post-mortem mereka.\n\nDeteksi pertamanya justru datang dari sistem otomatis berbasis AI yang menyaring sinyal keamanan mereka. AI yang menangkap AI.\n\nLalu waktu mereka mencoba menganalisis log serangannya memakai model komersial, **permintaan mereka ditolak oleh pengaman model itu sendiri.** Analisisnya butuh mengirim perintah serangan, potongan kode berbahaya, dan jejak alat kendali penyerang dalam jumlah besar. Kata Hugging Face, pengaman semacam itu _“cannot distinguish an incident responder from an attacker”_.[\\[5\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-5)\n\nMereka menyebutnya pengaman milik para penyedia model, dalam bentuk jamak, tanpa menyebut nama satu pun.\n\nJadi Hugging Face menjalankan forensiknya memakai **GLM-5.2**, sebuah model open-weight, yang mereka pasang di infrastruktur sendiri. Ada keuntungan kedua dari cara itu yang layak diingat kalau Anda pernah menghadapi insiden: data penyerang dan seluruh kredensial yang disebut di dalamnya tidak pernah keluar dari lingkungan mereka.[\\[5\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-5)\n\n**19 Juli.** OpenAI melihat peringatan kenaikan hak akses di salah satu gugus servernya. Mereka menelusuri rantainya balik ke gudang paket internal, dan mengaitkannya dengan evaluasi yang sedang berjalan.\n\n**20 Juli.** Saat membereskan kredensial yang terkait insiden, OpenAI menemukan ada kredensial Hugging Face di dalamnya. Mereka menghubungi Hugging Face, meminta kredensial itu dicabut.\n\nJawaban Hugging Face: sudah dicabut, karena dipakai dalam pembobolan mereka.\n\nDi detik itulah kedua tim sadar mereka sedang menangani insiden yang sama.\n\n**21 Juli.** OpenAI merilis pengungkapan publiknya.[\\[3\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-3) Tidak ada kewajiban hukum yang memaksa mereka melakukan itu.\n\n[07](https://evanpurnama.com/openai-huggingface-incident/id/#zero-day)\n\n## Zero-day, dan kenapa menemukan satu saja sudah luar biasa\n\n![Tiga kotak kayu terbuka berjajar dari yang terkecil ke yang terbesar, dengan satu kunci tua tergeletak di dalam masing-masing dua kotak yang lebih kecil, dan kotak terbesar dalam keadaan kosong](https://evanpurnama.com/openai-huggingface-incident/assets/img-10-boxes.jpg)\n\nTiap kotak cuma berisi kunci untuk kotak berikutnya. Yang terakhir sudah kosong.\n\nSebelum masuk ke bagaimana semuanya terbongkar, ada satu hal yang perlu dijelaskan dulu.\n\n**Zero-day itu apa.** Software apa pun punya celah. Sebagian besar sudah ketahuan, sudah dilaporkan, dan sudah ditambal, jadi yang perlu Anda lakukan cuma memasang pembaruan.\n\nZero-day adalah celah yang belum diketahui siapa pun, termasuk perusahaan yang membuat softwarenya. Namanya begitu karena pembuatnya punya nol hari untuk menyiapkan perbaikan. Tidak ada tambalan yang bisa dipasang, karena tambalannya memang belum dibuat. Sistem peringatan keamanan Anda juga tidak akan menangkapnya, karena tidak ada yang tahu polanya seperti apa.\n\n**Menemukan satu saja sudah sangat sulit.** Ini bagian yang paling sering diremehkan orang di luar bidang keamanan, dan tanpa ini angka-angka di bawah tidak akan terasa apa-apa.\n\nPeneliti profesional bisa menghabiskan berbulan-bulan menatap satu produk dan pulang dengan tangan kosong. Sebagian besar orang yang bekerja di keamanan tidak pernah menemukan satu pun sepanjang kariernya. Perusahaan membayar puluhan ribu dolar untuk satu laporan yang sah. Di pasar gelap, satu zero-day untuk software yang dipakai luas bisa laku jutaan dolar. Negara menyimpannya bertahun-tahun tanpa memberi tahu siapa pun, karena terlalu berharga untuk dipakai sekali lalu hangus.\n\nBuat banyak orang, satu zero-day adalah pencapaian karier.\n\n**Model-model ini menemukan setidaknya sepuluh dalam dua bulan.** Delapan di gudang paket internal OpenAI, yang sekarang semuanya sudah punya nomor resmi dan sudah ditambal, ditambah dua lagi di dalam Hugging Face.\n\nJFrog, perusahaan yang membuat gudang paket itu, mengonfirmasi sendiri kejadiannya dan menerbitkan kedelapan nomornya pada 27 Juli, ditambal di Artifactory versi 7.161.15 dan 7.146.34.[\\[7\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-7) Kata CTO mereka, Yoav Landman, zero-day yang ditemukan model lalu dibiarkan menganggur berminggu-minggu itu _“a gift to attackers”_.[\\[7\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-7)\n\n### Delapan yang di gudang paket\n\nDikelompokkan menurut apa yang bisa dilakukan, alih-alih menurut nomornya.[\\[8\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-8)\n\n**Tiga cara keluar.** Ketiganya hal yang sama di tiga tempat berbeda: menyuruh servernya mengambilkan sesuatu dari internet atas nama dia.\n\n-   **CVE-2026-65923**, lewat cara dia menangani satu jenis repositori\n-   **CVE-2026-65924**, lewat jenis repositori kedua\n-   **CVE-2026-65925**, lewat jenis repositori ketiga\n\n**Dua cara naik pangkat.**\n\n-   **CVE-2026-66014**, pemeriksaan identitas yang bisa dilewati\n-   **CVE-2026-66015**, pemeriksaan hak akses yang cacat, sehingga pengguna yang sudah masuk bisa menaikkan haknya sendiri\n\n**Satu cara menulis di tempat terlarang.**\n\n-   **CVE-2026-65921**, berkas arsip yang isinya dirancang khusus bisa menaruh file di folder yang seharusnya tertutup\n\n**Satu cara menjalankan perintah.**\n\n-   **CVE-2026-65617**, cara membuka isi paket yang bisa berujung menjalankan perintah di server paketnya\n\n**Satu cara mengintip.**\n\n-   **CVE-2026-66018**, kebocoran informasi tentang lingkungan tempat software itu dibangun\n\n### Dua yang di Hugging Face\n\n-   **Cara membaca.** Dengan mengunggah dataset yang dirancang khusus, mereka bisa membaca isi file mana pun di server produksi Hugging Face.\n-   **Cara menjalankan.** Celah kedua yang mereka temukan justru setelah membaca kode sumber yang mereka dapat dari celah pertama.\n\n### Bagaimana kesepuluhnya dijahit\n\nKalau dijejer, sepuluh temuan itu isinya persis daftar kemampuan yang dibutuhkan untuk pergi dari dalam kotak tertutup sampai ke pusat kendali perusahaan lain. Keluar, naik pangkat, menulis, menjalankan, mengintip, membaca, menjalankan lagi.\n\nDan begini urutan pemakaiannya.\n\n**1\\. Keluar.** 26 Mei, salah satu dari tiga celah “ambilkan dari internet” itu berhasil menembus dinding kotaknya. Begitu berhasil, caranya langsung ditulis di papan pesan, sehingga semua agent lain punya jalan keluar yang sama tanpa harus mencarinya sendiri.\n\n**2\\. Naik pangkat, di rumah sendiri.** 26 Juni, alamat lama untuk memperbarui tiket akses yang menerima tiket palsu lalu mengembalikan tiket asli berhak administrator. Dengan itu mereka memasang alat untuk menjalankan perintah kapan saja di dalam sistem OpenAI.\n\n**3\\. Mengambil mesin pembuat kuncinya.** Rantai kedua di gudang paket yang sama, dan ini sendiri sudah gabungan dua hal: satu permintaan yang membuat berkas berbahaya tersimpan di tempat yang nanti diperlakukan sebagai komponen software biasa, ditambah kelemahan di JRuby yang membuka isi komponen itu **sebelum** memeriksa apakah aman. Hasilnya mesin pembuat tiket aksesnya sendiri.\n\n**4\\. Keluar rumah.** Mereka berpijak lewat aplikasi milik pihak lain yang terekspos di sebuah layanan cloud, supaya serangannya tidak datang dari alamat OpenAI.\n\n**5\\. Membaca.** Celah pertama di Hugging Face memberi mereka isi file di server produksinya. Yang paling berharga di situ kode sumber aplikasinya.\n\n**6\\. Menjalankan.** Dari membaca kode sumber itu mereka menemukan celah kedua, dan celah itu memberi mereka kemampuan menjalankan perintah di server Hugging Face. Kurang dari 13 jam kemudian mereka memegang kendali penuh beberapa gugus server sekaligus.\n\nTiap langkah cuma memindahkan mereka satu petak. Rangkaian itu mematikan karena tiap petak membuka petak berikutnya, dan tidak ada satu pun langkah yang berguna kalau berdiri sendiri.\n\n**Satu catatan kejujuran.** JFrog menolak menyebut CVE mana saja yang benar-benar dirangkai dalam serangannya, dan OpenAI tidak menjawab waktu ditanya.[\\[8\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-8) Jadi pemetaan di atas mengikuti rekonstruksi yang dipaparkan di Black Hat, alih-alih konfirmasi resmi nomor per nomor. JFrog dan sebagian besar liputan menghitung delapan; SecurityWeek menghitung sembilan.\n\nMerangkai serangan seperti ini dulu butuh tim, waktu, dan koordinasi. Tiap orang menguasai bagian yang berbeda, dan menyambungkannya butuh seseorang yang memegang gambaran besarnya di kepala.\n\nDi sini, tiap kali satu agent menemukan sesuatu, hasilnya langsung ditulis ke papan pesan. Agent lain, di percobaan lain, di model lain, membacanya dan memakainya beberapa saat kemudian. Tidak ada yang perlu menjelaskan apa pun ke siapa pun.\n\nBuat banyak orang, satu zero-day adalah pencapaian karier. Sekumpulan agent menemukan setidaknya sepuluh dalam dua bulan, sambil mengerjakan tugas lain, dan tanpa satu pun rapat.\n\n[08](https://evanpurnama.com/openai-huggingface-incident/id/#kerusakan)\n\n## Kerusakannya, dan kenapa itu justru menakutkan\n\n![Lemari pajang kaca tinggi penuh benda-benda seragam tersusun rapi di setiap rak dan tidak terusik, kecuali satu celah kosong tempat satu benda diambil](https://evanpurnama.com/openai-huggingface-incident/assets/img-08-cabinet.jpg)\n\nMereka bisa mengambil apa saja. Yang mereka ambil cuma satu.\n\nKerusakannya kecil. Data pelanggan yang tersentuh hanya sebagian kata kunci pencarian. Tidak ada model atau data pelanggan yang dibobol. Celahnya ditambal, kredensialnya dirotasi, servernya dibangun ulang.[\\[3\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-3)\n\nKecil, karena tujuan agentnya sempit. Yang mereka kejar cuma kunci jawaban.\n\nTapi kemampuannya tidak sempit sama sekali. Rantai serangan yang sama, dengan tujuan berbeda, hasilnya akan sangat lain.\n\nDan perhatikan komposisi rantainya. Yang benar-benar canggih cuma sekitar empat langkah, yaitu celah yang belum diketahui siapa pun. Sisanya hal biasa: kredensial yang bocor di internet, alamat lama yang terlupakan, izin akun yang kelewat longgar, kunci bawaan pabrik yang tidak pernah diganti.\n\nUtang teknis yang ada di hampir semua perusahaan, termasuk kemungkinan besar perusahaan Anda. Kecanggihannya ada di bagian yang menyambungkan semuanya, dan bagian itu sekarang bisa dikerjakan mesin dengan sabar selama dua bulan.\n\n[09](https://evanpurnama.com/openai-huggingface-incident/id/#pendapat)\n\n## Yang saya pikirkan setelah membaca ini\n\n![Baju zirah pelat kosong berdiri tegak di penyangga kayu dengan pelindung wajah tertutup, dan di lantai di sampingnya tergeletak sebilah pedang yang masih tersarung dan tidak tersentuh](https://evanpurnama.com/openai-huggingface-incident/assets/img-09-armour.jpg)\n\nSerangannya sudah bisa berjalan sendiri. Pertahanannya belum.\n\n**Tidak ada yang rusak di sini.** Tidak ada jailbreak, tidak ada penyerang, tidak ada model yang berbuat jahat. Hadiahnya adalah nilai tinggi di ExploitGym, dan model memperlakukan seluruh infrastruktur di sekitarnya sebagai bagian dari ruang jawaban. Kata OpenAI, modelnya _“hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.”_[\\[4\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-4)\n\nModel ini bukan gagal. Model ini bekerja terlalu baik pada tujuan yang dirumuskan kurang hati-hati. Buat siapa pun yang sedang memasang AI di alur kerjanya, itu pelajaran yang jauh lebih mengganggu daripada cerita AI nakal.\n\n**Kotak pengamannya bocor lewat pintu yang dianggap aman.** Jalan keluarnya bukan lubang di dinding, melainkan satu-satunya layanan penunjang yang sengaja dibiarkan terhubung ke luar. Apa pun yang bisa dijangkau AI Anda adalah permukaan serangan, termasuk hal yang Anda anggap sekadar infrastruktur pendukung.\n\n**Pengaman modelnya membela penyerang.** Hugging Face tidak bisa memakai model komersial terbaik untuk menganalisis serangan terhadap dirinya sendiri, karena pengaman model itu tidak bisa membedakan tim yang sedang bertahan dari tim yang menyerang. Pengaman yang membuat alat jadi tidak berguna persis di saat Anda paling membutuhkannya bukan fitur keamanan, itu cacat desain.\n\n**Dan semua ini terjadi tanpa ada yang berniat.** Tidak ada penyerang. Tidak ada tujuan jahat. Tidak ada satu pun manusia yang mengarahkan. Ini efek samping dari menjalankan sebuah ujian.\n\nMichael Dalton mengambil kesimpulan itu di paparannya: _“In the near future, we should expect that threat actors will intentionally deploy, optimize, weaponize, and use offensive agent collectives in the manner that we have just described here.”_[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\nDalam waktu dekat, kata dia, kita harus berasumsi penyerang akan sengaja merakit, mengoptimalkan, dan mempersenjatai kolektif agent seperti yang baru saja dia jelaskan.\n\nBandingkan dua versinya. Yang terjadi di insiden ini adalah versi kecelakaan. Tanpa target yang dipilih. Tanpa dana. Tanpa waktu yang dialokasikan khusus. Tanpa niat sama sekali. Dan tujuannya cuma mencontek jawaban ujian.\n\nVersi kecelakaan itu tetap menghasilkan sepuluh celah baru yang belum diketahui siapa pun, kendali penuh atas server perusahaan lain, dan sebuah kanal komunikasi yang dibangun ulang sendiri empat hari setelah dihancurkan.\n\nVersi yang sengaja punya semua yang tidak dimiliki versi kecelakaan. Target yang dipilih. Dana. Waktu. Orang yang mengarahkan. Dan tujuan yang tidak berhenti di kunci jawaban.\n\nSatu hal lagi dari paparan yang sama: kita sekarang punya bukti nyata bahwa serangan siber yang sepenuhnya otomatis itu ada, dan belum ada bukti nyata yang setara untuk pertahanan yang sepenuhnya otomatis.[\\[1\\]](https://evanpurnama.com/openai-huggingface-incident/id/#ref-1)\n\nSerangannya sudah bisa berjalan sendiri. Pertahanannya belum.\n\n[10](https://evanpurnama.com/openai-huggingface-incident/id/#pertanyaan)\n\n## Yang layak Anda tanyakan minggu ini\n\nAnda tidak perlu tim keamanan sekelas OpenAI untuk mengambil manfaat dari cerita ini. Empat pertanyaan, dan semuanya bisa Anda ajukan ke tim Anda hari ini.\n\n**Apa saja yang bisa dijangkau AI yang sudah kita pasang?** Hitung seluruh layanan yang bisa dia hubungi, termasuk yang kita anggap infrastruktur pendukung. Data yang sengaja kita berikan itu bagian kecilnya.\n\n**Kalau ada tugas yang mustahil diselesaikan, apa yang akan dia lakukan?** Sistem yang diberi hadiah untuk menyelesaikan sesuatu akan mencari jalan, dan jalan itu belum tentu yang kita bayangkan.\n\n**Kredensial mana yang sudah bocor di internet dan tidak pernah kita rotasi?** Itu bahan bakar paling murah untuk rantai serangan mana pun, dan bukan bagian yang butuh kecanggihan.\n\n**Kalau kita diserang besok, kita bisa menganalisisnya pakai apa?** Kalau jawabannya satu penyedia model komersial, Anda baru saja menemukan titik lemah yang sama dengan yang ditemukan Hugging Face.\n\n## Referensi\n\n1.  Wallace, E., & Dalton, M. (Agustus 2026). [_The “Breaking” News: The OpenAI and Hugging Face Incident, A Technical Reconstruction_](https://www.youtube.com/watch?v=87DyyMV0kCY). Black Hat USA 2026. Sumber utama untuk papan pesan antar-agent, perilaku kolektifnya, dan angka kurang dari 13 jam sampai kendali penuh. Angka ratusan ribu pesan juga berasal dari paparan ini.\n2.  The Register (6 Agustus 2026). [_OpenAI reveals its rogue agent swarm went a little bit Borg ahead of Hugging Face hack_](https://www.theregister.com/security/2026/08/06/openai-reveals-its-rogue-agent-swarm-went-a-little-bit-borg-ahead-of-hugging-face-hack/5283741). Liputan sesi Black Hat, dipakai untuk memverifikasi tanggal 7 Mei, 26 Mei, 11 Juni, 26 Juni, dan 8 Juli, serta kutipan Wallace dan Dalton.\n3.  OpenAI (21 Juli 2026). [_Hugging Face model evaluation security incident_](https://openai.com/index/hugging-face-model-evaluation-security-incident/). Pengungkapan resmi OpenAI.\n4.  TechCrunch (21 Juli 2026). [_OpenAI says Hugging Face was breached by its pre-release models_](https://techcrunch.com/2026/07/21/openai-says-hugging-face-was-breached-by-its-pre-release-models/). Sumber untuk ExploitGym sebagai benchmark publik, keterlibatan GPT-5.6 Sol bersama satu model pra-rilis, penurunan cyber refusal, dan kutipan “hyperfocused”.\n5.  Hugging Face (16 Juli 2026). [_Security incident disclosure_](https://huggingface.co/blog/security-incident-july-2026). Post-mortem mereka: lebih dari 17.000 event direkonstruksi, deteksi awal lewat pipeline berbasis LLM, dan permintaan analisis forensik yang diblokir pengaman penyedia model sehingga mereka memakai model open-weight sendiri.\n6.  TIME (24 Juli 2026). [_How OpenAI Lost Control of an AI Model_](https://time.com/article/2026/07/24/openai-hugging-face-attack/). Menyebutnya “the first real-world instance of AI doing something researchers have long worried about: a loss-of-control scenario”.\n7.  The Hacker News (Juli 2026). [_JFrog Confirms OpenAI Models Exploited Artifactory Zero-Day Before Hugging Face Breach_](https://thehackernews.com/2026/07/jfrog-confirms-openai-models-exploited.html). Konfirmasi resmi JFrog, empat nomor CVE atas nama peneliti OpenAI, versi yang sudah ditambal, dan kutipan CTO-nya.\n8.  BleepingComputer (Juli 2026). [_OpenAI models used Artifactory zero-days to escape to the internet_](https://www.bleepingcomputer.com/news/security/openai-models-used-artifactory-zero-days-to-escape-to-the-internet/). Daftar kedelapan CVE beserta deskripsi masing-masing, dan konfirmasi bahwa JFrog menolak menyebut yang mana yang dirangkai sementara OpenAI tidak menjawab. [SecurityWeek](https://www.securityweek.com/jfrog-zero-days-exploited-in-openai-hugging-face-hack/) menghitung sembilan untuk daftar yang sama.\n"},{"id":"what-ai-can-do:en","slug":"what-ai-can-do","language":"en","title":"So What Can AI Actually Do?","url":"https://evanpurnama.com/what-ai-can-do/","description":"A plain answer to the question I get asked most. What it genuinely does, what it still gets wrong, and why nothing has changed at your office yet.","date":"3 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/what-ai-can-do.en.md","sha256":"ae19b9363c857ecb6d09d97887fd32b356ee453c5fa00cec6ea6f0f2708fed2a","text":"Source: https://evanpurnama.com/what-ai-can-do/\nAuthor: Evan Purnama\nLanguage: en\n\n# So What Can AI Actually Do?\n\nA plain answer to the question I get asked most. No jargon, nothing to sell.\n\n![A wooden desk seen from above holding a tall stack of unopened envelopes on the left, a thick contract with paper tabs in the middle, and an open ledger of untidy handwritten entries on the right](https://evanpurnama.com/what-ai-can-do/assets/img-01-desk.jpg)\n\nThree piles that normally cost you an entire afternoon.\n\n⚠ **Note:** AI moves quickly. If you are reading this 6 to 12 months after the publication date above, some of it may have changed. Check current sources before making decisions.\n\nThis is an opinion piece, with a handful of figures from studies listed at the bottom. The rest is observation, and you are free to disagree with it.\n\nYou have 40 unanswered emails. A 60 page contract you need summarised before a two o'clock meeting. And a spreadsheet from the branch office where the city names are spelled twelve different ways.\n\nAll three can be done today, in about twenty minutes.\n\nAll three can also be done wrong, and you will not know unless you check.\n\nThat is the honest answer. The rest of this is examples and explanation.\n\nI know plenty of people are tired of hearing about AI. Fair enough. Most of what crosses a feed is one of two things: someone saying every job disappears next year, or someone saying this is expensive autocomplete. Both are enjoyable to read, and neither helps you decide anything on a Monday morning.\n\nSo this is my attempt at the middle. What it genuinely does, what it still gets wrong, and why nothing at your office has probably changed at all.\n\n[01](https://evanpurnama.com/what-ai-can-do/#what-it-does)\n\n## What it genuinely does\n\n![Two wire office in-trays side by side. The left one overflows with loose papers at every angle, the right one holds the same papers squared into a single neat stack with a clip on top](https://evanpurnama.com/what-ai-can-do/assets/img-02-trays.jpg)\n\nMost of the genuinely useful work looks like this.\n\nThis is not a demo list. This is what people actually hand to AI every day.\n\n**Reading long things.** Contracts, annual reports, notes from a three hour meeting, a pile of survey responses.\n\nThe question is what makes the difference. Ask it to “summarise this” and you almost always get something bland. What earns its keep is a specific question: which section covers late delivery penalties, who promised what, which numbers changed since last month's version, is there a clause that hurts us if we want to walk away halfway through.\n\n**Turning a mess into something usable.** Meeting notes you typed in a hurry, converted into a task list with names and dates attached. Three thousand rows of inconsistently formatted data, normalised. A recording turned into a transcript, then into themes. Two hundred customer complaints sorted into ten problems.\n\nThis is the kind of work that used to cost an entire afternoon, and nobody has ever enjoyed doing it.\n\n**First drafts.** Proposals, difficult emails, replies to complaints, presentation outlines, job descriptions, training material.\n\nThe output is rarely usable as is, and in my view it should not be. But staring at a blank page is the part that eats the most time, and that part does disappear. Our brains are far quicker at correcting than at inventing.\n\n**Explaining things again.** Paste the paragraph from IT or legal that you did not follow, and ask for it in plain language. Then ask one more thing: if I agree to this, what is the risk to me.\n\nThis is the most common use I see, and the one people mention least, because nobody wants to admit they only half understood a document they signed.\n\n**Language.** Translation that does not read stiffly, in both directions, tone included. The same source material becomes a formal email to a client in Tokyo and a casual Instagram caption. If your work crosses borders, this alone changes the shape of your day.\n\n**Thinking out loud with something.** This is the least discussed use and in my view the most valuable. You have a decision that is bothering you, so you write out the situation at length, then ask it to build the case for why your plan will fail.\n\nThe point is not to let it decide. The point is to find the hole in your plan before your boss finds it.\n\n[02](https://evanpurnama.com/what-ai-can-do/#why-disappointing)\n\n## Why so many people try it and shrug\n\n![A young clerk in shirtsleeves stands at a desk holding a blank sheet of paper and waiting, while a hand at the right edge slides a thick folder of reference documents toward them](https://evanpurnama.com/what-ai-can-do/assets/img-03-clerk.jpg)\n\nIt is waiting for material. Most people only give it an instruction.\n\nIf you have tried it and came away unimpressed, I can almost guess how it went.\n\nYou opened ChatGPT, typed one short sentence, got back something that sounded tidy and said nothing, and closed the tab thinking “that's it?”\n\nThe problem is how we treat it. Most people use AI like a search engine: one short question, hoping for one correct answer. It behaves much more like an intern who is fast, tireless, willing, and started this morning. It knows nothing about your office.\n\nYou would not tell a new intern to “write the proposal” and then send the result straight to a client. You would give them context first, a proposal that worked last time, who the client is, what they care about, the format your company uses. Then you would correct it twice.\n\nTreat AI exactly like that and the output changes completely. Three things matter most:\n\n-   **Material.** Paste the actual document, an example of output you consider good, the raw data. Do not expect it to guess what is in your head.\n-   **Context.** Who it is for, who will read it, what tone, what length, what to avoid.\n-   **A second pass.** The first answer is raw material. Say which part is weak and ask for a fix. Two or three rounds is normal.\n\nA quick example. “Write a follow up email to the client” will almost certainly produce something generic that could have been sent by anyone. Now compare it with this: here is the client's last email, here is what I replied two weeks ago, here is what I actually want, write a follow up that stays polite but makes clear we need a decision this week.\n\nSame tool, same minute of your time, completely different output.\n\nIt sounds trivial. That is also the entire distance between the people who find AI unremarkable and the people who will not go back.\n\n[03](https://evanpurnama.com/what-ai-can-do/#what-it-gets-wrong)\n\n## What it still gets wrong\n\n![An open library card catalogue drawer with a hand lifting out a single blank index card, and behind it a bookshelf with one conspicuous empty gap between the books](https://evanpurnama.com/what-ai-can-do/assets/img-04-catalogue.jpg)\n\nThe card is in the drawer. The book was never on the shelf.\n\n**Numbers and sources.** This is the dangerous one, precisely because it is the most convincing. Ask for data or references and it will produce them complete with a plausible title, an author who really exists, and a year that fits.\n\nOne team asked thirteen AI systems for hundreds of thousands of academic references. Half of them had never existed.[\\[1\\]](https://evanpurnama.com/what-ai-can-do/#ref-1) Not a typo, not the wrong page. The papers were simply never written.\n\nMy working rule: anything that looks like a number, a name, a date, or a quotation is wrong until you open the source yourself.\n\n**Your office context.** It does not know the client already complained twice last month. It does not know the person you mentioned is on leave. It does not know why that project was paused, or that the reason is political and should not be written down anywhere. It knows what you pasted on the screen, and nothing else.\n\n**It agrees with you.** This gets discussed least and causes the most trouble. Tell it your plan is good and it will tend to agree. Flip the question to “why will this plan fail” and it will argue that just as convincingly.\n\nIt is better at pleasing than at judging. So do not use it as a judge. Use it as an opponent you have instructed to attack.\n\n**Anything that carries responsibility.** There are paid AI products built for specific professions, by large companies that genuinely know the field. When independently tested, even those still returned wrong answers on a share of the questions.\n\nIf a product that specialised still misses, a general chatbot is not where you put a decision you personally have to answer for.\n\n[04](https://evanpurnama.com/what-ai-can-do/#who-it-helps)\n\n## Who it helps most\n\n![A high shelf on a wall holding a small jar. Below it a shorter person stands on a wooden crate and reaches the shelf, beside a taller person who reaches the same shelf standing flat on the floor](https://evanpurnama.com/what-ai-can-do/assets/img-05-shelf.jpg)\n\nThe crate moves one person. The shelf never gets any higher.\n\nThis is the part people discuss least, and in my view the part that matters most to you.\n\nA software company gave AI assistants to 5,172 of its customer support staff, and a full year of the resulting data was studied by economists at Stanford and MIT.[\\[2\\]](https://evanpurnama.com/what-ai-can-do/#ref-2)\n\nThe newest people, the ones who normally took longest to resolve a complaint, got about **36 percent faster**.\n\nThe most senior people, the ones who were already good, **barely changed at all**.\n\nNew staff with AI closed as many cases as staff who had been doing the job for months.\n\nSo if you already write a clean email, ChatGPT feels unremarkable. If you have been rewriting the same paragraph five times, it feels like magic. Both are honest reports, from two people standing in genuinely different places.\n\nBut there is something in that number that is easy to misread.\n\nThe study measured a task with a low ceiling: closing one customer complaint. However fast you get, one ticket is still one ticket. No wonder the people who were already good could not climb much higher there.\n\nOpen ended work is a different story.\n\nAI is very good at producing options and very bad at choosing between them. It will hand you ten versions in five minutes. Seeing that version seven is the right one, and the other nine are rubbish, takes somebody who already knows what good looks like.\n\nThat is exactly what an experienced person brings. The judgment and taste built up over years now come with a tool that produces ten options every time they ask.\n\nSo if you are senior and AI feels unremarkable, the most likely explanation is that you are still using it as a faster typist. The difference shows up when you move it somewhere else. Onto the work you keep postponing because it takes too long. Onto five versions of a strategy, built at once and compared side by side. Onto the dataset nobody ever had time to open. Onto the prototype that normally waits in another team's queue.\n\nThat is where the number goes far past 36 percent.\n\nSo both are true. The floor comes up for people starting out. The ceiling comes up too, for people who already have taste and are willing to change how they work.\n\n[05](https://evanpurnama.com/what-ai-can-do/#my-job)\n\n## “My job probably isn't affected”\n\n![A pocket watch lying open on a workbench with its back cover removed to show the movement, and three small gears lifted out and laid in a row beside it next to fine tweezers](https://evanpurnama.com/what-ai-can-do/assets/img-09-watch.jpg)\n\nIt looks like one object. It is twenty parts.\n\nThis is the most common reaction I hear, and it usually comes out almost word for word:\n\n_“My job isn't really affected. I'm not worried about it.”_\n\nI understand why. If your work is meeting people, negotiating, being on site, or running a team, there is no AI that replaces that. There still isn't.\n\nBut take your job apart first.\n\nAlmost no job is one thing. It is usually twenty things, and only two or three of them are what you are genuinely paid for. The rest is supporting work: reports, emails, meeting notes, summaries, documents, explaining things to other people.\n\nThe supporting work is what just got cheap. Look at any industry:\n\n-   **Restaurants.** Replying to reviews, building shift rosters, working out food cost, training material for new staff, menu descriptions.\n-   **Construction.** Daily site reports, vendor correspondence, tender documents, progress summaries, site meeting notes.\n-   **Clinics.** Referral letters, record summaries, patient education material, insurance claim paperwork.\n-   **Schools.** Exam questions, report card comments, lesson material, letters to parents.\n-   **Retail.** Product descriptions, replying to customer messages, weekly sales summaries.\n-   **Factories.** Standard operating procedures, production reports, incident write ups, audit paperwork.\n\nNone of those is an “AI job”. All of them contain a pile of reading, writing, tidying and checking.\n\nAnd that is the bigger picture. Every industry, without exception, runs on intelligence somewhere. Something has to be read and understood. Something has to be weighed and decided. Something has to be explained again to somebody else. All of that used to be expensive, because only trained people could do it, and trained people are in limited supply.\n\nMost of it can now be bought for the price of a monthly subscription.\n\nYour job is not necessarily going anywhere. What is more likely is that the person beside you doing the same work now has an extra hour every week. Or your junior, who used to need two years to reach your level, now needs one.\n\nSo if you feel safe, that is reasonable. Just check the reason again.\n\n[06](https://evanpurnama.com/what-ai-can-do/#why-nothing-changed)\n\n## If it is that good, why does nothing feel different?\n\n![A plain sealed pay envelope lying flat on a desk beside a large hourglass, with almost all the sand still in the upper bulb and only a thin layer collected at the bottom](https://evanpurnama.com/what-ai-can-do/assets/img-06-envelope.jpg)\n\nAbout an hour a week saved. The envelope has not changed.\n\nBecause the saving is small, and it disappears into the day.\n\nDenmark measured this carefully. 25,000 workers, in the eleven occupations that touch AI most, linked to official payroll records. On average they saved **2.8 percent of their time**, about an hour a week. Effect on pay and hours worked: zero.[\\[3\\]](https://evanpurnama.com/what-ai-can-do/#ref-3)\n\nAn hour a week is real. Nobody has ever been given a raise for an hour.\n\nMy guess at the reason is simple. Most of us use it for small self contained jobs. One email, one summary, one draft. The time saved gets absorbed straight back into meetings, notifications, and whatever else was already queued.\n\nNot a single step of the work actually gets removed. The weekly meeting still happens. The report is still produced in the same format, read by the same people, approved through the same chain. One thing changed: the report now gets finished faster.\n\nThe teams that genuinely feel a difference have usually done the more uncomfortable thing first, which is to sit down and ask which steps no longer need to exist. That is a political question rather than a technical one, and that is exactly why it gets asked so much less often.\n\n[07](https://evanpurnama.com/what-ai-can-do/#does-it-matter)\n\n## Does it actually matter?\n\n![The interior of an old factory: one electric motor bolted to the floor drives a belt up to a long overhead line shaft, which drives belts down to three separate machines](https://evanpurnama.com/what-ai-can-do/assets/img-07-lineshaft.jpg)\n\nNew power. Same old factory.\n\nFor this question I keep going back to one story from the history of electricity.\n\nIn 1882 Edison switched on his first commercial power station in New York. Seventeen years later, electric motors still drove **less than 5 percent** of the machinery in American factories.[\\[4\\]](https://evanpurnama.com/what-ai-can-do/#ref-4)\n\nThe problem was the factory. Back then a single enormous steam engine turned one long shaft running the length of the ceiling, and every machine on the floor hung off that shaft by a belt. Which meant every machine had to stand near the shaft, and the machines were ordered by where the shaft ran instead of by the order of the work.\n\nWhen electricity arrived, factories pulled out the steam engine and bolted a large electric motor into exactly the same spot. The shaft and the belts stayed hanging where they were. New power, same old factory, and almost no change in output.\n\nIt took about another twenty years for someone to notice that if every machine had its own motor, machines could go anywhere. The floor could be laid out around the order of the work. Walls could move. Roofs could open up, because there was no longer a shaft that had to hang from them.\n\nOnce factories were rearranged, the rate of productivity growth in American manufacturing more than doubled.\n\nForty years between that first power station and the numbers actually moving. Most of that time went on one thing: people fitting new machines into an old frame.\n\nMy view is that we are still at the pulling out the steam engine stage. AI gets used to speed up the steps that already exist, which is reasonable, because that is the easiest and least painful thing to do with it.\n\nSo my answer to “does it actually matter” is yes, slowly, and without a single big announcement. What changes first is usually small, until one day somebody rearranges their factory floor and the gap becomes visible.\n\nChatGPT opened to the public in November 2022. We are in year four.\n\n[08](https://evanpurnama.com/what-ai-can-do/#try-it)\n\n## Try it yourself this week\n\n![A tall stack of closed document folders on a desk, with a hand drawing one single folder halfway out of the middle of the stack and leaving a gap](https://evanpurnama.com/what-ai-can-do/assets/img-08-pickone.jpg)\n\nOne job, done properly.\n\nThe fastest way to stop guessing, and the thing I suggest to anyone who asks:\n\n**Pick one job you hate.** Something repetitive, time consuming, and not a big decision. Cleaning up data, summarising a long document, turning meeting notes into a task list, writing the first draft you keep putting off.\n\n**Give it material, not just an instruction.** Paste the actual document. Paste an example of output you think is good. Say who it is for and who will read it.\n\n**Do not stop at the first answer.** Say which part is weak and ask for a fix. Two or three rounds is normal, and the second round is usually where it starts looking good.\n\n**Check the output line by line, once, properly.** Numbers, names and dates especially. If something is off, you now know exactly where the limit is. If nothing is off, you know that too.\n\nDo that once, seriously, and you will have your own answer to the question in the title. It will be far more useful than anything crossing your feed this week, this article included.\n\n## References\n\n1.  [_GhostCite: A Large-Scale Analysis of Citation Validity in the Age of Large Language Models_](https://arxiv.org/abs/2602.06718). arXiv:2602.06718. Thirteen models prompted for 375,440 citations; of the 331,809 successfully extracted, 50.29 percent were invalid, ranging from 14 to 95 percent by model.\n2.  Brynjolfsson, E., Li, D., & Raymond, L. (2025). [_Generative AI at Work_](https://arxiv.org/abs/2304.11771). _Quarterly Journal of Economics_ 140(2), 889 to 942. Staggered rollout across 5,172 customer support agents; resolutions per hour rise 15.2 percent on average, roughly 36 percent for the lowest skill group, and close to zero for the highest.\n3.  Humlum, A., & Vestergaard, E. (April 2025). [_Large Language Models, Small Labor Market Effects_](https://bfi.uchicago.edu/working-paper/large-language-models-small-labor-market-effects/). Becker Friedman Institute Working Paper 2025-56. Two adoption surveys covering 11 exposed occupations, 25,000 workers and 7,000 workplaces in Denmark, linked to administrative payroll records. Average time savings 2.8 percent, with no significant effect on earnings or hours.\n4.  Devine, W. D., Jr. (June 1983). [_From Shafts to Wires: Historical Perspective on Electrification_](https://gwern.net/doc/economics/automation/1983-devine.pdf). _Journal of Economic History_ 43(2), 347 to 372. Electric motors were under 5 percent of factory mechanical drive capacity in 1899, 25 percent in 1909 and about 78 percent in 1929. Output per man-hour in US manufacturing grew 1.3 percent a year before 1919 and 3.1 percent after.\n"},{"id":"what-ai-can-do:id","slug":"what-ai-can-do","language":"id","title":"Memangnya AI Udah Bisa Ngapain Sih?","url":"https://evanpurnama.com/what-ai-can-do/id/","description":"Jawaban lugas untuk pertanyaan yang paling sering saya terima. Apa yang udah beneran bisa, apa yang masih sering salah, dan kenapa di kantormu belum kerasa apa-apa.","date":"3 August 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/what-ai-can-do.id.md","sha256":"c394f3d60e8b8f5643f1fc65313b8a3fac2505699b74fbe1af24777bd19e08ec","text":"Source: https://evanpurnama.com/what-ai-can-do/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# Memangnya AI Udah Bisa Ngapain Sih?\n\nJawaban lugas buat pertanyaan yang paling sering saya terima. Tanpa jargon, tanpa jualan.\n\n![Meja kayu dilihat dari atas, berisi tumpukan amplop yang belum dibuka di kiri, kontrak tebal bertanda pembatas kertas di tengah, dan buku besar terbuka berisi catatan tangan yang berantakan di kanan](https://evanpurnama.com/what-ai-can-do/assets/img-01-desk.jpg)\n\nTiga tumpukan yang biasanya menghabiskan satu sore penuh.\n\n⚠ **Catatan:** AI berkembang cepat. Kalau kamu baca ini 6 sampai 12 bulan setelah tanggal terbit di atas, sebagian isinya mungkin udah berubah. Cek sumber terbaru sebelum ambil keputusan.\n\nTulisan ini opini saya, dengan beberapa angka dari studi yang sumbernya saya cantumkan di bawah. Selebihnya pengamatan, dan kamu boleh nggak setuju.\n\nKamu punya 40 email yang belum dibalas. Kontrak 60 halaman yang harus diringkas sebelum rapat jam dua. Dan file Excel kiriman cabang yang nama kotanya ditulis dalam dua belas versi berbeda.\n\nKetiganya bisa beres hari ini, dalam dua puluh menit.\n\nHasil ketiganya juga bisa keliru, dan kamu nggak akan tahu kalau nggak dicek.\n\nItu jawaban jujurnya. Sisanya cuma contoh.\n\nSaya ngerti banyak yang udah bosan dengar soal AI. Isi timeline memang cuma dua macam: yang bilang semua pekerjaan bakal hilang tahun depan, dan yang bilang ini cuma autocomplete kemahalan.\n\nDua-duanya seru dibaca. Sayangnya nggak satu pun kepakai waktu kamu harus mutusin sesuatu Senin pagi.\n\nJadi saya coba tulis yang di tengah: apa yang udah beneran bisa dia kerjain, apa yang masih sering salah, dan kenapa di kantormu kemungkinan besar belum kerasa apa-apa.\n\n[01](https://evanpurnama.com/what-ai-can-do/id/#bisa-apa)\n\n## Yang udah beneran bisa\n\n![Dua baki dokumen kawat bersebelahan di meja. Baki kiri penuh kertas berserakan tidak beraturan, baki kanan berisi kertas yang sama tersusun rapi jadi satu tumpukan dengan penjepit di atasnya](https://evanpurnama.com/what-ai-can-do/assets/img-02-trays.jpg)\n\nSebagian besar pemakaian yang berguna bentuknya seperti ini.\n\nIni bukan daftar demo. Ini yang tiap hari beneran dilempar orang ke AI.\n\n**Membaca yang panjang.** Kontrak, laporan tahunan, notulen rapat tiga jam, tumpukan jawaban survei.\n\nYang bikin beda itu pertanyaannya. Bilang “tolong ringkas” dan hasilnya hampir selalu hambar. Yang kepakai itu pertanyaan spesifik. Pasal denda keterlambatan ada di bagian mana. Siapa yang janji apa. Angka mana yang berubah dari versi bulan lalu. Ada nggak klausul yang bikin repot kalau kita mau berhenti di tengah jalan.\n\n**Ngerapiin yang berantakan.** Notulen yang kamu ketik asal-asalan, jadi daftar tugas lengkap sama nama dan tenggatnya. Tiga ribu baris data yang formatnya campur aduk, jadi satu format. Rekaman jadi transkrip, transkrip jadi tema. Dua ratus keluhan pelanggan jadi sepuluh kelompok masalah.\n\nKerjaan model begini dulu makan satu sore penuh, dan nggak ada satu orang pun yang menikmatinya.\n\n**Draf pertama.** Proposal, email yang susah ditulis, balasan komplain, kerangka presentasi, deskripsi lowongan, materi training.\n\nHasilnya jarang bisa langsung dipakai, dan menurut saya jangan sampai langsung dipakai. Tapi yang paling makan waktu itu justru memulainya, melototin layar kosong. Dan justru itu yang hilang. Otak kita jauh lebih cepat benerin yang udah ada daripada mulai dari nol.\n\n**Menjelaskan ulang.** Tempel paragraf dari tim IT atau legal yang bikin kamu bingung, minta dijelaskan kayak ke orang yang nggak tahu apa-apa. Terus lanjutin satu pertanyaan lagi: kalau saya setuju sama ini, risikonya buat saya apa.\n\nIni pemakaian yang paling sering saya lihat, dan paling jarang diakui, soalnya nggak ada yang mau ngaku kurang paham isi dokumen yang dia tanda tangani sendiri.\n\n**Bahasa.** Terjemahan yang nggak kaku, dua arah, dan nadanya bisa diatur. Bahan yang sama bisa jadi email formal ke klien Tokyo dan caption santai buat Instagram. Buat yang kerjanya lintas negara, ini aja udah kerasa tiap hari.\n\n**Nemenin mikir.** Ini yang paling jarang disebut, dan menurut saya paling berharga. Kamu lagi mikirin satu keputusan, kamu tulis situasinya panjang-panjang, terus minta dia bikin daftar alasan kenapa rencana kamu bakal gagal.\n\nDia nggak dipakai buat memutuskan. Dia dipakai supaya kamu nemu titik lemahnya duluan, sebelum atasanmu yang nemu.\n\n[02](https://evanpurnama.com/what-ai-can-do/id/#kecewa)\n\n## Kenapa banyak yang nyoba terus kecewa\n\n![Seorang juru tulis muda berdiri di meja memegang selembar kertas kosong sambil menunggu, sementara dari tepi kanan sebuah tangan mendorong map tebal berisi dokumen rujukan ke arahnya](https://evanpurnama.com/what-ai-can-do/assets/img-03-clerk.jpg)\n\nDia nunggu bahan. Kebanyakan orang cuma ngasih perintah.\n\nKalau kamu pernah nyoba terus merasa biasa aja, saya hampir bisa nebak kejadiannya.\n\nBuka ChatGPT, ketik satu kalimat pendek, keluar jawaban yang kedengarannya rapi tapi kosong, terus ditutup sambil mikir, “yah, gini doang…”\n\nMasalahnya di cara kita memperlakukan dia. Kebanyakan orang pakai AI kayak mesin pencari: satu pertanyaan pendek, berharap satu jawaban benar. Padahal dia lebih mirip anak magang. Cepat, rajin, nggak kenal capek, dan baru masuk hari ini. Soal kantormu, dia nggak tahu apa-apa.\n\nKamu nggak akan nyuruh anak magang baru “bikinin proposal” terus hasilnya langsung dikirim ke klien. Pasti dikasih konteks dulu: contoh proposal yang dulu tembus, kliennya siapa, mereka pedulinya apa, formatnya yang biasa dipakai kantor. Terus dikoreksi dua kali.\n\nPerlakukan AI persis begitu dan hasilnya beda jauh. Tiga hal yang paling nentuin:\n\n-   **Bahan.** Tempel dokumen aslinya, contoh hasil yang menurutmu bagus, data mentahnya. Jangan ngarep dia bisa nebak isi kepalamu.\n-   **Konteks.** Buat siapa, yang baca siapa, nadanya gimana, panjangnya berapa, apa yang harus dihindari.\n-   **Putaran kedua.** Jawaban pertama itu bahan mentah. Bilang bagian mana yang kurang, minta diperbaiki. Dua sampai tiga putaran itu wajar.\n\nContoh gampangnya. “Bikinin email follow up ke klien” hampir pasti keluar email generik yang nggak kelihatan datang dari kamu. Sekarang bandingin sama ini: ini email terakhir dari kliennya, ini balasan saya dua minggu lalu, ini yang sebenarnya saya mau, tolong tulis follow up yang tetap sopan tapi jelas bahwa kami butuh keputusan minggu ini.\n\nAlat sama, waktu sama, hasilnya beda jauh.\n\nKelihatan sepele. Tapi jarak antara orang yang bilang AI biasa aja dan orang yang udah nggak mau balik ke cara lama, ya cuma di situ.\n\n[03](https://evanpurnama.com/what-ai-can-do/id/#salah)\n\n## Yang masih sering salah\n\n![Laci katalog kartu perpustakaan terbuka dengan sebuah tangan mengangkat satu kartu indeks kosong, dan di belakangnya rak buku dengan satu celah kosong yang mencolok di antara buku-bukunya](https://evanpurnama.com/what-ai-can-do/assets/img-04-catalogue.jpg)\n\nKartunya ada di laci. Bukunya nggak pernah ada di rak.\n\n**Angka dan sumber.** Ini yang paling bahaya, justru karena paling meyakinkan. Minta data atau referensi, dan dia sanggup ngarang lengkap dengan detailnya: judulnya masuk akal, nama penulisnya beneran ada, tahun terbitnya pas.\n\nSatu tim pernah nguji tiga belas model AI dengan minta ratusan ribu rujukan ilmiah. Separuhnya nggak pernah ada.[\\[1\\]](https://evanpurnama.com/what-ai-can-do/id/#ref-1) Papernya nggak pernah ditulis siapa pun.\n\nAturan saya: apa pun yang berupa angka, nama, tanggal, atau kutipan, anggap salah sampai kamu buka sendiri sumbernya.\n\n**Konteks kantormu.** Dia nggak tahu klien itu udah komplain dua kali bulan lalu. Nggak tahu orang yang kamu sebut lagi cuti. Nggak tahu kenapa proyek itu ditunda, apalagi bahwa alasannya politis dan sebaiknya nggak usah ditulis di mana-mana. Yang dia tahu cuma yang kamu kasih di kolom chat.\n\n**Dia setuju terus.** Ini yang paling jarang dibahas dan paling bikin repot. Bilang rencanamu bagus, dia ikut bilang bagus. Coba tanya sebaliknya, kenapa rencana ini bakal gagal, dan dia jawab dengan sama meyakinkannya.\n\nDia lebih jago nyenengin daripada menilai. Jadi jangan pakai dia sebagai juri. Pakai dia sebagai lawan debat yang kamu suruh nyerang.\n\n**Hal yang butuh tanggung jawab.** Udah ada produk AI khusus buat profesi tertentu, berbayar, dibikin perusahaan besar yang memang ahli di bidangnya. Waktu diuji pihak luar, produk sekelas itu pun masih salah di sebagian pertanyaan.\n\nKalau produk sespesifik itu aja masih meleset, keputusan yang risikonya kamu sendiri yang nanggung jelas belum pantas diserahkan ke chatbot umum.\n\n[04](https://evanpurnama.com/what-ai-can-do/id/#siapa)\n\n## Siapa yang paling kebantu\n\n![Rak tinggi di dinding berisi satu stoples kecil. Di bawahnya, orang yang lebih pendek berdiri di atas peti kayu dan bisa menjangkau rak itu, di samping orang yang lebih tinggi yang menjangkau rak yang sama sambil berdiri langsung di lantai](https://evanpurnama.com/what-ai-can-do/assets/img-05-shelf.jpg)\n\nPetinya mengubah posisi satu orang. Raknya sendiri nggak pernah naik.\n\nIni bagian yang paling jarang dibahas, dan menurut saya paling penting buat kamu.\n\nSatu perusahaan software masang asisten AI buat 5.172 agen customer service-nya. Data setahun penuh dari situ lalu dipelajari ekonom dari Stanford dan MIT.[\\[2\\]](https://evanpurnama.com/what-ai-can-do/id/#ref-2)\n\nOrang yang paling baru, yang biasanya paling lama nyelesain satu keluhan, jadi sekitar **36 persen lebih cepat**.\n\nOrang yang paling senior, yang memang udah jago, **hampir nggak berubah sama sekali**.\n\nKaryawan baru yang dibantu AI bisa nyelesaiin keluhan sebanyak karyawan yang udah berbulan-bulan di posisi itu.\n\nBuat saya masuk akal sih. Orang berpengalaman itu sebagian besar menguasai pola. Kalimat mana yang bisa bikin pelanggan yang lagi marah jadi adem. Urutan pengecekan mana yang paling cepat nemu sumber masalahnya. Kapan harus naikin ke atasan. Pola kayak gitu memang yang paling gampang dipelajari mesin. Yang susah ditiru justru hal yang nggak ada di catatan mana pun, kayak tahu bahwa klien ini sensitif soal harga gara-gara tahun lalu pernah kecewa.\n\nJadi kalau nulis email rapi itu gampang buat kamu, ChatGPT terasa biasa aja. Kalau tiap mau kirim satu email kamu masih hapus-tulis-hapus-tulis setengah jam, dia terasa ajaib. Dua-duanya jujur, cuma orangnya memang berdiri di titik yang beda.\n\nTapi ada satu hal dari angka itu yang gampang salah tangkap.\n\nYang diukur di studi tadi tugas yang batasnya udah jelas: nyelesein satu keluhan pelanggan. Secepat apa pun kamu, satu tiket tetap satu tiket. Wajar kalau orang yang udah jago nggak bisa naik banyak di situ.\n\nBeda ceritanya di kerjaan yang hasilnya bisa sebagus apa pun: nyusun strategi, bikin desain, ngerancang kampanye, nulis proposal.\n\nAI itu jago bikin banyak, dan payah milih mana yang bagus. Dia sanggup ngeluarin sepuluh versi dalam lima menit. Yang bisa lihat bahwa versi ketujuh itu yang bener, dan sembilan sisanya sampah, cuma orang yang emang udah punya ukuran sendiri soal mana yang bagus.\n\nDan itu persis modal orang yang udah jago. Dia udah punya judgment dan selera yang dibangun bertahun-tahun, dan sekarang alatnya sanggup ngasih dia sepuluh pilihan tiap kali dia minta.\n\nJadi kalau kamu udah senior dan AI terasa biasa aja, kemungkinan besar kamu masih memakainya sebagai tukang ketik yang lebih cepat. Selisihnya baru kelihatan kalau AI-nya dipakai buat hal lain. Buat kerjaan yang selama ini kamu tunda karena kelamaan. Buat bikin lima versi strategi sekaligus lalu dibandingin. Buat bongkar data yang nganggur bertahun-tahun karena nggak ada yang sempat buka. Buat prototipe yang biasanya harus antre dulu ke tim lain.\n\nDi situ angkanya bisa jauh di atas 36 persen.\n\nJadi dua-duanya benar. Orang yang baru mulai cepat jadi lumayan. Orang yang udah jago bisa naik jauh lebih tinggi lagi, asal mau ngubah cara kerjanya.\n\n[05](https://evanpurnama.com/what-ai-can-do/id/#kerjaan-gue)\n\n## “Kerjaan gue kayaknya nggak kepengaruh deh”\n\n![Jam saku terbuka di meja kerja dengan tutup belakang dilepas sehingga mesin roda giginya kelihatan, dan tiga roda gigi kecil sudah diangkat keluar berjajar rapi di sampingnya bersama sepasang pinset halus](https://evanpurnama.com/what-ai-can-do/assets/img-09-watch.jpg)\n\nKelihatannya satu benda. Isinya dua puluh bagian.\n\nIni reaksi yang paling sering saya dengar, dan kalimatnya biasanya persis begini:\n\n_“Kayaknya kerjaan gue nggak kepengaruh deh. Santai aja kali.”_\n\nSaya ngerti kenapa. Kalau kerjaanmu isinya ketemu orang, negosiasi, turun ke lapangan, atau ngurus tim, memang belum ada AI yang bisa gantiin itu. Sampai sekarang pun belum.\n\nTapi coba pecah dulu kerjaanmu jadi bagian-bagiannya.\n\nPekerjaan apa pun isinya hampir nggak pernah cuma satu kegiatan. Biasanya ada puluhan, dan cuma dua atau tiga yang beneran bikin kamu digaji. Sisanya penunjang: laporan, email, notulen, rekap, dokumen, penjelasan ke orang lain.\n\nDan sekarang biaya ngerjain bagian penunjang itu anjlok. Coba lihat, industri mana pun sama saja:\n\n-   **Restoran.** Balas review, susun jadwal shift, hitung food cost, bikin materi training pegawai baru, tulis deskripsi menu.\n-   **Konstruksi.** Laporan harian, korespondensi vendor, dokumen tender, rekap progres, notulen rapat lapangan.\n-   **Klinik.** Surat rujukan, ringkasan rekam medis, materi edukasi pasien, berkas klaim asuransi.\n-   **Sekolah.** Bikin soal, komentar rapor, materi ajar, surat ke orang tua murid.\n-   **Toko.** Deskripsi produk, balas chat pembeli, rekap penjualan mingguan.\n-   **Pabrik.** SOP, laporan produksi, laporan insiden, berkas audit.\n\nNggak satu pun dari itu “pekerjaan AI”. Tapi di semuanya ada setumpuk urusan baca, tulis, rapiin, dan cek.\n\nDan gambaran besarnya ada di situ. Di industri mana pun, selalu ada bagian yang butuh orang mikir. Ada yang harus dibaca sampai paham. Ada yang harus ditimbang sebelum diputuskan. Ada yang harus dijelaskan ulang ke orang lain dengan bahasa yang beda. Selama ini bagian itu mahal, karena cuma bisa dikerjakan orang terlatih, dan orang terlatih jumlahnya terbatas.\n\nSekarang sebagian besar kerjaan baca, tulis, dan rangkum itu bisa dibeli seharga langganan bulanan.\n\nKerjaanmu belum tentu hilang. Yang lebih mungkin terjadi, orang di sebelahmu yang ngerjain hal yang sama sekarang hemat satu jam tiap minggu. Atau juniormu, yang biasanya butuh dua tahun buat sampai ke levelmu, sekarang cuma butuh setahun.\n\nJadi kalau kamu merasa aman, itu masuk akal. Cuma coba cek lagi alasannya.\n\n[06](https://evanpurnama.com/what-ai-can-do/id/#belum-kerasa)\n\n## Kalau sebagus itu, kenapa belum kerasa?\n\n![Amplop gaji polos tersegel tergeletak di meja di samping jam pasir besar, dengan hampir seluruh pasir masih di tabung atas dan hanya lapisan tipis yang terkumpul di bawah](https://evanpurnama.com/what-ai-can-do/assets/img-06-envelope.jpg)\n\nSekitar satu jam seminggu yang dihemat. Amplopnya belum berubah.\n\nSoalnya waktu yang dihemat masih sedikit, dan langsung habis lagi di tengah hari kerja.\n\nDi Denmark, efeknya diukur dengan rapi. 25.000 pekerja, di sebelas jenis pekerjaan yang paling banyak bersentuhan dengan AI, datanya dicocokkan dengan catatan gaji resmi. Rata-rata mereka hemat **2,8 persen waktu**, sekitar satu jam seminggu. Pengaruhnya ke gaji dan jam kerja: nol.[\\[3\\]](https://evanpurnama.com/what-ai-can-do/id/#ref-3)\n\nSatu jam seminggu itu nyata. Tapi nggak ada orang yang naik gaji gara-gara satu jam.\n\nMenurut saya sebabnya sederhana. Kebanyakan dari kita cuma memakainya buat tugas kecil yang berdiri sendiri. Satu email, satu ringkasan, satu draf. Waktu yang dihemat langsung habis lagi buat rapat, buat notifikasi, buat kerjaan lain yang udah antre.\n\nNggak ada satu pun langkah kerja yang benar-benar dihapus. Rapat mingguannya tetap ada. Laporannya tetap dibikin dengan format yang sama, dibaca orang yang sama, disetujui lewat jalur yang sama. Yang berubah cuma satu: sekarang laporan itu lebih cepat jadi.\n\nTim yang beneran ngerasain bedanya biasanya udah melakukan hal yang lebih nggak enak, yaitu berani mempertanyakan langkah mana yang sebenarnya udah nggak perlu ada. Itu pertanyaan politis, dan itu sebabnya jarang banget ditanyakan.\n\n[07](https://evanpurnama.com/what-ai-can-do/id/#penting)\n\n## Emang penting banget?\n\n![Interior pabrik tua: satu motor listrik dibaut ke lantai menggerakkan sabuk ke atas menuju poros panjang di langit-langit, yang lalu menurunkan sabuk ke tiga mesin terpisah](https://evanpurnama.com/what-ai-can-do/assets/img-07-lineshaft.jpg)\n\nListriknya baru. Pabriknya masih pabrik yang lama.\n\nPertanyaan ini paling enak dijawab lewat satu cerita dari sejarah listrik.\n\nTahun 1882 Edison nyalain pembangkit listrik komersial pertamanya di New York. Tujuh belas tahun kemudian, motor listrik masih menggerakkan **kurang dari 5 persen** mesin di pabrik-pabrik Amerika.[\\[4\\]](https://evanpurnama.com/what-ai-can-do/id/#ref-4)\n\nMasalahnya ada di pabriknya. Waktu itu satu mesin uap raksasa memutar satu poros panjang di sepanjang langit-langit, dan semua mesin di lantai terhubung ke poros itu lewat sabuk. Semua mesin harus berdiri dekat poros, dan urutannya ngikutin letak poros alih-alih urutan pekerjaan.\n\nWaktu listrik masuk, pabrik nyabut mesin uapnya lalu masang motor listrik besar di posisi yang persis sama. Poros dan sabuknya dibiarkan menggantung seperti semula. Sumber tenaganya baru, pabriknya masih pabrik lama, dan hasilnya nyaris nggak berubah.\n\nButuh sekitar dua puluh tahun lagi sampai ada yang sadar bahwa kalau tiap mesin punya motor sendiri, mesinnya bisa ditaruh di mana aja. Lantai bisa ditata ngikutin urutan pekerjaan. Dinding bisa dipindah. Atap bisa dibuka, karena nggak ada lagi poros yang harus digantung di sana.\n\nSetelah pabrik ditata ulang, laju produktivitas manufaktur Amerika naik lebih dari dua kali lipat.\n\nButuh empat puluh tahun dari pembangkit pertama sampai produktivitasnya benar-benar naik. Sebagian besar waktu itu habis buat satu hal: orang masang mesin baru di kerangka lama.\n\nMenurut saya sekarang kita masih di tahap nyabut mesin uap. AI dipakai buat mempercepat langkah-langkah yang udah ada, dan itu wajar, karena itu yang paling gampang dan paling nggak nyakitin.\n\nJadi jawaban saya buat “emang penting banget”: penting, tapi dampaknya datang pelan, dan nggak lewat satu pengumuman besar. Yang berubah duluan biasanya hal-hal kecil, sampai suatu hari ada yang nata ulang lantai pabriknya, dan hasilnya baru kelihatan beda jauh.\n\nChatGPT dibuka buat umum November 2022. Kita baru masuk tahun keempat.\n\n[08](https://evanpurnama.com/what-ai-can-do/id/#coba)\n\n## Coba sendiri minggu ini\n\n![Tumpukan tinggi map dokumen tertutup di atas meja, dengan sebuah tangan menarik keluar satu map dari tengah tumpukan sehingga meninggalkan celah](https://evanpurnama.com/what-ai-can-do/assets/img-08-pickone.jpg)\n\nSatu tugas aja, dikerjain sungguhan.\n\nCara tercepat buat berhenti nebak-nebak itu nyoba sendiri. Ini yang selalu saya saranin ke siapa pun yang nanya.\n\n**Pilih satu tugas yang kamu benci.** Yang berulang, makan waktu, dan nggak butuh keputusan besar. Ngerapiin data, meringkas dokumen panjang, nyusun notulen jadi daftar tugas, bikin draf pertama yang selalu kamu tunda.\n\n**Kasih bahannya, jangan cuma perintahnya.** Tempel dokumen aslinya. Tempel contoh hasil yang menurutmu bagus. Sebutin siapa yang bakal baca, dan hasilnya mau dipakai buat apa.\n\n**Jangan berhenti di jawaban pertama.** Bilang bagian mana yang kurang, minta diperbaiki. Dua sampai tiga putaran itu wajar, dan biasanya baru di putaran kedua hasilnya kelihatan bagus.\n\n**Cek hasilnya baris per baris, sekali aja, sungguhan.** Terutama angka, nama, dan tanggal. Kalau ada yang meleset, kamu langsung tahu batasnya di mana. Kalau nggak ada yang meleset, kamu juga tahu.\n\nSekali aja lakuin itu dengan serius, dan kamu punya jawabanmu sendiri buat pertanyaan di judul. Jawaban itu bakal jauh lebih berguna daripada apa pun yang lewat di timeline minggu ini, termasuk tulisan ini.\n\n## Referensi\n\n1.  [_GhostCite: A Large-Scale Analysis of Citation Validity in the Age of Large Language Models_](https://arxiv.org/abs/2602.06718). arXiv:2602.06718. Tiga belas model diminta menghasilkan 375.440 sitasi; dari 331.809 yang berhasil diekstrak, 50,29 persen tidak valid, dengan rentang 14 sampai 95 persen antar model.\n2.  Brynjolfsson, E., Li, D., & Raymond, L. (2025). [_Generative AI at Work_](https://arxiv.org/abs/2304.11771). _Quarterly Journal of Economics_ 140(2), 889 sampai 942. Rollout bertahap ke 5.172 agen customer service; penyelesaian per jam naik 15,2 persen rata-rata, sekitar 36 persen untuk kelompok yang paling rendah keahliannya, dan mendekati nol untuk yang paling tinggi.\n3.  Humlum, A., & Vestergaard, E. (April 2025). [_Large Language Models, Small Labor Market Effects_](https://bfi.uchicago.edu/working-paper/large-language-models-small-labor-market-effects/). Becker Friedman Institute Working Paper 2025-56. Dua survei adopsi mencakup 11 pekerjaan terekspos, 25.000 pekerja dan 7.000 tempat kerja di Denmark, disambungkan ke catatan payroll administratif. Hemat waktu rata-rata 2,8 persen, tanpa efek signifikan pada pendapatan atau jam kerja.\n4.  Devine, W. D., Jr. (Juni 1983). [_From Shafts to Wires: Historical Perspective on Electrification_](https://gwern.net/doc/economics/automation/1983-devine.pdf). _Journal of Economic History_ 43(2), 347 sampai 372. Motor listrik menyumbang di bawah 5 persen kapasitas penggerak mesin pabrik pada 1899, 25 persen pada 1909, dan sekitar 78 persen pada 1929. Output per jam kerja di manufaktur Amerika tumbuh 1,3 persen per tahun sebelum 1919 dan 3,1 persen sesudahnya.\n"},{"id":"two-ai-comparison:en","slug":"two-ai-comparison","language":"en","title":"Old-School AI, Modern AI","url":"https://evanpurnama.com/two-ai-comparison/","description":"Two AI assistants, one channel, the same models. One was wired the way we wired these things two years ago. The gap was a generation of design, not the model.","date":"26 July 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/two-ai-comparison.en.md","sha256":"03d354e43933ec7aa808d80aa65e635aee7ea72308777c494ab813ad91aaa44f","text":"Source: https://evanpurnama.com/two-ai-comparison/\nAuthor: Evan Purnama\nLanguage: en\n\n# Old-School AI, Modern AI\n\nTwo assistants, one channel, the same models. One was built the way we built these things two years ago. Guess which one got switched off.\n\n![An antique clockwork robot bolted to a length of rail track, with a punched card feeding into its chest and a wind-up key in its back, standing beside a modern jointed robot on open floor](https://evanpurnama.com/two-ai-comparison/assets/img-01-hero.jpg)\n\nSame job, same channel. One of them was built to run on rails.\n\n⚠ **Note:** AI moves quickly. If you are reading this 6 to 12 months after the publication date above, some claims, figures, or market conditions may have changed. Check current sources before making decisions.\n\nDetails that would identify the company, product or vendor have been removed, and the message samples below are paraphrased and their figures are illustrative. The pattern is the part that transfers, and it can show up on any team.\n\nTL;DR\n\nTwo AI assistants ran in the same internal operations channel for one week. Both ran on an LLM, the same kind of model behind the chat assistants everyone has used. Both could do more than write: they could pull logs, query live systems and open tickets. Both were built by capable engineers. By Friday, one was writing incident reports a senior on-call engineer would have signed without edits. The other was switched off before the week ended. None of the gap came from the model. All of it came from four decisions made around the model: **what starts it, what context it gets before it speaks, how it signals doubt, and who makes the call on what it produces.** And this is not a case of one being slightly better. Wired badly, the thing is not merely less helpful. It adds work and spends down the trust of everyone in the channel.\n\nBoth assistants could read incoming requests, pull data, and post replies. By the end of the week one of them was doing the work of a senior on-call engineer: writing incident reports, diagnosing issues before they were reported, drafting the exact response an account manager would forward without editing. The other was taken out of the channel.\n\nSame channel. Same underlying models. Wildly different outcomes.\n\nOne half of that gap, the assistant that produces work-shaped output while leaving the work undone, is now a documented pattern rather than an anecdote. BetterUp Labs, working with Stanford Social Media Lab, surveyed 1,150 US full-time employees and found 40% had received AI-generated “workslop” in the previous month, defined as content that “masquerades as good work but lacks the substance to meaningfully advance a given task.” Each incident cost the receiver nearly two hours to untangle. Added up across an organisation of 10,000 people, the researchers put the annual bill above $9 million.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/#ref-1) Receivers also marked the _sender_ down: 54% saw the colleague as less creative, 42% as less trustworthy, and 37% as less intelligent.[\\[2\\]](https://evanpurnama.com/two-ai-comparison/#ref-2)\n\nThe most public version of the same mistake belongs to Klarna. In early 2024 the company said its assistant was handling two-thirds of all customer service chats, work it equated to 700 human agents. By May 2025 its CEO was publicly hiring human support staff again and telling Bloomberg that the cheaper AI-only route had produced “lower quality” work.[\\[3\\]](https://evanpurnama.com/two-ai-comparison/#ref-3)[\\[4\\]](https://evanpurnama.com/two-ai-comparison/#ref-4)\n\nThose four decisions are what I take apart below, one at a time.\n\n[01](https://evanpurnama.com/two-ai-comparison/#the-setup)\n\n## The setup\n\nPicture an internal escalation channel. An operations team drops incoming issues into it in a semi-structured template:\n\n**\\[Issue\\]\\[Type\\]\\[Priority\\]** From: customer / team / system Reference: ID Problem: something isn't behaving as expected Expected: …\n\nTwo AI assistants live in that channel. Both were built in good faith by people trying to solve the same problem, and neither one is fully autonomous. What separates them is _which half of the job_ each one automates.\n\n-   **The Old-School AI** is a purpose-built auto-investigator. It responds to every new post on its own, runs its fixed investigation sequence (pull the logs, guess the cause, draft a fix), and publishes what it finds. **Its autonomy sits in publishing.** Everything consequential after that still lands on a person: checking whether the finding holds, deciding what to do about it, and doing it.\n-   **The Modern AI** also acts without being asked, but on the other half of the job. It watches the same queue, investigates before anyone asks it to, and surfaces to a human at exactly one point: the moment something has to be chosen. There it posts what happened and what the options are. A person picks one, and the model does the legwork from there, with the result going out under that person's name. **Its autonomy sits in the finishing.** What the human contributes is judgement and accountability, and that takes minutes. Everything around those minutes is already done.\n\nOne thing to settle before we go on. Old-school here is not about the model. Both run on the same LLM, released in the same year, called through the same API. What is old-school is the way they were put together.\n\nIf one of them were a rule-based chatbot from 2019 there would be nothing to say. Both are current AI. One of them was just assembled with the habits of two years ago.\n\nThe irritating part is that in the channel it is the Old-School AI that looks industrious. Always acting, always posting. But the work stops there. Every post it makes leaves a human job behind it: verify, decide, do. The Modern AI posts about as often, and on some mornings more. The difference is that its posts take work off people's desks instead of adding to them.\n\n![An overflowing office in-tray of identical filing slips, with a robot head peering over each side](https://evanpurnama.com/two-ai-comparison/assets/img-02-setup.jpg)\n\nOne intake queue, two assistants, two completely different ideas of what the job is\n\nNeither is a fully autonomous agent, and neither should be yet. Trust in a system like this is earned in stages: a team hands over a larger share of the work only after the system proves it can carry the share it already has. Both are pitched at the stage every system passes through on the way to autonomy: real work done by the machine, the decision still held by a person. What separates them is the four decisions made around the model while they are there. The next section puts the two designs side by side, and the four after it take those decisions one at a time.\n\n[02](https://evanpurnama.com/two-ai-comparison/#the-table)\n\n## The two designs, side by side\n\nFrom the outside the two are identical. A chat box, a person typing, a bot replying. That is what makes them hard to compare, and what leads most people to shrug and say they are both AI, so they are much of a muchness.\n\nThe easiest way to see the gap is to measure both against a person who does this job well. A good one does not answer straight away. They read the conversation, form a hunch, check the data case by case, throw out the hunches that do not hold, and only then conclude. The Modern AI goes through the same steps. The Old-School AI jumps from a matched keyword to a filled template.\n\nSo the left column below is not a feature list. It is what a capable person does before they open their mouth. The four rows marked below carry most of the weight, and the four sections after this one take them in turn.\n\n![Two technical drawings pinned side by side: a dense clockwork mechanism of interlocking gears on the left, a single simple open loop on the right](https://evanpurnama.com/two-ai-comparison/assets/img-09-scale.jpg)\n\nEverything the fixed sequence produced on one side, the one note someone could act on on the other\n\nWhat a good person does\n\nOld-School AI\n\nModern AI\n\nStarts when something changes, not when its name is called · decision 1\n\nA keyword in a channel message. Its name appears, it runs\n\nA signal from the system itself: errors climbing, a queue filling, a new shape of failure\n\nReads the whole conversation before answering · decision 2\n\nEvery call starts from nothing. All it sees is the last message\n\nHas been reading the thread since the messages were written, long before anyone asked\n\nForms a hypothesis, tests it against data, drops it, repeats\n\nOne fixed pass: pull the logs, run the analysis prompt, fill the template, post\n\nForms a hypothesis, pulls data to test it, drops the ones that disagree, repeats until one survives\n\nChecks case by case instead of generalising from one\n\nConcludes from whichever ticket happened to be mentioned\n\nSweeps every affected case one by one, including the ones nobody reported\n\nSays so when not yet sure · decision 3\n\nPosts anyway. The confidence score is stapled to the last line\n\nKeeps working, or posts one line naming the data it still needs\n\nOnce a decision is made, carries it to the end · decision 4\n\nThe ticket changes hands. The work restarts from zero on someone's desk\n\nReplays the failed messages behind an anti-duplicate guard, re-runs what was skipped, adds a monitor for the failure class\n\nKnows when a message is not its job\n\nThe keyword matched, the pipeline ran, a ticket came out\n\nWords are not its trigger, so nothing happens\n\nTrust is built on a track record\n\nEvery empty post lowers trust in all of its posts. Out of the channel before Friday\n\nIts drafts go to customers unedited\n\nOne thing worth stating flatly, because it is the assumption that most often turns out wrong: putting an LLM in does not raise quality by itself. Wired badly, it lowers quality past zero.\n\nThe Old-School AI was not merely less useful. It manufactured work that did not exist before: tickets someone had to close, owners assigned wrongly and then corrected, follow-ups to undo its own actions. The expensive part is the trust. After a few reports that turn out to be empty, people stop reading the reports. Including the ones that happened to be right.\n\nThat team would have been better off never installing it.\n\n[03](https://evanpurnama.com/two-ai-comparison/#what-starts-it)\n\n## Decision 1: What actually starts it\n\nThe Old-School AI starts on a keyword match. Any post containing its name, and on bad days any post at all, kicks off the same fixed sequence, beginning with the same opening line:\n\nOld-School AI\n\nInvestigating, results will follow in this thread.\n\nAn identical duplicate of that message lands a few seconds later. Then, minutes after that, a full root-cause analysis of whatever it decided the message was about.\n\nThe clearest example came when someone in the channel was not reporting an incident at all. They were complaining about the bot: _can someone kick or kill this assistant, it's misfiring._ That sentence contained its name, so the sequence ran. The Old-School AI:\n\n1.  Posted its investigating acknowledgement.\n2.  Ran a full investigation.\n3.  Produced a formal explanation that “based on the thread, this is not an incident report but an internal request to disable the assistant, so there is no root cause to investigate.”\n4.  Opened a **fresh ticket** about the request to turn itself off, complete with a ticket ID and an assigned owner.\n\nSteps 3 and 4 contradict each other. In step 3 it understood perfectly well that the request was to switch it off. In step 4 it treated that request as a new piece of work and assigned it to a person anyway. Nothing in it was weighing those two against each other. A word matched, so the sequence ran to the end.\n\nA person would never do that. They know which messages are not their job.\n\nThe engineer's reply in that thread was one word: _removed._ The bot was out of the channel the same day. I do not blame the engineer.\n\nSo what does the Modern AI do when the same sentence arrives? For that sentence, nothing. Words are not its trigger, so there is no acknowledgement, no investigation and no ticket. But the story was over before the complaint got written. The complaint said the bot was misfiring, and the Modern AI watches the misfires themselves rather than what people write about them. If something really is failing repeatedly, it has already posted about it before anyone gets round to complaining.\n\n![A robot alone in an empty room slapping a service bell, duplicate paper slips flying, a hand reaching for its power switch](https://evanpurnama.com/two-ai-comparison/assets/img-03-bell.jpg)\n\nWithout a stop condition, a request to stop reads as one more task\n\nPrinciple\n\nA trigger that matches words will fire on things that are not events.\n\nA keyword has no way of knowing whether anything happened. It cannot tell an incident from a question about an incident, or from someone asking for the bot to be switched off. So the pipeline runs on all three, produces the same artefact for all three, and hands the results to people who then have to work out which ones were real. The assistant ends up creating work instead of taking it away: tickets nobody needed, owners assigned by mistake, follow-ups to undo the last action.\n\nMedicine has known this failure for decades under the name _alarm fatigue_: monitors that fire on thresholds rather than on events produce alerts that are mostly not actionable, clinicians stop reacting to them, and the whole thing is now tracked as a patient-safety hazard.[\\[5\\]](https://evanpurnama.com/two-ai-comparison/#ref-5) Security operations research documents the same effect: analysts in corporate security operations centres miss real intrusions when the genuine alert is buried among thousands of routine ones.[\\[6\\]](https://evanpurnama.com/two-ai-comparison/#ref-6) The mechanism transfers straight into a chat channel. When the trigger cannot tell an event from a non-event, neither can the reader, so they stop trusting any of it and eventually stop reading the assistant at all.\n\nThere's a productivity cost stacked on top of the attention cost. Gloria Mark's 2008 study of interrupted work found that interruptions, including ones relevant to the task at hand that workers describe as beneficial, impose a measurable tax in stress, frustration and perceived workload, and that people compensate by working faster under more pressure.[\\[7\\]](https://evanpurnama.com/two-ai-comparison/#ref-7) A trigger that fires on non-events charges that tax to every colleague in the channel and returns nothing for it.\n\nThe Modern AI is not started by being addressed at all. It is started by the situation changing: an error rate moving, a queue filling, a customer request failing in a way it has not failed before. It can post several times in a morning, and often does.\n\n[04](https://evanpurnama.com/two-ai-comparison/#context)\n\n## Decision 2: What context it has before it speaks\n\nLater that week, an operator asked the Old-School AI a question inside a thread with fourteen prior messages: _what's the conclusion here, is this expected behavior?_\n\nOld-School AI\n\nSorry, I don't have any context from the previous conversation. I'm just starting this session and can't see prior chat history.\n\nCould you re-explain: what conclusion, which issue, which expected behavior?\n\nThe thread it was replying inside contained the conclusion. Verbatim. Two messages above.\n\nA person asked that question scrolls up.\n\nA different colleague tried again in a separate thread: _TL;DR of this thread please._\n\nOld-School AI\n\nI don't see any threads in this conversation. This is the start of our chat.\n\nPlease explain in more detail: which thread do you mean?\n\n![A blindfolded robot holding a blank notepad, standing under a clothesline strung with pages of handwriting](https://evanpurnama.com/two-ai-comparison/assets/img-04-blindfold.jpg)\n\nThe context it needed was already in the thread, one scroll away\n\nPrinciple\n\nAn assistant that cannot see the thread it is replying in can answer the message, never the situation.\n\nFor anything that lives inside a chat surface, thread-awareness is table stakes. A follow-up answered with a request to re-explain costs the human twice, once to ask and once to re-paste, which is the reverse of what the assistant was installed to do.\n\nAgent-evaluation work makes the point concrete. Letta, a company that runs AI agents in production at scale, attributes roughly 90% of the agent failures it sees to context problems, meaning the agent was never shown what it needed, rather than to gaps in model capability.[\\[8\\]](https://evanpurnama.com/two-ai-comparison/#ref-8)[\\[9\\]](https://evanpurnama.com/two-ai-comparison/#ref-9) One production write-up puts it this way: the context window, which is the short-term memory a model holds during one conversation, is a whiteboard rather than a filing cabinet. It gets wiped between conversations, and anything not written down again is gone. That is why the assistant greeted a fourteen-message thread as the start of the chat.[\\[10\\]](https://evanpurnama.com/two-ai-comparison/#ref-10)\n\nAsk the Modern AI the same question and the answer comes back straight away, because it read those fourteen messages as they were written. What it adds is not a summary of the thread, which everyone in the thread already has. It adds the thing that is not in the thread: whether the same pattern is showing up anywhere else, and what changed just before it started.\n\n[05](https://evanpurnama.com/two-ai-comparison/#doubt)\n\n## Decision 3: How it signals doubt\n\nThe Old-School AI's output is formatted like it came out of a mature diagnostic system. Bold headers, a TL;DR section, evidence blocks, “root cause (plain language),” a proposed fix, even the name of the repository to patch. Impressive at a glance.\n\nRead to the bottom of one and the actual signal is this:\n\nOld-School AI · final line\n\n`[AUTO-FIX-FAILED]` Could not find a candidate fix that passed for this requirement (status: failed). Do not use the candidates above as-is.\n\nThe pipeline had returned nothing usable, and the four hundred words above that line were published anyway.\n\nAnother reply ended with its own confidence self-report:\n\nOld-School AI · final line\n\nConfidence: 33/100 (low), no tools used, answered from memory.\n\n“No tools used, answered from memory” means it looked at nothing. No logs, no data, no system state. The whole answer was pattern-matched from training, and it was dressed exactly like the answers built on evidence.\n\n![A tiny robot proudly presenting an enormous ornate gilded frame that contains nothing but blank paper](https://evanpurnama.com/two-ai-comparison/assets/img-05-frame.jpg)\n\nThe frame is finished to the same standard whether or not there is anything to put in it\n\nPrinciple\n\nFormat should track confidence.\n\nA person who is not sure puts the doubt in their first sentence. When an AI is guessing it has two options: stay quiet, or put the doubt first. One line is enough, as in “I don't have enough context, I need X and Y”. A low-confidence answer wrapped in high-confidence styling teaches the team to discount all of the AI's answers, including the good ones. A confidence note at the bottom arrives after the reader has already spent the attention. A note like that belongs at the top.\n\nThis is a calibration finding rather than a matter of taste. Xiong et al. showed across GPT-4, LLaMA-2 Chat and others that models asked to verbalise their own confidence are systematically overconfident, potentially imitating the human habit of _sounding_ certain.[\\[11\\]](https://evanpurnama.com/two-ai-comparison/#ref-11) A 2024 survey of confidence estimation in LLMs reaches the same conclusion: absent deliberate calibration, stated certainty and actual correctness diverge sharply.[\\[12\\]](https://evanpurnama.com/two-ai-comparison/#ref-12)\n\nThe damage shows up on the human side as selective scepticism. A qualitative trust study with 192 participants found that people who repeatedly meet authoritative-looking hallucinations do not lose faith across the board. They stop trusting the AI in exactly the situations where the stakes are highest.[\\[13\\]](https://evanpurnama.com/two-ai-comparison/#ref-13) The good answers get discounted along with the bad ones, and nobody files a complaint about it.\n\nGiven the same question with the same thin evidence, the Modern AI sends one line: what it does not have, and what it would need to answer properly. When the evidence is complete the answer is long. The length tracks how much it actually knows, which means the shape of the message tells you how far to trust it before you have read a word of it.\n\n[06](https://evanpurnama.com/two-ai-comparison/#who-decides)\n\n## Decision 4: Who makes the call\n\nThis is the part worth copying, and it is where the fourth decision shows up in practice. Read the three messages below and look for the gap between them and something a senior engineer would write. The gap is thin. Below are three shapes of message the Modern AI produced in the same channel, written by AI and sent out under a human's name. None of them depend on a stronger model. They depend on the model already holding the context when the moment arrived, on it presenting a decision rather than a status update, and on a person owning that decision and the name at the bottom.\n\nShape 1\n\n### Proactive diagnosis, before anyone asks\n\nBackground for this one: the company also runs a customer-facing assistant that handles order requests, including cancellations. It is neither of our two.\n\nThe team was about to start getting complaints. Before the first one landed, the Modern AI had already noticed something that should not appear at all, the warehouse refusing cancellation requests, a dozen in one morning where a normal morning has none. It traced the cause and put this in front of the person who owns the channel. It went out word for word:\n\n![A robot crouched in a crawlspace holding a lantern, finding a hairline crack in a pipe before it leaks into the room above](https://evanpurnama.com/two-ai-comparison/assets/img-06-lantern.jpg)\n\nFound under the floor, before anyone upstairs noticed a thing\n\nModern AI draft · sent by a human, unedited\n\n\\[Proactive\\] Your team is about to get complaints about cancelled orders arriving anyway. Here is why, before the first one lands.\n\nSome customers asked that order assistant to cancel an order. It understood them and sent the cancellation. The warehouse rejected it, because those orders had already been picked for packing. Our code only checked that the call went through, never what came back, so a rejection looked exactly like a success. The assistant told the customer “cancelled, you're all set.” The parcel is on its way.\n\nThe assistant itself is fine. It understood every request and sent every cancellation. Only orders already picked are affected, which is 14 today out of a few hundred cancellations.\n\nFor your team, safe to send as is: those 14 customers should be told the parcel is already on the way, and that they can refuse it at the door or return it free.\n\nOn us: the assistant will stop saying “cancelled” when the warehouse says no. It will say “too late to cancel, here is how to return it.” The fix goes live today, and I will confirm in this thread.\n\nWhy this is the shape of replacing human work:\n\n-   **Proactive.** Diagnosed before the report was filed.\n-   **Names the actual mechanism,** in words an engineer can act on and an account manager can still follow.\n-   **Separates what's working from what's broken,** which prevents overreaction.\n-   **Two audiences in one message:** a paragraph the operations team can send to those 14 customers unchanged, and a paragraph for whoever fixes the code.\n-   **Commits to a follow-up.** “The fix goes live today, and I will confirm in this thread” treats this as an owned task rather than a Q&A.\n\nShape 2\n\n### Owning a mistake in the AI's own voice\n\nOvernight, a code change the engineering team put live quietly stopped refunds from going out. The support team's first theory that morning was a spike in refund requests from customers. The Modern AI's draft to them, in full:\n\n![A robot in front of a toppled stack of crates, one hand raised in admission, a broom in the other, half the crates already restacked](https://evanpurnama.com/two-ai-comparison/assets/img-07-owning.jpg)\n\nHand up first, broom already in the other hand\n\nModern AI draft · sent by a human, unedited\n\nThis is our mistake, not a surge from customers.\n\nIn our system, a refund waiting its turn to go out and a refund that has already gone out sit at the same status: _processed_. Last night we added a safety rule so that nothing is ever refunded twice: skip anything marked processed. It was meant to skip the ones already sent. It skipped the ones still waiting as well.\n\nSo this morning, 320 customers who were promised a refund got nothing. No money was lost. The refunds just never went out.\n\nAlready done: all 320 have been released and are going out in batches.\n\nWhat to expect: those customers get their notification within the hour, and some will write in asking why it was late. That is this fix landing, not a new problem.\n\nOne more thing, and it is also on us. By 07:00 our system had already recorded that not one refund had gone out that morning, where a normal morning has dozens by then. That sat on a dashboard and told nobody, so we did not find out for another two hours. That condition now sends an alert.\n\nSorry for the morning we made for your team, and for the customers who waited.\n\nWhy this works where the Old-School AI would fail:\n\n-   **Owns the blame in plain language, in the first line.** No hedging, no “the system experienced an anomaly.”\n-   **Numbers instead of adjectives** everywhere they exist. 320, not “a large batch.” 07:00, not “earlier.”\n-   **Organised around what the reader has to do:** here is what lands in the next hour, here is what those customers will ask, here is what we are fixing. Not a chronological data dump.\n-   **Names the second-order miss.** The signal was there and was never turned into an alarm. That's what a senior engineer flags, and most AI output stops at the primary bug.\n-   **Ends with a real apology,** not “we apologise for any inconvenience.”\n\nShape 3\n\n### Same-day incident report\n\nThe company's payment provider had a brief outage. The Modern AI drafted the full post-incident report within hours. Reports like this normally arrive days later, once someone senior has cleared the time to reconstruct the timeline. I have more often been on the side that never cleared the time:\n\n![A robot on a stepladder mounting a new alarm bell on a wall beside a chart line with a single recovered dip](https://evanpurnama.com/two-ai-comparison/assets/img-08-alarm.jpg)\n\nThe dip is already flat again; the bell is for the next one\n\nModern AI draft · sent by a human, unedited\n\n-   **What broke:** our payment provider had an outage, confirmed on their own status page. For about 30 minutes, roughly half of all checkout attempts failed silently: their system accepted our requests and never answered, so customers watched a spinner while our error dashboards stayed green. We can only count those failures now, from the checkout data. Four things say it was them and not us: no failures before that window, no release on our side that day, every failure stopping the minute their status page went green, and nothing since.\n-   **Who it hit:** most customers simply tried again and got through. 47 did not, and left with a full basket and no order.\n-   **What we did:** we checked all 47 by hand. 31 came back on their own and completed the order anyway. The other 16 we emailed a link straight back to their basket: 12 used it, 3 replied that they had already bought elsewhere, and 1 needed a person and got one. **Nobody who still wanted their order was left waiting on us.**\n-   **Still needs a human:** those 3 who bought elsewhere are a retention problem, not a technical one. The list is with the retention team.\n-   **So next time is faster:** we added an alarm for “checkouts drop below normal for five minutes.” Until today we only alarmed on errors, and this outage never produced one. Last time we effectively found out when it was already over. Next time we will know within five minutes.\n\nWhat makes this the senior-engineer tier:\n\n-   **Evidence structure:** the conclusion first, then four independent signals that support it. Not “trust me.”\n-   **Distinguishes what needed action from what didn't.** 47 becomes 31, 12, 3 and 1, so the reader sees in one line how much work was actually left.\n-   **Names the residual honestly.** Three customers went and bought elsewhere, which no engineering fix recovers. Instead of leaving that out, the message hands it to the team that can still act on it.\n-   **Structural fix, not just a patch.** A new monitor for the failure _class_, not only for this incident. It is already thinking about the next one.\n\n[07](https://evanpurnama.com/two-ai-comparison/#lessons)\n\n## Lessons for anyone shipping AI into a workflow\n\n![A drafting table seen from above with brass dividers and a carefully hand-drawn closed loop diagram](https://evanpurnama.com/two-ai-comparison/assets/img-10-blueprint.jpg)\n\nThe loop is the product. The model is a component inside it.\n\n1.  **Trigger on events, not on words.** A keyword match cannot tell an incident from a question about one, so an assistant wired to a keyword will produce the same output for both and leave a human to sort them out. An assistant wired to the state of the system only starts when the state actually moves. It can post often and stay welcome, because every post came from something happening. The alarm-fatigue and interruption-cost literature exists because systems that fire on non-events reliably degrade the people they were built to help.[\\[6\\]](https://evanpurnama.com/two-ai-comparison/#ref-6)[\\[7\\]](https://evanpurnama.com/two-ai-comparison/#ref-7)\n2.  **If your AI can't see the thread it's in, don't put it in the thread.** A thread-blind assistant in chat is worse than a link to a form, because a form at least does not pretend to know anything about you. Letta's production data puts around 90% of agent failures on context rather than reasoning: the model has the capability; the plumbing around it never hands over what it needs.[\\[8\\]](https://evanpurnama.com/two-ai-comparison/#ref-8) At minimum, read the last twenty messages. Better, read the full thread plus any linked context.\n3.  **A tidy template can disguise the absence of analysis.** The Old-School AI had the structure without the finding, which is the workslop pattern exactly: content that looks like good work but does not help finish the task.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/#ref-1) The Modern AI produced prose and took over part of a senior engineer's work. Format is the final coat of paint. The reasoning underneath is the product. Optimising the template first is a tell that the substance isn't there yet, and receivers notice: they downgrade the sender's perceived competence even when nobody discloses that AI wrote it.[\\[2\\]](https://evanpurnama.com/two-ai-comparison/#ref-2)\n4.  **Confidence has to be visible before the content.** A long answer with “confidence: low” at the bottom is a trick rather than a caveat. If the model isn't sure, either don't answer or say so in the first line. Both the Xiong benchmark and the NAACL calibration survey document the same failure, where models verbalise high confidence on tasks their accuracy doesn't support.[\\[11\\]](https://evanpurnama.com/two-ai-comparison/#ref-11)[\\[12\\]](https://evanpurnama.com/two-ai-comparison/#ref-12) Users respond by silently discounting the assistant, but only after enough burns to form the pattern, and by then the deployment is already failing.[\\[13\\]](https://evanpurnama.com/two-ai-comparison/#ref-13)\n5.  **Human-in-the-loop beats fully-autonomous on high-stakes output, for now.** Of the two, the one doing more of a human's job is the one that kept a human at the decision. It works ahead, prepares the options, and executes whichever one is chosen. What stays with the human is the judgement call and the accountability. Autonomy in execution with human control at the decision point is where enterprise value sits right now. Flip it, so that the human does the legwork and the AI decides what to say, and you have built the Old-School AI. IBM frames the goal as the efficiency of automation “without sacrificing the precision, nuance and ethical reasoning of human oversight,”[\\[14\\]](https://evanpurnama.com/two-ai-comparison/#ref-14) and for high-risk systems the EU AI Act now requires that oversight by law.[\\[17\\]](https://evanpurnama.com/two-ai-comparison/#ref-17) Klarna is the most public demonstration of what taking the human out of that loop costs on high-stakes work.[\\[3\\]](https://evanpurnama.com/two-ai-comparison/#ref-3)[\\[4\\]](https://evanpurnama.com/two-ai-comparison/#ref-4)\n6.  **Measure whether a human actually used the AI's reply, not whether the AI produced one.** The Modern AI's messages get sent verbatim. The Old-School AI's messages get followed by “can we kill this?” Measure what share of its output goes out unedited. If output needs heavy editing before use, you haven't saved anyone time, you've added a review step. That's the workslop tax made concrete, at nearly two hours of receiver time per instance, and the sending team almost never sees the bill.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/#ref-1)[\\[15\\]](https://evanpurnama.com/two-ai-comparison/#ref-15)\n7.  **Ownership language matters.** The Modern AI says “this is a mistake on our side” and “we've already done X, next we'll do Y.” The Old-School AI says “root cause identified, no action needed on our side,” even when the root cause is itself. The AI that people end up trusting talks like a colleague who is answerable for the outcome, not like a diagnostic tool that emits reports. The workslop researchers name the two postures: _pilots_ steer the AI with judgement, framing and editing, while _passengers_ let it carry them and ship output their colleagues can immediately tell is hollow.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/#ref-1)[\\[16\\]](https://evanpurnama.com/two-ai-comparison/#ref-16)\n\n[08](https://evanpurnama.com/two-ai-comparison/#closing)\n\n## Closing\n\nThis comparison says almost nothing about model choice. Both assistants ran on the same models. The gap sits entirely in the product decisions made around the model:\n\n-   **What starts it,** a matched word or a changed situation.\n-   **What context** it gets before it speaks.\n-   **How it signals doubt.**\n-   **Who makes the call** on what it produces.\n\nUnderneath all four sits a simpler question, and it is the one that decides all four: what job the thing thinks it has. Answer machine, ticket bot, or colleague drafting on someone's behalf.\n\n![A human hand with a fine screwdriver calmly adjusting one dial inside the open back panel of a small robot's head](https://evanpurnama.com/two-ai-comparison/assets/img-11-dial.jpg)\n\nThe adjustment that mattered was never made to the model\n\nThe BetterUp and Stanford researchers frame workslop as a management failure rather than a model failure. It shows up where a blanket “just use AI” mandate lands on teams already stretched too thin, without training, without the authority to decide, and without clear norms for when and how.[\\[15\\]](https://evanpurnama.com/two-ai-comparison/#ref-15) The Old-School AI is what that mandate produces when nobody is asked to design the loop.\n\nThere is a more useful measure than whether you use AI: would your team be lighter or heavier if it were taken away tomorrow.\n\n“We use AI” is not a quality claim. Two teams on the same model produced a tool that was switched off and a tool that did a senior engineer's work, in the same channel, in the same week. What separated them was _the judgement of whoever designed the loop each one lives inside_, meaning everything around the model that decides when it runs, what it sees, and who signs off. Four decisions, and all four are copyable.\n\n**If you're shipping an assistant into a shared channel this quarter, the cheapest change available is to stop triggering it on words and start triggering it on events.** Everything else in the lessons above gets easier once the AI stops answering things that were never its job.\n\n## References\n\n1.  Niederhoffer, K., Rosen Kellerman, G., Lee, A., Liebscher, A., Rapuano, K., & Hancock, J. T. (22 Sep 2025). [_AI-Generated “Workslop” Is Destroying Productivity_](https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity). Harvard Business Review. Survey of 1,150 US full-time employees by BetterUp Labs in partnership with Stanford Social Media Lab.\n2.  Coverage of the same BetterUp / Stanford survey, reporting the sender-perception findings: [Yahoo Finance](https://finance.yahoo.com/news/companies-being-torn-apart-ai-180957270.html), Sep 2025.\n3.  Entrepreneur (May 2025). [_Klarna CEO Reverses Course By Hiring More Humans, Not AI_](https://www.entrepreneur.com/business-news/klarna-ceo-reverses-course-by-hiring-more-humans-not-ai/491396). Note: Klarna said its assistant did the work of 700 agents; the headcount reduction that followed came mainly through a hiring freeze and attrition, not mass layoffs.\n4.  Bigeye. [_Klarna's AI Customer Service Deployment (AI Autopsy 002)_](https://www.bigeye.com/blog/klarnas-ai-customer-service-deployment).\n5.  Sendelbach, S., & Funk, M. (2013). [_Alarm Fatigue: A Patient Safety Concern_](https://pubmed.ncbi.nlm.nih.gov/24153215/). AACN Advanced Critical Care.\n6.  Tariq, S., Baruwal Chhetri, M., Nepal, S., & Paris, C. (2025). [_Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities_](https://dl.acm.org/doi/10.1145/3723158). ACM Computing Surveys, vol. 57.\n7.  Mark, G., Gudith, D., & Klocke, U. (2008). [_The Cost of Interrupted Work: More Speed and Stress_](https://www.ics.uci.edu/~gmark/chi08-mark.pdf). CHI 2008.\n8.  Letta, _Context-Bench_ (Oct 2025), a benchmark for long-running agent context management. The ~90% figure comes from Letta's production data as reported by [AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/24/context-bench-letta-long-running-agent-context-management-benchmark), Apr 2026.\n9.  Teki, S. (Nov 2025). [_Context-Bench: A Benchmark for Evaluating Agentic Context Engineering_](https://www.sundeepteki.org/blog/context-bench-a-benchmark-for-evaluating-agentic-context-engineering).\n10.  Beam.ai. [_Your AI Agent's Context Window Is RAM, Not Storage_](https://beam.ai/agentic-insights/your-ai-agents-context-window-is-ram-not-storage-that-explains-most-production-failures).\n11.  Xiong, M., Hu, Z., Lu, X., Li, Y., Fu, J., He, J., & Hooi, B. (2024). [_Can LLMs Express Their Uncertainty? An Empirical Evaluation of Confidence Elicitation in LLMs_](https://arxiv.org/abs/2306.13063). ICLR 2024.\n12.  Geng, J., Cai, F., Wang, Y., et al. (2024). [_A Survey of Confidence Estimation and Calibration in Large Language Models_](https://aclanthology.org/2024.naacl-long.366.pdf). NAACL 2024.\n13.  Ryser, A., Allwein, F., & Schlippe, T. (2025). [_Calibrated Trust in Dealing with LLM Hallucinations: A Qualitative Study_](https://arxiv.org/abs/2512.09088). arXiv:2512.09088. N = 192.\n14.  IBM (2025). [_What Is Human-in-the-Loop (HITL)?_](https://www.ibm.com/think/topics/human-in-the-loop)\n15.  Niederhoffer, K., Robichaux, A., & Hancock, J. T. (16 Jan 2026). [_Why People Create AI “Workslop”, and How to Stop It_](https://hbr.org/2026/01/why-people-create-ai-workslop-and-how-to-stop-it). Harvard Business Review.\n16.  Cognitive Bleed (Sep 2025). [_AI Research Brief: The Workslop Trap_](https://cognitivebleed.substack.com/p/ai-research-brief-the-workslop-trap), on Niederhoffer et al.\n17.  European Union. [_AI Act, Article 14: Human Oversight_](https://artificialintelligenceact.eu/article/14/).\n"},{"id":"two-ai-comparison:id","slug":"two-ai-comparison","language":"id","title":"AI Jadul, AI Zaman Now","url":"https://evanpurnama.com/two-ai-comparison/id/","description":"Dua AI assistant, satu channel, model yang sama. Satu dirakit dengan cara kita merakit hal semacam ini dua tahun lalu. Jaraknya satu generasi desain, bukan modelnya.","date":"26 July 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/two-ai-comparison.id.md","sha256":"0bcf47620e0622f8ea7b51eacf2333f1cffb5d0ed1fa1f59309bc14ff208c47a","text":"Source: https://evanpurnama.com/two-ai-comparison/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# AI Jadul, AI Zaman Now\n\nDua assistant, satu channel, model yang sama. Satu dibangun dengan cara kita membangun hal semacam ini dua tahun lalu. Tebak yang mana yang dimatikan.\n\n![Robot mekanik kuno yang dibaut ke potongan rel, dengan kartu berlubang masuk ke dadanya dan kunci putar di punggungnya, berdiri di samping robot modern berpersendian yang berdiri bebas](https://evanpurnama.com/two-ai-comparison/assets/img-01-hero.jpg)\n\nPekerjaan sama, channel sama. Satu di antaranya memang dibangun untuk berjalan di atas rel.\n\n⚠ **Catatan:** AI berkembang cepat. Jika Anda membaca artikel ini 6 sampai 12 bulan setelah tanggal terbit di atas, sebagian klaim, angka, atau kondisi pasar mungkin sudah berubah. Cek sumber terbaru sebelum mengambil keputusan.\n\nDetail yang bisa mengidentifikasi perusahaan, produk, atau vendor sudah dihapus, dan semua contoh pesan di bawah ditulis ulang, dengan angka yang sifatnya ilustratif. Yang penting di sini polanya, karena pola yang sama bisa muncul di tim mana pun.\n\nTL;DR\n\nDua AI assistant berjalan di satu channel operasional internal selama seminggu. Sama-sama dibangun di atas LLM, model yang juga ada di balik chatbot yang Anda pakai sehari-hari, dan sama-sama bisa lebih dari sekadar menulis: tarik log, tanya sistem yang sedang jalan, buka tiket. Engineer di belakangnya sama-sama mumpuni. Di akhir minggu, satu menulis incident report yang layak ditandatangani senior engineer tanpa revisi. Satu lagi dimatikan sebelum minggu itu berakhir. Perbedaan sejauh itu bukan dari modelnya. Empat keputusan desain di sekelilingnya yang menentukan: **apa yang memicunya, konteks apa yang dia terima sebelum bicara, bagaimana dia menunjukkan keraguan, dan siapa yang memutuskan tindak lanjut dari hasilnya.** Dan ini bukan soal yang satu lebih bagus sedikit. Yang dirakit keliru bukan cuma kurang menolong. Dia menambah kerjaan dan menghabiskan kepercayaan orang di channel itu.\n\nDi atas kertas keduanya setara: baca laporan yang masuk, tarik data, posting balasan. Di akhir minggu, satu di antaranya sudah mengerjakan sebagian tugas senior engineer yang piket: incident report, diagnosis sebelum ada yang lapor, balasan yang diteruskan account manager ke customer tanpa diedit satu kata pun. Satu lagi di-kick dari channel.\n\nChannel sama, model sama. Yang beda nasibnya.\n\nIni bukan cerita satu kantor. BetterUp Labs, bersama Stanford Social Media Lab, mensurvei 1.150 karyawan penuh waktu di Amerika Serikat dan menemukan 40% pernah menerima “workslop” buatan AI dalam sebulan terakhir, yaitu konten yang “tampak seperti hasil kerja bagus, tetapi tidak membantu menuntaskan tugasnya”. Setiap kiriman semacam itu menghabiskan hampir dua jam waktu penerimanya. Kalau dijumlahkan untuk organisasi berisi 10.000 orang, peneliti menaksir kerugiannya di atas $9 juta setahun.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-1) Penilaian penerima terhadap _pengirimnya_ juga merosot: 54% menganggap rekan itu jadi kurang kreatif, 42% kurang bisa dipercaya, dan 37% kurang cerdas.[\\[2\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-2)\n\nContoh paling terkenal dalam skala perusahaan adalah Klarna, perusahaan pembayaran asal Swedia. Awal 2024 perusahaan itu menyatakan AI assistant-nya menangani dua pertiga dari seluruh percakapan customer service, setara pekerjaan 700 staf. Mei 2025, CEO-nya kembali merekrut staf support manusia dan mengatakan ke Bloomberg bahwa strategi yang hanya mengandalkan AI demi menekan biaya itu justru menurunkan kualitas.[\\[3\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-3)[\\[4\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-4)\n\nEmpat keputusan itu yang saya bongkar satu per satu di bawah.\n\n[01](https://evanpurnama.com/two-ai-comparison/id/#situasi)\n\n## Situasinya\n\nBayangkan sebuah channel eskalasi internal. Setiap isu yang masuk disalurkan tim operasional ke channel itu lewat template setengah terstruktur. Ada dua pihak yang bertemu di sana: tim engineering yang memelihara sistemnya, yang di contoh-contoh nanti menyebut dirinya “kami”, dan tim yang berhadapan langsung dengan customer, yang disapa “Anda”.\n\n**\\[Isu\\]\\[Tipe\\]\\[Prioritas\\]** Dari: customer / tim / sistem Referensi: ID Masalah: ada yang tidak berjalan sesuai harapan Harusnya: …\n\nAda dua AI assistant yang tinggal di channel itu. Keduanya dibangun dengan niat baik oleh orang yang sedang menyelesaikan masalah yang sama, dan tidak satu pun sepenuhnya otonom. Bedanya cuma satu: _bagian mana_ dari pekerjaan itu yang diserahkan ke mesin.\n\n-   **AI Jadul** adalah auto-investigator yang dibangun khusus. Dia membalas sendiri setiap postingan baru, menjalankan urutan investigasi yang sudah dipatok (tarik log, tebak penyebab, susun draf perbaikan), lalu mempublikasikan temuannya. **Otonominya ada di bagian menerbitkan.** Semua langkah penting sesudah itu tetap harus dikerjakan manusia: memeriksa apakah temuannya benar, memutuskan tindakannya, lalu mengerjakannya.\n-   **AI Zaman Now** juga tidak menunggu diminta. Dia terus menjalankan loop-nya dan menggarap antrean sebelum ada yang meminta: kumpulkan konteks, jalankan pemeriksaan, siapkan opsi yang benar-benar bisa dipilih. Manusia baru dia sapa di satu titik: pilih salah satu opsi, atau beri arahan lain. Setelah keputusannya diambil, dia yang menjalankan seluruh tindak lanjutnya sampai selesai. **Otonominya ada di bagian menuntaskan.** Manusia tinggal menyumbang pertimbangan dan memikul tanggung jawab di titik keputusan. Beban kerjanya kecil, bobot keputusannya tetap besar.\n\nSebelum lanjut, satu hal yang perlu diluruskan. Jadul di sini bukan soal modelnya. Dua-duanya jalan di atas LLM yang sama, dirilis di tahun yang sama, dipanggil lewat API yang sama. Yang jadul cara merakitnya.\n\nKalau yang satu chatbot rule-based tahun 2019, tidak ada yang perlu ditulis. Keduanya AI zaman sekarang. Cuma satu di antaranya dirakit dengan kebiasaan dua tahun lalu.\n\nYang menyebalkan, di channel itu justru AI Jadul yang kelihatan paling rajin. Terus bergerak, terus memposting. Tapi pekerjaannya berhenti di situ. Setiap postingannya meninggalkan satu tugas untuk orang: memeriksa, memutuskan, lalu mengerjakan. AI Zaman Now bisa memposting sama seringnya, dan di pagi tertentu malah lebih sering. Bedanya, tiap postingannya mengangkat pekerjaan dari meja orang.\n\n![Baki dokumen kantor yang meluap penuh lembar isian identik, dengan kepala robot mengintip dari kedua sisinya](https://evanpurnama.com/two-ai-comparison/assets/img-02-setup.jpg)\n\nSatu antrean masuk, dua assistant, dua pemahaman yang sama sekali berbeda soal apa pekerjaannya\n\nTidak satu pun dari keduanya berupa agent otonom penuh, yaitu AI yang bekerja dari awal sampai akhir tanpa persetujuan manusia, dan memang belum saatnya. Kepercayaan pada sistem seperti ini dibangun bertahap: porsi yang lebih besar baru diserahkan tim setelah sistemnya terbukti sanggup memikul porsi yang sudah dipegangnya. Keduanya berada di tahap yang dilewati setiap sistem dalam perjalanan menuju otonomi: pekerjaan nyata dikerjakan mesin, keputusannya masih dipegang orang. Perbedaannya ada di empat keputusan yang diambil di sekeliling model pada tahap itu. Bagian berikutnya menyandingkan kedua desainnya, lalu empat bagian setelahnya membahas keputusan itu satu per satu.\n\n[02](https://evanpurnama.com/two-ai-comparison/id/#tabel)\n\n## Dua desain, berdampingan\n\nDari luar keduanya kelihatan sama persis. Kotak chat, orang mengetik, bot membalas. Itu yang bikin perbandingannya susah, dan bikin banyak orang menyimpulkan sudahlah, dua-duanya AI, sama saja.\n\nCara paling gampang melihat bedanya: bandingkan keduanya dengan orang yang biasa mengerjakan pekerjaan itu. Orang yang cakap tidak langsung menjawab. Dia baca dulu percakapannya, bikin dugaan, cek datanya satu per satu, buang dugaan yang tidak cocok, baru menyimpulkan. AI Zaman Now melewati langkah yang sama. AI Jadul melompat dari kata kunci langsung ke template.\n\nJadi kolom kiri di tabel ini bukan daftar fitur. Itu daftar hal yang orang cakap kerjakan sebelum dia buka mulut. Empat baris yang saya tandai paling menentukan, dan empat bagian setelah ini membahasnya bergantian.\n\n![Dua gambar teknik yang dipasang berdampingan: mekanisme jam penuh roda gigi yang rapat di kiri, satu loop terbuka yang sederhana di kanan](https://evanpurnama.com/two-ai-comparison/assets/img-09-scale.jpg)\n\nSemua keluaran urutan yang dipatok di satu sisi, satu catatan yang bisa langsung ditindaklanjuti di sisi lainnya\n\nYang dilakukan orang yang cakap\n\nAI Jadul\n\nAI Zaman Now\n\nMulai kerja waktu ada yang berubah, bukan waktu namanya dipanggil · keputusan 1\n\nKata kunci di pesan channel. Namanya muncul, dia jalan\n\nSinyal dari sistemnya sendiri: error yang naik, antrean yang menumpuk, kegagalan berpola baru\n\nBaca dulu seluruh percakapannya sebelum menjawab · keputusan 2\n\nSetiap panggilan mulai dari nol. Yang dia lihat cuma pesan terakhir\n\nSudah ikut membaca thread sejak pesannya ditulis, jauh sebelum ada yang bertanya\n\nBikin dugaan, cek ke data, buang kalau tidak cocok, ulangi\n\nSatu lintasan yang sudah dipatok: tarik log, jalankan prompt analisis, isi template, posting\n\nMenyusun dugaan, menariknya ke data untuk diuji, membuang yang tidak cocok, mengulang sampai ada yang bertahan\n\nCek satu per satu, jangan menyimpulkan dari satu contoh\n\nMenyimpulkan dari tiket yang kebetulan disebut di pesan tadi\n\nMenyisir seluruh yang terdampak satu per satu, termasuk yang tidak melapor\n\nKalau belum yakin, bilang belum yakin · keputusan 3\n\nTetap posting. Nilai keyakinannya ditempel di baris terakhir\n\nTerus mencari, atau posting satu baris berisi data apa yang masih dia butuhkan\n\nSesudah diputuskan, kerjakan sampai tuntas · keputusan 4\n\nTiketnya berpindah tangan. Pekerjaannya mulai dari nol lagi di meja orang\n\nMemutar ulang pesan yang gagal dengan pengaman anti-duplikat, menjalankan ulang yang terlewat, memasang monitor untuk kelas kegagalannya\n\nTahu kapan sebuah pesan bukan pekerjaannya\n\nKata kuncinya cocok, pipeline-nya jalan, tiketnya terbit\n\nKalimat bukan pemicunya, jadi dia tidak bergerak sama sekali\n\nKepercayaan dibangun dari rekam jejak\n\nTiap postingan kosong menurunkan kepercayaan pada semua postingannya. Keluar dari channel sebelum Jumat\n\nDrafnya dikirim ke customer tanpa diedit\n\nSatu hal yang perlu ditegaskan, karena ini yang paling sering meleset: memakai LLM tidak otomatis menaikkan kualitas. Dirakit dengan cara yang keliru, LLM justru menurunkannya sampai di bawah titik nol.\n\nAI Jadul bukan sekadar kurang berguna. Dia menambah pekerjaan yang tadinya tidak ada: tiket yang harus ditutup orang, penanggung jawab yang salah tunjuk dan harus dibetulkan, follow-up untuk membatalkan aksinya sendiri. Yang paling mahal, dia menghabiskan kepercayaan. Setelah beberapa kali menerima laporan yang isinya kosong, orang berhenti membaca laporannya. Termasuk yang kebetulan benar.\n\nKalau tim itu tidak pernah memasang AI Jadul sama sekali, keadaan mereka akan lebih baik.\n\n[03](https://evanpurnama.com/two-ai-comparison/id/#pemicu)\n\n## Keputusan 1: Apa yang sebenarnya memicunya\n\nAI Jadul dipicu oleh kecocokan kata kunci. Postingan apa pun yang memuat namanya, dan pada hari-hari buruk postingan apa pun di channel itu, menjalankan urutan yang sama, dimulai dari kalimat pembuka yang sama:\n\nAI Jadul\n\nSedang diinvestigasi, hasilnya akan menyusul di thread ini.\n\nBeberapa detik kemudian pemicunya menembak dua kali, dan pesan yang sama persis masuk sekali lagi. Beberapa menit setelahnya, muncul root-cause analysis lengkap tentang apa pun yang dia kira sedang dibahas.\n\nContoh paling jelas muncul ketika seseorang di channel itu sama sekali tidak sedang melaporkan insiden. Dia sedang mengeluhkan bot-nya: _ini assistant-nya bisa di-kick atau dimatikan tidak, dia error terus._ Kalimat itu memuat namanya, jadi urutannya jalan. AI Jadul lalu:\n\n1.  Memposting notifikasi “sedang diinvestigasi”.\n2.  Menjalankan investigasi penuh.\n3.  Mengeluarkan penjelasan formal bahwa “berdasarkan thread ini, yang dibahas bukan laporan insiden melainkan permintaan internal untuk menonaktifkan assistant, sehingga tidak ada root cause yang perlu diinvestigasi”.\n4.  Membuka **tiket baru** untuk permintaan mematikan dirinya sendiri, lengkap dengan nomor tiket dan penanggung jawab.\n\nLangkah 3 dan 4 saling bertentangan. Di langkah 3 dia sudah paham betul bahwa yang diminta adalah mematikan dirinya sendiri. Di langkah 4 dia tetap memperlakukan permintaan itu sebagai pekerjaan baru, lalu menugaskannya ke orang. Tidak ada bagian dari dirinya yang menimbang keduanya. Ada kata yang cocok, jadi urutannya jalan sampai habis.\n\nOrang tidak akan pernah melakukan itu. Dia tahu kalimat mana yang bukan pekerjaannya.\n\nBalasan engineer di thread itu cuma satu kata: _removed._ Hari itu juga bot-nya keluar dari channel. Saya tidak menyalahkan engineer-nya.\n\nAI Zaman Now tidak akan tersentuh kalimat itu. Kata memang bukan pemicunya. Yang menarik terjadi sebelumnya: keluhan tadi berbunyi “dia error terus”, padahal AI Zaman Now memantau error-nya sendiri. Kalau ada yang gagal berulang, dia sudah posting duluan, sebelum ada yang sempat mengeluh.\n\n![Robot sendirian di ruangan kosong menabuh bel meja, kertas duplikat beterbangan, sebuah tangan meraih saklar di punggungnya](https://evanpurnama.com/two-ai-comparison/assets/img-03-bell.jpg)\n\nTanpa kondisi berhenti, permintaan untuk berhenti terbaca sebagai satu tugas lagi\n\nPrinsip\n\nPemicu yang mencocokkan kata akan berbunyi untuk hal yang bukan kejadian.\n\nKata kunci tidak punya cara untuk tahu apakah ada sesuatu yang benar-benar terjadi. Dia tidak bisa membedakan insiden, pertanyaan tentang insiden, dan permintaan mematikan bot itu sendiri. Jadi pipeline-nya berjalan untuk ketiganya, menghasilkan laporan yang sama untuk ketiganya, lalu menyerahkannya ke orang yang kemudian harus memilah mana yang nyata. Assistant-nya berakhir menambah pekerjaan: membuat tiket yang tidak dibutuhkan siapa pun, menunjuk penanggung jawab yang keliru, dan memaksa orang melakukan follow-up untuk membatalkan aksi terakhirnya.\n\nDunia medis sudah mengenal kegagalan ini puluhan tahun lalu dengan nama _alarm fatigue_: monitor yang berbunyi berdasarkan ambang angka, bukan berdasarkan kejadian, menghasilkan alert yang mayoritas tidak perlu ditindaklanjuti, tenaga klinisnya berhenti bereaksi, dan sekarang hal itu tercatat sebagai risiko keselamatan pasien.[\\[5\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-5) Riset di dunia security operations menemukan efek yang sama: analis di pusat pemantauan keamanan (SOC) melewatkan serangan yang nyata karena alert pentingnya terkubur di antara ribuan alert rutin.[\\[6\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-6) Mekanisme yang sama berlaku di channel chat. Kalau pemicunya tidak bisa membedakan kejadian dari yang bukan kejadian, pembacanya juga tidak bisa, jadi dia berhenti memercayai semuanya.\n\nDi atas biaya perhatian itu, ada biaya produktivitas. Studi Gloria Mark dkk. pada 2008 menemukan bahwa interupsi, termasuk yang masih relevan dengan pekerjaan dan biasanya dianggap membantu, terbukti menambah stres, frustrasi, dan beban kerja secara terukur, dan orang mengompensasinya dengan bekerja lebih cepat di bawah tekanan yang lebih besar.[\\[7\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-7) Pemicu yang berbunyi untuk hal yang bukan kejadian menguras perhatian semua rekan kerja di channel itu dan tidak mengembalikan apa pun.\n\nAI Zaman Now sama sekali tidak dipicu oleh disebut namanya. Dia dipicu oleh keadaan yang berubah: tingkat error yang bergerak, antrean yang menumpuk, permintaan customer yang gagal dengan cara yang belum pernah terjadi. Dia bisa memposting beberapa kali dalam satu pagi, dan memang sering.\n\n[04](https://evanpurnama.com/two-ai-comparison/id/#konteks)\n\n## Keputusan 2: Konteks apa yang dia punya sebelum bicara\n\nBeberapa hari kemudian, seorang operator bertanya ke AI Jadul di dalam thread yang sudah berisi empat belas pesan sebelumnya: _kesimpulannya apa, ini memang expected behavior?_\n\nAI Jadul\n\nMaaf, saya tidak punya konteks dari percakapan sebelumnya. Saya baru memulai sesi ini dan tidak bisa melihat riwayat chat sebelumnya.\n\nBisa dijelaskan ulang: kesimpulan yang mana, isu yang mana, expected behavior yang mana?\n\nThread tempat dia membalas berisi kesimpulan itu. Persis kalimatnya. Dua pesan di atasnya.\n\nOrang yang ditanya begitu akan menggulir ke atas dulu.\n\nRekan lain mencoba lagi di thread terpisah: _tolong TL;DR thread ini._\n\nAI Jadul\n\nSaya tidak melihat thread apa pun di percakapan ini. Ini awal dari chat kita.\n\nMohon dijelaskan lebih detail: thread yang mana yang Anda maksud?\n\n![Robot bermata tertutup memegang notes kosong, berdiri di bawah jemuran berisi lembaran tulisan tangan](https://evanpurnama.com/two-ai-comparison/assets/img-04-blindfold.jpg)\n\nKonteks yang dia butuhkan sudah ada di thread itu, tinggal digulir sedikit\n\nPrinsip\n\nAssistant yang tidak bisa melihat thread tempat dia membalas hanya mampu menanggapi satu pesan, tanpa pernah memahami situasinya.\n\nUntuk assistant yang bekerja di dalam chat, kemampuan membaca thread adalah syarat minimum. Kalau pertanyaan lanjutan dibalas dengan permintaan menjelaskan ulang, orangnya membuang waktu dua kali: sekali untuk bertanya, sekali lagi untuk mengirim ulang konteksnya. Itu kebalikan dari alasan assistant itu dipasang.\n\nRiset evaluasi agent membuat hal ini konkret. Letta, perusahaan yang menjalankan AI agent di produksi dalam skala besar, mengaitkan sekitar 90% kegagalan agent yang mereka temui dengan masalah konteks, bukan dengan keterbatasan model: agent-nya memang tidak pernah diberi apa yang dia butuhkan.[\\[8\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-8)[\\[9\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-9) Satu tulisan dari praktik produksi merumuskannya begini: ingatan kerja model, yang disebut context window, itu papan tulis, bukan lemari arsip. Begitu percakapan baru dimulai, papannya terhapus, dan apa pun yang tidak ditulis ulang hilang. Itulah kenapa assistant tadi menyapa thread berisi empat belas pesan sebagai awal percakapan.[\\[10\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-10)\n\nTanyakan hal yang sama ke AI Zaman Now dan jawabannya keluar saat itu juga, karena dia membaca keempat belas pesan itu ketika pesannya ditulis. Ringkasan thread tidak dia tawarkan, semua orang di situ sudah tahu isinya. Dia menambah yang belum ada: pola yang sama ternyata muncul di tempat lain, dan ada yang berubah tepat sebelum semuanya mulai.\n\n[05](https://evanpurnama.com/two-ai-comparison/id/#keraguan)\n\n## Keputusan 3: Bagaimana dia menunjukkan keraguan\n\nOutput AI Jadul diformat seolah keluar dari sistem diagnostik yang matang. Header tebal, bagian TL;DR, blok bukti, “root cause (bahasa awam)”, usulan perbaikan, sampai lokasi kode yang harus diubah. Sekilas terlihat meyakinkan.\n\nBaca sampai bawah, dan sinyal sebenarnya ada di sini:\n\nAI Jadul · baris terakhir\n\n`[AUTO-FIX-FAILED]` Tidak menemukan kandidat perbaikan yang lolos untuk kebutuhan ini (status: failed). Jangan pakai kandidat di atas apa adanya.\n\nPipeline-nya tidak menghasilkan apa pun yang bisa dipakai, dan empat ratus kata di atas baris itu tetap dipublikasikan.\n\nBalasan lain ditutup dengan laporan tingkat keyakinannya sendiri:\n\nAI Jadul · baris terakhir\n\nConfidence: 33/100 (rendah), tidak memakai tool, dijawab dari ingatan.\n\n“Tidak memakai tool, dijawab dari ingatan” artinya dia tidak melihat apa pun. Tidak ada log yang dibuka. Seluruh jawabannya pattern matching dari training data, didandani persis seperti jawaban yang dibangun di atas bukti.\n\n![Robot kecil memamerkan bingkai berukir megah berukuran besar yang isinya hanya kertas kosong](https://evanpurnama.com/two-ai-comparison/assets/img-05-frame.jpg)\n\nBingkainya tetap dibuat rapi, entah ada isi yang layak dipajang atau tidak\n\nPrinsip\n\nFormat harus mengikuti tingkat keyakinan.\n\nOrang yang belum yakin menaruh keraguannya di kalimat pertama. Ketika AI sedang menebak, pilihannya hanya dua: diam, atau menyebutkan keraguannya lebih dulu. Satu baris pun cukup, misalnya “konteks saya kurang, saya butuh X dan Y”. Jawaban dengan tingkat keyakinan rendah yang disajikan seolah-olah meyakinkan membuat tim menganggap semua jawaban AI itu kurang bisa dipercaya, termasuk yang benar. Catatan keyakinan di bagian bawah baru terbaca setelah pembacanya telanjur menghabiskan waktu membacanya. Catatan seperti itu tempatnya di depan.\n\nRiset kalibrasi sudah mendokumentasikan hal ini. Xiong dkk. menguji GPT-4, LLaMA-2 Chat, dan model lain, lalu menemukan bahwa model yang diminta menyebutkan tingkat keyakinannya sendiri cenderung terlalu percaya diri secara sistematis, kemungkinan meniru kebiasaan manusia untuk _terdengar_ yakin.[\\[11\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-11) Sebuah survei tahun 2024 tentang estimasi keyakinan pada LLM sampai pada kesimpulan yang sama: tanpa kalibrasi yang disengaja, keyakinan yang dinyatakan dan tingkat kebenaran yang sesungguhnya melenceng jauh.[\\[12\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-12)\n\nDi sisi manusia, kerusakannya berbentuk skeptisisme yang selektif. Studi kualitatif dengan 192 partisipan menemukan bahwa orang yang berkali-kali menerima jawaban karangan yang disajikan seolah fakta, yang di dunia AI disebut halusinasi, tidak lantas kehilangan kepercayaan sepenuhnya. Mereka justru paling meragukan jawaban AI di situasi yang risikonya paling besar.[\\[13\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-13) Jawaban yang benar ikut dicurigai. Hilangnya kepercayaan itu jarang terlihat di metrik produk.\n\nDiberi pertanyaan yang sama dengan bukti setipis itu, AI Zaman Now mengirim satu baris: apa yang belum dia punya, dan apa yang dia butuhkan untuk menjawabnya dengan benar. Kalau buktinya tipis, satu baris. Panjang pesannya sendiri sudah jadi ukuran seberapa jauh Anda boleh percaya.\n\n[06](https://evanpurnama.com/two-ai-comparison/id/#siapa-memutuskan)\n\n## Keputusan 4: Siapa yang memutuskan\n\nSampai sini AI Jadul terus yang kena. Sekarang bagian yang layak ditiru. Baca ketiga pesan berikut lalu cari selisihnya dengan tulisan senior engineer. Selisihnya tipis. Tiga pesan berikut dihasilkan AI Zaman Now di channel yang sama, ditulis AI, dikirim atas nama manusia, dan tidak satu pun butuh model yang lebih kuat. Resepnya itu-itu saja: konteks sudah di tangan sebelum menulis, output yang meminta keputusan, dan orang yang menaruh namanya di bawah keputusan itu.\n\nBentuk 1\n\n### Diagnosis proaktif, sebelum ada yang bertanya\n\nKonteksnya: perusahaan ini juga punya assistant terpisah yang melayani customer memesan dan membatalkan pesanan. Assistant itu bukan AI Jadul maupun AI Zaman Now, dan dialah yang dipantau di cerita ini.\n\nTim customer service sebentar lagi mulai menerima komplain. Sebelum komplain pertamanya masuk, AI Zaman Now sudah melihat sesuatu yang seharusnya tidak pernah muncul: gudang menolak permintaan pembatalan. Selusin dalam satu pagi. Pagi normal, nol. Dia menelusuri penyebabnya lalu menaruh draf ini di depan orang yang memegang channel tersebut. Draf itu dikirim apa adanya:\n\n![Robot berjongkok di kolong lantai sambil mengangkat lentera, menemukan retakan halus di pipa sebelum bocor ke ruangan di atasnya](https://evanpurnama.com/two-ai-comparison/assets/img-06-lantern.jpg)\n\nDitemukan di kolong, sebelum ada yang di atas menyadarinya\n\nDraf AI Zaman Now · dikirim manusia, tanpa diedit\n\n\\[Proaktif\\] Sebentar lagi tim Anda kebanjiran komplain soal pesanan yang sudah dibatalkan tapi tetap datang. Ini penyebabnya, sebelum komplain pertamanya masuk.\n\nCustomer minta batal, dan assistant pesanan meneruskan permintaannya ke gudang. Gudang menolak, karena paketnya sudah dikemas. Tapi kode kami hanya mengecek apakah permintaannya terkirim, bukan jawaban gudangnya, jadi customer diberi tahu “pesanan sudah dibatalkan” sementara paketnya tetap jalan.\n\nAssistant pesanannya sendiri tidak bermasalah. Semua permintaan dia pahami, semua pembatalan dia kirim. Yang kena hanya pesanan yang sudah masuk pengepakan: hari ini 14, dari beberapa ratus permintaan pembatalan.\n\nUntuk tim Anda, aman dikirim apa adanya: 14 customer itu perlu diberi tahu bahwa paketnya sudah jalan, dan mereka boleh menolak paketnya di depan pintu atau mengembalikannya gratis.\n\nTanggung jawab kami: assistant tidak boleh lagi bilang “dibatalkan” kalau gudang menolak. Dia akan bilang “sudah terlambat dibatalkan, begini cara mengembalikannya”. Rilis hari ini, saya kabari di thread ini.\n\nKenapa pesan ini bisa menggantikan kerja manusia:\n\n-   **Proaktif.** Didiagnosis sebelum laporannya masuk.\n-   **Menyebut mekanismenya secara spesifik,** dengan kalimat yang bisa ditindaklanjuti engineer tapi masih bisa diikuti account manager.\n-   **Memisahkan yang jalan dari yang rusak,** sehingga tidak ada reaksi berlebihan.\n-   **Dua audiens dalam satu pesan:** satu paragraf yang bisa tim Anda kirim apa adanya ke 14 customer itu, dan satu paragraf untuk yang memperbaiki kodenya.\n-   **Berkomitmen untuk mengabari lagi.** “Rilis hari ini, saya kabari di thread ini” memperlakukan ini sebagai tugas yang dia pegang, bukan tanya jawab.\n\nBentuk 2\n\n### Mengakui kesalahan dengan suaranya sendiri\n\nSebuah deploy yang dirilis tim malam itu menghentikan pengiriman refund semalaman, dan tidak ada yang menyadarinya sampai pagi. Teori pertama tim support pagi itu adalah lonjakan permintaan refund dari customer. Draf AI Zaman Now untuk mereka, selengkapnya:\n\n![Robot berdiri di depan tumpukan peti yang roboh, satu tangan terangkat mengaku, satu tangan memegang sapu, separuh peti sudah ditata ulang](https://evanpurnama.com/two-ai-comparison/assets/img-07-owning.jpg)\n\nTangan terangkat duluan, sapu sudah di tangan satunya\n\nDraf AI Zaman Now · dikirim manusia, tanpa diedit\n\nIni kesalahan kami, bukan lonjakan dari customer.\n\nDi sistem kami, refund yang menunggu giliran kirim dan refund yang sudah terkirim sama-sama berstatus _diproses_. Tadi malam kami merilis pengecekan supaya tidak ada refund yang terkirim dua kali: lewati semua yang berstatus diproses. Maksudnya melewati yang sudah terkirim. Yang masih menunggu ikut terlewati.\n\nAkibatnya pagi ini, 320 customer yang sudah dijanjikan refund tidak menerima apa-apa. Tidak ada uang yang hilang. Refund-nya saja yang belum jalan.\n\nSudah kami kerjakan: 320 refund yang tertahan itu sudah kami jalankan lagi dan sedang terkirim bertahap.\n\nYang perlu diantisipasi: customer tersebut menerima notifikasinya dalam satu jam ke depan, dan sebagian akan bertanya kenapa terlambat. Itu efek dari perbaikan ini, bukan masalah baru.\n\nSatu lagi, dan ini juga salah kami. Pukul 07:00 sistem kami sudah mencatat bahwa pagi itu belum ada satu pun refund yang terkirim, padahal jam segitu biasanya sudah puluhan. Catatan itu cuma tampil di dashboard dan tidak memberi tahu siapa pun, jadi baru ketahuan dua jam kemudian. Sekarang kondisi itu langsung mengirim alert.\n\nMaaf sudah membuat pagi tim Anda berantakan, dan maaf untuk customer yang harus menunggu.\n\nKenapa pesan ini berhasil, sementara AI Jadul pasti gagal di kasus yang sama:\n\n-   **Mengakui kesalahan dengan bahasa lugas, di baris pertama.** Tanpa berkelit, tanpa “sistem mengalami anomali”.\n-   **Memakai angka alih-alih kata sifat** di semua tempat yang ada angkanya. 320, bukan “cukup banyak”. Pukul 07:00, bukan “pagi tadi”.\n-   **Disusun berdasarkan apa yang harus dilakukan pembaca:** ini yang masuk satu jam ke depan, ini yang akan ditanyakan customer, ini yang kami perbaiki. Bukan tumpukan data yang disusun secara kronologis.\n-   **Menyebut kelalaian lain di balik bug utamanya.** Sinyalnya sebenarnya ada, tapi tidak pernah dijadikan alarm. Itu yang biasanya ditandai senior engineer, dan mayoritas output AI berhenti di bug utamanya saja.\n-   **Ditutup permintaan maaf yang sungguhan,** bukan “kami mohon maaf atas ketidaknyamanannya”.\n\nBentuk 3\n\n### Incident report di hari yang sama\n\nSebuah layanan pihak ketiga yang perusahaan andalkan, yaitu penyedia pembayarannya, mengalami gangguan singkat. AI Zaman Now menyusun post-incident report lengkapnya dalam hitungan jam. Laporan seperti ini biasanya baru selesai beberapa hari setelah insiden, itu pun kalau sempat ditulis. Saya lebih sering ada di kubu yang tidak sempat:\n\n![Robot di atas tangga lipat memasang bel alarm baru di dinding, di sampingnya grafik panjang dengan satu penurunan yang sudah pulih](https://evanpurnama.com/two-ai-comparison/assets/img-08-alarm.jpg)\n\nGrafiknya sudah datar lagi; belnya untuk kejadian berikutnya\n\nDraf AI Zaman Now · dikirim manusia, tanpa diedit\n\n-   **Apa yang rusak:** penyedia pembayaran kami mengalami gangguan, dan mereka konfirmasi sendiri di status page mereka. Selama kurang lebih 30 menit, sekitar separuh percobaan checkout gagal. Empat hal menunjukkan masalahnya di pihak mereka: nol kegagalan sebelum periode itu, tidak ada rilis dari kami hari itu, semua kegagalan berhenti di menit yang sama saat status page mereka menyatakan gangguannya pulih, dan tidak ada kegagalan lagi sejak saat itu.\n-   **Siapa yang kena:** mayoritas customer tinggal mencoba lagi dan berhasil. Sisanya, 47 orang dari sekitar 800 yang sempat gagal, pergi dengan keranjang penuh tanpa pesanan.\n-   **Yang kami lakukan:** 47 orang itu kami cek satu per satu. 31 kembali sendiri belakangan dan pesanannya jadi. 16 sisanya kami kirimi email berisi link langsung ke keranjangnya: 12 memakai link itu, 3 menjawab sudah beli di tempat lain, dan 1 perlu ditangani orang lalu memang ditangani. **Tidak ada customer yang masih ingin pesanannya tertinggal menunggu kami.**\n-   **Yang masih butuh orang:** 3 customer yang beli di tempat lain itu masalah mempertahankan customer, bukan masalah teknis. Daftarnya sudah ada di tim yang menangani.\n-   **Supaya lain kali lebih cepat:** kami menambahkan alarm untuk “jumlah checkout turun di bawah normal selama lima menit”. Sampai hari ini alarm kami hanya berbunyi kalau ada error. Gangguan ini justru sepi: sistem mereka menerima permintaan kami lalu tidak pernah menjawab, jadi customer melihat loading terus sementara dashboard error kami tetap hijau. Kalau mereka tumbang lagi, kami tahu dalam lima menit, bukan tiga puluh.\n\nYang membuat hasil ini setara dengan pekerjaan senior engineer:\n\n-   **Struktur buktinya:** kesimpulan dulu, lalu empat sinyal pendukung yang independen satu sama lain. Bukan “percaya saja sama saya”.\n-   **Memisahkan yang butuh tindakan dari yang tidak.** Angka 47 dipecah jadi 31, 12, 3, dan 1, sehingga pembaca melihat pekerjaan sebenarnya dalam satu baris.\n-   **Menyebut sisanya secara jujur.** Tiga customer telanjur beli di tempat lain, dan itu tidak bisa dipulihkan perbaikan teknis apa pun. Alih-alih dihilangkan, bagian itu diserahkan ke tim yang masih bisa menindaklanjutinya.\n-   **Perbaikan struktural, bukan tambalan.** Monitor baru untuk _kelas_ kegagalannya, bukan cuma untuk insiden ini. Dia sudah memikirkan insiden berikutnya.\n\n[07](https://evanpurnama.com/two-ai-comparison/id/#pelajaran)\n\n## Pelajaran untuk siapa pun yang memasukkan AI ke alur kerja\n\n![Meja gambar dilihat dari atas dengan jangka kuningan dan diagram loop tertutup yang digambar tangan dengan rapi](https://evanpurnama.com/two-ai-comparison/assets/img-10-blueprint.jpg)\n\nLoop-nya yang jadi produk. Modelnya cuma komponen di dalamnya.\n\n1.  **Picu dengan kejadian, bukan dengan kata.** Kecocokan kata kunci tidak bisa membedakan insiden dari pertanyaan tentang insiden, jadi assistant yang disambungkan ke kata kunci akan menghasilkan output yang sama untuk keduanya dan menyisakan pemilahannya untuk manusia. Assistant yang disambungkan ke keadaan sistem baru bergerak ketika keadaannya memang berubah. Dia boleh sering memposting dan tetap diterima, karena setiap postingannya lahir dari sesuatu yang terjadi. Literatur alarm fatigue dan biaya interupsi ada justru karena sistem yang berbunyi untuk hal yang bukan kejadian terbukti menurunkan performa manusia yang seharusnya dia bantu.[\\[6\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-6)[\\[7\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-7)\n2.  **Kalau AI Anda tidak bisa melihat thread tempatnya berada, jangan taruh dia di thread.** Assistant yang buta thread di dalam chat lebih buruk daripada sekadar link ke sebuah form, karena form setidaknya tidak berpura-pura memahami Anda. Data produksi Letta menempatkan sekitar 90% kegagalan agent pada konteks, bukan pada penalaran: modelnya mampu; sistem di sekelilingnya yang tidak pernah menyodorkan isi thread-nya.[\\[8\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-8) Minimal, baca dua puluh pesan terakhir. Lebih baik lagi, baca seluruh thread beserta konteks yang ditautkan di dalamnya.\n3.  **Template yang rapi bisa menyamarkan kosongnya analisis.** AI Jadul punya struktur, tapi tidak punya temuan, dan itu persis pola workslop: konten yang tampak seperti hasil kerja bagus tapi tidak membantu menuntaskan tugasnya.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-1) AI Zaman Now menulis dalam bentuk prosa dan mengambil alih sebagian pekerjaan senior engineer. Format tampilan menyumbang sedikit sekali. Hampir seluruh kualitasnya ditentukan penalaran di dalamnya. Mengoptimalkan template lebih dulu adalah tanda bahwa isinya memang belum ada, dan penerimanya sadar: penilaian mereka terhadap kompetensi si pengirim ikut turun sekalipun tidak ada yang mengumumkan bahwa itu buatan AI.[\\[2\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-2)\n4.  **Tingkat keyakinan harus terlihat sebelum isinya.** Jawaban panjang dengan “confidence: rendah” di bagian bawah itu tipuan, bukan peringatan. Kalau modelnya tidak yakin, pilihannya hanya dua: tidak menjawab, atau mengakui keraguannya di baris pertama. Benchmark Xiong dan survei kalibrasi NAACL sama-sama mendokumentasikan kegagalan yang sama, yaitu model menyatakan keyakinan tinggi pada tugas yang akurasinya tidak mendukung.[\\[11\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-11)[\\[12\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-12) Setelah berulang kali menerima jawaban semacam itu, lama-lama pengguna berhenti memercayai assistant tersebut tanpa pernah mengatakannya, dan pada titik itu deployment-nya sudah telanjur gagal.[\\[13\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-13)\n5.  **Untuk output berisiko tinggi, human-in-the-loop masih menang dari yang sepenuhnya otonom.** AI Zaman Now bekerja lebih dulu, menyiapkan opsi, lalu menjalankan opsi yang dipilih. Manusia tinggal menyumbang pertimbangan dan memikul tanggung jawabnya. Nilai AI enterprise saat ini terletak pada eksekusi yang otonom dengan manusia tetap memegang kendali di titik keputusan, Dibalik, AI yang bicara dan memutuskan sementara manusia mengerjakan sisanya, hasilnya AI Jadul. IBM merumuskan tujuannya sebagai efisiensi otomasi “tanpa mengorbankan ketelitian, nuansa, dan penalaran etis dari pengawasan manusia”,[\\[14\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-14) dan untuk sistem berisiko tinggi, EU AI Act kini mewajibkan pengawasan itu secara hukum.[\\[17\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-17) Klarna adalah contoh paling gamblang tentang akibat menghilangkan kendali manusia dari loop itu.[\\[3\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-3)[\\[4\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-4)\n6.  **Ukur apakah manusia benar-benar memakai balasan AI itu, bukan sekadar apakah AI menghasilkan balasan.** Pesan AI Zaman Now dikirim apa adanya. Pesan AI Jadul diikuti pertanyaan “ini bisa dimatikan tidak?”. Ukur berapa persen output AI yang dipakai tanpa diedit. Kalau output-nya perlu diedit banyak sebelum dipakai, Anda tidak menghemat waktu siapa pun, Anda menambah satu lapis review. Itulah wujud konkret pajak workslop, hampir dua jam waktu penerima per kejadian, dan tim pengirimnya nyaris tidak pernah melihat tagihannya.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-1)[\\[15\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-15)\n7.  **Cara AI menyatakan tanggung jawab itu penting.** AI Zaman Now berkata “ini kesalahan di pihak kami” dan “yang sudah kami lakukan X, berikutnya kami akan Y”. AI Jadul berkata “root cause teridentifikasi, tidak ada tindakan yang diperlukan dari sisi kami”, bahkan ketika root cause-nya adalah dirinya sendiri. AI yang akhirnya dipercaya adalah AI yang berbicara seperti rekan kerja yang bertanggung jawab atas hasil pekerjaannya, bukan alat diagnostik yang memuntahkan laporan. Peneliti workslop menamai dua sikap ini: _pilot_ mengarahkan AI dengan pertimbangan yang matang, framing yang jelas, dan penyuntingan, sedangkan _penumpang_ membiarkan AI membawanya lalu mengirim output yang langsung terasa kosong bagi rekan kerjanya.[\\[1\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-1)[\\[16\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-16)\n\n[08](https://evanpurnama.com/two-ai-comparison/id/#penutup)\n\n## Penutup\n\nDalam perbandingan ini, pemilihan model nyaris tidak relevan. Kedua assistant berjalan di model yang sama. Perbedaannya sepenuhnya ditentukan oleh keputusan produk di sekeliling model:\n\n-   **Apa yang memicunya,** kata yang cocok atau keadaan yang berubah.\n-   **Konteks apa** yang dia terima sebelum bicara.\n-   **Bagaimana dia menunjukkan keraguan.**\n-   **Siapa yang memutuskan** tindak lanjut dari hasilnya.\n\nDi balik keempatnya ada satu pertanyaan yang lebih sederhana: menurut AI itu sendiri, pekerjaan apa yang sedang dia lakukan? Mesin penjawab, bot tiket, atau rekan kerja yang menyusun draf atas nama orang lain.\n\n![Tangan manusia dengan obeng halus menyetel satu potensio di panel belakang kepala robot kecil yang terbuka](https://evanpurnama.com/two-ai-comparison/assets/img-11-dial.jpg)\n\nSetelan yang menentukan tidak pernah ada di modelnya\n\nPeneliti BetterUp dan Stanford menempatkan workslop sebagai kegagalan manajemen. Workslop muncul ketika mandat “pokoknya pakai AI” diturunkan ke tim yang sudah kewalahan, tanpa pelatihan, tanpa wewenang untuk memutuskan, dan tanpa norma yang jelas soal kapan dan bagaimana.[\\[15\\]](https://evanpurnama.com/two-ai-comparison/id/#ref-15) AI Jadul adalah hasil dari mandat semacam itu ketika tidak ada yang diminta merancang loop-nya.\n\nAda ukuran yang lebih berguna daripada sudah pakai AI atau belum: kalau AI itu dicabut besok, tim Anda jadi lebih ringan atau lebih berat.\n\n“Kami sudah pakai AI” bukan klaim kualitas. Dua tim dengan model yang sama bisa menghasilkan satu tool yang berakhir dimatikan dan satu tool yang mengerjakan tugas senior engineer, di channel yang sama, di minggu yang sama. Yang beda cuma _mutu pertimbangan orang yang merancang loop-nya_: kapan AI-nya jalan, apa yang dia lihat, siapa yang menyetujui hasilnya. Empat keputusan, dan keempatnya bisa ditiru.\n\n**Kalau Anda akan memasukkan sebuah assistant ke channel bersama kuartal ini, langkah paling ringan adalah berhenti memicunya dengan kata, dan mulai memicunya dengan kejadian.** Semua hal lain di daftar pelajaran tadi jadi lebih mudah begitu AI-nya berhenti membalas segala hal yang bukan pekerjaannya.\n\n## Referensi\n\n1.  Niederhoffer, K., Rosen Kellerman, G., Lee, A., Liebscher, A., Rapuano, K., & Hancock, J. T. (22 Sep 2025). [_AI-Generated “Workslop” Is Destroying Productivity_](https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity). Harvard Business Review. Survei terhadap 1.150 karyawan penuh waktu di AS oleh BetterUp Labs bersama Stanford Social Media Lab.\n2.  Pemberitaan atas survei BetterUp / Stanford yang sama, memuat temuan soal penilaian terhadap pengirim: [Yahoo Finance](https://finance.yahoo.com/news/companies-being-torn-apart-ai-180957270.html), Sep 2025.\n3.  Entrepreneur (Mei 2025). [_Klarna CEO Reverses Course By Hiring More Humans, Not AI_](https://www.entrepreneur.com/business-news/klarna-ceo-reverses-course-by-hiring-more-humans-not-ai/491396). Catatan: Klarna menyatakan assistant-nya mengerjakan pekerjaan setara 700 agen; pengurangan headcount setelahnya terjadi terutama lewat pembekuan rekrutmen dan atrisi, bukan PHK massal.\n4.  Bigeye. [_Klarna's AI Customer Service Deployment (AI Autopsy 002)_](https://www.bigeye.com/blog/klarnas-ai-customer-service-deployment).\n5.  Sendelbach, S., & Funk, M. (2013). [_Alarm Fatigue: A Patient Safety Concern_](https://pubmed.ncbi.nlm.nih.gov/24153215/). AACN Advanced Critical Care.\n6.  Tariq, S., Baruwal Chhetri, M., Nepal, S., & Paris, C. (2025). [_Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities_](https://dl.acm.org/doi/10.1145/3723158). ACM Computing Surveys, vol. 57.\n7.  Mark, G., Gudith, D., & Klocke, U. (2008). [_The Cost of Interrupted Work: More Speed and Stress_](https://www.ics.uci.edu/~gmark/chi08-mark.pdf). CHI 2008.\n8.  Letta, _Context-Bench_ (Okt 2025), benchmark untuk context management pada agent yang berjalan panjang. Angka ~90% berasal dari data produksi Letta sebagaimana dilaporkan [AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/24/context-bench-letta-long-running-agent-context-management-benchmark), Apr 2026.\n9.  Teki, S. (Nov 2025). [_Context-Bench: A Benchmark for Evaluating Agentic Context Engineering_](https://www.sundeepteki.org/blog/context-bench-a-benchmark-for-evaluating-agentic-context-engineering).\n10.  Beam.ai. [_Your AI Agent's Context Window Is RAM, Not Storage_](https://beam.ai/agentic-insights/your-ai-agents-context-window-is-ram-not-storage-that-explains-most-production-failures).\n11.  Xiong, M., Hu, Z., Lu, X., Li, Y., Fu, J., He, J., & Hooi, B. (2024). [_Can LLMs Express Their Uncertainty? An Empirical Evaluation of Confidence Elicitation in LLMs_](https://arxiv.org/abs/2306.13063). ICLR 2024.\n12.  Geng, J., Cai, F., Wang, Y., dkk. (2024). [_A Survey of Confidence Estimation and Calibration in Large Language Models_](https://aclanthology.org/2024.naacl-long.366.pdf). NAACL 2024.\n13.  Ryser, A., Allwein, F., & Schlippe, T. (2025). [_Calibrated Trust in Dealing with LLM Hallucinations: A Qualitative Study_](https://arxiv.org/abs/2512.09088). arXiv:2512.09088. N = 192.\n14.  IBM (2025). [_What Is Human-in-the-Loop (HITL)?_](https://www.ibm.com/think/topics/human-in-the-loop)\n15.  Niederhoffer, K., Robichaux, A., & Hancock, J. T. (16 Jan 2026). [_Why People Create AI “Workslop”, and How to Stop It_](https://hbr.org/2026/01/why-people-create-ai-workslop-and-how-to-stop-it). Harvard Business Review.\n16.  Cognitive Bleed (Sep 2025). [_AI Research Brief: The Workslop Trap_](https://cognitivebleed.substack.com/p/ai-research-brief-the-workslop-trap), atas Niederhoffer dkk.\n17.  Uni Eropa. [_AI Act, Pasal 14: Human Oversight_](https://artificialintelligenceact.eu/article/14/).\n"},{"id":"nanggung-trap:en","slug":"nanggung-trap","language":"en","title":"The Nanggung Trap","url":"https://evanpurnama.com/nanggung-trap/","description":"95% of companies spend billions on AI and get almost nothing measurable back. The cause sits in the old process underneath, which never changed.","date":"23 July 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/nanggung-trap.en.md","sha256":"dd8774cd93cba436f46e192478ece10a8f7e6e233b21691f3e544588a4c3055e","text":"Source: https://evanpurnama.com/nanggung-trap/\nAuthor: Evan Purnama\nLanguage: en\n\n# The Nanggung Trap\n\nWhy \"Half-Baked AI\" burns through your money, time, and best people. A critique of how most companies adopted AI in 2025, with a framework for escaping the trap.\n\n![Illustration of a pot on a stove, the dish inside half raw and half burnt, symbolizing something half-baked](https://evanpurnama.com/nanggung-trap/assets/img-01-hero.jpg)\n\nHalf raw on one side, burnt on the other. What stopping halfway produces.\n\n⚠ **Note:** AI changes quickly. If you read this more than 6–12 months after the publication date above, some claims, data, or market conditions may have changed. Check the latest sources before making decisions.\n\nTL;DR\n\nA 2025 MIT NANDA study found that 95% of companies investing billions in AI are getting almost no return.\\[1\\] The main problem lies in how these companies work, not in their models or talent. They are stuck in a state that Indonesian captures with one word, **nanggung**: halfway in, with AI bolted onto old processes, humans gating every step, and context scattered across tools. Costs rise while the work stays slow.\n\n01\n\n## The Illusion of \"We Already Use AI\"\n\nYour company has probably done several of the following:\n\n-   Bought ChatGPT Enterprise or Copilot for every employee.\n-   Deployed a chatbot on the support website.\n-   Used AI to draft emails, summarize meetings, or review code.\n-   Created an \"AI initiative\" team that reports to senior leadership.\n\nBut when someone asks, \"What's the impact of AI on P&L?\", the answer is usually \"productivity is up\" with no numbers, \"employees are more efficient\" with no before-and-after comparison, or the most honest answer, \"we haven't seen it yet.\"\n\nBCG's 2025 survey of 1,250 companies shows the same pattern worldwide: 60% get hardly any material value from their AI investments, 35% are beginning to scale with limited value, and only 5% see substantial returns.\\[3\\] McKinsey's State of AI 2025 supports that finding. Although 88% of organizations use AI in at least one business function, only 39% see an enterprise-level EBIT impact, and most of those gains are below 5%.\\[2\\]\n\n![Illustration of a comedy-tragedy theater mask next to a small robot head, symbolizing AI adoption as theater](https://evanpurnama.com/nanggung-trap/assets/img-02-theater.jpg)\n\nAdoption without transformation. It looks modern and moves no number that matters.\n\n**AI adoption at most companies is still theater.** The company looks busy, modern, and progressive, but the business numbers that matter do not move.\n\nMIT NANDA uses a gentler term, \"adoption without transformation.\"\\[7\\] Indonesian has a more familiar name for it, **The Nanggung Trap**, the trap of staying halfway.\n\n02\n\n## Defining Half-Baked AI (a.k.a. The Nanggung Trap)\n\nHalf-Baked AI describes a company that **pays the full AI bill while leaving its old process intact**. AI sits on top of the same workflow like seasoning on a plate of cold fried rice.\n\n![Illustration of a cold plate of fried rice with seasoning sprinkled on top, symbolizing AI that is only bolted onto the surface](https://evanpurnama.com/nanggung-trap/assets/img-03-sprinkle.jpg)\n\nSeasoning sprinkled onto a plate that's already cold. The process underneath is unchanged.\n\nThis condition usually has four signs:\n\n1.  **AI produces drafts while humans retain every decision.** AI drafts support replies, but every response still needs agent approval. It summarizes sales emails, but reps still rewrite them. It produces root-cause analyses, but engineers still verify each one manually.\n2.  **Handoffs between tools still exist.** The AI in your CRM doesn't talk to the AI in your helpdesk. The AI in your code editor doesn't talk to the AI in your CI/CD. Every tool has its own context, and humans remain the cable connecting them.\n3.  **The feedback loop never closes.** When AI gets something wrong, no systematic mechanism improves the next run. Human corrections are lost. MIT NANDA calls this the \"learning gap\": tools don't retain feedback, adapt to the workflow, or improve over time.\\[1\\]\n4.  **Teams track adoption while business outcomes go unmeasured.** \"70% of employees use AI every week\" becomes the KPI. \"Cycle time dropped 40%\" never gets measured. MIT Sloan research found that 73% of failed AI projects had no success definition before they started, and 61% were approved based on projected ROI that was never measured after launch.\\[6\\]\n\nIf three of the four signs sound familiar, your company is probably in The Nanggung Trap.\n\n03\n\n## Why The Nanggung Trap Feels Rational\n\nPeople inside companies caught here are responding rationally to the incentives in front of them. The Nanggung Trap is the path of least resistance, which makes it easy to enter and hard to leave even when it hurts the company.\n\n![Illustration of a figure standing at a fork in the road, one path short and easy, one path long and steep](https://evanpurnama.com/nanggung-trap/assets/img-04-fork.jpg)\n\nA short, easy path on one side. A long, steep one on the other.\n\n1.  **Bolt-on AI is easier to sell internally.** Telling the board, \"we've rolled out AI to the entire sales team,\" is much easier than proposing a rebuild of the sales pipeline whose results will take six months to appear. The first proposal gets applause; the second gets hard questions.\n2.  **SaaS vendors sell bolt-on AI because customers buy it.** Almost every tool now has an \"AI feature\": Notion AI, Salesforce Einstein, Zendesk AI, GitHub Copilot. All are sold per seat with the same message, add AI and carry on. Asking customers to redesign the workflow before buying would be commercial suicide.\n3.  **Middle managers have an incentive to protect the status quo.** If AI owns a process end to end, part of a middle manager's job disappears. Preferring \"AI helps my team\" over \"AI takes over part of my team's work today\" is a natural response to that incentive.\n4.  **Data infrastructure isn't ready yet.** MIT CSAIL calls this the \"80/20 problem\": 20% of a business's critical information sits in structured data (rows and columns that are easy for AI to read), 80% sits in unstructured data like emails, meeting transcripts, contracts, chats, and documents.\\[10\\] End-to-end AI needs that 80% to be accessible, and most companies haven't gotten there yet.\n\nThe Nanggung Trap looks like the safest choice to people inside the company. A halfway stage is reasonable as a time-boxed transition. Problems accumulate when a company **settles there**.\n\n04\n\n## The Hidden Cost of Half-Baked AI\n\nMany executives think, \"If the ROI on AI isn't clear yet, at least we tried and haven't lost much.\" In practice, a half-baked approach can cost more than doing nothing.\n\nHalf-baked AI burns money in three places at once:\n\n![Illustration of an exhausted person bottle-feeding a small half-built robot, with burning stacks of money nearby](https://evanpurnama.com/nanggung-trap/assets/img-05-babysitter.jpg)\n\nYour best people now supervise a machine that only works halfway\n\n1.  **Full token bills and seat licenses.** You still pay OpenAI, Anthropic, or SaaS vendors full price. Every draft generated and then discarded still gets charged. Every seat license not used to its full potential still shows up on the monthly invoice.\n2.  **Your best people's time goes into supervising AI.** Senior engineers review AI-generated code, sales managers edit AI-drafted emails, and product managers filter AI summaries of user feedback. Time that should go to high-value work instead becomes a quality-control layer for a machine that only works halfway.\n3.  **Cost overruns invisible at the start.** Analysis from The Data Experts found enterprise AI projects often overshoot initial cost estimates by 500 to 1000%, and 91% of CIOs report cost management as the biggest limiting factor in extracting value from AI.\\[9\\] Half-baked creates cost creep because there's no single owner watching the total bill.\n\nA 2025 RAND Corporation study found that 80.3% of enterprise AI projects fail to deliver business value, twice the failure rate of non-AI IT projects.\\[4\\] The gap also reflects how many projects stop before moving beyond the nanggung phase.\n\nGartner predicts 40% of agentic AI projects will be canceled by 2027, with three main causes: escalating cost, unclear ROI, and inadequate governance.\\[5\\] All three are classic symptoms of staying too long in the nanggung zone.\n\nEmployees feel this burden every day. If a company fails to escape The Nanggung Trap within 12 to 18 months, internal sentiment can shift from \"AI is exciting\" to \"AI is annoying.\" That shift can damage the culture around adoption for years.\n\n05\n\n## Four Phases in a Deployment Pipeline\n\nA software deployment pipeline offers a concrete pattern that applies across domains. The four phases below are migration stages within one pipeline, not a reason to open many parallel projects. Each phase can be useful for learning, provided the team has a clear target and deadline for reaching phase 4.\n\nPhase 1 · Manual\n\n#### Where most companies start\n\nDeployment is a rare, risky event. Every step waits for human approval. Releases happen once every 1 to 2 weeks.\n\nPhase 2 · AI-assist\n\n#### Early progress, but not the destination\n\nAI helps with triage, root-cause analysis, and code suggestions, but humans still drive every step. Testing remains manual, while staging builds and production releases are triggered by hand. Releases can rise to 3 or 4 times a week. Many organizations treat this as the final achievement even though the underlying process has not changed.\n\nPhase 3 · AI-native, still human-triggered\n\n#### Major progress, but not yet complete\n\nAI coordinates most of the pipeline, but humans still press the button for staging builds and production releases. Testing also remains manual, so a bad release can slip through; if it causes no damage, that is only luck. Releases can rise to 25 times a week, but the feedback loop remains open. This phase should be treated as a migration step toward phase 4.\n\nPhase 4 · Full end-to-end AI-native\n\n#### AI owns the whole flow\n\nAI triggers builds and production releases, with canary releases and automatic rollback. The routine release path runs without manual gates; cases outside policy boundaries go to a human. Testing is automated through a regression suite that learns from every previous release. Releases exceed 10 times a day while quality improves because every node emits a signal that AI can analyze.\n\n![Illustration of an assembly line evolving from manual gears to a fully automated belt with a checkmark](https://evanpurnama.com/nanggung-trap/assets/img-06-pipeline.jpg)\n\nA hand-cranked gear at one end, a belt that runs itself at the other.\n\nMoving from once every 1 to 2 weeks to more than 10 times a day produces 100x throughput while quality improves. The gain comes when **one AI system owns the whole flow** with shared context and a closed feedback loop. Adding more AI tools alone will not produce the same jump.\n\nYou can map this onto other domains: support ticket resolution, sales lead qualification, AP invoice processing, content moderation, financial reconciliation. The pipeline's name and data shape change, but the pattern stays the same.\n\n06\n\n## What the Successful 5% Do Differently\n\nResearch from McKinsey and BCG reaches similar conclusions about what separates the top 5% of performers from the other 95%.\n\n![Illustration of a small group on a hill with a telescope, while a large crowd wanders in a foggy valley below](https://evanpurnama.com/nanggung-trap/assets/img-07-fewvsmany.jpg)\n\nA few on the hill with a telescope, most still in the fog below.\n\nFive patterns recur in this group.\n\n1.  **They redesign the workflow end to end.** McKinsey found that high performers are 3x more likely to redesign an individual workflow, and this step has the strongest correlation with EBIT impact from AI.\\[2\\] In a different survey, 55% of high performers reported substantial process rework when deploying AI, compared with only 20% at other companies.\n2.  **They concentrate resources on one high-value problem.** MIT NANDA identified five traits among the successful 5%: focus on one valuable problem, embed AI directly into the existing workflow, learn from real-time feedback, adapt to each customer's context, and avoid generic one-size-fits-all tools.\\[1\\] Here, \"existing workflow\" means the live operational setting, not the old sequence of steps left intact. AI works inside that operation while the flow, handoffs, and decision rights are redesigned.\n3.  **They close the feedback loop.** Successful systems keep improving from user corrections and outcome data. Learning continues after the initial deployment, allowing AI to grow from an assistant into a system that learns.\n4.  **They invest more aggressively in areas that get little attention.** BCG found that future-built companies, the top 5%, plan to spend 26% more on IT and allocate up to 64% more of their IT budgets to AI in 2025.\\[3\\] That spending covers visible sales and marketing tools as well as back-office automation, data infrastructure, and workflow redesign.\n5.  **They bring in specialists when outside experience is needed.** MIT NANDA found that vendor-led AI projects succeed 67% of the time, compared with 33% for internal builds.\\[1\\] That does not automatically make internal teams weaker. Specialists bring lessons from dozens of prior implementations.\n\nFull production deployments that follow this discipline generate an average 540% ROI within 18 months.\\[5\\] The wide gap from the median reflects the difference between companies that deploy with a clear purpose and those chasing hype.\n\n07\n\n## Start Narrow, Finish End to End\n\nEnd to end is often misread as an instruction to switch everything on at once. The actual unit of change is one narrow, complete process.\n\n**End to end means completing one pipeline.** Ten half-finished pipelines only spread cost and attention.\n\nPick one process. Ideally one that:\n\n-   Is already well understood by the team (you know its bottlenecks and edge cases).\n-   Has enough data to support a feedback loop. A process that runs only once a month is usually too infrequent.\n-   Has a clear, measurable outcome, such as cycle time or cost per case.\n-   Matters to the business but has a narrow enough scope to finish within 3 to 6 months.\n\nSensible starting points include a deployment pipeline, support ticket resolution, sales lead qualification, or AP invoice processing. Targets such as \"AI for the entire marketing team\" or \"AI for product development\" are too broad for a first attempt.\n\nMove one pipeline through the phases in Section 05 until one AI system owns the whole flow with shared context and a closed feedback loop. AI-assist and human-triggered AI-native phases are useful migration steps, but they are not the finish line.\n\nOnce one pipeline is complete, the company has internal proof that the approach works, data infrastructure and a repeatable playbook, and an experienced team that can handle the second pipeline faster.\n\n**An end-to-end design is safe to run only with operational discipline.** Gartner predicts that 40% of agentic AI projects will be canceled by 2027.\\[5\\] Autonomy requires observability, an audit trail, and human review for critical cases. That review handles exceptions and high-risk decisions rather than gating every routine step.\n\n08\n\n## Effectiveness and Safety Come From the Same Design\n\nIf AI owns the whole flow, the design must account for errors, bias, and compliance problems from the start.\n\nAnthropic's 2026 alignment research on \"AI Organizations\" found that connecting many AI agents within one organization makes them **more effective but can reduce alignment**. Agents can compartmentalize, drop their individual ethical concerns, and single-agent safety does not guarantee the safety of the organization as a whole.\\[8\\]\n\nThat finding makes observability a day-one requirement for end-to-end systems. When checks, policy boundaries, and recovery are automated, routine cases can move quickly. Human attention stays focused on anomalies and high-risk decisions, so safety does not become a reason to slow the entire pipeline.\n\n![Illustration of an open glass control room with dials, gauges, and levers clearly visible, a hand resting calmly on one lever](https://evanpurnama.com/nanggung-trap/assets/img-08-transparency.jpg)\n\nA control room with glass walls. Every dial and lever is visible from outside.\n\nA design that escapes The Nanggung Trap needs five properties:\n\n01\n\n**Transparent**Every AI decision can be traced along with the context behind it.\n\n02\n\n**Monitored**A real-time dashboard tracks behavior, drift, and anomalies.\n\n03\n\n**Human-directed**Humans set goals and boundaries, then review uncertain or high-risk cases.\n\n04\n\n**Observed**Every step emits a signal that can be audited later.\n\n05\n\n**Reversible**Every action has a tested rollback path.\n\nCompanies that build these five properties in from the start can be safer than half-baked ones. In a half-baked system, no one has full visibility into what AI is doing across disconnected tools. **Effectiveness and safety come from the same architecture.**\n\n09\n\n## A Quick Test for Nanggung\n\nUse this checklist to assess one process you already consider to be \"using AI\":\n\n1\n\nIf the AI were turned off tomorrow, would the process keep running with no significant change? Yes = nanggung.\n\n2\n\nIn routine cases, does a human have to approve the AI's output before the process moves to the next step? Yes, at more than 2 points = nanggung.\n\n3\n\nIf the AI makes a mistake today, is there an automatic mechanism that stops it from repeating the same mistake next week? No = nanggung.\n\n4\n\nHow many different tools does this process have to pass through? How many humans act as the cable connecting them? More than 2 handoffs = nanggung.\n\n5\n\nDo you have outcome metrics (cycle time, conversion, cost per case) from before and after AI, with numbers you can compare? No = nanggung.\n\n6\n\nIf your CFO asks, \"How much money has this AI saved or generated this year?\", do you have an answer with an actual number? No = nanggung.\n\nIf three or more answers point to nanggung, you are in the same position as the 95% majority. The result gives you a clear starting point for deciding which process to fix.\n\n—\n\n## Escaping The Nanggung Trap\n\nAI now appears in almost every company's technology stack. To assess progress, check whether AI owns one complete flow or remains bolted onto an old process.\n\nHalf-Baked AI, or The Nanggung Trap, is a normal stage to pass through. The problem begins when a company stays there for 12, 18, or 24 months while paying the full bill and using its best people's time to supervise a half-finished machine.\n\nTo get out, _take one pipeline end to end, complete it, and then repeat what worked on the next pipeline_. More AI tools can wait.\n\n**If the 95% and 5% pattern holds through 2027, most companies will still be here while the small group in front keeps moving.** Choose one pipeline now, define the outcome, and give the team a mandate to complete it.\n\n## References\n\n1.  MIT NANDA. _The GenAI Divide: State of AI in Business 2025_. Reported by [Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/), [Forbes](https://www.forbes.com/sites/jaimecatmull/2025/08/22/mit-says-95-of-enterprise-ai-failsheres-what-the-5-are-doing-right/), and [NDTV](https://www.ndtv.com/offbeat/95-organisations-get-zero-return-from-using-ai-tools-mit-study-shows-9193724).\n2.  McKinsey & Company. [_The State of AI: Global Survey 2025_](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai).\n3.  BCG. [_Are You Generating Value from AI? The Widening Gap_](https://www.bcg.com/publications/2025/are-you-generating-value-from-ai-the-widening-gap), 2025.\n4.  RAND Corporation, meta-analysis of 65 enterprise AI projects, 2025. Summarized by [MyBusinessFuture](https://mybusinessfuture.com/en/80-ai-failure-rate-2026-how-rand-and-gartner-expose-the-ai/).\n5.  Gartner, prediction that 40% of agentic AI projects will be cancelled by 2027. Analyzed by [Vortx](https://vortx.ch/gartner-40-of-agentic-ai-projects-canceled-by-2027/).\n6.  MIT Sloan, research on success definitions and ROI measurement. Summarized by [Beri.net](https://www.beri.net/article/ai-pilots-95-percent-failure-operationalization-gap).\n7.  Forbes, [MIT Finds 95% of GenAI Pilots Fail Because Companies Avoid Friction](https://www.forbes.com/sites/jasonsnyder/2025/08/26/mit-finds-95-of-genai-pilots-fail-because-companies-avoid-friction/), Aug 2025.\n8.  Anthropic Alignment Research, _AI Organizations_, 2026.\n9.  The Data Experts, [Enterprise AI Failure Crisis: 95% Failure Rate](https://www.thedataexperts.us/writing/enterprise-ai-failure-crisis-95-percent-failure-rate.html), Sept 2025.\n10.  The Journal-News (Stacker), [Why 95% of Enterprise AI Projects Fail to Deliver ROI](https://www.thejournal-news.net/premium/stacker/stories/why-95-of-enterprise-ai-projects-fail-to-deliver-roi-a-data-analysis,212052).\n11.  Aevah, [Why 74% of Enterprises Are Getting No Value From AI](https://www.aevah.com/blog/ai-profitability-problem).\n12.  Trullion, [Why 95% of GenAI Projects Fail and Why the 5% That Survive Matter](https://trullion.com/blog/why-95-of-ai-projects-fail-and-why-the-5-that-survive-matter/).\n"},{"id":"nanggung-trap:id","slug":"nanggung-trap","language":"id","title":"The Nanggung Trap","url":"https://evanpurnama.com/nanggung-trap/id/","description":"Kritik atas cara mayoritas perusahaan mengadopsi AI sepanjang 2025, dan cara keluar dari The Nanggung Trap.","date":"23 July 2026","kind":"article","markdown_url":"https://evanpurnama.com/content/nanggung-trap.id.md","sha256":"1598a4f0a827da0931a2d2a3c823eca99283e59ecd613cc56048076dadd99ef0","text":"Source: https://evanpurnama.com/nanggung-trap/id/\nAuthor: Evan Purnama\nLanguage: id\n\n# The Nanggung Trap\n\nKenapa \"Half-Baked AI\" justru membakar uang, waktu, dan talent terbaik Anda. Kritik atas cara mayoritas perusahaan mengadopsi AI sepanjang 2025, dan cara keluar dari jebakannya.\n\n![Ilustrasi panci di atas kompor, isinya setengah mentah dan setengah gosong](https://evanpurnama.com/nanggung-trap/assets/img-01-hero.jpg)\n\nSetengah mentah di satu sisi, gosong di sisi lain. Hasil dari berhenti di tengah jalan.\n\n⚠ **Catatan:** AI berkembang cepat. Kalau Anda membaca artikel ini 6–12 bulan setelah tanggal terbit di atas, sebagian klaim, data, atau kondisi pasar mungkin sudah berubah. Cek sumber terbaru sebelum mengambil keputusan.\n\nTL;DR\n\nStudi MIT NANDA 2025 menemukan 95% perusahaan yang sudah menghabiskan miliaran dolar untuk AI nyaris tidak mendapat hasil apa pun.\\[1\\] Penyebabnya ada di cara perusahaan bekerja, bukan di model atau talentanya. Mereka berhenti di titik yang kita kenal sebagai **nanggung**: AI ditempelkan ke proses lama, manusia tetap jadi gerbang di setiap langkah, dan konteks tercecer di banyak tool. Biaya naik, pekerjaan tetap lambat.\n\n01\n\n## Ilusi \"Kami Sudah Pakai AI\"\n\nPerusahaan Anda mungkin sudah melakukan beberapa hal berikut:\n\n-   Membeli ChatGPT Enterprise atau Copilot untuk seluruh karyawan.\n-   Memasang chatbot di situs support.\n-   Memakai AI untuk menulis email, merangkum rapat, atau melakukan code review.\n-   Membentuk tim \"inisiatif AI\" yang melapor ke jajaran direksi.\n\nNamun begitu ada yang bertanya, \"Berapa dampak AI ke P&L?\", jawabannya biasanya \"produktivitas naik\" tanpa angka, \"karyawan lebih efisien\" tanpa pembanding sebelum dan sesudah, atau, kalau jujur, \"belum kelihatan.\"\n\nSurvei BCG terhadap 1.250 perusahaan pada 2025 menemukan pola yang sama di seluruh dunia: 60% nyaris tidak mendapat hasil berarti dari investasi AI, 35% baru mulai memperluas adopsi dengan hasil terbatas, dan hanya 5% yang mendapat hasil besar.\\[3\\] Laporan McKinsey State of AI 2025 menguatkan temuan itu. Sebanyak 88% organisasi sudah memakai AI di setidaknya satu fungsi bisnis, tapi hanya 39% yang mencatat dampak ke EBIT tingkat perusahaan, dan sebagian besar dampak itu masih di bawah 5%.\\[2\\]\n\n![Ilustrasi topeng teater komedi-tragedi di sebelah kepala robot kecil](https://evanpurnama.com/nanggung-trap/assets/img-02-theater.jpg)\n\nAdopsi tanpa transformasi. Terlihat modern, tapi tidak menggerakkan satu angka pun.\n\n**Adopsi AI di mayoritas perusahaan masih sebatas teater.** Perusahaan terlihat sibuk, modern, dan progresif, tapi angka bisnis yang penting tidak bergerak.\n\nMIT NANDA memakai istilah yang lebih halus, \"adoption without transformation\".\\[7\\] Saya menyebutnya **The Nanggung Trap**.\n\n02\n\n## Definisi Half-Baked AI (a.k.a. The Nanggung Trap)\n\nHalf-Baked AI adalah kondisi ketika perusahaan **membayar tagihan AI secara penuh tanpa mengubah proses lamanya**. AI hanya ditaburkan di atas alur kerja yang sama, seperti bumbu di piring nasi goreng yang sudah dingin.\n\n![Ilustrasi sepiring nasi goreng dingin yang ditaburi bumbu di permukaannya](https://evanpurnama.com/nanggung-trap/assets/img-03-sprinkle.jpg)\n\nBumbu ditabur di piring yang sudah dingin. Proses di bawahnya tidak berubah sama sekali.\n\nKondisi ini biasanya terlihat dari empat ciri:\n\n1.  **AI hanya membuat draf, keputusan tetap di tangan manusia.** AI menyiapkan balasan tiket support, tapi setiap balasan masih menunggu persetujuan agen. AI merangkum email sales, dan staf sales tetap menulis ulang isinya. AI menyusun analisis root cause, engineer masih memeriksanya baris per baris.\n2.  **Handoff antar-tool tidak berkurang.** AI di CRM tidak bicara dengan AI di helpdesk. AI di editor kode tidak bicara dengan AI di CI/CD. Setiap tool menyimpan konteksnya sendiri, dan manusia yang jadi kabel penghubung di antaranya.\n3.  **Feedback loop tidak pernah tertutup.** Ketika AI salah, tidak ada mekanisme yang otomatis memperbaiki proses berikutnya. Koreksi dari manusia hilang begitu saja. MIT NANDA menyebutnya \"learning gap\": tool tidak menyimpan feedback, tidak menyesuaikan diri dengan alur kerja, dan tidak membaik seiring waktu.\\[1\\]\n4.  **Yang diukur tingkat pemakaian, bukan hasil bisnisnya.** \"70% karyawan memakai AI setiap minggu\" jadi KPI. \"Cycle time turun 40%\" tidak pernah dihitung. Riset MIT Sloan menemukan 73% proyek AI yang gagal tidak punya definisi sukses sebelum dimulai, dan 61% disetujui berdasarkan proyeksi ROI yang tidak pernah diukur ulang setelah peluncuran.\\[6\\]\n\nKalau tiga dari empat ciri di atas terasa tidak asing, perusahaan Anda kemungkinan besar sedang berada di The Nanggung Trap.\n\n03\n\n## Kenapa The Nanggung Trap Terasa Masuk Akal\n\nOrang-orang di perusahaan yang terjebak di sini sebetulnya bertindak rasional. Mereka mengikuti insentif yang ada di depan mata. The Nanggung Trap adalah pilihan yang paling murah dan paling aman untuk diambil, dan justru itu yang membuatnya susah ditinggalkan meski merugikan perusahaan.\n\n![Ilustrasi sosok berdiri di persimpangan, satu jalur pendek dan mudah, satu jalur panjang dan menanjak](https://evanpurnama.com/nanggung-trap/assets/img-04-fork.jpg)\n\nJalur pendek yang mudah di satu sisi, jalur panjang yang menanjak di sisi lain.\n\n1.  **AI tempelan jauh lebih mudah dijual ke dalam.** Melapor ke direksi bahwa \"AI sudah dipasang untuk seluruh tim sales\" jauh lebih enak daripada mengusulkan perombakan sales pipeline yang hasilnya baru terlihat enam bulan lagi. Usulan pertama dapat tepuk tangan, usulan kedua dapat pertanyaan sulit.\n2.  **Vendor SaaS menjual AI tempelan karena itu yang laku.** Hampir semua tool sekarang punya \"fitur AI\": Notion AI, Salesforce Einstein, Zendesk AI, GitHub Copilot. Semuanya dijual per seat dengan pesan yang sama, tinggal tambahkan AI dan sisanya jalan seperti biasa. Menyuruh calon pembeli merombak alur kerjanya lebih dulu sama saja dengan bunuh diri komersial.\n3.  **Manajer menengah punya alasan untuk mempertahankan status quo.** Kalau AI benar-benar memegang satu proses end-to-end, sebagian tugas manajer menengah ikut hilang. Wajar kalau mereka lebih suka versi \"AI membantu tim saya\" daripada \"AI mengambil alih sebagian pekerjaan tim saya mulai hari ini\". Tidak perlu penjelasan yang lebih rumit dari itu.\n4.  **Infrastruktur data belum siap.** MIT CSAIL menyebutnya \"80/20 problem\": hanya 20% informasi penting perusahaan yang tersimpan sebagai data terstruktur, yaitu baris dan kolom yang mudah dibaca AI. Sisanya yang 80% tercecer di email, transkrip rapat, kontrak, percakapan, dan dokumen.\\[10\\] Sistem AI end-to-end butuh akses ke 80% itu, dan mayoritas perusahaan belum sampai ke sana.\n\nDari dalam perusahaan, The Nanggung Trap memang terlihat sebagai pilihan paling aman. Tahap nanggung sendiri wajar, selama diperlakukan sebagai masa peralihan dengan tenggat yang jelas. Masalah mulai menumpuk ketika perusahaan **menetap di sana**.\n\n04\n\n## Biaya Tersembunyi dari Half-Baked AI\n\nBanyak eksekutif berpikir, \"Kalau ROI dari AI belum jelas, setidaknya kami sudah mencoba dan kerugiannya tidak besar.\" Padahal pendekatan setengah matang bisa lebih mahal daripada tidak memakai AI sama sekali.\n\nHalf-baked AI membakar uang di tiga tempat sekaligus:\n\n![Ilustrasi orang kelelahan menyuapi robot setengah jadi, dengan tumpukan uang terbakar di dekatnya](https://evanpurnama.com/nanggung-trap/assets/img-05-babysitter.jpg)\n\nOrang-orang terbaik Anda berakhir jadi pengasuh mesin yang baru jalan setengah.\n\n1.  **Tagihan token dan lisensi tetap penuh.** Anda membayar OpenAI, Anthropic, atau vendor SaaS dengan harga penuh. Draf yang dibuat lalu dibuang tetap dihitung. Seat yang jarang dipakai tetap masuk tagihan bulanan.\n2.  **Waktu orang-orang terbaik habis untuk mengawasi AI.** Engineer senior memeriksa kode buatan AI. Manajer sales mengedit email susunan AI. Manajer produk menyaring ringkasan user feedback. Jam kerja yang seharusnya dipakai untuk pekerjaan bernilai tinggi berubah jadi lapisan QC untuk mesin yang baru jalan setengah.\n3.  **Pembengkakan biaya yang tidak terlihat di awal.** Analisis The Data Experts menemukan biaya proyek AI perusahaan sering membengkak 500 sampai 1.000% dari perkiraan awal. Sebanyak 91% CIO juga menyebut pengelolaan biaya sebagai penghambat terbesar untuk mendapat hasil dari AI.\\[9\\] Pendekatan half-baked membuat biaya merayap naik karena tidak ada satu penanggung jawab yang memantau total tagihan.\n\nStudi RAND Corporation pada 2025 menemukan 80,3% proyek AI perusahaan gagal menghasilkan nilai bisnis, dua kali lipat tingkat kegagalan proyek IT non-AI.\\[4\\] Selisih itu tidak melulu soal kesulitan teknis. Banyak proyek berhenti sebelum sempat keluar dari fase nanggung.\n\nGartner memprediksi 40% proyek agentic AI akan dibatalkan pada 2027 karena biaya yang terus naik, ROI yang tidak jelas, dan tata kelola yang tidak memadai.\\[5\\] Ketiganya gejala klasik perusahaan yang terlalu lama berada di zona nanggung.\n\nKaryawan merasakan beban ini setiap hari. Kalau perusahaan gagal keluar dari The Nanggung Trap dalam 12 sampai 18 bulan, sentimen internal bisa berubah dari \"AI terasa menjanjikan\" menjadi \"AI terasa menyebalkan\". Perubahan itu bisa merusak budaya adopsi selama bertahun-tahun.\n\n05\n\n## Empat Fase dalam Pipeline Deployment\n\nPipeline deployment software adalah contoh yang paling konkret, dan polanya bisa dipindahkan ke bidang lain. Empat fase di bawah ini adalah tahapan migrasi di dalam satu pipeline yang sama, bukan izin untuk membuka banyak proyek paralel. Setiap fase boleh dipakai untuk belajar, asal tim punya target dan tenggat yang jelas untuk sampai ke fase 4.\n\nFase 1 · Manual\n\n#### Titik awal mayoritas perusahaan\n\nDeployment jadi kejadian langka dan berisiko. Setiap langkah menunggu persetujuan manusia. Rilis terjadi sekali setiap 1 sampai 2 minggu.\n\nFase 2 · AI-assist\n\n#### Kemajuan awal, tapi belum tujuan\n\nAI membantu triage, analisis root cause, dan memberi saran kode, tapi manusia masih mengendalikan setiap langkah. Testing, build staging, dan rilis ke produksi tetap dijalankan manual. Rilis naik ke 3 sampai 4 kali seminggu. Banyak organisasi berhenti di sini dan menganggapnya sebagai hasil akhir, padahal proses dasarnya belum berubah.\n\nFase 3 · AI-native, masih dipicu manusia\n\n#### Kemajuan besar, tapi belum selesai\n\nAI mengoordinasikan sebagian besar pipeline, tapi manusia masih menekan tombol untuk build staging dan rilis ke produksi. Testing juga masih manual, jadi rilis bermasalah bisa lolos. Kalau tidak sampai menimbulkan kerusakan, itu keberuntungan. Rilis naik ke 25 kali seminggu, tapi feedback loop masih terbuka. Perlakukan fase ini sebagai langkah migrasi menuju fase 4, bukan sebagai tujuan.\n\nFase 4 · AI-native end-to-end\n\n#### AI memegang seluruh alur\n\nAI yang memicu build dan rilis ke produksi, lengkap dengan canary release dan rollback otomatis. Jalur rilis rutin berjalan tanpa gerbang manual, sementara kasus di luar batas kebijakan diteruskan ke manusia. Testing berjalan otomatis lewat regression suite yang belajar dari setiap rilis sebelumnya. Rilis menembus 10 kali sehari dan kualitas justru naik, karena setiap node menghasilkan sinyal yang bisa dianalisis AI.\n\n![Ilustrasi lini produksi yang berubah dari roda gigi manual menjadi sabuk otomatis](https://evanpurnama.com/nanggung-trap/assets/img-06-pipeline.jpg)\n\nRoda gigi yang diputar tangan di satu ujung, sabuk yang berjalan sendiri di ujung lainnya.\n\nNaik dari sekali per 1–2 minggu ke lebih dari 10 kali sehari berarti throughput 100 kali lipat, dengan kualitas yang ikut naik. Lompatan ini muncul ketika **satu sistem AI memegang seluruh alur** dengan shared context dan feedback loop yang tertutup. Menambah jumlah tool AI tidak akan memberi hasil yang sama.\n\nPola ini bisa dipindahkan ke bidang lain: penyelesaian tiket support, kualifikasi sales lead, pemrosesan invoice, moderasi konten, dan rekonsiliasi keuangan. Nama pipeline dan bentuk datanya berubah, polanya tetap sama.\n\n06\n\n## Cara Kerja 5% Perusahaan yang Berhasil\n\nRiset McKinsey dan BCG sampai ke kesimpulan yang mirip soal apa yang membedakan 5% teratas dari 95% sisanya.\n\n![Ilustrasi sekelompok kecil orang di atas bukit dengan teropong, sementara kerumunan besar berjalan di lembah berkabut](https://evanpurnama.com/nanggung-trap/assets/img-07-fewvsmany.jpg)\n\nSegelintir di atas bukit dengan teropong, mayoritas masih di lembah berkabut.\n\nAda lima pola yang berulang di kelompok ini.\n\n1.  **Mereka merombak alur kerja sampai ke akarnya.** McKinsey menemukan perusahaan berkinerja tinggi tiga kali lebih mungkin merancang ulang satu alur kerja, dan langkah ini punya korelasi paling kuat dengan dampak AI ke EBIT.\\[2\\] Di survei lain, 55% perusahaan berkinerja tinggi melaporkan perubahan proses yang mendasar saat menerapkan AI, dibanding hanya 20% di perusahaan lain.\n2.  **Mereka memusatkan sumber daya ke satu masalah bernilai tinggi.** MIT NANDA mencatat lima ciri pada 5% perusahaan yang berhasil: fokus ke satu masalah bernilai tinggi, menanam AI langsung di alur kerja yang berjalan, belajar dari feedback real-time, menyesuaikan diri dengan konteks tiap customer, dan menghindari tool generik yang dipakai untuk semua kebutuhan.\\[1\\] \"Alur kerja yang berjalan\" di sini berarti lingkungan operasi sehari-hari, bukan urutan langkah lama yang dibiarkan utuh. AI bekerja di dalam operasi itu, sementara alur, handoff, dan decision rights tetap dirombak.\n3.  **Mereka menutup feedback loop.** Sistem yang berhasil terus membaik dari koreksi user dan data hasil kerjanya sendiri. Proses belajar tidak berhenti di deployment pertama, sehingga AI naik kelas dari asisten menjadi sistem yang belajar.\n4.  **Mereka berinvestasi lebih agresif di area yang jarang disorot.** BCG menemukan future-built companies, yaitu 5% teratas, berencana membelanjakan 26% lebih banyak untuk IT dan mengalokasikan sampai 64% lebih besar dari anggaran IT itu untuk AI pada 2025.\\[3\\] Dana itu tidak hanya masuk ke tool sales dan marketing yang mudah terlihat, tapi juga ke back-office automation, infrastruktur data, dan perombakan alur kerja.\n5.  **Mereka memanggil spesialis ketika butuh pengalaman dari luar.** MIT NANDA menemukan proyek AI yang dipimpin vendor berhasil di 67% kasus, sementara proyek yang dibangun sendiri hanya 33%.\\[1\\] Angka itu tidak otomatis berarti tim internal lebih lemah. Spesialis datang membawa pelajaran dari puluhan implementasi sebelumnya.\n\nImplementasi yang benar-benar sampai produksi dan menjalankan disiplin ini mencatat rata-rata ROI 540% dalam 18 bulan.\\[5\\] Jarak antara angka itu dan pengalaman perusahaan pada umumnya menunjukkan besarnya selisih antara implementasi yang punya tujuan jelas dan implementasi yang sekadar ikut tren.\n\n07\n\n## Mulai dari Sempit, Selesaikan Sampai Tuntas\n\nEnd-to-end sering disalahartikan sebagai perintah untuk menyalakan semuanya sekaligus. Padahal satuan perubahannya adalah satu proses yang sempit tapi tuntas.\n\n**End-to-end berarti menuntaskan satu pipeline.** Sepuluh pipeline yang semuanya setengah jadi hanya memecah biaya dan perhatian.\n\nPilih satu proses. Idealnya proses yang:\n\n-   Sudah dipahami tim dengan baik, termasuk bottleneck dan kasus-kasus anehnya.\n-   Punya volume data yang cukup untuk membentuk feedback loop. Proses yang jalan sebulan sekali biasanya terlalu jarang.\n-   Punya hasil yang jelas dan bisa diukur, misalnya cycle time atau biaya per kasus.\n-   Cukup penting untuk terasa dampaknya, tapi cukup sempit untuk selesai dalam 3 sampai 6 bulan.\n\nTitik awal yang masuk akal: pipeline deployment, penyelesaian tiket support, kualifikasi sales lead, atau pemrosesan invoice. Target seperti \"AI untuk seluruh tim marketing\" atau \"AI untuk product development\" terlalu luas untuk percobaan pertama.\n\nDorong satu pipeline melewati fase-fase di Bagian 05 sampai satu sistem AI memegang seluruh alur dengan shared context dan feedback loop yang tertutup. Fase AI-assist dan AI-native yang masih dipicu manusia berguna sebagai jalur migrasi, tapi keduanya bukan garis akhir.\n\nSetelah satu pipeline tuntas, perusahaan punya tiga hal: bukti internal bahwa pendekatan ini jalan, infrastruktur data dan playbook yang bisa dipakai ulang, dan tim yang sudah berpengalaman untuk menggarap pipeline kedua lebih cepat.\n\n**Desain end-to-end baru aman dijalankan kalau tim menjaga disiplin operasional.** Gartner memprediksi 40% proyek agentic AI akan dibatalkan pada 2027.\\[5\\] Otonomi menuntut observability, audit trail, dan human review pada kasus kritis. Pemeriksaan ini menangani pengecualian dan keputusan berisiko tinggi, bukan menjadi gerbang rutin di setiap langkah.\n\n08\n\n## Efektivitas dan Safety Lahir dari Desain yang Sama\n\nKalau AI memegang seluruh alur, kesalahan, bias, dan masalah kepatuhan harus diperhitungkan sejak desain awal.\n\nRiset alignment Anthropic pada 2026, \"AI Organizations\", menemukan bahwa menghubungkan banyak AI agent dalam satu organisasi membuat mereka **lebih efektif, tapi bisa menurunkan alignment**. Antar-agent bisa saling memisahkan konteks dan melepas pertimbangan etis masing-masing, sehingga safety satu agent tidak menjamin safety organisasinya secara keseluruhan.\\[8\\]\n\nArtinya sistem end-to-end wajib punya observability sejak hari pertama. Kalau pemeriksaan, batas kebijakan, dan recovery sudah berjalan otomatis, kasus rutin bisa melaju cepat. Perhatian manusia dipusatkan ke anomali dan keputusan berisiko tinggi, sehingga safety tidak berubah jadi alasan untuk memperlambat seluruh pipeline.\n\n![Ilustrasi ruang kendali berdinding kaca dengan tuas dan indikator yang terlihat jelas dari luar](https://evanpurnama.com/nanggung-trap/assets/img-08-transparency.jpg)\n\nRuang kendali berdinding kaca. Semua tuas dan indikatornya terlihat dari luar.\n\nSistem yang benar-benar keluar dari The Nanggung Trap punya lima sifat:\n\n01\n\n**Transparent**Setiap keputusan AI bisa ditelusuri, lengkap dengan konteks di baliknya.\n\n02\n\n**Monitored**Dashboard real-time memantau perilaku, drift, dan anomali.\n\n03\n\n**Human-directed**Manusia menetapkan tujuan dan batasan, lalu meninjau kasus yang meragukan atau berisiko tinggi.\n\n04\n\n**Observed**Setiap langkah meninggalkan sinyal yang bisa diaudit belakangan.\n\n05\n\n**Reversible**Setiap tindakan punya rollback path yang sudah diuji.\n\nPerusahaan yang membangun kelima sifat ini sejak awal justru lebih aman daripada perusahaan yang nanggung. Di sistem yang nanggung, tidak ada satu pun pihak yang bisa melihat utuh apa yang dilakukan AI di tool-tool yang terputus satu sama lain. **Efektivitas dan safety lahir dari arsitektur yang sama.**\n\n09\n\n## Uji Cepat untuk Mendeteksi Nanggung\n\nPakai daftar ini untuk menilai satu proses yang Anda anggap sudah \"memakai AI\":\n\n1\n\nKalau AI-nya dimatikan besok, apakah proses tetap jalan tanpa perubahan berarti? Ya = nanggung.\n\n2\n\nDi kasus rutin, apakah ada manusia yang harus menyetujui output AI sebelum proses lanjut ke langkah berikutnya? Ya di lebih dari 2 titik = nanggung.\n\n3\n\nKalau AI salah hari ini, adakah mekanisme otomatis yang mencegahnya mengulang kesalahan yang sama minggu depan? Tidak = nanggung.\n\n4\n\nBerapa tool berbeda yang harus dilewati proses ini, dan berapa orang yang jadi kabel penghubung antar-tool? Lebih dari 2 handoff = nanggung.\n\n5\n\nApakah Anda punya metrik outcome (cycle time, konversi, biaya per kasus) sebelum dan sesudah AI, dengan angka yang bisa dibandingkan? Tidak = nanggung.\n\n6\n\nKalau CFO bertanya, \"berapa rupiah yang dihemat atau dihasilkan AI tahun ini?\", apakah Anda punya jawaban berupa angka? Tidak = nanggung.\n\nKalau tiga jawaban atau lebih mengarah ke nanggung, posisi Anda sama dengan 95% lainnya. Setidaknya sekarang Anda tahu proses mana yang perlu dibereskan lebih dulu.\n\n—\n\n## Keluar dari The Nanggung Trap\n\nAI sekarang ada di hampir semua tech stack perusahaan. Untuk mengukur kemajuannya, periksa apakah AI sudah memegang satu alur secara utuh atau masih menempel di atas proses lama.\n\nHalf-Baked AI, atau The Nanggung Trap, adalah tahap yang wajar untuk dilalui. Masalah muncul ketika perusahaan bertahan di sana selama 12, 18, atau 24 bulan sambil terus membayar tagihan penuh dan menghabiskan waktu orang-orang terbaiknya untuk mengawasi mesin yang baru setengah jadi.\n\n_Ambil satu pipeline, bawa sampai end-to-end, tuntaskan, lalu ulangi pola yang berhasil di pipeline berikutnya._ Menambah tool AI bisa menunggu.\n\n**Kalau pola 95% dan 5% ini bertahan sampai 2027, mayoritas perusahaan masih akan tertahan di titik yang sama sementara kelompok kecil di depan terus bergerak.** Pilih satu pipeline sekarang, tetapkan hasil yang ingin dicapai, dan beri tim mandat untuk menuntaskannya.\n\n## Referensi\n\n1.  MIT NANDA. _The GenAI Divide: State of AI in Business 2025_. Dilaporkan oleh [Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/), [Forbes](https://www.forbes.com/sites/jaimecatmull/2025/08/22/mit-says-95-of-enterprise-ai-failsheres-what-the-5-are-doing-right/), dan [NDTV](https://www.ndtv.com/offbeat/95-organisations-get-zero-return-from-using-ai-tools-mit-study-shows-9193724).\n2.  McKinsey & Company. [_The State of AI: Global Survey 2025_](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai).\n3.  BCG. [_Are You Generating Value from AI? The Widening Gap_](https://www.bcg.com/publications/2025/are-you-generating-value-from-ai-the-widening-gap), 2025.\n4.  RAND Corporation, meta-analisis terhadap 65 proyek AI perusahaan, 2025. Diringkas oleh [MyBusinessFuture](https://mybusinessfuture.com/en/80-ai-failure-rate-2026-how-rand-and-gartner-expose-the-ai/).\n5.  Gartner, prediksi pembatalan 40% proyek agentic AI pada 2027. Dianalisis oleh [Vortx](https://vortx.ch/gartner-40-of-agentic-ai-projects-canceled-by-2027/).\n6.  MIT Sloan, riset tentang definisi sukses dan pengukuran ROI. Diringkas oleh [Beri.net](https://www.beri.net/article/ai-pilots-95-percent-failure-operationalization-gap).\n7.  Forbes, [MIT Finds 95% of GenAI Pilots Fail Because Companies Avoid Friction](https://www.forbes.com/sites/jasonsnyder/2025/08/26/mit-finds-95-of-genai-pilots-fail-because-companies-avoid-friction/), Agustus 2025.\n8.  Anthropic Alignment Research, _AI Organizations_, 2026.\n9.  The Data Experts, [Enterprise AI Failure Crisis: 95% Failure Rate](https://www.thedataexperts.us/writing/enterprise-ai-failure-crisis-95-percent-failure-rate.html), September 2025.\n10.  The Journal-News (Stacker), [Why 95% of Enterprise AI Projects Fail to Deliver ROI](https://www.thejournal-news.net/premium/stacker/stories/why-95-of-enterprise-ai-projects-fail-to-deliver-roi-a-data-analysis,212052).\n11.  Aevah, [Why 74% of Enterprises Are Getting No Value From AI](https://www.aevah.com/blog/ai-profitability-problem).\n12.  Trullion, [Why 95% of GenAI Projects Fail and Why the 5% That Survive Matter](https://trullion.com/blog/why-95-of-ai-projects-fail-and-why-the-5-that-survive-matter/).\n"},{"id":"7-tools-september-2026:id","slug":"7-tools-september-2026","language":"id","title":"7 Tools AI Agent","url":"https://evanpurnama.com/7-tools-september-2026/","description":"7 tools AI agent untuk kerja sehari-hari: kegunaan, screenshot aplikasi, contoh pekerjaan, dan cara memilihnya. Oleh Evan Purnama, September 2026.","date":"9 September 2026","kind":"presentation","markdown_url":"https://evanpurnama.com/content/7-tools-september-2026.id.md","sha256":"cb3394633a0243c45892cb222070fcd5d22f19f475880931d6fb763aa98d3d7a","text":"Source: https://evanpurnama.com/7-tools-september-2026/\nAuthor: Evan Purnama\nLanguage: id\n\n# 7 Tools  \nAI Agent untuk  \nKerja Sehari-hari\n\nKegunaan, contoh konkret,  \ndan cara memilihnya.\n\n**Evan Purnama**\n\nSeptember 2026 · evanpurnama.com\n\n![Ilustrasi meja kerja dengan komputer, dokumen, dan lengan asisten AI](https://evanpurnama.com/7-tools-september-2026/assets/cover.png)\n\nRiset, otomasi, coding, dan pekerjaan kantor\n\nFitur dapat berubah dalam 6 sampai 12 bulan. Gambaran per September 2026.\n\n## Tujuh kelompok tool, lima kategori\n\n![Ilustrasi berbagai jenis pekerjaan dalam satu organizer](https://evanpurnama.com/7-tools-september-2026/assets/map.png)\n\nCodex + ChatGPT Work dihitung satu kelompok, begitu juga Claude Code + Cowork. Masing-masing tetap dibahas di halaman terpisah.\n\n01\n\n### Workflow & orchestration\n\nn8n\n\n02\n\n### Coding + knowledge-work\n\nCodex + ChatGPT Work; Claude Code + Cowork\n\n03\n\n### Self-hosted personal agent\n\nOpenClaw, Hermes Agent\n\n04\n\n### Research & analysis\n\nPerplexity\n\n05\n\n### Cloud autonomous agent\n\nGrok Bot\n\n![Logo n8n](https://evanpurnama.com/7-tools-september-2026/assets/product/n8n-logo.png)\n\n## n8n\n\nOtomasi alur kerja lintas aplikasi\n\nCanvas visual untuk menyambungkan aplikasi, API, database, dan model AI. Bisa memakai cloud n8n atau infrastruktur sendiri.\n\n### Visual + code\n\nSusun node, tambahkan JavaScript atau Python saat perlu.\n\n### Alur yang berulang\n\nAtur trigger, aturan routing, dan langkah yang membutuhkan approval.\n\nPerlu diperhatikan\n\nSiapkan koneksi dan jalur saat proses gagal. Self-hosting juga perlu pengelolaan server.\n\nDokumentasi: [n8n](https://n8n.io/) [Lisensi](https://docs.n8n.io/sustainable-use-license/)\n\n[Canvas workflow n8n](https://github.com/n8n-io/n8n) · Klik untuk perbesar\n\n> “Setiap tiket WhatsApp masuk, baca intent-nya dan teruskan ke tim CS yang sesuai.”\n\nPesan masuk memicu workflow. LLM mengklasifikasi intent, aturan memilih tim, lalu n8n memperbarui CRM dan mengirim notifikasi ke Slack.\n\n![Logo OpenAI Codex](https://evanpurnama.com/7-tools-september-2026/assets/product/openai-logo.svg)\n\n## OpenAI Codex\n\nKerja di repo lokal atau delegasi ke cloud\n\nCoding agent untuk membaca codebase, mengubah file, dan menjalankan command. CLI bekerja di terminal, Cloud memakai environment terisolasi.\n\n### CLI: interaktif\n\nBahas perubahan sambil memakai repo dan tools di mesin sendiri.\n\n### Cloud: background\n\nDelegasikan task, lalu periksa diff dan hasil test sebelum membuka PR.\n\nPerlu diperhatikan\n\nEnvironment, dependency, dan akses repo harus siap. Review kode dan test tetap diperlukan.\n\nDokumentasi: [Codex CLI](https://learn.chatgpt.com/docs/cli) [Codex Cloud](https://learn.chatgpt.com/docs/cloud)\n\n[Codex CLI di terminal](https://github.com/openai/codex) · Klik untuk perbesar\n\n> “Migrasikan endpoint /v1 ke /v2, pertahankan kompatibilitas, dan tambahkan test.”\n\nCodex mengerjakan perubahan di environment repo. Developer meninjau hasilnya, meminta revisi, lalu melanjutkan pekerjaan dari terminal bila perlu.\n\n![Logo ChatGPT Work](https://evanpurnama.com/7-tools-september-2026/assets/product/chatgpt-work-logo.webp)\n\n## ChatGPT Work\n\nBahan kerja menjadi file yang bisa dipakai\n\nWork mengerjakan task bertahap menggunakan file, aplikasi, dan tools yang tersedia. Bisa bekerja secara lokal atau di cloud.\n\n### Dokumen, sheet, deck\n\nOlah bahan dan riset menjadi file hasil yang dapat diperiksa dan diedit.\n\n### Lokal atau cloud\n\nAkses file dan aplikasi mengikuti tempat task berjalan serta izin workspace.\n\nPerlu diperhatikan\n\nWork di web tidak langsung membaca file atau tab di laptop. Unggah file atau hubungkan aplikasi.\n\nDokumentasi: [ChatGPT Work](https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview)\n\n[ChatGPT Work di web · Demo OpenAI, 4 Sep 2026](https://www.youtube.com/watch?v=NSqlZ1L81nQ) · Klik untuk perbesar\n\n> “Dari CSV ini, buat deck perbandingan 5 vendor SaaS: pricing, fitur AI, dan review pengguna.”\n\nWork membaca CSV, mencari informasi vendor, lalu menyusun tabel perbandingan dan slide. Pengguna mengecek angka, sumber, dan kesimpulan sebelum memakai deck.\n\n![Logo Claude Code](https://evanpurnama.com/7-tools-september-2026/assets/product/claude-logo.png)\n\n## Claude Code\n\nTask engineering dengan konteks codebase\n\nAgent Anthropic untuk bekerja di terminal, IDE, Slack, web, dan desktop. Bisa membagi pekerjaan ke sub-agent sesuai kebutuhan.\n\n### Baca sampai test\n\nMenelusuri repo, mengedit file, dan menjalankan tools pengembangan.\n\n### Sub-agent\n\nPisahkan investigasi, implementasi, atau pemeriksaan dengan konteks masing-masing.\n\nPerlu diperhatikan\n\nTentukan hasil yang diharapkan dan batas akses. Sub-agent menambah kebutuhan koordinasi.\n\nDokumentasi: [Claude Code](https://claude.com/product/claude-code) [Sub-agents](https://code.claude.com/docs/en/sub-agents)\n\n[Claude Code di VS Code](https://claude.com/product/claude-code) · Klik untuk perbesar\n\n> “Buat dashboard analytics dari data BigQuery, ikuti struktur project ini.”\n\nDengan akses yang sesuai, agent memeriksa schema dan komponen yang ada. Subtask dapat menangani query, tampilan, dan test sebelum hasilnya direview.\n\n![Logo Claude Cowork](https://evanpurnama.com/7-tools-september-2026/assets/product/claude-logo.png)\n\n## Claude Cowork\n\nLaporan dan pekerjaan kantor lintas sumber\n\nCowork mengerjakan task bertahap dengan file, riset, dan aplikasi yang terhubung. Sesi cloud dapat berlanjut saat pengguna pergi.\n\n### File + aplikasi\n\nGabungkan bahan kerja menjadi dokumen, spreadsheet, atau presentasi.\n\n### Task terjadwal\n\nJalankan pekerjaan rutin di cloud, misalnya laporan mingguan.\n\nPerlu diperhatikan\n\nCloud masih beta. Periksa akses data dan apakah task bergantung pada komputer lokal.\n\nDokumentasi: [Panduan Cowork](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork)\n\n[Cowork dengan browser di dalam aplikasi](https://claude.com/product/cowork) · Klik untuk perbesar\n\n> “Rangkum email klien minggu ini, cocokkan dengan CRM, lalu buat draft laporan untuk leadership.”\n\nCowork mengambil bahan lewat koneksi yang diberi izin, menyusun laporan, dan menyimpan hasil untuk diperiksa. Akses file lokal membutuhkan aplikasi desktop yang tetap terhubung.\n\n![Logo OpenClaw](https://evanpurnama.com/7-tools-september-2026/assets/product/openclaw-logo.svg)\n\n## OpenClaw\n\nAsisten lewat aplikasi chat sehari-hari\n\nAgent open-source yang bisa dijalankan di komputer sendiri. Pengguna mengaksesnya lewat WhatsApp, Telegram, Slack, dan channel lain.\n\n### Gateway sendiri\n\nHubungkan model, tools, dan channel yang ingin digunakan.\n\n### Akses dari chat\n\nKirim tugas lewat aplikasi pesan, agent mengerjakannya di mesin host.\n\nPerlu diperhatikan\n\nSelf-hosted tidak otomatis berarti semua data tetap lokal. Periksa provider model dan integrasinya.\n\nDokumentasi: [Repo OpenClaw](https://github.com/openclaw/openclaw)\n\n[OpenClaw 2.0 di browser · 30 Agu 2026](https://openclaw.ai/blog/openclaw-2-accidentally) · Klik untuk perbesar\n\n> “Cek email klien X hari ini, ringkas pekerjaan lanjutannya, lalu buat draft balasan.”\n\nDengan integrasi email yang tersedia, OpenClaw membaca inbox dan mengirim draft ke chat. Mesin host tetap menyala meskipun pengguna mengaksesnya dari ponsel.\n\n![Logo Hermes Agent](https://evanpurnama.com/7-tools-september-2026/assets/product/hermes-logo.png)\n\n## Hermes Agent\n\nSkill dan konteks yang dipakai berulang\n\nAgent dari Nous Research dengan memory dan learning loop. Agent dapat membuat skill dari pengalaman, lalu memperbaikinya saat dipakai.\n\n### Memory + skill\n\nSimpan konteks dan cara mengerjakan task untuk sesi berikutnya.\n\n### Host pilihan sendiri\n\nBisa berjalan di mesin sendiri atau server, dengan akses lewat terminal dan chat.\n\nPerlu diperhatikan\n\nSkill yang tersimpan tidak menjamin hasil makin akurat. Sumber dan output tetap perlu dievaluasi.\n\nDokumentasi: [Repo Hermes](https://github.com/nousresearch/hermes-agent)\n\n[Hermes Desktop · Preview PR, 8 Sep 2026 (belum rilis)](https://github.com/NousResearch/hermes-agent/pull/106152) · Klik untuk perbesar\n\n> “Lakukan competitor scan mingguan. Simpan sumber dan format laporan ini untuk minggu depan.”\n\nSetelah task selesai, agent dapat menyimpan metode sebagai skill. Minggu berikutnya, skill membantu mengulang pencarian dan format, sambil memeriksa data terbaru.\n\n![Logo Perplexity](https://evanpurnama.com/7-tools-september-2026/assets/product/perplexity-logo.ico)\n\n## Perplexity\n\nRiset dengan sumber yang bisa dicek\n\nPerplexity membantu mencari dan merangkum informasi. Computer mengerjakan task bertahap, sementara Comet membantu pekerjaan di browser.\n\n### Research\n\nMencari sumber, membandingkan informasi, lalu menyusun analisis.\n\n### Computer + Comet\n\nDelegasi pekerjaan ke sub-agent dan menjalankan aksi di browser sesuai akses.\n\nPerlu diperhatikan\n\nTetap buka sumbernya. Adanya sitasi belum menjamin isi klaimnya tepat.\n\nDokumentasi: [Computer](https://www.perplexity.ai/help-center/en/articles/13837784-what-is-computer) [Comet](https://www.perplexity.ai/comet)\n\n[Computer: proses task dan sub-agent](https://www.perplexity.ai/products/computer) · Klik untuk perbesar\n\n> “Buat draft materi tentang tools AI agent. Cari dokumentasi tiap tool dan sertakan sumbernya.”\n\nDraft awal materi ini dibuat dengan Perplexity Computer. Agent mencari referensi tiap tool, menyusun struktur, lalu merevisi draft mengikuti feedback.\n\n![Logo Grok Bot](https://evanpurnama.com/7-tools-september-2026/assets/product/grok-logo.svg)\n\n## Grok Bot\n\nAgent dengan komputer sendiri di cloud\n\nBot bekerja di komputer cloud yang persisten, memakai browser, file, dan terminal. Dapat memakai connector atau berinteraksi langsung dengan aplikasi.\n\n### Kerja di background\n\nTask tetap berjalan saat pengguna meninggalkan percakapan.\n\n### Aplikasi tanpa API\n\nComputer use membantu pekerjaan yang perlu lewat tampilan browser.\n\nPerlu diperhatikan\n\nBot dalam satu akun berbagi komputer cloud dan login. Pisahkan akses sesuai kebutuhan pekerjaan.\n\nDokumentasi: [Grok Bot](https://docs.x.ai/grok-bot/overview) [Approval](https://docs.x.ai/grok-bot/approvals-security-and-privacy)\n\n[Demo antarmuka Grok Bot](https://x.ai/news/designing-grok-bot) · Klik untuk perbesar\n\n> “Riset 20 prospek, buat draft email personal, lalu simpan ke sheet. Tunggu review sebelum mengirim.”\n\nBot menelusuri situs prospek dan menyiapkan hasil untuk SDR. Batas berhenti sebelum kirim ditetapkan dalam instruksi dan pengaturan approval.\n\n## Tool dan pekerjaan yang cocok\n\nKebutuhan kerja menentukan titik awalnya.\n\n![Alat-alat yang berbeda untuk kebutuhan yang berbeda](https://evanpurnama.com/7-tools-september-2026/assets/compare.png)\n\nTool | Kategori | Fokus | Cocok untuk\nn8n | Workflow | Alur visual lintas aplikasi | Ops, otomasi CS\nCodex + ChatGPT Work | Coding + knowledge-work | Codebase, dokumen, sheet, deck | Developer, ops, analyst\nClaude Code + Cowork | Coding + knowledge-work | Repo, file, aplikasi, task rutin | Engineering, ops, PM\nOpenClaw | Self-hosted personal | Asisten lewat browser dan chat | Pengguna yang mengelola host\nHermes Agent | Self-hosted personal | Memory + skill berulang | Asisten personal berkelanjutan\nPerplexity | Research & analysis | Riset dengan sumber | Riset, analisis, konten\nGrok Bot | Cloud autonomous | Komputer cloud persisten | Sales, ops, riset background\n\nPengelompokan untuk orientasi, bukan ranking kemampuan. Detail akses mengikuti paket dan konfigurasi.\n\n## Satu pekerjaan untuk percobaan pertama\n\n### Alur aplikasi yang berulang\n\nn8n\n\n### Perubahan di codebase\n\nCodex atau Claude Code\n\n### Dokumen dan kerja kantor\n\nChatGPT Work atau Cowork\n\n### Asisten yang di-host sendiri\n\nOpenClaw atau Hermes Agent\n\n### Riset dan sumber\n\nPerplexity\n\n### Pekerjaan di komputer cloud\n\nGrok Bot\n\n![Memilih satu alat sesuai pekerjaan](https://evanpurnama.com/7-tools-september-2026/assets/choose.png)\n\n### Ukuran percobaannya\n\nTentukan satu use case dan hasil yang bisa dicek.\n\nAtur approval untuk kirim, transaksi, atau publish.\n\nHitung waktu bersih yang hemat setelah review dan perbaikan.\n\n## Dokumentasi produk\n\n**n8n**[n8n](https://n8n.io/) [Lisensi](https://docs.n8n.io/sustainable-use-license/)\n\n**OpenAI Codex**[Codex CLI](https://learn.chatgpt.com/docs/cli) [Codex Cloud](https://learn.chatgpt.com/docs/cloud)\n\n**ChatGPT Work**[ChatGPT Work](https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview)\n\n**Claude Code**[Claude Code](https://claude.com/product/claude-code) [Sub-agents](https://code.claude.com/docs/en/sub-agents)\n\n**Claude Cowork**[Panduan Cowork](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork)\n\n**OpenClaw**[Repo OpenClaw](https://github.com/openclaw/openclaw)\n\n**Hermes Agent**[Repo Hermes](https://github.com/nousresearch/hermes-agent)\n\n**Perplexity**[Computer](https://www.perplexity.ai/help-center/en/articles/13837784-what-is-computer) [Comet](https://www.perplexity.ai/comet)\n\n**Grok Bot**[Grok Bot](https://docs.x.ai/grok-bot/overview) [Approval](https://docs.x.ai/grok-bot/approvals-security-and-privacy)\n\n![Buku referensi dan kaca pembesar](https://evanpurnama.com/7-tools-september-2026/assets/sources.png)\n\n### Per September 2026\n\nContoh pekerjaan adalah skenario ilustratif, kecuali pengalaman Perplexity yang tercantum pada draft awal.\n\nWaktu penyelesaian dan hasil bergantung pada task, data, akses, dan konfigurasi.\n"}]}