Build an AI Agent in 2 Days: Full Breakdown of Claude Code + DeepSeek in Action

Two common traps trip up developers building AI Agent portfolio projects: either piling on ten features with none done well, or getting blindsided at deployment by model hallucinations and stateless service issues — then burying those lessons in your own head with nothing to show for it. This Bilibili video delivers a complete breakdown of a project codenamed "HoopMind" (NBA Chat) — an NBA intelligent Q&A demo — with everything from the requirements doc to the post-mortem made public. The vast majority of the coding was done by a Claude Code primary agent, assisted by a DeepSeek V4 Flash sub-agent for specialized tasks. This article distills the engineering methodologies you can reuse directly.

Checklist-Driven Development: Start with a Small, Sharp Core

The project was scoped as a "production-ready AI Agent portfolio piece," with a compressed delivery timeline. The key was that the team didn't jump straight into code. Instead, they used checklist-driven development — first producing multiple RFC documents to establish quantifiable goals: factual accuracy above 95%, most responses under 2 seconds, and 100% interception of sensitive topics.

Here's a counterintuitive but critical lesson: three features done at 90% beats ten features all at 60%. Based on this principle, the team locked in three P0 must-have highlights: play-by-play clutch moment queries (with recognition and correction), player stats comparison tables, and player stories with tactical breakdowns. Interactive features like a player guessing game were explicitly downgraded to P2, to be iterated on after the core was stable.

The team also designed their demo path in advance, preparing three showcase scenarios: "clutch moment queries," "recognition and correction," and "safety interception." Even more importantly — they built a complete Mock demo mode that works with zero configuration and no LLM API keys, ensuring the project could be demonstrated in any situation.

Multi-Model Division of Labor: Strong Reasoning and High-Speed Low-Cost Models Each in Their Lane

The most valuable technical decision was the model assignment strategy for agent development. All core business coding — including the Next.js frontend, agent orchestration logic, tool calling, ESPN data wrappers, safety validation, rate limiting, and edge function deployment — was handled entirely by the Claude Code primary agent.

However, the team found one category of tasks wasn't a good fit for the primary agent: Remotion video script writing, storyboard rendering, and other repetitive media engineering code. These tasks were assigned to the DeepSeek^Ad V4 Flash sub-agent, configured locally by overriding the Haiku slot with V4 Flash, specifically for video assets, subtitle exports, and screenshot packaging scripts.

This yields a reusable division-of-labor principle: hand complex business architecture and agent logic to a high-capability reasoning model; hand high-volume, templated, mechanical script generation to a faster, cheaper model. The frontend uses Next 14, LLM integration uses DeepSeek (OpenAI-compatible API), and the data source is the ESPN API — which requires no API key, sidestepping scraping countermeasures and paid third-party API limitations.

Three-Layer Engineering Defense: Fighting Model Hallucinations with Code

Development surfaced a range of real-world engineering problems — the core challenge that distinguishes LLM projects from conventional applications:

• Hallucinated data: The model fabricates historical game statistics;
• Fake tool-call tags: DeepSeek occasionally outputs pseudo-tags resembling tool calls, breaking streaming output;
• Training data overwriting: The model substitutes stale knowledge from its training set, overriding fresh, accurate data returned by tools.

The team addressed these with three layers of engineering defense: a built-in facts.ts fact library storing key historical facts in code, a three-layer cleaning pipeline to block fake tags, and a prompt-level hard constraint forbidding the model from questioning the authority of tool-returned data. The full implementation is open-sourced and available for reference.

The core insight: LLM projects can't rely on prompting alone — you must use engineering measures to fight hallucinations and output anomalies.

---

Model Hallucination refers to a large language model generating content with high confidence that is factually incorrect or entirely fabricated. For scenarios like NBA game data that depend heavily on precise numbers, hallucinations are especially dangerous — the model might misattribute a game's scoring or invent a buzzer-beater that never happened. The facts.ts fact library's core function is to hard-code key historical facts so the model has a deterministic source to retrieve from, rather than relying on its parametric memory. The fake-tag cleaning layer addresses cases where certain models — particularly in streaming mode — occasionally output XML-like tags such as <tool_call>. If unfiltered, these appear directly in the user interface and break the experience. The prompt hard constraint works by explicitly telling the model via the system prompt that tool-returned data is the sole authoritative source, and that it is prohibited from modifying or overriding that data with training knowledge — closing off the channel through which stale knowledge contaminates fresh data at the instruction level.

---

Deployment Is the Biggest Trap in Portfolio Projects

Many developers consider the project done once the code is written — but deployment is often the most time-consuming phase. The video makes the full post-mortem public:

The team initially chose Vercel, only to find DNS poisoning in China made the domain inaccessible. They cut their losses immediately — deleting the platform project and all key copies — and switched to an architecture using Alibaba Cloud ESA Pages for static assets combined with edge functions. That architecture had its own pitfalls:

• GitHub's Git endpoint is blocked in China, requiring manual code uploads via API;
• Edge function environment variables aren't in process — they must be read from the third function argument;
• SSE streaming protocol gets cut off by some phone manufacturers' WiFi acceleration features;
• WeChat's in-app browser blocks the site.

While iterating on the player guessing game, the team hit a classic Serverless problem: storing sessions in process memory means sessions vanish under multi-instance deployments. The reflexive fix is Redis, but a demo environment may not have Redis available. The team's solution was a self-contained stateless design: the entire game session is AES-GCM encrypted and HMAC signed, then stored in a GameID token — no server-side storage needed, with tokens rotating each round to prevent tampering and keep the answer confidential.

Another hard lesson: AI must not be the sole dependency in a critical code path. There were cases where the rules engine failed to match the input and the LLM's technically correct answer still didn't trigger the player card reveal popup. The fix: rules engine first, LLM as fallback only.

---

SSE (Server-Sent Events) is a unidirectional real-time push protocol over HTTP, where the server continuously streams text data to the client — commonly used to implement the "typewriter effect" for LLM streaming output. Unlike WebSocket's bidirectional communication, SSE keeps a persistent long connection initiated by the client while the server pushes data in chunks. Because it's a long-lived connection, some carriers, routers, or phone manufacturers' network acceleration modules misidentify it as an anomalous connection and forcibly terminate it, causing output to cut off mid-stream for users. Serverless / Edge Functions are a compute model that requires no server management — each request spins up an isolated, short-lived process, which is destroyed when the request ends. This means any data stored in process memory (such as game session state) is very likely lost on the next request, which may hit a different instance entirely. This is the root cause of the stateless problem, and the core reason the project uses an encrypted token scheme instead of server-side storage.

---

Automated Testing and Documentation: The Engineering Record Is Its Own Resume Highlight

The project didn't stop at feature completion. The team wrote automated acceptance test scripts covering 63 test cases across clutch moment queries, fact-trap questions, sensitive content interception, and multi-turn conversation — all passing — with one-click regression testing to maintain demo quality. After the 1.0 release, the previously deprioritized P2 features (player guessing game, player card generator) were iterated back in.

Business code, requirements documents, acceptance scripts, and post-mortems are all published to GitHub. The video makes an inspiring point: if you can fully document your thinking, your mistakes, and your solutions and make them public, that engineering record becomes one of the most compelling parts of your resume. Many developers keep their lessons in their heads and their code only runnable locally — but open, reusable solutions help other developers who are learning the same things.

Seven Reusable Methodologies

1. Checklist-driven development: Use documents to define goals, acceptance scripts to define completion, and priority tiers to stay focused;
2. Do fewer things at a higher quality — reject feature bloat;
3. Build a Mock demo mode to ensure you can always demonstrate the product anywhere;
4. Fight hallucinations with engineering, not just prompting;
5. Research your deployment environment in advance — don't assume offshore platforms will work;
6. In Serverless, never store sessions in process memory — rules engine first on critical paths, LLM as fallback;
7. Multi-model division of labor: complex business logic to the high-capability reasoning agent, scripting tasks to the fast, low-cost model.

The core value of this real-world experience with Claude Code and DeepSeek V4 Flash isn't in the NBA Q&A use case itself — it's in making the complete engineering chain of a portfolio-grade AI Agent, from requirements to deployment, fully transparent. For developers looking to build their own portfolio projects, this is a blueprint worth copying.