Ahmed Hassan·
Honest tech-debt audit with an impact-vs-effort matrix - the quick wins paid off week one
Analyzes codebase-wide technical debt, categorizes issues, and produces a prioritized remediation roadmap with effort estimates.
Technical Debt Scanner & Remediation Plan
You are a principal engineer conducting a technical debt assessment across a codebase. Provide a comprehensive analysis and remediation plan.
## Codebase Samples
```
{{codebase_samples}}
```
## Context
- Language: {{programming_language}}
- Framework: {{framework}}
- Codebase age: {{codebase_age}}
- Team size: {{team_size}}
- Business criticality: {{criticality}}
- Key pain points: {{known_pain_points}}
## Assessment Framework
Analyze across these dimensions:
1. **Code Quality** - Duplication, complexity, coupling, test coverage
2. **Architecture** - Layer violations, dependency direction, monolith vs service boundaries
3. **Dependencies** - Outdated packages, deprecated APIs, security vulnerabilities, license risks
4. **Performance** - Known hotspots, inefficient patterns, missing caching
5. **Reliability** - Error handling, observability, circuit breakers, graceful degradation
6. **Security** - Auth patterns, input validation, secrets management, audit trails
7. **DevEx** - Build times, test speed, local setup, documentation, onboarding
8. **Scalability** - State management, session handling, database patterns, horizontal scaling readiness
## Output Format
For each issue found:
- Severity (Critical/High/Medium/Low)
- Category (from above)
- File/location references
- Impact description (quantified if possible)
- Remediation approach with code example
- Effort estimate (hours/story points)
- Risk of remediation (safe/risky/needs careful rollout)
## Deliverables
1. **Debt Inventory** - Complete list of all issues found
2. **Priority Matrix** - Impact vs effort visualization (ASCII)
3. **Remediation Roadmap** - Phased plan over {{timeframe}}
4. **Quick Wins** - Low-effort, high-impact items to start immediately
5. **Strategic Investments** - Larger architectural improvements
6. **Metrics Dashboard** - KPIs to track debt reduction
7. **Prevention Measures** - Code review checklist, CI gates, architecture decision records to prevent recurrence
Be honest and thorough. Prioritize based on business impact, not just code elegance.
Ergebnisse
Technical-debt assessment of the `checkout` module (TypeScript + Express, ~4 yrs old, team of 6, business-critical). Stated pain: slow deploys, flaky payments.
## Priority matrix (impact × effort)
```
high │ [Payment retries] [Split monolith]
impact│ [Add p95 alerting]
│ [Migrate ORM]
low │ [Rename vars] [Rewrite legacy cron]
└──────────────────────────────────────────
low effort high effort
```
## Top findings
| Sev | Category | Issue | Effort | Risk |
|-----|----------|-------|--------|------|
| Critical | Reliability | `chargeCard()` has no retry/timeout — single gateway blip fails checkout | 8h | safe |
| High | Security | Raw `req.body` spread into SQL in `order.repo.ts:88` | 4h | safe |
| High | Performance | N+1 loading line items per order in the cart view | 6h | safe |
| Medium | DevEx | 9-min CI from un-cached Docker layers | 3h | safe |
## Quick wins (start now)
- Add `p95 > 500ms` alerting — 2h, instant visibility.
- Cache CI Docker layers — cuts deploys from 9 min to ~3 min.
## Strategic
Extract payments into its own service behind a stable interface (phase over the next quarter). **Prevention:** add a CI gate failing on new `any`, and a code-review checklist item for input validation at boundaries.
Modell: Claude Sonnet 4
43 Likes8 SavesScore: 35
3 Kommentare
Marco Rossi·
The observability hooks are a thoughtful touch.
Luca Brunner·
Sending this code generation one to my whole team.
Tobias Keller·
Clean separation of concerns here, easy to drop into an existing service.