Backend Engineering with Claude: Beyond Vibe Coding

Students learn to use Claude as a design partner before writing any code — exploring resource structure, status codes, and error envelopes through conversation. This establishes the "design first" habit and produces a written contract that drives every subsequent prompt in the section.

Students learn to write constraint-first prompts that produce production-quality Spring controllers — with Bean Validation on nested types, RFC 7807 ProblemDetail error responses, and constructor injection — without needing to correct Claude's defaults after the fact. The key insight is that specificity in the prompt eliminates rework.

Students learn the "adversarial self-review" prompt pattern: after Claude generates output, ask it to find the gaps in what it just produced. Applied here to OpenAPI documentation — Claude adds @Operation annotations, then reviews the resulting spec for undocumented error codes and missing response schemas. This pattern recurs throughout the course (security section, testing section).

Students learn to use Claude as a design tool for JPA entity modeling — exploring fetch strategies, cascade options, and relationship types through conversation before generating code. The key insight is that Claude defaults to EAGER fetching and broad cascades unless you constrain it, and that prompting Claude to reason about Hibernate implications exposes trade-offs most developers skip.

Students learn to generate Flyway migration scripts with Claude while catching the common mistakes Claude makes in DDL: missing NOT NULL constraints that the entity requires, incorrect UUID column types for PostgreSQL, forgetting indexes on foreign keys, and generating non-reversible DDL without warning. The key prompt pattern is asking Claude to generate the migration from the entity — not from scratch — so the DDL matches what JPA expects.

Students learn to use Claude as a Hibernate performance auditor — pasting SQL output into Claude to detect N+1 queries, prompting for @EntityGraph and JOIN FETCH fixes, and asking Claude to explain PostgreSQL EXPLAIN output. The key insight is that Claude can read Hibernate SQL logs and database execution plans better than most developers scan them manually, but you have to give it the right context and ask the right questions.

Students learn to critically evaluate where Claude places @Transactional by asking it to explain its reasoning. The key technique is the "explain your choice" prompt — when Claude places @Transactional on a method, ask it why, and watch for incorrect reasoning about Spring's proxy-based AOP, propagation defaults, and read-only optimizations. This builds the habit of questioning Claude's decisions on correctness-critical code.

Students learn to prompt Claude for a complete Spring Security 6 JWT implementation — filter chain, token service, authentication filter, and token refresh endpoint — by encoding every security decision in the prompt rather than letting Claude choose defaults. The key insight is that security code is the highest-risk output Claude produces, and vague prompts produce exploitable defaults.

Students learn the "adversarial review" prompt pattern applied to security code: after Claude generates a Spring Security configuration, ask it to attack its own output by enumerating specific vulnerability categories. This is the security-specific version of the self-review pattern introduced in Lecture 6 (OpenAPI). The key insight is that Claude finds real gaps when you give it a structured attack surface to check against — CORS, CSRF, token storage, header injection, timing attacks.

Students learn that Claude-generated JPQL queries can be vulnerable to injection when string concatenation is used instead of parameterized queries, and that Claude's default input validation misses several common backend attack vectors. The key prompt technique is asking Claude to enumerate the security gaps it did NOT address — forcing it to surface risks it didn't handle proactively.

Students learn to recognize the three failure modes of default Claude-generated tests: happy-path-only coverage, verify() instead of real assertions, and missing edge cases. The lecture introduces the prompt fix — a specific constraint block that changes Claude's test output from shallow to meaningful.

Students learn the specific prompt patterns that produce deep unit tests with AssertJ assertions, ArgumentCaptor usage, and failure scenario coverage — instead of the shallow verify()-only tests Claude generates by default. The key technique is the constraints block that mandates assertion style, failure scenarios, and edge cases.

Students learn to prompt Claude for @SpringBootTest integration tests backed by a real PostgreSQL container via Testcontainers — including test fixtures, transactional isolation, and asserting on actual database state. The key insight is that Claude can generate the entire Testcontainers setup when given the right constraints, but it needs explicit instructions about transaction handling and cleanup to avoid flaky tests.

Students learn the TDD prompt workflow with Claude: give the requirement, ask for the test first, verify the test fails, then ask Claude to implement only enough code to make it pass. The key insight is that this workflow prevents Claude from generating untested code paths and forces implementations to be driven by expected behavior.

Students learn to prompt Claude for async processing patterns — @Async service methods, ApplicationEventPublisher for decoupled flows, and RabbitMQ listener boilerplate — while reviewing the thread pool configuration Claude generates. The key insight is that Claude's default @Async setup uses SimpleAsyncTaskExecutor (which creates unbounded threads), and the prompt must specify a bounded thread pool to avoid production issues.

Students learn to paste async error logs and thread dump excerpts into Claude for diagnosis — identifying thread pool exhaustion, lost async tasks, and transient failures. The key prompt pattern is giving Claude the log context plus the async configuration and asking for root cause analysis. Students also learn to prompt Claude for Spring Retry configuration with @Retryable.

Students learn to prompt Claude for production observability infrastructure — structured JSON logging with Logback, MDC correlation ID filters, and custom Micrometer metrics — while reviewing the output for common gaps. The key insight is that Claude generates valid configurations but defaults to plain-text logging without profile separation and forgets to tag Micrometer metrics unless explicitly prompted.

Students learn the incident diagnosis prompt pattern: give Claude the full context (stack trace + relevant code + configuration), then ask for root cause and fix. The key insight is that Claude's diagnosis quality scales directly with the context you provide — a stack trace alone gets a generic answer, but a stack trace plus the code plus the config gets the actual root cause. Students also learn to push back when Claude suggests a workaround instead of the real fix.

Students learn the architecture-first prompt pattern: have a design conversation with Claude before writing any code. The key insight is that Claude produces dramatically better code when it has a written spec to work from — and that the design conversation itself catches requirements gaps and trade-off decisions that would otherwise surface mid-build.

Students see an end-to-end feature build using every technique from the course — from Flyway migration to JPA entity changes, controller endpoint, service logic with validation, async event publishing, integration tests with Testcontainers, and observability. The key insight is that Claude handles multi-file, multi-layer changes effectively when it has good context (the CLAUDE.md + the design spec from the architecture session).

Students learn to configure Claude Code hooks — deterministic automation that runs before or after Claude's tool calls. The key insight is that hooks enforce rules automatically, not through prompts. A prompt says "don't edit production config." A hook physically blocks it. For production-minded backend engineers, hooks are how you make Claude Code safe by default.

Students learn to create custom Claude Code commands (slash commands) that encode their repetitive Spring Boot prompts as reusable templates. The key insight is that the prompt discipline from the entire course — specific constraints, package names, CLAUDE.md rules — can be captured once in a command file and reused with a single slash command.