I spent some time this week experimenting with DeepSeek as a coding model inside VS Code.

The experience was surprisingly uneventful, and I mean that as a compliment.

I gave it a few tasks in projects I already knew well. Small changes. Refactors. The kind of work where I already had a clear expectation of what the final result should look like. It completed the tasks, made reasonable modifications, and generally behaved the way I expected a coding assistant to behave.

The quality wasn’t dramatically better than other models I’ve used. It wasn’t dramatically worse either. It may have felt a little slower in some situations. What stood out most was the cost.

I added a few dollars of credit to test it and quickly realized that I would probably need a long time to spend them.

That observation led me to think about something broader.

For the last few years, discussions about AI models have focused heavily on quality. Which model writes better code? Which one reasons more effectively? Which benchmark score is higher? Which model wins the latest comparison?

Those questions still matter, but they are becoming less important for a growing category of work.

When I ask an assistant to add a field to a form, update a validation rule, create an endpoint, write a migration, or refactor a service, I’m usually not looking for groundbreaking intelligence. I’m looking for a competent collaborator that can execute a well-understood task.

If the model completes the work correctly in one or two iterations, the difference between “excellent” and “slightly more excellent” becomes difficult to notice.

In those situations, cost starts becoming a more interesting variable.

For most of software history, engineering productivity was constrained by people. We tried to automate repetitive work because developer time was expensive and limited. AI introduces a different constraint. Now we have access to nearly unlimited assistance, but each interaction has a cost attached to it.

When the cost drops dramatically, our behavior changes.

A few years ago, it would have seemed absurd to have an assistant continuously reviewing code, searching documentation, exploring implementation options, generating test cases, summarizing pull requests, or monitoring multiple projects simultaneously. Today the technology exists. The remaining question is whether the economics make sense.

Cheap models make many of those activities viable.

I suspect this will eventually create different layers of AI usage inside development workflows.

There will be premium models that are used for difficult architectural decisions, complex debugging sessions, system design reviews, and situations where reasoning quality matters most.

There will be mid-tier models handling everyday development tasks.

And there will be extremely inexpensive models that quietly perform large amounts of supporting work in the background.

The pattern feels familiar.

We do not provision the most powerful infrastructure for every workload. We do not use senior architects for every decision. We do not optimize every system for peak performance. We match capabilities to the problem being solved.

AI models are likely heading in the same direction.

What I find particularly interesting is that this changes how we evaluate tools.

The question stops being “Which model is best?” and becomes “Which model is good enough for this task?”

Those are very different questions.

My brief DeepSeek experiment was probably not enough to evaluate its limits. I was working in code I already understood, with tasks where I already knew the expected outcome. The more revealing test will come later, when I ask it to explore unfamiliar parts of a project, understand business rules, trace dependencies, or propose solutions to ambiguous problems.

That’s where differences between models tend to appear.

Still, I left the experiment with a different impression than I expected.

The story may not be that cheaper models are catching up to the best models.

The story may be that many software tasks never required the best model in the first place.

As builders, we often focus on capabilities. Sometimes the more important shift comes from economics. When a useful tool becomes dramatically cheaper, people don’t simply use it to do the same things for less money.

They start using it in places where they would not have used it at all before.

That may end up being the bigger change.

Related Sparkio Products

Founder Interactive business history simulator inspired by the stories and decisions behind the world's most influential companies.

AppGrid Platform designed to help independent developers connect their products with potential customers.