Locking Code Sections from AI Edits in Lovable

Why code locking is not native to Lovable's AI workflow

Lovable's AI agent works by understanding your project's full codebase and making changes across whatever files it deems necessary to implement your request. This cross-file capability is one of its strengths — it can refactor imports, update type definitions, and modify dependent components in one step. However, it also means the AI may modify files you consider stable or finalized. This is a real problem in production projects. You might have a carefully configured Supabase client, a custom authentication flow, or a complex data transformation function that took many iterations to get right. If the AI edits these files while implementing an unrelated feature, it can break working functionality and burn credits trying to fix what it broke. Lovable provides indirect mechanisms to control this. The AGENTS.md file (placed in your project root) contains instructions that the AI reads at the start of every session. By listing files that should not be modified, you give the AI clear boundaries. The @file syntax in prompts scopes changes to specific files. Plan Mode lets you review what the AI intends to change before any code is modified. None of these are as strong as a true file lock, but together they significantly reduce unintended edits.

• AI modifies stable files while implementing unrelated features because it has full codebase access
• No AGENTS.md file with preservation rules — the AI has no boundaries on which files to edit
• Prompts are too broad: 'Fix the login' may cause the AI to modify files beyond the login component
• Plan Mode not used before implementing — changes applied without review
• The AI's looping behavior may cause it to modify protected files while trying to fix a different bug

Error messages you might see

Before you start

• A Lovable project with files you want to protect from AI modifications
• Dev Mode access or GitHub integration to create the AGENTS.md file
• Knowledge of which files in your project are stable and should not be changed

How to fix it

// No AGENTS.md exists
// AI has no boundaries and may modify any file in the project

// AGENTS.md in project root
# Project Agent Instructions
## Protected Files (DO NOT modify these files)
- src/integrations/supabase/client.ts
- src/integrations/supabase/types.ts
- vite.config.ts
- tailwind.config.ts
- src/contexts/AuthContext.tsx
- src/lib/utils.ts
## Rules
- Do NOT rename or move existing component files
- Do NOT change database table schemas without explicit permission
- Do NOT modify the routing structure in src/App.tsx unless specifically asked
- When adding new features, create new files rather than modifying existing ones
- Preserve all existing import paths when refactoring

// Broad prompt — AI may modify many files
"Add a loading state to the user profile"

// Scoped prompt — AI focuses on the specified file
"@src/components/UserProfile.tsx add a loading skeleton that shows while user data is being fetched. Use the Skeleton component from @/components/ui/skeleton. Do not modify any other files."

Complete code example

1# Agent Instructions for This Project
2
3## Critical Rules
4
51. NEVER modify files listed in the Protected Files section below
62. NEVER delete or rename existing component files
73. When adding new features, create NEW files instead of heavily editing existing ones
84. Ask for clarification before changing any database schema or table structure
95. Preserve all existing import paths — do not reorganize the file structure
10
11## Protected Files (DO NOT EDIT)
12
13These files are stable and tested. Do not modify them for any reason:
14
15- `vite.config.ts` — build configuration
16- `tailwind.config.ts` — theme configuration
17- `src/integrations/supabase/client.ts` — Supabase client setup
18- `src/integrations/supabase/types.ts` — database type definitions
19- `src/contexts/AuthContext.tsx` — authentication logic
20- `src/lib/utils.ts` — shared utility functions including cn()
21- `src/App.tsx` — route definitions (add routes only, do not restructure)
22
23## Code Style Preferences
24
25- Use TypeScript strict mode for all new files
26- Use the `@/` import alias (maps to src/)
27- Use shadcn/ui components from `@/components/ui/`
28- Use `cn()` from `@/lib/utils` for all class name merging
29- Name components in PascalCase, utilities in camelCase
30- Add inline comments explaining WHY, not WHAT
31
32## Project Architecture
33
34- Pages go in `src/pages/`
35- Shared components go in `src/components/`
36- Page-specific components go in `src/components/[page-name]/`
37- Hooks go in `src/hooks/`
38- API/data logic goes in `src/services/`

Best practices to prevent this

• Create AGENTS.md as early as possible in your project — before the AI makes changes you need to protect
• List specific file paths in AGENTS.md rather than vague rules like 'don't change important files'
• Use @file references in every prompt to scope changes to the intended files
• Switch to Plan Mode for any change that might affect multiple files — review the plan before implementing
• Keep critical files version-controlled in GitHub so you can restore them if the AI ignores AGENTS.md instructions
• Add coding style preferences to AGENTS.md so the AI generates consistent code that matches your existing patterns
• Periodically check protected files in Dev Mode to verify they have not been accidentally modified
• End prompts with 'Do not modify any other files' as an extra safeguard when making targeted changes

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

Related error patterns