|
| 1 | +## Title |
| 2 | + |
| 3 | +AI Code Generation Context |
| 4 | + |
| 5 | +## Patlet |
| 6 | + |
| 7 | +AI tools generate code that diverges from project standards and architectural patterns. Provide an AI Code Generation Context within the repositories to guide AI tools in producing contributions that align with existing project conventions, reducing review friction and maintaining code consistency. |
| 8 | + |
| 9 | +## Problem |
| 10 | + |
| 11 | +With the growing use of AI tools (like GitHub Copilot, ChatGPT, or custom LLMs), InnerSource contributors are increasingly using generative AI to write code. However, without project-specific context, these tools often produce code that diverges from the project's architectural patterns, naming conventions, or quality standards. This leads to friction during reviews, inconsistent codebases, and technical debts or additional burden on maintainers. |
| 12 | + |
| 13 | +## Context |
| 14 | + |
| 15 | +* InnerSource adoption is in place across the organization. |
| 16 | +* Developers are encouraged to use AI tools to improve their productivity. |
| 17 | +* Contributors may not be familiar with or fail to meticulously prompt when generating code through AI, using the target codebase's idioms, architecture, or constraints. |
| 18 | +* Maintainers want to empower contributors using AI while preserving code consistency and maintainability. |
| 19 | +* Multiple teams are contributing to shared repositories with varying levels of familiarity with project standards. |
| 20 | +* Code review processes are becoming bottlenecked by AI-generated code that requires significant rework. |
| 21 | + |
| 22 | +## Forces |
| 23 | + |
| 24 | +* **AI Model Limitations**: AI models generate code based on generalized training data, not project-specific patterns, leading to generic solutions that may not fit the project's architecture |
| 25 | +* **Knowledge Gap**: New contributors using AI tools might unknowingly bypass existing architectural norms, coding standards, and established patterns |
| 26 | +* **Review Overhead**: AI-assisted PRs can significantly increase review load if not aligned with existing practices, as maintainers must spend time explaining and correcting deviations |
| 27 | +* **Productivity vs. Quality Trade-off**: While AI tools boost individual productivity, they can reduce overall team productivity if the generated code requires extensive rework |
| 28 | +* **Context Switching Cost**: Developers benefit from AI tools only when they have the right contextual grounding, but manually providing this context for each AI interaction is time-consuming |
| 29 | +* **Inconsistent Standards**: Different AI tools and different prompting approaches by contributors can lead to wildly inconsistent code styles and patterns |
| 30 | +* **Maintenance Burden**: Creating and maintaining the comprehensive AI context requires ongoing effort from maintainers |
| 31 | +* **Tool Integration Complexity**: Different AI tools have different ways of consuming context, making it challenging to create universal guidance |
| 32 | +* **AI Tool Cost Constraints**: Comprehensive AI context increases processing costs (AI tools charge based on "tokens" \* units of text measurement) and usage limits, requiring strategic balance between context completeness and efficiency |
| 33 | + |
| 34 | +## Solution |
| 35 | + |
| 36 | +Provide an **AI Code Generation Context** folder within the repository to guide AI tools in producing contributions that align with project standards. This folder serves as a comprehensive reference that contributors can easily provide to AI tools, ensuring that generated code adheres to project conventions. |
| 37 | + |
| 38 | +### Implementation Structure |
| 39 | + |
| 40 | +Create an `innersource-ai/` folder in the repository root containing: |
| 41 | + |
| 42 | +#### Core Documentation Files (Required) |
| 43 | + |
| 44 | +`PROMPT.md`: Project-specific instructions for AI tools |
| 45 | + |
| 46 | +* Naming conventions (variables, functions, classes, files) |
| 47 | +* Logging patterns and error handling approaches |
| 48 | +* Testing strategy and preferred testing frameworks |
| 49 | +* Code formatting and style preferences |
| 50 | +* Common anti-patterns to avoid |
| 51 | +* Preferred libraries and frameworks for specific tasks |
| 52 | + |
| 53 | +`ARCHITECTURE.md`: Lightweight system overview |
| 54 | + |
| 55 | +* High-level system architecture and component relationships |
| 56 | +* Data flow patterns and API design principles |
| 57 | +* Dependency management guidelines |
| 58 | +* Module organization and layering principles |
| 59 | +* Integration patterns with external systems |
| 60 | + |
| 61 | +`STYLE_GUIDE.md`: Comprehensive coding guidelines |
| 62 | + |
| 63 | +* Language-specific style rules |
| 64 | +* Code organization patterns |
| 65 | +* Documentation standards |
| 66 | +* Performance considerations |
| 67 | +* Security guidelines and common vulnerabilities to avoid |
| 68 | + |
| 69 | +#### Enhancements (Optional) |
| 70 | + |
| 71 | +##### Practical Examples |
| 72 | + |
| 73 | +`EXAMPLES/`: Sample code files demonstrating best practices |
| 74 | + |
| 75 | +* `good-examples/`: Well-written code snippets with explanations |
| 76 | +* `bad-examples/`: Common mistakes with explanations of why they're problematic |
| 77 | +* `refactoring-examples/`: Before/after code showing proper improvements |
| 78 | +* Template files for common patterns (controllers, services, utilities) |
| 79 | + |
| 80 | +##### Configuration and Tooling |
| 81 | + |
| 82 | +`CONFIG/`: Shared formatter and analysis configurations |
| 83 | + |
| 84 | +* `.prettierrc`, `.eslintrc`, or equivalent formatting configs |
| 85 | +* `.editorconfig` for consistent editor settings |
| 86 | +* Static analysis tool configurations |
| 87 | +* Pre-commit hook configurations |
| 88 | + |
| 89 | +`INTEGRATION/`: AI tool-specific integration guides |
| 90 | + |
| 91 | +* GitHub Copilot workspace configuration |
| 92 | +* Custom GPT instructions and prompts |
| 93 | +* IDE plugin configurations |
| 94 | +* CLI tool integration examples |
| 95 | + |
| 96 | +##### Advanced Features |
| 97 | + |
| 98 | +`EMBEDDINGS/` (Optional): For advanced LLM integrations |
| 99 | + |
| 100 | +* Searchable knowledge base of project patterns |
| 101 | +* Vector embeddings of code examples |
| 102 | +* Semantic search capabilities for finding relevant patterns |
| 103 | + |
| 104 | +**Context Efficiency**: Start with core documentation files (~1000 words of context) to balance context value with AI tool costs. Expand strategically based on measured impact on review cycles and code quality. |
| 105 | + |
| 106 | +**Naming Convention**: The suggested file and folder names follow industry common practices. However, codebase owners may choose alternative names that are more discoverable and relatable to their specific project or codebase. Any chosen naming convention should be clearly documented and communicated to contributors through proper documentation. Should files like [AGENTS.md](https://agents.md) become standard in the future, the naming conventions in this pattern might be adapted accordingly. |
| 107 | + |
| 108 | +### Usage Patterns |
| 109 | + |
| 110 | +#### For Contributors |
| 111 | + |
| 112 | +* **Before Starting**: Review the AI context to understand project standards |
| 113 | +* **During Development**: Reference specific files when prompting AI tools |
| 114 | +* **Code Generation**: Include relevant context snippets in AI prompts |
| 115 | +* **Validation**: Use provided examples to verify AI-generated code aligns with standards |
| 116 | + |
| 117 | +#### For AI Tool Integration |
| 118 | + |
| 119 | +* **Direct Reference**: Copy relevant sections into AI tool prompts |
| 120 | +* **URL Integration**: Reference files via repository URLs in AI tools that support web access |
| 121 | +* **IDE Integration**: Configure AI plugins to automatically include context |
| 122 | +* **Custom Workflows**: Integrate context into CI/CD pipelines for automated validation |
| 123 | + |
| 124 | +### Maintenance Strategy |
| 125 | + |
| 126 | +* **Version Control**: Track changes to AI context alongside code changes |
| 127 | +* **Regular Updates**: Review and update context as project standards evolve |
| 128 | +* **Community Contribution**: Allow contributors to suggest improvements to AI context |
| 129 | +* **Metrics Tracking**: Monitor the effectiveness of AI context through code review metrics |
| 130 | + |
| 131 | +## Resulting Context |
| 132 | + |
| 133 | +* **Improved Code Quality**: AI-assisted contributions become consistent with existing code standards and architectural patterns from the first submission |
| 134 | +* **Reduced Review Friction**: Maintainers can trust incoming PRs more readily, significantly reducing review fatigue and time-to-merge |
| 135 | +* **Enhanced Contributor Experience**: Contributors using AI produce better, more maintainable code even on their first attempts, leading to increased confidence and participation |
| 136 | +* **Scalable Collaboration**: Opens the door to scalable, AI-aware InnerSource collaboration across teams without sacrificing code quality |
| 137 | +* **Knowledge Preservation**: Project knowledge becomes more explicit and accessible, reducing dependency on tribal knowledge |
| 138 | +* **Faster Onboarding**: New contributors can leverage AI tools effectively from day one, reducing the learning curve for project-specific patterns |
| 139 | +* **Consistent Evolution**: As AI tools improve, the context ensures that enhanced capabilities are channeled toward project-appropriate solutions |
| 140 | + |
| 141 | +## Rationale |
| 142 | + |
| 143 | +This pattern addresses the fundamental mismatch between AI tools' general training and project-specific requirements. By providing structured, easily consumable context, we enable AI tools to generate code that feels like it was written by an experienced project contributor rather than an outsider. |
| 144 | + |
| 145 | +The `innersource-ai/` folder approach is intentionally explicit and discoverable, making it clear to both humans and AI tools where to find project-specific guidance. The modular structure allows teams to implement incrementally, starting with basic style guides and expanding to more sophisticated examples and configurations as needed. |
| 146 | + |
| 147 | +This solution balances the productivity benefits of AI tools with the quality requirements of professional software development, creating a sustainable approach to AI-assisted InnerSource collaboration. |
| 148 | + |
| 149 | +## Status |
| 150 | + |
| 151 | +* Initial |
| 152 | +* Drafted in August 2025 |
| 153 | + |
| 154 | +## Authors |
| 155 | + |
| 156 | +* [Amburi Roy](https://www.linkedin.com/in/amburi/) |
| 157 | + |
| 158 | +## Related Patterns |
| 159 | + |
| 160 | +* [Standard Base Documentation](../2-structured/base-documentation.md) - Provides the foundation documentation that AI context builds upon |
| 161 | +* [InnerSource Portal](../2-structured/innersource-portal.md) - Could include AI context availability as searchable metadata for project discovery |
| 162 | +* [Trusted Committer](../2-structured/trusted-committer.md) - Trusted Committers are responsible for maintaining and evolving the AI context |
0 commit comments