GPT-4.1 made coding models feel specialized

GPT-4.1 made coding models feel specialized instead of generic.

The useful part of the release was the shape of the family. Full, mini, and nano made the routing problem visible. A repo-level repair task is not the same thing as a quick diff summary. A migration is not the same thing as a type error. A broad rewrite is not the same thing as one small fix. One default model hides those differences and makes every code job look like a hammer job.

I think of the family as a set of different tools for different failure shapes.

job	route	why
explain a test failure	mini	cheap read of logs and stack traces
patch a tricky bug	full	needs broader context and better reasoning
summarize a diff	nano	short, narrow, and low risk
review a migration	full	higher cost of a bad change

That is the practical win. The product gets better when the route matches the job.

Long context helped, but only if patch discipline stayed in place. I still want the model to keep the change small, respect the surrounding files, and leave a readable working tree behind. A model that can see more of the repository is useful only if it still behaves like a code editor and not like a rewrite bot.

For me, the specialization mattered because it made code work easier to route by intent. Not every code task deserves the same model, the same budget, or the same review path.

The practical example is boring. A typo fix can go through the cheap route and return a one-file patch. A failing migration might need the full model because the surrounding schema changes matter. A git diff summary can go to the nano route and produce a readable change log for a reviewer. The family only becomes useful when the product can say which job is being asked for before it burns the bigger model on everything.