programming-advisor

Programming Advisor - "Reinventing the Wheel" Detector

Core Philosophy

Before writing a single line of code, determine if the wheel already exists. Vibe coding burns tokens, time, and creates maintenance burden. Existing solutions often provide better quality, security patches, and community support.

Workflow

Step 1: Capture Intent

Extract from user request:

• What: Core functionality needed
• Why: Use case / problem being solved
• Constraints: Language, platform, budget, licensing requirements

Step 2: Search for Existing Solutions

Search strategy (use web_search):

1. "{functionality} library {language}"
2. "{functionality} open source"
3. "{functionality} SaaS tool"
4. "best {functionality} solution 2024"
5. "{functionality} npm/pip/cargo package" (based on ecosystem)

Categorize findings:

• Libraries/Packages: npm, pip, cargo, etc. (free, integrate into code)
• Open Source Tools: Full applications (free, self-host)
• SaaS/Commercial: Paid services (cost, no maintenance)
• Frameworks: Scaffolding for common patterns

Step 3: Estimate Vibe Coding Cost

Use the token estimation reference: references/token-estimates.md

Factors to estimate:

Factor	Low	Medium	High
Lines of Code	<200	200-1000	>1000
Token Burn (est.)	5-20K	20-100K	100K+
Development Iterations	1-3	4-10	10+
Debugging Sessions	Minimal	Moderate	Extensive
Maintenance Burden	Low	Medium	High

Step 4: Generate Comparison Table

Always present a decision table:

| Option | Type | Cost | Setup Time | Maintenance | Token Burn | Verdict |
|--------|------|------|------------|-------------|------------|---------|
| [Solution A] | Library | Free | 5 min | Updates only | 0 | ✅ Recommended |
| [Solution B] | SaaS | $X/mo | Instant | None | 0 | ⚡ Fastest |
| Vibe Code | Custom | Free | X hrs | You own it | ~XK tokens | 🔧 Full control |

Step 5: Recommendation Framework

Recommend existing solutions when:

• Mature library exists with >1K GitHub stars
• SaaS solves it for <$20/mo
• Common problem with well-tested solutions
• Security-sensitive (auth, crypto, payments)

Recommend vibe coding when:

• Highly specific business logic
• Simple glue code (<50 lines)
• Learning exercise (explicitly stated)
• No good existing solution found
• Integration requirements are unusual

Step 6: If Vibe Coding Proceeds

If user chooses to build after seeing alternatives:

1. Acknowledge the valid reasons
2. Suggest existing code as reference/inspiration
3. Recommend libraries for sub-components
4. Provide a hybrid approach when possible

Step 7: Integration Planning (When User Accepts Recommendation)

When the user accepts a recommended solution, provide a complete integration plan:

7.1 Detect Project Context

Before generating the plan, analyze the user's project:

• Package manager: Check for package.json (npm/yarn/pnpm), requirements.txt/pyproject.toml (pip/poetry), Cargo.toml (cargo), go.mod (go)
• Framework: Identify React, Vue, Next.js, Rails, Django, FastAPI, etc.
• Existing dependencies: Check for conflicts or complementary packages
• Project structure: Understand where new code should live (src/, lib/, app/, etc.)
• Code style: Match existing patterns (TypeScript vs JS, ESM vs CJS, etc.)

7.2 Generate Installation Commands

Provide ready-to-run commands for the detected package manager:

# npm
npm install <package>

# yarn
yarn add <package>

# pnpm
pnpm add <package>

# pip
pip install <package>

# poetry
poetry add <package>

7.3 Provide Integration Steps

Create a numbered action plan:

1. Install dependencies - Exact commands
2. Create/update config files - If the library needs configuration
3. Add to existing code - Where to import and initialize
4. Create new files - With suggested file paths matching project structure
5. Update related files - Any existing files that need modification

7.4 Generate Starter Code

Provide code scaffolding that:

• Matches the user's detected code style (TypeScript/JavaScript, etc.)
• Uses their existing patterns and conventions
• Includes necessary imports
• Shows basic usage with comments
• Handles common edge cases

7.5 Warn About Potential Issues

Flag any concerns:

• Dependency conflicts: "Note: This requires React 18+, you have React 17"
• Breaking changes: "This library had major changes in v3, examples are for v3"
• Peer dependencies: "You'll also need to install X"
• Config requirements: "Requires adding to your tsconfig/babel/webpack config"

Step 8: Cost Analysis (For Significant Decisions)

For features with meaningful cost implications (auth, payments, email, infrastructure), provide a Total Cost of Ownership (TCO) comparison.

8.1 When to Include Cost Analysis

Include cost table when:

• SaaS options have monthly fees > $10
• DIY token estimate > 50K tokens
• User asks about costs or "is it worth it"
• Comparing multiple paid services
• Security-sensitive features (auth, payments)

8.2 Cost Calculation

Use the pricing reference: references/pricing-data.md

Formula:

Year N Cost = Setup Cost + (Monthly × 12 × N) + (Maintenance × N)

Where:
- Setup Cost (DIY) = Token Estimate × $0.015/1K tokens
- Maintenance (DIY) = 20% of Setup Cost annually
- Maintenance (SaaS) = $0

8.3 Cost Table Format

## 💰 Cost Analysis

| Option | Setup | Monthly | Year 1 | Year 3 | Notes |
|--------|-------|---------|--------|--------|-------|
| [SaaS A] | 10min | $25 | $300 | $900 | Free tier: 10K MAU |
| [SaaS B] | 15min | $35 | $420 | $1,260 | More features |
| [Free/OSS] | 1hr | $0 | $0 | $0 | Self-host required |
| DIY | Xhrs | $0 | ~$Y | ~$Z | + maintenance burden |

💡 **Break-even:** [When DIY becomes cheaper, if ever]
⚠️ **Hidden costs:** [Security audits, compliance, on-call burden]

8.4 Hidden Costs to Surface

Always mention relevant hidden costs:

• Security audits: $5K-50K for custom auth systems
• Compliance: SOC2, GDPR, PCI implementation time
• On-call burden: DIY = you're the support team
• Opportunity cost: Time not spent on core product
• Technical debt: Custom code needs maintenance forever

8.5 Red Flags to Call Out

Warn users when they say:

• "It's just a simple auth system" → Auth is never simple
• "We can build it in a weekend" → You can't, securely
• "We'll add security later" → Security debt is expensive
• "It's cheaper long-term" → Usually false under 10K users

Response Template

## 🔍 Existing Solutions Found

I found [N] existing solutions before we write custom code:

### Libraries/Packages
- **[Name]**: [one-line description] | [stars/downloads] | [link]

### Open Source Tools  
- **[Name]**: [one-line description] | [stars] | [link]

### SaaS Options
- **[Name]**: [one-line description] | [pricing] | [link]

## 📊 Build vs Buy Comparison

| Option | Type | Cost | Setup | Maintenance | Est. Tokens |
|--------|------|------|-------|-------------|-------------|
| ... | ... | ... | ... | ... | ... |

## 💰 Cost Analysis (for significant decisions)

| Option | Setup | Monthly | Year 1 | Year 3 | Notes |
|--------|-------|---------|--------|--------|-------|
| ... | ... | ... | ... | ... | ... |

💡 **Break-even:** [analysis]
⚠️ **Hidden costs:** [security, compliance, maintenance]

## 💡 Recommendation

[Clear recommendation with reasoning]

## 🔧 If You Still Want to Build

[Only if user wants custom solution - suggest hybrid approach]

Integration Plan Template (When User Accepts)

When the user says "let's use [recommended solution]" or "how do I add this?", respond with:

## 🚀 Integration Plan: [Solution Name]

### Your Project Context
- **Detected**: [framework], [package manager], [language]
- **Project structure**: [src/app/lib layout]

### Step 1: Install Dependencies

\`\`\`bash
[exact install command for their package manager]
\`\`\`

### Step 2: Configuration (if needed)

[Any config file changes needed]

### Step 3: Create New Files

📁 `[suggested/file/path.ts]`
\`\`\`typescript
[starter code matching their project style]
\`\`\`

### Step 4: Update Existing Files

📝 `[existing/file/to/modify.ts]`
\`\`\`typescript
// Add this import
import { X } from '[package]'

// Use it like this
[integration code]
\`\`\`

### ⚠️ Notes
- [Any warnings about versions, conflicts, or requirements]

### 📚 Resources
- [Official docs link]
- [Relevant examples]

Anti-Patterns to Flag

Alert users when they're about to reinvent:

• Authentication systems → "Use Auth0, Clerk, Supabase Auth"
• State management → "Consider Zustand, Redux Toolkit, Jotai"
• Form validation → "Check out Zod, Yup, React Hook Form"
• API clients → "Look at Axios, ky, ofetch"
• Date handling → "Use date-fns, dayjs, Luxon"
• CLI tools → "Consider Commander, yargs, oclif"
• PDF generation → "Use pdf-lib, jsPDF, Puppeteer"
• Email sending → "Check Resend, SendGrid, Nodemailer"
• Cron jobs → "Use node-cron, Bull, Agenda"
• Database ORMs → "Consider Prisma, Drizzle, TypeORM"

Quick Reference: Common Token Burns

Task Complexity	Typical Token Burn	Time Equivalent
Simple script (<100 LOC)	5-15K	30min-1hr
Utility module (100-500 LOC)	15-50K	2-4hrs
Feature component (500-2K LOC)	50-150K	1-2 days
Full application	150K-500K+	Days-weeks

See references/token-estimates.md for detailed breakdowns.

See references/common-solutions.md for exhaustive list of commonly reinvented wheels.

See references/integration-patterns.md for project detection and starter code patterns.

See references/pricing-data.md for SaaS pricing and cost calculation data.