AI<->Human C++ My project rules to Stop GenAI from ruining code.

I want to share what i believe a C++ project structure should use and explain why I believe this setup is an must in a mixed active AI driven project.

Let's make one thing clear first: best practices are best practices it does not matter what is generating the code. Whether you are a human developer typing every line or pair programming with a generative AI, the same rules apply.

I am highly skeptical of solo C++ AI projects. When you let a GenAI write a large C++ codebase on its own, it inevitably hallucinates legacy styles, triggers silent memory bugs, violates copy/move resource rules, and generates chaotic global build system configurations that leak state everywhere.

But mixed AI-human workflow is awesome. Humans can produce bad code sure, but at the high velocity of gen AI, we humans have very little chance to code review at same pace.

I AI mixed project must surround the coding process with an automated, multi-layered, ultra-strict diagnostic net. If the project's build and verification framework is robust, it acts as a filter that (instantly) catches, isolates, and flags bugs—whether introduced by an AI or not.

Below is not new or revolutionary, but best practices needs to be repeated again and again when gen AI is one click away in every modern IDE.

## 1. Limiting Visibility for AI Agents via Ignore Rules

Before you even compile, you need to prevent the AI agent from being overwhelmed by your project's workspace. Letting an agent scan massive build directories, binary assets, or internal IDE files wastes its context window, dilutes its attention, and causes it to hallucinate bad code references.

Use an agent ignore file which agent search tools inherit, in it hide dynamically generated files, heavy database files, and media folders. Generally, you should filter out:

Dynamic compile directories and build output folders.
IDE metadata directories and user preference configs.
Heavy binary databases and serialization outputs.
Large media assets, zipped files, and static binary templates.

Limiting what the AI can see ensures it remains focused on the exact translation units it is meant to write or refactor.

## 2. The Symmetry Principle: Directory == Target == Translation Unit

GenAI frequently generates chaotic Cmake build configurations, for example polluting global scopes with legacy commands that include directories globally. This leads to state leakage, long compile times, and header name collisions.

To block this, modern Cmake build systems should enforce target-centric directory symmetry.

In a symmetry principle project, knowing the folder name foo guarantees that:

The target name is foo.
The source file is foo.cpp.
The header path is foo/foo.hpp.
The internal dependency link target is ${PROJECT_NAME}::foo

## 3. Strict C++ & Build Standards, Agent Skill Files

To keep both human developers and AI agents aligned, document architectural coding rules inside dedicated skills directory. Provide an AI agent with clear, version-controlled skill descriptions prevents it from guessing coding standards and ensures it outputs highly compatible, project-specific code by default. Do this for each language, C++, Cmake, python etc.

## 4. Severe Standard Library Hardening, a Debug Complement.

GenAI produces logic bugs involving container lifetimes, such as iterator invalidation (mutating a collection while looping over it) and off-by-one errors inside standard arrays. To trap these, use Cmake build presets that uses deep debug levels that uses internal standard library diagnostic assertions.

When the AI writes code that invalidates iterators under a hardened run, instead of silently corrupting memory or producing non-deterministic bugs, the application triggers a clean, immediate runtime abort with a stack trace.

Severe hardening is a complement to a normal debug builds, not an either-or.

## 5. Compiler Warning Gates

Always build with every compiler you can in my case GCC, Clang, Intel