LLM Usage Guidelines

Last Updated: January 1, 2026

---

Core Philosophy

Large Language Models (LLMs) like ChatGPT, Claude, and GitHub Copilot can significantly accelerate development, but only when used correctly. Used poorly, they create technical debt, obscure understanding, and produce brittle code that breaks in subtle ways.

The fundamental rule: LLMs cannot compensate for lack of understanding.

---

The Three Pillars of Effective LLM Use

To use LLMs effectively in software development, you need all three of these foundations:

1. Good Documentation

You need quality reference material. LLMs work best when your codebase, libraries, and frameworks have clear documentation.

• Maintain up-to-date documentation for your own codebase
• Ensure LLMs have access to relevant context
• Document architectural decisions and patterns
• Keep API documentation current

Why this matters: LLMs can help navigate and apply documented patterns. Without documentation, they hallucinate solutions that seem plausible but don't match your system.

2. Good Planning

You need a clear plan before writing code. LLMs can help implement a plan, but they can't create good plans from vague requirements.

Before using an LLM:

• Define what you're building and why
• Break down the problem into concrete steps
• Identify technical constraints and requirements
• Consider integration points and dependencies
• Plan for edge cases and error handling

Critical skill: Reflection and modification. Plans change as you learn. Good developers:

• Start with a plan
• Reflect on progress regularly
• Modify the plan based on new information
• Use LLMs to help execute revised plans

Bad practice: Asking an LLM "build a user authentication system" without specifying requirements, security constraints, or integration needs.

Good practice: "Implement JWT token validation middleware that checks for tokens in the Authorization header, verifies against our public key from environment variable, and attaches the decoded user ID to the request context."

3. Good Understanding

You need deep knowledge of what you're building. This is the most critical pillar and the one most commonly missing.

You must understand:

• The programming language you're using
• The frameworks and libraries involved
• Your codebase's architecture and patterns
• How components should interact
• What good code looks like in your context

Essential capability: Code evaluation, not just comprehension.

• Comprehension = "I understand what this code does"
• Evaluation = "I can judge if this code is good, maintainable, secure, and correct"

LLMs can explain code. But you must be able to evaluate whether that code is appropriate for your specific situation.

---

The Understanding Problem

Why Understanding Cannot Be Substituted

If you don't understand React, an LLM cannot make you productive with React.

Without fundamental understanding:

• You can't evaluate LLM suggestions
• You can't determine if code will integrate properly
• You can't debug when things go wrong
• You can't maintain or extend the code later
• You can't recognize security issues or performance problems

Example scenario:

A developer who doesn't understand React hooks might accept LLM-generated code with:

• Infinite render loops due to missing dependencies
• Stale closures causing subtle bugs
• Improper state updates that don't trigger re-renders
• Memory leaks from uncleaned effects

A developer who understands React will immediately recognize these issues and either reject the suggestion or fix it.

The Evaluation Gap

You cannot determine what makes a good plan without understanding.

• How do you evaluate if the LLM's proposed architecture is sound?
• How do you know if the suggested library is appropriate?
• How do you judge if error handling is sufficient?
• How do you assess security implications?

Without understanding, you cannot answer these questions. You'll accept plausible-sounding but potentially problematic solutions.

---

Practical Guidelines

When to Use LLMs

LLMs are most valuable for:

1. Boilerplate generation - When you know exactly what pattern you need
2. Code translation - Converting between languages you understand
3. Refactoring assistance - When you can evaluate the output
4. Documentation writing - When you can verify accuracy
5. Test generation - When you understand what needs testing
6. Exploring APIs - When you can verify against documentation
7. Code review support - When you can judge the feedback

When NOT to Use LLMs

Avoid LLMs for:

1. Learning fundamentals - Learn properly first, use LLMs to accelerate later
2. Architecture decisions - These require deep understanding of trade-offs
3. Security-critical code - Without understanding, you can't verify safety
4. Performance optimization - Requires profiling and measurement, not guessing
5. Debugging complex issues - LLMs can suggest, but you must understand the root cause

Best Practices

1. Always review generated code - Never blindly accept LLM output
2. Test thoroughly - LLM code often works for happy paths but fails on edge cases
3. Understand before committing - If you don't understand it, don't merge it
4. Use as a starting point - Treat suggestions as drafts, not final solutions
5. Verify against documentation - Check that code follows actual APIs and patterns
6. Consider maintainability - Will you or your team understand this in 6 months?

---

The Competence Amplifier

LLMs are competence amplifiers, not competence creators.

• 10x developer + LLM = 15x developer
• 1x developer + LLM = 0.5x developer (creates more problems than they solve)

The better you are, the more value you get from LLMs. They help you move faster on things you already know how to do.

---

Warning Signs

You're using LLMs incorrectly if:

• You can't explain how the generated code works
• You're spending more time debugging LLM code than writing your own
• Your PRs are getting rejected for quality issues
• You're creating technical debt faster than you're shipping features
• You're afraid to touch code you generated with an LLM
• You're using LLMs to learn a new technology from scratch

---

Investment in Understanding

Time spent learning is never wasted.

• Read the documentation
• Work through tutorials
• Build small projects to understand fundamentals
• Study your codebase's patterns
• Ask questions when you don't understand

Once you have understanding, LLMs become incredibly powerful tools. Without it, they're a liability.

---

Team Expectations

At Eddy, we expect:

1. Code understanding - You can explain any code you commit
2. Quality standards - LLM-generated code meets the same standards as hand-written code
3. Testing - All code is properly tested, regardless of how it was created
4. Documentation - Complex logic is documented, especially if LLM-generated
5. Honest communication - If you're stuck or don't understand something, ask for help

---

Conclusion

LLMs are powerful tools that can make you significantly more productive - if you already know what you're doing. They're not a shortcut to competence, but they can help competent developers move faster.

Invest in understanding first. Use LLMs to accelerate second.

---

Related Documentation