DeepSeek v4: Day 2

# Build your own app with this toolchain

1. Get the [System Design Agent Prompt](https://github.com/warncke/ai-proxy/blob/master/system-design-agent.md)
  * Go to [DeepSeek](https://chat.deepseek.com/) and enter the prompt in "Expert Mode"
3. Develop the prompt then use the "generate technical paper" command
4. Copy and paste the result into the `technical-specification.md` file in your project directory
5. Use `npm install -g dirac-cli` to install [dirac](https://dirac.run/)
6. Get the [Self Instatiation Prompt](https://github.com/warncke/ai-proxy/blob/master/instantiate.md)
  * Save as `instantiation.md`
7. Run `cat instantiation.md | dirac -yv`

Two days ago I did my first experiment with DeepSeek v4. Today I pushed it to its limits. The result was not just a prototype — it was a fully spec’d, diagrammed, reviewed, tested, and implemented HTTP reverse proxy with SQLite-backed session tracking, SSE stream parsing, and 90%+ test coverage. All built through structured AI collaboration. Total API cost for the entire day: $0.89.

If you’re an engineer wondering what these new models can actually do — and what you need to use them effectively — here’s the story.

The Setup: All Open Source, One New Fork

The toolchain is deliberately simple. VS Code as the editor. Cline as the coding agent. But there’s a catch: Cline doesn’t support DeepSeek V4 yet, so it can’t use the full 1‑million‑token context window. The solution was Dirac, a Cline fork that’s barely a month old. Dirac not only adds V4 compatibility but brings a critical optimization: instead of regenerating entire files, it makes small, targeted edits. The result is about 65% fewer API calls — which at scale translates directly into lower cost, lower latency, and faster iteration. I ran the whole experiment on Dirac.

Beyond the editor and agent, everything else was just raw prompt engineering: two carefully crafted agent prompts (one for system design, one for npm package generation) and a relentless loop of specification, review, revision, diagramming, test‑planning, and code verification. No cloud services, no paid middleware. The stack is entirely open source, and it cost less than a dollar to run.

What Got Built: A Proxy That’s Actually Production‑Ready

On Day 1 I built a CLI tool called Deepseek Codex. Its built‑in proxy (AiProxyServer) was a monolithic class that logged to flat JSONL files, buffered SSE streams into opaque blobs, had no session tracking, and minimal error handling. It worked, but it was clearly a prototype — an experienced engineer could reproduce it in about three hours.

Today’s output, the AI Reverse Proxy, is a completely different beast. Seven dedicated components:

• ProxyConfig — immutable configuration with 9 parameters
• DatabaseStore — SQLite (WAL mode) with a normalized 4‑table schema and hash‑based session matching queries
• SessionMatcher — heuristic session tracking via SHA‑256 message hashes, client‑ID derivation, idle timeout, and touch‑on‑activity
• RequestDeduplicator — body preprocessing, hash computation, immutable content storage
• RequestForwarder — buffering, upstream HTTPS, hop‑by‑hop header stripping, SSE vs. plain routing, full error mapping (400/413/502/504), timeout detection
• SseStreamHandler — proper SSE protocol parser handling all delimiter variants (\r\n\r\n, \n\n, \r\r), partial chunk reassembly, sequence numbering, and named event handling
• ProxyServer — lifecycle management, graceful shutdown, database ownership

Each component is covered by a test suite that drills into the ugly edge cases: \r\r delimiters, null headers, double‑upsert prevention, client‑disconnect abort, error‑after‑response‑end, and more. A professional software engineer would need roughly 25 hours to produce an equivalent implementation from the same spec. The human time I actually invested across all the design, review, and direction phases? About 5.5 hours.

That’s an 8× amplification on coding alone — and the spec work, which the AI also drafted and reviewed, would have taken an expert another 20+ hours.

The Process: Why Day 2 Was Different

The biggest change wasn’t the model. DeepSeek V4 is excellent, but so was the model I used on Day 1. The difference was process: I split the work into an eight‑stage pipeline where the AI plays multiple roles, and the human provides direction, domain knowledge, and critical judgment at each step.

1. System Design — a conversational agent asks clarifying questions and builds a specification.
2. Specification Authoring — precise TypeScript interfaces, database schemas, and data flow.
3. Critical Review — the same model, now wearing a reviewer hat, finds gaps, inconsistencies, and missing edge cases. It has no ego and catches errors a human might miss.
4. Revision — targeted edits, each justified and traceable to a review finding.
5. Diagram Generation — C4 container and Mermaid sequence diagrams that catch errors invisible in prose.
6. Test Planning — 60+ unit test cases, 17 end‑to‑end scenarios, and validation queries, all before any implementation code exists.
7. Code Generation — a separate coding agent, fed only the final spec, generates the package. It runs a non‑negotiable loop (build → test → coverage) and is forced to continue until all commands exit with code 0 and branch coverage exceeds 90%.
8. Code Review — a final pass found a critical mismatch between SSE delimiter detection and extraction logic, which would have caused silent data loss.

This multi‑stage, role‑switching approach is exactly what I described fourteen months ago in the paper Agentic Synthetic Super Intelligence. The core thesis: AI doesn’t replace human intelligence; it amplifies it, when embedded in a tight human‑in‑the‑loop system where the human defines specifications, reviews outputs, and iterates the prompts.

Takeaway for Engineers

If you’re experimenting with DeepSeek V4, here’s what I learned:

• Separate design from implementation. Don’t mix them in a single prompt. The design phase produces a spec; the coding phase consumes it.
• Use the AI as its own reviewer. After any significant output, explicitly ask: “Review this for missing specifications, incorrect statements, and internal contradictions.” The model will find errors.
• Represent the system in multiple forms. Prose, TypeScript interfaces, C4 diagrams, and Mermaid sequence diagrams are orthogonal; they catch different classes of errors.
• Write the test plan before the code. It forces precision in the spec and gives the coding agent concrete expected behaviours.
• Enforce hard quality gates. Coverage thresholds (90%) are non‑negotiable. The agent is not done until all commands exit clean.
• Treat AI mistakes as prompt bugs. Fix the prompt, not the generated code. Each iteration improves future sessions.
• Estimate everything. Regularly ask the model to estimate your time and a human expert’s equivalent time. That feedback reveals what’s actually high‑leverage.

The prompts, the pipeline, and the verification patterns are all reusable. What worked today will work tomorrow, on a different problem, with a different model.

Repositories: Deepseek Codex (Day 1) · AI Reverse Proxy (Day 2). Theoretical foundation: Agentic Synthetic Super Intelligence (August 2024).

This paper was written by AI (deepseek). The expectation is that readers will engage with the content through AI, using AI to evaluate, explain and question the claims that are made.