First of all, this assignment was created before the last 2 generations of models, so implementing it as is would be a five-word prompt today, rather than a two-hour task, so I thought I'd try to be creative and do way more than was assumed by the creator, and spend less time anyway.
So I thought I could cover all 3 goals by rewriting the thing in Go:
Under normal work circumstances I wouldn't rewrite a whole service for no good reason. Also I don't even know the potential number of users and estimated load, so it makes no sense at all to start performance optimization. So for this exercise I assumed I'll just do 80% performance optimization for high-ish load. I thought I would show off in my use of agents, actually I didn't even use many agents as the task is still too small to benefit much from parallelization.
Implemented a full test suite and benchmark that's implementation-platform agnostic. Reimplemented the service in Go using the test suite. Optimized queries and measured the gains from query optimization, optimized Django vs. Go, and both combined.
Summarized performance results:
Endpoint Query Optimized Combined optimization Django → Go ━━━━━━━━━━ ━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━ ━━━━━━━━━━ Listing 10.7× 34.6× 369× ────────── ──────────────── ────────────── ────────── Search 12.1× 11.8× 143× ────────── ──────────────── ────────────── ────────── Tag 11.9× 22.7× 271×
See the detailed performance comparison for timings, resource measurements and methodology. Query-only and combined ratios compare runs with different preparation protocols; the optimized Django-to-Go comparison uses matched runs.
Everything is documented, but it's better if you use your agent to ask about it, there is a lot.
Extra deliverables:
What I did, i.e. how I achieved the result:
Human time spent 1 hour 50 minutes, wall clock time spent with AI running: 4 hours 7 minutes
Built an independent Go HTTP/database/SQL/benchmark harness, characterized the existing Django behavior, then implemented the eight endpoints in Go. The 66 contract cases and six full-data read comparisons pass. The declared paired performance/resource gates pass; full listing went from about 93 seconds to 263 ms on the synthetic fixture, primarily by eliminating repeated SQL queries. Added native setup/migrations, production safeguards, operational tests, a systemd example and CI configuration. See the report for evidence, failed initial measurements, coverage and limitations.
As a final control, optimized Django's three collection queries in a separate variant. Its full listing dropped to about 8.7 seconds; Go took about 252 ms in the matched comparison. That measures the implementations, not language alone.
A rewrite is a deliberate exercise-specific choice: the application is small, there is no stated language restriction, and building a reusable harness makes the experiment interesting and inspectable. It is also fun. I would not automatically rewrite an inherited production application; migration cost and actual consumers would matter more than demonstrating a new implementation.
Port or test the unused Django admin, add authentication, fix functional bugs, add pagination, redesign the domain, require containers/VMs, or install another PostgreSQL server. Existing bugs and partial writes are preserved and documented. The original Django application is unchanged. Python tooling improvements are not the primary submission; Django's query problems are fixable, not inherently hopeless. No live-data cutover or actual host service installation is claimed.
Agree on pagination and write correctness with the API's consumers, then version those behavior changes and extend the existing harness. Unbounded responses and lost counter updates remain real problems even when the implementation is faster. Before a real rollout, rehearse migration and backup restoration on representative data and run sustained-load tests on the intended deployment host.
Codex assisted with discovery, planning, implementation, tests, diagnostics and documentation. Decisions and measurements are inspectable in the repository. The visible conversation threads exclude tool payloads, system instructions, private reasoning and injected checkpoint summaries.