That code you rejected 3 times? Your AI just suggested it again.

I'm staring at Cursor suggesting neutral-100 for a background color. Again.

Our design system uses neutral-010, neutral-020, neutral-030... up to neutral-090. The gaps are intentional - room to grow up or down when we need more shades. But AI assumes every design system follows the standard 100, 200, 300 pattern.


/* What Cursor suggests every damn time */
.card-background {
 background-color: var(--neutral-100);
 border: 1px solid var(--neutral-200);
}

/* What actually exists in our system */
.card-background {
 background-color: var(--neutral-010);
 border: 1px solid var(--neutral-020);
}


The --neutral-100 variable doesn't exist. The component breaks. I fix it, explain why, and move on. Three hours later, new chat session, same suggestion.

Yesterday it happened with testing frameworks. Our entire codebase uses Vitest for visual tests. Every single test file. But Cursor keeps generating Jest syntax:


// Cursor's favorite suggestion
import { describe, it, expect } from '@jest/globals';
describe('Button component', () => {
 it('should render correctly', () => {
   expect(component).toMatchSnapshot();
 });
});

// What we actually use everywhere
import { describe, it, expect } from 'vitest';
describe('Button component', () => {
 it('should render correctly', () => {
   expect(component).toMatchInlineSnapshot();
 });
});

The syntax is close enough that you don't catch it immediately. The test runs, fails, and you spend 10 minutes figuring out why your snapshot assertions are broken.

The Context Window Death Spiral

AI context windows burn through tokens fast. Start a new session, lose all your previous explanations. You're back to square one, re-explaining the same architectural decisions you've made dozens of times.

I tried solving this with Cursor Rules. Added our design system specs, testing preferences, component patterns - everything I was tired of repeating. The markdown file hit 800 lines.

Cursor started skimming. It would read the first 200 lines, maybe grab something from the middle, then ignore the rest. Suggestions got worse, not better. The AI was confident about rules it never actually read.

<!-- Line 1-50: Color system -->
neutral-010: #fafafa
neutral-020: #f5f5f5
neutral-030: #ededed
...

<!-- Line 300-400: Testing preferences -->
- Use Vitest, not Jest
- Visual regression tests with toMatchInlineSnapshot
- Component tests should cover accessibility
...

<!-- Line 600+: Architecture decisions -->
- No CSS-in-JS solutions
- Tailwind utilities only, no custom classes
- TypeScript strict mode required
...

Past 500 lines, the system breaks down. Sometimes it reads the color rules but ignores testing. Sometimes it catches the TypeScript requirements but suggests CSS-in-JS anyway. Never all of it together.

I split the rules into multiple files. .cursorrules, design-system.md, testing-guide.md, architecture.md. Now I'm managing four different documentation files, trying to keep them in sync as our system evolves. Half the time I forget to update one of them.

The Startup Problem

Components work fine with AI. Button, Card, Input - single items with clear interfaces. The AI can understand "use the Button component" and mostly gets it right.

But at a startup, you're constantly building things that aren't components yet. New pages, complex interactions, experimental features. The AI needs to understand your typography scale, spacing system, color palette, elevation levels, animation preferences, and accessibility requirements simultaneously.

// AI needs context for ALL of this
function FeatureCard({ title, description, priority }) {
 return (
   <div className={`
     // Typography: what scale? what weights exist?
     // Spacing: internal padding, margin rules
     // Colors: background, text, borders
     // Elevation: shadow levels, hover states
     // Animation: transition timing, easing
   `}>
     {/* Complex layout that requires understanding
         all our design decisions at once */}
   </div>
 );
}

Every new feature becomes a context explosion. The AI pulls from its training data instead of your actual system. You end up with designs that look reasonable but break your carefully crafted consistency.

Why Everyone Hits This Wall

Engineering deals with the same problem for code architecture. Product managers for business logic. Designers for interaction patterns. Everyone spends their day re-explaining decisions to AI that should already understand the context.

The context window limitation isn't just technical - it's organizational. Your company's knowledge is scattered across decision docs, style guides, architectural decision records, meeting notes, and tribal knowledge. AI gets fragments, never the full picture.

Building Brief to Fix This

We built briefhq.ai specifically for this problem. Instead of cramming everything into context windows or managing massive rules files, Brief uses MCP with RAG to surface exactly the relevant context for each request.

When you ask for a component, Brief knows your design system, your testing setup, your architectural constraints, and your business requirements. Not because it read a 1000-line markdown file, but because it can intelligently pull the right context without overwhelming the AI.

The AI gets the context it needs. You stop repeating yourself. Your team stops fighting the same battles every single session.

---

Join the waitlist at briefhq.ai

‍