The Optimization-First Approach to AI Development

The dominant narrative in US-based AI development goes something like this: make models bigger, train on more data, spend more on compute, and eventually you get to artificial general intelligence. The scaling hypothesis, roughly. Companies like OpenAI, Anthropic, and Google are investing billions on the premise that more scale yields meaningfully better capability.

Chinese AI labs, largely out of necessity, have been pursuing a different strategy. And the results are starting to complicate the scaling narrative in ways worth paying attention to.

Constraints as a design choice

The context matters here. Chinese labs have had limited access to the most advanced AI training hardware (notably Nvidia's H100 GPUs) because of US export controls. They can't match the compute budgets of OpenAI or Google. Cloud infrastructure costs are a bigger constraint.

Rather than treating these as problems to overcome, labs like DeepSeek have treated them as design constraints and optimized aggressively within them. DeepSeek's models have been competitive with GPT-4 class systems at a fraction of the reported training cost. The exact numbers are debated, but even conservative estimates suggest they're getting comparable performance with significantly less compute.

On the tooling side, the PicoClaw project (which rewrote Anthropic's Computer Use for embedded hardware) reflects a similar mindset. Instead of asking "how powerful does the hardware need to be?", the question becomes "how little hardware can we get away with?" That shift in framing leads to very different engineering decisions: smaller models, more aggressive quantization, hardware-aware optimization. And it opens up deployment scenarios that the scale-first approach simply can't reach.

Why efficiency matters for deployment

The practical significance here isn't really about national competition (though that's how it's often framed). It's about what kind of AI deployment is possible and economical in real-world settings.

Consider running models on local hardware rather than in the cloud. This matters for manufacturing environments where latency is critical, for applications where privacy requires keeping data local, for regions with unreliable internet, and for any deployment where per-query cloud API costs are too high at scale. A model optimized to run on a $100 device serves a very different market than one that needs $10,000+ in monthly cloud compute.

Iteration speed is another underappreciated advantage. Labs that ship quickly, gather feedback, and iterate accumulate practical knowledge faster than those that spend months refining before release. Several Chinese labs have adopted release cadences that look more like a startup than a research institution, and over time that faster learning loop adds up.

What this means for the scaling debate

None of this proves that scaling is wrong. For frontier research, complex multi-step reasoning, and pushing the boundaries of what AI can do, larger models with more training compute are almost certainly still better. The question is how much of real-world AI value depends on being at the absolute frontier versus being "good enough" and cheap to deploy.

For most practical applications (customer support, data processing, code assistance, content generation, routine automation) the difference between a frontier model and one that's 80% as capable but 10x cheaper to run is often not worth the cost premium. This is especially true when you consider that most of the value in a real deployment comes from the integration work, data pipelines, and application logic around the model, not from the model's raw capability.

If that framing is right, then the optimization-first approach may prove more commercially important than the scaling-first approach, even if it never produces the most capable model on any given benchmark. A model that's good enough and runs anywhere is, for many use cases, more valuable than one that's slightly better but requires expensive infrastructure.

Broader lessons

Regardless of the geopolitics, there are some useful takeaways here for anyone building AI-powered products or making infrastructure decisions.

Optimizing for deployment constraints, not just model performance, is increasingly important as AI moves from research demos to production systems. The question isn't just "how good is the model?" but "how good does it need to be for this specific use case, and what does it cost to run there?"

Speed of iteration matters more than most teams realize. Getting something deployed, learning from real usage, and improving incrementally is almost always more valuable than waiting for a perfect solution. This is standard startup wisdom, but it applies just as much to AI product development.

And constraints, while uncomfortable, can be productive. The need to work within hardware and budget limits has driven real innovation in model efficiency, quantization, and edge deployment. These are techniques that are useful regardless of whether you're constrained or not. There's something to be said for asking "what's the cheapest way to solve this well enough?" even when you have the budget to do it the expensive way.

The scale-versus-optimization question probably isn't going to be settled cleanly. Both approaches have their place, and the right answer depends on the use case. But for anyone building practical AI systems today, the optimization side of the equation deserves more attention than it typically gets.