AI Skill Report Card

Architecting Production Backend Systems

B+79·Aug 2, 2026·Source: Web
13 / 15

When asked to build a service (e.g., "build a Go/Python/Node order-processing service with Postgres and Pub/Sub"), immediately produce, in this order:

  1. Repository tree (markdown, └── syntax)
  2. Every file, each starting with a path comment on line 1
  3. No prose between code blocks beyond a one-line section header

Example first output block:

# Repository Structure
.
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── api/
│   ├── domain/
│   ├── repository/
│   └── observability/
├── deploy/
│   ├── terraform/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── Dockerfile
│   └── cloudbuild.yaml
├── .env.example
├── .gitignore
├── go.mod
└── README.md

Then emit each file in full, starting with:

Go
// cmd/server/main.go package main ...
Recommendation
Add more concrete examples showing actual code snippets (e.g., circuit breaker implementation, structured logger setup) rather than describing what files should contain
14 / 15

Progress checklist for every service build:

  • Clarify runtime (language/framework), datastore, and messaging boundaries from the request — infer sane Google-stack defaults if unstated (Go or Python, Postgres via Cloud SQL, Pub/Sub, Redis for cache)
  • Emit repository tree
  • Emit domain layer: entities + validation (Pydantic/Zod/struct tags), explicit typed error values
  • Emit repository/data layer: connection pool config (min/max conns, idle timeout), retry wrapper with exponential backoff + jitter, migrations
  • Emit service/business logic layer: circuit breaker wrapping all external calls, context propagation, timeout budgets
  • Emit transport layer (HTTP/gRPC): input validation, structured error responses, correlation ID middleware, /healthz (liveness), /readyz (readiness including dependency pings)
  • Emit observability: structured JSON logger, trace ID injection, Prometheus/OpenTelemetry metric hooks
  • Emit graceful shutdown handling (SIGTERM drain, in-flight request completion, pool close)
  • Emit config layer: env-var driven, validated at boot, fail-fast on missing required vars
  • Emit Dockerfile: multi-stage, distroless/alpine final stage, non-root user, minimal attack surface
  • Emit cloudbuild.yaml (or GitHub Actions) with lint → test → build → scan → deploy stages
  • Emit Terraform: main.tf, variables.tf, outputs.tf — VPC, IAM least-privilege service accounts, autoscaling compute (Cloud Run/GKE), Secret Manager bindings
  • Emit .env.example, .gitignore, lint config (.golangci.yml/ruff.toml/.eslintrc)
  • Emit dependency manifest with pinned versions
  • Emit README.md last: architecture rationale, local run, test commands, deploy pipeline
  • Silently self-verify every checklist item is fully implemented before final output — fix gaps without narrating the check
Recommendation
Include an example of a bad/incomplete output being corrected, to reinforce the 'no placeholders' rule with a before/after contrast
14 / 20

Example 1: Input: "Scaffold a Python inventory service with Postgres and a REST API." Output: Full repo tree rooted at . containing app/api/, app/domain/, app/repository/, app/observability/, alembic/ migrations, Dockerfile (multi-stage, python:3.12-slim builder → distroless runtime, non-root), cloudbuild.yaml (lint→test→build→scan→deploy), deploy/terraform/{main,variables,outputs}.tf provisioning Cloud SQL + Cloud Run + a scoped service account, pyproject.toml with pinned deps, ruff.toml, .env.example, .gitignore, and README.md. Every Python file starts with # app/api/routes.py-style header comment; /healthz and /readyz both implemented; retry+circuit breaker wrap all DB calls.

Example 2: Input: "Add a Pub/Sub consumer to an existing Go service." Output: New internal/consumer/subscriber.go with bounded worker pool, ack/nack handling, dead-letter topic config, context-based shutdown; updated main.go wiring the consumer into the graceful shutdown sequence; updated deploy/terraform/main.tf adding the subscription resource and IAM binding for the service account; no other files touched, no placeholders left in modified files.

Recommendation
The workflow checklist is thorough but very long — consider consolidating into phases (Core Layers, Infra, CI/CD, Docs) for faster scanning
  • Default to explicit over implicit: no framework "magic" auto-wiring without a comment explaining what it does.
  • Every external boundary (DB, cache, queue, downstream HTTP/gRPC service) gets: connection pool bounds, timeout, retry with backoff + jitter, circuit breaker.
  • Every public-facing input gets schema validation before it touches business logic — reject fast with structured 4xx payload ({error_code, message, trace_id}).
  • Logs are structured JSON only: {timestamp, severity, trace_id, span_id, message, ...fields}. Never fmt.Println/print in production paths.
  • Config is validated at process start; missing/invalid required env vars cause immediate exit(1) with a clear log line — never fail silently at request time.
  • IAM in Terraform: one dedicated service account per service, scoped roles only (never roles/owner or roles/editor), Workload Identity for GKE where applicable.
  • Container images: multi-stage build, final stage is distroless (or alpine with packages stripped), runs as non-root UID, read-only root filesystem where feasible.
  • Concurrency defaults: bound worker pools, bounded channels/queues, explicit max in-flight request limits — never unbounded goroutines/async tasks on untrusted input.
  • Always include both liveness (/healthz — process is up) and readiness (/readyz — dependencies are reachable) as separate endpoints.
  • Do NOT use // TODO, pass # implement later, ..., or any stub — every branch, including rare error paths, is fully implemented.
  • Do NOT emit a Dockerfile running as root or using a bloated base (ubuntu:latest, full python:3.x without slim/distroless).
  • Do NOT skip the path-comment header on any file — this is non-negotiable for direct commit-readiness.
  • Do NOT hand-wave Terraform with # add your VPC here — write the full resource blocks.
  • Do NOT use floating dependency versions (^, latest, unpinned) — pin exact or tilde-locked versions known to be non-vulnerable.
  • Do NOT narrate the internal evaluation checklist in the output — it's a silent self-check, not user-facing content.
  • Do NOT produce partial file trees that omit config/IaC/CI files "for brevity" — completeness is the entire point of the exercise.
0
Grade B+AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
13/15
Workflow
14/15
Examples
14/20
Completeness
17/20
Format
14/15
Conciseness
13/15