Risk isn't a question of "if it will happen," but "when it will happen." The key is knowing where the risks are and how to respond.
6.1 The Risk Landscape
The risks of AI coding aren't "a single risk"—they're "a set of risks." Different risks vary in impact and probability, and they need to be treated differently. The following is a quick overview—each risk is developed in detail in the sections that follow.
| Risk Category | Risk Description | Impact | Probability |
|---|---|---|---|
| Quality | The quality of AI-generated code is not controllable | High | Medium |
| Security | AI code introduces security vulnerabilities | High | Low |
| Architecture | Code deviates from the architecture design | Medium | High |
| Team | Team skills degrade or the team becomes dependent on AI | Medium | Medium |
| Compliance | AI code involves copyright or compliance issues | High | Low |
| Cost | API call costs exceed the budget | Low | Medium |
6.2 Quality Risk
Risk Description
AI-generated code may be functionally correct but harbor quality hazards—inconsistent code style, incomplete error handling, performance problems, poor maintainability. Why is this a "high-impact, medium-probability" risk? Because quality risk doesn't explode all at once; it accumulates steadily. Today one lapse in style consistency, tomorrow one incomplete error handler—day by day, the codebase becomes a "legacy" that is hard to maintain.
Prevention Measures
- Establish an acceptance system (detailed in Chapter 4)
- Set coding standards, so AI follows a unified style
- Use automated tools (linting, formatting, type checking)
Contingency Plan
Problem: Quality issues are found in AI code that has already been committed. Response:
- Assess the scope of impact
- If it's a localized issue, fix it and re-commit
- If it's a systemic issue, roll back and rebuild
- Analyze the cause: were the instructions not clear enough, or was the acceptance process not strict enough?
6.3 Security Risk
Risk Description
AI coding tools may generate code that contains security vulnerabilities. Why is this a "high-impact, low-probability" risk? Because when a security vulnerability does occur, the consequences can be catastrophic—data breaches, system intrusion, compliance penalties. But the probability is relatively low, because AI's training data contains a great deal of "common security practice" (such as parameterized queries and input escaping). Still, AI may also "recall" examples of insecure code from its training data--low probability is not zero probability, which is why security inspection cannot be skipped. Common vulnerability types (for coverage-style estimates see the OWASP Top 10; no precise percentages are given here): information leakage, missing authorization, insufficient input validation, and hardcoded credentials--see the security inspection checklist in this chapter and Chapter 5 of Volume 2.
Common security vulnerabilities generated by AI include:
Prevention Measures
- Fold security review into the acceptance process (acceptance must include security checks)
- Establish secure coding standards, making security requirements explicit in the instructions
- Use security scanning tools to automatically detect common vulnerabilities
- Manually review sensitive operations: features involving payments, user data, and authentication must be reviewed by humans
Security Review Checklist
Security review checklist (used during acceptance):
- [ ] Is user input validated or escaped?
- [ ] Are database queries parameterized?
- [ ] Do API endpoints have access control?
- [ ] Are data fields that should not be exposed being returned?
- [ ] Are there hardcoded keys or credentials?
- [ ] Is the authentication logic complete?
- [ ] Do third-party libraries have known vulnerabilities?
Contingency Plan
Problem: A security vulnerability is found in AI-generated code. Response:
- Fix the vulnerability immediately (highest priority)
- Check whether other features have similar issues
- Update the acceptance checklist to include this security item
- If it's a systemic security issue, pause AI coding for that project and retrain
6.4 Architecture Risk
Risk Description
While implementing features, AI may deviate from the architecture design. Why is this a "medium-impact, high-probability" risk? Because architecture drift is "everyday"—AI can produce minor architecture deviations almost every time it generates code (for example, placing a file in the wrong location or using the wrong naming style). A single deviation has little impact, but accumulated over time it gradually erodes the codebase's structure. What's more, architecture drift is implicit—the code runs and the functionality is correct, so it's hard to spot at first.
Prevention Measures
- The blueprint must include clear architecture conventions (directory structure, tech stack, naming rules)
- Acceptance must check architecture compliance
- Conduct regular architecture audits
Contingency Plan
Problem: Architecture drift is found in the code. Response:
- Assess the severity of the drift
- Mild drift: record it and correct it in subsequent iterations
- Severe drift (tampering with foundations, runaway size): roll back and rebuild
- Update the blueprint to explicitly prohibit the offending operations
6.5 Team Risk
Team risk is the one most easily overlooked by managers—because it isn't a "technical problem" but a "human problem." Technical problems have clear solutions (add acceptance, add gates, add tools), but human problems require sustained attention and management.
Risk One: Skill Degradation
Developers who rely on AI to write code over the long term may lose the ability to code and debug independently.
Prevention measures:
- Require developers to understand AI-generated code before they can accept it
- Schedule regular "no AI days" or "no AI features"
- Encourage developers to read AI-generated code and offer improvement suggestions
Monitoring signals:
- Developers consult AI first for simple problems instead of thinking for themselves
- Developers are unable to explain AI-generated code
- Code reviews reveal that developers don't understand the code they submitted
Risk Two: AI Dependence
Developers become overly reliant on AI when making decisions, losing the capacity for independent judgment.
Prevention measures:
- Establish the principle that "AI gives suggestions, humans make decisions"
- Architecture decisions must be led by humans, with AI serving only as a reference
- Encourage questioning AI's recommendations
Monitoring signals:
- AI-recommended technical solutions are adopted without analysis
- Developers cite AI as an authority in technical discussions
- Signs of a lack of independent thinking
Risk Three: Knowledge Gap
AI wrote the core code, but no one on the team understands it.
Prevention measures:
- Core code must be understood by someone—the person who accepts it is the "owner"
- Conduct regular code walkthroughs in which developers explain AI-generated code
- During onboarding, new members must complete a small feature independently (without relying on AI)
6.6 Compliance Risk
Risk Description
Compliance risk is the easiest to overlook. AI-generated code may conflict with open-source licenses, and AI services may process sensitive data (including the risk of code being used for model training). If any of these risks materialize, they can bring legal and compliance problems. (AI reproducing copyrighted code verbatim in long stretches has been observed in controlled experiments, but there is no reliable estimate of how often it occurs in everyday development--conventional review for open-source license similarity remains the main line of defense.)
Prevention Measures
- Clarify the coding tool's data-processing policy—will your code be used for training?
- Don't use AI coding for sensitive projects—or use locally deployed AI models
- Watch for license compliance during code review
- Don't input sensitive data (passwords, keys, customer information) into AI tools
6.7 Cost Risk
Risk Description
API calls to AI coding tools can incur significant costs, especially at large scale. Cost risk is "low-impact, medium-probability"—because costs are predictable and controllable, unlike security vulnerabilities. But without management, monthly API fees can exceed the budget.
Cost Control Recommendations
- Use on demand: not every feature needs AI coding
- Use caching: the results of identical or similar instructions can be reused
- Monitor usage: track API call volume and costs
- Deploy locally: for large-scale use, consider locally deployed AI models
Cost Estimation
Order-of-magnitude cost example (a calculation example, not measured data; actual costs follow the current pricing of your tool):
- A small feature (1-2 files): several thousand tokens
- A medium feature (3-5 files): tens of thousands of tokens
- A large feature (5-10 files): tens of thousands to over a hundred thousand tokens
Monthly estimate (10-person team, 5 calls per person per day):
- Daily calls: 50
- Monthly calls: 1100
- Monthly tokens: on the order of millions, depending on task size
- Monthly cost: calculated based on actual API pricing
6.8 The Risk Management Process
Identify risks → Assess risks → Formulate plans → Execute plans → Review and improve
- Identify risks: regularly identify new risks (once per quarter)
- Assess risks: assess the degree of impact and the probability of occurrence
- Formulate plans: develop prevention measures and contingency plans for high-impact risks
- Execute plans: carry out the prevention measures in daily work
- Review and improve: after a risk materializes, review and update the risk management plan
Chapter Summary
The six risks of AI coding—quality, security, architecture, team, compliance, cost—differ in impact and probability and must be treated differently. Security and architecture risks deserve the most attention: security risks are low in probability but severe in consequence, while architecture risks are moderate in impact but high in probability. Team risks (skill degradation, AI dependence, knowledge gaps) are the easiest for managers to overlook yet have the most far-reaching impact. Establish an "identify → assess → plan → execute → review" risk management process so that risks stay under control rather than being left to luck. In the next chapter, we'll learn how to train your team.