AI-Generated Code Risk: Mengapa Development Cepat Tetap Membutuhkan Guardrail Enterprise

AI telah mengubah economics dari software development. Bagian pekerjaan yang sebelumnya membutuhkan developer menulis kode secara manual selama berjam-jam kini dapat dimulai dari prompt, specification, existing codebase, atau issue description dan menghasilkan draft implementasi dalam hitungan menit. Perubahan ini membuat prototype lebih cepat dibuat, repetitive code lebih mudah dihasilkan, dan developer dapat bergerak lebih cepat ketika bekerja dengan framework atau bagian sistem yang belum terlalu familiar.

Namun percepatan pada tahap menulis kode tidak otomatis membuat keseluruhan software delivery menjadi lebih cepat, lebih murah, atau lebih aman. Semakin mudah organisasi menghasilkan code, semakin besar pula volume perubahan yang harus dipahami, diuji, direview, diintegrasikan, diamankan, dan dipertanggungjawabkan sebelum masuk ke production. Dalam enterprise environment, bottleneck mulai berpindah: dari kemampuan menghasilkan kode menuju kemampuan membuktikan bahwa perubahan tersebut benar-benar layak dijalankan di sistem bisnis.

Perubahan tersebut penting karena enterprise software tidak beroperasi sebagai kumpulan fitur yang berdiri sendiri. Satu perubahan pada pricing logic dapat memengaruhi invoice. Perubahan pada customer model dapat memengaruhi CRM, ERP, reporting, dan integration API. Kesalahan authorization dapat membuka akses lintas tenant. Dependency baru dapat memperbesar attack surface. Logic yang terlihat benar pada happy path dapat gagal ketika berhadapan dengan concurrency, incomplete data, exception workflow, atau transaction volume yang sebenarnya.

Karena itu, diskusi mengenai AI coding sebaiknya tidak berhenti pada pertanyaan “seberapa cepat AI dapat membuat software?”. Pertanyaan yang lebih relevan bagi enterprise adalah: seberapa cepat organisasi dapat menghasilkan perubahan software yang tetap benar, aman, maintainable, terintegrasi, dan dapat dirilis tanpa meningkatkan risiko bisnis?

DORA menggambarkan AI dalam software development sebagai sebuah amplifier. Berdasarkan State of AI-assisted Software Development 2025, 90% technology professionals yang disurvei menggunakan AI dalam pekerjaan dan lebih dari 80% menilai AI meningkatkan produktivitas mereka. Namun analisis DORA yang dipublikasikan pada Maret 2026 juga menunjukkan trade-off yang penting: AI mempercepat initial code generation, tetapi sebagian waktu yang dihemat kemudian berpindah ke auditing dan verification. DORA juga menemukan hubungan antara adopsi AI yang lebih tinggi dengan meningkatnya delivery throughput sekaligus meningkatnya delivery instability. (Dora)

Artinya, AI dapat membuat organisasi bergerak lebih cepat. Tetapi jika engineering system di bawahnya lemah, organisasi juga dapat bergerak lebih cepat menuju technical debt, production incident, dan software complexity.

Apa yang Dimaksud dengan AI-Generated Code Risk?

AI-generated code risk adalah risiko yang muncul ketika kode yang dihasilkan atau dimodifikasi menggunakan generative AI masuk ke software development lifecycle tanpa context, architectural constraint, verification, security control, dan ownership yang memadai.

Risikonya bukan berarti AI selalu menghasilkan kode buruk. AI coding tools dapat sangat efektif untuk membuat boilerplate, membantu refactoring, menulis test, menjelaskan codebase, menyelesaikan repetitive implementation, atau mempercepat eksplorasi technical solution. Persoalannya adalah code generation bersifat probabilistik, sedangkan production software membutuhkan hasil yang dapat diverifikasi secara deterministik melalui specification, architecture, testing, security control, dan runtime evidence.

Bahkan GitHub dalam dokumentasi responsible use untuk Copilot Agents menyatakan bahwa generated code dapat terlihat valid tetapi tetap tidak benar secara semantic atau syntactic, tidak sepenuhnya sesuai dengan intent developer, atau mengandung security issue. Karena itu, output tetap perlu direview dan diuji sebelum digunakan pada application yang kritis atau sensitif. (GitHub Docs)

Perbedaan antara “code berhasil dibuat” dan “software siap digunakan bisnis” inilah yang menjadi pusat risiko.

AI Membuat Code Generation Murah, tetapi Verification Tetap Mahal

Secara tradisional, menulis code merupakan salah satu aktivitas yang menyerap banyak waktu developer. AI menurunkan cost of creation tersebut secara drastis. Seorang engineer sekarang dapat meminta AI membuat API endpoint, database migration, validation layer, test case, UI component, atau integration adapter dalam waktu yang jauh lebih singkat.

Namun software development bukan hanya proses menghasilkan source code. Setiap perubahan tetap harus menjawab beberapa pertanyaan: apakah requirement dipahami dengan benar, apakah data model konsisten, apakah perubahan menghormati architecture boundary, apakah permission benar, apakah existing behavior rusak, apakah edge case sudah tertangani, dan apakah sistem tetap mampu berjalan ketika workload meningkat.

DORA menyebut salah satu konsekuensi ini sebagai verification tax. Dalam analisis terhadap lebih dari 1.100 respons software engineer Google pada 2025, AI menunjukkan peningkatan velocity di berbagai aktivitas engineering, tetapi verification overhead dan hallucination muncul secara konsisten sebagai friction. Developer dapat menghemat waktu ketika membuat draft, tetapi sebagian penghematan tersebut harus digunakan kembali untuk mengaudit apakah output benar. (Dora)

Fenomena tersebut memiliki implikasi organisasi. Jika seorang developer dapat membuat pull request lima kali lebih cepat tetapi reviewer, testing infrastructure, security pipeline, dan deployment process tetap memiliki kapasitas lama, organisasi tidak mendapatkan delivery system yang lima kali lebih cepat. Organisasi hanya memindahkan antrean dari coding menuju review dan validation.

Karena itu, AI tidak menghilangkan cost of software engineering; AI mengubah di mana cost tersebut muncul.

Prototype Speed dan Production Readiness Adalah Dua Hal Berbeda

Salah satu efek paling menarik dari AI coding adalah kemampuannya membuat prototype terlihat hampir selesai dalam waktu sangat singkat. Interface sudah tampil, API dapat menerima request, database terkoneksi, dan workflow utama berjalan. Bagi stakeholder non-teknis, kondisi seperti ini mudah memberikan kesan bahwa 80–90% pekerjaan telah selesai.

Namun enterprise production readiness memiliki lapisan yang biasanya tidak terlihat pada demo pertama. Authentication dan authorization harus benar untuk berbagai role. Data validation perlu menghadapi input abnormal. Integration membutuhkan timeout, retry, idempotency, dan failure handling. Database perlu mempertimbangkan concurrency serta transaction integrity. Logging harus cukup untuk investigasi incident. Sensitive data tidak boleh muncul pada log. Deployment harus dapat diulang. Migration harus aman. Application perlu tetap berjalan saat dependency eksternal gagal.

DORA juga menemukan adanya workflow gap antara rapid prototyping dan production integration. AI dapat menurunkan barrier untuk memulai pekerjaan, tetapi bagian terakhir menuju production membutuhkan precision, integration dengan internal system, dan penanganan edge case yang lebih besar. (Dora)

Karena itu, project estimation tidak dapat hanya diturunkan secara proporsional karena AI mampu menghasilkan initial implementation lebih cepat. Organisasi perlu melihat keseluruhan value stream dari requirement hingga production, bukan hanya waktu yang dibutuhkan untuk menghasilkan source code.

Mengapa Risiko AI-Generated Code Lebih Besar pada Enterprise System?

Kesalahan pada prototype biasanya memiliki blast radius terbatas. Kesalahan pada enterprise software dapat memengaruhi transaksi, financial reporting, inventory, customer data, approval, compliance, atau aktivitas operasional antar-departemen.

Enterprise system juga memiliki context yang jauh lebih besar daripada apa yang dapat terlihat dari satu prompt atau satu repository. Business rule mungkin berasal dari regulatory requirement. Sebuah field mungkin digunakan oleh tiga aplikasi lain. Database table yang terlihat redundant mungkin dipertahankan karena reconciliation process. API tertentu mungkin memiliki backward compatibility requirement untuk partner yang tidak dapat segera melakukan upgrade.

AI dapat memahami bagian codebase yang diberikan kepadanya, tetapi belum tentu memahami seluruh konsekuensi organisasional dari perubahan tersebut.

Inilah mengapa artikel sebelumnya mengenai AI-Native Software Development perlu dibedakan dari persoalan guardrail. AI-native development membahas bagaimana AI mulai mengubah cara software dibuat. Artikel ini membahas pertanyaan berikutnya: mekanisme apa yang memastikan peningkatan velocity tersebut tidak menurunkan reliability enterprise software?

Lima Lapisan Risiko AI-Generated Code

Risiko AI coding sebaiknya tidak dipandang sebagai satu kategori “AI bisa salah”. Dalam enterprise environment, risiko berada pada beberapa lapisan yang saling berhubungan.

Pemisahan tersebut penting karena tidak semua risk dapat diselesaikan menggunakan code review. Reviewer mungkin dapat menemukan coding mistake, tetapi sulit mendeteksi missing business requirement jika specification tidak jelas. Automated test dapat memastikan behavior tertentu tetap bekerja, tetapi tidak menentukan apakah architecture decision tepat. Security scanner dapat menemukan vulnerability pattern, tetapi belum tentu mengetahui bahwa sebuah API memberikan akses bisnis terlalu luas.

Guardrail yang efektif karena itu harus membentuk sebuah system of controls, bukan bergantung pada satu checkpoint.

Guardrail 1: Mulai dari Specification, Bukan dari Prompt

AI menghasilkan jawaban berdasarkan instruction dan context yang diberikan. Jika requirement ambigu, AI dapat menghasilkan implementation yang terlihat masuk akal tetapi berbeda dari business intent yang sebenarnya.

Itulah alasan Spec-Driven Development semakin relevan ketika AI mulai menulis lebih banyak code. Specification menyediakan kontrak tentang behavior yang diharapkan sebelum implementation dibuat.

Untuk enterprise system, specification tidak harus selalu menjadi dokumen panjang. Yang lebih penting adalah kejelasan mengenai business rule, input-output, role dan permission, exception scenario, integration dependency, acceptance criteria, serta constraint yang tidak boleh dilanggar.

Misalnya, instruksi “buat auto-approval untuk purchase order di bawah Rp50 juta” terlihat sederhana. Namun specification perlu menjelaskan apakah threshold berlaku per transaction atau cumulative supplier exposure, siapa yang dapat mengubah limit, bagaimana jika currency berbeda, bagaimana approval ditangani saat supplier sedang diblokir, dan apakah audit trail tetap dibutuhkan.

AI dapat mempercepat implementation setelah keputusan tersebut jelas. AI sebaiknya tidak digunakan untuk secara implisit membuat keputusan bisnis yang belum pernah disepakati organisasi.

Guardrail 2: Architecture Harus Membatasi Apa yang Boleh Dibuat AI

Salah satu risiko AI-assisted development adalah local optimization. AI dapat menghasilkan implementation yang bekerja pada file atau module tertentu tanpa memahami architectural consistency keseluruhan system.

Hari ini AI membuat query langsung dari UI ke database karena terlihat paling sederhana. Besok module lain membuat business logic di API route. Berikutnya integration melakukan bypass domain service. Setiap perubahan mungkin bekerja secara individual, tetapi dalam beberapa bulan architecture kehilangan boundary dan system menjadi semakin sulit diuji, diamankan, dan diubah.

Karena itu, architecture perlu berfungsi sebagai constraint terhadap generation. AI harus mengetahui module boundary, dependency direction, data-access pattern, validation rule, error-handling convention, authentication mechanism, dan contract antarsystem.

Ini tidak berarti enterprise membutuhkan architecture yang kaku. Justru, architecture yang modular memungkinkan AI bergerak cepat di dalam boundary yang jelas tanpa membuat setiap generated feature menciptakan design pattern baru.

Prinsipnya adalah: AI boleh mempercepat implementation, tetapi tidak seharusnya mendefinisikan ulang architecture secara diam-diam setiap kali menghasilkan code.

Guardrail 3: Automated Testing Harus Tumbuh Secepat Code Generation

Ketika kemampuan menghasilkan code meningkat, manual testing tidak dapat menjadi satu-satunya mekanisme verification. Kecepatan creation akan selalu mengalahkan kapasitas manusia untuk mengecek setiap perubahan secara manual.

Di sinilah automated testing berubah dari engineering best practice menjadi scaling mechanism untuk AI development.

NIST dalam proyek DevSecOps Practices menempatkan automation, CI/CD dengan security checks, monitoring, vulnerability management, serta automated security testing sebagai bagian penting dari secure software development. Untuk penggunaan AI, NIST juga menekankan bahwa AI-generated content tetap membutuhkan human validation dan verifiable process untuk memastikan accuracy serta trustworthiness. (NIST Pages)

Automated test memberikan verifiable evidence tersebut. Unit test memvalidasi local business logic. Integration test memastikan dependency bekerja sesuai contract. End-to-end test memvalidasi business flow. Regression test memastikan perubahan baru tidak merusak behavior existing.

Yang berubah di era AI adalah hubungan antara test dan velocity. Ketika AI dapat menghasilkan implementation dengan cepat tetapi test suite lambat, rapuh, atau tidak lengkap, perusahaan mendapatkan code generation acceleration tanpa delivery acceleration.

DORA juga merekomendasikan fast feedback, test automation, serta perubahan kecil dan mudah direview sebagai countermeasure ketika AI mempercepat volume perubahan. (Dora)

Guardrail 4: Security Harus Masuk ke Pipeline, Bukan Menunggu Audit Akhir

AI coding juga mengubah security workload. Semakin banyak code yang dapat dibuat, semakin banyak pula input validation, access control, API, dependency, database query, dan configuration yang perlu diverifikasi.

GitHub secara eksplisit mengingatkan bahwa AI-generated suggestions dapat mengandung security vulnerabilities dan tetap harus diuji serta direview, khususnya untuk application yang sensitif. (GitHub Docs)

Pendekatan yang lebih scalable adalah memindahkan sebagian security control ke development pipeline. Static analysis, dependency scanning, secret detection, infrastructure policy, automated security test, dan permission test dapat memberikan feedback sebelum perubahan mencapai production.

Prinsip tersebut sejalan dengan Secure Software Development Framework dari NIST. SSDF dirancang agar secure development practices terintegrasi ke dalam software development lifecycle, bukan menjadi aktivitas tambahan setelah software selesai dibuat. Framework tersebut mengelompokkan praktik menjadi preparing the organization, protecting software, producing well-secured software, serta responding to vulnerabilities. (NIST Computer Security Resource Center)

NIST juga telah menambahkan SP 800-218A sebagai companion untuk aspek generative AI dan AI system development, yang memperluas secure development considerations sepanjang lifecycle. (NIST)

AI mempercepat coding. Karena itu security juga perlu bergerak lebih awal dan lebih otomatis.

Guardrail 5: Human Review Berubah dari Penulis Kedua Menjadi Risk Owner

Munculnya AI coding bukan berarti code review kehilangan relevansi. Namun fungsi reviewer perlu berubah.

Pada model tradisional, reviewer banyak memeriksa implementation detail: naming, pattern, duplicate logic, style, edge case, dan correctness. Ketika volume AI-generated code meningkat, pendekatan manual line-by-line pada setiap perubahan dapat menjadi bottleneck baru.

DORA menyarankan agar lebih banyak automated feedback diberikan kepada author sebelum code sampai ke reviewer. Automated checks, AI-assisted review, test, dan organizational standards sebaiknya menangkap issue mekanis lebih awal sehingga manusia dapat memusatkan attention pada hal yang membutuhkan judgment: apakah design masuk akal, apakah business rule benar, apakah blast radius dipahami, apakah permission tepat, dan apakah solusi menciptakan technical debt baru. (Dora)

Dengan kata lain, review bergeser dari sekadar “apakah code ini terlihat benar?” menjadi “apakah perubahan ini layak menjadi bagian dari sistem enterprise?”

Pembahasan mengenai proses review sendiri sudah dimiliki Crocodic melalui Code Review: Investasi Kecil yang Mencegah Kerugian Besar. Dalam konteks AI-generated code, review tersebut perlu ditempatkan sebagai satu bagian dari guardrail system, bukan sebagai satu-satunya defence.

Small Batch Menjadi Lebih Penting Ketika AI Semakin Cepat

AI dapat mendorong developer menghasilkan pull request yang semakin besar karena banyak implementation dapat dibuat dalam waktu singkat. Ironisnya, large batch dapat menghilangkan sebagian keuntungan tersebut.

Perubahan besar membutuhkan lebih banyak cognitive load untuk direview, lebih sulit ditest secara terisolasi, memiliki lebih banyak kemungkinan interaction, dan memperbesar blast radius jika gagal.

DORA secara khusus menempatkan working in small batches sebagai countermeasure terhadap risiko AI-assisted development. Ketika perubahan dipecah menjadi unit kecil yang reviewable dan testable, peningkatan individual productivity lebih mudah diterjemahkan menjadi real software delivery performance. (Dora)

Karena itu, AI development tidak seharusnya diukur dari seberapa banyak code yang dapat dibuat dalam satu sprint. Ukuran yang lebih sehat adalah seberapa cepat verified business change dapat bergerak dari requirement menuju production.

Inilah salah satu perbedaan terbesar antara fast coding dan fast delivery.

Crocodic AI Code Guardrail Stack

Dari perspektif enterprise engineering, hubungan antara AI dan software quality dapat dilihat melalui enam lapisan:

Business Intent → Specification → Architecture Constraint → Automated Verification → Human Accountability → Production Feedback

Business intent memastikan software menyelesaikan masalah yang bernilai. Specification menerjemahkan intent tersebut menjadi behavior yang dapat diuji. Architecture constraint menjaga setiap implementation tetap berada dalam structure system yang konsisten. Automated verification memberi bukti bahwa perubahan memenuhi correctness dan security requirement. Human accountability memastikan keputusan kritis tetap memiliki owner. Production feedback kemudian membuktikan apakah system benar-benar bekerja pada kondisi nyata.

Keenam lapisan tersebut menghasilkan perubahan penting dalam cara kita melihat produktivitas AI.

Produktivitas tidak lagi cukup dihitung dari berapa cepat developer menghasilkan code.

Produktivitas perlu dilihat dari berapa cepat organisasi mengubah business intent menjadi verified production value tanpa menaikkan operational risk.

Framework ini juga menjelaskan mengapa perusahaan dengan engineering foundation yang kuat cenderung mendapatkan keuntungan lebih besar dari AI. DORA menemukan bahwa AI bekerja sebagai amplifier: organisasi dengan platform, API, workflow, dan testing practice yang kuat memperoleh leverage, sedangkan masalah yang sudah ada dapat ikut diperbesar pada organisasi dengan infrastructure atau process yang lemah. (Dora)

Jangan Mengukur Keberhasilan AI Coding dari Lines of Code

Lines of code menjadi semakin tidak relevan ketika AI dapat menghasilkan ribuan baris code hampir tanpa marginal effort. Bahkan jumlah pull request atau jumlah story yang selesai dapat memberikan gambaran yang menyesatkan jika output meningkat tetapi rework, incident, atau technical debt ikut meningkat.

DORA juga memperingatkan bahwa AI dapat menginflasi volume code sehingga output-based metric tidak cukup untuk mengukur produktivitas engineering. Mereka merekomendasikan pengukuran yang lebih holistik melalui delivery flow dan downstream outcomes. (Dora)

Untuk enterprise, evaluasi dapat menghubungkan velocity dengan quality melalui indikator seperti lead time perubahan, review turnaround, escaped defect, change failure, rework, deployment frequency, incident rate, recovery time, dan business outcome dari fitur yang dirilis.

Logikanya sederhana. Jika AI membuat coding 50% lebih cepat tetapi jumlah defect dan rework meningkat sehingga release tetap membutuhkan waktu yang sama, business value belum meningkat secara signifikan. Jika AI mempercepat delivery sekaligus menjaga stability dan mengurangi cycle time, barulah perusahaan mendapatkan leverage nyata.

Risiko Terbesarnya Bukan AI Menulis Kode Buruk, tetapi Organisasi Kehilangan Kontrol

Fokus berlebihan pada pertanyaan apakah AI dapat menulis code “sebagus developer” dapat mengalihkan perhatian dari persoalan yang lebih besar.

AI coding mengubah rate of change dalam software system.

Ketika rate tersebut meningkat, organisasi memerlukan kemampuan yang lebih kuat untuk mengendalikan perubahan. Jika tidak, jumlah code dapat tumbuh lebih cepat dibandingkan kemampuan perusahaan untuk memahami codebase-nya sendiri.

Ini berhubungan langsung dengan Technical Debt: Mengapa Kode Buruk Menggerogoti Profit?. Technical debt di era AI tidak hanya berasal dari developer mengambil shortcut secara manual. Debt juga dapat muncul ketika generated implementation diterima karena “sudah bekerja”, sementara consistency, maintainability, duplication, dependency, dan future change cost tidak pernah diperiksa secara sistematis.

AI dapat mempercepat pembuatan solusi sekaligus mempercepat akumulasi complexity jika guardrail tidak ikut berkembang.

Masalah enterprise bukan kekurangan code. Masalahnya adalah memastikan setiap perubahan code tetap berada di bawah kendali architecture, security, dan business intent.

Bagaimana CIO dan CTO Menilai Kesiapan AI-Assisted Development?

Technology leader tidak perlu memilih antara dua ekstrem: melarang AI coding atau membiarkan developer menggunakan AI tanpa batas. Pertanyaan yang lebih berguna adalah apakah software delivery system sudah mampu menyerap peningkatan velocity yang diberikan AI.

Organisasi yang siap biasanya memiliki requirement dan ownership yang cukup jelas, architecture boundary yang terdokumentasi, version control yang disiplin, automated test yang dapat dipercaya, security check di pipeline, review process yang efektif, serta observability setelah release. Ketika komponen tersebut tersedia, AI dapat meningkatkan throughput tanpa membuat setiap peningkatan kecepatan menjadi peningkatan risiko yang sama besar.

Sebaliknya, jika application landscape sudah penuh hidden dependency, test sedikit, deployment manual, architecture tidak konsisten, dan production issue sulit ditelusuri, menambahkan AI coding dapat mempercepat output tetapi juga memperbesar downstream disorder.

DORA merangkum kondisi tersebut dengan sangat relevan: AI bukan pengganti engineering system yang baik. Ia memperbesar karakter system yang sudah dimiliki organisasi. (Dora)

Crocodic Perspective: AI Harus Mempercepat Value, Bukan Hanya Code

Dari perspektif Crocodic, AI-assisted development sebaiknya tidak dimulai dari target “membuat software secepat mungkin”. Targetnya adalah memperpendek jarak antara business problem dan measurable solution tanpa menurunkan reliability.

Perubahan tersebut membutuhkan dua mesin yang berjalan bersamaan. Mesin pertama adalah generation engine: AI membantu specification, coding, testing, debugging, documentation, dan repetitive engineering work. Mesin kedua adalah verification engine: architecture rule, automated test, security control, code review, deployment pipeline, dan production monitoring memastikan output tetap berada di bawah kendali.

Jika hanya generation engine yang dipercepat, organisasi menghasilkan lebih banyak change daripada yang mampu diverifikasi. Jika verification engine berkembang bersamaan, AI mulai memberikan leverage pada keseluruhan delivery system.

Karena itu, pertanyaan strategis bagi enterprise bukan lagi:

“Apakah kita menggunakan AI untuk coding?”

Pertanyaannya menjadi:

“Apakah software delivery system kita cukup kuat untuk menerima perubahan dengan kecepatan yang sekarang dapat dihasilkan AI?”

Perbedaan tersebut menentukan apakah AI menjadi productivity multiplier atau technical-debt multiplier.

Kesimpulan

AI-generated code bukan sesuatu yang perlu dihindari. Kemampuan AI untuk menghasilkan, memahami, dan memodifikasi software kemungkinan akan menjadi bagian normal dari enterprise engineering. Data DORA menunjukkan bahwa adopsinya sudah sangat luas dan developer melihat manfaat produktivitas yang nyata. (Dora)

Namun semakin murah cost of code generation, semakin penting kemampuan organisasi untuk melakukan verification. Specification perlu menjaga intent. Architecture menjaga structure. Automated testing menjaga behavior. Security pipeline menjaga exposure. Human review menjaga judgment. Observability menjaga feedback setelah perubahan sampai ke production.

Enterprise yang hanya mempercepat coding akan mendapatkan lebih banyak software change. Enterprise yang membangun AI coding guardrails dapat mengubah percepatan tersebut menjadi business value.

Bagi perusahaan yang mulai mengadopsi AI-assisted development pada sistem kritis, assessment sebaiknya tidak hanya melihat tool AI yang digunakan. Evaluasi perlu mencakup existing architecture, development workflow, testing maturity, integration dependency, security control, dan deployment process. Dari sana, perusahaan dapat menentukan apakah existing system sudah siap untuk accelerated development atau membutuhkan penguatan fondasi terlebih dahulu melalui Custom Enterprise Software maupun modernization terhadap sistem yang sudah berjalan.

Dengan fondasi tersebut, AI tidak menggantikan engineering discipline. AI justru membuat engineering discipline menjadi semakin penting.