The Frontend AI That Knows When NOT to Suggest useState

Introduction

Your AI assistant just ignored six months of your work.

You've built consistent patterns, organized your components, and established conventions. Your store handles state, your file structure makes sense, and your team knows where everything lives.

Then you ask AI to add a feature, and the code it gives you doesn’t fit anywhere. New useState hooks when you have global state. Inline styles when you use Tailwind. Random file names when you follow conventions.

Most AI coding tools are incredibly capable, they can solve complex problems, write clean code, and handle logic. But they often generate solutions in isolation, without considering your existing architecture.

Recently, I've been seeing specialized AI tools that take a different approach. Instead of jumping straight to code generation, they first analyze your project to understand existing patterns. I wanted to see if this approach really makes a difference, so I decided to test it.

The results showed something interesting about how different AI approaches handle established codebases. But first, I wanted to understand why this pattern mismatch happens so frequently.

Why Generic AI Defaults to Common Patterns

I ran a simple test with Claude Sonnet 4.5. Asked it to add features to an existing app, a theme switching, and a form validation feature. Despite having established patterns for each, Claude consistently suggested generic solutions:

• useState for state,
• inline styles instead of my utility classes, and
• manual validation logic instead of my schema setup.

Claude did read my files and understood what I was trying to build. But it defaulted to universal solutions rather than extending my existing patterns.

The 2024 State of React survey explains why. While modern libraries like Zustand grew from 28% to 42% adoption among developers, basic patterns still dominate training data. Most public code examples, tutorials, Stack Overflow answers, and isolated demos use fundamental React APIs because they work in any context.

Generic AI models learn from this public data. When they analyze your codebase during generation, they still lean toward statistically common solutions.

This isn't about intelligence. Claude is remarkably capable. It's about training bias. Generic models optimize for solutions that work universally, even when project-specific patterns would integrate better. They learned from isolated examples, not cohesive architectures.

This made me curious. What would happen if I used a tool specifically designed to understand existing codebases first? That's when I decided to test one of these specialized approaches.

How Context-Aware AI Works: Meet Kombai

I decided to test Kombai(a frontend specialized agent), one of the tools I'd been hearing about. It sounded promising because, instead of generating code first, it scans your codebase to understand existing patterns, then generates code that fits your architecture.

Kombai claims to outperform generic coding agents on complex frontend tasks. In their tests of 200+ real-world scenarios, they report higher compilation rates and better adherence to frontend best practices than tools like Sonnet 4 + MCPs or Gemini 2.5 Pro agents.

Benchmark numbers aside, I was more interested in understanding exactly how this scan-first approach works in practice. To understand this better, let’s look at how Kombai approaches code generation in three distinct phases.

Kombai's Three-Phase Approach

Phase 1: Codebase Scan

Kombai reads your project files like a human developer. It examines package.json to understand your dependencies, scans component folders to map reusable pieces, and identifies state management patterns. If you're using Zustand, it finds your store files. If you have a custom component library, it catalogs each component's props and functionality.

Phase 2: Pattern Recognition

With your codebase mapped, Kombai identifies your coding conventions. How do you name files? Where do you place API calls? What state management patterns do you follow? It builds a context model of your architectural decisions, not just what libraries you use, but how you use them.

Phase 3: Context-Aware Generation

When generating code, Kombai references this context model. Instead of defaulting to common patterns, it checks:

"Does this project use global state? Are there existing user preference patterns?" The code it generates follows your established conventions, uses your existing components, and integrates with your current architecture.

This process adds upfront scanning time that generic AI skips entirely. For developers working on production codebases with established patterns, this investment can prevent hours of refactoring poorly-fitting code.

But does this theoretical advantage translate to real-world results? I wanted to find out with a direct comparison.

Testing Agents

To test the difference, I built a multi-step form validation app using Next.js, TypeScript, React Hook Form, Zod schemas, and Zustand. The app had seven form sections with 30+ fields and complex validation patterns.

The app looks like this:

Then I gave both tools the same task:

Prompt:

 

Add a new form section: Emergency Contact Information. Include emergency contact name, relationship dropdown, phone number, and email. Add it between Work Details and Preferences sections.

Tools tested:

• Claude 4.5 via VS Code GitHub Copilot Chat
• Kombai via VS Code extension

Generic AI Output (Claude 4.5)

Claude approached the task methodically. It started generating immediately and read files as needed during the process. I watched it examine the existing form structure, check the Zustand store, and analyze validation patterns.

Process:

• No upfront scanning. It began coding right away
• Read 6 different files during generation to understand patterns
• Generated schema first, then component, then store updates
• Total time: 2 minutes 30 seconds

Output:

Claude created exactly what I asked for. The emergency contact schema used the same Zod patterns as existing forms. The component followed the established structure. It extended the Zustand store instead of creating useState declarations. The form integrated seamlessly into the navigation flow.

Files generated: 2 new files, 5 modified

Integration effort: Zero, compiled and ran immediately

Pattern consistency: Perfect match to existing architecture

Kombai Output

Kombai took a different approach. It spent 15 seconds scanning my entire codebase before generating any code. I could see it analyzing the project structure, reading package.json, examining existing schemas, and mapping component patterns.

Process:

• 15-second upfront codebase scan
• 6.2 seconds of thinking before starting code generation
• Generated all files simultaneously after analysis
• Total time: 1 minute 30 seconds

Output:

Kombai delivered functionally identical results. Same Zod schema structure, same component patterns, same Zustand integration. It even caught and fixed a small TypeScript issue in an existing schema that Claude missed.

Files generated: 2 new files, 7 modified (including the bug fix)

Integration effort: Zero, compiled and ran immediately

Pattern consistency: Perfect match plus one improvement

Metrics Comparison

Cost Breakdown:

• Claude: Used ~3% of monthly quota ($10 plan) ≈ $0.30 for this task
• Kombai: Used 56 credits, ~1.2% of monthly credits ($40 plan) ≈ $0.48 for this task

Both tools succeeded completely. They read my codebase, understood my patterns, and generated code that fit my architecture. Neither defaulted to useState nor ignored existing conventions. The time savings came from Kombai's scan-first approach, though at a slightly higher cost per task.

The difference wasn't capability, it was approach. Claude read files during generation, discovering patterns as needed. Kombai scanned everything first, then generated from the complete context. Both strategies worked, but the upfront analysis was faster and caught an additional improvement opportunity.

The upfront scanning advantage makes sense when you think about it. By mapping your entire architecture upfront, Kombai could see connections that on-demand reading might miss. It spotted that my existing schema had a TypeScript error because it analyzed all schema files together, not just the one it was creating.

This raised a question. What exactly was Kombai analyzing during that upfront scan? The process happened quickly, but it was clear from its behavior what it was looking at and how it used that information.

What Kombai Actually "Reads" in Your Codebase

During that upfront scan, Kombai wasn't just indexing files randomly. I could track exactly what it analyzed by watching the process and examining its outputs.

Project Structure Detection

1. package.json Analysis: Kombai identified every dependency I was using. React Hook Form, Zod, Zustand, and TypeScript. More importantly, it recognized the relationship between these libraries. It saw @hookform/resolvers and knew I was connecting Zod schemas to React Hook Form validation.
2. Folder Architecture: It mapped my entire folder structure: schemas/ for validation logic, components/forms/ for form components, store/ for Zustand state management, lib/ for utilities. When generating the emergency contact form, it knew exactly where each file belonged.

Pattern Recognition

1. Naming Conventions: Every schema file followed *-schema.ts, every form used *-form.tsx. Kombai picked up these patterns and applied them automatically.
2. Validation Architecture: It recognized my validation setup, each form used zodResolver, each schema exported both Zod objects and TypeScript types, error messages appeared with specific CSS classes.
3. Component Relationships: Kombai mapped how pieces connected, forms imported from components/index.ts, the review page displayed data from all sections, and step navigation relied on the Zustand store's counter.

Code That Shows the Difference

The real proof came when I compared the actual schemas both tools generated. The difference in context awareness was immediately visible:

Claude 4.5 Generated:

import { z } from "zod";

export const emergencyContactSchema = z.object({
  emergencyContactName: z
    .string()
    .min(2, "Emergency contact name must be at least 2 characters")
    .max(100, "Emergency contact name must be less than 100 characters"),
  relationship: z.string().min(1, "Please select a relationship"), *// No validation*
  emergencyPhone: z
    .string()
    .regex(/^\+?[1-9]\d{1,14}$/, "Please enter a valid phone number"), *// Inline regex*
  emergencyEmail: z.string().email("Please enter a valid email address"), // long name, not reused
});

Kombai Generated:

import { z } from "zod"
import { RELATIONSHIPS } from "@/lib/constants"        *// Uses existing constants*
import { PHONE_E164_REGEX } from "@/lib/validators"    *// Reuses shared validator*

export const emergencyContactSchema = z.object({
  name: z.string().min(2, "Name must be at least 2 characters"), *// Clean naming*
  relationship: z.enum(RELATIONSHIPS, {                          *// Enum validation*
    message: "Select a relationship",
  }),
  phone: z.string().regex(PHONE_E164_REGEX, "Use international format"),
  email: z.string().email("Enter a valid email"),
})

Claude generated working code that followed Zod patterns perfectly. But Kombai generated code that integrated with my existing architecture, importing existing constants, reusing shared validators, and maintaining architectural consistency.

Claude generated working code that followed Zod patterns perfectly. But Kombai generated code that integrated with my existing architecture, importing existing constants, reusing shared validators, and maintaining architectural consistency.

Though this pattern recognition was impressive, I found that Kombai still has clear boundaries when working outside its optimized domain.

What It Can't Detect (And Why That Matters)

Based on my testing and Kombai's documented capabilities, the limitations became clear in specific scenarios.

• Technology Stack Boundaries: Kombai works really well with over 30 popular frontend libraries. For newer or less common libraries not in its training data, you might need to give it more detailed instructions. When I used Arco Design (a newer component library), I had to explain the library's patterns and rules more clearly so Kombai could understand the setup better. With this extra guidance, it integrated much better with my existing setup when it comes to less common libraries.
• Development Scope Limitations: The frontend-only focus creates practical workflow challenges. While Kombai excels at frontend architecture, teams still need separate tools for backend development, database design, and server-side logic. This creates a workflow split that general-purpose tools like Claude avoid. Additionally, without reference images or Figma designs, Kombai's design creativity lags behind Claude's imagination. When creating UI from scratch, Claude often generates more visually appealing interfaces while Kombai sticks to safer, conventional layouts.

These limitations are reasonable. Context-aware AI excels at understanding architectural patterns and technical conventions within its domain. The gaps occur when projects require bleeding-edge libraries, cross-stack development, or creative design work without visual references.

When You DON'T Need Context Awareness

Context-aware AI isn’t always the better choice. In fact, there are plenty of times when a good old generic model like Claude makes more sense.

1. When You’re Still Figuring Things Out: If you’re learning React, exploring a new library, or starting a project from scratch, you don’t need context awareness. You don’t have patterns yet. Generic AI gives you standard solutions that help you learn and move faster.
2. Quick Prototypes & One-Off Demos: When you just need something working, like a quick client demo or proof of concept, skip the context scanning. Claude’s fast, flexible output gets the job done without setup overhead.
3. Small, Isolated Tasks: For Stack Overflow-style problems, a single function, algorithm, or component, context awareness doesn’t add much. You just need the code.
4. Cross-Domain or New Tech Work: If your project jumps between frontend, backend, and new frameworks, generic AI’s broader experience usually wins.

Context-aware AI shines as your app grows and patterns emerge. But if your project’s still light, experimental, or evolving, that extra context is often just overhead.

Conclusion

I ran the same task through both tools and measured what actually happened. The numbers don't lie. Kombai was 40% faster and caught architectural issues Claude missed.

Both tools generate working code. The difference is integration quality. Claude gives you universal solutions that work anywhere. Kombai gives you code that fits your existing system.

My recommendation: If you're building on established frontend projects with consistent patterns, Kombai's context-aware approach saves real time. For prototypes, learning, or cross-stack work, stick with Claude's versatility or any generic agents.

The choice is simple: Do you need code that integrates seamlessly, or code that works universally?

Test Kombai yourself with their free credits and see how context-aware AI handles your specific frontend patterns.