I read Jon Seager’s post on the Ubuntu Discourse about where AI is going in Ubuntu, and the part that stuck with me was the sentence: “Ubuntu won’t become an AI product.” That is the right framing, and it is also the framing most distros will land on, even if some of them have not figured it out yet. The interesting question is not whether AI shows up in your operating system. Of course it does. The interesting question is what shape it takes when it gets there, who runs it, and whether you can turn it off.
Seager is Canonical’s VP of Engineering, which means the post is partly a roadmap and partly a defense of how slowly some things will move. Both reads are useful. Here is what stood out, what to ignore, and what an ordinary Ubuntu user should actually do this year.
The stance: AI as a feature, not the product
Canonical is drawing a hard line between two ways an operating system can absorb AI. The first is to make the OS itself an AI product, with chat baked into the launcher, an assistant that reads your screen, and a marketing site that promises to replace your search engine. The second is to use AI where it makes an existing feature better, ship it as an opt-in piece, and let the OS stay recognizably Ubuntu.
The post is unambiguous about which path Canonical is taking. The second one. AI will land in Ubuntu the way accessibility features landed in Ubuntu: as improvements to things you already do, not as a new product to learn.
There are four things I took from the post about how this stance plays out internally at Canonical.
- Engineers are told to use AI for mechanical work, prototyping, troubleshooting, and learning new things. They are not told to hit a quota of “code written by AI.”
- The company tracks whether AI is producing high-quality output, not whether it is producing more output. The phrase “AI slop,” which has appeared in a lot of open source mailing lists in the last year, is named directly as the failure mode to avoid.
- AI is treated as a tool that augments engineers, not as something that replaces them. The exact line in the post is “engineers who master these tools effectively will thrive,” which is a polite way of saying the people who do not will not.
- When AI is shipped in a feature, it ships with the same human review and approval that every other change goes through. There is no “the AI wrote this, ship it” path.
The internal rules matter because they shape what eventually lands in your apt repo. A company that measures AI by lines of code will eventually ship AI-generated code. A company that measures AI by whether the change makes the OS better will not.
Implicit AI versus explicit AI
Seager introduces a distinction between two kinds of AI features, and I think it is the most useful frame in the entire post. He calls them implicit and explicit.
Implicit AI is a model that runs behind the scenes to make an existing feature work better. The user does not know AI is involved, and they do not need to. Speech-to-text is the canonical example: the speech recognizer gets noticeably better when there is a local model backing it, and the user just sees a more accurate transcription. They do not see a chat box. They do not see a prompt. They see a feature that works.
Explicit AI is the opposite. It is a feature the user opens, talks to, and gets an answer from. An agent that helps you write a document is explicit AI. A troubleshooting assistant that walks you through a network problem is explicit AI. Anything where you are clearly interacting with a model counts.
The reason the distinction matters for Ubuntu is the rollout plan. Implicit AI features ship as part of the OS, on by default where they improve accessibility or core UX, and they look like better Ubuntu. Explicit AI ships as opt-in previews, starting with Ubuntu 26.10 in late 2026, and they look like new applications.
For most users, the implicit category is the one that will actually affect daily life, because the improvements are silent. The explicit category is the one the marketing will talk about, because it is photogenic.
Inference snaps and local models by default
The technical lever for both categories is the same: inference snaps. An inference snap is a sandboxed (snap is a package format that runs in a restricted container with explicit permissions, similar to how iOS apps run in their own sandboxes) package that ships a pre-trained model plus the runtime needed to run it on your hardware. The user installs it with a single command.
snap install nemotron-3-nano is the example Seager uses, and the idea generalizes to any model Canonical partners on. The snap is hardware-optimized, which means the same package runs faster on an M-series Mac than on a five-year-old Intel laptop, because the snap picks the right backend at install time.
The model runs locally by default. The data does not leave your machine. That is the privacy story and the offline story at the same time, and it is the reason Canonical cares about snaps rather than packaging models through apt. Snaps already have the confinement and permission model that keeps a piece of software from reading files it should not read, and that model extends naturally to “the model on your machine does not get to talk to the network unless you let it.”
There are four practical things this means for someone running Ubuntu today.
- Models like Gemma 4 and Qwen variants with strong tool-calling can already run locally on commodity hardware for many everyday tasks, including web search, API interaction, and reasoning that goes beyond the training data.
- The snap packaging model gives Canonical a way to ship model updates without breaking the OS. A new model is a new snap, not a system library change.
- Hardware-optimized inference means the same snap runs on Nvidia, AMD, and Apple Silicon, with backend selection happening at install time rather than at compile time.
- Because the model is local, latency is bounded by your hardware, not by your network. A 14-billion-parameter model on a recent laptop gives you round-trip latency in the low hundreds of milliseconds for most queries.
If you want to try the local-inference path before 26.10 ships the polished version, the inference snaps are the on-ramp. They are not the final UX. They are the part of the stack that does not need a UI to be useful.
What about AI slop
The phrase “AI slop” has been doing a lot of work in open source discussions in the last year. It refers to the flood of low-quality AI-generated contributions that arrived in many projects through 2024 and 2025: pull requests that look plausible but do nothing useful, bug reports that are hallucinations, and documentation rewrites that strip out the parts that were actually correct.
Seager names the problem directly and says Canonical’s internal policy is to treat it as a failure mode to design against, not as a tax to pay. The two operational levers they mention are review and traceability. Every AI-assisted change goes through a human reviewer who is accountable for the change, and the tools used to produce the change are logged so the team can see whether AI-assisted changes are introducing more regressions than human-only changes.
This is not a solved problem at the industry level. It is a posture. The companies that take the posture seriously ship better software than the companies that take the productivity claims at face value.
What you can actually do today
For Ubuntu users who are not on the engineering side of Canonical, the practical question is what to install and what to skip.
If you want to experiment with local AI on Ubuntu today, here is a sensible order of operations.
- Install an inference snap and try a small model locally. The first run will be slow because the model has to download, but subsequent runs use the cached weights.
- Try the improved speech-to-text on a recent Ubuntu desktop. The implicit accessibility improvements are the most user-visible AI wins in the OS right now.
- Hold off on third-party AI toolbars, sidebars, and chat assistants that promise to “boost your productivity.” The pattern of those products has been to gather data first and ship value later.
- If you maintain a project that takes contributions, add a contributor policy that requires human accountability for AI-assisted changes. The projects that did this in 2024 are now in better shape than the projects that did not.
The implicit features will arrive without you noticing. The explicit features will arrive in 26.10 as opt-in previews. Neither one requires you to learn a new product.
Trade-offs
The local-first inference strategy is not free. There are real costs.
Inference snaps need hardware, and the hardware floor is rising. A 14-billion-parameter model will not run well on the laptop you bought in 2019. Canonical can optimize for the hardware they partner with, but the partner list will not include every chip. If you are running commodity hardware that is more than five years old, the “local AI” pitch will not land for you.
The opt-in nature of the explicit features means there is a slow period where Ubuntu’s AI features look behind competitors that ship chat boxes and assistants as defaults. Marketing will compare Ubuntu unfavorably to distros that have bolted on a chat interface. The honest answer is that the distros that bolted on the chat interface did it before they had the runtime model figured out, and they will have to redo it when local inference becomes the default. Canonical is doing the slower version first.
The internal policy on AI slop depends on review, and review is expensive. Every AI-assisted change needs a human reviewer who is paid to actually read the change. That cost does not show up in a press release, but it is real, and it is the reason the company is being deliberate about where AI lands.
For most users, the trade-off is right. For users who need an AI assistant today, the trade-off is wrong. The 26.10 preview will help, but it is six months out.
Bottom line
Anyone running Ubuntu today gets a straightforward answer about where AI is headed. The short version is: better accessibility, opt-in assistants, and a model story that runs locally by default. The first two are shipping in the next two releases. The third one is the strategic bet that makes the first two possible.
For maintainers of open source projects, the contributor policy question is the one to deal with now, not when the first AI-generated pull request lands in your repo.
For users choosing an OS in 2026 with AI features as the deciding factor, Ubuntu is not trying to win that argument this year. Canonical is trying to win the 2028 argument about whether the AI features you actually use are local, private, and optional. That argument is the more interesting one.