# Claude writes better Spring Boot configs than your senior dev

> Source: <https://promptcube3.com/en/threads/6950/>
> Published: 2026-08-19 16:47:08+00:00

# 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.
