AI Coding Agent Setup by Framework
An agent is only as good as what it knows about your project. These guides cover the rules file that works for each framework, the MCP servers worth wiring up, and the mistakes models repeatedly make in that ecosystem, so you can rule them out once instead of every session.
By framework
Next.js
Next.js has two routing systems that look similar in code but behave completely differently, and most model training data blends them. An agent needs to know which router the project uses, which Next major version is installed, and where the server/client boundary sits, because almost every wrong answer in this ecosystem comes from mixing App Router and Pages Router idioms. It also needs to know that server components, route handlers, and server actions all run on the server but have different rules about caching, streaming, and input validation.
6 common agent mistakes · rules file included
SvelteKit
SvelteKit moved fast enough that training data contains three incompatible generations of it: Sapper, SvelteKit 1.0, and SvelteKit 2 on Svelte 5. The single most useful thing an agent can know is which Svelte version the project runs and whether runes are enabled, because that decides the syntax of nearly every component it writes. It also needs the universal versus server-only load distinction, since that boundary is enforced by filename rather than by anything visible inside the file.
6 common agent mistakes · rules file included
Nuxt
Nuxt 3 and later rebuilt the framework on Vue 3, Vite, and Nitro, which means Nuxt 2 answers are not partially correct, they are entirely wrong. An agent needs to know that composables, components, and utils are auto-imported, that the server directory runs on Nitro with h3 helpers rather than Express, and that data fetching has to be SSR aware or the same request fires twice. Config lives in defineNuxtConfig and runtime values come from useRuntimeConfig, not from process.env at the point of use.
6 common agent mistakes
Laravel
Laravel is convention heavy, which helps an agent right up until conventions change between major versions, and Laravel 11 moved a lot: no HTTP kernel, a slimmer app skeleton, and middleware plus routing registered in bootstrap/app.php. An agent needs the major version, the queue and cache drivers in use, and whether the frontend is Blade, Livewire, or Inertia, because those three lead to completely different code for the same feature. Eloquent's ergonomics are also its trap: the easy way to write a relationship access is usually the way that generates a query per row.
6 common agent mistakes · rules file included
Django
Django's ORM is the centre of gravity: it is expressive enough that an agent can write something readable and correct-looking that issues hundreds of queries. An agent working here needs to know the Django version, whether the project uses function based or class based views, how settings are split across environments, and that any model edit implies a migration. Async support exists but is partial, so the boundary between sync ORM code and async views is a real source of runtime failures rather than a style question.
6 common agent mistakes · rules file included
Ruby on Rails
Rails has twenty years of accumulated idioms in training data, and a large share of them were removed years ago, so an agent's confident answer is often a Rails 4 answer. The frontend story in particular forked several times, from Sprockets to Webpacker to importmaps and Hotwire, and picking the wrong one produces code that never loads. An agent also needs to understand that the schema file is generated output and that ActiveRecord callbacks are the default place agents hide side effects.
6 common agent mistakes
React Native
React Native shares JSX and hooks with React on the web and shares almost nothing else, which is exactly why agents go wrong here: they carry web assumptions across a boundary that looks invisible in the source. An agent needs to know that there is no DOM, that styling is a constrained flexbox subset rather than CSS, and that any dependency containing native code requires a rebuild rather than a Metro refresh. It also needs to know whether the New Architecture is enabled, since that affects which third party libraries work at all.
6 common agent mistakes · rules file included
Expo
Expo's value comes from managing the native layer for you, and almost every agent failure here is an agent stepping around that management because older React Native advice told it to. The agent needs to know the SDK version, whether the project uses continuous native generation or has committed native directories, and whether the target runtime is Expo Go or a development build. Package versions are pinned to the SDK, so installing with the wrong tool is enough to break a build that was previously fine.
6 common agent mistakes · rules file included
Flutter
Flutter's API has been stable for years but its widget catalogue has churned, and Dart's move to sound null safety split training data into pre and post eras that do not compile together. An agent needs the Flutter and Dart versions, the state management approach the project actually uses, and whether Material 3 is enabled. Layout errors here are constraint errors rather than style errors, so an agent that does not reason about bounded and unbounded constraints will keep producing overflow warnings it cannot explain.
6 common agent mistakes · rules file included
By agent
Each framework has a page per tool with the exact rules file and settings.