I care about Bun. I have been rooting for it since the initial release in 2022. I switched all my development from Node to Bun. I used it in the development of the Nue framework and now with my new project Hertta.

The last three months have not looked good for Bun. It started as one of the most impressive individual engineering projects I have seen, but has now turned into this weird AI-powered creature with continuous false promises and an increasingly frustrated community.

In the next version of Bun

In the next version of Bun used to be a positive tweet to watch for. For years it meant a feature had been implemented, tested, and would ship in a few days. This changed after the Rust rewrite. Now the posts are false promises about the upcoming release:

It’s now three months and counting since the last stable release, the longest gap in Bun’s history since 2022. Nothing unusual there. Software slips, that’s normal. It’s just that an account which used to communicate with real dates and real numbers has switched to vibing. And the user reaction is what you’d expect after constant false promises:

Bun on GitHub

The Bun 1.4 rewrite is a big bet on AI. In the past month, 15.8k commits came from robobun, 1.6k commits from autofix-ci[bot], and 790 commits from Jarred.

The project has over 5k open pull requests, which is the largest number of pull requests I’ve seen. For comparison, OpenClaw has 2.2k, and React has 441. GitHub recommends staying under 1,000 open PRs against a single branch before mergeability checks start timing out.

The biggest worry is, of course, the code itself. In the early days Jarred’s work was inspirational. I thought he was a true Zig talent, until I read Zig creator Andrew Kelley’s thoughts on the Bun rewrite:

What was the problem with Zig?

This rewrite is the most closely watched real-world test of whether AI agents can take over a production codebase with a human mostly directing rather than reading. Anthropic’s own reputation is also on the line: if this goes well, it is real proof of what agentic coding can do. If it goes badly, it will send a signal in the opposite direction.

The number of unsafe blocks in the Rust code suggests the rewrite did not deliver the memory safety that was given as the reason for doing the rewrite in the first place. Instead this rewrite feels more like an Anthropic ad.

And was Zig really the problem? Bun’s early identity was built on Zig: its performance, its fast compile times, its low friction, its direct memory control with a small team.

It feels like Jarred and Anthropic decided early on that this was going to be written in Rust, and used Zig’s memory issues as the excuse to let the world know how powerful Claude is. A rewrite like this would make great headlines, and it certainly did. Now we’re looking at the long tail of issues from the rewrite they didn’t prepare for.

Maybe Bun should have put that same AI-assisted effort into disciplined, human-understood Zig instead of a full language change. I never saw Jarred seriously engage with this option.

And ‘tomorrow’ has come and gone. Still no v1.4.

¯\_(ツ)_/¯

The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.

One of the comments I hear often lately boils down to “LLMs may be good at coding, but software was never the hard part” and “coding is easy, it's figuring out what to code that's hard”.

I believe that's a gross insult to all programmers everywhere.

If coding is easy...

If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?

If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?

If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?

If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?

If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?

If coding is easy, why is software so damn buggy?

If figuring out what to build is the hard part...

If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers?

If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?

If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for!

If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?

Another cliché comment is “most work in software development is talking to stakeholders, understanding the customer's needs, and having clarity on the priorities”.

I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”.

Some software developers do say “I don't write code, I solve customer's problems”. But then they turn around and start to opine on monads, memory safety, and DRY principles, while their understanding of the customer is a made-up “user persona”, and they think “affordance” is the money your parents used to give you on weekends so you could go out and have a good time.

Yet others will say “Software development is theory building”. Programs are actually proofs (as in, mathematical proofs). Every commit should tell a story. And solving a customer's problem by FTPing a PHP file is a cardinal sin.

I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho. (post-scriptum edit: this sentence was way overboard; I meant it as tongue-in-cheek “very few people can do that” and I do actually advocate for that in the next section. mea culpa)

What is important?

I do believe that talking to users, understanding their experience, empathizing with them, solving customers' problems and having all the stakeholders on the same page is critical to the success of a software project.

I also believe that creating good code is a craft that requires skill, patience, attention to detail, experience and wisdom, and that it will continue to be relevant in the times ahead.

¿Por qué no los dos?

To the extent that we can pull it off, I think we should aim for both. A deep understanding of the system we're building, together with a deep understanding of why we're building it.

Loudly proclaiming that “code is easy” or, at the opposite end, “code is art, a creative human expression that cannot be automated”, is just burying our heads in the sand.

It's cope. And you don't want cope, you want to thrive.

By this, I don't mean “jump on the LLM bandwagon.” I don't mean “become a manager of fleets of AI agents.” I also don't mean “AI-generated code is stolen slop garbage, fight it with tooth and nail, the bubble will pop soon enough anyways.”

But do recognize we're in the middle of an industry-wide tectonic change. We need to figure out how to adapt. We need to understand what is likely to change and what never changes.

What doesn't change?

Software will be getting more complex. Software will always need maintenance: bit-rot is a fact of life. So is entropy. Technology (hardware and software) will move forward, for better or worse. The tower (skyscraper?) of abstractions grows ever higher.

Users will always want more and be prepared to spend less. They still won't know how to relay their needs and wants. Worse, they still won't know exactly what they want. The disconnect between the customers (who actually pay for the software) and users (who use it) will still be here, as will the tension between the needs of the business and the needs of its customers.

Also: there will never be a shortage of snake oil salesmen. Tech du jour comes and goes (I'm still waiting for the new VR renaissance!)

What changes?

Programmers have been in the business of disrupting our own industry since the beginning. Nobody uses punch-cards any more. Very few people need to code in assembly, or COBOL. Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless in the age of Rust, Go, Python and JavaScript.

I'm old enough to appreciate valgrind or remember mysql_real_escape_string() from the PHP4 era—stuff I'll never again need in my life. And that wasn't even so long ago! I narrowly missed the dBase, Clipper, HyperCard and Access era, technologies which I can still spot operating in shops, cafes, or a dusty, once beige and now golden-brown, midi-tower still happily running some bespoke biz solution (backups? what backups?)

How do we thrive?

Accept that change happens. Be equal parts curious and critical about the new stuff.

Understand there's a lot of hype and try to discriminate between hot air and what really works (and to what extent). Also be aware of ever-shifting goalposts: stand back and look at the past year, or five, and assess the velocity of change (technical, economic, societal).

Your role and your responsibilities will be changing. Be willing to invest time and energy into better understanding fields or roles adjacent to yours.

If you're a senior developer, don't just find solace in deepening your expertise. Learn about user experience, customer interviews, or business strategies for the companies in your domain. It will help you gain a better appreciation of all the work done to put a piece of software into users' hands, whether or not you'll actually ever have to do any of those other bits.

If you're just starting or are junior in your role: invest in deepening your understanding of how software works. Understanding pointers, recursion, or memory hierarchy will help you even if you're a JavaScript developer. Understanding network protocols and how HTTP works will be useful even if you're building WordPress plugins. Do leetcode and learn about algorithms and data structures even if you don't need to. Don't be afraid to ask why and how exactly.

For inspiration, here are a few books and other resources that might be helpful:

• Structure and Interpretation of Computer Programs (PDF)
• Cracking the Coding Interview
• The Mythical Man-Month
• Working Backwards
• Team Topologies
• 7 Powers
• The Soul of a New Machine
• Obviously Awesome
• The Design of Everyday Things
• Don't Make Me Think
• Continuous Discovery Habits
• The Mom Test

One more thing

Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI. Don't abdicate your responsibility. Don't be a meat proxy.

PS. Lots of interesting and insightful comments over at Hacker News and Lobsters—the post really hit a nerve. Fascinating how many different experiences people have and the varying definitions of coding, programming, development and engineering they use.

Back to Articles

In the AI world, time feels compressed. A few months after our spring report in our biannual analysis worked through the ecosystem, there are quite a few findings that we have observed until this summer. This report lays out these observations from January to August 2026 and presents the data behind each one.

Models and datasets on HF hub are growing on a daily basis. Public model repositories grew from 2.43 to 2.96 million over the period, datasets from 711,000 to 1 million, Spaces from 1.00 to 1.44 million. The distribution underneath stays extreme, roughly 85.6% of models have fewer than 200 lifetime downloads, and 1.5% of repositories account for 99.2% of all downloads. Everything below happens inside that shape.

1. The frontier is moving fast

There used to be a clear progression path: labs would start by releasing smaller models and gradually work their way toward the top end of the scale. In 2026, several Chinese labs skipped this progression entirely.

In almost every month of 2026, the largest and most performant open model from a Chinese lab was larger than any model an American lab released. China's monthly ceiling ran between 754B and 2.78 trillion parameters; U.S. models stayed under 130B in five of seven months, the exception being NVIDIA's Nemotron 3 Ultra at 561B in May and June, and Inkling from Thinking Machines Lab.

The chart splits the labs into two camps. Moonshot, MiniMax, Xiaomi and Z.ai publish almost nothing below 70B, so a developer's first encounter with them is a model too large to run on anything they own. Tencent and Alibaba Qwen cover the whole range instead, from under 1B upward.

Two things made the first camp possible. Building large stopped being a differentiator. Xiaomi, Ant Group and Meituan both cleared a trillion parameters this year, and neither was a household name in open weights twelve months ago. And a lab no longer has to ship a small model to be reachable, because the community's quantization layer will make a large one runnable within days, a dependency we return to below.

That leaves the size profile as a statement of intent rather than of capability. A frontier only portfolio stakes everything on benchmark position and API demand. A full spectrum portfolio is a bid to be the family developers standardise on. Both are rational, they are playing for different prizes.

The United States is not absent from open source.

The two organizations publishing the most new open models this year are also the companies making the hardware: AMD and NVIDIA. Each released more than 200 new model repositories, far ahead of the rest of the field, with LiquidAI ranking third at around 100. Hardware vendors have realized that open models are a way to sell chips: a model optimized for your hardware and freely available is the clearest proof that the hardware works.

When smaller models and embedding models are included, where Google, Microsoft, IBM Granite, and OpenAI’s older vision and speech models generate hundreds of millions of downloads annually, U.S. open source AI is growing.

More hardware and infrastructure organizations such as NVIDIA are training and open-weighting competitive models. NVIDIA's Nemotron model family boasts high performance. Long-time leaders such as Meta reignite open roots with Meta's Muse Glimmer.

At the frontier scale, some U.S. model releases above 100B parameters this year are built on top of Chinese models or leverage artifacts from Chinese labs, such as Thinking Machines’ Inkling (952B). Major original American models include NVIDIA’s Nemotron 3 Ultra (561B), Nemotron 3 Super (124B), and Arcee AI’s Trinity-Large (399B).

AMD contributed many conversions. This work is important: it enables trillion-parameter models to run efficiently on U.S. hardware. This represents a distribution and optimization layer.

Meanwhile, Chinese open models are increasingly optimized for domestic chips in China, the same competition in reverse, where models are designed around specific hardware ecosystems.

2. Attention ≠ Adoption

We took the top 25 model repositories by downloads accumulated this year and the top 25 by likes. Exactly one repository appears in both lists.

We counted downloads inside the window rather than lifetime, so nothing is credited for merely having existed longer, and controlling for age makes the split sharper. Not one model published in 2026 reaches the download top 25, while thirteen of the twenty-five date from 2022. all-MiniLM-L6-v2 was pulled 1.55 billion times in seven months against 5,156 likes; Kimi-K3 was pulled about 60 times per like it received.

The two numbers record different acts. A like says a release matters, and goes to frontier models in the weeks after they ship. A download says something is wired into a pipeline that runs on a schedule, and accrues to small, stable models over years. Likes are the right instrument for reading what the field is excited about, downloads for reading what it currently depends on. Treating either as a proxy for the other is the most common mistake we see in coverage of the Hub, including our own earlier work. The same split appears at the level of the publisher.

China's frontier labs are the only accounts on the Hub where the heavy band carries the volume. Effectively all of MiniMax's 2026 downloads are of models above 70B, along with 88% of Moonshot's, 55% of DeepSeek's and 39% of Z.ai's. No large American account looks like this: Google, Microsoft and IBM Granite record essentially none of their 2026 downloads above 70B, and NVIDIA and Meta only 14% and 9%.

The difference becomes clearer in total downloads. Moonshot’s frontier-only portfolio recorded 37M downloads over the year, while Qwen’s broader release strategy across model sizes reached 2,045M (across repositories with declared parameter counts, 2,061M including all repositories) , about 55 times more. The continued expansion of the family, from the 2.4T-parameter Qwen 3.8 Max to smaller variants such as 27B, shows the same focus on coverage across different use cases.

Time also plays an important role. Most models experience a sharp decline in usage after release, followed by a long tail of steady activity. A model’s adoption is largely determined within its first few months.

This helps explain why today’s download volume is often driven not by the newest releases, but by a smaller group of models that have become established infrastructure over time.

3. Open weights shift where value accumulates

If frontier models were a licensing business, you would expect the biggest releases to carry the tightest terms. However, the data below shows a different story.

Of 178 Chinese releases above 20B parameters this year, 59% carry Apache 2.0 and 22% carry MIT, and most carry a non-commercial restriction. However, in the last few weeks, we started to see a change on this trend for the really large models, with Kimi K3 and Qwen3.8 starting to include some non-commercial restrictions and revenue share requirements to their licenses

DeepSeek and Z.ai ship models between 700 billion and 1.65 trillion parameters under plain MIT. Chinese labs license their largest models about as permissively as their smallest, and more permissively than American labs license theirs: on the American side of the same size band, 29% is Apache or MIT, 41% sits under custom terms and 30% declares nothing at all.

Whatever these releases are for, it is not licence revenue. The weights are given away on the most permissive terms available. The return has to come from somewhere else: API and cloud business, hardware and platform positioning, or the ecosystem position itself. For instance, the valuations of Z.ai and Kimi point to an effective open source strategy, getting traction and growth opportunities in the community. Going forward, however, the industry is likely to shift toward clearer monetization paths from open-source adoption.

4. Qwen has become the community's base model

A model’s ecosystem position is not defined only by its own releases, but by how much the community builds on top of it. As mentioned above, Qwen is one exception which is getting attention and adoption.

Data from Hugging Face

By this measure, Qwen has become one of the largest foundations in the open model ecosystem. Qwen-based models now account for 151,448 derivatives on the Hub, 2.6× Meta’s total footprint and 4.7× the Llama repositories specifically. Google follows with 82,506 derivatives. The third-largest source is Unsloth, a community account publishing quantized and fine-tuning-ready builds, many of which further extend the Qwen ecosystem.

Qwen derivatives have increased at roughly 180–210 new repositories per day throughout the first seven months of 2026, showing that adoption is not driven only by individual launches. Qwen has become part of the default workflow for developers deciding what models to fine-tune and deploy.

Several factors contributed to this position. First, consistency. Qwen has maintained a regular release cadence, continuously updating its model family rather than relying on occasional flagship releases. Second, coverage. It publishes models across a wide range of sizes and use cases, allowing developers to stay within the same ecosystem whether they need a small local model or a larger deployment model. Third, openness. Apache 2.0 licensing reduces friction for modification, redistribution, and commercial use.

These factors reinforce each other. A broad model family attracts more developers; more developers create more derivatives; and those derivatives make the ecosystem more attractive to future users.

This position was built largely by the community. The 151,448 derivatives represent downstream work created by other developers, not releases produced by Qwen itself. Even among the 28,531 GGUF conversions of Qwen models on the Hub, Qwen published only 54.

5. Small models remain the practical layer

Among models that declare a parameter count, those under 1B take 83% of all-time downloads and everything above 100B takes 1%. Restricting to downloads accumulated in 2026 changes nothing: 3% of the volume goes to models above 70B. This is the March finding that has held up most cleanly, for the same reason as before, small models are the only ones that run on the hardware most developers actually have.

So how does a trillion-parameter model reach anyone at all? Through llama.cpp.

In February the ggml team joined Hugging Face, with the project remaining fully open-source, community-governed and in the same technical direction. What changed is that the most important project in local inference now has durable resources behind it.

The ceiling moved with llama.cpp. The July snapshot carries GGUF builds of DeepSeek-V4-Flash at roughly 284B parameters and Kimi-K3 at roughly 2.8 trillion. Local inference used to mean an 8B model on a laptop. It now means a trillion-parameter mixture-of-experts spread across a few consumer machines, which is the alternative route the frontier did not have a year ago, and the reason a frontier-first release strategy is viable at all.

And that route runs on Qwen: 39.6 million GGUF downloads a month, nearly twice Gemma's 20.8 million and more than five times Llama's 7.5 million. The Llama gap is not a supply problem, Llama-derived GGUF repositories slightly outnumber Qwen's. Same shelf space, a fifth of the traffic.

Model repositories grew 21.5% over these seven months. Several things around them grew several times faster.

Repositories declaring the gguf library rose 464%, lerobot 194% and Apple's mlx148%, against 16% for transformers and peft and 21% for diffusers. The modelling core is growing at roughly the platform average. The layer that decides where a model can physically run local inference formats, Apple silicon, robot control stacks, is growing three to seven times faster than that.

Across the ten largest model families, the labs behind these models publish very few official GGUF conversions. Yet GGUF versions are often the ones used by developers running models locally. Providing an official conversion at release, documenting quantization choices, and signing the artifacts would require limited additional effort. Rather than maintaining this workflow internally, labs could collaborate with existing ecosystem contributors such as Unsloth. Doing so would narrow the gap between the weights tested by model creators and the versions adopted by the broader community.

6. Agents are the new user

We could not have written this section in March, because the instrument did not exist. The agent-usage dataset, published in July, records the agent/<name> token that coding agents send when they call the Hub through huggingface_hub or the hf CLI — searching for models, pushing datasets, running Jobs, creating Spaces. For the first time we can see how much agent traffic the Hub receives and which harnesses it comes from.

Claude Code led July with 44.4%, but a single month conceals the real finding: it held 67.8% in April and 6.4% in May, while Codex climbed steadily from 10.4% to 20.8%. This is a market with no incumbent, where one release or one changed default can move half the traffic in a month.

The second finding is the unregistered row. Nearly a quarter of agent-tagged traffic in July came from harnesses not yet named in the dataset, and in May that figure was 59.8%. Between April and July more than a dozen new client identifiers appeared. New entrants are arriving faster than any registry can name them — which is itself the finding.

We spent much of the year building for this reader rather than only for human browsers. Papers began serving machine-readable Markdown in March. April brought agent traces as a first-class dataset type and an agents.md endpoint on every Gradio Space, so an agent can read a Space's API and call it directly. July brought the hf_fs tool on our MCP server, exposing repositories, storage, docs and papers through a single interface in just over a thousand tokens, alongside attachable sandboxes for secure execution. The same consolidation happened at the protocol layer, with MCP moving into the Linux Foundation's Agentic AI Foundation.

Then, in July, an agent stopped being a reader and became an intruder. What appears to be the first documented case of an autonomous agent running a sustained intrusion on its own initiative happened to us. While our team tried to use frontier closed models to analyze the captured attack code, their safety guardrails declined the work. The analysis was completed in the end on a quantized open model GLM-5.2 running on our own infrastructure. We published a disclosure and a full technical timeline.

Looking forward

Compared to the spring report, the geographical rebalancing of power continues to accelerate. While U.S. open source models continue to be competitive, the race between several Chinese frontier model labs draws strong attention. Many likes on these frontier models point to what excites the community the most, and growth opportunity for companies leveraging the attention for valuations.

However, the AI race is not only sprints, but also a marathon; tools like llama.cpp helps deploying the big models locally, but a broad model family and its adoption is still the key, to build a positive feedback loop between developers, publisher and future users. Models to be embedded in the infrastructure and being part of the ecosystem, may lead to a commercially sound exit at the end of the tunnel.

In the end, with agents being the number 1 user on HF Hub for the first time, the next report may look very different.

In AI, a few months can reshape the ecosystem.

Notes on method

This analysis is based on activity observed on the Hugging Face Hub during the first seven months of 2026.

The metrics used in this report, including downloads, likes, derivatives, and model releases, represent different aspects of ecosystem activity. They should not be interpreted as direct measures of model quality, commercial adoption, or overall market share.

Downloads indicate usage within the Hub ecosystem, but they do not capture API usage, private deployments, or models distributed through other channels.

Likes reflect community attention and interest, while derivative models provide a signal of how much developers build on top of an existing model.

Because open-source AI adoption happens across many channels, Hub activity should be viewed as one perspective on ecosystem development rather than a complete measurement of the AI market.

Edited

This article was edited to include latest releases in early August.