Coding Standards for Engineering Teams in the AI Era: A new mandate
As our teams across the board are now using AI to develop their code, a practice I absolutely want to promote, and encourage, we need to build some robust coding standards that can supplement our existing general coding guidelines and focus on readability, maintainability, and future-proofing of our applications.
For large organizations with diverse technology stacks, this means our coding standards need an upgrade. We must establish a clear framework that ensures every line of code shipped is production-ready, regardless of its origin. Here are the essential standards our teams are adopting to responsibly integrate AI into the coding workflow, ensuring we build for the future.
Code Review & Ownership Standards
Human-in-the-Loop Review (Mandatory):
- Every line of AI-generated code must be treated as a suggestion, not a definitive solution.
- Engineers must manually review, trace, and confirm the functionality of all generated code before it is committed. Do not accept large blocks of generated code without scrutiny.
- The human engineer is the ultimate owner and is fully accountable for the quality, correctness, and security of the committed code, regardless of its origin..
Clarity in Commit Messages:
- If a significant portion of a commit utilized AI assistance (e.g., a complex algorithm implementation or a large boilerplate section), the commit message or the pull request (PR) description should acknowledge the use of AI. (e.g., "Feature X: Implemented with AI assist, fully reviewed and tested."). We have to let our teams know that its absolutely OK to use AI to augment our code, build features, just let us know wherever it is happening, so that we can use this information while maintaining and adding new features in future.
Refactoring & Readability:
- Immediately after generation, the engineer must refactor the code to match team/language-specific style guides (e.g., variable naming conventions, indentation).
- Ensure generated code is not overly complex or "clever" at the expense of readability. If the AI output is obfuscated, simplify it.
Maintainability & Documentation
Intent-Driven Comments & Documentation:
- While AI can generate what the code does (docstrings, function signatures), engineers must ensure the documentation clearly explains the engineering *intent* and *why* a particular approach was chosen.
- Critical sections, business logic, or complex algorithms must have comprehensive, human-written comments to ensure future maintainability and knowledge transfer.
- Generated code that violates existing architecture or design patterns must be manually corrected and its deviations documented.
Consistent Naming Conventions:
- Generated variables, functions, and classes must strictly adhere to our established naming standards (e.g., snake_case for Python variables, PascalCase for C# classes). This is a common area where AI tools can be inconsistent.
Dependency Management:
- Engineers must verify that any suggested library or external dependency introduced by AI is approved, maintained, and aligns with the company's security and licensing policies.
Security & Compliance
Security Vetting (Non-Negotiable):
- All AI-generated code that handles sensitive data, authentication, authorization, or external communication must undergo an elevated level of security review.
- Engineers must actively look for and immediately correct common security pitfalls often present in AI-generated snippets, such as:
- Hardcoded secrets or API keys.
- Vulnerable patterns (e.g., SQL Injection, XSS, insecure deserialization).
- Insecure use of cryptography primitives.
Data and Intellectual Property (IP):
- Teams must only use AI tools approved by the organization that adhere to strict data and IP agreements, ensuring that our company code is not used to train public models.
- Engineers must be vigilant for potentially plagiarized or verbatim code snippets from public repositories suggested by AI tools, and must ensure all committed code is compliant with established license agreements.
Testing & Quality Assurance
Test-Driven Correction:
- While AI can often generate test stubs, the generated tests are often insufficient. Engineers must manually verify, expand, and own the test suite.
- Tests (whether generated or not) must achieve the team's defined code coverage targets and include sufficient boundary, error, and integration cases relevant to CPG operations.
Debugging AI Output:
- Engineers must develop skills in debugging AI-generated code efficiently. If a generated code block is overly complex or difficult to debug manually (it happens more than what we would like to admit), it should be simplified or rewritten.
Performance Verification:
- For performance-critical code paths (e.g., real-time processing, high-volume transactions), the engineer must independently benchmark and verify that the AI-generated implementation meets performance requirements, as generated code can sometimes be inefficient.
Process & Training
AI Tool Prompt Engineering:
- Teams should develop and share best practices for writing effective and specific prompts to guide the AI toward desired coding patterns and CPG-specific architectural styles. Poor prompts lead to poor, unmaintainable code.
- Prompts should always reference existing internal libraries and design patterns whenever possible.
- Not just save the code, but also save the prompts to ensure that we can refer back to the prompts as when required for any AI generated code.
Continuous Learning:
- Regularly share "AI-Generated Code Horror Stories" (i.e., poor or buggy code accepted from AI) and Best Practice Snippets across teams to promote shared learning and vigilance.
- Conduct internal workshops on the responsible and effective use of AI coding tools.
Conclusion
These standards create a necessary check-and-balance system, allowing our teams to leverage AI's productivity gains while maintaining the high quality and integrity required for enterprise-level applications.
PS: In addition to this, I have created a document for Naming Standards, that my team and I rely upon to name our variables, tables, endpoints etc. I am sharing the same here, you can use it as a base to build upon your own standards: Link to the Document.