DEV Community

Cristian Sifuentes
Cristian Sifuentes

Posted on

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

#ai #claudeai #docker #backend

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)