Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

The result, up front

Apple's new SpeechAnalyzer is the most accurate on-device speech engine we tested. It beat every Whisper model we ship, including Whisper Small, on both the clean and the noisy half of LibriSpeech, while running roughly three times faster than Small. And the API it replaces, SFSpeechRecognizer, came last on clean speech: behind even Whisper Tiny, a 40MB model.

Lower is better: WER is word error rate, the percentage of words an engine substitutes, drops, or invents. LibriSpeech test-clean is 2,620 utterances of clean read speech; test-other is 2,939 harder, noisier utterances. Every engine ran fully on-device on an Apple M2 Pro (32GB, macOS 26.5.1).

Why we ran this

With iOS 26 and macOS 26, Apple replaced SFSpeechRecognizer with a new API, SpeechAnalyzer and SpeechTranscriber. It published no accuracy figures for either one. So every developer deciding whether to migrate, and everyone comparing Apple's built-in recognition against Whisper, has been guessing.

We ship both Apple engines and three Whisper models side by side in Inscribe, a private on-device AI workspace, which puts us in an unusual position: we can run all five through identical production code paths on the same machine and the same audio. So we did.

Should you migrate off SFSpeechRecognizer?

Yes. This is the clearest result in the data. The new API cuts word error rate by 3.5 to 4x on the same audio: from 9.02% to 2.12% on clean speech, and from 16.25% to 4.56% on noisy speech. There is no accuracy trade-off to weigh; the new API wins everywhere we measured, and it produces punctuated, cased text where the legacy engine's output is rougher.

Put differently: an hour-long meeting transcribed with the legacy API contains roughly four times as many wrong words as the same meeting through SpeechAnalyzer. If your app still uses SFSpeechRecognizer for anything longer than a voice command, the migration is worth it on accuracy alone.

SpeechAnalyzer vs Whisper

The more surprising result: Apple's new engine also beat Whisper Small, the largest model we ship, by a comfortable margin on both splits, at roughly a third of Whisper Small's compute time per second of audio. For English, on Apple hardware, the built-in engine is now the strongest on-device option we can measure.

Whisper keeps two real advantages. It covers far more languages (SpeechTranscriber supports around 30 locales), and it runs anywhere, not just on Apple platforms with OS 26. But for English transcription on a current iPhone or Mac, the days of Whisper being the automatic accuracy pick are over.

We changed our own product on this result: Inscribe's Auto engine now prefers SpeechAnalyzer for the languages it supports, and Whisper for everything else. Shipping a benchmark and ignoring it in your own defaults would be a strange kind of honesty.

Speed

All five engines ran comfortably faster than real time: between roughly 12x and 40x on the M2 Pro, meaning an hour of audio transcribes in about 1.5 to 5 minutes on-device. SpeechAnalyzer was about 3x faster than Whisper Small per second of audio while beating it on accuracy. We are deliberately not printing a precise per-engine timing table yet: the accuracy runs shared the machine with a development workload, which does not affect WER but does add noise to timing. We will update this page with timings from a dedicated idle run.

Methodology, and why you can check it

A benchmark from a company that sells one of the engines should be treated with suspicion. Ours has two properties designed for that suspicion.

The Whisper column is reproducible against OpenAI's own numbers

We used LibriSpeech precisely because OpenAI published Whisper's WER on it. If our harness measured Whisper correctly, our numbers should land on theirs. They do, on all six measurements:

The small, consistent positive offset (a slightly stricter text normalizer plus CoreML quantization) is what honest reproduction looks like; random error would scatter in both directions. Since the same corpus, normalizer, and scorer produced the Apple columns, the numbers nobody else can check inherit the validation from the numbers anyone can.

The raw transcripts are public

Every per-utterance hypothesis for both Apple engines is downloadable below, next to the reference text and per-utterance WER. Disagree with our normalization? Rescore it yourself.

• summary.json - all ten measurements, machine-readable (3KB)
• raw-transcripts-apple.json.gz - SpeechAnalyzer, all 5,559 utterances (620KB)
• raw-transcripts-legacy.json.gz - SFSpeechRecognizer, all 5,559 utterances (620KB)

Details that decide whether a WER number means anything

• Same production code paths. Each engine ran through the exact code Inscribe users get, not a lab harness with different buffering or settings.
• Text normalization. LibriSpeech references are uppercase, unpunctuated, with numbers spelled out; modern engines emit punctuation and digits. Both sides pass through the same normalizer (casing, punctuation, digits-to-words, contractions), mirroring OpenAI's English normalizer. Score raw text and you punish engines for formatting nicely rather than for mishearing.
• Corpus WER, not averaged WER. Total errors divided by total reference words, so short utterances are not over-weighted.
• Fully on-device, verified. SFSpeechRecognizer sends audio to Apple's servers by default. We forced on-device recognition and made the harness refuse to run rather than silently fall back to the cloud, both because a cloud result would invalidate the comparison and because we were not going to upload 5,559 utterances from a privacy product.
• Failures counted, not hidden. An engine returning nothing scores 100% WER for that utterance. It happened once in 27,795 transcriptions (legacy, test-other).

What building this taught us about our own app

The benchmark found a shipping bug in Inscribe. Our Apple-engine file import fed audio to SpeechAnalyzer and closed the input stream, but never called finalizeAndFinishThroughEndOfInput(). Without that call the analyzer never delivers its final results, and the import hangs forever. It had gone unnoticed because our Auto setting preferred Whisper. The fix shipped the same day, and it is part of why we publish the harness details: measuring your own product carefully has a way of finding the things you were not looking for.

Limitations

• English only. LibriSpeech is English read speech. These numbers say nothing about the 100+ languages Whisper supports that SpeechTranscriber does not.
• Read audiobook speech, not meetings. LibriSpeech is the standard, comparable corpus, which is why we started with it. Accented, far-field, and multi-speaker meeting audio is the obvious follow-up.
• One machine. M2 Pro, macOS 26.5.1. Accuracy should transfer across Apple Silicon; speed will vary by chip.
• Whisper via WhisperKit CoreML. Quantized on-device conversions, the same builds Inscribe ships. Reference GPU implementations may differ slightly, which the validation table quantifies.

What this means if you just want good transcription

If you are on a current iPhone or Mac, the best on-device transcription engine for English is already in the operating system, and the private option is no longer the compromise option. Inscribe uses exactly the engines measured here: SpeechAnalyzer where it supports your language, Whisper where it does not, all fully on-device, nothing uploaded. The benchmark is not separate from the product; it is how we decide what the product does.

Full article content is not available for inline reading.

Read the original article →

Adobe just bought the company that made your noisy 4K footage look like it was shot on a cinema camera. On June 25, 2026, Adobe announced a definitive agreement to acquire Topaz Labs, the AI image and video enhancement firm behind Gigapixel, Astra, and Bloom. That single sentence undersells what is actually happening here. This deal is not a feature grab. It is Adobe buying the plumbing that lets serious AI models run on a laptop instead of a server rack, and it reshapes who controls the “clean-up” layer of nearly every professional video and photo pipeline on the planet.

I have spent the past two weeks pulling apart the Adobe Topaz Labs acquisition: the press release, the regulatory language, the pricing history, and the reaction from working editors and photographers who actually depend on this software. What I found is more interesting and more consequential than the headline suggests. So let’s get into it properly, term by term, claim by claim.

What Exactly Did Adobe Just Buy?

Topaz Labs is not a startup in the usual sense. Albert Yang founded the company in 2005, and his son Eric Yang now runs it. Topaz built a profitable, self-funded business without taking venture capital, reportedly serving more than a million customers and generating somewhere around $48 million to $50 million in annual revenue. That bootstrapped history matters, because it explains why the Topaz user base reacted so sharply to the news. This was one of the last major independent players in AI enhancement software, and it built its reputation on staying independent.

The products Adobe is acquiring include Topaz Photo, Topaz Video, Gigapixel, Astra, and Bloom. These tools sharpen, denoise, stabilize, upscale, and restore existing footage and images rather than generating new content from scratch. Topaz also won an Emmy for its production technology, a detail Adobe made sure to mention in its own announcement. Neither company has disclosed the purchase price. The deal is expected to close in the second half of 2026, pending regulatory approval.

Here is the framework I want to introduce, because it explains why this acquisition matters more than a typical bolt-on purchase: the Post-Capture Stack. Think of modern content creation in two layers. The generation layer creates pixels that never existed, the world of Firefly, Midjourney, and Runway. The post-capture layer takes pixels that already exist, whether from a camera or a generative model, and makes them better. Topaz built the most trusted independent post-capture stack in the industry. Adobe just absorbed it.

Why Adobe Needed This Deal Right Now

Adobe is not buying Topaz from a position of strength. The company’s stock has fallen roughly 36% year to date and sits well below its all-time high from last summer. CEO Shantanu Narayen is stepping down after 18 years, staying on as chairman while a special committee runs the search for his successor. CFO Dan Durn also departed, with Steve Day stepping in as interim CFO. Investors are nervous, even though Adobe posted record quarterly revenue and guided fiscal 2026 revenue toward roughly $26 billion. That combination, strong numbers paired with leadership uncertainty, tells you something about the timing. Acquiring Topaz Labs gives Adobe a concrete, easy-to-explain answer to a hard question: can Adobe actually lead in AI, or will nimbler startups eat its lunch? Buying proven technology and folding it into Creative Cloud is a faster answer than building it from zero. This deal follows Adobe’s roughly $2 billion purchase of Semrush earlier this year, and it lands in the middle of an aggressive AI product cycle that includes Firefly Image Model updates, a redesigned color grading workflow in Premiere, and new agentic partnerships across the industry.

The Hybrid Workflow Problem

There is also a real technical driver behind the deal, and it is worth taking seriously. Creators increasingly mix footage they actually shot with footage an AI model generated. When you blend the two, quality mismatches show up immediately. Real footage has grain, lens characteristics, and natural noise. Generated footage often looks too clean or too soft in different ways. Call this gap Enhancement Debt: the quality difference a studio has to pay down before a hybrid shot feels seamless. Topaz’s models exist specifically to pay down that debt, whether the source is a 20-year-old archival tape or a freshly generated Firefly clip. Adobe wants that debt-clearing tool built directly into its own products instead of licensed from a third party.

Neurostream: The Real Prize Inside This Deal

Most coverage of this acquisition leads with the branded apps. I think that misses the point. The technical asset Adobe actually wanted is Neurostream, Topaz’s proprietary inference optimization engine. Neurostream is designed to shrink the memory footprint of large AI models by up to roughly 95%, which allows complex video and image models to run locally on a standard consumer GPU instead of requiring cloud processing. That number deserves its own vocabulary, so I am calling it the Neurostream Compression Ratio: the proportion of a model’s memory demand that gets stripped away while keeping output quality intact. A high compression ratio is what separates a tool you can run on your own desktop from one that only works through a metered cloud subscription. Adobe has spent years pushing customers toward cloud-based, credit-metered AI features. Neurostream hands Adobe the opposite capability: efficient, local, on-device inference. Whether Adobe actually ships that efficiency to customers, or keeps charging cloud-style credits for locally-capable processing is the single most important open question in this whole deal.

What Happens to Existing Topaz Customers?

This is where the article gets less comfortable, and I want to be direct with you. Adobe says Topaz products will keep running as standalone offerings, and that customers can expect continued support and investment. Those are real commitments, but they are commitments made at the moment of signing, not guarantees for the next decade. Topaz itself already moved away from its original lifetime-license promise toward an annual subscription model in recent years, before Adobe ever entered the picture. That history is part of why longtime users responded to this news with real frustration rather than excitement.

I built a small framework to track how acquisitions like this typically unfold, because the pattern repeats across the software industry. Call it the Lock-In Ladder, four rungs a company climbs after it gets acquired by a platform giant.

The Lock-In Ladder, Rung by Rung

Rung one is Partnership. The acquired company’s tools show up inside the platform’s apps, usually billed through the platform’s own credit system, while the original standalone product keeps running untouched. Topaz was already here before the acquisition, with its models available inside Photoshop and Lightroom through Adobe credits.

Rung two is Acquisition. Ownership changes hands. Public statements promise continuity, standalone availability, and unchanged pricing “for now.” This is exactly where the deal sits today.

Rung three is Standalone Sunset. New features, model updates, and top-tier processing power start flowing to the platform version first. The standalone product still works, but it quietly stops getting the newest capabilities.

Rung four is Full Absorption. The standalone brand either disappears or becomes a thin legacy option, and the technology lives on almost entirely inside the parent platform’s subscription.

I am not predicting Adobe will rush Topaz through all four rungs. But every acquisition of this shape follows this ladder eventually, and the pace depends entirely on how much backlash Adobe is willing to absorb from professional editors who built entire workflows around Topaz staying independent.

How This Affects Photographers, Editors, and Studios Right Now

If you use Topaz today, nothing changes immediately. Your license still works. Your plugin still loads inside Premiere, DaVinci Resolve, or Final Cut. The transaction has not even closed yet, and it still needs regulatory clearance. What should change is your planning horizon. If your studio depends on Topaz running as a neutral, cross-platform tool outside any single subscription, treat the next 12 to 18 months as a transition window rather than a stable status quo. Document your current settings and presets now. Watch closely for any announcement about plugin support for non-Adobe editors like DaVinci Resolve, since that is usually the first place platform owners quietly deprioritize investment.

Timeline: What to Watch Through the Rest of 2026

Regulatory review will dominate the next several months. Adobe already faces scrutiny after its March 2026 settlement with the Department of Justice over hidden cancellation fees, a $150 million resolution covering civil penalties and free services. That history means regulators may look harder at whether this deal simply removes Adobe’s most credible independent competitor in high-fidelity enhancement, rather than adding genuine new value for customers. Expect the deal to close sometime in the third or fourth quarter of 2026, assuming no major regulatory objection emerges. Adobe MAX, typically held in October, is the most likely venue for the first real product demonstrations combining Topaz models with Firefly and Premiere.

The Competitive Landscape This Deal Just Reshaped

Adobe is not making this move in a vacuum. Canva has been aggressively expanding its own AI editing suite. Blackmagic Design’s DaVinci Resolve remains the preferred hub for many colorists who relied on Topaz as an external plugin precisely because it stayed neutral. Runway continues pushing generative video forward from the opposite direction: creation rather than enhancement. Even Apple has been quietly building on-device AI processing into its own creative tools. By absorbing Topaz, Adobe removes a supplier that every one of those competitors could plausibly have partnered with or acquired instead. That is the quiet strategic logic here: this deal is as much about denying rivals access to best-in-class enhancement technology as it is about improving Adobe’s own products.

My Predictions for What Happens Next

Based on everything in the public record and the pattern this industry follows, here is where I expect this to land.

First, standalone Topaz apps survive through 2027 largely unchanged, but pricing quietly converges toward Adobe’s credit system by 2028. Second, Neurostream gets a new name inside Adobe’s marketing within a year, most likely folded into the Firefly brand. Third, plugin support for non-Adobe editors like DaVinci Resolve and Final Cut receives noticeably less attention than the Premiere integration, starting within 18 months of closing. Fourth, regulators clear the deal without blocking it, though possibly with minor behavioral commitments around interoperability. Fifth, Adobe ships a genuine hybrid-capture feature inside Premiere by early 2027 that automatically blends real and AI-generated frames, powered directly by Topaz’s restoration models. None of these predictions are guaranteed. But they follow directly from how Adobe has handled every previous acquisition of an independent creative tool, and from the specific language Adobe chose in its own announcement.

Frequently Asked Questions

When will the Adobe Topaz Labs acquisition officially close?

Adobe expects the transaction to close in the second half of 2026, subject to regulatory approval and customary closing conditions. No exact date has been confirmed.

Will Topaz Labs products still work as standalone software?

Yes, for now. Adobe has stated that Topaz Photo, Topaz Video, Gigapixel, Astra, and Bloom will remain available as standalone offerings through the Topaz Labs website after the deal closes.

Does this affect my current Topaz license or subscription?

Not immediately. Existing licenses and subscriptions continue to function as they do today. Long-term pricing and licensing changes have not been announced.

What is Neurostream, and why does it matter?

Neurostream is Topaz’s proprietary technology for running large AI models locally on consumer hardware by dramatically reducing their memory requirements. It matters because it lets Adobe offer advanced AI video and image processing without forcing every task through the cloud.

Will Adobe raise prices on Topaz tools after the acquisition?

Adobe has not announced any pricing changes. Given Adobe’s existing credit-based model for AI features, many professional users expect eventual convergence toward that system, though nothing has been confirmed publicly.

How does this acquisition affect DaVinci Resolve and Final Cut users?

Topaz previously functioned as a neutral plugin across multiple editing platforms. Under Adobe ownership, the incentive to prioritize non-Adobe integrations weakens, and users on competing platforms should watch closely for any reduction in plugin support or feature parity.

Is the deal expected to face antitrust scrutiny?

It is possible. Adobe recently settled a $150 million case with the Department of Justice over unrelated consumer practices, and regulators may examine whether this acquisition removes a key independent competitor in the AI enhancement space.

Today, we are releasing verifiers v1 — an overhaul of our environment stack for the modern era of agentic RL and evals.

We decompose environments into a taskset, a harness, and a runtime.

Run complex agentic tasks like coding and computer use at scale, in any harness.

The decomposition allows you to:

• Create tasksets, either verifiers-native or by re-using other frameworks such as Harbor
• Evaluate and train in any harness (e.g. Codex, mini-SWE-agent) or bring your own
• Run them in different runtimes, e.g. subprocesses, Docker or sandboxes

For example, run Nemotron 3 Ultra on Terminal-Bench 2 under Codex by authoring a simple config and launch it with our CLI.

The central piece is the verifiers-managed interception server which proxies the requests between the harness and the inference server.

It records traces on the fly, which allows for training and rewriting (e.g. to mitigate reward hacks).

These traces are now message DAGs: every message is stored exactly once.

Now, trace sizes are O(n) in turns instead of O(n²), which makes long horizon agentic rollouts feasible, especially for router replay and multimodal data.

Rollouts aren't linear. Compaction and subagents create branches in the graph — and every root→leaf branch is a contiguous, trainable sample.

One trace, N training samples. Long-horizon training past the context window, natively.

verifiers v1 plugs straight into prime-rl for training.

We have been using v1 internally for all our production runs.

In this run, we train GLM-4.5-Air on ScaleSWE tasks with under-4-minute steps and 35-turn rollouts, completing 1K steps in 2 days on just 6 H200 nodes.

Read the full verifiers v1 deep dive: primeintellect.ai/blog/verifiers…

Collections of hundreds of physical 3D cellular bricks, simple modular hardware units that run identical local Neural Cellular Automata without any global knowledge, collaboratively infer their overall shape class.

At Sakana AI, a recurring theme in our research is collective intelligence: the observation that sophisticated, robust behavior can arise from many simple parts following local rules, with no central controller, as it does in a colony, a tissue, or a brain. Until now, we have explored this idea in simulated systems, such as getting several frontier models to reason together and build on one another’s attempts, coordinating them so that many models act as one, or having agents with partial, overlapping views negotiate along their shared boundaries to converge on a globally consistent solution.

Today, we are happy to share that a paper extending this line of work into physical hardware has been accepted for publication in Nature Communications. The system is a collection of simple cubic bricks, each running the same small neural network and communicating only with the bricks it is physically connected to. No brick is told its position or which shape it is part of, yet from these purely local exchanges the collective converges on the correct global shape and can locate where modules are missing or damaged.

For us, this is a first step toward taking our work on collective intelligence beyond software and into the physical world. We wanted to ask whether the same decentralized principles hold up when communication is noisy and modules fail. They largely do. Hundreds of bricks classify a range of 3D shapes, still recognize shapes with variations they were not trained on, and keep converging correctly even when a fraction of their modules go silent. Using the same framework, the collective can also flag structural damage and guide a step-by-step recovery.

The work is a collaboration between researchers at IT University of Copenhagen, Sakana AI, and Autodesk.

Read the full paper in Nature Communications: https://www.doi.org/10.1038/s41467-026-75166-7

Explore the code on GitHub: https://github.com/rmorenoga/cube3D

Introduction

Many biological systems exhibit a remarkable capacity to determine their own anatomical structure. Through local communication and self-organization, groups of cells can assess whether they have correctly formed a target shape, such as an organ, and can actively remodel body parts following injury. A salamander can regenerate a damaged tail that transforms into a functional leg, and simple organisms like Hydra and Planaria can fully restore their morphology regardless of which part is lost. This ability to classify general anatomical features, rather than match a fixed target shape, is what enables variability among individuals while enhancing the robustness of the process. The overall function and design of an organ may be consistent across a species, even as its specific shape, size, or scale differs from one individual to the next.

Artificial systems composed of many physically distributed modules that can autonomously infer their structural class, without centralized control, would represent a significant step toward more adaptable, intelligent artificial collectives. Such systems could enable powerful applications in smart materials and reconfigurable robotics, where global knowledge must emerge from local sensing and communication. Motivated by the scalability and resilience of biological collective intelligence, we introduce a fully decentralized system in which hundreds of physically embodied “cellular” bricks collectively classify their global shape and detect local damage, with no central controller and no module ever knowing its own position.

The collective intelligence algorithm we developed builds on the framework of differentiable Neural Cellular Automata (NCA) and self-classifying collective systems, extended to operate in 3D and implemented on physical modular hardware. NCAs generalize traditional cellular automata, in which the local update rules are typically hand-crafted, by instead learning these rules. Unlike traditional CAs that operate with discrete cell states, NCAs use continuous-valued cell states, enabling end-to-end differentiability and compatibility with gradient descent. On a high level, each cell in our system is tasked with determining which type of shape it is a part of, based solely on communication with its local neighbors and its own memory state. The update rules are parameterized by a deep neural network built from 3D convolutional layers, whose outputs are added to the state of each cell. Here, the collective is tasked to distinguish between objects resembling planes, chairs, cars, tables, houses, guitars, and boats, trained with a cross-entropy loss to predict the class label through gradient-based optimization.

Rather than matching against a single, predefined configuration, our system generalizes across entire classes of shapes, such as different planes or different tables. This shift from precise self-recognition to high-level shape classification enables greater flexibility and tolerance to variation. The system can also detect structural inconsistencies caused by missing or faulty modules, using only local interactions and without requiring any actuation or centralized sensing.

Results

Each cellular brick is a small printed-circuit-board cube with electrical connectors on all six faces, a microcontroller, an LED to display its current class guess, and the electronics to power itself. Bricks stack together into arbitrary objects and communicate purely locally over a custom digital serial protocol, iterating until the collective converges on a single shape label.

We ran large-scale experiments with more than 500 bricks in simulation and almost 200 physical bricks. In simulation the approach reaches 98.97% accuracy. Transferring the simulation-trained NCA directly onto hardware, we built four distinct shapes ranging from 26 bricks (a guitar) to 197 (a round table); the bricks reached correct consensus on a plane, a guitar, a boat, and a table, with 100% success rate across all four. In hardware, the collective converges in fewer than 60 update cycles, about three minutes of real time.

Robustness to faulty cells and shape variation

Biological systems are remarkably robust to damage, noise, and faulty components, thanks to their local, distributed decision-making. To test whether our system inherits this property, we disabled subsets of bricks in hardware, preventing them from sending or receiving messages, and measured the effect on recognition. Most shapes maintained high accuracy at 5% failure rates, and some, like the plane and boat, degraded only minimally even at 15%. The exception is shapes with narrow structural bottlenecks: in the guitar, a single failure along the neck can sever the two halves of the object and disrupt classification.

The system also generalizes beyond the specific examples it saw during training. We designed test shapes with novel variations within known classes: a table modified to have five shortened legs at random positions, a boat with its central bridge shifted off-center, and scaled-down versions of the plane and table. The altered five-legged table was still correctly classified as a table, and the shifted boat bridge did not impair recognition, suggesting the NCA captures abstract structural features rather than overfitting to specific instances. It is not infallible, however: the scaled-down table was misclassified as a chair, likely because the reduced module count compresses the structural cues the network relies on.

Emerged communication strategies

We also looked at how the collective actually solves the task. Inspired by morphogens (the diffusible molecules that form gradients across developing tissues and give cells positional information), we examined the activation patterns of the NCA’s hidden channels. Early in the process, the system often establishes left-right and radial patternings that resemble the developmental axes of embryos.

This also explains how the collective tells tables from chairs. Many cells in a chair are initially classified as a plane, just as in tables. Unlike tables, though, an anterior-posterior patterning is established (akin to the biological head-to-tail axis), and over time this signal propagates from the backrest outward, guiding the cells to a consensus that they form a chair. The default reading for both is “table,” and morphogen-like signals originating in the backrest gradually induce a coherent reclassification.

Damage detection and recovery

An exciting extension is to let each cell not only recognize which larger shape it belongs to, but also detect whether one of its neighboring cells has been damaged. To achieve this, the cells were trained jointly for shape classification and local damage detection, predicting either no damage or damage in one of six spatial directions. Training used synthetically damaged shapes with spherical and cubic lesions. Despite the added task, the system retained 98.9% shape-classification accuracy while detecting damage with an average accuracy of 94.8%.

Can we exploit this to recover from damage, rather than merely predict it? Biological organisms like planarians and axolotls regrow complex body parts through distributed, decentralized cycles of sensing and regeneration, with no central controller. Mirroring this, we started from a small cluster of cells and repeatedly added new cells in the direction indicated by the existing ones, until no more damage was detected. Without ever being trained starting from only a few cells, the model recovered almost all shapes across all object classes with high accuracy. Models with larger hidden states performed significantly better, likely because they can carry more information across the growth process.

Simulation scaling to larger and more complex morphologies

Hardware experiments are naturally limited by the number of available robotic bricks and the practical constraints of physical deployment. We therefore evaluated scaling behavior in simulation, where the approach already works well beyond the morphologies demonstrated in hardware, extending from 15x15x15 to 32x32x32 and 64x64x64 grids. Moreover, the higher-resolution experiments involve substantially richer geometries than those used in hardware, including shapes with hollowness, internal cavities, and assemblies of more than 18,000 cubes. These experiments reveal encouraging scaling behavior: as spatial resolution and structural complexity increase, maintaining high performance requires greater model capacity, but the relationship is predictable and favorable.

Conclusion

These experiments show that learned, fully-decentralized control lets large assemblies of simple, identical modules reach a coherent understanding of their global shape and pinpoint structural faults, using nothing more than short-range communication and on-board computation. In hardware trials with almost 200 bricks, the collective converged on the correct class in fewer than 60 update cycles, about three minutes of real time, and the very same infrastructure and identical per-cube code extends to localizing missing modules and even guiding their regrowth. To our knowledge, this is the first physical realization of large-scale, bio-inspired self-recognition in three dimensions, and a concrete step toward the long-standing goal of modular, self-reconfigurable systems.

For us at Sakana AI, it is also a first step in a broader direction: taking the principles of collective intelligence we have studied in software and letting them emerge, decentralized and robust, in the physical world.

Looking ahead

We are excited about where this leads. In the future, we imagine smart materials that let structures sense and report damage on their own, enabling safer and more resilient architecture, or LEGO-like systems that recognize their own configuration and adapt in real time. Getting there will require active self-repair through actuation, such as magnetically docked milli-scale blocks, along with miniaturized electronics and refined connectors for denser, more organic geometries, and closed-loop growth in which bricks autonomously recruit others from a shared pool.

More broadly, embedding distributed intelligence into the building blocks themselves points toward environments that are robust, adaptive, and regenerative, blurring the boundary between construction and computation. We can imagine many other directions too, from denser cellular collectives to mobile, reconfigurable physical systems.

To learn more, read the full paper in Nature Communications and explore the code on GitHub.

Video Generation Models are General-Purpose Vision Learners

Overview

TL;DR

Pushing computer vision from the task-specific era toward general-purpose visual intelligence — just as NLP evolved from task-specific models into general-purpose language intelligence.

GenCeption repurposes a pre-trained video generative model into a single unified, general-purpose, feed-forward vision model that solves a wide range of vision tasks with SOTA performance — all steered by text instructions, with exceptional learning efficiency and intriguing emergent behaviors.

Visual Generative Pretraining

GenCeption leverages video generation models as representation pretraining, and conducts multi-task post-training in a unified architecture.

Unified & Feed-Forward

GenCeption handles both dense and sparse vision tasks, transforming the multi-step generative backbone into a single-step feed-forward model.

SOTA & Emergent

GenCeption is a SOTA unified model on various vision tasks, with exceptional learning efficiency and intriguing emerging behaviors.

Methodology

GenCeption leverages a video generative diffusion model as a pre-training base to capture rich spatio-temporal world priors and native vision-language alignment at scale. During multi-task post-training, the model is adapted to a feed-forward model fine-tuned on predominantly synthetic data to handle diverse perception tasks. GenCeption shows strong performance on multiple vision tasks with intriguing Emerging Behaviors, enabling seamless sim-to-real transfer and generalization to out-of-distribution object categories.

This highlights a paradigm shift from specialized, task-specific computer vision models toward fully unified, generalist vision models — just as NLP evolved from task-specific models into general-purpose language intelligence.

Results

SOTA performance: GenCeption is competitive with or outperforms state-of-the-art models dedicated to individual tasks (DepthAnything3, D4RT, VGGT-Ω, SAM3, Sapiens, DAVID, Genmo, Lotus-2). Our specialist denotes a model trained on each task individually, whereas the generalist represents a single model trained jointly across multiple tasks.

Data efficiency: under matched fine-tuning data, the video-generative backbone beats alternative pre-training paradigms (V-JEPA, VideoMAE V2), shows preliminary scaling properties, where it improves with larger models and more data, and reaches performance comparable to D4RT and VGGT-Ω with 7× to 500× less training data.

Architecture

Architecture overview of GenCeption, a simple yet powerful architecture adapted from text-to-video diffusion models. Given an input video and a text prompt specifying the desired output, our unified model, trained majorly on synthetic data, is capable of performing a wide range of dense and sparse perception tasks, with a single forward-pass of the model. The dense vision tasks are unified in the RGB ambient space where supervision can be applied in latent space efficiently, and the sparse vision tasks are realized by adding learnable tokens as additional inputs to the diffusion transformer (DiT).

Video Any-Task Capabilities

GenCeption is able to seamlessly switch between different vision tasks, just like how humans do in real life.

Native Vision-Language Alignment

Given a natural-language expression, GenCeption accurately segments the referred object — reasoning about colors, spatial relationships and motion — and generalizes to unseen objects (e.g., a rocket) by leveraging knowledge from text-to-video pre-training.

Understanding the Complex Visual World

As an example of pushing the boundaries of understanding the complex visual world, GenCeption predicts 4D human keypoints under challenging conditions (complex motion, occlusion, ego-centric, multi-view, etc.) — robust 4D human understanding that underpins real-world applications across robotics and AR/VR.

Grounded 4D Reconstruction

From a single video, GenCeption predicts per-pixel geometry and camera pose that lift the scene into a 4D point cloud — enabling free-viewpoint fly-throughs and language grounding of objects from a text instruction.

Emergent Behaviors

Although fine-tuned predominantly on synthetic human videos, GenCeption transfers seamlessly from simulation to real footage and to out-of-distribution categories — evidence of a universal "world model" inside generative video backbones.

• Trained purely on synthetic videos, the model transfers zero-shot to real-world footage — seamless sim-to-real transfer.
• Trained on synthetic single-object videos, the model generalizes zero-shot to real videos with multiple instances.
• Trained only on humans, it generalizes to unseen categories — animals and robots.

Citation

@inproceedings{wang2026genception,
  title     = {Video Generation Models are General-Purpose Vision Learners},
  author    = {Wang, Letian and Zhang, Chuhan and Kabra, Rishabh and Uijlings, Jasper and
               Waslander, Steven and Zisserman, Andrew and Carreira, Joao and He, Kaiming and
               Andriluka, Misha and Bazavan, Eduard Gabriel and Zanfir, Andrei and Sminchisescu, Cristian},
  booktitle = {European Conference on Computer Vision (ECCV)},
  year      = {2026}
}

Long-Horizon Terminal-Bench (LHTB)

 _     _   _ _____ ____
| |   | | | |_   _| __ )
| |   | |_| | | | |  _ \
| |___|  _  | | | | |_) |
|_____|_| |_| |_| |____/
  Long-Horizon Terminal-Bench

Long-Horizon Terminal-Bench is a 46-task benchmark for measuring how well LLM agents sustain useful work in a containerized terminal over hundreds of steps.

Unlike short-horizon coding benchmarks where an agent writes one artifact and stops, LHTB drops the agent into a stateful environment and grades it with hidden, rebuild-from-artifact verifiers — self-reported progress does not count.

Tasks span interactive games & puzzles, multimodal analysis, software / reverse engineering, scientific computing, earth & energy systems, security & performance, research reproduction, and professional APEX-style workflows.

Companion to Terminal-Bench / Terminal-Bench 2.0. Evaluated with Harbor.

Results (July 2026 snapshot)

We evaluated 21 frontier models through one identical Terminus-2 harness (90-minute budget per task). Even the strongest model solves only ~28% of tasks at a strict bar, and the median task is never solved by any model — LHTB is far from saturated.

Leaderboard — mean reward over 46 tasks

Solved = reward ≥ 0.95. Cost = estimated average USD per task at list prices (multiply by 46 for a full-suite estimate). See the live leaderboard for the latest numbers.

Cost vs. reward

Capability does not track price (costs below are per task). Grok 4.5 tops the board at ~$11/task, and cheaper models like MiniMax M3 ($6/task) and Hy3 ($2.47/task) are competitive with models costing 5–10× more (Claude Fable 5 at $73/task, Claude Sonnet 5 at $60/task).

The benchmark is hard

• 29 of 46 tasks are never solved (R ≥ 0.95) by any model.
• Only 17 tasks are solved by at least one model.
• Across all model×task runs, ~55% land at reward < 0.25 — agents get stuck, loop, or quit early well before the budget runs out.

Repository layout

LHTB/
├── tasks/                      # 46 Harbor task definitions (the dataset)
│   ├── langchain-version-migration/
│   ├── document-table-layout-reconstruction/
│   ├── great-expectations-audit/
│   └── ...
├── configs/examples/           # Sample Harbor YAML (no secrets)
│   ├── oracle_smoke.yaml
│   ├── terminus2_openai.yaml
│   ├── terminus2_openrouter.yaml
│   └── full_benchmark.yaml
├── LICENSE
└── README.md

Each task uses the same 5-file Harbor layout as Terminal-Bench 2.0:

<task>/
├── task.toml          # metadata, timeouts, resources
├── instruction.md     # agent-facing prompt
├── environment/       # Dockerfile + assets
├── tests/             # hidden verifier
└── solution/          # reference / oracle solution

Getting started

1. Install Harbor

uv tool install harbor
# or:  pip install harbor

You also need Docker running. Many LHTB images are amd64-only; on Apple Silicon:

export DOCKER_DEFAULT_PLATFORM=linux/amd64

2. Clone this repo

git clone https://github.com/zli12321/LHTB.git
cd LHTB

# Large APEX world zips / videos use Git LFS (>100MB).
git lfs install
git lfs pull

3. Smoke-test with the oracle agent (no API key)

harbor run -c configs/examples/oracle_smoke.yaml

This runs a few reference solutions end-to-end and checks that Docker builds + verifiers work.

4. Run an agent on a few tasks

Put your key in the environment (never in the YAML):

export OPENAI_API_KEY=sk-...          # your key
harbor run -c configs/examples/terminus2_openai.yaml

Or via OpenRouter:

export OPENROUTER_API_KEY=sk-or-v1-...
harbor run -c configs/examples/terminus2_openrouter.yaml

5. Full 46-task benchmark

export OPENAI_API_KEY=sk-...
harbor run -c configs/examples/full_benchmark.yaml

Edit model_name, n_concurrent_trials, and timeouts in the YAML to match your setup. Results land under ./jobs/ (git-ignored).

Sample configs

Security: example YAMLs intentionally omit api_key. Pass credentials through environment variables (OPENAI_API_KEY, OPENROUTER_API_KEY, …). Do not commit real keys.

Task categories (46 tasks)

Blog & paper

• Blog: https://zli12321.github.io/LHTB/
• Leaderboard: https://zli12321.github.io/LHTB/leaderboard.html
• Paper: https://arxiv.org/abs/2607.08964
• Dataset (Hugging Face): https://huggingface.co/datasets/IntelligenceLab/Long-Horizon-Terminal-Bench

Citing LHTB

@misc{li2026longhorizonterminalbenchtestinglimitsagents,
      title={Long-Horizon-Terminal-Bench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading}, 
      author={Zongxia Li and Zhongzhi Li and Yucheng Shi and Ruhan Wang and Junyao Yang and Zhichao Liu and Xiyang Wu and Anhao Li and Yue Yu and Ninghao Liu and Lichao Sun and Haotao Mi and LeoweiLiang},
      year={2026},
      eprint={2607.08964},
      archivePrefix={arXiv},
      primaryClass={cs.AI},
      url={https://arxiv.org/abs/2607.08964}, 
}

Related work

• Terminal-Bench / Terminal-Bench 2.0
• Harbor — evaluation harness used by LHTB

License

Apache License 2.0 — see LICENSE.

Full article content is not available for inline reading.

Read the original article →

AI Gateway Production Index — July 2026

Every month, AI Gateway routes tens of trillions of tokens between production applications and AI labs, giving us a view of what AI usage actually looks like in today’s enterprise. We publish that view here.

July 2026 summary

The July index reports on AI Gateway data collected in June 2026.

• AI Gateway token volume grew 29% month over month and spend grew 27%. The price per token was flat after rising almost 20% in May.
• Open-weight models ran 29% of gateway tokens, up from 11% in April, on under 4% of spend. DeepSeek reached 22.6% of token volume, in third place and less than two points behind Google, and GLM 5.2 broke into the gateway's top models by volume two weeks after release.
• Anthropic took 61% of gateway spend on 32% of tokens, and captured 72% or more of spend in every high-stakes use case.
• Each modality has a different leader. OpenAI's GPT Image generated 53% of images, ahead of Google's Nano Banana at 39%. Chinese labs took two-thirds of video spend, while xAI's Grok Imagine generated 42% of videos, the most of any model.
• Claude Fable 5 was released June 9 and reached 22% of Opus 4.8's request volume in four days. A US export-control directive suspended access for the rest of the month.

AI investment kept climbing, and the average token price went flat

In June, token volume and spend grew at nearly the same rate, 29% and 27%, while the price per token remained steady. The month before, spend had grown more than twice as fast as volume, driving the average token cost up by almost 20%.

The market spent more overall, but not more per token. Since April, open-weight models have climbed from a ninth of all token volume to nearly a third, at about a tenth of the average token price on the gateway. That alone should have pulled the price per token down. But as cheap volume rose in June, so too did closed-weight frontier prices, up about 12% per token. They offset each other, so the average price per token was flat.

This is evidence of the routing discipline June's report documented, now visible in the aggregate: high-volume work goes to low-cost models, high-risk work stays on the frontier. Investment in AI is still growing quickly, and companies are getting more strategic about balancing that spend across models.

Open weight ran nearly a third of production tokens

Open-weight models ran 29% of gateway tokens in June on just under 4% of spend. That is nearly a third of the tokens for one twenty-fifth of the dollars.

Open-weight token share has almost tripled since April. Most of that volume comes from the continued growth of DeepSeek, now the third-largest source of tokens on the gateway at 22.6%, behind Anthropic and Google. Google's share of token volume slipped to 24% as its April surge unwound, leaving DeepSeek within two points of second place.

Roughly one in eight enterprise customers now runs an open-weight model in production. And on current trajectories, an open-weight lab will soon be the second-largest by volume on AI Gateway.

The newest entrant shows the pattern accelerating. Z.ai released GLM 5.2, an MIT-licensed open-weight model aimed at long-horizon agentic work at approximately a fifth of Opus 4.8 pricing. From its June 16 API availability through month end, its daily token volume grew about 50x. It ranked #11 on AI Gateway by tokens in the final week, and as high as #7 on single days. It took 76% of its family's June tokens in barely two weeks. Gemini 3.1 Pro, the fastest in-family migration we had previously charted, took until its second month to reach a similar share.

Frontier labs kept nearly all of the spend

The top four frontier US labs took 95% of AI Gateway spend in June. Anthropic alone took 61% of spend on 32% of tokens, down from 65% in May, but in line with April. It also took 72% or more of spend in the most consequential use cases, where mistakes are costly: coding agents, back-office agents, and app generation.

OpenAI’s token share fell from 12.5% to 10.3% while its spend share rose from 13.3% to 16.1%, driving its cost per token up about 50% relative to the market in one month. In contrast to DeepSeek, customers sent OpenAI less volume but costlier work, a divergence that only shows up in production data.

Each modality has a different leader

Image generation is a two-lab race on AI Gateway. OpenAI's GPT Image family generated 53% of images and took 52% of image spend in June. Google's Nano Banana generated almost 39% of images and took 43% of spend. No other family cleared 5% of either.

Video is the one modality where Chinese labs currently hold the premium tier. ByteDance's Seedance led spend at 49% with only a third of videos generated. xAI's Grok Imagine generated 42% of videos on 19% of spend, the same volume-discount position DeepSeek holds in text. The Chinese labs together, Seedance, Kling, and Alibaba's Wan, took roughly two-thirds of video dollars. The category is early, so we expect these shares to fluctuate.

Anthropic leads text, OpenAI leads images, xAI leads video volume, and ByteDance leads video spend. Running the leading model in every modality requires routing across at least three labs.

US export controls suspended Claude Fable 5 only days after launch

Anthropic released Claude Fable 5 on June 9, and it was adopted rapidly. In only four days, Fable usage rose to 22 requests for every 100 sent to Opus 4.8.

On June 12, a US export-control directive took effect covering Fable 5, and Anthropic suspended access to comply. The model stayed offline for the rest of the month. Controls lifted on June 30 and access resumed July 1.

Also in June's data

• Back-office agents are the most expensive workload per token on the gateway, running 5% of total tokens on 14% of total spend.
• B2B use cases drove 46% of June tokens but 60% of spend; B2C the reverse, at 43% of tokens and 26% of spend.
• Google's volume concentrates in consumer-shaped workloads. It ran 57% of personal-assistant tokens and 54% of education tokens in June, but less than 2% of coding agent tokens.

About this report

This analysis is based on anonymized, aggregate routing data from the Vercel AI Gateway through June 2026.

A few notes on measurement:

• Spend uses market-rate pricing (published list price) to provide a normalized view across teams that bring their own API keys.
• Volume counts tokens routed through AI Gateway.
• B2C, B2B, and use-case classifications are aggregate. No individual team or workload is identified.
• Image and video figures count generated media (successful requests only), not tokens. Image and video models are not billed per token, so shares reflect images and videos produced.
• Open-weight models are measured two ways. Volume and spend shares (the lab-share charts) classify by provider, counting the four labs that serve their own models on the gateway (DeepSeek, MiniMax, Moonshot, Z.ai). This is conservative. The enterprise-adoption figure classifies by model, counting open-weight models regardless of which provider served them, such as Qwen, Gemma, GPT-OSS, and Kimi.

The first public beta of iOS 27 is now available. It works on every iPhone that runs iOS 26, but Apple Intelligence features will require an iPhone 15 Pro or newer. The update is focused on performance, stability, and making the iPhone feel even better to use. The biggest addition is Siri AI, which can now hold an ongoing conversation, understand onscreen context, take actions in apps, and answer broad questions.

The next test flight of SpaceX’s Starship spacecraft and Super Heavy booster could take off as soon as Thursday, and much of the hour-long mission will look a lot like the last Starship flight in May.

But there are a few key differences for this launch, set to occur during a launch window that opens at 5:45 pm CDT (22:45 UTC) on Thursday. The most notable change is the inclusion of real, functioning Starlink satellites inside Starship’s cargo bay. SpaceX previously tested the ship’s payload deployment mechanism using simulators mimicking the mass and dimensions of the company’s next-generation Starlink Version 3 broadband satellites.

This time—Starship’s 13th full-scale test flight and the second to use SpaceX’s newest version of Starship—technicians have installed 20 Starlink V3 satellites into the ship’s deployer, a system of pulleys and cables designed to eject a stack of satellites one at a time through an opening on the side of the spacecraft. The satellites will not be part of SpaceX’s operational network, but engineers will attempt to briefly establish laser communication links between the Starlink V3s and other spacecraft flying in low-Earth orbit. If successful, these links will validate Starlink V3’s interoperability with SpaceX’s previous generation of Starlink satellites.

As with all of SpaceX’s previous Starship test flights, the more than 400-foot-tall rocket will fly on a long suborbital trajectory arcing halfway around the world from the launch site at Starbase, Texas, to a predetermined location in the Indian Ocean. The flight of Starship and the 20 Starlink satellites will last a little more than an hour before they fall back into the atmosphere. The ship will target a controlled splashdown northwest of Australia, while the Starlink satellites will burn up during reentry.

A new ingredient

The flight plan for this week’s mission has just enough time in space for the Starlink satellites to extend their solar arrays and antennas. The satellites will also attempt to connect with ground stations in South Africa as they soar more than 100 miles overhead.

What’s more, some of the Starlink V3s will host cameras to scan Starship’s heat shield and transmit the imagery down to engineers on the ground, according to SpaceX. The imagery will allow ground teams to “continue testing methods of analyzing Starship’s heat shield readiness for return to launch site on future missions,” SpaceX said in a post on its website.

Two of the Starlink mockups carried cameras for external imaging on the last Starship mission, returning views of the ship set against the ghostly darkness of space. This time, SpaceX has affixed cameras to six of the Starlink satellites. The imaging opportunity on this week’s mission will occur during nighttime, just as it did on the last flight.

The presence of Starlink V3s on the next Starship test flight is a harbinger for what’s to come. Fully loaded Starships will be capable of launching up to 60 Starlink V3s on a single flight, unlocking a dramatic expansion of the network’s capacity. Each Falcon 9 launch with V2 satellites adds about 2.6 Tbps to the constellation. Pairing Starship with a full stack of V3 satellites will add 60 Tbps to the network.

Starship is designed to carry other kinds of satellites, too, including customer payloads and massive platforms for SpaceX’s proposed orbital data center network. The rocket is also designed for flights to the Moon and Mars. Starship is a core part of NASA’s Artemis program to land astronauts at the Moon’s south pole. But the first real operational missions for Starship will begin fielding SpaceX’s third-generation Starlink constellation, perhaps later this year if all goes according to plan.

Lessons learned

SpaceX must send Starship into low-Earth orbit before achieving any of these lofty objectives. A near-perfect test flight Thursday would put the company on the cusp of an orbital launch. That, in turn, would allow Starship to move toward several important milestones, such as bona fide satellite launches, in-orbit refueling demos, and the first return of Starship to Starbase, Texas, for future reuse.

One reason SpaceX isn’t attempting an orbital flight this week is Starship’s failure to complete one of its test objectives on the last launch, when the spacecraft was supposed to ignite one of its six Raptor engines for a brief burn in space. The spacecraft skipped the burn after a Raptor engine shut down prematurely during the launch sequence.

The rest of the ship’s flight went according to plan, culminating in a pinpoint splashdown in the Indian Ocean. It was the first flight of SpaceX’s Starship V3 debuting new, more powerful Raptor engines. But officials need confidence in the Raptor engine’s ability to reignite in the airless vacuum of space before proceeding to an orbital flight. In a worst-case scenario, a failed Raptor engine relight would strand Starship in orbit, leaving the enormous stainless steel vehicle to an unguided reentry that could become a risk to public safety.

The flight plan for this week’s mission includes the Raptor restart objective left unaccomplished in May. In an update posted to its website over the weekend, SpaceX did not address what caused the premature shutdown of the Raptor engine on Flight 12.

“The vehicle was able to demonstrate its engine out capability and reach its planned suborbital trajectory,” the company wrote on its website. “Several hardware and operational modifications have been made to address the interconnected causes with additional reliability improvements planned in upcoming versions of the Raptor engine.”

The other goal left incomplete on Starship’s last flight involved the splashdown of the rocket’s Super Heavy booster, or first stage, which lost control moments after separating from the ship, or upper stage, a few minutes after liftoff. SpaceX intended for the booster to fly itself to a water landing in the Gulf of Mexico downrange from its launch base in South Texas.

“At stage separation on Flight 12, slight differences in engine startup on the ship caused the directional flip of the booster to be off by approximately 90 degrees,” SpaceX wrote. “The startup sequence has been modified to be more robust to timing variability and more reliably flip in the desired direction, which is done to increase overall performance.

“After stage separation and the flip, the Super Heavy booster attempted its boostback burn,” SpaceX continued. “Five of its 33 engines experienced issues when attempting to relight causing the boostback burn to end early. The Super Heavy on this upcoming flight has hardware modifications to improve relight reliability along with updates to engine alarms and aborts to match the conditions seen in the multi-engine flight environment.”

SpaceX will also use Flight 13 to continue experimenting with Starship’s heat shield, one of the most daunting technical challenges on the program. If the full rocket is to become rapidly reusable, as SpaceX intends, the heat shield’s thousands of ceramic tiles must not only protect the ship once; they also must be robust enough to handle the extreme heating of reentry over and over again without refurbishment or replacement.

“What’s the single biggest remaining problem for Starship? It’s having the heat shield be reusable,” Musk said in February on the Dwarkesh Podcast. “No one has ever made a reusable orbital heat shield. The heat shield’s got to make it through the ascent phase without shucking a bunch of tiles, and then it’s got to come back in and also not lose a bunch of tiles or overheat the main airframe.”

“We have brought the ship back and had it do a soft landing in the ocean. We’ve done it a few times, but it lost a lot of tiles, and it … would not have been reusable without a lot of work,” Musk said. “If you want to be able to land it, refill propellant, and fly again, you can’t do this laborious inspection of 40,000 tiles type of thing.”

On this flight, SpaceX will test out modified tiles and attachment mechanisms to gather flight data on different heat shield options. The shield will also have “load sensing tiles” to take measurements as the vehicle experiences higher dynamic pressure during ascent than on previous flights. This higher dynamic pressure will put “added stress on the tile attachments in exchange for increased payload to orbit capability,” SpaceX said.

WebMCP for Documentation

How WorkOS taught its docs to speak WebMCP, giving AI agents real tools instead of HTML to scrape

When an AI agent reads your documentation today, it does what a scraper does: pull the rendered HTML and guess. It parses a wall of markup, tries to tell navigation from content, and hopes the page it landed on is the one the user actually needed. Every step is an interpretation, and every interpretation is a chance to be wrong.

WebMCP closes that gap. It's a proposed web standard for building and exposing structured tools that AI agents can call directly, providing JavaScript and HTML form annotations so agents know exactly how to interact with a page instead of inferring it from markup. We put this exciting new tech on the WorkOS docs, and documentation turned out to be close to an ideal surface for it.

The problem with "just build an MCP server"

The default answer to "make my product AI-accessible" has been to stand up an MCP server. That's the right call for a lot of things — APIs, internal tools, database access. It's the wrong call for a documentation site.

An MCP server is a separate process. It has its own deployment, its own auth story, its own hosting bill, its own tools, and its own drift problem: the moment your docs change, the server's view of them is stale unless you wire up a sync pipeline. You end up maintaining two representations of the same content — the site humans read, and the server agents read — and reconciling them forever.

For docs, that's absurd. The docs are the interface. The content, the navigation, the search index, the code samples — they already exist, rendered, in the browser. What we actually need is a way to let an agent talk to the page the user is looking at, using the same DOM, the same search, the same state.

That's what WebMCP is for.

What WebMCP actually does

The core idea is a shift in who declares intent. Instead of an agent inspecting a button or a field and guessing what it's for, the page declares each element's purpose so it gets used correctly — which is more reliable than actuation, where a multi-step interaction leaves each step open to the agent's interpretation.

A page exposes tools through document.modelContext (or navigator.modelContext), and the standard covers three things: discovery, so pages register tools with agents in a standard way; JSON Schemas, so inputs and outputs are defined explicitly to cut down on hallucination; and state, so the agent shares an understanding of the current page context. Tools run on the page visibly, so a user can watch the work happen and trust the result, and the site keeps its own design for humans intact.

There are two ways to author tools: an imperative API where you define them in standard JavaScript, and a declarative API where you annotate standard HTML forms.

Why documentation is the right surface

A docs site is read-mostly and navigation-heavy. The things an agent wants to do — find the right page, understand a section, move to it — map cleanly onto a small set of safe, well-defined tools. You don't need to model a shopping cart or guard a payment. You need search and movement.

WebMCP lives on the page the human already visits. The tools are generated from the same build that produces the docs, so they can't describe a version of the site that no longer exists. The agent and the human see the same thing.

How we built it

The implementation is a single custom Astro integration, integrations/webmcp.mjs, wired into the docs astro.config.mjs integration list. It has two halves: a build step that generates a manifest, and a client script that registers tools at runtime.

At build time, the integration reads each rendered page's index.html, pulls the <title> and the description meta tag, groups pages into collections by their first path segment, and writes /_webmcp/manifest.json with the entries and per-section counts. When the site finishes building, the manifest is also copied to the deploy root so the client's fetch to /_webmcp/manifest.json resolves

On the client, an injected script registers four tools:

• search_content: keyword search over page titles and descriptions in the manifest, with an optional collection filter and a limit.
• list_sections: enumerates the top-level content sections with page counts, derived from the first path segment of each URL.
• go_to: navigates the browser to a page by slug or path. Matches against slug, url, or /{slug}/, and falls back to a "use search_content" hint when nothing matches.
• get_page_info: returns the current page's title, meta description, h1/h2/h3 headings, and pathname, read straight from the live DOM.

Registration looks something like this.

mc.registerTool({
      name: "search_content",
      description: "Search documentation pages by keyword. Returns titles, URLs, and descriptions of matching results.",
      annotations: {
        readOnlyHint: true,
        untrustedContentHint: true
      },
      inputSchema: {
        type: "object",
        properties: {
          query: {
            type: "string",
            description: "Search term"
          },
          collection: {
            type: "string",
            description: "Filter by content section (optional)"
          },
          limit: {
            type: "number",
            description: "Max results (default 10, max 50)"
          }
        },
        required: ["query"]
      },
      execute: async (args) => {
          const m = await loadManifest();
          if (!m) return "Manifest unavailable.";
      }
});

The manifest is fetched once and cached through a loadManifest helper, so repeated searches don't refetch it.

The injected script can run again on client-side navigations, like Astro's view transitions, where document.modelContext persists. A document.__webmcpRegistered flag guards registration so each tool is registered once instead of stacking duplicate handlers on every navigation. All tool output runs through a truncation helper capped at a MAX_OUTPUT_LENGTH of 4000 characters before it's serialized to JSON, so a broad search can't dump an unbounded blob into the agent's context.

Where this is headed

WebMCP is still early, but the potential is huge! You can make use of the technology now through a Chrome origin trial starting in Chrome 149, with a chrome://flags/#enable-webmcp-testing flag for local development.

The spec is still moving, browser support is still landing, and the broader set of agent tools is still working out how to negotiate between page-declared tools and server-declared ones. The bet is straightforward: agents are going to read documentation whether or not we give them a good way to do it. Handing them real search and navigation tools, generated from the same build that ships the site, beats leaving them to scrape. The direction is clear though: the web is going to expose itself to agents through the same surface it exposes to humans, not through a parallel universe of servers that shadow every site.

sx 2.0 is out: a native app for Mac, Windows, and Linux that lets anyone share AI skills with their team, no git and no terminal required.

A few months ago I wrote that there’s an npm-shaped hole in the AI tooling stack. Your best AI users build up skills, MCP configs, and commands that multiply their output, and that knowledge stays trapped on their machines because there’s no clean way to distribute it. We built sx, an open source package manager for AI assets, to fill that hole. It worked. Developers use it to version skills in git vaults and install them across Claude Code, Cursor, Copilot, Codex, Gemini, Cline, and Kiro with a lock file and deterministic installs.

Then I made a mistake I should have seen coming, because I’ve watched Atlassian make it twice. I built the sharing layer for developers and assumed everyone else would eventually meet us at the command line. They won’t. In the sixty or so discovery interviews we’ve run this year, the people getting the most out of skills are increasingly in marketing, legal, sales, and ops. They write great skills. They have no git, no terminal, and no interest in acquiring either. Asking a marketing team to sx init --type git is asking them to not share skills.

sx 2.0 is the fix. It’s a real desktop app, and the distribution model it leans on is one every team already has: a shared folder.

A shared Dropbox folder is the whole backend

Here’s the workflow for a non-technical team. You open the app, point your library at a folder in Dropbox, Google Drive, OneDrive, or iCloud, and drag your skills in. Markdown goes in, skills come out. Your teammates point the app at the same folder and everything you publish shows up for them. There’s no server and no accounts. The file sync product your company already pays for does the replication.

This works because of the other big change in 2.0: vault format v2. The latest version of every asset now lives directly on disk at assets/<name>/ as plain, readable markdown. Version history lives in .sx/versions/ next to it. You can grep the vault. You can open it in Obsidian. You can point .claude/skills straight at it and it just works, because there’s nothing to unpack.

The obvious comparison is exactly that Obsidian setup, a markdown vault in a synced folder, and plenty of teams do run their skills that way today. The difference is what happens after the files sync. sx knows about the AI clients natively. When you hit Sync in the app, it runs an sx install in the background: it resolves what should be installed for you, translates each asset into every client’s format (Claude Code skills, Cursor rules, Copilot instructions, and so on), and writes it to the right place on your machine. Your teammate drops a skill in the shared folder, you click one button, and it’s live in your AI client. That translation layer is the part a folder full of markdown can’t do for you.

Developers lose nothing here. The CLI is still the same Go binary, the git and skills.new vault types still work, and the app and CLI read the same vaults. 2.0 adds collections, which group related skills and install as a unit resolved at read time, so a skill added to a shared collection next month reaches the whole team automatically without anyone re-running anything.

Extensions, because your team’s problems aren’t my roadmap

The second half of this release line is an extension system for the app. I’ve spent enough years around plugin ecosystems (I was at Atlassian when my co-founder Don built theirs) to believe that the interesting problems in a team tool are always specific to the team, and that cramming every team’s answer into core is how products get bloated and slow.

So the app is now pluggable. An extension is a folder with a manifest and one ES module, no build step until you want one. Extensions can add dashboard widgets, publish-time checks, editor commands, and whole new views. There’s a marketplace that ships with fifteen of them, and the ones people reach for first are the team-health ones:

• Collection Doctor scores a collection 0 to 100 and names the problems: thin descriptions, stale assets that should be retired, near-duplicate skills, oversized skills eating context. Each finding is one click from the asset it names.
• The adoption widgets show who on the team is actually using which skills, so you can see whether that skill someone spent a week on is earning its keep.
• Review Rota gives every asset a review due date that adapts to how heavily it’s used, and rotates reviews fairly across the team.
• Collection Export compiles a collection into a Claude Code, Codex, or Gemini plugin, or a plain zip, for sharing outside your vault.

Two design decisions I’ll defend if you push on them in the comments. First, extensions are permission-gated: no filesystem, no Node, no network beyond hosts an extension explicitly declares, and enabling one shows you a plain-language list of exactly what it can touch, re-prompted whenever an update changes that list. Second, extensions are just sx assets. They publish, version, scope to teams, pin, and audit through the same pipeline as a skill, which means an extension update can never sneak past review the way it can in ecosystems where plugins auto-update out-of-band. Org admins can allowlist or disable third-party extensions vault-wide. The marketplace itself is just another sx vault, so pointing the app at your own repo gives you a private one.

Where this is going

The premise behind sx hasn’t changed since the first release: AI gains are trapped in individuals, and the missing layer is distribution. What changed is my picture of who needs it. The 2.0 line is a bet that the next wave of skill authors won’t be developers, and that meeting them means a native app, a folder they already share, and one sync button that hides a package manager underneath.

Everything is Apache-2.0 and on GitHub: github.com/sleuth-io/sx. The app is in the release assets for all three platforms, and brew install sx still gets you the CLI. If you try the shared-folder setup with your team, I want to hear where it breaks. That’s the part of this release I’m least sure survives contact with real Dropbox latency.

Cloudflare and OpenAI this week launched a research pilot that feeds Cloudflare's real-time network data into OpenAI's search system, an arrangement the companies say could help artificial intelligence tools find and index web content with less delay.

The project, announced July 8, 2026, pairs Cloudflare's visibility into traffic behavior and content changes across its global network with OpenAI's large-scale search and answer infrastructure, according to a joint statement carried through a Cloudflare press release. Cloudflare sits behind more than 20% of the web, according to the company, giving it a broad vantage point on how pages change and how both human and automated traffic moves across sites in real time.

The stated goal is narrow: improve the accuracy and timeliness of AI-generated answers by helping crawlers and indexing systems tell the difference between a page that has genuinely changed and one that has not.

What the pilot actually does

According to Cloudflare, the arrangement draws on real-time network insights the company already collects for its own infrastructure customers - specifically content freshness, traffic quality, and actual page changes. Combined with OpenAI's frontier models and its large-scale search and answer system, the two companies intend to examine whether signal-driven crawling and indexing can improve how quickly and accurately AI answers reflect what is actually on a page.

Neither company disclosed a technical specification for how the signals will be transmitted, how OpenAI's systems will weigh them against existing crawling logic, or what a successful outcome looks like in measurable terms. The release describes the collaboration as a pilot and frames it as exploratory rather than a finished product.

"By sharing our sophisticated network signals, we can find a better way to make AI search more efficient and help people get quality answers faster," said Matthew Prince, co-founder and chief executive officer of Cloudflare, in the announcement.

Nick Ryder, vice president of research at OpenAI, framed the collaboration around a similar concern with data currency. "Up-to-date information is important for delivering accurate answers to people using ChatGPT," Ryder said. "Piloting this with Cloudflare will allow us to explore whether network-level insights can help us discover content more efficiently."

Scope and limitations disclosed

The companies specified that the pilot is focused on improving the accuracy and timeliness of answers, and that it centers on how participating websites' content gets discovered and indexed on the open web. The release does not name which websites are participating, how many sites are involved, what data-sharing safeguards apply, or when the companies expect to report results. No commercial terms accompanied the announcement; nothing in the release indicates that publishers are paid, charged, or otherwise compensated as part of this specific pilot.

Cloudflare's own description of its position - sitting behind more than 20% of the web - has appeared consistently in the company's public statements over the past year as it has built out a series of tools addressing how AI systems access, crawl, and increasingly compensate the sites they draw content from.

Where this fits in a year of Cloudflare-AI announcements

The OpenAI pilot arrives one week after Cloudflare's most significant prior move in this area. On July 1, 2026, marking what the company calls its second annual Content Independence Day, Cloudflare announced a shift away from charging AI crawlers per individual page fetch and toward paying publishers based on whether their content actually appeared inside an AI-generated answer. That announcement introduced what Cloudflare called a research program built on freshness signals, arguing that a single page might be crawled once and cited thousands of times, or crawled repeatedly and never cited at all - meaning the crawl itself is a poor proxy for value. The centerpiece of that July 1 post was a claim that more than half of the crawl traffic generated by bots Cloudflare classifies as legitimate goes toward re-fetching pages that have not changed since the previous visit.

Today's pilot with OpenAI reads as a direct extension of that framework, naming a specific AI company as a technical partner for the freshness-signal research Cloudflare previewed a week earlier. The July 1 post named Ceramic.ai and You.com as commercial partners testing new payment mechanics; OpenAI's involvement, disclosed today, appears oriented toward the underlying signal-sharing research itself rather than a payment arrangement, since no compensation terms were disclosed in either release.

The freshness argument Cloudflare has been building did not emerge from a single data point. In April 2026, Cloudflare and ETH Zurich published joint research arguing that AI crawler traffic breaks assumptions built into standard web caching systems, because more than 90% of pages processed by large-scale crawlers such as Common Crawl are unique by content - a pattern that defeats caching architectures designed around the expectation that popular pages get requested repeatedly. By early June 2026, Cloudflare Radar data showed bots accounting for 57.4% of all HTML web traffic tracked across its network, with training-related crawlers alone making up 50.6% of that total and search-related bots representing a much smaller 10.7% share.

A year of documented imbalance between crawling and referral traffic

The relationship between Cloudflare and OpenAI specifically has a documented history that provides useful context for today's pilot. Cloudflare's own published data has tracked OpenAI's crawl-to-referral ratio - the number of times an OpenAI bot crawls a page against the number of human visitors that bot eventually sends back through a referral link - at 1,091 crawls per referral as of August 2025, a figure disclosed when Cloudflare expanded its AI Crawl Control system with customizable HTTP 402 Payment Required responses. That same disclosure showed a competing AI company's crawler accessing 38,000 pages for every one referred visit, illustrating a wide spread in how different AI operators treat the publishers whose content they draw from.

Cloudflare CEO Matthew Prince has previously distinguished OpenAI's approach from that of other AI companies operating on his network. In comments reported in September 2025, Prince described OpenAI as "a good actor" that had engaged in content licensing discussions following Cloudflare's initial pay-per-crawl launch, a characterization that contrasted with Prince's sharper criticism of other platforms accused of circumventing content blocks entirely.

The broader question of whether AI-generated summaries reduce the traffic publishers depend on has generated a growing body of independent research over the past year. A 2025 Pew Research Center study, cited directly in Cloudflare's July 1 announcement, found that when Google's AI Overviews appear in search results, users click a traditional search result link in just 8% of cases - roughly half the rate observed when no AI summary appears - and click a link inside the AI summary itself in only 1% of cases. Separate analysis from Ahrefs, examining 300,000 keywords, found in April 2025 that AI Overviews correlated with a 34.5% reduction in clicks to the top-ranking organic result; a follow-up Ahrefs analysis found that figure had grown to 58% by February 2026.

Technical context: what "network signals" means in practice

Cloudflare's global network - the infrastructure underlying the more than 20% of the web the company says sits behind its proxying and security services - gives it visibility into three categories of information relevant to this pilot: content freshness (whether a page's underlying content has changed since it was last observed), traffic quality (patterns distinguishing legitimate visits from automated or malicious activity), and actual page changes (direct observation of modifications to a site's served content, as opposed to inference from crawl timestamps alone).

These categories align closely with the freshness-signal research Cloudflare previewed on July 1, in which the company argued that a freshness signal confirming nothing has changed on a page allows a crawler to skip that page entirely, saving compute costs for the AI company issuing the crawl and bandwidth costs for the publisher serving the request. Today's pilot with OpenAI appears to test whether that same signal category - applied specifically to OpenAI's search and answer infrastructure - measurably improves how quickly OpenAI's systems surface updated content and how much unnecessary re-crawling can be eliminated as a result.

Neither the Cloudflare release nor any accompanying technical documentation specifies a data-transmission protocol, an opt-in mechanism for individual publishers, or a method for verifying that shared signals are not used for purposes beyond search indexing. Cloudflare's July 1 announcement had explicitly stated that a related freshness-signal program was restricted to search functions, that no content was being shared through it, and that none of the data involved would be used to train foundation models; today's release does not repeat or update those specific scope commitments for the OpenAI pilot by name.

Industry context: crawler behavior remains a live regulatory and commercial issue

The announcement lands amid continued scrutiny of how different AI companies' crawlers behave relative to one another. Cloudflare disclosed on January 30, 2026, data showing that Google's search crawler accessed substantially more web content than competing AI crawlers - roughly 3.2 times as much as OpenAI and more than three times as much as Bing, over a two-month observation period. That disclosure coincided with a consultation opened by the UK's Competition and Markets Authority examining conduct requirements for Google following the regulator's designation of the company with Strategic Market Status in the search market.

Anthropic, a separate AI company operating its own crawlers, published updated documentation on February 25, 2026, clarifying how its three bots - ClaudeBot, Claude-User, and Claude-SearchBot - interact with the robots.txt standard and confirming the company would not attempt to bypass CAPTCHA verification systems. That documentation update followed months of scrutiny after Cloudflare data showed Anthropic's crawl-to-referral ratio reaching 286,930 crawls per referral in January 2025, a figure that had fallen to 38,000 by July of that year.

Separately, research from Rutgers Business School and The Wharton School, most recently revised on April 21, 2026, found that news publishers who blocked large language model crawlers through robots.txt lost roughly 7% of weekly website traffic within six weeks of implementing the block - a finding measured in human browsing panel data rather than automated bot metrics alone. That research complicates any simple assumption that blocking AI crawlers protects a publisher's traffic without cost, since the study found the traffic decline occurred without a corresponding reduction in how often the publisher's content was cited in AI-generated answers.

Why this matters for publishers and marketers

For publishers and marketing teams tracking how their content appears inside AI-generated search results, today's pilot represents a narrower and more technical development than Cloudflare's July 1 payment-model announcement, but it sits on the same underlying thesis: that crawling behavior driven by stale or incomplete signals wastes resources on both sides of the publisher-AI relationship. If the pilot demonstrates that network-level freshness signals meaningfully reduce unnecessary re-crawling, publishers using Cloudflare's infrastructure could eventually see reduced server load from AI bot traffic, addressing a cost that Cloudflare has documented at length over the past year without, to date, offering a resolved technical fix specific to OpenAI's systems.

The pilot also offers an early data point on how OpenAI, characterized in the past by Cloudflare's own executives as cooperative relative to some competing AI companies, continues to engage directly with infrastructure providers on search-quality questions rather than solely on data-licensing or payment terms. Because no financial terms, publisher opt-in mechanism, or measurable success criteria accompanied the July 8 release, the practical effect on any individual publisher's traffic or AI visibility cannot yet be assessed. Marketing teams evaluating answer engine optimization strategies - a discipline that has grown rapidly over the past year, with products from HubSpot and Microsoft Advertising addressing similar visibility questions - will likely want to watch whether Cloudflare publishes measurable results from this pilot, and whether wider public availability, projected only in general terms in the company's July 1 statement, includes OpenAI as a named launch partner.

Timeline

• January 2025: Cloudflare data shows one AI operator's crawl-to-referral ratio reaching 286,930 crawls per referral
• July 1-2, 2025: Cloudflare launches Pay Per Crawl in private beta, introducing HTTP 402 Payment Required responses for AI crawler monetization
• August 28-29, 2025: Cloudflare expands AI Crawl Control with customizable HTTP 402 responses; data shows OpenAI's crawl-to-referral ratio at 1,091 crawls per referral
• January 30, 2026: Cloudflare discloses data showing Google's crawler accessing roughly 3.2 times more web content than OpenAI's crawler
• February 25, 2026: Anthropic publishes updated documentation clarifying how its three crawlers interact with robots.txt
• April 2, 2026: Cloudflare and ETH Zurich publish joint research on AI crawler traffic breaking standard web caching assumptions
• April 21, 2026: Rutgers Business School and Wharton School researchers publish revised findings on traffic effects of blocking AI crawlers
• June 5, 2026: Cloudflare Radar data shows bots accounting for 57.4% of all HTML web traffic across its network
• July 1, 2026: Cloudflare announces a shift from Pay Per Crawl toward Pay Per Use and previews a freshness-signal research program
• July 8, 2026: Cloudflare and OpenAI announce their joint research pilot on network signals and web indexing

Summary

Who: Cloudflare, the connectivity cloud company led by co-founder and chief executive officer Matthew Prince, and OpenAI, represented in the announcement by Nick Ryder, vice president of research.

What: The two companies launched a research pilot combining Cloudflare's real-time network signals - covering content freshness, traffic quality, and page changes - with OpenAI's search and answer infrastructure, aiming to improve how accurately and quickly AI systems discover and index web content.

When: The pilot was announced today, July 8, 2026, one week after Cloudflare's July 1, 2026 announcement previewing a related freshness-signal research program.

Where: The pilot operates across Cloudflare's global network, which the company says sits behind more than 20% of the web, in partnership with OpenAI's search infrastructure.

Why: Both companies frame the collaboration as an effort to improve the efficiency and accuracy of AI-powered search by helping crawling and indexing systems distinguish genuinely updated content from unchanged pages, extending a broader industry effort - documented extensively by Cloudflare over the past year - to address the costs and imbalances created by high-volume AI crawler traffic.

Full article content is not available for inline reading.

Read the original article →

Taste cannot be delegated

The death of design by committee in the age of AI

In my previous writing, I explored two ideas that initially seemed separate.

In AI made everyone a creator, not a designer, I argued that AI is fundamentally changing the relationship between creation and design. When anyone can generate interfaces, visuals, and concepts in seconds, the designer’s value no longer comes from producing more outputs. It comes from knowing which outputs deserve to exist.

In the organizational cost of low taste, I looked at what happens when that judgment disappears inside organizations. Not because people suddenly lose their ability to recognize quality, but because decisions become diluted across layers of alignment, compromise, and approval.

The more I think about it, the more I believe these are not two separate conversations. They describe the same problem from different directions. One asks whether AI can replace design judgment. The other asks whether organizations have already done it. Both rest on the same misunderstanding.

We increasingly talk about taste as though it were something that can be collected, measured, or encoded. We assume that if enough people agree, or if enough data is available, the right answer will eventually emerge. But taste has never worked that way.

Taste begins with knowing what good looks like. It comes from exposure to exceptional work, from studying history, understanding proportion, typography, interaction, composition, and learning to recognize quality with consistency. Designers who struggle to make strong decisions often do not lack confidence. They simply have not yet built that internal reference library. Yet recognizing quality is only the beginning.

Taste becomes valuable when someone has the responsibility to act on it. That distinction matters because recognizing quality and deciding what should exist are not the same thing. This is where both AI systems and modern organizations reveal the same limitation. Both are becoming remarkably good at identifying what is preferred. Both are much less capable of deciding what deserves to happen next.

The illusion of encoded taste

As generative AI becomes increasingly capable of producing interfaces, brands, illustrations, products, and entire user experiences, a familiar claim keeps appearing: AI is learning taste.

On the surface, the argument makes sense. These models are trained on enormous collections of human-created work. They learn from rankings, comparisons, reinforcement learning, and millions of examples of what people tend to prefer. As the models improve, they become increasingly effective at predicting what users are likely to consider successful. But prediction is not judgment.

Preference describes what people choose. Judgment explains why something is the right choice.

A model can learn that users generally respond well to clean interfaces, balanced layouts, familiar navigation patterns, generous spacing, or restrained typography. It can detect statistical relationships between visual decisions and positive feedback at a scale no human could ever match.

What it cannot understand is intent.

It cannot know whether removing an element creates clarity or removes personality. It cannot know whether breaking a convention introduces unnecessary friction or fundamentally improves the experience. It cannot evaluate a design decision against an ambition that does not yet exist. Because every important design decision is made in context.

The right interface for a banking application is not the right interface for a children’s learning platform. The right visual language for a heritage luxury brand is not the right language for a startup trying to challenge an entire category. The same design principle can be brilliant in one situation and completely wrong in another. Patterns alone cannot resolve those tensions.

Only judgment can.

This is why design has never simply been the application of best practices. Best practices describe what has worked before. Design decides when the future requires something different. That distinction is easy to miss because successful design decisions often appear obvious in retrospect.

Before the iPhone, the smartphone industry was built around physical keyboards. Devices like the BlackBerry represented the prevailing belief that serious mobile computing required tactile input. Every observable signal reinforced that assumption. Business users valued keyboards. Manufacturers competed by refining them. Existing preferences all pointed in the same direction.

Apple asked a different question. Instead of asking how to improve the existing smartphone, it asked what a phone could become if the interface itself disappeared. Removing the keyboard looked irrational through the lens of current preferences. Through the lens of judgment, it created something entirely new. The multi-touch display was not simply another interface choice. It transformed the phone into a software-defined device that could continuously evolve instead of being constrained by its hardware. The decision was not an optimization. It was a bet on a future users had not yet experienced. That is the difference between preference and judgment. Optimization improves what already exists. Judgment decides what should exist next.

Organizations made the same mistake before AI

The interesting part is that artificial intelligence did not invent this problem. Many organizations have been trying to replace judgment with preference aggregation for years.

A design proposal enters a meeting, and suddenly everyone becomes a reviewer. Product managers raise legitimate product concerns. Engineers explain technical constraints. Marketing protects positioning. Sales represents customer objections. Leadership evaluates business impact. Legal assesses risk. Every perspective contributes something valuable.

The problem is not collaboration.

The problem begins when collaboration replaces ownership. As more people participate, accountability quietly disappears. Decisions become increasingly shaped by what survives discussion instead of what best serves the product. The strongest idea slowly becomes the safest idea. Nobody explicitly asks for average design. Average design is simply what emerges when every decision must satisfy every stakeholder equally. Organizations often describe this as alignment. Design experiences it as erosion. The irony is that committees are often excellent at identifying what people already like. That is exactly why they struggle to create something people have never seen before. Innovation almost always begins by making a decision that feels uncomfortable before it feels inevitable.

The same pattern appears in branding. When Mastercard redesigned its identity in 2016, the most significant decision was not changing the logo itself. It was removing the company name from many applications altogether. Viewed through the logic of stakeholder approval, that decision looked unnecessarily risky. Financial institutions depend on recognition and trust. Removing the name seemed to weaken both. But the designers recognized something metrics alone could not capture. After decades of consistency, the overlapping circles had accumulated enough meaning to carry the brand by themselves.

The word had become redundant. The redesign was not an exercise in minimalism because minimalism happened to be fashionable. It was an acknowledgment that one element had stopped contributing to the communication. That is another form of judgment. Not knowing what to add. Knowing what no longer needs to be said.

The danger of optimizing only what can be measured

The same pattern extends far beyond branding. Digital products are increasingly optimized through metrics. Every interaction can be measured. Every screen can be tested. Every decision can be validated against clicks, conversions, engagement, retention, or time spent. Those signals are valuable. The mistake is assuming they are sufficient. Metrics tell us whether something is performing against today’s objective. They rarely tell us whether we are building the right objective in the first place. That distinction explains why some of the most influential digital experiences did not emerge from optimization alone.

When The New York Times published Snow Fall: The Avalanche at Tunnel Creek in 2012, it was more than an article. It reimagined what digital storytelling could become by weaving long form writing with video, photography, animation, maps, and interaction into a single narrative experience. The project became influential not because it optimized an existing format, but because it challenged the assumption that online journalism should simply replicate print on a screen. The decision reflected a broader belief about the future of the medium.

Digital publishing was not just another distribution channel. It was an entirely different storytelling canvas. No experiment could have asked readers whether they wanted that experience before they had seen it. No dashboard could have measured demand for a format that did not yet exist. The judgment came first. The metrics came later.

That is often how meaningful innovation works. Optimization refines the present, when judgment creates the future.

The role of design leadership is protecting judgment

This is why design leadership matters. A design leader is not valuable because they have the strongest aesthetic preferences in the room. They are valuable because they can connect aesthetics, product strategy, user behavior, technical constraints, business objectives, and brand into a coherent point of view. Their responsibility is not to eliminate disagreement, but to resolve it.

Healthy design organizations are not built on consensus. They are built on clear ownership, and feedback should improve a decision. It should not replace the person responsible for making it.

When ownership is unclear, organizations naturally drift toward decisions that satisfy everyone a little instead of decisions that excite anyone deeply. The result is rarely bad design. In fact, average design often feels remarkably competent. The interface is usable, the typography is clean, the flows work, the branding is consistent. Nothing is obviously wrong.

Nothing is particularly memorable either. That is what design by committee usually produces: not failure, forgettability.

Taste requires exposure, but responsibility creates judgment

Taste is often described as intuition. In reality, judgment is built, and it begins with exposure. Studying exceptional work. Understanding history. Developing sensitivity to proportion, typography, composition, interaction, and detail. Many designers struggle to make strong decisions not because they lack confidence, but because they have not yet developed a reliable sense of what good looks like. But recognizing quality is only the beginning.

Judgment emerges when taste meets responsibility. It develops when decisions have consequences. When you must choose between competing priorities. When you defend a direction without complete certainty. When you accept that a good decision may initially make people uncomfortable before it becomes obvious.

Knowing what looks good is a prerequisite. Knowing what matters is what turns taste into leadership.

AI will not replace taste. It will reveal where taste was missing.

AI systems will continue to improve at predicting what people prefer. Organizations will continue to improve at collecting opinions.

Both are valuable. Neither creates judgment.

Judgment is not the result of combining enough signals. It emerges when someone understands the context, accepts the trade offs, and takes responsibility for deciding what deserves to exist.

The future of design will not belong to the people who can generate the most options. That will soon describe almost everyone. It will belong to the people who can recognize the one worth pursuing. That requires taste.

Not taste as an aesthetic preference. Not taste as a collection of visual references. Taste as the ability to recognize quality. Judgment as the willingness to choose a direction. Leadership as the responsibility to stand behind that choice. Those three qualities have always been connected.

AI changes how we create. It does not change who is accountable for deciding what deserves to exist. Because taste can be assisted. It can be challenged. It can be refined. But it cannot be delegated.

We Didn't Teach Our Designers AI: We Built a Place Where They Could Learn It Together

The Question We Kept Hearing

“How do I use AI?”

That question, typed in a DM rather than asked out loud, told us everything. Our design team was not short on curiosity. What was missing was somewhere to be a beginner. A space where not knowing wasn’t a liability, but the whole point. So we built one. In true Slack fashion, our AI origin story starts with a Slack channel and a lot of enthusiasm.

Back in early 2025, the vibe was exploratory. AI felt like something cool on the horizon, a new tool worth poking at. We kicked off a channel, secured some vibe tool training for anyone who wanted it, and ran a few sessions. The energy was “take it for a spin.” Low stakes, high curiosity. Very Slack Design.

Then 2026 happened.

Suddenly AI wasn’t a future thing. It was a right now thing. Engineers were moving fast, really fast. Designers needed to start moving with them, not after them. That’s where Builder Days came into play: three days where designers, engineers, and product managers would set aside their roadmaps and just build together with AI. The mood shifted from curiosity to something with a little more urgency: we need to be ready for this.

As a Design Ops person with a soft spot for learning programs and the human side of change, I saw a chance to help. Not to mandate anything, but to create the space where curious designers could get genuinely, practically ready. to show up to Builder Days with something to contribute, not just something to observe.

This is that story. What we did, what we learned, what surprised us, and what we’d tell any design team trying to figure out where they fit when everything starts moving at once.

For Design, By Design

The problem wasn’t a shortage of learning opportunities. It was the opposite. Tool enablement sessions started flooding our calendars from every direction, and almost none of them were built with designers in mind. Most of these sessions were designed for engineers, and we were just along for the ride. There was another wrinkle: things were moving so fast that a setup guide from Monday was outdated by Friday.

So we decided to build our own AI enablement programming. For design, by design.

That phrase became our north star. Hearing what AI tools can do from a fellow designer lands completely differently than hearing it from an engineer. It wasn’t evangelism. It was permission, and for the designers on our team who were still waiting to be convinced, that distinction mattered more than we expected.

Our sessions weren’t polished. And honestly? That was the point.

We ran a Friday series called Designers Who Vibe & AI, and the most memorable moments weren’t the prepared demos. They happened when someone interrupted to ask a question, shared their screen (tabs and all), and we’d just figure it out together in real time. No scripts. Just curiosity out loud.

We were learning something that was changing faster than any guide could keep up with. So instead of pretending we had all the answers, we leaned into the one thing that actually worked: ask the question, try the thing, and when you get stuck, ask AI.

Let AI teach you how to use AI. That became one of our mantras.

Three Days. No Roadmap. Just Build.

Builder Days were designed to be intentionally open-ended. Show up, find your cross-functional partners, and build something with AI. Simple in concept, but harder in practice, especially when both the technology and the collaboration model are new at the same time.

So we helped designers come prepared. We highlighted how other designers were thinking about their approach, so no one had to figure it out alone. We created a “Designer’s Guide to Builder Days,” a one-stop resource for what to expect, what was expected of you, and where to find inspiration. It also included a terminology section for anyone who needed a jargon-free answer to “Wait, what’s a terminal?”

We also reframed what success looked like. The purpose of Builder Days wasn’t to make AI work for you: it was to learn when it does and when it doesn’t. Finding the edges was the point. We even created a temporary support channel just for Builder Days. If you got stuck, you asked, and someone from the team would help. No judgment, no friction.

And when one designer, deep into a frustrating loop of prompts, finally admitted they just wanted to touch grass, we counted that as a finding too. At the end of the day, we’re still human, and we can’t lose sight of that.

Before Builder Days, learning was happening in pockets. Builder Days forced something different and what we saw was messy and energizing in equal measure. Designers who’d been lurking suddenly had a forcing function, and teams circling AI integration for months had no choice but to try it. Some things broke, and a lot of things surprised people in a good way.

But the real learning happened after Builder Days. We brought together a handful of designers who’d had mixed experiences and asked what they actually learned. The answers were honest and spicy in the best way.

• Human judgement is a non-negotiable: The speed of AI output demands a corresponding increase in coordination, communication, and human oversight — not less.
• Upfront planning is everything: The teams that thrived had a clear plan from day one — defined ownership, a shared working model, and early, frequent progress sharing.
• The harness matters as much as the model: A great model alone isn’t enough. Investing in the “harness” — prompts, claude.md, skills, and documentation — is what unlocks product-quality AI output.
• Collaboration models are shifting: AI shifts collaboration from optimizing async work to spending more time on meaningful, high-value activities: decisions, brainstorming, and shared ideation.

One designer spent her three days trying to understand her own relationship with AI. Not building something to show, not optimizing a workflow, simply just sitting with it and asking it hard questions. Her conclusion? “It’s complicated.”

And you know what? That’s okay. That’s also a really good finding. Not every designer walked away with a working prototype or a merged PR. Some walked away with something harder to measure and more important: a clearer sense of where they currently stand with this technology, what excites them, what makes them uneasy, and what questions they still need to answer for themselves.

That’s the thing about building a learning culture: the value isn’t always in the output. Sometimes it’s in the container. When people know there’s a place to bring their confusion, they bring it. And when confusion is visible, it becomes something the whole team can work on together.

Start With the Community

We’re still in the middle of this. Builder Days just ended. The channel is still buzzing. Our AI programming will keep evolving based on what the team actually needs. But if we could pass one thing on to another design team, it’s this: don’t start with the tools, start with the people. Find your beginners. Give them a place to be curious without embarrassment. Put them next to someone who’s one step ahead, not ten. And give the whole team enough protected time to practice together.

The tools will keep changing, but the culture you build around learning them is what compounds. And as someone whose job is to clear the path for designers, I met this AI moment the only way I know how to approach a program: start with the people.

Making Fable Cheaper Than Opus

We replaced Opus 4.8 with Fable 5, and Devin’s bill went down. Fable 5 costs twice as much per token as Opus 4.8. But when we ran both models on FrontierCode 1.1 using our new Fusion architecture,...

Personal update: I'm taking a leave of absence from YC to join Anthropic. I'll be working with @NotTomBrown on the compute team.

Powerful AI has the potential to improve the life of every human on earth and, as we enter the early stages of recursive self-improvement, availability of compute becomes one of the most important issues to solve.

I'm excited to get started 🚀

Honestly, has this ever worked?

Big consultancies are responsible for some of the most egregious tech delivery failures in modern times.

I'm so fed up that we can't build good public-service apps.

https://twitter.com/charliehrysmith/status/1494023615616008193

I've repeatedly been tempted to go and offer to help build stuff like this myself.

But then I remember the ridiculous government bureaucracy and decide to preserve my sanity.

Companies like Deloitte are awesome at navigation bureaucracy, managing competing stakeholders and winning complex bid processes.

It's a shame they totally suck at actually building stuff people love to use.

Apple's lawsuit accusing OpenAI of systematically stealing its intellectual property could disrupt OpenAI's device ambitions long before the case is resolved. The claims may cause many Apple employees to reconsider leaving for OpenAI, and that could slow OpenAI's recruiting pipeline, keep more engineers at Apple, and reduce the flow of institutional knowledge into OpenAI. This, along with several other factors, threatens to slow development. OpenAI is reportedly still on track to announce its first product this year with a release in 2027.

Meet the newly public, Bezos-backed company that’s recreating the sun and stars

General Fusion CEO Greg Twinney spoke with Sherwood News from the Nasdaq during the stock’s first day of trading.

Smashing nuclei together to generate energy has proved a lot more difficult than splitting the atom.

The first pure-play publicly traded company in pursuit of that goal, General Fusion, debuted on the Nasdaq on Monday as part of a SPAC merger with Spring Valley Acquisition Corp III.

The firm uses a hybrid approach called Magnetized Target Fusion (or more colorfully, steampunk) in which magnetism and shockwaves combine to generate intense heat and compress what are among the tiniest things in the universe.

CEO Greg Twinney spoke with Sherwood News from the Nasdaq during the stock’s first day of trading, calling fusion a “trillion dollar opportunity” with the potential to deliver “on-demand, clean, incredibly abundant energy.”

It’s something to dream on — and something that’s been dreamt on for a long time.

With $150 million in the bank, Twinney says that General Fusion has “the capital we need to hit those really important science milestones” with the goal of having a fusion power plant running by 2035.

This transcript has been lightly edited for clarity.

Sherwood News: Off the top for those who might not be too familiar, uh, can you just describe where you think you are in terms of General Fusion generating commercially viable nuclear fusion energy? What have you achieved, and what’s your roadmap for progressing?

Greg Twinney: I think it all starts with the demand case, right? The world's entering an era of unprecedented energy demand. That's driven by AI, data centers, advanced manufacturing, electrification, industrial growth, all those things driving massive demand. And so the world needs more energy, and ideally that's clean, reliable, base load power. And that is what we are out to do is provide that clean, reliable, base load power with fusion. At General Fusion, we've been at this for over two decades now and are a world leader on the path to commercialize fusion, put fusion power plants on the grid. And that's exciting. It's exciting for us, but it's also exciting to think about how the decades past with fusion have set us up now to move into ultimately a first of a kind as the major milestone in 2035.

SN: One thing I noticed in some of your filing materials you put forward was the disclaimer that some of your growth depends on technology that has not yet been demonstrated or developed. Can you speak to what you need to get done? What are the incremental milestones that investors should be looking for?

GT: To create a fusion power plant, you need to almost recreate conditions similar to the sun and the stars. The sun and stars…that's fusion happening in front of our eyes. And so recreating those conditions inside a machine allows us at General Fusion to unlock all the potential of fusion. And the first major milestones for us based on, you know, the last 20 years of foundation are to achieve these fusion conditions using our unique approach to fusion.

And really, it's climbing a temperature curve up from industry accepted milestones of ours for 10 million degree temperatures inside the machine, the fuel, and then 100 million degrees, and then, the third major industry milestone, which we're aiming to achieve by 2028, is something called the Lawson Criterion, and that's this combination of temperature, fuel density, and time long enough to get enough fusion reactions that, the energy that could come out of that reaction would be equal to what went in to create it in the first place.

And so that's the first major set of science milestones. On the other side of that, building out repeatability, and some of the engineering components of, of our approach, we take a very engineering-centric approach to creating these fusion conditions. So we'll need to build out those pieces and then, finalize the design and, and have our first of a kind stood up in 2035.

SN: You’re probably tired of hearing this, but there’s the old joke that nuclear fusion is the energy of the future, and it always will be. What's changed about either the technology or the funding environment that’s bringing us closer to retiring that phrase, in your mind?

GT: I think that phrase comes from an era of national labs and academia working on fusion for many decades. And now what I can say is that the acceleration of the development and the advancement of the plasma physics of the demonstrations has accelerated an extraordinary amount, and that's because you've got private companies working on fusion now, and we're one of the world leaders in that regard.

And so the pace of development has increased significantly, and what's been achieved has been a demonstration of some of these really important fusion conditions in different science demonstrations, and it's now up to us — a company like us, General Fusion, that have a commercial design for creating those conditions — to recreate those conditions and then move this from a science project into commercialization.

SN: General Fusion is — as every headline will have it — Bezos-backed. What's his level of involvement, interest in the company, and the nature of that relationship?

GT: So I can't speak to all, all the details, but can say, he has been an investor in the company, and one of many of our investors. We've had sovereign wealth funds, other ultra high net worth individuals, VCs, et cetera, all part of the mix of the $400 million or so that we raised in the private markets to set ourselves up for where we are now, which is stepping into the public markets and now having a much broader set of investors, and deeper capital pool to be able to fund the go forward milestones.

SN: I believe you have about $150 million today, and one of the things I’ve seen you say about developing your technology is “We Build It to Prove It.” That sounds to me like a capex intensive exercise. So is $150 million enough to get where you want to go, or do you foresee that you'll be needing to take advantage of some of this deeper pool that public markets offer in order to continue to meet the roadmap you laid out?

GT: It's a good question. The $150 million of capital we're entering into the public markets with is the capital we need to hit those really important science milestones, the 10 million degrees, 100 million degrees, and those breakeven fusion conditions inside the machine. So that's the capital that will fully fund it. And why we have confidence, is that we've already built the machine. The machine's fully licensed. It's operating. It's compressing plasmas in the way that it needs to, and we're already progressing towards those milestones. And so a lot of the uncertainty around the costs is behind us now. And, and now it's all about using this $150 million to advance through those next set of milestones.

SN: Let's fast-forward to a world in which you've hit these milestones and beyond, and you’ve successfully commercialized nuclear fusion energy.

What does this disrupt? What changes about the world? One thing that jumps to mind for me is, there’s been a lot of talk recently about data centers in space. If we have this energy source to tap into on Earth, are we really going to be needing to look to do that?

GT: Just imagine a world where we have on-demand, clean, incredibly abundant energy, in a way that nothing else provides at this point. That's why for decades, scientists have been pursuing fusion, and now we pick it up because the market opportunity for fusion is a trillion-dollar market opportunity, and being one of the first companies to get there, capture that market, and deliver is our goal.

SN: One thing you can offer some good insight into is the funding environment right now. Is AI sucking all of the oxygen out of the room?

GT: If you think about the tailwinds for fusion, and they're threefold, right? You got this huge demand for energy, a desire to do that in a clean way, and this AI power crunch that's exasperating all of that. And those are the long-term tailwinds.

And the investors that have been a part of our journey recognize that those are long-term tailwinds. And the goal is to not just demonstrate fusion, but to capture those tailwinds by commercializing fusion. And that's been our goal from day one. And so even though there's a lot of capital flowing into these other areas, underneath all of that, we're still gonna need energy.

And that's the long game that creates this trillion-dollar market opportunity, starting with our first of a kind in 2035.

SN: So when's the last generation that didn't fight a war over access to energy? There’s a clear national security interest in terms of developing energy. In the US, there’s been a lot more of a muscular industrial policy — we’ve even seen Canadian-based critical minerals producers receive equity financing from the US government. And I know you have, you know, support from the Canadian government in terms of R&D funding from crown corps, federal and provincial governments, and partnership in the UK and with the US DOE. But would you like some more support form the US government, is that something you’d be advocating for?

GT: We work with governments all around the world actually, and we've had good support from the Canadian federal government on the financial side, but we have worked with the US DOE, won several awards there. We work with the UK, the UK Atomic Energy Authority, for example, on the science side. So we are a Canadian company, but operating globally because the market ultimately is global, and fusion energy will reorder how energy is produced globally. Some of the things that you just talked about, those challenges can be overcome with clean, safe, on-demand energy, and fusion can provide that in a way that fission and traditional nuclear can't.

Many programmers are not as impactful as they could be because they are looking at the code. Looking at the code is suboptimal and often pointless. The amount of code that LLMs generate makes it impractical to read, understand, and edit every line of code. It's more efficient to just control the ideas - how things work, what is the best design, and how to reach a certain level of performance - and then check the implementation for correctness.

The Most Human Technology Ever Made

Most people aren't trying to save time. They're trying to spend it.

People are happier when they make things. The table your neighbor built himself beats the one he ordered from West Elm. Kids abandon their expensive toys by lunchtime and then spend all week making a basement fort with the boxes they came in. We know this about ourselves and yet we keep half-forgetting it, partly because most of the technology of the last hundred years was built to do the reverse: to let us have more while doing less.

That technology is wonderful. I can summon a (self-driving!) car or order groceries that show up in an hour. But almost none of it is what I’d point at if you asked me what makes a life worth living. A paintbrush has never saved anyone a single minute, and we’ve kept them within reach for tens of thousands of years.

A while ago, Eugenia Kuyda, who has spent years building AI consumer products, said something to me that I keep coming back to. Most people, she said, aren’t trying to save time. They’re trying to spend it.

Almost everything anyone says about AI, for it or against it, is an argument about time. Will it take jobs or augment them? How many minutes has the model shaved off writing the memo, and then off of reading it? Were the tokens worth what they cost?

But I think the more interesting thing about AI is that it’s also the other kind of technology, the paintbrush kind, the kind that lets us express ourselves as humans. A few technologies in history have managed to be both: language, the printing press, and the steam engine are all tools that saved enormous labor and, almost as a side effect, expanded what a person could be. AI belongs to that small category. It makes making things feel more possible.

Why does making matter so much more than consuming? Oliver Sacks had an idea late in his life that I keep coming back to. He observed that most people treat being present as the goal, as if the whole point of living were to sit inside the current second. He thought that was a little sad. The people he found most alive were soaked in the past and future at once: remembering, planning and dreaming. That’s what making does to you. It stretches you across all three tenses, because you’re building toward something you can already see, out of everything you’ve ever loved. Consuming, by contrast, parks you in the now.

Take social media. At the start it was a little miraculous: people taking the time to share what was happening and what they were thinking with each other. Then it became a contest. A call for attention. And once the algorithms took over, the thing that broke through was whatever was loudest, so people optimized for loud, and lately we’ve started calling the machine-made version of it slop.

But the feed was slop before any machine got involved. Slop is just what you get when everyone consumes and nobody creates, and the cure is people making things again, which AI is unusually good at enabling. That’s about the most anti-slop thing I can imagine. A companion you talk to and shape and argue with will do more for you than a celebrity you watch from across the internet, because one of them is a thing you make and the other is a thing that happens to you. It’s the difference between putting on an autogenerated Spotify playlist and making somebody a mixtape. A mixtape is you, smuggled into another person’s afternoon.

And this isn’t reserved for creatives. A master electrician in Kentucky with no computer science degree used AI to build a load-calculation tool that sells for $12.99 and replaces a $500 service call. A plumber canceled a $40,000 consulting contract after a single afternoon with OpenClaw got him further than the consultants had scoped in weeks. For most of computing history, if you couldn’t code, you were a consumer of other people’s ideas. That’s over. The cost of trying things has collapsed, and the people picking this up first are not the ones anyone predicted. Software is about to be everywhere the way YouTube made video everywhere, and most of it will be built by people who’d never have called themselves builders.

The same thing is arriving in the time you spend at home. The McKinsey-esque (and unimaginative) version of the promise of AI is that everything in your life will get ten percent more efficient. The better version is that every year or so, you’ll find one new thing to fall in love with and pour your free time into it. None of this matters, in the big serious sense of the word, which is the good news, because the things that don’t matter are usually the things people love the most. Fan fiction. A kid DJing in his bedroom. Some ridiculous game you and your daughter invent on a rainy Saturday. It’s also where nearly every great consumer company has ever come from. As my partner Chris Dixon said, the next big thing will start out looking like a toy.

Work is the same story. The good part of any job is the stretch where you’re doing the thing you’re genuinely good at, and everything around it, the politics and the status and the meetings about other meetings, is a tax you pay to get there. AI is starting to eat the tax. As it shrinks, the job feels more like yours, more like the thing you’d have done anyway. And the part of work that feels like play is where the real breakthroughs have always lived. The good ideas almost never climb out of strategy books. They come from some side quest a person went down because they couldn’t help themselves, the strange weekend project, the rabbit hole that paid off.

There’s an old story about the moment the hippies turned into the finest capitalists the country had ever produced, well-explored in David Brooks’ book Bobo’s in Paradise. All that sixties individuality, the stuff that was supposed to be the sworn enemy of money, gradually evolved into the engine of it. The war between the strivers and the rebels didn’t end with a winner; it ended with a merger. Being a distinct person stopped being a rebellion and became the whole economy (some companies that exemplify this include Ben & Jerry’s, Restoration Hardware, and Range Rover).

What I want is more of that, pushed harder. Individuality at scale. Which is why the frightened version of the AI story, the one where a few companies own everything and everyone else sinks into a permanent underclass, has always felt to me like the wrong story. The side quests and the rabbit holes and the weekend projects don’t ladder up into a neat diagram of who owns what. Whatever barbell this thing creates, you’ll feel it first in the texture of your own days, in what you get to make and who you get to become, long before it ever turns into a chart of how society is arranged.

Look at the people who already use this stuff all day. They haven’t gone limp and checked out. They’re working more, and they’re further into it. People who spent years as spectators of their own ambitions are finally actualizing them. Give someone the means to build the thing they’ve been carrying around in their head, and they don’t lean back. They lean in. They stay up too late, and they text you at 2am to show you what happened.

A few months ago I went on a strange guys’ trip where the daily routine was four hours on our laptops in the morning, then padel, then a long dinner, and the dinner was mostly four grown men showing each other what they’d built that morning. That felt like the future to me, mostly because of how badly everyone wanted to show their work.

Here’s what I think happens when execution gets cheap. For most of history, the bottleneck on making something was never the idea, it was the grind: acquiring the years of skill, raising the money, assembling the team, and getting the permission. So most people’s best ideas died inside them, unmade. Lift that bottleneck and the thing that decides what gets built is no longer whether people can justify the VC funding or the enterprise-level capital expenditure, but who has something to say. The most human thing about you stops being a private quirk and starts being the point.

Individuality was supposed to be the luxury you bought once you’d made it. I think it’s about to become the thing everyone gets to spend their life on, the work itself. So when I picture where this goes, I see a lot of people making strange, beautiful, slightly pointless things and handing them around to see what happens. The toys were fine. But we always wanted to play with the boxes.

Senior design, product, and research leaders with 10 years or more at the company are out, in a restructuring the chief executive calls speed and some staff call cost-cutting.

“The design team is a little smaller now,” Edward Mitchell, a Sonos designer of roughly 12 years’ standing, wrote on LinkedIn as the audio company parted ways with a swathe of its most senior product and design leaders.

Sonos has pushed out several long-serving executives in recent weeks in cuts that reach far higher up the organisation than a routine trim.

Among those leaving are Dana Krieger, a vice-president of design with 12 years at the company, Kate Wojogbe, a senior user-experience executive of nearly a decade, and Scott Fink, a 15-year veteran who helped build the home-theatre business that gave Sonos much of its living-room identity.

The losses run right through the teams that shape how Sonos products look and feel. Michelle Enright, who led packaging and product sustainability, left after 14 years, and Sara Lincoln, a hardware product manager, departed after 11.

Rebecca Phillips, a user-experience researcher, wrote that “nearly the entire UX research team was let go,” while Kristen Leclerc, who ran user research, was also among those cut.

The departures sit within a broader reduction. Sonos confirmed last month that it was cutting about 3% of staff, weighted toward the user-experience and product groups behind its app, the same software it has been painstakingly rebuilding after a botched 2024 overhaul triggered a customer revolt.

Chief executive Tom Conrad framed the changes as a matter of speed rather than savings. In an internal memo seen by Bloomberg, he wrote that he wants “a Sonos that moves with more conviction and more velocity,” with “fewer months in conference rooms” and “more prototypes in our labs.”

The stated aim is to strip out management layers and make the company nimbler.

A company spokesperson said Sonos still has experienced leaders across the affected teams and that user-research work would continue, and stressed that the cuts were not related to artificial intelligence. That last point sits a little awkwardly next to Conrad’s own words.

On a May earnings call, he said AI was “already transforming how we operate internally, from the way we build software to how we execute marketing to how I run the company.”

The company’s insistence that the reductions have nothing to do with automation makes it something of an outlier at a moment when many firms are explicitly pinning cuts on AI.

Not everyone inside the building accepts the official framing. Some longtime staff reportedly see the layoffs as primarily a cost-cutting exercise, and worry that removing experienced designers and researchers will hurt both future products and the culture that produced them.

The timing is delicate. Conrad took over from Patrick Spence, who stepped down in early 2025 after the 2024 app redesign sparked a rare consumer backlash and dented Sonos’s hard-won reputation for polish. Initially installed on an interim basis, Conrad was later confirmed as permanent chief executive.

For a company whose identity rests on design and hardware craft, losing more than a decade of institutional memory in a single round is a gamble. The people being let go are, in several cases, the ones who shaped the packaging, the interfaces, and the home-theatre systems that made the brand feel premium in the first place.

Sonos says it is still developing new products, including a second-generation Ace headphone and updated home-theatre gear, and Conrad is betting that a leaner, faster organisation will ship them sooner.

The pitch to investors and staff alike is that fewer meetings and more prototypes will translate into a quicker cadence of releases. Whether velocity can substitute for the experience walking out of the door is the question hanging over the restructuring.

The worry voiced by former employees is not that Sonos cannot build its next speaker, but that the harder, less obvious work of dreaming up a breakthrough product tends to rest on exactly the kind of senior judgment now being cut.

Apple is reportedly planning new versions of the Apple Pencil (USB-C) and Apple Pencil Pro to launch alongside new iPad Pro models in spring 2027, with redesigned battery systems that users can replace themselves. The change is expected to help Apple comply with new EU battery regulations that take effect in February 2027, requiring portable device batteries to be removable and replaceable by end users. While making the Apple Pencil compliant appears relatively straightforward, meeting the same requirements for products like AirPods will likely be much more technically challenging.

Career advice for designers

Common problems with design career advice

Career advice is common amongst designers. Often from respected designers. But I see common problems with some advice.

1. The advice reflects an ideal situation/perspective: Many designers who give advice work for closer-to-ideal companies than the majority. The company they’re associated with is doing things in the right way. This advice isn’t as useful to designers who, statistically, will probably apply to/work for companies that don’t do things in the right way. e.g. “Your portfolio doesn’t need to be beautiful, it just needs to explain your process” isn’t helpful when most companies do seem to be impressed by beautiful portfolios.
2. The advice is from someone who doesn’t decide whether you’ll be hired: Career advice, especially about how to get a new job, should come from people who decide whether or not designers will be hired. Other designers might not have enough insight into the hiring process.
3. The advice reflects that designer’s career path only: Designers often give advice about what skills to learn, what topics to dive into, or what kinds of companies to work for. Generally these represent the career path of the person who gives the advice. But other career paths are possible, and might be better for the advice-seeker’s situation.
4. The advice reflects the designer’s current focus: Some designers claim that X is most important (e.g. research, people skills, documentation). In these cases X is generally what the designer who gave the advice is currently focused on. They feel that other areas of design are less important because they’re less important to them, now. In fact those other areas may be just as, or more, important. Especially for people in other situations.
5. The advice reflects the designer’s current view: Some designers notice that changes are happening. They give advice based on what they’ve noticed. And it might be true that “everyone they know is going through this”. But they probably know less than 1% of the design community. Their advice might be irrelevant to people who are not part of the design industry slice they can see.

The five minute design curriculum

You’re guaranteed to be a good designer if you put these five lessons into practice.

1. 1. Learn like a beginner: Always assume there’s more to learn, whether you’ve been a UX designer for one year or one hundred. Learn about your colleagues’ work, and the fields related to design. Be humble.
2. 2. Find good design: You develop your taste and personal style when you look at good design. You improve your craft when you pull it apart to understand how it was made. You can use a personal catalogue of good design as inspiration.
3. 3. Explore a lot: When you need to understand, research for as long as you can. When you need a solution, come up with as many ideas as you can. Once you’ve chosen an idea, iterate until you can’t.
4. 4. Make a lot: As much as you can. Quantity leads to quality, so practice regularly.
5. 5. Share your work: Ask your colleagues and community what they think. The feedback will help you improve, and the exposure will grow your network.

What outsiders look for in a good designer

Usually when I ask designers what “good” means, they don’t want to define it. This fascinates me, so I hunted for definitions and found eight.

This list is supposed to be cynical and practical. It lists the factors that other people might rely on to figure out if you’re a good designer. You might feel they’re not fair.

1. A good designer gets results: The designer moves whatever needle needs to be moved. Perhaps the conversion rate goes up by 5% when their design is built and released, or internal teams get their work done 50% faster because of improvements to internal tools.
2. A good designer gets stuff done: The designer’s output is very good, regardless of the outcomes. They have a productive attitude to their work and are willing to get stuck into anything and see it through.
3. A good designer makes impressive design: The designer makes design that is beautiful, has lots of impressive details, and represents the skills of a good craftsperson. This is about visual design but also interactivity details that impress people. Fluid animation, fun microinteractions, etc.
4. A good designer is creative: The designer comes up with ideas that others don’t.
5. A good designer is knowledgeable: The designer knows everything about design. If you have a question about design theory, this is the first person you go to. They recommend books, articles, videos, other designers, websites, and more. They have a vast library of design patterns in their head.
6. A good designer has social proof: The designer has, for example, lots of followers on Twitter; gushing testimonials on their portfolio; a strong referral from another good designer; respected design awards; or has worked with impressive companies like Apple, Stripe, and Nike.
7. A good designer works well with others: The designer is humble, and a good listener. They understand their teammates’ work, needs, and language. They’re able to present their designs effectively to anyone. They can sell their work. This is about good collaboration and communication.
8. A good designer is a good product manager: There is already overlap between the work of designers and product managers. In smaller organisations where there is no product manager, a good designer might be expected to deeply understand the business, its customers, and the problem (and reframe it where needed). They might also be partly responsible for product vision.

Factors of a good interface designer

Knowledge

• Pattern knowledge
• Trend knowledge
• A desire to learn more
• A desire to explore good design

Experience

• A sense of where to start/what will work
• Good taste
• Good judge of your own design and others’
• Comfortable working in many styles
• Willing to have a strong opinion

Creativity

• Novel ideas
• Exhaustive exploration of options/approaches
• Exhaustive iteration

Quality

• A preference for quality
• A preference to test designs
• Open to feedback
• Able to balance classical and expressive aesthetics
• Able to balance aesthetics and usability
• Obsessed with details
• Rigorous

Technical skills

• Good typography
• Good composition/layout
• Good colour choices
• Good at some associated skills (e.g. prototyping, animation, imagery, writing)
• Tool expertise

Wider picture

• Informed by understanding of the product (e.g. research)
• System thinking (how the work is connected to other things)
• Product thinking (what makes a successful product)
• Development thinking (how a design might be implemented)
• Practical mindset when necessary
• Believes in importance of accessibility

Communication

• Able to articulate your design “feelings”
• Able to explain design principles to others
• Can clearly document/explain the design (e.g. specifications, mockups)
• Good relationship-building, especially with developers
• Able to “sell” a design idea

Defensible visual design

When you show your visual design to people, they might ask questions or challenge your decisions. Here are some notes on how to make your visual design easier to defend.

Note there are steps you can take to avoid questions/challenges in the first place, e.g. managing expectations. They are not covered here.

1. It’s possible to design by taste/intuition alone. But that’s best when everyone trusts you. If you work in a low-trust environment, it’s harder to fall back on taste.
2. Tie every visual design decision back to a project goal or the brand of the organisation/system.
3. Some organisations have secret goals they don’t like to admit (e.g. “we want to look like the industry leader”). Your visual design might be judged against these goals. The better you understand them, the less vague feedback you might get.
4. Every decision in your visual design should be intentional. You should be ready to explain the decision behind every pixel if necessary.
5. If every value in the style (e.g. spacing, colours, text size) is related to every other value in some way, you can explain why you chose the values you did.
6. Prefer accessible values whenever possible. If someone doesn’t like a decision, it’s better to point at an objective goal like accessibility than a subjective one like “I like how it looks”.
7. You want to avoid any situation where it’s your opinion versus the opinion of someone with more power than you.
8. Tie decisions to clarity. Whether people can understand something is universal and easy to measure. Something like beauty is much harder to measure.
9. Look to industry and competitor standards where it’s sensible. That’s what many of the people who use your product will be familiar with.
10. Tie decisions to how your company or product already does something. It’s easier to argue against something if it’s novel.
11. Explore as many options as you can. Even ones you don’t think will work. If someone suggests one of those options, have it to hand so you can show why it doesn’t work.
12. Tie visual design decisions to interaction design or commercial benefits, e.g. “this helps guide people’s attention to the call to action”.
13. Don’t only use styles or techniques only because you saw them somewhere else/they’re popular. Find another reason to use them.
14. Make sure your visual design choices are technically possible/easy.

How to look impressive without impressive projects or jobs

Some designers have worked at companies like Airbnb and Nike. They have impactful projects in their portfolio. They glide into new jobs.

But what if you’re an absolute loser like me?

Here are 10 (not at all easy) ways to look good and impress other people.

1. Become an expert in a niche/specialist topic: Learn so much that you become the go-to person on accessibility. Or visual design (it me). Or design systems (it everyone else). Read all the books. Seek out the forbidden knowledge. Build a moat out of the stuff in your brain.
2. Perfect a niche/specialist skill: Really good animation looks cool. So learn how to do that. Or be the best information designer. As long as other people value it. I believe in you. It’ll only take you five years of gruelling effort.
3. Make a beautiful portfolio: Craft a website that designers swoon over. Pixel-perfect details in every corner. Like that one scene in Pulp Fiction, where they open the briefcase and golden light shines out? But with a web browser, and it’s your portfolio.
4. Make beautiful mock-ups: Everyone finds good visual design impressive. So make the best, and share it around. You think people are going to be annoyed that you’ve shoved something beautiful under their nose? NO. They’re going to thank you and fall at your feet.
5. Make impressive interaction demos: Design the best interactions. Full of fiddle factor. Record videos of them in action. Whack ’em on the internet.
6. Become a mentor: Share what you know with other designers. Not only does this show that you know things, it also helps you refine how you share what you know with others.
7. Network with community regulars: Go to all of the events. Speak to everyone. Show interest in their work. Talk about your work, but don’t boast. Keep in touch with them.
8. Get impressive testimonials: As you impress people more and more, they’ll say impressive things about you. Write those things down. Put them in public places. Social proof, baby.
9. Gain a lot of Twitter followers: You know what everyone loves, even if they won’t admit it? Big numbers. 10,000 followers on Twitter? People assume you must be doing SOMETHING right.
10. Create a popular design resource: Write a book. Create a course. Make a wallpaper pack. Give it away for free. Or charge for it. Either way, make something that other people want, and make a note of how many people wanted it. More big numbers.

A practical career approach for generalist designers

There are as many career approaches as there are designers, but this is what I’d recommend to a new designer.

Work experience

• Do a small research and design project:
  1. Find out why people use your local government’s website.
  2. Test the website with people to see how easy it is to do those things. Note down all of the problems.
  3. Pick the biggest one and design a new page/flow.
  4. Test the new design with new people to see if you’ve improved it.
• Find real projects on websites that match skilled people with charities.
• Give design help to an open source project.

Portfolio

• Make your portfolio beautiful. First impressions count, and your portfolio is a design project as well.
• Put as much detail in your case studies as you want. But make sure that someone who skims through a case study in 30 seconds understands what you did and what impact it had.

Exposure/networking

• Post beautiful work often on a major social network. People are impressed by beautiful work.
• Explain interface design concepts for other new designers.
• Respond to designers you like with genuine questions. Not all of them will answer.

Signs that an organisation values interface design

An organisation may not meet all of these, but may still value interface design.

Company structure

1. Enough designers are employed
2. Design is represented directly at the top of the company
3. Designers are expected to work closely with other teams

Culture

1. Designers are seen to be experts
2. Developers are willing to spend time on the small details necessary for good design
3. The company has a strong design culture (e.g. celebration, understanding)
4. The company’s products are opinionated (i.e. they have strong opinions about how products should be, and they stick to them)

Responsibility

1. The company sees design as a source of significant commercial value
2. Designers are relied upon to affect outcomes, not produce outputs
3. Designers are empowered to work effectively and efficiently

Priority

1. The company spends significant amounts of time on design
2. Quality is prioritised over other things (e.g. scope and deadlines are lowered before quality)
3. The company believes it should prioritise good interaction and visual design, even if there’s not an obvious commercial case
4. The company believes accessibility is important

Understanding

1. Design work is informed by discovery work
2. Design work is validated (e.g. usability testing, analytics)

Quality

1. Iteration after release is normal
2. There are few to no paper cut bugs in the product

Professional development

1. Designers are paid well
2. Designers are helped to improve their skills
3. Designers can easily work with their preferred tools
4. The company has good retention rates for designers

Community

1. The company shares public knowledge about its design practices
2. The company’s products set design trends
3. The company has made a name for itself for “good design”
4. Designers want to work at the company

The worst-case software company

Most designers won’t work for an ideal software company. Especially at the start of their career. Here are some things that might be true about the average software company.

Leadership

• You report to engineering rather than design or product.
• The CEO wants to be involved in product decisions despite bad judgement.
• The company exists to carry out the wishes of the CEO or clients rather than discover problems and solve them.

Roles

• You are expected to produce mock-ups rather than help define the right solution.
• The product team are project managers. They keep work on track. They don’t decide if work is worthwhile.

Priorities

• There is never enough time to fix paper-cut issues.
• Priorities change often, so projects are abandoned before they are built.
• “Redesign it from scratch” is always preferred over “improve it incrementally”.

Design process

• The company says it values research but allows no time for it, or ignores findings. You may be allowed to do competitor research.
• The company has a design system because they believe they should have one, but it is out of date and no-one maintains it.
• The existing poor visual design style constrains your own visual design skills. You cannot do your best visual design work. It will look out of place if you do.
• If there are other designers, you work on your own projects. You don’t collaborate with other designs.

Feedback

• Feedback is in the form of “change this”, and not “here is a problem, please fix it”.
• Leaders need high-fidelity design before they can discuss it or give feedback.
• There is no easy way for you to challenge feedback from leaders.
• Design feedback mostly happens in cross-functional demos. Lots of pepople with various amounts of understanding pile on your work.
• The CEO sees the work for the first time after a lot of work has happened, and asks you to re-do everything.

Implementation

• Developers do not notice or prioritise the small details that you care about. You must either document everything or accept compromises.
• If you document everything it will not be read.
• Technical debt stops improvements to parts of the product.

Product quality

• No iteration happens on shipped features. All of the improvements discussed for “version 2” are left behind as you move on to the next feature.
• Even if leadership says they believe in “ship it then iterate”, if a feature does not meet their personal expectations they will demand you change it before you can ship it.

Cynical advice for designers

I do not follow all of this advice. But it’s clear that some designers take advantage of it.

Visual design

1. “It looks good/interesting” is a valid reason to make a visual design decision if you want to impress people.
2. The more structure and imagery (including icons) you add to a design, the more “designed” it looks.
3. The more expressive your design, the more impressive.
4. The more effort your design apparently took, the more impressed people will be.
5. It’s often enough to make a simple design and put in an impressive visual centrepiece.
6. It’s easier and usually nearly as effective to copy someone else who’s better than you. Don’t copy one person directly. Mix inspiration together.
7. Lean on the good work of others, e.g. use high quality imagery and typefaces.
8. You can impress people with simple design if you do a series of small designs, which belong together as a set, with small variations between each one, e.g. a series of home screen widgets.
9. Some interfaces (e.g. a calendar full of colourful blocks) are more visually interesting. You can impress people more with the same amount of effort if you focus on those.

Presentation of work

1. Put more than one related mock-up in the same image. More visual design is more impressive.
2. If you have many mock-ups, put them in an orderly grid of some kind. It gives people’s eyes something to explore, and they’ll be impressed more.
3. Annotate your mock-up with call-out lines, etc. This allows you to add technical/fiddly elements (the annotations) even if your mock-up doesn’t have any.

Career

1. Good visual design impresses customers, colleagues, and hiring managers.
2. It can be helpful if people believe design is magic. When you are vague about your process it promotes that idea.
3. Post impressive work consistently on social media to get a following.
4. People who screen job applications often don’t work in design and look for key words. Your application should use the words they know, not the “correct” words.
5. Many hiring managers look at your application for a minute. First impressions count.
6. If you are impressive in one area you can be less impressive in another. e.g. if you’ve got a prestigious company on your CV you don’t need an impressive portfolio.
7. 95% of software is boring, and 95% of us will work on boring software. You don’t need to learn impressive new technologies or skills to work on boring software.
8. If you have strong opinions and good taste in software, you won’t be able to express those fully at 95% of companies. You’ll either need to accept that you can’t produce your best work, or start your own company.

Collection of the most essential UI transitions for web apps. Copy and paste them, or use them with skill directly in your project.

Open canvas where ideas become visuals. beta

Generate images, create videos, edit and compose — all through a simple conversation with AI. No design skills required.

Powered by Nanobanana, Kling, Grok, and Veo — generate from text, turn photos into video, and edit on a visual canvas.

Everything you need

Video Generation

Turn text or images into video. 1–8 seconds, up to 1080p. Product demos, ads, animations.

Image Generation

Any style, any size. From photorealistic product shots to illustrations and concept art.

AI Agent

Describe what you want in plain English. The AI agent thinks, generates, edits, and arranges for you.

Ready to create?

Open the editor and describe your first visual.

Free The Icons

Apple should end their prohibition on shapes in MacOS app icons

With last year’s release of MacOS 26 (Tahoe), Apple made a mess of app icons. In the first betas of MacOS 27 (Golden Gate), however, there are signs of a turnaround. We’re urging Apple to continue making improvements, by restoring the ability for MacOS app icons to have distinct shapes.

Apple’s Liquid Glass App Icons

In Tahoe, Apple modified the icons for dozens of their first-party apps to give them a “Liquid Glass” appearance. The changes were a substantial regression, leading to blurry, dumbed-down icons.

With the recently unveiled Golden Gate, Apple has again updated their MacOS app icons. This time, however, the changes are genuine improvements. Here’s the refined Automator icon, for example:

The newer icon is sharper, with superfluous Liquid Glass removed. Dozens of Apple’s apps have seen similar updates. The result is that Golden Gate’s icons are superior to Tahoe’s, as this comparison from Basic Apple Guy shows. Seeing these improvements led me to think about another fix Apple should make in MacOS.

The Problem of Tahoe’s Dictated Squircles

With the Tahoe release, Apple didn’t just mess with their own icons. They also dictated the shape of every third-party app icon, forcing them to adopt the same prescribed squircle. Any icon that failed to do so found itself shrunk down and imprisoned in an ugly gray background, in order to fit Apple’s desired aesthetic.

To avoid this icon jail, developers were forced to redesign their icons to match Apple’s preferred form. After decades of beautiful, memorable Mac icons in varying shapes, Tahoe flattened personality to obtain bland uniformity. The platform is worse for it.

Past icons weren’t just more expressive. They were also more usable. Having distinct shapes provided a useful way to tell icons apart. Tahoe eliminates that cue by forcing everything into the same squircle, leaving color as the primary way to tell icons apart at a glance.

That falls down if you’ve got color vision deficiency, or even just multiple icons with similar color schemes. I’m looking at you, Slack and Photos. I have to look closely, because it’s so difficult to tell you apart now.

It Doesn’t Have to Be Like This

Apple’s prohibition on shapes is a step backward for both usability and creativity in app icons. Icons are now harder to distinguish because they’re no longer allowed to be distinctive. But there’s no technical reason for it. Apple could, and should, once again allow icons to take on a wide variety of shapes.

It’s clear that some people within Apple recognize that the transition to Liquid Glass introduced mistakes. They also appear to have the authority to fix those mistakes. Refinements to Apple’s own icons in Golden Gate are a welcome course correction, as is the much-celebrated Liquid Glass opacity slider. It’s time to correct the mistake of banning icon shapes as well.

Apple should stop forcing every icon into the same squircle. Let’s return to a world of gorgeous app icons like these:

Free the icons.

Footnotes:

1. With color now so critical to tell icons apart, it should be no surprise that the new “Clear” and “Tinted” icon styles added in Tahoe are seeing so little uptake. As Adam Engst noted, “[I]t’s nearly impossible to identify a particular app when they’re all clear or tinted squircles, as you can see below. My brain just shuts down when it sees them.”

   I’m not sure this “Tinted” style would be a good idea even if these icons had distinct shapes, but I know it’s a very bad one given their uniformity.

2. For folks within Apple, this was feedback filed as FB23388490 (“Third-Party App Icons Should Not Be Restricted to Apple’s Dictated Squircle Shape”). I imagine it is a duplicate many times over.

AI is emerging as a transformative tool, empowering individuals to create and innovate, rather than just consume. It reduces the barriers to production, allowing people without technical backgrounds to build practical and creative applications. Unlike consumption-focused technologies, AI nurtures individuality and creativity, fostering a culture where personal projects and ideas can flourish and become meaningful contributions.

Manus Auto-Publish allows automatic deployment of successful builds to live URLs without manual intervention.

Intelligence and the economy are converging into a single new system.

Several states are preparing to file a lawsuit to block Paramount's acquisition of Warner Bros. Discovery as soon as this week. The lawsuit claims that the $111 billion deal would harm competition in the market for tentpole films. Paramount says it is prepared to address legitimate antitrust issues and that the merger raises no such concerns. The companies plan to close the deal in the third quarter of this year. Paramount will pay Warner Bros. Discovery's shareholders about $650 million in cash for each quarter the deal doesn't close starting in October.

Olympiads breed people who normalize hard work and don't shy away from intense competition.

Create product demos, explainers, training videos, and support replies from your first product launch to every customer touchpoint.

Fixing a struggling design team starts with diagnosing root causes—like lack of trust or unclear goals—rather than reacting to surface symptoms such as poor morale. Interview teammates individually, identify allies and resistant "liabilities," then tackle one small, fixable problem to build momentum. Trust grows gradually, and leaders themselves may be a major source of team dysfunction.

I Shall Name the Dead is a surreal magical-realism horror adventure with hand-drawn, graphic-novel-style art featuring eerie orange-and-teal visuals that evoke fragmented memory and grief.

A viral trend of fan-made alternative movie posters showcases more creative and memorable designs than many official posters, highlighting how formulaic and celebrity-focused modern movie marketing has become.