Everyone's obsessed with getting Kimi to summarize a single article or debug a snippet. That's like using a siege engine to crack a nut. The real leverage is in volume and pattern recognition, something I had to figure out when they dumped three years of startup investment memos on me for due diligence. A hundred-plus documents, all different formats, structures, and levels of technical coherence.
The key is to stop thinking of it as a chat and start treating it as a batch processing job. You need a structured prompt that forces consistency across a wildly inconsistent dataset. Here's the core of my approach. I feed documents one at a time, but each gets the same interrogation.
```markdown
You are a technical due diligence analyst. For the provided startup document, extract the following into a structured JSON summary. If information is absent, state "NOT EXPLICITLY STATED".
1. Core Technology: The primary technical innovation or differentiator.
2. Stated Architecture: Mentioned architectural patterns (e.g., microservices, serverless, monolith).
3. Key Dependencies: Specific third-party services, APIs, or platforms (AWS/Azure/GCP services, Stripe, Twilio, etc.).
4. Scaling Claims: Any specific claims about throughput, latency, or user capacity.
5. Identified Single Points of Failure: Obvious SPOFs from the description (e.g., "single database", "primary orchestrator node").
6. Security Hand-waving: Vague security claims without cited mechanisms (e.g., "secured by blockchain", "military-grade encryption").
```
You run this against every document—pitch deck, technical whitepaper, outdated architecture diagram. The output isn't perfect JSON, but it's close enough to parse. The magic is in aggregation. You then take, say, 50 of these summaries and throw *that* back at Kimi.
"Based on the following 50 JSON summaries, identify the three most common claimed architectural patterns, the five most frequently cited AWS services, and list all startups that made a scaling claim without mentioning a data store."
*That's* when you get the insight. You discover that 70% of "AI-first" startups are leaning on a single managed PostgreSQL instance as their vector store, which is a hilarious bottleneck they've all glossed over. Or that "event-driven" is used to describe everything from a cron job to a Kafka pipeline.
The tool isn't the analysis. It's the forced, consistent extraction from chaos. The analysis is you comparing the extracted facets across the whole set. It catches the buzzword-to-substance ratio. Saves you from having to read the hundredth claim about "cloud-native scalability" backed by a diagram showing a single load balancer and two app servers.