AI coding assistants can help developers write code faster, but they work more effectively when they understand how a particular project is structured. Every established application has its own development patterns, architectural decisions, naming conventions, testing practices, and technical boundaries. These details may not be fully explained in general documentation, but they are often visible throughout the existing codebase.
This is where AI coding rules can help. By analyzing an existing codebase and converting important project-specific conventions into clear instructions, development teams can give AI coding tools better context while reducing inconsistent code suggestions.
Laravel has recently explored this approach through Laravel Boost, using an agent skill to identify useful project conventions and turn approved findings into scoped rules.
AI coding rules are project-specific instructions that guide an AI coding assistant when it generates, modifies, or reviews code.
For example, a project might follow a rule such as:
These rules provide context that a general AI coding assistant may not automatically know.
The important point is that AI rules should describe decisions specific to the application, rather than repeating general Laravel or PHP recommendations.
A new project can document its conventions as development progresses. An older application is different. Its conventions may already be spread across controllers, models, validation classes, tests, database structures, and directories.
Developers who have worked on the application for years may understand these patterns naturally. An AI coding agent, however, needs those patterns to be made explicit.
Without this context, an AI assistant could generate technically valid code that does not fit the application’s existing architecture.
For example, if an application consistently places business logic in app/Actions, an AI assistant should understand that before creating a new service or introducing another architectural layer.
The first step is to inspect the application rather than immediately writing rules.
An AI-assisted audit can examine areas such as:
The objective is to discover repeated and meaningful decisions.
However, repetition alone does not automatically make something a useful AI rule. Laravel’s approach emphasizes identifying conventions that a future coding agent could reasonably implement differently.
One of the most important parts of the process is distinguishing Laravel defaults from decisions made by the development team.
For example, if a project uses a standard Laravel feature exactly as the framework normally generates it, documenting that behavior may provide limited additional value.
On the other hand, if the team has deliberately chosen a particular architecture or data-handling approach, that decision may be valuable to an AI assistant.
A useful question is:
“Could an AI developer reasonably make a different choice here?”
If the answer is yes, and the existing code provides strong evidence for the current approach, the pattern may deserve to become an AI coding rule.
Architecture is one of the most useful areas for AI coding rules.
Consider an application where controllers consistently delegate business operations to Action classes. If an AI assistant does not know this convention, it might place new business logic directly inside controllers.
A project rule could explain the established structure and give the AI a clear destination for new functionality.
The same principle applies to deliberate absences.
For example, if an application intentionally does not use a repository layer and works directly with Eloquent models, that boundary can also be documented. Recording what the project does not use can sometimes be just as useful as recording what it does use.
AI-generated assumptions should not automatically become project rules.
A better process is to collect examples from the codebase and present the evidence for developer review.
Laravel’s documented approach uses multiple consistent examples and looks for the absence of a meaningful competing pattern before proposing a rule. Developers can then accept, reject, modify, or change the scope of the proposed rule.
This review step is important because an existing codebase may contain legacy code, exceptions, or partially completed migrations.
The goal is to describe the application’s current conventions—not automatically redesign the application.
AI rules become more useful when they are relevant to the files or concepts where they apply.
For example, a testing rule does not necessarily need to be loaded for every frontend-related task. Similarly, a model-specific convention may not be relevant when an AI agent is modifying documentation.
Laravel Boost’s approach uses scoped rules so project knowledge can be associated with relevant paths or concepts. Approved rules are stored in .ai/rules, where they can be read, edited, version-controlled, and reviewed alongside the application.
This helps reduce unnecessary instructions and keeps AI context focused.
AI rules are more valuable when they travel with the source code.
Keeping them inside the repository means developers can review changes through the normal version-control workflow. New team members and different AI coding tools can also access the same project knowledge.
Laravel’s implementation uses approved rule information such as a file scope, a title describing the project decision, and a note containing the context needed by the coding agent.
This creates a shared source of project-specific instructions rather than relying entirely on individual developers’ AI settings or memories.
An AI coding rule should not be considered permanent.
Applications change. Teams introduce new architecture, replace old components, change testing practices, and remove legacy patterns. A rule that was accurate six months ago can eventually become misleading.
For this reason, rules should be reviewed during significant architectural changes and, where possible, alongside pull requests that modify the behavior described by the rule.
Laravel notes that automated stale-rule auditing is an area that could be developed further, while currently relying on code review to keep rules aligned with the application.
For PHP and Laravel teams, AI coding rules can provide an additional layer of project context for coding assistants.
The most useful rules are usually not long documents. They are concise instructions explaining important project decisions, architectural boundaries, exceptions, and conventions that an AI assistant might otherwise misunderstand.
A practical workflow is:
Inspect the codebase → identify meaningful patterns → collect evidence → review proposed rules → scope them appropriately → store them in version control → update them as the application evolves.
This approach allows AI-assisted development to work with the existing structure of an application instead of forcing every new code suggestion into a generic pattern.
Creating AI coding rules from an existing codebase is essentially a process of turning valuable institutional knowledge into structured, reusable instructions for AI development tools.
The strongest rules come from deliberate project decisions rather than simple repetition. They should be supported by evidence, reviewed by developers, scoped to the areas where they matter, and maintained as the application evolves.
For Laravel and PHP development teams adopting AI coding assistants, this approach can help bridge the gap between AI-generated code and the conventions of an existing application.
The result is not simply more AI instructions. It is a clearer way for AI tools to understand how a particular codebase is designed and how new code should fit into it.
AI coding rules are project-specific instructions that tell AI coding assistants how an application is structured and which development conventions they should follow. They can cover architecture, naming, testing, data handling, directory structure, and other project decisions.
Yes. An existing Laravel application can be inspected for recurring architectural and development patterns. Those findings can then be reviewed by developers and converted into rules that provide project-specific context to AI coding tools.
No. Framework defaults and mechanical formatting rules do not necessarily need to become AI rules. Useful rules should generally document meaningful project decisions that an AI assistant could otherwise implement differently.
Laravel Boost’s documented approach stores approved project rules under the .ai/rules directory. These files can be maintained and version-controlled with the application.
Rules should be reviewed whenever important architecture or development conventions change. Pull requests and major refactoring projects are good opportunities to check whether existing AI rules still accurately represent the codebase.
Laravel, “Extracting AI Rules from an Existing Codebase,” August 31, 2026. The article explains Laravel Boost’s approach to identifying existing project conventions, reviewing evidence, and recording approved scoped rules.
Source: https://laravel.com/blog/extracting-ai-rules-from-an-existing-codebase
