Dear friends,

The key idea of agentic coding loops is to have an agent keep working until it satisfies a condition, such as achieving a product specification. Coming up with the spec, the evals, or test set is one of the hardest tasks for many AI systems, and a key place to inject human knowledge. Once you have a clear spec, the paths to fulfilling it (such as having a coding agent iterate) become clearer. I'd like to share useful practices for building product specs that drive coding loops when quickly building 0-to-1 applications. As I'll explain below, one organizing principle I use is: AI tokens are cheap; human tokens are gold. (Yes, I know humans don't literally tokenize, but I work so much with tokens that I now think of myself as providing tokens to my computers!)

When building a large, complex system, it is worthwhile to spend time architecting it well. This involves deciding, for example, what database do you want to use? How do you break down the workload across different services? What third-party dependencies are you locking yourself into? What are the API boundaries between frontend and backend? Thinking through such questions in advance helps to avoid being stuck with a bad decision that is hard to change.

But when building quick 0-to-1 prototypes or applications in domains I'm unfamiliar with, I often move faster and with less deliberation. I find it convenient to jump quickly into directing a coding agent to start building, so I can examine what it has built in order to make the next set of decisions. No need to spend an hour of human time mulling over a design spec when an AI agent will spend 20 minutes building a simple prototype; I'd rather spend 10 minutes writing an inferior spec, see what the agent has built, examine its assumptions, and then refine the spec and repeat the process. Instead of "spec drive development" becoming a new waterfall process where writing a spec is a gate to further progress, this allows me to more iteratively refine the spec.

For example, the first version of many apps I’ve prototyped had confusing UI designs that I modified the spec to fix, and no amount of my time spent tweaking the initial spec would have led me to realize in advance that these changes would be needed. Coming up with those human tokens on my own would have been too expensive. It was easier (and cheaper) to see what went wrong in order to explain how to do it right.

As a software project matures, coding agents will work longer (maybe hours) to build to more complex specs, But at this early stage, it is fine to throw away the entire codebase and restart from scratch, so nothing is hard to change. All that code was cheap, in human time and token costs. What we learned from testing it was more valuable.

Further, having one implementation to react to (or sometimes I'll ask the agent for a few different designs) gives you an efficient way to get feedback (human tokens) to refine the spec to help drive later iterations. If you're building a 0-to-1 product, I encourage you to put the coding agent to work, maybe even earlier than might feel comfortable, see what it comes up with, and use that as a starting point. Then document your reactions and keep iterating.  

Here, too, you can make the agent do most of the work. One common source of frustration among developers is when we tell a coding agent something and later (maybe after memory compaction) it forgets what had said. I hope future coding harness improvements will ameliorate this, but for now, when I make key decisions, I often steer the agent to remember that decision somewhere, say in a SPEC.md file. In the course of building a project, a coding agent may generate millions of tokens — far more than the human developer would type. So if an agent discovers something and later forgets it, there is a cost, since it might burn more tokens to rediscover it — but this is not too bad. But if it forgets something that you told it, that is much more frustrating, since you end up having to tell it again: more golden tokens down the drain.

Coding agents have become less forgetful in the last few months because of model advances, but they still occasionally forget. When I spot something in a prototype that I'm unsatisfied with, often I tell the agent not only to fix it but also to update the spec (and perhaps the test plan), so the agent’s stopping criteria in the future require checking that this problem does not occur again.  This is one way to make sure it treats the human tokens as gold.

Keep building!

Andrew 

A MESSAGE FROM DEEPLEARNING.AI

Meet Ambient, from Kian Katanforoosh and Workera, designed to measure your skills in the flow of work. You already measure everything that matters: sleep, steps, screen time. Why not your skills? Join Waitlist

News

Fable’s Return and Fallout

Claude Fable 5 and the more powerful Claude Mythos 5 are back, three weeks after Anthropic suspended the models due to an export control directive from the U.S. Department of Commerce.

What’s new: Anthropic restored customer access to Claude Fable 5 via the Claude API, Claude Code, and other Anthropic-controlled platforms on July 1. As part of its agreement with the U.S. government, Anthropic added additional guardrails to the model blocking some cybersecurity queries and routing them to the less capable Claude Opus 4.8.

What happened: The redeployment of Claude Fable 5 and Mythos 5 brings a resolution to the most high-profile conflict between the U.S. government and an AI company so far this year. However, the dispute didn’t only involve Anthropic, but also Amazon, Google, Microsoft, and OpenAI. (Disclosure: Andrew serves on Amazon’s board.) Here’s a timeline of when the models were released and why they were suspended and reinstated.

• Anthropic debuted Claude Mythos Preview for select government and tech partners in April. The model was released only to companies that maintain critical infrastructure to allow them to identify security vulnerabilities and patch them.
• Two months later, on June 9, Anthropic released Claude Fable 5 to customers worldwide. Its guardrails prevented certain queries related to cybersecurity and biological research; the model also controversially degraded its responses about how to build powerful AI models.
• Amazon researchers used Claude Fable 5 to obtain information about how to conduct a cyberattack, which led to the directive. Anthropic contends that any sufficiently capable model, including its own Claude Opus 4.8 and those from other providers, could identify the same vulnerability and produce an exploit.
• On June 12, the U.S. government issued an export control directive to suspend access to Claude Fable 5 and Mythos 5 to any foreign national, regardless of where they lived, citing national security concerns. The same day, Anthropic disabled access to the models for all users worldwide.
• The U.S. government told Anthropic on June 26 it could redeploy Claude Mythos 5 for select government organizations. In a letter to the company, Commerce Secretary Howard Lutnick said the weeks of negotiations with Anthropic had yielded “significant progress” and that the AI developer was committed to working with the government to protocols and standards for security assessments of AI models.
• The export controls for Claude Mythos 5 and Fable 5 were lifted on June 30 after Anthropic implemented new safety guardrails to address the cybersecurity risk the Amazon researchers had identified. The company announced Claude Fable 5 would be available to users globally beginning July 1. Access for AWS, Google Cloud, and Microsoft Foundry customers followed soon after.
• Days after Claude Fable 5’s return, some users reported that the model’s performance had degraded since its earlier release, with basic questions in the biological sciences censored and coding tasks more restricted. Anthropic said in an X post that some routine coding tasks would fall back to Opus 4.8, but the company will try in the coming weeks to “better distinguish genuine misuse from legitimate requests.”
• Other users complained that the model would soon only be available for 50 percent of a subscriber’s usage credits and users would have to pay per credit for more access. Anthropic eventually extended paid subscribers’ full Claude Fable 5 access through July 12.

Behind the news: In an earlier high-stakes dispute in February, the Pentagon labeled Anthropic a “supply-chain risk” after the AI developer declined to provide the U.S. government a version of its model without guardrails preventing its use for mass surveillance or autonomous weapons. The consequential designation meant the Defense Department and its partners could no longer use Anthropic’s products. However, the export control order in June was the first time a government intervention led to the suspension of general access to a model. OpenAI’s recent launch of three new powerful models in the GPT-5.6 family were also preceded by a government-mandated preview of the technology’s capabilities before their wider release in July.

Why it matters: The U.S. government's review of Anthropic and OpenAI's top-tier models marks a pivotal moment for the AI industry, one that will likely influence future model releases. The export ban signals governments’ growing willingness to scrutinize the capabilities of the most advanced AI systems before they are widely deployed, raising questions about how models should be rolled out and who should have access. It could also impact how nations can maintain technological leadership. Nations that see the U.S. government limit access to top models have strong incentive to develop frontier models of their own, or turn to less restrictive partners, to protect their AI sovereignty.

We’re thinking: If a government decides to intervene in the rollout of AI models — which we question the wisdom of given the risk of regulatory capture leading to a small number of models passing through — it should at least be via a predictable process. Companies need to know what standards they are expected to meet to bring their products to market. Any framework for governing model releases needs to be fair, stable, transparent, and reasonably permissive to reduce uncertainty, encourage investment, and avoid ad hoc decisions that can delay innovation and erode public trust.

Google Pairs Nano Banana Update With Video API

Google built a low-cost, high-throughput pipeline for developers working with media, combining Gemini’s fastest image model yet with a similarly speedy multimodal model that can turn images into video with synchronized sound.

What's new: Google released Nano Banana 2 Lite (formally Gemini 3.1 Flash Lite Image), the company’s fastest and lowest-cost image model, intended as a replacement for the original Nano Banana. The company also made its latest video model, Gemini Omni Flash, available to developers through its API platforms, six weeks after it first reached consumers via Google apps. Google's announcement bills the pair as a potential double feature, allowing users to generate an inexpensive still image (or a hundred) with the image model, then turn the best one into video through the same conversational interface.

• Input/output: Nano Banana 2 Lite – text and image input to image (1k max resolution) and text output. Gemini Omni Flash – text, image, and video input to 720p video with synchronized audio output, up to 10 seconds per clip
• Availability: Both models are available through the Gemini API, Google AI Studio, and the Gemini Enterprise Agent Platform, plus the Gemini app and Google Flow. Nano Banana 2 Lite also available via AI Mode in Search, NotebookLM, Google Photos, Stitch, and Google Ads; Gemini Omni Flash also via YouTube Shorts
• Price: Nano Banana 2 Lite $0.034 per 1K-resolution image; Gemini Omni Flash $0.10 per second of 720p video
• Performance: Nano Banana 2 Lite – fifth place in Elo on Image Arena; Gemini Omni Flash – first in Elo for video generation on Video Arena (second for editing)
• Speed: Nano Banana 2 Lite generates an image in about four seconds; Gemini Omni Flash generation times undisclosed
• Undisclosed: Parameter counts and training data for both models

How it works: Google published a model card for each release, giving the base architecture and known limits but withholding parameter counts and training-data specifics.

• Nano Banana 2 Lite is a multimodal transformer trained on text and images that runs on Gemini 3.1 Flash-Lite, Google's cost-efficient multimodal base mode. Gemini Omni Flash is a multimodal transformer trained on text, image, audio, and video.
• Gemini Omni Flash returns a 720p clip with native audio from a text prompt, a starting image, or reference images. Its editing is conversational: when processed through Google’s Interactions API, the model keeps session history so each instruction revises the prior clip rather than regenerating it, for up to three sequential edits.
• The image-to-video mode is how the two work together: through the same Gemini API (or conversationally in the Google AI Studio web interface), a Nano Banana 2 Lite image can be passed to Gemini Omni Flash as a starting frame.

Performance: Google reports favorable human-rater results for both models, and both place near the top of Arena.ai's crowd-voted boards. Most of Google's figures come from its own comparisons on internal benchmarks, so independent confirmation is still limited.

• On text-to-image, Nano Banana 2 Lite ranks fifth on Arena.ai's crowd-voted board at 1,250 Elo, edging out the pricier Nano Banana Pro (1,245 Elo) despite costing 10 cents less per 1k image; OpenAI's GPT-Image-2 leads the board at 1,386 Elo.
• On video, Gemini Omni Flash leads generation at 1,527 Elo and ranks second on the video-edit board at 1,347 Elo, just behind ByteDance's Seedance 2.0 (1,377 Elo).
• In Google's own human-rater comparisons, Gemini Omni Flash took first for overall preference and instruction-following on video editing (504 examples) and on Meta's public MovieGenBench (1,003 prompts), and tied for first with Grok-Imagine-Video and Kling on VBench I2V (355 image-text pairs).

Behind the news: Google’s popular "Nano Banana" moniker began as a placeholder codename before the original model, Gemini 2.5 Flash Image, went live in August 2025. Google has extended the family with qualifiers since — Nano Banana Pro in November 2025, Nano Banana 2 in February 2026 — and now Nano Banana 2 Lite. Gemini Omni Flash first appeared at Google I/O on May 19, available only to Gemini app subscribers, Google Flow, and on YouTube Shorts.

Why it matters: Media generation is now cheap and fast enough to run inside an app at runtime, rather than as a slow, curated production step, marking a shift in its unit economics. Ten-second clips can be chained into longer pieces, and developers can now automate those generations directly within their own apps. Among other use cases, this meets the needs of high-volume digital advertisers and social media producers. Meta, for example, is reportedly building a system to generate ad creative, including video, from a product image and a budget. 

We're thinking: It’s a mistake to treat image and video generation as just one market. Nano Banana 2 Lite and Gemini Omni Flash aren’t high-resolution enough to work for Hollywood, and their speed and cost improvements might not add up to much to hobbyist users. But just as we’ve seen with text and audio, there’s more value to unlock with multimedia by adding automation, interaction, personalization, and agentic workflows. This is a good time to unleash your imagination!

DeepSeek’s DSpark Gains Velocity

DeepSeek built a speculative decoding module that speeds up its production models’ text generation by more than 50 percent without sacrificing accuracy, then made its technique open source.

What’s new: Xin Cheng and colleagues at Peking University and DeepSeek introduced DSpark, a speculative decoding method in which a small model (called a draft module) generates tokens for a large language model to verify in a single pass. The team applied DSpark to their DeepSeek-V4 models and later released the checkpoints DeepSeek-V4-Pro-DSpark and DeepSeek-V4-Flash-DSpark, which add the draft modules to unchanged preview weights of DeepSeek-V4-Pro and DeepSeek-V4-Flash. The modified DeepSeek models are free to download from Hugging Face under a commercially permissive MIT license.

Key insight: In speculative decoding — the technique DSpark builds on — a small draft module proposes a block of tokens and the large model it serves checks the whole block in one pass. That pass computes the large model’s own next-token choice at every drafted position simultaneously, so it keeps the longest run of drafted tokens that match those choices. This speeds up text generation while the verification step maintains text quality. The authors identify three components that affect speed: the cost of drafting tokens, how many drafted tokens survive the check, and how much checking the large model does. Earlier drafters traded the first two against each other and left the third fixed regardless of server load. DSpark works on all three, but its main contribution is adjusting the third dynamically, verifying more under light server loads and less under heavy server loads.

How it works: A DSpark draft module attaches to the larger target model, which stays frozen. DeepSeek trained only three parts of the module: a drafting backbone, a small sequential component, and a confidence head, since the module borrows the target’s embedding layer and output head. In offline experiments, the team fed prompts from Open-PerfectBlend, an open dataset, to the target model and trained the drafter on the target model’s responses. Training pushed the drafter to match the target model’s token probability distribution and taught the confidence head to estimate each token’s odds of acceptance.

• The authors adopted DSpark’s backbone from DFlash, an earlier drafter from another team. Like DFlash, DSpark proposes tokens for every position in a block in a single pass. One pass costs the same, however long the block, so a parallel drafter can afford more layers than a token-by-token drafter, making its early guesses stronger. But because the drafter predicts each position independently, it can mix and match across valid continuations; in the authors’ example, where the context could continue “of course” or “no problem,” it may splice together “of problem”. Accuracy falls sharply toward the end of a block, wasting computation.
• To address this, the authors added a sequential component, a compact lookup the authors call a Markov head, which adjusts each position’s token probabilities based only on the token drafted just before it. For example, after the drafter picks “of,” the odds shift toward “course” and away from “problem.” The step runs token by token but is so small that lengthening drafts from 4 tokens to 16 tokens only adds 0.2 to 1.3 percent to each round’s latency compared to the unmodified DFlash backbone.
• For each drafted token, a confidence head estimates the probability that the token will survive verification given that all earlier tokens in the block survived. Such estimates run overconfident, and choosing how many tokens to verify requires their true magnitudes rather than a mere ranking of stronger and weaker tokens. The authors added a calibration step that rescales the estimates, position by position, until chains of them match acceptance rates observed on held-out data.
• At serving time, a scheduler multiplies the per-token confidence estimates together, since a draft survives to a given length only if every token before it survives, yielding a survival probability for each possible draft length. The scheduler then sets each request’s verification length to maximize expected total output across users, consulting a profile of the system’s speed at each load level, measured once at startup. Under light traffic, it verifies long drafts to cut waiting times; under heavy traffic, it drops drafted tokens with low odds of acceptance to free capacity for other users.

Results: DeepSeek evaluated DSpark offline against its own retrained versions of earlier drafters on open-weights models and in production against its previous serving setup. In all cases, DSpark outperformed competing draft modules.

• DSpark raised the average number of tokens accepted per verification round, a measure of draft quality. Compared to the sequential drafter EAGLE-3, it gained 30.9 percent, 26.7 percent, and 30.0 percent on Qwen3-4B, Qwen3-8B, and Qwen3-14B, respectively. Compared to the parallel drafter DFlash, it gained 16.3 percent, 18.4 percent, and 18.3 percent on the same models. The gains held on Gemma4-12B, a model family separate from Qwen3, which suggests the advantage isn’t specific to one lineage.
• In production, DSpark made DeepSeek-V4-Flash generate tokens for each user 60 percent to 85 percent faster and DeepSeek-V4-Pro 57 percent to 78 percent faster than they did with DeepSeek’s previous production drafter, MTP-1, which proposed one token per cycle.
• DeepSeek compared DSpark to its existing draft module at different hardware speeds. At 80 tokens per second per user for DeepSeek-V4-Flash and 35 tokens per second per user for DeepSeek-V4-Pro, DSpark raised the total tokens generated per second across all users by 51 percent and 52 percent, respectively. At 120 tokens guaranteed per second per user and 50 tokens per second per user for the respective models, gains reached 661 percent and 406 percent. Practically, this amounts to 60 to 85 percent boost in per user generation speeds. DeepSeek’s old drafter nearly failed at the higher speeds, so the authors read the figures as marking new feasible operating points rather than just speedups.

Behind the news: Authors at Google Research first described speculative decoding in 2022. The technique has since become common in production serving, and designs for token-drafting modules have multiplied. Early drafters were sequential, generating draft tokens one at a time: EAGLE-3, the drafter DSpark was compared against, works this way, using features from several layers of the target model to predict each new token. Parallel drafters then broke the sequential bottleneck by drafting an entire block of tokens at once: DFlash, which supplies DSpark’s backbone, does so with a small diffusion model. Its authors reported up to 2.5 times the speedup of EAGLE-3, and Nvidia said it boosted inference up to 15 times on the company’s Blackwell GPUs. DSpark keeps the parallel speed of drafters and the coherence of sequential drafters. DeepSeek’s used a simple sequential drafter since DeepSeek-V3 until DSpark, combining the advantages of sequential and parallel drafters, replaced it two weeks after the DeepSeek-V4 preview launched.

Why it matters: Every token a deployed model outputs costs its provider money and makes the user wait, both of which limit what developers can build. Common remedies like using smaller or quantized models sacrifice accuracy. DSpark cuts cost and time without touching model weights or degrading output: On net, the gain converts into cheaper tokens and faster responses.

We’re thinking: DeepSeek made its name by training strong models inexpensively and sharing techniques like reinforcement-learning-based reasoning models through open papers. We’re glad that it’s also optimizing model serving and sharing the results and code for anyone to use.

Text Without Typing

Imagine you are typing a sentence. But instead of a keyboard, joystick, or eye tracker, a device surrounding your head reads your intentions and generates that sentence on screen

What’s new: Researchers presented Brain2Qwerty v2, an updated version of their previous system that can translate brain waves into text. The team included contributors at Meta, French National Centre for Scientific Research, Hospital Foundation Adolphe de Rothschild, Basque Center on Cognition, Brain and Language, Paris Cité University, and the French Institute for Research in Computer Science and Automation.

How it works: Brain2Qwerty v2 first (i) breaks brain activity into characters using an encoder, then (ii) converts character embeddings into word embeddings using a model the authors call an aligner, and finally (iii) corrects those words using a fine-tuned language model (Qwen3-4B). To train the system, the authors recorded the brain activity of 9 subjects typing sentences in English, totaling 90 hours or 22 thousand examples. They recorded it using a magnetoencephalography (MEG) machine, a non-invasive device that records a brain's magnetic activity.

• Given a recording of brain activity, an encoder composed of a convolutional neural network (CNN) followed by a CNN/transformer hybrid called a conformer generates character embeddings and classifies brain activity into characters. The encoder learned by minimizing the difference between generated and actual sequences of characters.
• Given the character embeddings, the aligner used a vanilla neural network to re-embed them. The aligner grouped these embeddings by word (as predicted by spaces in the generated sequences of characters) and averaged across words to produce word embeddings. The aligner learned to increase the similarity of the word embedding to the Qwen3 embedding of the ground truth word (if the generated word was correct) and decrease its similarity with the embeddings of other words.
• Given the character sequence and the word embeddings, a fine-tuned Qwen3-4B corrected the sequence. The authors fine-tuned Qwen3-4B for each subject with a LoRA adapter to generate the correct sentence, and averaged the adapters over all subjects.

Results: Brain2Qwerty v2 outperformed its predecessor. The authors also observed that increasing the training data increased the system’s performance on their dataset.

• Brain2Qwerty v2 achieved a 39 percent word error rate (percent of words guessed wrong), whereas v1 achieved a 43 percent word error rate.
• As the amount of data increased, the character error rate (percent of characters guessed wrong) of the system’s encoder decreased. For instance, at 20 hours of training data, their encoder achieved roughly 50 percent character error rate, while at 90 hours, it achieved roughly 25 percent character error rate. The authors did not observe a plateau in performance before running out of data.
• Comparing per-subject performance, training the system on each subject individually performed significantly worse than the authors’ method. For instance, for the median performance across the nine subjects, training on just that individual achieved a word error rate of 66.5 percent, while training with their combined method achieved a word error rate of 47.8 percent.

Behind the news: The first Brain2Qwerty research program compared MEG recordings with EEG (electroencephalography), finding that MEG readings enabled more accurate predictions of text. Brain2Qwerty v2 was MEG-only, updated the architecture, and used more training data than v1. The researchers also open sourced the training code for both versions, and released the data for v1.

Why it matters: It’s unsurprising that increasing data improves performance. But it may come as a surprise that training across multiple subjects’ brain activities improves performance, even compared to training on a single individual. After all, historically in brain-computer prostheses, models are often trained for a single user. Building a system that can interpret any individual's unique brain activity, learn common patterns, and continue to improve with data suggests that models recognizing text from brain waves should be able to improve performance with more data from more subjects, much like LLMs have improved with more data over the last few years.

We're thinking: Invasive procedures like surgically planting electrodes in the brain have enabled previous patients to communicate with error rates in the single digits. While the numbers the authors report don’t yet match those of these procedures, every percent down represents progress towards a future where patients don’t need to take the risk to get brain surgery.