Claude writes better Spring Boot configs than your senior dev

Claude 3.5 Sonnet outperformed GPT-4o, Gemini 1.5 Pro, and DeepSeek-V3 in Spring Boot configuration and code generation tests on a legacy Java codebase, correctly identifying transaction boundaries and JPA annotations in 3/3 tests, while GPT-4o conflated annotations twice and Gemini suggested @EnableAutoConfiguration for everything. The author advises using Sonnet for module design and Angular scaffolding but writing Flyway migrations and Redis cache keys manually, noting that LLMs cannot replace architectural judgment.

Claude writes better Spring Boot configs than your senior dev Claude /en/tags/claude/ as co-pilot isn't asking the right question. They're asking "can I?" when the real question is "which model actually understands Spring Boot transaction boundaries without hallucinating a @Transactional on a private method?"I've benched all four majors against a nasty legacy Java codebase — 2,000 lines of spaghetti services, circular dependencies, and a UserService that somehow manages payment processing. Here's what actually happened. Architecture decisions: Claude 3.5 Sonnet GPT-4o Gemini 1.5 Pro DeepSeek-V3 Context retention on multi-file refactors: Sonnet held 15-file context for 45 minutes. GPT-4o started forgetting package structures after file 8. Gemini hallucinated a Repository interface that didn't exist. DeepSeek /en/tags/deepseek/ gave up and suggested rewriting in Go. Spring Boot specifics: Sonnet correctly identified @EnableJpaRepositories vs @EntityScan confusion in 3/3 tests. GPT-4o conflated them twice. Gemini suggested @EnableAutoConfiguration as a fix for everything. DeepSeek didn't know @Transactional propagation types. PostgreSQL schema design: Sonnet produced a normalized schema with proper indexes and foreign keys on first try. GPT-4o forgot ON DELETE CASCADE on a join table. Gemini suggested JSONB for everything including primary keys. DeepSeek generated MySQL syntax. Code generation: it's not even close Prompt: "Add optimistic locking to this JPA entity with version field" Sonnet: Added @Version , explained OptimisticLockException handling in service layer, warned about detached entity merges. GPT-4o: Added @Version , missed the service-layer retry logic. Gemini: Added @Version on a String field. Compiled. Failed at runtime. DeepSeek: Added @Version , then rewrote the entire entity in Kotlin unprompted. Where you still need a human or at least a very careful prompt engineer Redis cache invalidation strategies: Every model suggests @CacheEvict allEntries = true like it's free. It's not. Sonnet at least warns you when you ask for it on a 500k-entry cache. Database migration ordering: Flyway/Liquibase scripts generated by LLMs assume clean slate. They don't handle "this column existed in prod for 3 years with nullable=true now you're making it not-null." Angular change detection zones: All four models default to ChangeDetectionStrategy.Default and wonder why your 500-row table lags. Sonnet is the only one that proactively suggests OnPush + trackBy without being asked. My actual advice for this stack 1. Let Sonnet design the Spring module boundaries — feed it your domain description, ask for a package diagram with bounded contexts. It'll give you something defensible. 2. Write your own Flyway migrations — LLMs don't know your production data. 3. Use Sonnet for Angular component scaffolding + OnPush patterns — it genuinely understands the zone.js trap. 4. Redis? Write the cache keys yourself. Naming conventions user:123:profile:v2 are tribal knowledge no model has. 5. Hire a senior for 2 hours — not for code, for a 30-minute architecture review and a 90-minute "here's where you'll regret this in 6 months" session. Worth every penny. The app is buildable. The stack is fine. But don't pretend Claude replaces architectural judgment — it just makes the iteration loop tighter when you have judgment. Next Kimi K3 Attention Residuals → /en/threads/6947/ All Replies （7） Claude's great for "hey, what's this pattern called?" or "why's this failing?" — but you still gotta drive. The magic happens when you stop treating it like a senior dev and start treating it like a rubber duck that actually talks back. Just ship something ugly first. Polish later. @RayTinkerer /en/users/RayTinkerer/ the cut-off killed me — what was the rest? "what's the java equivalent of..." with Claude. Ask for reasoning, justifications, first principles — make it explain the "why" behind every concept, even stuff unrelated to your app. Treat it like a sparring partner, not a code vending machine. why it works. If you skip that part, you're just building a house of cards.