Author here. I work at Sanity, so I'm obviously looking at this through our lens, but I tried to write it as general advice for anyone building developer tools and haven't thought that much about agents yet.
The thing that prompted this: I kept having conversations with teams where the first question was "how do we write better skills files?" and I kept finding that the issues were upstream in our error messages, CLI surface, and so on. I increasingly feel that Skill files is your "last resort."
The Workbench experiment in the post is admittedly simplified to unpack the mental model; you would probably set up evals etc to actually test it, which we have started doing at Sanity as well.
Happy to answer questions and channel more of our experience with agents (heh) and designing for them.
I work with Rosti at Sanity and helped get the word out on this. The core problem is that logos vary wildly in aspect ratio, pixel density, and visual weight, so lining them up at the same height or width never looks right.
Rosti's approach uses three things: proportional normalization based on aspect ratio, pixel density analysis (so a dense wordmark doesn't visually overpower a thin logomark), and a center-of-mass calculation for optical alignment. The perceptual sizing math builds on Dan Paquette's earlier work.
Author's colleague here. Rosti wrote this after we kept running into the same problem across customer sites.
The core formula is Dan Paquette's proportional normalization (aspect ratio raised to a scale factor), but the density compensation and visual center-of-mass calculation are the interesting additions.
The visual center algorithm weights each pixel by sqrt(colorDistance) * (alpha / 255) to find where the "ink" actually lives vs. the geometric center. It's a subtle effect but makes a noticeable difference with asymmetric logos.
Fair point, we appreciated that courtesy, and I should have reached out first. That was a miss on my part.
My thinking was that it became public pretty quickly once your post went viral (folks were already connecting the dots in the replies), and it felt awkward to respond to the substance without being direct about the context.
But you're right that a heads-up would have been the better move.
(I wrote the response) Just because it's marketing, doesn't mean it can also be educational?
I am a marketer and a developer. But I also know that you don't get far by trying to trick people into your product. As a marketer, I also get front row seat seeing how software plays out for a lot of businesses out there, and I have done so for a lot of years. I wanted to share those perspectives in response to Lee's write-up.
So yes, obviously both these pieces make a case for how the software we're employed by solves problems. And anyone who has been in developer marketing for a while knows that the best strategy is to educate and try to do so with credibility.
But in that bias is a ton of experience in the CMS field and a lot of observation of actual teams trying to solve for content operations challenges. I think that's valuable to share, even if we happen to also sell a solution to these things.
She's our recruiter at Sanity. Never coded. Wanted a pottery portfolio. 7 hours with Cursor later, she had a live site. Didn't know what "deploying" meant when she started, debugged until 4AM, maxed out Vercel's deployment limit. But she shipped!
I wrote a piece a few years ago that still reflects a lot of my thoughts on the tension between Markdown as a format and the actual experience of writing and publishing on the web: [“Thoughts on Markdown” – Smashing Magazine](https://www.smashingmagazine.com/2022/02/thoughts-on-markdow...).
What Apple seems to be doing with Notes—embracing Markdown syntax but not treating it as a source format—feels like a pragmatic move. It acknowledges Markdown’s familiarity without overcommitting to it as a canonical format. That distinction matters: many people like typing emphasis or `code`, but few need or want to version-control or export that exact syntax. It’s the gesture of Markdown that carries value for most users, not the fidelity to a plain-text artifact. "Even" Google Docs implemented it recently.
In my article, I argue that Markdown is increasingly a “source language” for interfaces, not documents, and this Apple Notes move seems to align with that trend. Curious how others feel about Markdown as an authoring experience vs. a content format.
Hi! I work at Sanity and wanted to share a blog post I co-wrote about our new Live Content API. We’ve tackled the challenge of delivering real-time content updates directly from our CDN, allowing it to scale without the usual caching headaches. We’ve also created a simple Next.js abstraction to make it easy™ to implement. Would love to hear your thoughts!
You could actually always host the Studio yourself, since it's an SPA. What's new is that we refactored it out of its custom webpack tooling and made it “just a React dependency” which allows you to embed it into other applications.
It's true that the Studio connects to the hosted data store (<pitch>but as many free projects as you want with pay-as-you-go for overages</pitch>), so the use case is the optionality to have your content workspace with your content models close to where you're consuming it. It also allows you to put the content workspace on a route so that content creators can go to a `/admin` or similar to edit content.
* What you find finicky with installing basic components
* What SEO issues that are connected to using GROQ/TypeScript
As far as I can gather from the docs, Payload doesn't come with more out-of-the-box components, and doesn't support custom blocks in the rich text editor, unless you commit to building the UI for it yourself?
Knut from Sanity.io here. First of all, congrats on the launch and what seems to be a well done product!
And to be a bit nit-picky and to clarify our world-view: The API side of Sanity isn't 3rd-party (it's native to the platform), but it is hosted and propertary.
There are always trade-offs, so no, you don't get the kind of control you get when you host your own Express-server or sit on your own MongoDB instance, but then again, you don't have to do those things to have a scalable real-time document store that supports deeply nested document structures with queryable references (with referential integrity). We build our APIs specifically to improve developer experience where we take care of the hard parts™ so that you can focus on the productive things. All of our HTTP APIs are versioned, because we specifically want to avoid breaking changes as much as possible.
Furthermore, there are other things that you just get. Like GROQ which is way more expressive and flexible for querying data compared to GraphQL (which we also offer). You get on-demand image transforms. You get both content and assets behind a CDN. You have a mutation/patch API that can do transactions with pretty specific operations (“change only this value in an nested array for this key if it matches this value”). Since the backand has full attributed revision history, you can also have controls that prevents race conditions, so that you can programatically update documents even if people are editing them. You can define triggers for webhooks and its payload with GROQ, so you can use serverless functions (or a server) to update content based on conditions. You can hit the export API endpoint and get all of your stuff over a stream wherever you want it. And so on and so forth.
Of course, there are always use cases where you want a solution that can be run fully on-prem or specific bespoke behavior in the database/API-layer beyond the capabilities in the platform. If you need those things, then you should probably look elsewhere than Sanity.io, and Payload might be an excellent choice.
Thanks for these links! I tried to track the origin down, but there's only so much digging one could do. But I think it safe to say that Jekyll _popularlized_ the YAML-style frontmatter.
The thing that prompted this: I kept having conversations with teams where the first question was "how do we write better skills files?" and I kept finding that the issues were upstream in our error messages, CLI surface, and so on. I increasingly feel that Skill files is your "last resort."
The Workbench experiment in the post is admittedly simplified to unpack the mental model; you would probably set up evals etc to actually test it, which we have started doing at Sanity as well.
Happy to answer questions and channel more of our experience with agents (heh) and designing for them.