Mikko Laakkonen (@mikkolaakkonen) on X

What it is

Mikko Laakkonen's checklist for enterprises that want staff to vibe code internal apps: 200 application checks plus 16 EU bonus checks (numbered 201-216). It is meant as a gate for apps that outgrow experimentation. A 300-check version with 36 EU checks and a worksheet is linked at tai.ga. The page text cuts off partway through the quoted Mark Ajzenstadt post, so that post's content is not covered here.

How to use it

• Select only the checks that apply. Billing (191-194) and runtime-AI (171-180) checks drop out for apps without those features. AI-written code alone does not trigger the runtime-AI checks.
• For each selected check, record what company services already cover and what the app team still owes. Link evidence and put a named person against each item. The bracketed teams on each heading are suggested leads.
• Experimenting with fake data in an approved sandbox needs none of it.
• The triggers for starting the work are stated: confidential data entering the app, an API key gaining write permission, or a team starting to depend on the app.

Number ranges:

Checks that go beyond a generic production list

• Shadow hosting: check 20 asks for a way to detect the app quietly moving to someone's personal hosting account. Check 30 asks for regular inventory-versus-reality comparisons.
• Coding-agent containment (81-90):
• Tool permissions are enforced outside the prompt (86).
• Agents cannot grant themselves rights or disable required checks (87).
• Agent execution is isolated from production (84).
• Untrusted documents, sites and packages are treated as possible malicious instructions (85).
• Retention rules cover dev chats and temporary files (90).
• Read-only is not safe by default: check 72 notes that reading can still leak the whole database. Check 74 requires the receiving system to enforce permissions when the caller is an agent.
• Approvals tied to the specific target and change, not a vague permission to proceed (76). Stop controls and revocation must work even when the app is broken (79).
• Agent test claims: check 149 says to verify actual test runs when an agent reports "all tests passed". Check 141 says tests should come from business requirements, not from what the generated code happens to do.
• Authz test cases: the document 15→16 URL change (63), direct API calls bypassing the UI (64), and tenant isolation in searches, jobs, caches and exports (65).
• Recovery: emergency revocation that has actually been tried (48). A restore into a separate environment with the recovered data checked (164). Backups that include encryption keys (162).
• Supply chain (121-130):
• A machine-readable SBOM (SPDX or CycloneDX) per release.
• SBOM gaps recorded, including separately downloaded extensions.
• The SBOM linked to source revision, build and deployed artefact.
• A way to find every deployed app affected by a new dependency flaw.
• Human continuity: a named backup for both owners (3) and someone able to debug what the agent can't fix (197).

EU bonus dates

The page says these were checked on 17 October 2026 and that scope depends on organisation, product, data and use. Confirm scope with whoever owns compliance.

• An internal app is not automatically in CRA scope (206).
• GDPR already applies, including a DPIA where required (202-204).
• Keep separate incident-reporting decisions for GDPR, NIS2, CRA and contracts, because thresholds, recipients and deadlines differ (215).
• Some AI Act duties arrive earlier than the high-risk deadline (212).

Caveats

• The page says a risk-acceptance form does not make a legal duty disappear.
• Sector rules such as DORA, medical-device and accessibility obligations can add more.
• The list does not decide who approves payments, which supplier records each person sees, or what happens when the app gives a wrong answer. Those decisions remain with the business.