AI Class

AI Agent Workflow Automation untuk Audit Kode API sebelum Deploy dengan n8n: Auto-Checklist, Risk Scoring, dan Gate CI/CD

· 7 menit baca

AI Agent Workflow Automation untuk Audit Kode API sebelum Deploy dengan n8n: Auto-Checklist, Risk Scoring, dan Gate CI/CD

Kalau kamu pernah deploy perubahan kecil di API lalu tiba-tiba production error (atau lebih halus: latency naik, cost cloud meledak, atau data pelanggan “ke-skip”), kamu tahu masalahnya bukan “kurang jago”. Masalahnya: proses review dan pre-deploy check itu sering nggak konsisten. Hari ini rajin, besok lupa. Dan kalau tim kecil (atau kamu solo founder), review checklist gampang banget jadi formalitas.

Di artikel ini kita akan bikin AI Agent workflow automation yang bertindak sebagai “security + reliability buddy” sebelum deploy: ia baca PR/commit, cek perubahan yang menyentuh endpoint API, jalankan checklist, kasih risk scoring, lalu (kalau perlu) nge-block deploy lewat CI/CD gate. Semua diorkestrasi pakai n8n automation dan integrasi API yang realistis.

Kenapa AI Agent Workflow Automation itu lebih efektif daripada checklist manual

Checklist manual itu bagus… sampai kamu:

  • lagi kejar deadline,
  • ada context switching,
  • reviewer beda-beda standar,
  • atau PR-nya kebanyakan “noise”.

AI Agent bukan pengganti engineer. Tapi untuk pre-deploy audit, dia punya keunggulan: konsisten, cepat, dan bisa dipaksa mengikuti policy. Kamu bisa treat dia seperti “linting untuk proses engineering”: bukan menilai style, tapi menilai risiko.

Yang menarik: saat kamu gabungkan AI Agent dengan n8n (sebagai orchestrator), kamu dapat workflow automation yang bisa:

  • narik data dari GitHub/GitLab,
  • menganalisis diff + file yang berubah,
  • memanggil LLM untuk reasoning + klasifikasi,
  • memanggil tools lain (SAST, unit test, OpenAPI validator),
  • mengambil keputusan (approve/needs-human/block),
  • dan nulis komentar otomatis di PR.

Konsep inti: “Agent sebagai Quality Gate” (bukan sekadar chatbot)

Kebanyakan orang pakai LLM di pipeline hanya buat “ringkas PR”. Itu lucu, tapi nggak mengurangi incident.

Di sini kita pakai pola yang lebih produksi:

  • Policy-driven: agent punya aturan eksplisit (misalnya: perubahan auth wajib ada test; perubahan DB migration wajib ada rollback plan).
  • Evidence-based: agent harus nyebut bukti (file/path, potongan diff, log hasil tool).
  • Decision output: agent mengeluarkan JSON keputusan yang bisa dipakai CI/CD.
  • Human-in-the-loop: kalau risk tinggi tapi masih ambigu, agent minta approval manusia.

Bayangin seperti ini: LLM = otak, n8n = sistem saraf, CI/CD = otot. Tanpa orkestrasi, “otak” cuma ngomong. Dengan orkestrasi, dia bisa bertindak.

AI Agent Workflow Automation (n8n) untuk audit kode API: arsitektur workflow

Target: setiap ada PR ke branch main (atau release/*), workflow jalan dan mengeluarkan keputusan.

1) Trigger: PR opened/synchronize (GitHub/GitLab)

  • Node: GitHub Trigger (atau Webhook + GitLab)
  • Event: pull_request (opened, synchronize, reopened)
  • Filter: base branch == main

2) Ambil context: diff, daftar file berubah, dan metadata

  • Node: GitHub → Get Pull Request
  • Node: GitHub → List Pull Request Files
  • Node: HTTP Request → ambil patch/diff (kalau perlu)

Tip produksi: jangan kirim seluruh repo ke LLM. Kirim delta (diff) dan file yang relevan saja. Ini bikin biaya turun dan hasil lebih tajam.

3) Klasifikasi perubahan: ini menyentuh API atau tidak?

Node: AI (LLM) untuk klasifikasi cepat berdasarkan paths, misalnya:

  • src/routes/*, controllers/*, openapi.yaml → API surface
  • auth/*, middleware/* → security critical
  • db/migrations/* → data risk

Output yang kita mau:

{
  "touches_api": true,
  "touches_auth": false,
  "touches_migrations": true,
  "suspected_breaking_change": true,
  "why": ["openapi.yaml modified", "migration adds NOT NULL"]
}

4) Jalankan “cheap deterministic checks” sebelum panggil agent besar

Ini bagian yang sering dilewati padahal paling ngaruh. LLM itu mahal dan kadang halu. Jadi lakukan dulu pengecekan yang pasti:

  • OpenAPI lint/validate (mis: Spectral)
  • Unit test minimal subset (atau pastikan ada test files berubah)
  • Dependency diff kalau package-lock/pnpm-lock berubah
  • Secret scan (mis: gitleaks) untuk diff PR

Di n8n kamu bisa:

  • Panggil GitHub Actions workflow dan tunggu hasilnya, atau
  • Jalankan containerized tool via webhook/internal runner, atau
  • Panggil API layanan SAST/DAST yang kamu pakai.

5) AI Agent audit: reasoning + risk scoring + rekomendasi fix

Node: AI Agent (LLM) yang menerima:

  • PR description + title
  • Daftar file + patch penting (truncate per file)
  • Hasil tool deterministic (pass/fail + log ringkas)
  • Policy organisasi (dalam bentuk aturan singkat)

Agent mengeluarkan JSON keputusan, misalnya:

{
  "decision": "BLOCK" | "NEEDS_REVIEW" | "PASS",
  "risk_score": 0-100,
  "risk_factors": [
    {"type":"BREAKING_CHANGE","evidence":"openapi.yaml: removed /v1/orders/{id}","severity":"high"},
    {"type":"DATA_MIGRATION","evidence":"migration adds NOT NULL without backfill","severity":"high"}
  ],
  "required_actions": [
    "Add backward compatible field strategy or version endpoint",
    "Provide backfill step or default value for NOT NULL",
    "Add test covering auth edge case"
  ],
  "suggested_comment": "..."
}

6) Gate CI/CD: publish status check + comment PR

  • Node: GitHub → Create Commit Status atau Check Run
  • Node: GitHub → Create Comment di PR dengan ringkasan
  • Jika BLOCK: status check = failed → merge terblokir
  • Jika NEEDS_REVIEW: status = neutral + mention reviewer tertentu
  • Jika PASS: status = success

AI Agent Workflow Automation: contoh use case real (yang kejadian banget)

Use case: “Perubahan kecil” di endpoint checkout yang bikin order nyangkut

Skenario: kamu ubah payload POST /checkout dengan menambah field wajib customerPhone karena butuh untuk kurir. Di frontend web sudah diupdate, tapi ada mobile app versi lama yang masih kirim payload tanpa field itu.

Tanpa gate, PR ini kemungkinan lolos karena:

  • unit test backend masih hijau (test tidak cover client versi lama),
  • reviewer fokus ke logic baru,
  • tidak ada yang ingat backward compatibility.

Dengan AI Agent workflow automation di n8n:

  • Agent melihat openapi.yaml berubah: field baru jadi required.
  • Agent mendeteksi potensi breaking change karena kontrak API berubah (required field).
  • Agent memberi risk score tinggi dan mem-block merge dengan rekomendasi:
    • jadikan field optional sementara + validasi conditional, atau
    • buat endpoint versi baru /v2/checkout, atau
    • terapkan default/backfill strategy.

Aha moment: agent bukan cuma “ngomong ini breaking change”, tapi mengubah struktur keputusan engineering: kalau kontrak API berubah, merge harus punya mitigasi eksplisit.

Breakdown prompt & policy yang bikin agent kamu nggak generik

Bagian paling penting bukan modelnya. Tapi policy + format output. Ini template policy ringkas yang biasanya cukup “tajam” untuk audit API:

  • API contract: perubahan OpenAPI yang menghapus endpoint/field required → minimal NEEDS_REVIEW, sering BLOCK jika tanpa strategi versi.
  • Auth: perubahan middleware/authz tanpa test tambahan → BLOCK.
  • Migrations: tambah NOT NULL/unique/index heavy tanpa backfill/plan → BLOCK.
  • Observability: perubahan critical path tanpa log/metric/tracing update → minimal NEEDS_REVIEW.
  • Rate limit / idempotency: endpoint pembayaran/checkout harus idempotent; perubahan yang menghapus idempotency key → BLOCK.

Dan kamu wajib paksa output JSON. Ini trik sederhana agar n8n bisa bikin keputusan tanpa “menafsirkan teks”.

Strategi paling penting: jadikan workflow ini “murah, cepat, dan tahan banting”

Kebanyakan orang gagal karena agent dipasang “di semua PR”, biayanya mahal, dan akhirnya dimatikan. Ini strategi yang lebih waras:

1) Routing pintar: panggil agent hanya untuk PR berisiko

  • Jika file berubah hanya README / UI non-API → skip agent, langsung PASS.
  • Jika menyentuh openapi/auth/migrations → panggil agent + tool.

2) Gunakan “two-pass”: small model untuk klasifikasi, big model untuk audit

  • Pass 1: model murah untuk label risiko & memilih snippet diff penting.
  • Pass 2: model lebih kuat untuk reasoning dan rekomendasi fix.

3) Simpan memori sebagai artefak, bukan chat memory

Yang kamu butuhkan adalah audit trail: keputusan, risk factors, evidence, timestamp. Simpan ke:

  • Postgres / Supabase
  • Notion/Confluence (opsional)
  • atau langsung sebagai komentar PR (yang bisa dicari)

4) Buat “escape hatch” yang aman

Ada kondisi darurat. Sediakan override, tapi harus tercatat:

  • label PR: override-risk
  • hanya bisa dipakai role tertentu
  • wajib alasan + link incident ticket

5) Ukur dampak: bukan “agent keren”, tapi incident turun

Tambahkan metrik sederhana:

  • berapa PR yang di-block
  • berapa yang akhirnya fixed sebelum merge
  • berapa incident terkait breaking change setelah workflow aktif

Ini yang bikin kamu bisa justify workflow ini sebagai investasi engineering, bukan gimmick AI.

Mini blueprint node n8n (yang bisa kamu build hari ini)

  • GitHub Trigger → PR event
  • GitHub: Get PR
  • GitHub: List PR Files
  • Code node: filter file & truncate patch
  • LLM node (small): classify + select top diffs
  • HTTP Request: run OpenAPI lint / gitleaks / test (via CI endpoint)
  • LLM node (agent): audit + JSON decision
  • IF node: decision router
  • GitHub: Create Check Run + Comment PR
  • DB node: store audit log

Penutup: build quality gate pertamamu, lalu iterasi ala vibe coding

Kalau kamu lagi build SaaS cepat dengan AI, satu hal yang sering kelupaan adalah quality gate. Padahal makin cepat kamu ship, makin besar peluang kamu ship bug. Ironis.

Mulai dari versi minimal:

  • deteksi perubahan OpenAPI + migration
  • risk score + komentar PR
  • block hanya untuk aturan yang jelas (NOT NULL tanpa backfill, breaking change tanpa versioning)

Lalu iterasi dengan gaya vibe coding: tambahkan aturan sedikit demi sedikit berdasarkan incident beneran yang kamu alami. Dalam 1–2 minggu, kamu akan punya AI Agent workflow automation yang terasa seperti “reviewer tambahan” yang selalu on, nggak capek, dan nggak baper.

Call to action: kalau kamu mau, kasih tahu stack kamu (GitHub/GitLab, bahasa backend, pakai OpenAPI atau tidak, CI tool apa). Nanti aku bantu turunkan menjadi template n8n yang siap kamu impor + prompt/policy yang sesuai produkmu.

Artikel terkait