Conversational Development With Claude Code — Part 11: Implementing Ratings in the Backend with Claude Code and Docker

Conversational Development With Claude Code — Part 11: Implementing Ratings in the Backend with Claude Code and Docker

TL;DR

We implemented the Ratings feature in the Platiflix backend using Claude Code v2 with Sonnet 4.5, fully inside Docker, orchestrated with a Makefile, accelerated using Dangerously Skip Permissions in a controlled environment, validated with 39 passing tests, and finalized with a structured security review aligned to OWASP.

This is disciplined AI-assisted backend engineering — not autocomplete.

When architecture stops being theory

In the previous phase, we migrated the database.

In this phase, we introduced behavior.

A ratings table without services is inert.
An endpoint without validation is fragile.
A feature without tests is irresponsible.

So the objective was precise:

• Implement the Service Layer
• Expose controlled endpoints
• Preserve container isolation
• Maintain test stability
• Perform a security audit before declaring success

This is where planning becomes execution.

Environment discipline: nothing runs outside Docker

One invariant guided the entire implementation:

Every backend command must execute inside the API container.

We enforced this using:

• Docker
• Makefile orchestration
• Claude Code project memory via hash
• Pre-flight container validation

Execution flow:

make build
make start
make test

The Makefile became our operational interface.

This eliminated environment drift and ensured reproducibility.

Controlled acceleration: using Dangerously Skip Permissions safely

We enabled Dangerously Skip Permissions only because:

• The backend ran inside a disposable container
• The database could be recreated via migrations and seeds
• Unit tests were comprehensive
• The network surface was restricted

This removed repetitive approval prompts and significantly accelerated implementation.

But the rule is strict:

Never use this flag where damage is irreversible.

Acceleration without isolation is recklessness.

Phase 1 — Service Layer

Seven methods were implemented according to the architectural plan.

Responsibilities included:

• Creating ratings (1–5 enforced)
• Updating ratings with ownership validation
• Preventing duplicates where required
• Aggregating ratings per course
• Maintaining transactional integrity
• Delegating persistence to repositories

No business logic leaked into endpoints.

Service layer = rule enforcement.

Phase 2 — Endpoints and Schemas

We introduced:

• A schemas directory
• Pydantic rating models
• Clear request/response boundaries
• Strict validation contracts

Endpoints:

• Were thin controllers
• Delegated immediately to services
• Enforced authentication context
• Were covered by integration tests

Routes orchestrate. Services decide.

Phase 3 — Testing inside Docker

Tests ran inside the container using:

make test

Final outcome:

• 39 passed
• 1 skipped
• 0 regressions

Validated areas:

• Database integration
• Model persistence
• Endpoint correctness
• Rating bounds enforcement
• Aggregation logic

Tests were not an afterthought.
They were the safety net for long AI-assisted sessions.

Long-session context management

This build consumed ~66% of a 200k token context window.

Claude Code suggested compaction when 9% remained.

Commands used:

context
compact
reset

Understanding memory usage prevents reasoning degradation in extended sessions.

Context is infrastructure.

MCP usage and token economy

We used:

• Two MCPs tied to the editor
• Minimal custom agents

Each tool increases token overhead.

Tool discipline = cognitive clarity.

Security review: the non-negotiable audit

After bypassing permissions and completing implementation, we ran:

security review

Claude Code produced:

• A structured Markdown report
• Stored under spec/03-ratings-security-review.md
• Executive summary
• Risk prioritization

Critical finding

Potential authorization bypass in rating modification.

Classification:

• OWASP: Broken Access Control
• Confidence: 95%

This confirmed the necessity of post-implementation security analysis.

Remediation workflow

1. Patch authorization logic.
2. Add negative-path tests.
3. Re-run security review.
4. Repeat until no critical findings remain.

Security is iterative tightening.

What this chapter proves

We achieved:

• Fully functional backend ratings feature
• Container-isolated execution
• Makefile-driven reproducibility
• Stable test suite
• Context-aware AI session management
• OWASP-aligned security validation
• Structured documentation in spec/

This is not AI replacing engineering.

This is AI operating under engineering constraints.

Next phase

• Harden authorization rules
• Expand negative-path coverage
• Align with CI/CD pipeline
• Prepare frontend integration

The feature exists.

Now it must survive production.

If you implemented this feature:

• Did you isolate execution inside Docker?
• Did you audit authorization boundaries?
• Did you use security review before merging?

Share your approach in the comments.

— Cristian Sifuentes