!
This article is a reprint from I've Started Using Claude Code.
Fable 5—the smartest model available, but only for a limited time—will end its run on July 7th. A little before that, the same story was circulating on X. Use this smart model while you can to build your development environment; invest before it disappears. People were sharing configuration files and diagramming how to use different models. Everyone was trying to take that intelligence out of their own environment.
My interest was one step before that. There was something that had been nagging at me. If AI keeps getting smarter at this speed, won't the tricks I've built up become obsolete with each new model, eventually making all of them unnecessary? If so, investing time in current tricks would be a waste.
So, while the smartest model was available, I decided to use it. I wanted to see whether my accumulated knowledge was already outdated.
I Verified the Hype with Official Documentation
To put the claims floating around on X into one sentence: "You can't buy intelligence itself, but you can transfer the patterns of smart behavior to cheaper models through certain configurations." The idea was to solidify your workflow with the smart model while you can, then have the cheaper model replicate the same behavior.
I wondered if it were really that simple. If copying behavior alone transfers intelligence, that would be ideal. I've built up my environment quite a bit. I checked the official documentation to see if it could really be transferred.
What I found was two things. First, for smart models, giving overly detailed instructions can actually degrade quality. For older models, detailed notes might be helpful, but for smart models they become obstacles—consider removing them. Second, those "patterns of behavior" were explicitly called out as something to consolidate in a constitution file (CLAUDE.md) that you pass to the AI. The transfer discussion was about bringing that into a different configuration.
It turns out that adding instructions to a smart model isn't the right approach. The smarter the model, the better it is to give just the key points and let it handle the rest, rather than micromanaging. If the official docs are correct, we should be moving toward removal. But where and how much to remove? Deciding what's "unnecessary" myself would mix in attachment and bias. So I didn't make the decision myself; I left it to Fable and the verification process it runs. I just watched what happened.
I Had My Own Constitution Attacked for Deletion
That verification used a method where a separate AI deliberately presents counterarguments to try to tear down the original claims (let's call this role the "refuter"). Fable took my constitution (a global CLAUDE.md that compiled all the practices I wanted the AI to follow) and distributed it to eleven refuters, having each read it in the same way. "These are excessive instructions for old models, garbage that a smart model no longer needs. Identify clauses that can be deleted, and go ahead and delete them." With deletion as the goal, eleven refuters read the constitution separately.
The result was unexpected. Not a single clause could be purely deleted. Every one served some purpose. Moreover, five clauses that seemed obvious—ones I thought wouldn't hurt to remove—the refuters actually pushed back, saying "these are necessary." Left to its own devices, a smart model tends to ramble and do things you didn't ask for. Those five clauses specifically curbed that tendency. For example, one rule: "only do what was asked, don't expand on your own." It seemed obvious, but the refuter showed that removing it would cause the smart model to start expanding its own work. The more obvious something is, the more it needs to be written down and enforced.
This was the first answer. In light of a smarter model, my accumulated knowledge wasn't outdated. I tried to delete what I thought could be removed, and everything survived.
I Consolidated Scattered Projects from a Single Seat
The fact that the constitution survived intact meant that the practices I'd accumulated since February were still effective. To make those practices work across all projects, the folder structure and workflow needed to be consistent. But my projects had diverged in approach since February, with different structures and workflows depending on the machine. So, while I was reviewing the constitution, I also standardized the projects. Looking across all machines, I found about fifty project folders. Leaving them as-is would cause trouble later. Among them, I standardized eighteen active projects into a common template in one day.
Going through fifty folders alone would be impractical. What helped here was a tool I'd built earlier (aiterm). I designated one seat for issuing commands (in my case, a configuration project). The smart model sitting there would call, via aitem, the Claude instance running in each project's folder. The called instance would work with full knowledge of that project's contents. If I'd tried to rewrite everything remotely without knowing the contents, I'd likely break things. Because each project's designated handler worked with its own context, the work remained grounded.
Which project to assign to which AI? This allocation I left to the smart model in the command seat. I only gave the policy: to save costs and available usage, use several cheaper AIs (e.g., Codex for reviews, another AI for bulk rewrites). Initially, the allocation wasn't working well. So I gradually added requirements, and each time it worked, I recorded the allocation method in the constitution file. I repeated the cycle of fixing and recording, cultivating it. The next time a similar task came up, the recorded knowledge allowed it to be allocated more intelligently from the start. I also subjected this tool itself to the same refuter process later, to scrub it of flaws once.
Even When the Model Switched Midway, Work Didn't Stop
On July 4th, I ran the smart model fully for one day and had largely built the foundation up to that point: how to orchestrate multiple AIs, project standardization, the configuration project, and the aiterm tool. The next day, the 5th, the smart model quota was exhausted. From there on, I switched to the usual model (Opus).
Models are replaceable parts; accumulated ingenuity and structure remain. The role-to-model mapping table, folder templates, trap records, and practice constitution form the foundation, so work doesn't stop even when the model is switched.
Even after the switch, work didn't stop. The usual model ran through and completed the remaining finishing work. This was because everything was built from the start to work with any model. There are three ways to make the design model-agnostic.
First, write the model name in only one place. Have a single mapping table that says "for this role, use the strongest current model," and don't write dated model names in code or rules. When the model generation changes, rewriting that one sheet updates everything.
Second, standardize project folders to the same template. Locations are fixed—design decisions go here, research findings go there—so an AI entering a project for the first time, regardless of model, can look at the same places and work.
Third, have a mechanism to remember traps you've once fallen into. Record them so they can be referenced to avoid repeating the same mistakes—so even when switching to a new model, you carry forward the traps the previous model encountered.
None of these rely on the intelligence of a specific model. What's worth building while you have access to a smart model is this kind of design that outlasts model changes. The proof is the fact that even with a mid-course model switch, the work ran to completion.
Enforcing Rules Through Friction
With the same thinking as making mechanisms model-agnostic, I also changed how rules are enforced. As work progressed, a hole appeared in my approach. Even though my AI was the orchestrator, it sometimes hoarded routine tasks (writing many tests, creating configuration files) that should have been delegated to cheaper AIs, consuming its expensive quota. The rule was clear: pass routine tasks to cheaper AIs, and let the orchestrator focus solely on decisions. It was decided, but unless told, it wasn't followed.
Writing "be careful" in prose requires willpower to follow. Willpower, left unchecked, loses to the path of least resistance. So I made the desired behavior the default, and added friction to the lazy option. Before starting to write code, the AI must always label each task as either "do it myself" or "delegate to a cheaper AI." If deciding to do it themselves, they must write one line explaining why. Because writing a reason is bothersome, the default naturally shifts toward "delegate." Additionally, I set up an automated mechanism to inject a memo reminding them of this practice the moment a plan is approved.
What's injected is just a reminder memo. Whether it's followed depends on the reading AI—if ignored, it slips through. As for the pre-work labeling, it's still only written in prose and hasn't been mechanized to fire automatically. This is the weakest point. In the process of turning rules into mechanisms, half has become mechanized, and half remains just words.
I previously wrote about giving up writing "be careful" to the AI and instead reinforcing it from the outside with three mechanisms (The Story of Giving Up Writing 'Be Careful' to Claude and Reinforcing It from the Outside with Three Things). This time's rule mechanism is a continuation of that.
What Remained
The worry I had before starting—that my know-how would become obsolete as AI gets smarter—didn't happen for these two days. The accumulated ingenuity, even when scrutinized by a smarter model, all survived. The assembled mechanisms completed without stopping even when the model was switched midway. What newly remained from having access to a smart model was the design that outlasts the model itself, and the allocation method cultivated through repeated fixing and recording.
Top comments (0)