quick answer#
i am planning a recurring model review series on philliant on youtube. the working idea is to talk through “models of the week”, notable releases, and the models i am actually using for production work, with practical opinions based on use instead of launch hype.
the goal is simple. i want to give people a shortcut to understanding whether a model is likely to be useful to them, because i have already spent the time using it, grading it, judging it, and comparing it against the work i actually need to ship.
who this is for#
- people using ai models for real work, not only demos
- engineers, data people, writers, and builders trying to choose between too many model options
- anyone who wants practical model judgment from someone using these systems in production workflows
- future me, when the model names change again and i need a record of what actually worked
why this matters#
model announcements move faster than most people can evaluate them.
every week there is a new release, a new benchmark chart, a new context window, a new reasoning mode, a new coding claim, or a new tool-use demo. those announcements are useful, but they are not the same thing as living with a model inside real work.
my question is usually more practical. can this model help me ship something i understand and can stand behind? does it handle long context without losing the point? does it make good edits, or does it produce polished noise? does it improve my production workflow enough to earn a place in rotation?
that is the kind of review i want to make.
what i mean by model reviews#
i am not trying to become a benchmark channel.
benchmarks matter, but they are not the whole story. a model can look impressive in a release post and still be awkward in a real workflow. another model can look less exciting on paper and still become useful because it is fast, predictable, good with tools, or strong in one narrow lane.
these reviews will be working reviews. i want to talk about how models feel after i have used them to write, reason, code, review, debug, plan, and move production work forward.
that means the reviews will probably cover things like:
- what the model is good at in my workflow
- where it breaks down
- what kind of tasks i would give it again
- what kind of tasks i would avoid giving it
- how it compares with the models already in my rotation
- whether the release changed my actual behavior
the model of the week idea#
the phrase i keep coming back to is “model of the week”.
some weeks that might mean a brand-new release. other weeks it might mean a model i finally spent enough time with to have a useful opinion. sometimes it might be a direct comparison between two models that are competing for the same slot in my workflow.
i am still deciding the cadence. weekly might be the cleanest format if releases keep moving this fast. monthly might be better if i want more time with each model before saying anything public. release-driven episodes might be the right answer when something meaningful ships and deserves a timely review.
the format may become a mix of all three. a regular rhythm when there is enough to say, deeper monthly roundups when the week-to-week noise is too thin, and immediate reviews when a release is important enough to change the conversation.
empirical evidence over launch hype#
the part i care about most is empirical evidence from my own work.
i do not mean lab-grade measurement. i mean repeated use against the kinds of tasks i actually do. production code. data engineering decisions. writing. repo maintenance. documentation. debugging. model comparison. prompt repair. agent supervision.
that kind of evidence is not universal, but it is useful. if i tell you a model helped me with a hard refactor, i want to explain what made it useful. if i tell you a model fell apart, i want to explain where the failure showed up. if i tell you a model earned a place in my rotation, i want to explain what it replaced or what new capability it added.
that is the shortcut i want to provide. not a promise that my ranking should become your ranking, but a practical signal from someone already doing the work.
where this fits with the site#
i already wrote a snapshot of the ai models i actually use in cursor. that post is a written roster, and it is useful as a point-in-time reference.
the youtube version should be more alive than that. models change too quickly for one static page to carry the whole conversation. the channel gives me a place to talk through what changed, what i tried, what surprised me, and what i would actually recommend based on current use.
this also fits the broader reason i launched philliant on youtube. the site stays the archive and source of truth. the channel becomes the place where i can talk through the work in a more conversational way.
closing#
so that is the plan. model reviews are coming to the philliant youtube channel.
i will keep the focus practical. less hype, more use. less “this model is best”, more “this model helped me with this kind of work, failed at this other kind of work, and here is what i would use it for now”.
if the format works, it should help people spend less time guessing and more time choosing the right model for the work in front of them.
faq#
will this replace written model posts?#
no. the written posts will still be useful for reference, links, and slower thinking. the videos should add voice, timing, and current impressions that are harder to keep fresh in a static post.
will these be rankings?#
sometimes, but rankings are not the main point. i care more about task fit than a single leaderboard. the better question is not “which model is best”, but “which model would i trust for this kind of work right now”.
will you only cover coding models?#
no. coding and agentic work will be a major part of the series because that is where i spend a lot of time, but i also expect to cover writing, reasoning, long context, multimodal input, speed, cost, and general workflow fit.
