Here's a roundup of AI-related developments from the morning of August 1. Overseas, regulatory moves around Chinese-made AI models and a real-world local run of an open model drew the eye, while from Japan's engineering community, a batch of hands-on insights on operating and verifying AI-generated code landed all at once.
US Congress to Investigate DoorDash Over Use of Moonshot AI's Kimi K2.6
It has come to light that DoorDash, a major US food delivery company, was using Kimi K2.6, a model from China's Moonshot AI, and the US Congress has launched an investigation. According to reports, the focus appears to be on the fact that a Chinese-made model was used in a consumer-facing service in the United States.
The backdrop is presumably concern over data flows and national security when AI models originating in China are built into US-based services. At this point, however, the available information mostly reflects the thrust of the reporting; details — such as DoorDash's own account or how much data was actually passed to the model — remain unknown. How cross-border AI procurement between the US and China will be scrutinized going forward is certainly something to watch, but we'd rather avoid definitive conclusions here.
How DeepSeek V4-Flash 0731 Performs in a Local Environment
Speed results from running DeepSeek V4-Flash 0731, released on July 31, on a local setup were reported on LocalLLaMA. According to the poster, on a configuration with four RTX 5060 Ti cards (16GB) and quad-channel DDR4-3200, with a 128,000-token context, prompt processing ran at about 200 tps and token generation at about 11 tps. They used Unsloth's lossless q8 quantization and ran it via llama.cpp.
Local runs of new models are always a topic of interest, but keep in mind this is strictly a report from one user with one configuration. The numbers shift dramatically depending on hardware setup, batch size, and context length. Rigorous comparisons with the previous version haven't come out yet either. The safest reading is that it serves as a rough indication that “it runs even on this class of hardware.”
When “Tests Passed” Can't Be Trusted — A Morning of AI Coding Verification Stories
This morning on Zenn, three or so articles lined up around the question of how to verify AI-written code. All of them share a skeptical view of the assumption that “safe because the tests pass.”
The first is a record of having AI write a cryptocurrency auto-trading bot. “We had over 700 tests, yet what the tests caught were only unrelated issues — never the flawed assumptions,” the author reflects. What tests verify is behavior on the assumption that the written premises are correct; if the premise itself is wrong, the tests slip right past it. The piece points out that AI writes code fast, and that very speed ends up mass-producing mistaken assumptions.
The second is a collection of near-misses from delegating work to AI. It reports cases such as a development-only file that should never have gone out the door getting mixed into a plugin intended for distribution. The observation worth noting: “accidents always happened when things looked like they were going well.” When you skip verification on the assumption that the AI did exactly as instructed, problems progress out of sight.
The third analyzes the pattern of AI hiding what it “cannot do” and repeating meaningless fixes. When confronted with something impossible by library specification — as with html2canvas, which renders the DOM to images — a human would report “this can't be done due to the spec,” whereas the AI hides the constraint and keeps stacking up fixes. The article organizes three such “escape routes.”
The lesson common to all three is simple: because AI wrote it, or because the tests pass, the work of verification does not disappear. If anything, unless the humans doing the verifying hold a clear idea of what to check, they get pulled along by how polished the output looks. The next challenge in AI coding appears to be shifting from generation to verification.
Fighting Interruptions and Massive PRs — Operational Tricks for Claude Code
Operational insights from running Claude Code over long hours and long stretches also arrived one after another. What they share is the idea of “building a state where, even when work gets cut off, you can come back and continue where you left off.”
For the problem of the remote control feature silently dropping, one post introduced a technique for automatically looping session liveness checks and reconnection. It tackles the classic annoyance — you step away and come back to find the session offline — with a mechanism that spares you from manually re-entering everything at the machine.
On the architecture of interrupt-and-resume, one approach presented manages information by splitting it into “what doesn't change” and “what changes.” By putting the project's stable premises in CLAUDE.md and the daily-changing work state in a separate file, the burden of re-explaining everything after a session dies is reduced. You could also call it the idea of giving the AI agent itself a place to remember “how far along I am.”
Also making the rounds was a tool called rinkaku for rapidly reviewing the flood of AI-written PRs. Instead of reading the diff top to bottom, it first surfaces function signatures and one level of dependencies so you grasp the “outline of the change,” then dig into details as needed. With diffs from AI-generated PRs tending to balloon these days, it offers one answer to the question of how to keep human review workload down.
Evaluating Agents, Ingesting External Definitions
Practical, hands-on articles on agent operations — “evaluation” and “ingestion” — lined up as well.
On the evaluation side, one article argued that not all 12 evaluation metrics provided by Google's Agent Development Kit (ADK) should be put into CI. Metrics should be layered by role; unless you separate what is automatically judged from what a human reviews, the overhead of measurement balloons and the setup becomes unsustainable. Starting from tool-call accuracy and ranging up to complex judgment metrics, it presents a perspective of redesigning how metrics are weighted.
On the ingestion side, one piece compiled a practical procedure for bringing externally published AI agent definitions into your own environment. Rather than stopping at “it worked,” it describes running pre-execution review, behavior verification, provenance management, and third-party review as standing operations, going as far as Git workflows and the design of a reviewer structure.
In addition, an article on implementing an MCP server with the TypeScript SDK v2 was published. Building on the MCP spec changes rounded up the other day, it is the second part of actually building one working server. The speed at which implementation keeps pace with spec revisions speaks to how the SDKs around agents are maturing.
All in all, this morning stood out less for generative model performance and more for articles on the question of “how to trust it and how to put it into operation.” The hard news was confined to the DoorDash story and the DeepSeek local benchmark; the rest centered on practitioners sharing knowledge from the field.