From Zero to Production-Grade AI Autopilot in 10 Days: Building Claimflow on Qwen Cloud:
The Challenge On July 5th, 2026, I stared at a blank repository and a bold deadline: 10 days to build a production-ready AI autopilot agent for the Global AI Hackathon Series with Qwen Cloud — Track 4. The problem I chose to tackle? Insurance claims fraud detection — an $80 billion annual problem where manual processes are slow, inconsistent, and easily gamed. The goal: build a system that could read a customer's claim, analyze their uploaded photo, verify real-world weather data, cross-validate everything, and make an intelligent routing decision — all with human oversight at critical checkpoints. Today, July 15th, Claimflow is live, tested, and submitted. Here's how it happened.
Day 1-2: Architecture First, Code Second I've learned from past hackathons (including building TerraPilot) that jumping straight into code creates technical debt you can't repay in a sprint. So I started with the architecture. The core insight: Fraud detection isn't a single AI call — it's an orchestrated pipeline where each step informs the next. I designed a 6-node LangGraph state machine: Triage → Investigation → Risk Assessment → Human Review / Auto-Approve / Reject ↓ ↓ Vision Analysis Weather Verification
Each node has a single responsibility: Triage Node: Extract structured data from messy customer text using Qwen-Max with Pydantic-enforced Structured Output (zero hallucination) Vision Node: Analyze uploaded photos with Qwen-VL to detect damage type and severity Investigation Node: Call external tools (Open-Meteo Historical Weather API) to fact-check claims against real-world data Risk Assessment Node: Cross-validate text ↔ image ↔ weather and calculate a fraud risk score Human Review Node: Route high-risk claims to human analysts with full evidence Auto-Approve Node: Fast-track legitimate claims with matching evidence Key design decision: Fail-Closed Security. If any verification step fails, the system NEVER auto-approves. It always escalates to human review. In insurance, a false positive (unnecessary review) is infinitely better than a false negative (paying a fraudulent claim). Day 3-4: The Qwen Cloud Integration The heart of Claimflow is Alibaba Cloud's Qwen models, accessed through the DashScope API. Why Qwen? Three capabilities made the difference: Structured Output with qwen-max: Instead of parsing JSON from free-form text (fragile, error-prone), I forced the model to return Pydantic objects directly. The model either conforms to the schema or the library retries. Zero parsing errors in 103+ tests. Multimodal reasoning with qwen-vl-max: The agent doesn't just read — it SEES. When a customer claims "my kitchen caught fire" but uploads a photo of a water leak, Qwen-VL catches the inconsistency immediately. This cross-validation between text and image is what separates a toy demo from a real fraud detection system. Tool calling: Qwen's ability to decide WHEN to call external tools (like weather APIs) and HOW to interpret the results enables the Investigation Node to act autonomously without hard-coded logic. Integration challenge: The DashScope API required careful configuration of the international endpoint (dashscope-intl.aliyuncs.com) and proper API key management through Alibaba Cloud's RAM (Resource Access Management) service. I created a dedicated RAM user (claimflow-dev) with minimal permissions — following the principle of least privilege even in a hackathon project. Day 5-6: The Frontend and Human-in-the-Loop Track 4 explicitly requires "production-readiness over toy demos." The most production-ready pattern in AI? Human-in-the-loop. I built a two-panel Streamlit dashboard: Left Panel (Customer Portal): Submit claims with text description and photo upload Right Panel (Analyst Dashboard): Real-time visualization of the AI agent's reasoning process, with approve/reject actions and audit trail The critical UX detail: the analyst sees WHY the AI flagged something, not just that it did. Every inconsistency is listed with evidence: ❌ Image shows water damage but text claims fire ❌ Weather data shows clear skies on reported storm date ⚠️ No structured data could be extracted — manual review required This transparency builds trust. The AI augments human judgment; it never replaces it. Internationalization: Since this is a global hackathon, I implemented full i18n support (English, Portuguese, Spanish) with a single environment variable switch. The system defaults to English but can serve Latin American or European markets without code changes. Day 7-8: Hardening for Production A demo that crashes during judging is worse than no demo at all. I spent two full days on resilience: Security: API key authentication (X-API-Key header) on all protected endpoints File upload hardening: 10MB size limit, MIME type validation, magic byte verification to prevent extension spoofing PII redaction in logs (names, emails, CPF numbers) Observability: Structured logging with request_id and correlation_id on every log line Graph node duration tracking (duration_ms) Prometheus-format /metrics endpoint (claims_submitted, claims_approved, claims_rejected, avg_processing_time) Request ID middleware echoing X-Request-ID, X-Correlation-ID, and X-Response-Time-Ms on responses Testing: 115+ tests passing across graph nodes, vision service, weather tool, storage backends, review API, authentication, file validation, and observability 82% code coverage End-to-end test of the full submit → process → review → decision flow Day 9: Infrastructure and CI/CD Docker: Multi-stage Dockerfile with non-root user, plus docker-compose.yml for one-command deployment (backend + frontend + PostgreSQL). GitHub Actions CI: Automated lint (ruff), test (pytest with coverage), and build verification on every push. The CI badge in the README proves code quality is continuously enforced. PostgreSQL: Alembic migrations with async SQLAlchemy. The system defaults to in-memory storage for demos but switches to PostgreSQL persistence by setting a single DATABASE_URL environment variable. Day 10: Demo, Document, Deliver The final day was about making everything accessible and verifiable: Architecture diagram (Mermaid.js) showing all four layers and data flows Alibaba Cloud proof with console screenshots proving real DashScope API usage 3-minute demo video showing the full pipeline detecting a fraudulent claim Comprehensive README with setup instructions, architecture overview, and API documentation What I Learned in 10 Days Orchestration > Prompting. The value isn't in a single clever prompt — it's in how you chain multiple AI calls with deterministic routing and error handling. LangGraph's state machine was essential for this. Multimodal cross-validation is the killer feature. Text-only fraud detection misses obvious visual inconsistencies. Qwen-VL's ability to analyze images AND compare them against text claims is what makes Claimflow genuinely useful. Fail-closed is non-negotiable. In any system handling real money, "I couldn't verify this" must mean "escalate to human," not "approve anyway." This single design decision separates production systems from prototypes. Transparency builds trust. Showing the analyst WHY the AI flagged something (with evidence) is more important than the flag itself. Black-box AI doesn't get adopted in enterprise — explainable AI does. 10 days is enough — if you architect first. The two days spent on architecture before writing code saved me from at least three major refactors. Design documents are force multipliers in sprints.
Log in or sign up for Devpost to join the conversation.