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

" width="800" height="533">

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