The future isn’t AI replacing developers — it’s developers teaching AI how we build. Then letting it handle the boring parts.
I got tired of rebuilding admin panels from scratch, so I did what any sane developer would do in 2025: I made the AI do it.
We already had Admiral, our open-source React component library for internal tools. Tables, forms, filters — all the essentials for admin dashboards. But the wiring? Still manual.
That changed when I integrated .cursor/rules into the project – a special directory that contains development guidelines written in Markdown format. These rules integrate with the Cursor IDE and help follow project-wide standards when writing code.
You can learn more in the official documentation:
Basically, I streamlined and accelerated our development process and created a reusable set of AI instructions for working with Admiral to help us maintain high-quality code across all our Cursor-powered projects.
I wrote Markdown-based rules that taught Cursor how to use Admiral components, hooks, file structures, and naming conventions.
Now, when I need a new CRUD UI, I just feed the AI a short config:
@crud-page
Resource: /api/products
Fields: name, price, category
Filters: category
Cursor generates a fully-typed, production-ready UI: routes, layout, forms, table, filters; all conforming to our codebase standards.
This isn’t about AI helping developers, more like the developers teaching AI how we actually build software — then letting it handle the boilerplate.
I’m training it to understand and enforce our architecture, UI patterns, and code quality standards. By embedding project-specific rules into .cursor/rules
, I’ve effectively built a reusable AI assistant that knows how to generate consistent, typed, and production-ready admin UIs tailored to our stack. It can spin up CRUD pages with full routing, component usage, form logic, filters, and even menu config — all in minutes, without a single line of manual glue code. It’s like giving your junior dev a perfect memory, 24/7 availability, and zero burnout.
That way,
- I don’t skip type safety.
- I don’t bypass lint rules
- I don’t touch code I wouldn’t deploy
And now I can spin up new admin features in minutes.
Ready to see the full setup?
I’ll break down how the rules work, what’s in each file, and how to extend the system for my own team. Let’s do a full walkthrough!
Right now, Admiral ships with three key rules inside .cursor/rules
:
crud-page.mdc
– how to build CRUD pages with Admiral;admiral-components.mdc
– how to use our React components;admiral-hooks.mdc
– how to use shared hooks across projects.
admiral-components.mdc
and admiral-hooks.mdc
These rules are always included in Cursor's context. They act like cheat sheets for the AI — so it knows which components exist, what props they take, and what patterns to follow. That means no more hallucinated props or accidental misuse of internal APIs. Instead, consistent code that matches how we actually build.
crud-page.mdc
: The Heart of CRUD Automation
Admin panels are CRUD-heavy by nature. This rule teaches Cursor how we handle them — not just the UI, but the file structure, naming, typing, and component usage.
It enforces:
- A consistent structure for all CRUD pages;
- Predictable variable and function names;
- Approved usage of components from @devfamily/admiral;
- File and directory structure that matches our standards.
All we have to do is describe the resource and fields. Cursor takes it from there. How the Rule Works (From the AI’s Perspective)
-
Core Logic
At the core of this setup is the way I’ve taught the AI exactly what a CRUD page should look like in our codebase. It’s about enforcing structure. I made sure the AI understands how we organize our files, how we name functions and variables, and what the required sections of each page config are — like path, resource, and index. I also gave it clear boundaries on which components from our Admiral library it’s allowed to use, and how to use them properly. That way, every CRUD page it creates follows the same architecture, the same conventions, and the same level of quality I’d expect from a human teammate.
-
Folder Structure
Every page gets its own directory inside the project:
-
AI Responsibilities
I’ve set it up so that Cursor knows exactly what to do once it gets the input. It creates all the right files in the right places, registers the routes in the
pages
directory, and even adds a menu item if the config calls for it. Every component it uses is fully typed and comes straight from our@devfamily/admiral
library — no third-party randomness or rogue elements. And once the code is generated, Cursor automatically runs TypeScript and lint checks on everything. If something’s off, it fixes it on the spot. -
Best Practices
Baked In The rule also includes a bunch of practical tips I’ve baked in over time — things I found myself repeating in code reviews. It knows how to handle column widths and when to use custom renderers inside tables. It understands how we group filters and use
allowClear
for select inputs to keep the UI clean. For forms, it follows our layout rules usingcolumnSpan
, and it knows when to break fields into modular components for readability. Even table actions are handled the way we like them — usingTopToolbar
with the right set of icon buttons, so everything feels polished out of the box. -
Type Safety
The AI knows where to find Admiral’s internal types:
node_modules/@devfamily/admiral/lib/admiral/crud
Literally no more type mismatches.
Developer Experience
If you use @crud-page
in the prompt, Cursor will either ask for the necessary inputs or act on what you’ve already provided.
Here’s the config format:
Base name: Products
Resource: /api/products
Table: name, price, category
Create fields: name, price, category
Edit fields: (same)
Filter fields: category
Quick filters: (same)
From there, Cursor generates everything: pages
, types
, layout
, forms
, filters
, routing
, menu
— all wired up and ready to go.
You get a new feature in minutes with no glue code and skipped types.
Real Example
We start by triggering the @crud-page rule
.
Since no config was given, Cursor asks us for the required info. We reply with the full setup.
Once I hand over the config, the AI gets to work. It builds out the full file structure, fills in all the logic based on the rules I’ve defined, and immediately runs type checks and linter passes on the result. If anything breaks, it doesn’t just point it out — it fixes it. I don’t even have to leave the editor.
We end up with clean, deploy-ready code. From there, we can iterate — either by prompting the AI again or tweaking files manually.
Conclusion
We’re using .cursor/rules
on real projects today. It’s already saving us hours, and the results are more consistent than any junior dev or templating tool we’ve used before.
Next up: expanding the rule set to cover layout patterns, async logic, and deeper form validation.