AI (sparkle emoji)

2025 was an eventful year for AI (to be precise, the use of LLMs in applications called AI. I don't believe AI is a useful term outside of marketing purposes.) I expect 2026 to be similar. It's fairly predictable that models will get better. There's also discussion of an AI bubble bursting. I don't know how to define a bubble, and it might take years before we can point to the time it burst. What I do know is that we're currently in a data center construction boom. These data centers will take years to come online, and power generation is a larger bottleneck than compute. Knowing that the market can stay irrational longer than you can stay solvent, I think we won't see any major shifts in 2026 regarding AI spending and bubbles. As long as the money is flowing AI will boom, demand be damned.

An 8B parameter model scores at least 0.8 on MMLU-Pro by December 31.

Basically, I'm predicting there will be open source models that can run locally in 2026 that are as good as cloud models from 2025. Let's use this benchmark. Currently GPT-5(high) scores 0.871. InternLM3 (open source) at 8B parameters scores 0.576. LLaMA 3.1 (2024) Instruct 8B basically doubled the score of LLaMA 2 7B (2023) in about a year. LLaMA-4 Scout (2025) is showing the same performance as LLaMA3.1-Instruct with 75% fewer parameters. The trend is towards smaller models with better benchmark performance. For this prediction, I will only consider the total number of model parameters (not "active" parameters). An optional side prediction: the model that achieves a score of 0.8 on MMLU-Pro with 8B parameters will come from China.

Usage of ChatGPT and Gemini decline after launch of new Siri

The current leaders in AI chat apps are OpenAI's ChatGPT and Google's Gemini. Apple is famously "behind" in the AI race. But Apple has a history of winning, even when it's late to the game. Lagging in AI hasn't hurt Apple's stock price in the slightest (up 8.93% in 2025.) It's long been expected that Apple will release their revamped Siri in 2026, and it's been reported that the new Siri will be powered by Google's Gemini. So no matter how this plays out, Google wins. Nevertheless I predict Apple's offering will be good enough that most iPhone users won't need a dedicated ChatGPT or Gemini app. In other words, AI chatbots will be Sherlocked. Official numbers may be hard to find, so to verify this result I'll rely on third-party reporting and some speculation. Gemini had 21M downloads last month according to Sensor Tower. And ChatGPT had 65M. A decline in these numbers doesn't necessarily mean Apple is gaining market share, but we might be able to speculate based on reporting about Apple's new Siri features.

New standards for agent tooling

With the formation of the new Agentic AI Foundation, I anticipate many more standards being announced in 2026. The most obvious one I can think of is a standard for AI tool calling. Look at this leaked system prompt for ChatGPT 5 or this Gemini CLI prompt. They have to describe every tool available to the agent and how to use it. Both have different syntax. Presumably some non-LLM deterministic code understands how to interpret and run the commands in the output This prediction passes if a standard is drafted that includes syntax for AI agent tool calling, or an approach emerges that replaces the need for it.

Politics

I don't like to write or talk about politics much, because such discussions are rarely fruitful. Nevertheless, we live in a world where almost everything is politicized so you can't avoid it. These are my predictions.

Many of Trump's tariffs are ruled unconstitutional

The Supreme Court heard arguments in Learning Resources v. Trump in November. We're still waiting on a ruling. The case hinges on whether the International Emergency Economic Powers Act authorizes tariffs under Trump's emergency declarations. My prediction is that the Supreme Court will rule against Trump. This would unravel many (but not all) of the imposed tariffs.

Democrats win in the House midterms

Every once in a while I like to peak at Nate Silver's Trump Approval Dashboard. The accumulation of polls presents an interesting picture over time. The exact numbers aren't meaningful, but the trends seem pretty clear to me: Trump is losing popularity. The political pendulum swings—if people don't feel like the current party is improving their life, then they'll vote for the other one. There's precedent for this too. Trump lost the house in 2018 with record voter turnout. This time, the Republicans are trying new strategies like redistricting in Texas, but I think these efforts won't matter. Hispanic voters were critical to Trump's election, but now they've soured on him.

Billionaires get richer

Billionaires earned a collective $2.2 trillion in 2025. That's an absurd amount of money, but I don't see it stopping. I predict they'll earn a collective $3 trillion in 2026.

Other

Here are a few more predictions in other dimensions of life.

Avatar: Fire and Ash reaches top 10 highest grossing films of all time

James Cameron will do it again. Avatar 1 is the highest grossing film of all time. Avatar 2 is the 3rd highest grossing film of all time, and Titanic is the 4th highest grossing film of all time. Betting against James Cameron just seems silly. As of writing, Avatar 3 has about $800 million in box office revenue. It just needs to double that to get into the top 10. I don't really know much about the economics of movies, but maybe that's possible. I'll award partial credit if it makes top 50 (~$1 billion.)

Bitcoin drops to $50,000

After hitting a peak around $125,000 BTC is now down to $87,000. The last time it was $50k was in 2024. There are no fundamentals driving the price of Bitcoin. People either take advantage of the dip to pump it up again, or it continues to sink. That's right, you heard it here first: bitcoin will either go up or down! But my bet is down. Bonus prediction: there will be no Walmart or Amazon stablecoin in 2026 (who would use this?)

5% of Steam users will be on Linux

Linux usage grew from 2% to 3% in 2025. Linux users currently make up 3.2% since November. With the recently announced Steam Machine and additional hardware, switching to Linux will probably be even more appealing. Microsoft has done gamers no favors. Valve's investment in Linux protects them from dependence on Microsoft. Windows is getting worse. I don't put much stake in public outcry—because rants on Reddit rarely reflect on a company's top line metrics—but I think it fits into a larger narrative around the decline of Windows and Xbox. Microsoft has been losing in the gaming sphere for some time. The PlayStation 5 way outperformed the Xbox Series X/S. Now they're putting Halo on PlayStation, presumably because they can't make money on their own consoles anymore. They severely botched their acquisition of Activision Blizzard, which looked like an attempt to rescue their gaming division, but it backfired. They fired most of the Activision employees already and the future of some franchises seems uncertain. Microsoft lost their lead in consoles, and now they're losing in PC gaming. Even Apple is getting AAA studios to port their games. Basically—Windows is giving gamers every reason to abandon ship and Valve is over here offering a life raft.

It depends

The best use cases I've found for AI are the things I'm bad at: drawing art for video games, writing physics simulations, using new programming languages, preparing taxes, etc. Because these things take so long for me to figure out on my own, the results from AI are a huge time saver. Not only that, the results are better than what I can do. I don't have time to practice drawing, so I'm happy that AI can draw me a tree, even if it's soulless and devoid of anything that could be perceived as art. It lets me focus on the pieces I care about, which is writing code. Obviously hiring a human artist would be better, but also more expensive. Maybe I can do that once I have a game that makes money.

There's another category of use-cases where the stakes are very low, and there's not much skill involved: writing unit tests, taking meeting notes, preparing outlines, building static websites, etc. AI tools do these tasks perfectly fine. The results won't blow you away, but they'll save you a lot of time.

That said, I won't use AI for anything I'm good at, where quality is important to me. I'm almost never happy with the API design choices than AI agents produce. They get the job done, but aren't designed well for long term maintenance and growth. Furthermore, I've never found them good at large code refactors, in part because they start to hallucinate new functionality. Additionally, when I do a lot of writing, I don't trust AI to effectively convey what I want in text, but it's fine if it wants to check my grammar or whatever. Usually, if I have the experience to visualize the end state I want, and how to get there, AI won't meet my standards. It might be capable of bits and pieces, but it won't one-shot an entire implementation of something I'm skilled enough to make myself.

One of the reasons I think AI can't do what I'm skilled at is context. In our brains there is a lot of context we take for granted. Perhaps the AI agent can do what I want, but only if I write enough context for it. LLMs are statistical models of the collective sum of all written human knowledge. They're specifically trained to produce the expected sequence of tokens. Meaning: they're not creative. Any creativity produced by an LLM must be derived from the (human-generated) prompt. But writing a highly detailed prompted might be just as much work as doing it myself.

Mediocrity

In short, AI lifts up the bottom. It gives us all tools to make us better at things we're bad at, but it doesn't make you better at what you're good at. If you've never written code in your life, you now have access to a dozen (and counting) tools to build no-code or low-code apps. You'll never replace a real engineer with these, but now you can build something. If you've never been good at art, you can produce almost anything you want on demand. It might not be "art", but it can bring life to an empty page. If you've never been good at languages, you have an on-demand translator for hundreds of languages. It might not capture nuance or intention in your Booker Prize-winning novel or poem, but it can grow the audience of your video game or app.

We're at a point where the baseline skill for a lot of things is good enough thanks to AI. This means individually, we are capable of a lot more. But I don't think AI is yet an expert at anything. If you want the best software, you hire an expert. If you want the best art, you hire an expert. If you wan the best writing, you hire an expert. There is a corollary: in this future where AI makes us all mediocre artists, how do you become a master? Companies are hiring fewer software developers (in part) because of AI. How will we train the next generation of senior software developers if the new crop of candidates rely on AI to do mediocre work?

I'm not convinced the current models will ever be good enough to replace experts. Iterative improvements in benchmarks might make the LLMs "smarter", but they don't make them better decision makers. They don't have anything at stake, so they can't make long-term/short-term trade-offs like a human. They have no accountability, so they don't care if they mess up. They don't experience the human condition, so they can't make artistic choices. They only "know" what you tell them in the prompt, and no more.

One person can get a lot more done with AI than they can alone, but the results just won't be that good. AI can do the job of mediocre humans. No company wants to hire mediocre humans to begin with, but that's because mediocre humans are expensive! By comparison, AI is cheap. When a company says something like "AI first," I don't assume they mean they will replace humans with AI. I assume it means they want more mediocrity. Sometimes that's fine–plenty of businesses want quantity over quality. But for anyone that wants excellence, reach for humans first, and AI second.

Humanity

A solo project will remind you that you are a human. You are creative. Whatever your company thinks you're worth, it's ten times that. It will remind you that you can create truly amazing things when you're not implementing a robust governance structure and fostering a culture of transparency to empower teams to proactively identify and course-correct risks before they escalate into critical path blockers.

What's that? An excuse? You don't have time? Well delivering a project on time is not merely a function of deadline adherence but a holistic exercise in resource optimization, expectation management, and adaptive execution.

Make a game. Do it yourself, maybe jam with a friend. But do it because it's fun, it's liberating, and you can feel like there's something human still left in you after a day spent ensuring project trajectory remains on schedule and aligned with broader business objectives, thereby maximizing value creation and reinforcing stakeholder trust.

Learning

You can learn a lot too. Have you ever written something in an ECS framework? Did you know Prime Video implemented an entire UI renderer in WebAssembly using an ECS framework for delivering a fast, consistent experience across devices with over-the-air updates? That's right: knowing how to do more than one thing can drive sustained value realization by remaining impact-oriented.

If you're like me, you probably work with HTTP APIs all day (or maybe gRPC or whatever.) But game networking is much different. Try adding netcode to your game. Make it multiplayer. Learn how to simulate the game on the server using UDP to transmit commands. Figure out how to scale it (hint: Kubernetes won't save you.) The challenges are new, fresh, and fun.

Why should you care about learning new things? Claude Shannon invented digital circuits because he knew analog circuits and boolean algebra (a rare combination at the time.) Computers exist because of him. Today's AI exists because David Rumelhart knew differential calculus. For context, backpropogation was unsolved for 17 years. Maybe the only thing stopping you from discovering a seismic shift in the fabric of technology is that you're too busy making real-time reporting dashboards.

Productivity

We're in a golden era where the cost of creativity has plummeted. What might have taken a team of 10 people can be done by one person. Sure, AI is destroying the environment, poising our brains, and killing jobs, but it's also created the opportunity for smaller teams to compete with larger incumbents. And, if it's not abundantly clear, small teams spend less time instituting a governance architecture that balances strategic oversight with operational agility to preemptively address misalignment risks before they escalate into critical disruptions.

Here's an early video from my first game, which implements simple kinematics to move the ball and the board. The amazing thing is, AI implemented almost everything up to this point.

Okay, maybe games aren't your thing. Maybe what you really want is to make an iOS camera app that applies nostalgic film filters. Maybe you want to create a calendar app that isn't just a wrapper around Google, Apple, or Microsoft. Maybe you want to destroy your least favorite SaaS provider by undercutting them with a fraction of the capital. Those are fine too. Find your creative outlet and show the world what you can do.

Or maybe coding is what you do for work and you want to spend your free time with your family, going on long walks in nature, painting a landscape, and eating fancy ice cream. Honestly, I can't fault that.

Protobuf is a language that describes an interface. An interface description language (IDL), if you will. It's also a serialization format that transports data across the wire. It's also a command line tool (protoc) that compiles the IDL into language-specific packages to read and write said serialization format. It generates code in many languages.

Rust is a language that can do everything, but it's very boilerplate-heavy. Not good for simple interface definitions. Blessedly, Rust supports macros, which reduce boilerplate. Macros can auto-generate virtually any Rust code at compile time. There are two kinds of macros that are important for replacing Protobuf.

• Macros like wasm-bindgen (JS) and pyo3 (Python) that generate glue code to bind to foreign function interfaces. With hardly any effort, we can expose our basic Rust types to JavaScript and Python.
• Serde, a macro that describes how any Rust struct or enum should be serialized. It's format-agnostic, so you can plug-and-play any serialization format you want such as JSON or msgpack.

If it's not abundantly obvious what we're going to do, let me make it clear: we can write our interface using Rust structs, bind them to other languages, and serialize them with serde. Rust bindings in any language give us the portability of Protobuf with the expressiveness of Rust/serde types.

Protobuf is bad

Perhaps because it has to interface with so many languages which do not share the same language features, some things are just needlessly verbose. Google publishes a standalone Python library (not baked into the generated Protobuf code) just to smooth over the painful ergonomics in Python. For example, everything has a a default field, so if you don't check HasField everywhere you can't tell the difference between something that was set to the default, or just something that is the default. (The pythonic approach would be to simply check if not field.)

For a language that's meant to describe data, Protobuf is extremely limited in its expressiveness. There are lots of complaints about this online. To provide an example we can use, consider this interface meant to represent arithmetic expressions:

syntax = "proto3";

package algebraic;

// An algebraic data type for arithmetic expressions
message Expr {
  oneof expr {
    int32 number = 1;
    BinaryOp binary_op = 2;
    UnaryOp unary_op = 3;
  }
}

// Represents a binary operation (e.g., addition, multiplication)
message BinaryOp {
  enum Operator {
    ADD = 0;
    SUBTRACT = 1;
    MULTIPLY = 2;
    DIVIDE = 3;
  }
  Operator op = 1;
  Expr left = 2;
  Expr right = 3;
}

// Represents a unary operation (e.g., negation)
message UnaryOp {
  enum Operator {
    NEGATE = 0;
  }
  Operator op = 1;
  Expr operand = 2;
}

Probably, you won't "just use" the generated Protobuf types in your language. It's going to be tedious. So instead, you'll write your own types and convert them to/from Protobuf. This isn't wrong per se, it's similar to how you probably wouldn't "just use" JSON off the wire. But it is annoying. If we're going through the effort to define our types, we should get more for our troubles.

In Rust we could represent the above far more concisely:

pub enum Expr {
    Number(i32),
    Op(Op),
}
pub struct UnaryOp(Expr);
pub struct BinaryOp(Expr, Expr);
pub enum Op {
    Add(BinaryOp),
    Subtract(BinaryOp),
    Multiply(BinaryOp),
    Divide(BinaryOp),
    Negate(UnaryOp),
}

Not only is this more concise, it may map more neatly to our data model. Rust enum values mean we can represent all operations as a single type Op instead of two types: BinaryOp and UnaryOp. More flexible types like this make it easier to express what we mean in our APIs.

Serde is great

The 10th most downloaded crate on crates.io is serde. It's usually the first dependency I add to a project. It's so good I have a hard time using other languages that don't have something similar.

We can annotate a struct with serde derive macros, and convert it to any number of formats.

This example is from the serde docs. Observe that the Point struct has no knowledge of what formats it will serialize. Only that it can be serialized. We can delay the choice of format all the way until the moment we absolutely need it.

use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, Debug)]
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let point = Point { x: 1, y: 2 };

    let serialized = serde_json::to_string(&point).unwrap();
    println!("serialized = {}", serialized);

    let deserialized: Point = serde_json::from_str(&serialized).unwrap();
    println!("deserialized = {:?}", deserialized);
}

This can be used, for example, to respond intelligently to different Accept headers. We can use JSON for a smooth development experience and switch to MsgPack when we want better performance in prod.

Ridl

I've published a demo of a crate I call ridl (sounds like "riddle") which does roughly everything I said above. It's free for all to see and modify. I can't say for sure that people should be using this. What I can say though, is if you have a reason to invent another IDL, maybe start with Rust. If you think this idea could actually be something, then please open a pull request against ridl and start hacking. I'd love to see people's ideas.

At the time of writing, a ridl object looks something like this, with support for Python and JavaScript.

#[cfg_attr(feature = "py", ridl::popo("hello"))]
#[cfg_attr(feature = "wasm", ridl::pojso)]
pub struct Hello {
    pub name: String,
}

pub struct Hello {
  pub name: String,
}

That's it! A whole message in just a few lines of code.

For now, ridl serves as a proof-of-concept and further development will depend on how much people find value in this idea. After all, maximizing value is what we're here to do.

To write hello in Python:

from typing import Annotated
from rust_idl import hello

from fastapi import FastAPI, Response, Header

app = FastAPI()

@app.get("/hello/{name}")
def greet(name: str, accept: Annotated[str, Header()] = None):
    greeting = hello.Hello(name)

    if accept == "application/msgpack":
        response = Response(content=greeting.to_msgpack())
        response.headers["Content-Type"] = "application/msgpack"
    else:
        response = Response(content=greeting.to_json())
        response.headers["Content-Type"] = "application/json"

    return response

To read hello in JavaScript

import init, { Hello } from "rust-idl";

await init(); // load wasm

const greet = async (name: string): Promise<Hello> => {
  const result = await fetch(`${WEBSERVER_URL}/hello/${name}`);
  payload = new Uint8Array(await result.arrayBuffer());
  return Hello.from_json(payload);
};

Future

There are limitations. For example, pyo3 doesn't support enum values like the arithmetic example from earlier. Similarly, generic types present some challenges in language bindings. These may get better over time as the Rust ecosystem evolves, or they may be fundamental limitations that are never fully resolved.

Ridl may not be significantly more expressive than Protobuf without enum values and generics, but it can only get better. Protobuf is a highly constrained language, but Rust is a very expressive language. For example, ridl could, with the help of some more custom proc macros, rewrite the value enums into something pyo3 can bind.

There are some ergonomic improvements to be made. For example, having a single proc macro instead of one-per-language. Also the build steps have to be run separately for each language (wasm-pack for JS, maturin for Python, etc.) but even that could be improved.

The future API for ridl could be much better. Here's the simplest one you could imagine:

#[ridl]
pub struct Hello {
  name: String
}

// build with `cargo build -F js -F py` or similar

Serde lacks the backward compatibility guarantees of the Protobuf serialization format. While serde can't serialize Protobuf (or anything like it), we don't have to use serde either. We could invent a new format. Or you could just, you know, not break backwards-compatibility.

There are other conceivable benefits to using Rust over Protobuf and its ilk. For example, you could extend your types with bits of logic. Arguably, that might stretch the idea of an IDL a bit too far. Taken to the extreme, you might as well write your whole app in Rust. But delivering value sometimes means being pragmatic. Just like this whole blog post is about being pragmatic. And rewriting everything in Rust is pragmatic.

The code you write isn't going to be around in 5 to 10 years. When your product is successful, old assumptions won't work anymore. Requirements evolve. You need to think about how your code will get replaced. Will it be easy or hard?

Don't leave behind a half-assed project, finished in one quarter and abandoned after you got promoted. If you can't commit to maintenance and support, you shouldn't write a single line of code. Use a popular open-source solution instead of writing your own. With zero effort on your part, there's documentation and a community that will keep working even when you stop. If there's no community solution, reflect on why that might be.

Stop writing code, and start thinking about not writing code. Only use 10% of your time writing code (or telling AI to write code) and the remaining 90% of your time figuring out what code not to write. Find off-the-shelf solutions. They age better. They come with better support. AI can auto-complete boto3 calls, it can't auto-complete your bespoke DynamoDB API wrapper written in Lua.

In the business world, they sometimes talk about core competencies. Very few companies have a core competency writing databases. Or build pipelines. Or CI/CD automation. Or container orchestration. You would never write those things by hand. Just like you probably shouldn't be writing whatever you're about to write by hand.

If you're the best company in the world to solve that problem, then do it. Otherwise, figure out how to avoid it.

Another Dockerfile? You sure?
A Helm chart? Are you serious right now?
Authentication??? The door is right there.

Portability

Containers solved a lot of important problems in software development. We had VMs before containers, but they were not as ergonomic to use. The experience of containers was, by comparison, a true delight. Fast(er) builds, near-instant startup, no virtualization, etc.

Now we're in an era where containers are annoying to work with. The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals. Learning how to use Docker is a distraction. No one has a goal to "improve Docker build times" unless you're part of the new PlatformOps (formerly DevOps (formerly Ops)) team.

My money is on WebAssembly (WASM) to replace containers. It already has in some places. WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.) You can compile several languages into WebAssembly already. Languages that can't be compiled will eventually have their own interpreters compiled to WebAssembly. The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated.

A very obvious argument against WASM succeeding is the Java Virtual Machine (JVM). It's almost exactly the same promise: write once, run anywhere. After all, over 3 billion devices run Java. There are many languages that run on the JVM: Java, Kotlin, Scala, Clojure, Jython, etc. The biggest limitation is that JVM bytecode cannot run in a web browser (RIP Java Applets). Web browsers are a crucial target for app development. Anyone that wants to share code between platforms will avoid the JVM. There is an interesting, slow-moving trend away from the JVM and towards statically compiled binaries. See: GraalVM, Kotlin Native, Scala Native, Jank.

Microservices

In a microservice architecture, you communicate with other services through HTTP or RPC calls, or using a message broker. This decoupling has important tradeoffs. The success of the model suggests most companies find the benefits outweigh the costs. Importantly, it creates strict boundaries between parts of your system. Conway's Law, etc. You don't need network boundaries to create good encapsulation, but it sure helps when you have a lot of developers.

Perhaps the biggest downside is the cost associated with having many small services communicating over a network. Not only do you pay for the bandwidth and resource overhead, but you have to engineer solutions to improve the reliability of each system in the face of network partitions.

With the advent of "serverless" platforms like AWS Lambda, you can take microservices to the extreme: just deploy single functions in the cloud. My favorite serverless model is Cloudflare Workers. If you have one Worker call another Worker, there is no actual network request. Instead, it just calls the Worker code in the same V8 runtime. Meaning you don't pay the cost of a network roundtrip.

Importantly, Cloudflare Workers all run in V8 sandboxes. There are no containers. You have the option of writing your worker in JavaScript/TypeScript, or compiled WASM. A container cannot call another container in the same process. But V8 can. In other words: by deploying WASM in V8 sandboxes, you get all of the developer benefits of microservices with all of the runtime benefits of monoliths. Cloudflare is not the only provider doing this. Wasmer is trying to build a solution in this space as well.

Adoption

WebAssembly is still a young technology. But it's rapidly developing, and support seems to be growing. Maybe it doesn't work for you yet, but keep an eye on it. Try developing on Cloudflare to see what the future looks like. (TV infomercial voice): if you or a loved one are building Docker images, you may be entitled to a better experience.

If you primarily develop in languages like Python, Ruby, or PHP, be patient. I recommend adding a compiled language like Go or Rust to your Golden Path so you can be prepared when the WASM reckoning is upon us.