Ragex Comprehensive Demo: Product Cart Application
View SourceThis demo showcases Ragex's powerful code analysis and AI-enhanced capabilities using a deliberately mediocre product cart application. The code contains numerous quality issues that Ragex can detect, analyze, and help improve.
Table of Contents
- Demo Overview
- Project Setup
- Code Quality Issues Present
- Ragex Analysis Walkthrough
- AI-Enhanced Features
- Refactoring Recommendations
- Conclusions
Demo Overview
Goal: Demonstrate Ragex's comprehensive analysis capabilities on a realistic e-commerce cart system with intentional quality issues.
Technologies:
- Elixir application (product cart)
- 5 modules with 500+ lines of problematic code
- Multiple security vulnerabilities
- Code duplication, complexity, and architectural issues
Ragex Features Demonstrated:
- Security vulnerability scanning (Phase 1)
- Code complexity analysis (Phase 2)
- Code smell detection (Phase 3)
- Code duplication detection (Phase 11)
- Dead code analysis (Phase 11)
- Dependency and coupling analysis (Phase 11)
- Impact analysis and refactoring suggestions (Phase 11G)
- AI-enhanced validation and insights (Phases A-C)
Project Setup
1. Navigate to Demo Directory
cd examples/product_cart
2. Analyze the Codebase
First, let Ragex analyze and index the codebase:
# From ragex root directory
mix ragex.analyze --path examples/product_cart/lib
This builds the knowledge graph, creates embeddings, and prepares the codebase for analysis.
Code Quality Issues Present
The demo application intentionally includes:
Security Issues (8+)
- Hardcoded API keys and secrets (lines with
sk_live_,pk_live_, etc.) - Unsafe deserialization with
:erlang.binary_to_term(Cart.ex:142) - Weak cryptography using MD5 hashing (Cart.ex:236, Product.ex:157)
- Potential code injection vulnerabilities
Code Complexity (High)
- Cart.add_item/4: 56 lines, nesting depth 6, cyclomatic complexity 10+
- Cart.update_item/4: 56 lines, nearly identical structure
- Cart.checkout/8: 68 lines, 8 parameters, nesting depth 8+
- Product.create_product/6: 66 lines, 6 parameters, nesting depth 6
- Product.update_product/7: 62 lines, 7 parameters
Code Smells (15+)
- Long Functions: checkout/8, add_item/4, create_product/6
- Deep Nesting: 6-8 levels in multiple functions
- Magic Numbers: 50, 100, 200, 0.1, 0.15, 0.2, 10000 hardcoded everywhere
- Complex Conditionals: Multiple
orchains, nested if statements - Long Parameter Lists: checkout/8 (8 params), create_order/13 (13 params)
Code Duplication (Severe)
- Discount calculation logic duplicated 4 times (Cart.ex, Product.ex)
- Validation logic duplicated between add_item and update_item
- Category validation duplicated
- Price calculation duplicated
Dead Code (4 functions)
Cart.old_calculate_discount/1- never calledCart.legacy_validate_cart/1- never calledProduct.old_price_calculator/1- never calledProduct.legacy_category_validator/1- never called
Tight Coupling
- Product module directly depends on Cart, Inventory, Pricing, Analytics
- High efferent coupling (outgoing dependencies)
- Difficult to test in isolation
Ragex Analysis Walkthrough
Step 1: Security Vulnerability Scan
MCP Tool: scan_security
Command (via MCP client):
{
"name": "scan_security",
"arguments": {
"path": "examples/product_cart/lib",
"severity": ["medium", "high", "critical"]
}
}Expected Results:
Security Scan Results
=====================
Total Issues: 8
Critical: 2 | High: 3 | Medium: 3
CRITICAL Issues:
1. File: lib/product_cart/cart.ex:142
Type: unsafe_deserialization
CWE: CWE-502
Description: Unsafe deserialization with :erlang.binary_to_term
Recommendation: Use safe deserialization with validation
2. File: lib/product_cart/cart.ex:19
Type: hardcoded_secret
CWE: CWE-798
Pattern: sk_live_1234567890abcdef
Description: Hardcoded API key in source code
Recommendation: Use environment variables or secret management
HIGH Issues:
3. File: lib/product_cart/cart.ex:236
Type: weak_crypto
CWE: CWE-327
Description: MD5 used for cryptographic purposes
Recommendation: Use SHA256 or stronger
4. File: lib/product_cart/cart.ex:145
Type: hardcoded_secret
Pattern: pk_live_abcdef123456
5. File: lib/product_cart/product.ex:15
Type: hardcoded_secret
Pattern: vendor_secret_key_12345
MEDIUM Issues:
6-8. Additional secret exposures in Product moduleKey Insights:
- 2 critical vulnerabilities requiring immediate attention
- All secrets should be moved to environment variables
- MD5 hashing is cryptographically broken
Step 2: Code Complexity Analysis
MCP Tool: find_complex_code
Command:
{
"name": "find_complex_code",
"arguments": {
"path": "examples/product_cart/lib",
"min_complexity": 10
}
}Expected Results:
Complex Functions
=================
Total: 5 functions exceed complexity threshold
1. ProductCart.Cart.checkout/8
Cyclomatic Complexity: 15
Cognitive Complexity: 28
Lines of Code: 68
Nesting Depth: 8
Issues: Multiple responsibilities, deep nesting, long parameter list
2. ProductCart.Cart.add_item/4
Cyclomatic Complexity: 12
Cognitive Complexity: 18
Lines of Code: 56
Nesting Depth: 6
Issues: Deep validation nesting, duplicated logic
3. ProductCart.Cart.update_item/4
Cyclomatic Complexity: 12
Cognitive Complexity: 18
Lines of Code: 56
Issues: Nearly identical to add_item/4 (code duplication)
4. ProductCart.Product.create_product/6
Cyclomatic Complexity: 11
Cognitive Complexity: 20
Lines of Code: 66
Issues: Tight coupling, deep nesting, duplicated validation
5. ProductCart.Product.update_product/7
Cyclomatic Complexity: 10
Cognitive Complexity: 19
Lines of Code: 62
Issues: Duplicates create_product logicHalstead Metrics (for checkout/8):
Volume: 892.3
Difficulty: 47.2
Effort: 42,116
Time to Understand: ~39 minutes
Estimated Bugs: 0.3Step 3: Code Smell Detection
MCP Tool: detect_smells
Command:
{
"name": "detect_smells",
"arguments": {
"path": "examples/product_cart/lib",
"severity": ["high", "critical"]
}
}Expected Results:
Code Smells Detected
====================
Total: 18 smells | Critical: 3 | High: 9 | Medium: 6
CRITICAL Smells:
1. Long Function: Cart.checkout/8 (68 statements)
Threshold: 50 statements
Suggestion: Extract validation, order creation, and notification logic
2. Deep Nesting: Cart.checkout/8 (8 levels)
Threshold: 4 levels
Suggestion: Use early returns, guard clauses, or with statements
3. Long Parameter List: Cart.checkout/8 (8 parameters)
Threshold: 5 parameters
Suggestion: Group parameters into structs
HIGH Smells:
4. Deep Nesting: Cart.add_item/4 (6 levels)
5. Long Function: Product.create_product/6 (66 statements)
6. Deep Nesting: Product.create_product/6 (6 levels)
7. Magic Numbers: Cart.add_item/4 (50, 100, 200, 0.1, 0.15, 0.2)
8. Complex Conditionals: Multiple or-chains in conditionals
9-12. Additional smells in update functions
MEDIUM Smells:
13-18. Magic numbers throughout both modulesStep 4: Code Duplication Detection
MCP Tool: find_duplicates
Command:
{
"name": "find_duplicates",
"arguments": {
"path": "examples/product_cart/lib",
"threshold": 0.85
}
}Expected Results:
Code Duplication Analysis
=========================
Total Duplicate Blocks: 6
EXACT DUPLICATES (Type I):
1. Discount Calculation Logic (100% match)
Locations:
- Cart.add_item/4 (lines 34-46)
- Cart.update_item/4 (lines 96-108)
- Product.create_product/6 (lines 23-35)
- Product.update_product/7 (lines 89-101)
Lines: 13 each
Suggestion: Extract to calculate_discount/1 function
NEAR-MISS DUPLICATES (Type III - 92% similarity):
2. Validation Logic
Locations:
- Cart.add_item/4 (lines 13-17)
- Cart.update_item/4 (lines 70-74)
- Product.create_product/6 (lines 11-13)
- Product.update_product/7 (lines 78-80)
Suggestion: Extract to validate_input/4
3. Complex Conditional Patterns (88% similarity)
Locations:
- Cart.checkout/8 (line 137)
- Product.create_product/6 (line 41)
- Product.update_product/7 (line 106)
Suggestion: Use Enum membership checks or pattern matching
SEMANTIC DUPLICATES (Type IV):
4. ID Generation Functions
- Cart.generate_id/0
- Product.generate_product_id/0
Both use MD5 hashing pattern
Suggestion: Create shared utility moduleSemantic Search for similar patterns:
{
"name": "find_similar_code",
"arguments": {
"code_snippet": "if subtotal > 50 do",
"threshold": 0.8
}
}Results show 4 locations with nearly identical discount logic.
Step 5: Dead Code Detection
MCP Tool: find_dead_code
Command:
{
"name": "find_dead_code",
"arguments": {
"path": "examples/product_cart/lib"
}
}Expected Results:
Dead Code Analysis
==================
Total Dead Functions: 4
Unused Private Functions:
1. ProductCart.Cart.old_calculate_discount/1
Lines: 199-206
Reason: No callers found in codebase
Confidence: High (100%)
2. ProductCart.Cart.legacy_validate_cart/1
Lines: 209-211
Reason: No callers found
Confidence: High (100%)
3. ProductCart.Product.old_price_calculator/1
Lines: 141-147
Reason: No callers found
Confidence: High (100%)
4. ProductCart.Product.legacy_category_validator/1
Lines: 151-153
Reason: No callers found
Confidence: High (100%)
Total Lines of Dead Code: 28
Estimated Savings: 7% of codebase
Recommendation: Safe to remove all 4 functions after verificationStep 6: Dependency & Coupling Analysis
MCP Tool: analyze_dependencies
Command:
{
"name": "analyze_dependencies",
"arguments": {
"module": "ProductCart.Product"
}
}Expected Results:
Dependency Analysis: ProductCart.Product
========================================
Efferent Coupling (Outgoing): 4 modules
- ProductCart.Cart
- ProductCart.Inventory
- ProductCart.Pricing
- ProductCart.Analytics
Afferent Coupling (Incoming): 1 module
- ProductCart.Cart
Instability: 0.8 (High)
Formula: Ce / (Ce + Ca) = 4 / (4 + 1)
Issues:
- High efferent coupling indicates tight dependencies
- Product module knows too much about other modules
- Changes in dependencies will ripple to Product
- Difficult to test in isolation
Recommendations:
1. Introduce dependency injection via behavior contracts
2. Use structs/protocols instead of direct module calls
3. Consider extracting shared logic to a service layer
4. Reduce coupling by using message passing patternsCircular Dependencies:
{
"name": "find_circular_dependencies",
"arguments": {}
}No circular dependencies detected (good!), but coupling is still high.
Coupling Report:
{
"name": "coupling_report",
"arguments": {
"threshold": 3
}
}Results:
High Coupling Detected
======================
ProductCart.Product: 4 outgoing dependencies (exceeds threshold of 3)
- Consider refactoring to reduce coupling
- Use interfaces/behaviors for abstractionStep 7: Impact Analysis
MCP Tool: analyze_impact
Command:
{
"name": "analyze_impact",
"arguments": {
"module": "ProductCart.Cart",
"function": "add_item",
"arity": 4
}
}Expected Results:
Impact Analysis: Cart.add_item/4
=================================
Direct Callers: 0 (no internal callers found)
Indirect Callers: 0
Files Affected: 1 (cart.ex)
Risk Assessment:
- Change Risk: LOW (no internal callers)
- Test Coverage: Unknown (no tests in demo)
- Complexity Risk: HIGH (cyclomatic complexity: 12)
- Coupling Risk: MEDIUM (calls 2 external functions)
Overall Risk Score: MEDIUM (6.5/10)
Recommendations:
1. Add tests before refactoring
2. Extract nested logic to reduce complexity
3. Consider using `with` for validation chain
4. Move discount calculation to separate module
Estimated Refactoring Effort: 2-3 hours
- Extract functions: 30 min
- Write tests: 1 hour
- Refactor conditionals: 1 hour
- Code review: 30 minStep 8: Automated Refactoring Suggestions
MCP Tool: suggest_refactorings
Command:
{
"name": "suggest_refactorings",
"arguments": {
"path": "examples/product_cart/lib",
"priority": "high"
}
}Expected Results:
Automated Refactoring Suggestions
==================================
Found 8 refactoring opportunities (showing top 5 by priority)
1. EXTRACT_FUNCTION: Discount Calculation Logic
Priority: CRITICAL (score: 9.2/10)
Benefit: Eliminates 4 exact duplicates
Impact: 4 files affected
Risk: Low (pure calculation)
Effort: 1 hour
Confidence: 95%
Target: Cart.ex lines 34-46 (and 3 other locations)
Suggested Name: calculate_discount/1
Parameters: [subtotal]
Return Type: number
Step-by-Step Plan:
a. Create new function calculate_discount/1 in shared module
b. Replace 4 duplicate blocks with function call
c. Add tests for edge cases
d. Verify all call sites work correctly
RAG Context: Discount logic follows standard tiered pricing pattern.
Consider making thresholds configurable.
2. INLINE_FUNCTION: Dead Code Removal
Priority: HIGH (score: 8.5/10)
Benefit: Removes unused code, improves maintainability
Impact: 2 files, 4 functions
Risk: None (no callers)
Effort: 15 minutes
Targets:
- Cart.old_calculate_discount/1
- Cart.legacy_validate_cart/1
- Product.old_price_calculator/1
- Product.legacy_category_validator/1
Plan: Safe to delete immediately
3. EXTRACT_FUNCTION: Validation Logic
Priority: HIGH (score: 8.1/10)
Benefit: Reduces nesting, improves readability
Impact: 4 functions affected
Risk: Low
Effort: 2 hours
Target: Nested if statements in add_item, update_item, etc.
Suggested: validate_cart_params/4, validate_product_params/6
Pattern: Use `with` statement or early returns
RAG Context: Elixir best practice is to use `with` for validation chains
4. REDUCE_COUPLING: Product Module Dependencies
Priority: HIGH (score: 7.8/10)
Benefit: Reduces instability from 0.8 to ~0.5
Impact: Product module and 4 dependencies
Risk: Medium (requires interface changes)
Effort: 4 hours
Plan:
a. Define behavior contracts (protocols)
b. Inject dependencies instead of direct calls
c. Update tests to use mocks
d. Refactor call sites
RAG Context: Consider using GenServer or Agent for state management
5. SIMPLIFY_COMPLEXITY: Cart.checkout/8
Priority: HIGH (score: 7.5/10)
Benefit: Reduces cognitive load from 28 to ~12
Impact: 1 function (68 lines)
Risk: Medium (complex logic)
Effort: 3 hours
Suggested Actions:
a. Extract validate_checkout_params/8
b. Extract create_and_process_order/3
c. Extract send_notifications/2
d. Use `with` for validation chain
e. Add struct for checkout parameters
RAG Context: Phoenix best practice is to use changesets for validationExplain Specific Suggestion:
{
"name": "explain_suggestion",
"arguments": {
"suggestion_id": "extract_function_discount_calc"
}
}Returns detailed explanation with code examples and benefits analysis.
AI-Enhanced Features
Feature 1: AI-Enhanced Validation (Phase B)
When Ragex detects syntax errors or validation issues, it provides AI-powered explanations:
Example validation error in refactoring:
Validation Error: Syntax error at line 45
AI Explanation:
--------------
The error occurs because the 'end' keyword is missing after the 'if' statement.
In Elixir, all control structures (if, case, cond) must be closed with 'end'.
Context: Your nested if statements have 6 levels of nesting. This makes it
easy to miss closing keywords.
Suggestion: Consider refactoring to use 'with' statement:
with {:ok, _} <- validate_cart(cart),
{:ok, _} <- validate_quantity(quantity),
{:ok, _} <- validate_price(price) do
# success path
else
{:error, reason} -> {:error, reason}
end
This reduces nesting and makes validation logic clearer.Feature 2: AI Refactoring Preview (Phase B)
MCP Tool: preview_refactor (with AI commentary)
Command:
{
"name": "preview_refactor",
"arguments": {
"operation": "extract_function",
"params": {
"module": "ProductCart.Cart",
"source_function": "add_item",
"source_arity": 4,
"new_function": "calculate_discount",
"line_start": 34,
"line_end": 46
}
}
}AI-Enhanced Response:
Refactoring Preview: Extract Function
======================================
AI Analysis:
-----------
This refactoring will extract the discount calculation logic into a
separate function, eliminating 4 exact duplicates across the codebase.
Risk Assessment:
- Overall Risk: LOW (3/10)
- Pure calculation with no side effects
- No external dependencies
- Easy to test in isolation
Benefits:
- Reduces code duplication by 52 lines
- Improves maintainability
- Makes discount logic configurable in one place
- Follows Single Responsibility Principle
Recommendations:
1. Consider making discount thresholds configurable (50, 100, 200)
2. Add type specs for better documentation
3. Consider using a struct for discount tiers
4. Write property-based tests for edge cases
Potential Issues:
- None identified
Confidence: 95%
Would you like to proceed? (yes/no)Feature 3: AI Dead Code Refiner (Phase C)
Reduces false positives in dead code detection using AI reasoning:
Command:
{
"name": "find_dead_code",
"arguments": {
"path": "examples/product_cart/lib",
"ai_refine": true
}
}AI-Enhanced Results:
Dead Code Analysis (AI-Refined)
================================
Confirmed Dead Code (High Confidence):
1. Cart.old_calculate_discount/1
AI Reasoning: Function name suggests legacy code. No callers found.
Similar logic exists in duplicated inline code.
Safe to remove.
2. Cart.legacy_validate_cart/1
AI Reasoning: Prefix "legacy_" indicates deprecated code. No usage.
Modern validation exists in calling functions.
Safe to remove.
3. Product.old_price_calculator/1
AI Reasoning: Duplicate of old_calculate_discount pattern.
No callers. Safe to remove.
4. Product.legacy_category_validator/1
AI Reasoning: Simple list membership check. Replaced by inline logic
in create_product and update_product.
Safe to remove.
False Positives Avoided:
- send_confirmation_email/2, send_sms_notification/2: Appear unused but
are actually called in checkout/8. AI detected these as false positives.Feature 4: AI Semantic Clone Detection (Phase C)
Detects Type IV (semantic) clones using AI analysis:
Command:
{
"name": "find_duplicates",
"arguments": {
"path": "examples/product_cart/lib",
"ai_analyze": true
}
}AI-Enhanced Results:
Semantic Clone Detection (AI-Powered)
======================================
Type IV Clone Detected:
Functions with different implementations but similar purpose:
1. Cart.generate_id/0 and Product.generate_product_id/0
Similarity: Semantic (95%)
AI Analysis:
Both functions generate unique identifiers using:
- MD5 hashing (weak crypto)
- Erlang unique integer
- Base16 encoding
Despite different variable names and string prefixes, they serve
the same purpose and use the same flawed algorithm.
Recommendation:
- Consolidate into shared generate_id/1 utility
- Replace MD5 with secure random generation (e.g., UUID)
- Consider Ecto.UUID.generate() for production use
2. Validation patterns across modules
Similar intent: Parameter validation with nested if statements
AI Analysis:
Multiple functions implement similar validation logic:
- Range checks (quantity > 0, price > 0)
- Length constraints
- Nil checks
Pattern detected across 6 functions. Suggest extracting to
shared validation module or using Ecto changesets.Feature 5: AI Architectural Insights (Phase C)
MCP Tool: analyze_dependencies (with AI insights)
Command:
{
"name": "analyze_dependencies",
"arguments": {
"module": "ProductCart.Product",
"ai_insights": true
}
}AI-Enhanced Response:
Dependency Analysis with AI Insights
=====================================
Module: ProductCart.Product
Instability: 0.8 (High)
AI Architectural Analysis:
--------------------------
The Product module exhibits characteristics of a "God Object" anti-pattern:
- Directly depends on 4 different modules
- Performs multiple responsibilities (pricing, inventory, analytics)
- High instability indicates fragility to upstream changes
Observed Patterns:
1. Service Locator Anti-Pattern
- Directly calling multiple service modules
- Tight coupling reduces testability
- Violates Dependency Inversion Principle
2. Missing Abstraction Layer
- No interfaces/behaviors between Product and services
- Makes mocking difficult in tests
- Changes in service APIs break Product module
AI Recommendations:
-------------------
Refactoring Strategy (Effort: 6-8 hours):
1. Introduce Behavior Contracts (2 hours)
Define protocols:
@behaviour PricingService
@behaviour InventoryService
@behaviour AnalyticsService
2. Dependency Injection (2 hours)
Pass services as function parameters or use Application config:
def create_product(params, pricing: Pricing, inventory: Inventory)
3. Extract Product Service Layer (3 hours)
Create ProductService module that orchestrates calls:
ProductService.create_product(params, services)
4. Testing improvements (1 hour)
Use Mox or Hammox for behavior-based mocking
Expected Benefits:
- Instability reduced from 0.8 to ~0.3
- Test coverage improves (mockable dependencies)
- Easier to swap implementations
- Follows SOLID principles
Example Code:
-------------
# Before (tight coupling)
pricing_data = Pricing.calculate_price(...)
inventory = Inventory.check_availability(...)
# After (dependency injection)
pricing_data = pricing_service.calculate_price(...)
inventory = inventory_service.check_availability(...)Refactoring Recommendations
Based on Ragex analysis, here's a prioritized refactoring plan:
Phase 1: Security (CRITICAL - 1 day)
Remove hardcoded secrets - 2 hours
- Move all API keys to environment variables
- Use config/runtime.exs for configuration
- Add secrets management documentation
Fix unsafe deserialization - 2 hours
- Replace :erlang.binary_to_term with safe alternative
- Add input validation before deserialization
- Use structured data (JSON/structs) instead
Replace weak cryptography - 1 hour
- Replace MD5 with SHA256 or UUID
- Use :crypto.strong_rand_bytes for random generation
- Add tests for ID uniqueness
Phase 2: Code Duplication (HIGH - 1 day)
Extract discount calculation - 2 hours
- Create shared DiscountCalculator module
- Make thresholds configurable
- Add comprehensive tests
Extract validation logic - 3 hours
- Create validation module or use Ecto changesets
- Replace nested ifs with
withstatements - Add validation tests
Consolidate ID generation - 1 hour
- Create shared IDGenerator utility
- Use secure random generation
Phase 3: Complexity Reduction (HIGH - 2 days)
Refactor Cart.checkout/8 - 4 hours
- Extract validation functions
- Extract order processing logic
- Extract notification logic
- Reduce parameter count with struct
Refactor Cart.add_item/4 and update_item/4 - 3 hours
- Extract shared logic
- Use early returns or
with - Reduce nesting from 6 to 2 levels
Refactor Product functions - 3 hours
- Similar treatment as Cart
- Extract shared validation
- Reduce duplication
Phase 4: Architecture (MEDIUM - 2 days)
Reduce coupling in Product module - 6 hours
- Define behavior contracts
- Implement dependency injection
- Create ProductService orchestrator
- Update tests with mocks
Extract shared utilities - 2 hours
- Create Validation module
- Create DiscountCalculator module
- Create IDGenerator module
Phase 5: Clean Up (LOW - 1 hour)
Remove dead code - 30 minutes
- Delete 4 unused functions
- Clean up comments
Add documentation - 30 minutes
- Add @doc for public functions
- Add @spec type specifications
- Update module documentation
Expected Outcomes
Metrics Before:
- Total Lines: ~500
- Average Complexity: 12
- Code Duplication: 52 lines (10%)
- Security Issues: 8
- Dead Code: 28 lines
- Test Coverage: 0%
Metrics After:
- Total Lines: ~380 (24% reduction)
- Average Complexity: 5 (58% improvement)
- Code Duplication: 0 lines (100% elimination)
- Security Issues: 0 (100% fixed)
- Dead Code: 0 lines
- Test Coverage: 85%+
Maintainability Improvements:
- Cognitive load reduced by 65%
- Time to understand code: 39 min → 12 min
- Coupling reduced from 0.8 to 0.3
- All code smells eliminated
Conclusions
Ragex Capabilities Demonstrated
Security Analysis (Phase 1)
- Detected 8 vulnerabilities with CWE mapping
- Identified hardcoded secrets, weak crypto, unsafe deserialization
- Provided actionable remediation advice
Complexity Metrics (Phase 2)
- Computed cyclomatic, cognitive, and Halstead metrics
- Identified functions exceeding complexity thresholds
- Estimated maintenance effort and bug probability
Code Smell Detection (Phase 3)
- Found 18 smells across 5 types
- Provided severity ratings and thresholds
- Suggested specific refactoring actions
Code Duplication (Phase 11)
- Detected exact, near-miss, and semantic clones
- Found 4 instances of identical 13-line blocks
- Suggested extraction and consolidation
Dead Code Detection (Phase 11)
- Identified 4 unused functions with high confidence
- Calculated 7% potential code reduction
- AI refinement eliminated false positives
Dependency Analysis (Phase 11)
- Computed coupling metrics (instability: 0.8)
- No circular dependencies (good)
- Identified architectural issues
Impact Analysis (Phase 11)
- Risk scoring for proposed changes
- Effort estimation for refactoring
- Test discovery and coverage gaps
Automated Suggestions (Phase 11G)
- Generated 8 prioritized refactoring opportunities
- Provided step-by-step action plans
- RAG-powered contextual advice
AI Enhancements (Phases A-C)
- Validation error explanations
- Refactoring preview with risk assessment
- False positive reduction
- Semantic clone detection
- Architectural insights
Why Ragex is Powerful
Comprehensive Analysis:
- Combines static analysis, graph algorithms, ML embeddings, and AI
- Detects issues across security, quality, architecture, and maintainability
- Provides both breadth (many issue types) and depth (detailed insights)
Actionable Intelligence:
- Not just problem detection - suggests specific solutions
- Priority ranking helps focus effort
- Effort estimates aid planning
- Step-by-step refactoring guides
AI-Enhanced Understanding:
- Explains complex issues in plain language
- Provides context-aware recommendations
- Learns from codebase patterns via RAG
- Reduces false positives with semantic reasoning
Developer-Friendly:
- MCP protocol integration for IDEs and tools
- Streaming notifications for long operations
- Configurable thresholds and filters
- Beautiful reports in multiple formats
Production Readiness
This demo shows Ragex is production-ready for:
- Pre-commit hooks (security, complexity checks)
- CI/CD pipelines (quality gates)
- Code review automation (suggestions, impact analysis)
- Technical debt tracking (dead code, duplication, smells)
- Refactoring planning (impact analysis, effort estimation)
- Developer education (AI explanations, best practices)
Next Steps: Try Ragex on your own codebase and discover what issues are hiding in plain sight!
Running the Demo
Prerequisites
# Ensure Ragex is compiled
mix deps.get
mix compile
# Start the MCP server (optional, for interactive demo)
mix ragex.server
Quick Demo Script
# From ragex root directory
cd examples/product_cart
# Run all analyses (see run_demo.sh)
./run_demo.sh
# Or run individual analyses
mix ragex.analyze --path lib
mix ragex.security --path lib
mix ragex.quality --path lib
mix ragex.suggestions --path lib
Interactive Demo (via MCP)
Use any MCP client (Claude Desktop, Cursor, etc.) to interactively explore the codebase using Ragex's 45 MCP tools.
Example workflow:
scan_security- Find vulnerabilitiesfind_duplicates- Detect code clonessuggest_refactorings- Get improvement planpreview_refactor- See AI-enhanced previewanalyze_impact- Assess change risk- Execute refactoring with confidence!
Demo Version: 1.0
Ragex Version: 0.2.0
Last Updated: January 24, 2026
Author: Ragex Team