Comparison Summary

Amp wins overall.
Claude leads structure.

Based on the code in these folders, Amp is the stronger overall implementation, while Claude remains the cleaner engineering baseline.

Current Overall Score
72.8 / 100

Balanced toward current app strength, security, product completeness, and operational practicality.

Maintainability Lens
74.4 / 100

Weighted toward architecture, code quality, testability, observability, and change safety.

Overall Winner Amp is the stronger overall app because it combines the richer workflow set with a stronger security and deployment posture.
Best Engineering Shape Claude has the better modularity, readability, and lower-coupling baseline.
Key Factors The main differentiators are same-origin frontend calls, guarded TLS bypass, env-based CORS, and delete ownership enforcement.
CVE Status `pip-audit` found no known vulnerabilities in either Python requirement set, so the biggest risks are code and config choices rather than disclosed package CVEs.
Why Amp Leads

Why Amp Ranks First

Amp ranks first because the current code combines the richest feature set with a meaningfully stronger current security and deployment posture than Claude.

TLS bypass is opt-in
`ALLOW_INSECURE_MODEL_DOWNLOADS=1` is required before the bypass is enabled.
CORS is env-configured
Allowed origins come from `ALLOWED_ORIGINS`, and allowed methods/headers are narrowed.
Delete authorization is enforced
Published-entry deletion checks the authenticated username or stored `user_id` before allowing removal.
Frontend backend routing is same-origin
Amp's JS uses relative paths consistently instead of hardcoded remote backend URLs.

Key Constraints

Amp is highly coupled
Large shared files dominate the implementation: `static/common.js`, `static/common.css`, and `server/server.py` carry a lot of cross-cutting behavior.
Claude ships a hardcoded key
`run.bat` contains an OpenAI API key and leaves `APP_PASSWORD` blank in that launcher path.
Neither repo has tests
That keeps change-safety low for both implementations, even though Claude’s smaller structure makes it safer to refactor.
Claude is easier to reason about
Cleaner abstractions and smaller modules make it the better engineering skeleton.
Scoring Model

Balanced Lens

Weights favor current app strength, security, product completeness, and real-world usefulness.

Maintainability Lens

Weights favor architecture, readability, observability, testability, and refactor safety.

Interpretation

Amp wins the balanced lens because it combines the strongest product scope with a stronger security posture.
Claude wins the maintainability lens because its server and shared frontend are much smaller and cleaner.
This is not a contradiction. It is the actual tradeoff between current product strength and long-term codebase shape.
Visual Scoreboards

Radar: Current Balanced Assessment

Amp spikes on scope, UX, deployability, and security. Claude dominates maintainability-oriented criteria.

Amp
Claude

Two-Lens Totals

Balanced lens answers "which app is stronger overall?" Maintainability lens answers "which codebase is healthier to evolve?"

Amp: 72.8 balanced, 63.6 maintainability-heavy.
Claude: 68.8 balanced, 74.4 maintainability-heavy.
Complexity And Scope

Objective Metrics

Measure Amp Claude
Files in scope2016
Approximate LOC8,1242,581
FastAPI routes2216
Top 3 files share60.7%52.1%
JS fetch calls172
Python `print()` calls230
Structured logging calls012
Tests found00

What These Numbers Mean

Amp buys a lot with its extra size
The complexity is not pointless. It translates into publish/replay, richer reading workflows, denser metrics, live graphs, exports, and stronger UI scope.
But Amp is concentrated
Over 60% of the original code sits in three files, which increases regression risk and slows safe modification.
Claude is lean
The whole system is much smaller, which explains its better readability and maintainability scores.
Claude’s leanness also means thinner scope
It simply does less, so not all of the lower complexity is “better engineering”; some of it is lower ambition.

UX And Product Surface

Amp is visibly more polished
Richer menu, sidebar navigation, editable passages, log/export controls, replay, and more informative metric cards all show stronger product thinking.
Claude is cleaner but plainer
The UI is intentionally simpler and faster to understand, but less impressive as a complete assessment product.
Security And CVEs

Security Comparison

Amp current strengths
Fail-closed auth when `APP_PASSWORD` is unset, env-configured CORS instead of wildcard default, guarded insecure TLS mode, and owner checks on delete materially improve the security story.
Amp current caveats
Identity is lightweight and based on Basic Auth username plus a shared app password, so it is not strong multi-user authorization. It also pulls JSZip from a CDN in several pages.
Claude critical risk
`run.bat` contains a hardcoded OpenAI API key and blank `APP_PASSWORD`, which is the larger operational risk in this comparison.
Claude default posture is weaker
Wildcard CORS remains in the server, auth allows all requests if `APP_PASSWORD` is unset, and `server/start.sh` defaults to `demo`.

CVE And Dependency Readout

`pip-audit -r server/requirements.txt` reported no known vulnerabilities for Amp.
`pip-audit -r claude-version/server/requirements.txt` reported no known vulnerabilities for Claude.
That is a useful signal, but not a complete safety story: both manifests use wide `>=` ranges and there is no lockfile.
In this comparison, code-level security choices and secrets handling matter more than package CVEs.
Architecture And Maintainability

Why Claude Wins Here

Smaller shared frontend
Claude’s `static/common.js` is a compact helper layer. Amp’s `static/common.js` is a very large multi-responsibility runtime.
Smaller server surface
Claude’s server is easier to scan and reason about end-to-end. Amp’s server mixes auth, storage, analysis, publishing, routing, and startup policy in one file.
Better observability style
Claude uses structured logging. Amp relies mainly on `print(...)` and traceback output.

Why Amp Lags Here

Large files dominate behavior
`static/common.js`, `static/common.css`, and `server/server.py` dominate the codebase and increase the blast radius of changes.
Cross-cutting state is heavier
Amp has more browser-side state, richer replay/log flows, and more implicit connections between UI and server behavior.
No tests to protect the complexity
The larger and richer implementation would benefit most from regression tests, but none are present.

Best Practical Reading

Amp is the better app overall.
Claude is the better code shape for a team to inherit.
If a team had to maintain this for a year, Claude would be the more comfortable starting point.
If a team had to impress users or stakeholders tomorrow, Amp would be the stronger demo.
Recommendation

Decision Guidance

If You Care Most About... Pick Reason
Best current demo / pilot Amp More complete workflows, richer metrics, better UI scope, and a stronger security posture.
Cleanest codebase to extend Claude Smaller files, better modularity, better logging, and lower refactor friction.
Current security posture Amp Claude has a committed API key and weaker runtime defaults.
Long-term team-owned product Hybrid Use Amp as the feature reference, then refactor toward Claude’s structure.

Best Strategic Path

1. Treat Amp as the feature benchmark
It is the stronger current implementation and the best source of product requirements and workflow ideas.
2. Fix Claude’s critical secret issue immediately if it remains in use
Remove the hardcoded OpenAI key, require auth, and tighten CORS.
3. Reduce Amp’s structural debt next
Split `server/server.py` and `static/common.js`, replace `print(...)` logging, and add a small regression suite around the publish and analysis flows.
4. Ideal end state
Claude’s code organization plus Amp’s feature set would be the best combined result.
Presentation artifact generated from the current local code.
1 / 8
← Swipe to navigate →