ai-implementation
The Engineering Team: How using Claude Code to Run an Entire Infrastructure Company
Feb 8, 2026
On one hand, the biggest companies on earth are doubling down on AI investment. The hyperscalers are pouring billions into GPU clusters and model infrastructure. Entire divisions are being reorganized. Some of these companies are spending more on AI compute than small nations spend on defense. The signal from the top is unmistakable: AI is the bet.
On the other hand, the doom-and-gloom chorus has never been louder. It’s overhyped. The bubble is about to pop. Large language models are just fancy autocomplete. Investors are going to get burned. The discourse swings between breathless optimism and existential dread, and most of it misses the point entirely.
Here’s what I know: if you were building a startup five years ago and you’re building one now, the difference isn’t subtle. It’s tectonic. The speed at which you can ship has changed. The scale of what a small team can maintain has changed. The creative surface area available to a lean startup — the ability to think across backend systems, infrastructure, frontend, data pipelines, and developer experience simultaneously — has changed in ways that would have felt like science fiction in 2020.
Five years ago, you would have needed to choose. Pick one domain, outsource or ignore the rest, and hope the gaps don’t kill the company before revenue fills them. Today, you don’t have to choose.
We are building pg-collector, an AI-powered observability platform for PostgreSQL. It combines edge compute, LLM-driven diagnostics, and vector databases to give database teams predictive intelligence — a dashcam for your database.
The ambition is massive. We’re not building a simple monitoring dashboard. We’re building a platform that ingests telemetry from PostgreSQL instances at the edge, runs AI-driven root cause analysis in real time, maintains a persistent Query Vault with Bronze/Silver/Gold data layers for historical performance forensics, and is expanding to cover MySQL and SQL Server. Managed and unmanaged deployment options. GitHub Actions as a distribution model. Diagnostic accuracy targets north of 95%.
That’s the kind of roadmap that would normally demand a well-funded engineering organization. Instead, we run lean — extremely lean — with Claude Code acting as a force multiplier across every engineering domain we touch.
No bloated engineering org. No six-figure monthly payroll. Just a small team with deep domain expertise, Claude Code in the terminal, and a monthly burn rate under $2,000 while we ship across six engineering domains that would normally require a staff of five or six specialists.
This post isn’t about which side of the AI debate is right. It’s not about hype cycles or market corrections. It’s about the operational reality — right now, today — of using an AI coding agent to execute an ambitious technical roadmap without burning through a seed round in nine months. The big companies are spending billions because they see what’s coming. The skeptics are focused on what AI can’t do. We’re focused on what it already does, every single day, in our terminal.
The Problem With Ambitious Plans and Thin Teams
Every startup advisor tells you to focus. Pick one thing and do it well. That’s great advice — until you realize that “one thing” requires:
A data collection agent that runs at the edge (Go, systemd, PostgreSQL internals)
A streaming pipeline to ingest telemetry (Kafka, schema management)
An API backend to serve diagnostics (Python, FastAPI)
A frontend that doesn’t look like it was built in 2009 (Next.js, React)
Infrastructure that doesn’t fall over (Kubernetes, Helm, Terraform)
CI/CD that actually catches bugs before your users do (GitHub Actions)
A caching strategy that keeps your cloud bill from bankrupting you
That’s not one discipline. That’s six or seven, each with its own ecosystem, best practices, and failure modes. A traditional startup would need at minimum a backend engineer, a frontend developer, a DevOps/platform engineer, and maybe a part-time data engineer. At market rates, you’re looking at $40K-$60K/month in payroll before you’ve closed a single deal.
For a lean company optimizing for runway, that math doesn’t work.
Claude Code as an Engineering Multiplier
We started using Claude Code not as a code generator, but as a domain-context orchestrator. The distinction matters.
A code generator gives you snippets. An orchestrator holds the context of your entire system in working memory — your Kubernetes manifests, your API contracts, your caching topology, your CI pipelines — and makes coherent changes across all of them simultaneously.
Here’s what a typical development session looks like:
We describe a feature or a bug in GitHub Issues + .claude.md. Claude Code reads the relevant files, understands the dependency chain across services, and proposes changes that span multiple repositories and infrastructure layers. We review, adjust, and ship.
The key insight is that Claude Code eliminates the context-switching tax that kills lean team productivity. Instead of spending 30 minutes remembering how a Helm chart’s value overrides work before adding a new environment variable, we describe the intent and Claude Code navigates the YAML hierarchy, the Dockerfile, the application config, and the CI pipeline in one coherent pass.
Domain-by-Domain: Where Claude Code Delivers
Backend Engineering
pg-collector’s diagnostic engine runs LLM inference against PostgreSQL telemetry data — query plans, wait events, pg_stat_statements snapshots, lock graphs. Getting the analysis pipeline right means working across Python async code, PostgreSQL-specific domain logic, and LLM prompt engineering simultaneously.
Claude Code handles this well because the feedback loop is tight. We describe the diagnostic scenario (e.g., “detect when index bloat is causing sequential scans on tables that have valid indexes”), Claude Code writes the detection logic, the LLM prompt template, and the unit tests. We run the tests against real anonymized production snapshots. Iterate. Repeat.
The accuracy of our AI diagnostics has climbed from 65% to over 85% largely because Claude Code lets us run experiments that would take hours in minutes. Prompt refinement, temporal correlation logic, workload classification — these are all areas where rapid iteration matters more than perfect first-draft code.
CI/CD with GitHub Actions
CI/CD is the domain where Claude Code saves me the most calendar time. Not because the code is hard, but because CI/CD debugging is one of the most painful feedback loops in software development. You push a change, wait 3-8 minutes for the pipeline to run, read a wall of logs, make a fix, and repeat.
Claude Code collapses this loop. We describe what we want the pipeline to do — build the Docker image, run the test suite against a real PostgreSQL instance, push to the container registry, update the Helm chart — and Claude Code generates the workflow YAML with the correct action versions, secret references, and job dependencies.
More importantly, when a pipeline breaks, we paste the error output and Claude Code diagnoses the issue across the workflow file, the Dockerfile, and the application code simultaneously. No more bouncing between three browser tabs trying to correlate a Docker build failure with a missing build argument that was supposed to come from a GitHub secret.
Kubernetes and Cloud Infrastructure
We run pg-collector’s backend on Kubernetes. The platform deploys into customer environments as well, which means the Helm charts need to be production-grade — configurable, well-documented, and resilient.
This is where Claude Code’s ability to hold multiple file contexts shines. A single feature addition might touch the Deployment manifest, the Service, the ConfigMap, the values.yaml, the helpers template, and the NOTES.txt. Claude Code treats these as a coherent unit rather than six independent files.
We’ve also used Claude Code to write Terraform modules for our managed offering. The pattern is the same: describe the desired end state, review the generated infrastructure code, apply it. The quality is consistently good enough that we spend review time on security and cost implications rather than syntax debugging.
The Caching Layer: Targeting 95% Cache Hit Rates
This is the domain where Claude Code has had the most direct impact on our unit economics.
pg-collector uses a headless Wagtail CMS with a Next.js frontend. Every CMS page render that hits the database costs money — both in compute and in database load that we’d rather reserve for actual product workloads. Our target is a 95% cache hit rate, which effectively means that only 1 in 20 page requests should touch the origin.
The caching architecture spans multiple layers:
Next.js ISR (Incremental Static Regeneration): Pages are statically generated at build time and revalidated on a configurable interval. Claude Code helped us design a revalidation strategy that balances freshness with cache efficiency — high-traffic marketing pages revalidate every hour, documentation pages every 24 hours, and the blog on a webhook trigger from the CMS.
Nginx reverse proxy cache: Sits in front of the Next.js server and caches full page responses. Claude Code helped us debug a subtle cache staleness issue where Nginx was serving stale content after CMS edits because the cache key didn’t account for Wagtail’s draft/live revision system. The fix required coordinated changes across the Nginx config, the Wagtail signal handlers, and the Next.js API routes that trigger cache purges. That’s a three-layer debugging problem that would have eaten an entire day to untangle manually.
API response caching with Redis: Diagnostic API responses are cached with TTLs based on data volatility. Static reference data (PostgreSQL version compatibility, known issue signatures) is cached aggressively. Live telemetry summaries use short TTLs with cache-aside patterns.
CDN edge caching: Static assets and marketing content are pushed to the CDN edge with long cache lifetimes and content-hash-based cache busting.
Claude Code’s contribution here isn’t just writing the caching code — it’s maintaining coherence across the layers. When we add a new content type in Wagtail, Claude Code updates the ISR config, the Nginx cache rules, the purge webhook, and the CDN invalidation logic in a single pass. Without that cross-cutting coherence, cache bugs are inevitable, and cache bugs are the kind of silent failures that bleed money.
Frontend Development
Our core expertise is in databases, distributed systems, and data engineering — not pixel-perfect frontend development. But pg-collector needs a marketing site, a documentation portal, and a product dashboard that doesn’t make database engineers cringe.
The more valuable contribution is in Next.js-specific patterns — server components vs. client components, dynamic vs. static rendering, middleware for authentication, and the App Router’s caching semantics. These are areas where the framework moves fast and the documentation doesn’t always cover the edge cases. Claude Code’s training data includes enough Next.js patterns that it handles most of these correctly on the first pass.
The Economics
Let me lay out the actual numbers.
We can iterate on product-market fit without the existential pressure of a payroll clock ticking down.
The 95% cache hit rate target is a direct contributor here. Every percentage point of cache efficiency reduces our compute costs. At scale, the difference between 80% and 95% cache hit rates is a 3-4x reduction in origin server load. For a lean company, that’s the difference between needing a $200/month server and a $800/month server.
What Claude Code Can’t Do
Honesty matters, so here’s where Claude Code falls short:
Deep architectural decisions. Claude Code can implement an architecture, but it doesn’t have the judgment to choose between fundamentally different approaches. Should pg-collector use a push model or a pull model for telemetry collection? That decision requires understanding the customer’s network topology, security posture, and operational culture. That’s founder work.
Customer conversations. No amount of AI tooling replaces talking to database engineers about their pain points. The product direction comes from those conversations, not from code generation.
Novel algorithm design. When we need a new approach to temporal correlation in diagnostic data — linking a CPU spike at 2:47 PM to a specific query pattern that started at 2:45 PM — Claude Code can help implement the algorithm once we’ve designed it, but the creative leap of figuring out the right approach still requires human intuition and domain expertise.
Security review. We use Claude Code to write security-sensitive code, but we review it with the same rigor we’d apply to any contractor’s work. Trust but verify.
Advice for Technical Founders Considering This Approach
Optimize for tight feedback loops. Claude Code is most valuable when you can test its output quickly. Invest in local development environments, fast test suites, and preview deployments. The faster you can validate, the more iterations you can run per hour.
Treat Claude Code as a senior engineer who needs code review, not as a junior who needs hand-holding. Give it context, intent, and constraints. Don’t micromanage the implementation. Review the output like you’d review a pull request.
Invest in documentation and structure. Claude Code performs dramatically better when your codebase is well-organized with clear naming conventions, consistent patterns, and good documentation. This is time well spent regardless, but it pays compound dividends when you’re working with AI tooling.
Keep your architecture boring. The simpler your infrastructure, the better Claude Code handles it. Kubernetes with Helm, GitHub Actions, PostgreSQL, Redis, Next.js — these are all well-understood patterns with massive training data coverage. If you’re running an exotic stack, your mileage will vary.
Use caching as a cash flow strategy, not just a performance optimization. Every request you serve from cache is a request that doesn’t hit your database or your compute layer. At lean startup scale, a 95% cache hit rate isn’t a vanity metric — it’s a survival strategy.
Conclusion
pg-collector exists — with an ambitious multi-database, multi-deployment roadmap — because Claude Code made it economically viable for a lean team to ship across six engineering domains simultaneously. Not perfectly — but well enough to get to market, talk to customers, and iterate toward product-market fit without burning through a seed round in nine months.
The startup ecosystem has spent the last decade optimizing for speed-to-scale. Raise fast, hire fast, grow fast. There’s an emerging alternative: stay lean, stay solvent, and let AI tooling handle the breadth while you focus the team’s energy on the depth that only domain experts can provide.
If you’re running PostgreSQL in production and you want AI-powered diagnostics that actually understand your workload patterns, check out pg-collector. It’s built by database people who got tired of staring at dashboards at 2 AM — and by an AI coding agent that never gets tired at all.
If you’re running PostgreSQL and want AI-powered diagnostics that think like a senior DBA, join the Beta