Read items from part 1, part 2.

Gotchas

Item 7: Recognize and mitigate the risk of AI hallucinations and errors

AI models produce incorrect or nonsensical outputs with disturbing frequency. They "hallucinate" facts, invent APIs, and reference non-existent functions with complete confidence. This combination of error and certainty creates a dangerous trap for the unwary.

Never assume correctness in AI-generated code. Treat each output as a hypothesis requiring verification rather than a solution deserving implementation. The most dangerous errors aren't syntax violations that compilers catch, but logical flaws that seem plausible until runtime.

The Driver / Observer model becomes particularly valuable in mitigating these risks. The developer driving the AI interaction may develop a kind of confirmation bias, seeing what they expect rather than what's actually produced. A second set of eyes provides crucial protection against this effect.

Some categories of AI hallucinations occur predictably. Be especially vigilant when the model generates code that:

1. References APIs or libraries not mentioned in your prompts

2. Creates complex abstractions without clear necessity

3. Implements functionality that seems too concise for the problem's complexity

4. Includes comments explaining non-existent features

These patterns often indicate the model is drawing from its training data rather than responding to your specific requirements.

Item 8: Guard against over-abstraction and premature optimization

AI has a troubling tendency to over-abstract and prematurely optimize. Given its training on millions of codebases, it gravitates toward patterns that might be inappropriate for your specific context. This predisposition requires active counterbalance.

When AI suggests complex abstractions or optimizations early in development, ask a simple question: "What problem does this solve right now?" If the answer involves hypothetical future requirements or marginal performance improvements, reject the suggestion. The clearer code is nearly always preferable to the clever code.

Remember that abstraction should bring together dissimilar things based on genuine similarities, not simply be a byproduct of AI's pattern-matching capabilities. An abstraction that doesn't serve immediate clarity or DRY principles imposes cognitive costs without compensating benefits.

Be particularly wary when AI generates unnecessarily complex class hierarchies, introduces design patterns without clear necessity, or optimizes for performance in non-critical paths. These tendencies reflect its exposure to codebases where such features evolved over time in response to genuine needs - a context likely different from your current project.

Item 9: Prioritize data security and privacy when using AI tools

Every interaction with external AI services represents a potential data exposure. Code, business logic, and potentially sensitive information leave your controlled environment and enter the model provider's systems. This exchange requires careful management.

Never share personally identifiable information, credentials, or business secrets with AI models, especially those hosted outside your organization. Sanitize all inputs before sharing them with external services. Use internally hosted models like Amazon Bedrock, Google Vertex AI for sensitive projects where data control is paramount.

Understand the data processing and retention policies of your AI tool providers. Models like Claude, Gemini, and others have different approaches to how they handle your inputs. Some retain data for training purposes, others delete it after processing. Make security decisions based on these distinctions rather than treating all tools equally.

Consider implementing prompt templates that automatically strip sensitive information or add reminders about security boundaries. These guardrails protect against accidental exposure during the rapid back-and-forth of development.

(to be continued)