I do not have a favorite AI model in the way people sometimes have a favorite programming language, camera, or brand of power tool.
I have models I prefer for different kinds of work.
That distinction has become central to how I build software. A product does not require one continuous type of intelligence from the first idea through release. Architecture, first implementation, interface refinement, clickpath testing, debugging, documentation, and production review are different roles that require different modes of thinking. Asking one model to perform all of them is convenient, but convenience is not the same as efficiency.
My current workflow is imperfect and still evolving. But I consistently get better results when I change models as the nature of the work changes.
“Which model is best?” is usually the wrong question
Model comparisons often collapse software development into a single benchmark. One model solves more tasks. Another responds faster. Another is cheaper per token. Another produces an interface that looks prettier on the first attempt.
Those comparisons can be useful, but they do not resemble the full lifecycle of an actual product build.
A product begins as an unresolved system. Someone needs to define the user, the commercial boundary, data model, trust, failure states, and definition of done. Later, the work becomes narrower: make this screen understandable, repair this redirect, trace this missing authorization check, hey our button doesn’t work, etc.
The best model for an ambiguous architecture problem may be an expensive way to fix the button. The model that quickly cleans up a clickpath may not be the one I want making an early decision about downstream agent instructions, API routing, OAuth scope, or billing state.
So I have stopped asking which model should build the product. I ask which model best fits the job directly in front of me.
Phase one: use stronger reasoning for the shape of the system
I tend to begin with Fable when the product still needs a framework or a serious first crack at implementation. This is where I want breadth. I need the model to hold product goals, system behavior, security, data relationships, pricing logic, edge cases, and extensibility in the same conversation.
The output I want is not simply code. I need a sturdy foundation that won’t unravel like a house of cards when we disturb it with later additions.
At this stage, we’re answering big questions and making sweeping requests. I invite the model to ask as many questions as it can out of initial requirements documents and this often steer into philosophy of product, customer engagement, and other useful rubrics for current proof of life vs final deliverable product.
I find Fable exposes contradictions before they become unmanageable spaghetti. It also produces a coherent initial implementation that gives other models something concrete to attach to.
This is where the luxury models earn their keep. A bad architectural decision is much more expensive down the road (ask me how I know).
Phase two: downshift when the problem becomes experiential
Once the underlying system is stable, we maybe don’t need all the brain power the more expensive models bring. Content hierarchy, dialogues, almost all UX challenges and frontend broadly can be handled by lighter weight models.
For interface and clickpath work, I often downshift to Opus, Sonnet or really any of the mid-range GPT models. These models are fast enough to support repeated visual and behavioral iteration without spending top-tier reasoning on every adjustment.
That does not mean interface work is intellectually trivial. Good interaction design requires judgment. But when we’re discussing human layer items at frontend, it’s only natural that the human user takes over more of the cognitive load for decisions and guidance. There’s genuinely less for the model to do at this point.
The goal is to match the cost and tempo of the model to the current problem.
Phase three: switch again when something breaks
I’ll be honest. GPT-5.6 Sol sometimes drives me crazy for being a tad overbearing with re-re-testing the test and then testing again just to confirm. However, there have been times I wished I had put it to work on a project sooner for precisely this reason.
When the product behaves incorrectly, I want a model that will stop decorating the solution and isolate the failure. I have found GPT-5.6 Sol particularly effective for focused problem-solving: inspecting the evidence, tracing state across files, challenging the current theory, and making the smallest repair that explains the observed behavior.
Sidenote: it is good to babysit this model and read along very carefully while it’s working. Sometimes it can lose the grand perspective we discussed with Fable and decide that “making the smallest repair that explains the observed behavior” means ambitiously helping you overwrite your entire architectural flow. (ask me again how I know)
That said, a model that remains in expansive product-design mode can make debugging worse. When using Fable, I find a tendency to solve the bug it expected rather than spending the time validating the evidence beforehand that Sol will take, and that often yields better results.
I’ll add that there’s never anything wrong with swapping the models in and out like a team to evaluate before taking any action, or asking for a second opinion from outside the workspace (see below).
Model switching is also budget management
Frontier models perform long (long), complex reasoning cycles and that capacity can consume a lot of resource. Leaving the most expensive model attached to every stage of a build is the AI-development equivalent of keeping the front door open with the air conditioning running.
My current direct model and tooling cost for deploying a logically intensive application appears to land around $400. That is an emerging personal benchmark, not an industry average. Application scope varies too much for the number to stand alone, and it excludes the value of my own product judgment, review time, and accumulated frameworking experience; i.e. extensive time commitment still.
Still, the number is useful. It gives me something to compare across builds. Did the application become more complex? Did I spend too long asking a frontier model to polish a simple task? Did a cheaper model create rework that erased the savings (or surprise me and crush right through the work)? What effect has iterative planning over multiple projects had?
Bottomline: token efficiency is not about always choosing the cheapest model.
Use a separate room for higher-order thinking
Not every useful AI conversation needs to happen inside the build environment. When I am still asking “What is this?”, and trying to get the shape of things, I often take the problem to a personal subscription account first, or even bounce it off of an open session Chat GPT session just to get a totally tabula rasa impression of things.
The costing analysis is straightforward. Broad conceptual exploration can consume a remarkable amount of conversation without producing a line of deployable code. Yes, many agentic coding surfaces have tandem “ask” and other states, but the per token cost still doesn’t pan out in my observations (especially with the frontier models). For someone already paying a flat subscription, a personal account can be a cheaper place to hash things out than a metered development account. More often than not, you’re getting the same reasoning model without the dev tax. In some cases, the lack of repository level view of your project can even be an advantage for staying requirements-focused on the final product. Think of your personal account as the PM x DPM layer, and the agentic environment as your PO x Lead Architect layer.
The separation is valuable beyond cost. Higher-order product thinking is allowed to be exploratory, circuitous, and occasionally wrong. The dev environment can remain grounded in the repository and the exact constraints of the build. Instead of carrying an entire wandering conversation into development, I carry forward a compact decision brief reduced to deliverable requirements.
A second model can also serve as an inexpensive skeptical reviewer. I might ask one model to develop the premise, another to challenge its implications, and the implementation model to test both positions against the actual system. The point is not to average three answers or crown a winner. Disagreement helps identify assumptions that still need evidence.
And, less scientifically: it’s fun to watch the robots fight :D
The human is the routing layer
This workflow does not automate away product leadership. It makes product leadership more visible.
The models do not reliably announce that the nature of the problem has changed. I have to notice that we are no longer designing the system and are now polishing it—or that we are no longer polishing it because an authorization path is broken.
That requires me to keep ownership of:
- Problem definition and commercial intent
- Task decomposition and model selection
- Acceptance criteria
- Security, privacy, and claims boundaries
- Evidence used to diagnose failures
- The decision that a capability is ready to ship
A multi-model workflow is not a committee of artificial developers independently producing a product. It is an operating system directed by a human who understands the difference between an idea, a plausible implementation, a validated feature, and a deployable business capability.
I do not always switch at the right moment
I am not perfect at this.
Sometimes I leave an expensive model polishing hero banners. Sometimes I ask a mid-range model to keep wrestling with an architectural contradiction because switching feels like an interruption or I just plain forgot.
Context creates inertia. Starting over with another model can feel wasteful. But accumulated context is not always useful context. A fresh model with a narrow problem statement, current evidence, and explicit acceptance criteria can outperform a long-running conversation carrying every abandoned theory from the build. This is especially true in agentic coding environments where the model always has the entire repository available for reference.
The workflow works best when I pause and ask one question:
What kind of problem is this now?
That question is usually more valuable than asking which model won this month’s benchmark.
A practical model-routing checklist
- Use high-reasoning models when the system is still ambiguous, decisions interact across layers, mistakes create architectural debt, or the first implementation needs to establish a reusable pattern.
- Downshift when the work is bounded, observable, repetitive, visually testable, or supported by clear acceptance criteria.
- Switch into debugging mode when the expected behavior and actual behavior diverge, evidence must be traced, or continued feature-building would bury the defect.
- Escalate again when the apparent bug exposes a deeper product contradiction, security issue, data-model problem, or incorrect assumption about the user.
Build the workflow, not the model dependency
The individual model will change. Capabilities will improve. Prices will move. Today’s premium may become tomorrow’s mid-range default.
Use stronger models to shape the system, faster models to refine the experience, and focused models to solve what breaks. The human remains responsible for knowing when to make the handoff.
Update, September 27: a week with Astra
After a week with Astra, I’ve had a chance to put it through its paces a bit more. I’d mostly conclude that it is “more of Sol” with one major caveat that may not always be ideal. Sol seems exceedingly user-oriented and has a tendency to at least confirm before it takes broader action. Astra seems to be more autonomously driven toward whichever solution it has derived, even to the exclusion of user inputs and preferences. It’s powerful and it cranked through some major changes to a product build I had rather quickly. It also broke some critical infrastructure by overstepping well beyond our agreed range.
It’s always good practice to carefully describe include / exclude lists at each phase of work, keep an ongoing “permissions gate” and agreed requirements to check in before any scope, lock down certain sections of your code as sacrosanct and untouchable, provide design frameworks and clear build requirements in an iterative and curated way… but Astra still takes a special amount of babysitting and handholding in my brief experience.