Warren Husband

Chief Technology Officer at EdgeTheory

There's No Best AI Model. That's the Point.

Everyone wants to know which AI model is best. It's the wrong question. The more important question is whether your organization can adapt as the answer keeps changing.

The question I get asked most about AI is some version of "Which model should we use?"

It's a reasonable question. It's also the wrong place to start.

In March, I spoke at the NCNI Summit at Ole Miss in Oxford, in a session on cognitive warfare and artificial intelligence. Part of my presentation was a snapshot of the AI landscape: who was building the leading models, how their capabilities compared, and where the industry was heading.

The model names on those slides have already started to age. That's actually the point. The organizations that build their AI strategy around a particular model are going to spend a lot of time rebuilding it.

Here's what I think matters more.

AI isn't an experiment anymore

The first thing I wanted the room to understand was scale.

According to McKinsey's global survey, 88% of companies were using AI in at least one business function, up from 78% the previous year and 55% the year before that. The average company was using AI in about three different departments.

That's a significant shift. A few years ago, the conversation was about whether organizations should experiment with AI. Now it's about how to operate it across the business.

Those are very different challenges. Experimentation is about finding possibilities. Operational adoption is about integration, cost, security, accountability, and whether the technology actually improves the work.

Your employees are probably already using AI, whether there's an organizational strategy for it or not. That's a reason to have a plan, not a reason to panic.

The model race isn't producing a permanent winner

In March, I put nine models on one slide. Four closed models from OpenAI, Anthropic, Google DeepMind, and xAI made up the top tier. Five open-weight models from Meta, DeepSeek, Alibaba, Mistral, and Google were competing not far behind.

Two things stood out.

First, there wasn't a clear winner. Each leading model had areas where it performed particularly well. One might lead on reasoning, another on coding and writing, another on general-purpose capabilities or ecosystem. Price, context length, deployment options, and customization added another layer to the comparison.

Second, open-weight models had closed much of the gap faster than many people expected.

DeepSeek was a particularly good example. Its architecture demonstrated how a model could have hundreds of billions of total parameters while activating only a fraction of them for each token. That has significant implications for the cost of running capable models. Meta's Llama models demonstrated how far context windows were expanding.

The distinction between open and closed models matters, too. Open-weight models can offer more control over deployment, data, and customization. Closed models often offer managed infrastructure, support, and a more integrated ecosystem.

Neither approach is automatically better.

Most organizations will eventually find themselves using a combination. Different problems have different requirements, and the economics and capabilities of the models keep changing.

The mistake is treating model selection as a permanent decision.

Benchmarks are a starting point, not a buying decision

I also showed the audience IQ test results for several frontier models using Mensa Norway's testing framework.

It's an easy way to start a conversation because everyone understands what an IQ score is supposed to represent.

The results were striking. The top two models tied at 145, and the top seven cleared the traditional Mensa threshold of 130. Even several open models scored above the human test average.

But I made a point of explaining what those numbers don't tell us.

These tests measure particular forms of reasoning, pattern recognition, and problem-solving. They don't establish that a model has human-equivalent intelligence, and they certainly don't tell you whether it will perform well in your organization.

The same model could score quite differently depending on whether it was working from text or images. Some models performed exceptionally well on this test but weren't necessarily the strongest choices for coding, writing, or other specialized tasks.

That's the larger lesson.

A model can lead a benchmark and still be the wrong choice for your application. It might struggle with your data, fail to follow your instructions consistently, use tools poorly, or produce answers that require too much human review.

A leaderboard can tell you who's capable. It can't tell you who's right for you.

The only benchmark that really counts is performance on your own problems.

From answers to actions

The biggest transition I discussed was agents.

The industry called 2025 the year of the agent. In 2026, we're seeing agents move into production.

Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of this year. The architecture is shifting from a single assistant that answers questions to teams of specialized agents that coordinate across workflows. The Model Context Protocol, or MCP, has emerged as an important standard for connecting agents to tools and data.

The difference is simple to describe and hard to overstate.

A traditional AI feature waits for a question and gives you an answer. An agent is given a goal. It determines the steps, selects its tools, accesses data, performs actions, and returns a result.

That changes the risk profile.

When an AI gives you a bad answer, someone can choose not to use it. When an agent has permission to modify a database, send an email, execute code, or make a decision in another system, the consequences are different.

The questions become architectural: What can the agent access? What is it allowed to change? How do you verify its work? Where does a human need to approve an action?

Those aren't questions you want to answer after deployment.

Software development is changing, too

Software engineering is going through its own version of this transition.

Andrej Karpathy coined the term "vibe coding" in February 2025, and Collins Dictionary subsequently made it its Word of the Year. The idea is that you describe what you want in plain English and AI writes the code.

A quarter of Y Combinator's Winter 2025 startups reported that 95% of their code was AI-generated. Coding agents are now built into the major development ecosystems, and the tools around them have become big businesses.

I see this firsthand.

The speed improvement is real. But writing code was never the hardest part of building good software. Understanding the problem, making architectural decisions, anticipating how a system will behave, and knowing whether the result is actually correct are much harder.

AI changes the economics of producing code. It doesn't eliminate the need for experienced engineering judgment. If anything, it makes that judgment more valuable.

When producing code becomes dramatically cheaper, the ability to determine what should be built and whether it works becomes the differentiator.

What I'd tell leaders

If I had to boil my talk down to four recommendations, they'd be these:

The models I showed in March have already been superseded by newer versions. The models available today will eventually be replaced, too.

That's not a problem. It's the nature of the market.

The organizations that succeed won't necessarily be the ones using the model that scores highest on the latest benchmark. They'll be the ones that understand their problems, evaluate their options, manage their risks, and adapt as the technology changes.

Don't build your AI strategy around a model. Build it around your ability to use whichever model does the job best.

I gave this talk at the NCNI Summit 2026 in Oxford, Mississippi, on March 31, 2026.

Warren Husband is CTO at EdgeTheory and has been building software since 1995. He lives in Ridgeland, Mississippi.