The 1,000,000 KRW Mistake — What Not to Delegate to AI

The boundary between what you can and can't delegate to AI is your differentiation.

How a 1 million KRW mistake starts

Last year a startup founder built payments in 3 hours with Claude Cursor. The joy of "finally done" was short-lived. The moment the first user paid, problems exploded. The code handling the payment response had its API key hard-coded. The moment it was committed to GitHub, someone had already found the key and was calling the API at will. The bill a month later passed 1,000,000 KRW.

This isn't someone else's story. With AI tools "very convenient," the security line gets blurry. The problem isn't AI being convenient — it's not knowing where AI delegation should stop.

The delegation line: external dependencies vs internal core

Not all code carries the same weight. Some code is fine to have AI generate. Some you have to review yourself.

Areas AI can safely take

"Repetitive, verifiable, and not externally dependent."

• Data format conversion (JSON → CSV)
• Basic UI component structure (buttons, card layouts)
• Algorithm implementation (sorting, filtering)
• Document generation (API docs, test cases)

Areas you must never delegate

"Where the result of delegation directly causes loss."

• Anything security-related (auth, encryption, API key management)
• Payments and financial transactions (PG integration, FX, transaction records)
• Personal data handling (user data storage, lookup, deletion)
• Domain core logic (your business's competitive moat)
• Legal compliance (TOS, privacy policy, compliance)

Making the boundary clear gives you two wins. First, AI's role is precise, so prompts are sharper. Second, when something breaks, responsibility is clear. "AI made it wrong" is not a valid excuse.

The security boundary: why AI-built code gets breached

The most common security issue in AI-generated code is API key and auth token exposure. Trend Micro research found a significant share of ChatGPT-generated code contained hard-coded API keys. Ask "integrate the payments API," and AI often suggests the simplest option — pasting the key into the source.

"I'll only test in dev, it's fine" is the most dangerous thought. Once committed, the key lives in GitHub history forever.

There was the 2023 Google API key incident, too. Developers followed official guides to set up keys, then Google changed the system so the keys functioned as Gemini auth tokens. The result? Hundreds of millions of won in unauthorized charges.

Korea makes this more complex. Every PG's security policy is different. Toss Payments, NHN KCP, NICE Payments — there's documentation, but precise security guides often only come over the phone. Ask AI to "build payments" and it follows generic patterns, which can violate your PG agreement.

Payments and security can never be "good enough." A 1% error becomes a 1 million KRW loss. Always have a specialist (PG tech team or a payments-specialist developer) review, and call AI for help only after that.

Domain core: where your unfair advantage lives

People ask "what can AI not do?" Simple answer: your domain core logic.

Say your app is "cosmetics recommendation by skin type." Core logic is "the algorithm that accurately classifies user input into skin type." AI can build a generic classifier, but to handle a nuanced edge case like "sensitive skin with high reactivity," you need to define the rules with a skin specialist.

E-commerce example:

• What AI can do: product listing UI, search filters, review display format
• What AI must never do: fee calculation logic, refund policy decisions, inventory rules

Why? Those rules are your competitive edge and your business model. AI can build "generic" e-commerce logic, but it can't build "your" e-commerce logic.

If you don't understand your own business logic, problems explode the moment your first users arrive. The feedback from your first 10 users is the most precious, but if you can't explain "why we built it this way," response speed slows.

Design grain: humans guard consistency

AI can build individual UI components flawlessly. But consistency when they're combined is something AI can't guarantee.

A design system is "a set of rules that creates a consistent experience." Font sizes, colors, spacing, corner radii defined in Figma must be implemented precisely across every screen.

• Button default height 44px → all buttons 44px
• Header font Pretendard 16px Bold → same standard everywhere
• Spacing on 8px units → no 12px spacings allowed

10 AI-generated components can each be individually logical but disharmonious when placed together. AI doesn't perfectly remember "the button I built before."

4 steps for design consistency

1. Build a component library in Figma first
2. Ask AI to "build based on the components in this Figma file"
3. Compare the rendered code against the original (use DevTools for colors and spacing)
4. Direct explicit fixes for mismatches

No-delegate checklist

Wrapping up

The core of this post is "drawing the line." Not "AI can't do this" — clearly defining "what AI must not do." Whether your app becomes "a fast generic app" or "a slower but differentiated app" depends on how you drew this line.

Next post: the last gate just before launch. Why what you missed sinks the launch more than what you built, and a pre-launch checklist to avoid it.

References

1. Security Vulnerabilities of ChatGPT-Generated Code — Trend Micro (2023)
2. Generative AI Privacy Processing Guidelines — Korea Personal Information Protection Commission (2025)
3. AI agent security: hard-coded API key issues — MegaZone Soft
4. Codex Command Injection Vulnerability — OpenAI Security Blog (2026)
5. Toss Payments MCP official guide and developer community cases (2026)

Previous: An AI Build Course for Developers
Next: What You Forgot Costs More Than What You Built — Pre-Launch Checklist

Minchul Kim, CEO of Freeive, Fail School