How to choose an AI model for software development

We're preparing to launch our most ambitious product yet: a competitor to Notion. We spend over $10,000 per year on Notion and over the last year or two we have found that it has become bloated, difficult to navigate, disorganized, slow, and buggy. We decided we could build something better.

We've been working on this new product for the last couple of months using Spec-Driven Development and AI-assisted workflows. This has been effective, but choosing what AI model to use is crucial. Different parts of the work require very different kinds of models.

Today I'll share a bit about how we choose which AI model to use for software development.

There are seemingly endless major AI models available to software teams today. Their capabilities overlap, but they are not interchangeable.

Some are better at architecture and complex reasoning. Some are optimized for writing code quickly. Some are dramatically cheaper than others. Several come in three different sizes, and a new model seems to appear every few weeks.

On the Foundry team, we use SDD for most substantial product work. Before asking an AI agent to start writing code, we define what we are building, how it should work and how we plan to implement it.

Our typical AI-assisted engineering workflow is broken down (roughly) into these stages:

1. Product definition and refinement
2. Product spec
3. Technical spec
4. Execution plan
5. Review of the plan
6. Implementation
7. Gap analysis against the spec
8. Testing and debugging
9. Routine tweaks
10. Front end and visual polish
11. Final security and performance reviews

Different stages of this workflow require different kinds of intelligence.

Writing a technical specification requires architectural judgment and the ability to identify ambiguity. Implementing an approved plan requires speed, reliable tool use and the ability to make changes across many files. Reviewing the finished implementation requires skepticism and enough context to compare the code against the original requirements.

If time and money are not something you care about, you can just throw Fable 5 at the entire workflow and call it a day.

In practice, that is usually wasteful and not necessarily the best way to produce reliable software.

The general approach is:

• Use expensive frontier models for planning, decisions, architecture and critical reviews.
• Use faster, less expensive coding models for implementation and routine changes.
• Have a different model family review important work whenever possible.

The goal is not to identify one model that is “best at coding.” It is to assign each model the role where its strengths provide the most value.

As of July, 2026, here are the primary models we consider, what they are good at, and some of the trade-offs we need to consider.

Anthropic Fable 5 — Best for architecture, complex specifications and very long autonomous implementations. Very slow, token-hungry and extremely expensive.

Anthropic Opus 4.8 — Best for planning, critical reviews, gap analysis and difficult debugging. Slow to medium speed and expensive.

Anthropic Sonnet 5 — Best for everyday implementation, refactoring, testing and debugging. Fast, capable and moderately priced.

OpenAI GPT-5.6 Sol — Best for architecture, complex planning, security review and difficult full-stack work. Slow to medium speed and expensive.

OpenAI GPT-5.6 Terra — Best for everyday implementation, code review, testing and debugging. Medium-fast with balanced pricing.

Google Gemini 3.1 Pro — Best for huge codebases, multimodal analysis, UI work and broad gap analysis. Medium-slow and moderately expensive.

Google Gemini 3.6 Flash — Best for fast implementation, debugging and large-context code exploration. Fast and relatively inexpensive.

xAI / Cursor Grok 4.5 — Best for agentic implementation, terminal-heavy work and complex multi-file changes. Fast and moderately priced.

xAI / Cursor Composer 2.5 — Best for executing clear plans, editing many files and fixing test failures. Very fast and extremely inexpensive.

We can take this list and broadly categorize the models into the following jobs:

• Architects and Planners: Fable, Opus, Sol, and Gemini Pro
• Implementers: Sonnet, Grok, and Terra
• Fast utility models: Sonnet, Gemini Flash, and Composer
• UI/UX and design specialists: Sol, Gemini Pro, and Gemini Flash

Rolling this into the SDD workflow we discussed before, here is how we select which model to use for each of the stages:

• Sol writes the specification.
• Fable creates the implementation plan.
• Opus reviews the plan.
• Sonnet, Terra, or Grok implements it.
• Gemini Pro performs a broad repository-level gap analysis.
• Opus or Sol performs the final security and performance review.
• Sol or Gemini Pro handles UI/UX design and marketing-related changes.
• Composer, Terra, or Flash handles the remaining debugging and fixes.

As with everything AI-related, the more context the model has the better it will perform. This can be frustrating for someone who just wants to come in and one-shot something.

Before having your Architect model create an implementation plan, provide it with several different specification files that describe the product, features, and various guidelines you want the AI agent to respect. You will spend much more time writing and reworking spec files, but the outcome will be much higher quality.

Switching between models and having them review each other's work is also a critical part of finding gaps or problems. Just like in the real world, having a fresh set of eyes on something can often surface issues you previously overlooked. Do not let one model author, implement, review, and approve the same feature — split this up between several different models.

The best AI engineering workflow is not built around one model. It is built around a clear specification, deliberate division of labor and multiple independent opportunities to catch mistakes before they reach production.

This isn't one-size-fits-all, but this is the thought process I use when designing and building new products and features.

We’re using this exact workflow to build our Notion competitor now. When it launches, you can judge the results for yourself.

Cheers,

Ryan