Projects Built With Claude Code: Real Systems in 2026

The first time I let Claude Code refactor a serverless integration by itself, I sat and watched the diff scroll by. Twenty-three files touched, three of them ones I would not have thought to change. It found a race condition in a Lambda I wrote in 2023 that had been silently retrying itself for months. That was the moment I stopped treating agentic coding as a demo and started building around it.

This post is a walkthrough of actual production systems I shipped in 2026 with Claude Code as the primary coding agent: what I let it drive, what I keep human, and the specific patterns that made the difference between a fun toy and something I trust in a paid engagement.

The three systems I'll walk through

Three shipped systems, one paragraph each, then we go deep.

System 1: BizFlowAI ContentStudio. A multi-agent SEO and content machine that researches topics, drafts, edits, optimizes for AEO, and publishes across several sites. Claude Code wrote most of the orchestration layer, the retry logic, and the eval harness. About 34,000 lines of TypeScript across the monorepo.

System 2: Serverless AWS glue for a support workflow. Zendesk to AWS Lambda via EventBridge, with SLA scoring, escalation routing, and a Slack surface. Claude Code owns the IaC (CDK) and the Lambda handlers. I own the schemas and the alerting thresholds.

System 3: Local-LLM RAG for a technical knowledge base. Ollama plus pgvector plus a hybrid search layer with RRF. Claude Code wrote the ingestion pipeline, the reranking logic, and about 80% of the eval set. I wrote the retrieval strategy, because retrieval is where you lose or win.

None of these are green-field playgrounds. They all have paying users or internal SLAs. That constraint shapes everything below.

System 1: A multi-agent SEO pipeline (what I delegated, what I did not)

ContentStudio is the system I get asked about most, so let's start there. The architecture, roughly:

research agent → outline agent → draft agent → 
critic agent → SEO/AEO agent → publish agent

Each agent is a Claude call with a scoped tool set and a strict output schema. A scheduler kicks off runs, a Postgres table holds state, and a worker moves jobs through the graph. Nothing exotic. What is exotic is that Claude Code wrote roughly 70% of the code in this system, and I trust it in production.

Here is the delegation split that actually worked:

The pattern: I own intent, it owns implementation. If I can write a paragraph describing what a piece of code should do and a paragraph describing how to know it works, Claude Code can usually write it faster and cleaner than I can, and it will add tests I would have skipped at 9pm.

Where it burned me: agent prompts. Early on I let Claude Code "improve" the writing agent's system prompt based on a few failure examples. The prompt got longer, more defensive, and the output got worse. Prompts are a product surface, not code. I write them, I version them, I eval them. Claude Code can suggest variants, but it does not merge them.

Number that matters: the eval harness Claude Code wrote for me runs 40 scenarios in about 90 seconds and flags regressions on every PR. Before it existed, I was shipping prompt changes on vibes. Now I ship them on a green check.

System 2: Serverless AWS glue, with actual SLA compliance

This one is closer to what most engineering leaders ask me about: unglamorous integration work that has to be right. Zendesk fires an event, EventBridge routes it, a Lambda scores the ticket against SLA rules, another Lambda escalates and posts to Slack. All in CDK, all deployable from a single command.

Claude Code wrote almost all of the CDK. The pattern that worked:

1. I describe the resource graph in plain English at the top of a PLAN.md file.
2. Claude Code generates the stack, one construct at a time, running cdk synth between steps.
3. I read the CloudFormation diff before every deploy. Every time.

That last step is non-negotiable. Agentic coding for infra is fine if and only if the human reviews the synthesized artifact, not just the source code. I have caught two subtle IAM issues this way that would have overprovisioned roles. Not catastrophic, but not something I want on a client's account.

The gotcha that will bite you: EventBridge retry semantics

Claude Code, by default, writes Lambda handlers as if they will run exactly once. EventBridge does not promise that. I now include this in my project's CLAUDE.md:

All handlers processing EventBridge events must be idempotent. Use the event ID as an idempotency key stored in DynamoDB with a 24h TTL. Do not assume single delivery.

The moment I added that line, every new handler it wrote came with the right pattern. CLAUDE.md is the single highest-leverage file in any Claude Code project. Treat it like a staff engineer's onboarding doc for the agent.

System 3: RAG with local LLMs, and where the agent stops being useful

The RAG system is where I learned the sharpest lesson about delegation. Retrieval quality is not a coding problem, it is a search problem, and search problems are won by understanding your data. Claude Code cannot understand your data. You have to.

The stack: PostgreSQL with pgvector for dense retrieval, tsvector for lexical, Reciprocal Rank Fusion to combine them, a cross-encoder rerank on the top 50, and Ollama serving a local model for generation. Standard 2026 hybrid RAG.

What Claude Code did brilliantly:

• Wrote the chunker with configurable strategies (fixed, sentence, semantic).
• Built the ingestion pipeline including OCR fallback and dedup.
• Wrote the pgvector index management (HNSW parameters exposed).
• Generated ~200 eval questions from the corpus, then wrote the scorer.

What I had to do myself:

• Decide the chunk boundaries actually made sense for our docs (they did not, at first).
• Look at the top-10 retrievals for 40 real queries by hand.
• Tune the RRF weights based on that manual review.
• Kill the semantic chunker and replace it with a hand-tuned heuristic.

The number: manual review of 40 queries moved retrieval hit-rate from 0.71 to 0.89. No amount of agentic coding would have done that, because the agent does not know what a correct retrieval looks like in your domain.

This is the honest limit of agentic coding for RAG in 2026. The plumbing is a solved problem. The judgment is not.

The workflow that makes Claude Code actually productive

After a year of shipping with it, my workflow has converged on a few habits. I will list them in the order they matter.

1. Start every project with a real CLAUDE.md. Not a README. A document that answers: what does this system do, what are the invariants that must never be violated, what are the conventions (naming, error handling, logging), and what are the "if in doubt, ask" cases. Mine average 300-500 lines. This is the single biggest quality lever.

2. Plan before you code. For any change bigger than a bug fix, I ask Claude Code to produce a plan first, in a scratch file. I read the plan, edit it, then approve. This catches about 80% of the times it would have gone off the rails.

3. Keep sessions scoped. Long sessions accumulate context that hurts more than helps. I open a new session per logical unit of work. Passing state through committed code and CLAUDE.md is more reliable than passing it through chat history.

4. Read every diff. Non-negotiable. I have never once regretted reading a diff. I have regretted skimming one.

5. Let it write tests before it writes code. This is basic TDD, but it maps unusually well to agentic coding. If Claude Code writes a failing test that captures the intent, then implements against it, the output is dramatically better than free-form generation.

6. Version prompts like code. Every agent prompt in ContentStudio lives in a file, has a version, has an eval scorecard, and cannot be changed without a PR. Claude Code respects this because I put it in CLAUDE.md.

What to delegate vs. what to review yourself

If you are a founder or head of engineering evaluating agentic coding, this is the mental model I would give you:

Delegate freely:

• Boilerplate: schemas, types, DAO layers, migration files.
• Test scaffolding and fixture generation.
• IaC that you will read the synth output of.
• Refactors within a well-tested module.
• Documentation and inline comments.

Delegate with review:

• Business logic (always read the diff).
• Retry, error handling, idempotency (verify the invariants).
• Prompt suggestions (accept ideas, not merges).
• Dependency upgrades (run the full suite).

Do not delegate:

• The schema design itself.
• Retrieval strategy in RAG.
• The eval rubric ("what is good").
• Security-sensitive code paths.
• Anything you cannot describe clearly in a paragraph.

That last one is the honest test. If you cannot describe what you want in plain English, the agent cannot build it, and neither can a junior engineer. The failure mode is the same, the fix is the same: get clear first, then delegate.

The pitfalls that cost me time

A short honest list, in case you are about to hit them.

Overconfidence on unfamiliar libraries. Claude Code will happily write code against a library API that no longer exists in the current version. Pin your versions in CLAUDE.md and tell it to check.

Silent scope creep. Ask for a bug fix, get a refactor of three adjacent files. Cap scope explicitly: "change only handler.ts, do not touch other files."

Test theater. It will write tests that pass by asserting on the implementation rather than the behavior. Read the tests, not just the count.

Prompt bloat in agent systems. Every time it "fixes" a prompt by adding a paragraph, quality drops. Prompts want to be short and specific.

Migration disasters. Do not let it run destructive DB migrations without a dry-run. Ever.

What I'd do if I were starting today

If you are a founder or CTO looking at agentic coding for the first time, here is the honest sequence:

1. Pick one system you own end-to-end that has a clear spec and low blast radius.
2. Write a proper CLAUDE.md before you write a line of code.
3. Give Claude Code the plumbing, keep the judgment.
4. Instrument everything. Evals, logs, cost per run. You cannot improve what you do not measure.
5. Do not fire your senior engineers. Give them agentic tools and watch throughput multiply. The bottleneck moves from typing to thinking, which is exactly where you want it.

The systems I shipped this year would have taken me 3x longer without Claude Code. They also would have been worse, because the eval harnesses and the test coverage would not have existed. That is the real story of agentic coding in 2026: not that the agent replaces the engineer, but that a senior engineer with a good agent ships work that used to require a team.

If you are evaluating agentic coding for a real system and want a second opinion from someone who has shipped these patterns in production, get in touch at lazar-milicevic.com/#contact. There are more field notes on the blog if you want to keep reading.