Every developer has lived this nightmare: It's your first day on a new project. You open the repository. There's a utils folder with 47 files. Half the components use kebab-case, the other half use camelCase. There's a NewButton.tsx and a Button.tsx and a ButtonComponent.tsx, and you have no idea which one you're supposed to use. Someone started implementing authentication but gave up halfway through. The README was last updated in 2021.
Welcome to reality.
This is the problem every "AI code generation" tool conveniently ignores. They're great at generating code from scratch—give them a blank canvas and a prompt, and they'll build you a beautiful, consistent, perfectly-architected application. But the moment you ask them to continue someone else's work? Silence.
At Rocket, we decided to solve the problem everyone else was avoiding.
The Problem Nobody Talks About
Here's the thing about AI code generation in 2026: every tool can generate code from scratch. Cursor, GitHub Copilot, Lovable, Replit—they're all excellent at building new applications. Give them a clean slate and clear requirements, and they'll produce high-quality code that follows best practices.
But that's not how real development works.
Real development is inheriting a six-month-old Next.js project where:
- The original developer left three months ago
- There are two competing state management patterns (Context API and Zustand)
- Some API calls use
fetch, others use axios, and a few brave souls tried ky
- Half the components are functional, half are class-based
- The TypeScript configuration is set to
"strict": false because "we'll fix it later"
- There's a
services/ folder, a utils/ folder, and a helpers/ folder, and nobody remembers the difference
Now try asking an AI to add authentication to that codebase. Should it use the existing pattern or start fresh? Should it follow the inconsistent naming conventions or fix them? Should it use fetch or axios? Should it add to services/, utils/, or helpers/?
This is the question that defines whether AI code generation is a toy or a tool.
Why This Is Actually Hard
When we started building Rocket's GitHub integration, we thought the hard part would be the Git operations—cloning repos, managing branches, handling merge conflicts. Those turned out to be the easy parts.
The hard part was teaching AI to do what every senior engineer does instinctively on their first day: read the room.
Challenge #1: Understanding What Already Exists
Generating new code is pattern matching. Understanding existing code is archeology.
When you connect a GitHub repository to Rocket, we don't just clone the files—we analyze the entire codebase to answer questions like:
- What framework patterns is this project using? (App Router vs Pages Router, server components vs client components)
- What's the component architecture? (atomic design, feature-based folders, flat structure)
- What's complete and what's half-finished? (is that
auth/ folder a fully-implemented feature or an abandoned experiment?)
- What are the implicit rules? (why do some files have
.component.tsx and others don't?)
The difference between a junior developer and a senior developer is that the senior developer spends their first week reading code before writing any. We had to teach AI to do the same thing.
Challenge #2: Deciding When to Follow vs When to Fix
Here's where it gets philosophically interesting.
Let's say you inherit a codebase where every component file is 800 lines long—clearly violating best practices. As an AI system, should you:
A) Follow the existing pattern (write new 800-line component files to maintain consistency)
B) Fix the existing pattern (break components into smaller pieces, refactor the entire codebase)
C) Do something in between (write smaller components but don't touch the existing ones)
The answer depends on context humans understand but machines don't:
- How much time does the user have?
- Is this a side project or production code?
- Is the "bad pattern" actually bad, or is there a good reason for it?
- Will changing the pattern break something?
We built a system that:
- Identifies the dominant patterns in the codebase (even if they're not best practices)
- Respects those patterns by default (consistency > perfection in existing code)
- Flags problematic patterns (and asks the user if they want to fix them)
- Learns from user feedback (if you reject AI changes that break the pattern, it adapts)
Challenge #3: The Half-Finished Feature Problem
This is my favorite problem because it's so uniquely human.
You clone a repository and find:
- An
auth/ folder with login.tsx, register.tsx, and forgot-password.tsx
- A
useAuth hook that's implemented but never imported anywhere
- API routes for
/api/auth/login and /api/auth/register but not /api/auth/logout
- Environment variables for
AUTH0_DOMAIN but the actual Auth0 integration is commented out
Is authentication implemented or not?
A human developer would:
- Check if the auth components are used anywhere (nope)
- Check if the environment variables are set (nope)
- Conclude: "Someone started this but never finished it"
- Either finish it or start fresh
We had to teach AI to do the same detective work. Now when Rocket analyzes a codebase, it doesn't just look at what files exist—it looks at:
- What's actually imported and used
- What has tests (complete features usually have tests)
- What has corresponding environment variables set
- What's connected to the actual application flow
If a feature is half-finished, Rocket tells you: "I found an auth folder, but it doesn't look complete. Want me to finish it or start fresh?"
What We Actually Built
Let me show you what this looks like in practice.
Step 1: The Analysis Phase
When you connect a GitHub repository to Rocket, the first thing we do is run it through our codebase analyzer. This isn't a simple file tree inspection—it's a full architectural audit.
For a typical Next.js project, we identify:
- Project structure (App Router, Pages Router, monorepo structure)
- TypeScript configuration and strictness level
- State management patterns (Context, Redux, Zustand, none)
- API patterns (REST, tRPC, GraphQL)
- Styling approach (CSS Modules, Tailwind, styled-components, etc.)
- Component patterns (atomic design, feature folders, etc.)
- Testing setup (Jest, Vitest, Playwright, none)
- Existing integrations (Supabase, Auth0, Stripe, etc.)
For monorepos, we go deeper:
- Identify all packages/apps in the workspace
- Let the user choose which one to work on
- Understand cross-package dependencies
- Avoid breaking shared code
Step 2: The Continuation Phase
Once we understand the codebase, Rocket doesn't just generate code—it continues the story.
If you ask Rocket to "add authentication," it doesn't give you a generic auth implementation. It:
- Checks if auth is partially implemented (and offers to complete it)
- Checks what other features use for API calls (and matches that pattern)
- Checks your styling approach (and matches it)
- Checks your folder structure (and adds files in the right places)
- Generates code that looks like a senior developer who's been on your team for six months wrote it
Step 3: The Sync Phase
Here's where it gets really interesting. Every change Rocket makes is:
- Committed to a dedicated branch (
rocket-update)
- Opened as a pull request to your default branch
- Reviewable by your team (with full diff visibility)
- Bidirectional (you can make changes in your IDE and pull them into Rocket)
This isn't "AI overwrites your code." This is "AI joins your team."
You can:
- Make changes in Rocket → PR created automatically → review → merge → pull back to Rocket
- Make changes locally → push to GitHub → pull into Rocket → continue AI-assisted work
- Have teammates work locally while you work in Rocket, and sync both directions
The Edge Cases Nobody Talks About
Building this feature taught us that edge cases are the real product.
Edge Case #1: The Inconsistent Naming Convention
The scenario: A codebase where:
- API routes use kebab-case:
/api/user-profile, /api/order-history
- Frontend components use PascalCase:
UserProfile.tsx, OrderHistory.tsx
- Utility functions use camelCase:
getUserProfile(), getOrderHistory()
What most AI tools do: Pick one convention arbitrarily (usually whatever's in their training data).
What Rocket does: Recognize that each domain has its own convention, respect all three, and apply the correct one based on what type of file is being generated.
Edge Case #2: The Undocumented Dependency
The scenario: The codebase uses a custom fetcher wrapper around fetch that adds authentication headers, retries, and error handling. But it's not documented anywhere.
What most AI tools do: Generate code using vanilla fetch (because they don't know the wrapper exists).
What Rocket does:
- Detect that 90% of API calls use this
fetcher function
- Recognize it's a wrapper (by analyzing its signature)
- Use it for all new API calls
- Ask if you want to refactor the remaining 10% to use it too
Why This Matters More Than You Think
Here's the uncomfortable truth: most "AI code generation" tools are built for demos, not for work.
They're optimized for the TechCrunch headline: "Watch AI build a full-stack app in 60 seconds!" They generate beautiful greenfield projects that make great screenshots.
But real development isn't greenfield projects. Real development is:
- Maintaining a three-year-old Next.js app
- Refactoring a six-month-old feature
- Fixing bugs in code you didn't write
- Adding features to a codebase with technical debt
- Working with a team where everyone has different coding styles
The ability to understand and continue existing code is the difference between a coding assistant and a coding teammate.
At Rocket, we didn't just build a tool that generates perfect code from scratch. We built a tool that can jump into your messy, real-world codebase and start contributing like a senior engineer.
What This Unlocks
When AI can actually understand existing codebases, suddenly a lot of previously-impossible workflows become possible:
1. Onboarding New Developers
Instead of spending your first week reading code, you can ask Rocket:
- "Where is authentication handled in this codebase?"
- "What's the pattern for creating new API routes?"
- "Why are there two different Button components?"
And get architectural answers, not just file locations.
2. Refactoring Legacy Code
"This UserDashboard.tsx file is 1,200 lines. Break it into smaller components following the existing patterns in this codebase."
Rocket doesn't just split the file—it:
- Matches your naming conventions
- Matches your folder structure
- Maintains imports and exports
- Updates all references
- Runs your tests to verify nothing broke
3. Documenting Undocumented Code
"Generate a README for this codebase that explains the architecture, conventions, and how to add new features."
Because Rocket actually understands your code, it can write documentation that's specific to your project, not generic boilerplate.
4. Migrating Between Frameworks
"Migrate this component from Pages Router to App Router while keeping the same functionality."
Because Rocket understands what the component does (not just what it says), it can translate intent across different patterns.
5. Team Collaboration with AI
The most exciting one: AI becomes a team member that understands your codebase.
Instead of every developer working with their own isolated AI assistant that has no memory of the project, your whole team shares a Rocket workspace that:
- Understands your codebase architecture
- Remembers past decisions and patterns
- Learns from code reviews
- Maintains consistency across contributors
What We Learned
Building this feature taught us three things:
1. Context Is Everything
The same code change is good or bad depending on context. Adding type safety is great in a new project, but if you're working in a codebase with "strict": false, forcing strict types will break everything. AI needs to understand context, not just syntax.
2. Consistency > Perfection
In existing codebases, maintaining consistency with "okay" patterns is usually better than introducing "perfect" patterns that break consistency. A codebase where everything follows the same mediocre pattern is easier to work with than a codebase with a mix of perfect and mediocre patterns.
3. Trust Requires Transparency
Developers won't trust AI that silently changes code. Every change needs to be visible, reviewable, and reversible. That's why we built the PR workflow—not because Git operations are hard, but because trust requires visibility.
Why We're Excited
Every other AI coding tool is racing to build better code generation. Faster models. Longer context windows. Better prompting.
We're racing in a different direction: teaching AI to understand the code that already exists.
Because here's the reality: the world has billions of lines of existing code, and only a tiny fraction of new code written every day. If AI can't understand and continue existing code, it's limited to greenfield projects—which is maybe 5% of real development work.
At Rocket, we're building for the other 95%.
Try It Yourself
If you've ever inherited a codebase and wished you had a senior engineer to help you understand it, Rocket's GitHub integration is built for you. It's the first AI tool that actually tries to understand your code instead of just generating new code next to it. Because the future of AI-assisted development isn't generating code from scratch. It's understanding the code we've already written—and helping us make it better.
Try Rocket's GitHub integration: rocket.new
Read the technical docs: docs.rocket.new/build/create/from-github
