Skip to main content
In this section we demonstrate how to audit software quality at scale using Claude Code. We’ll run an architecture and design analysis against the Express Login Demo, then review the generated findings and precise remediation guidance. This walkthrough is useful for engineers and architects who want to automate codebase-level audits that check architecture, separation of concerns, error handling, security posture, and maintainability.
The repository used for prompts and follow-along artifacts includes the review prompts and generated audit files. This avoids retyping long prompts during the walkthrough and helps reproduce the analysis locally.

Starting Claude Code (CLI)

Here is the initial CLI session used to start Claude Code in the project workspace:
Rather than retyping long prompts during follow-along, the review prompts used for software and security reviews are included with the course materials.
A dark‑mode browser window showing a GitHub repository page titled "Claude‑Code‑Reviewing‑Prompts" with a list of markdown files (LICENSE, README and various security-related docs). The repo view is open over a code editor window in the background.

Review Prompt (excerpt)

The analysis was driven by a concrete prompt asking Claude to evaluate architecture, produce file-level findings, and recommend precise remediation:

Claude Code Exploration (excerpt)

Claude explored the repository, read files, searched for patterns and then wrote a detailed report into audits/SOFTWARE_DESIGN_ARCHITECTURE_ANALYSIS.md. The CLI output showed the main actions:
After confirming the write, Claude saved the analysis file. Below are the consolidated excerpts and actionable findings from that report.

Software Design & Architecture Analysis — Key Excerpts

Project: Express Login Demo
Analysis Date: 2025-08-24
Scope: Architecture patterns, design quality, and code organization assessment

Executive summary

  • Overall Architecture Score: 4/10
    The codebase approximates a minimal MVC pattern but contains significant design limitations. Business logic is embedded in route handlers, there is no service or repository abstraction, and error handling is not centralized.
  • Modularity: 3/10 — Flat structure with minimal organization.
  • Maintainability / Testability: Low — Tight coupling and monolithic route handlers hinder unit testing and safe refactoring.
Immediate high-level recommendations:
  • Extract service layer from route handlers (e.g., authentication logic currently in routes/auth.js)
  • Implement centralized error-handling middleware
  • Introduce a data access layer (repositories) and move raw DB queries into it
  • Add input validation and sanitization consistently
  • Add structured logging, monitoring, and rate-limiting

Project structure (observed)

Use this quick reference to understand the current layout detected by the analysis: Textual output observed:

Architecture assessment

  • Pattern Identified: Minimal MVC-inspired structure
    • Model Layer: Basic PostgreSQL integration via config/database.js
    • Controller Layer: Route handlers in routes/auth.js
    • View Layer: JSON API responses (no frontend)
  • Separation of concerns: 3/10
    • Business logic mixed with route handling
    • Data access performed directly in controllers
    • No dedicated services or repositories
    • Database config is separated (positive)
Data flow summary:
  • Controllers → direct DB queries → return responses
  • No caching or rate-limiting present
  • Potential bottlenecks: single DB pool, synchronous password hashing, and lack of connection limits/retries
Architecture diagram (textual / ASCII):
Dependency flow (conceptual):

Anti-patterns and code smells detected

  • God module: routes/auth.js has too many responsibilities (severity 8/10).
  • Primitive obsession: raw SQL strings and unparameterized queries (risk of SQL injection).
  • Duplication: repeated validation and error responses — candidate for centralized middleware.
  • Tight coupling: direct imports of DB pool and crypto logic into route files.

Concrete Remediation — Code Examples

The report prioritized concrete, minimal-drop-in fixes. Below are the suggested code reorganizations and snippets Claude produced. These are ready to drop into the repository with the listed file paths.
Before applying code changes in production, run the test suite (if any), and perform integration tests against a staging environment. Backup the database and confirm config values for hashing/keys.

1) Simplify routes and delegate to controllers/services

routes/auth.js — thin route definition using express-validator, delegating to a controller:
Controller delegates to a service:
Service that encapsulates business logic:
Repository using parameterized queries:

2) Centralized error handler (drop-in)

Create middleware/errorHandler.js:
Attach it in server.js after route setup:

3) Use asynchronous password hashing (avoid blocking the event loop)

Ensure account creation uses the async hash function instead of synchronous APIs.

4) Input validation and sanitizer middleware

Create middleware/sanitizer.js to unify validation error handling:
Use this middleware after route validators.

5) Rate limiting for authentication endpoints

Example using express-rate-limit:

Remediation Summary Table

Performance & Operational Risks

  • Single DB connection pool without limits — configure pool max connections and backoff/retries.
  • Synchronous password hashing — blocks event loop; switch to async.
  • No caching layer — consider caching session metadata or tokens.
  • No monitoring/metrics — add tracing and metrics to identify hotspots.
  • Current State: Functional but brittle; significant architectural debt.
  • Technical Debt: High — refactoring required to scale safely.
  • Maintainability: Low — monolithic handlers and tight coupling impede change.
  • Testability: Very Low — lack of separation makes unit tests hard to write.
Immediate actions:
  1. Extract business logic into service layer.
  2. Implement centralized error handling.
  3. Create repository/data access layer and remove raw SQL from controllers.
  4. Add validation, sanitization, and rate limiting.
  5. Implement structured logging and monitoring.
Long-term goals:
  • Adopt a layered architecture with dependency inversion / DI.
  • Expand unit and integration test coverage.
  • Add configuration management, observability, and CI checks for architecture quality.

This initial software design analysis was saved to audits/SOFTWARE_DESIGN_ARCHITECTURE_ANALYSIS.md. In later sections we’ll perform deeper design and security audits and use Claude Code to help refactor and iteratively improve the architecture score. References and further reading:

Watch Video