kmelve

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.

The core normalization logic is plain JS with no React dependency: https://github.com/sanity-labs/react-logo-soup/blob/main/src...

Someone already forked it into a framework-agnostic version: https://github.com/auroris/logo-soup

Rosti is around if there are questions about the density compensation or optical alignment math.

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.

Library is MIT licensed: https://github.com/sanity-labs/react-logo-soup

Live Storybook: https://react-logo-soup.sanity.dev

Working on getting Rosti signed up to HN for questions you might have!

It's strange to see folks here speculate about something you've written.

And if you only knew how much those headings and the structure of this post changed as I wrote it out and got internal feedback on it ^^_

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.

Yeah, we're looking into it!

Ooof. We should fix that!

Author here.

I don't know folks... Maybe I have been dabbling so much with AI the last couple of years that I have started taking on its style.

I had my digits on the keyboard for this piece though.

We're fixing every week! Have you tried it recently? Are there particular issues you're having?

Author here! Of course, I'm biased!

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.

I had the great pleasure of processing Sanity's donations to open source projects too. Hope other companies follow suit!

Pretty cool! The BlueSky API is on point. A colleague of mine put together this visualization based on the firehose: https://bigmood.blue/

Source: https://bsky.app/profile/even.westvang.com/post/3laob7tefxk2...

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!

Hi! Knut from Sanity.io here.

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.

Hi! Knut from Sanity.io here.

Would love to learn more about:

* 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.

The author here!

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 author here!

   Markdown is for writing not for editing. If you want to focus on writing, text, and content instead of on bells and whistles with formatting and typesetting it's really hard to go easier than Markdown.

The author here!

I'm kinda bummbed out that the post read as an ad. I was super nervous to publish this because it I knew I was poking at something that's near and dear to a lot of devs (myself included). But I have experienced enough friction with Markdown in the real world and wanted to explore poking what I see as the status quo. And it seems to have sparked some conversation, which was what I wanted. I'm truly not trying to “hawk” something, but I believe the thinking that went into Portable Text can provide value and I'm sort of putting it out there for people to make up their own minds.

To your point: I agree, Markdown is for writers, but only for some writers. Maybe I didn't get that across, but it is kinda amazing that it has become so ubiquotos in all its shapes and colors.

But it comes with these actual constrains and challenges that I feel a lot of developers aren't really being upfront or honest about. The simplicity comes with trade-offs that just adds complexity elsewhere. Either for people who don't desire to learn specialized syntax or developers who have to spend a lot of time figuring out how to parse it in a sensible manner to get their job done.

Sorry about that. You won't believe how long the first verison was ;)

The author here.

Yeah, I'm well aware that markdown didn't happen in a vacuum and was inspired by plain text formatting conventions. But there is only that much you can cover in an already too long blog post. It wouldn't have changed my argument much either. It wouldn't be historically accurate to say that Markdown existed before Gruber/Swartz, like it wouldn't be accurate to say that HTML existed before Tim-Berners Lee, even though SGML and such was a thing.

I'm not arguing for a more proprietary binary word processor format either. Or that we should type JSON. It's actually possible to have decent WYSIWYG editors that does their job. And they won't get better if don't put our minds to them.

The point you're missing in this reply is the legitime user-unfriendly experience of markdown and the challenges it poses for developers who are trying to solve things for their teams and customers today.

As the “humanities tecnologist” in question, I'd say that looking at technology as a result of and embedded in human history and culture can be quite interesting and you might even learn something from it. But of course, you could also read and relate to the argument on its own merits?

Hi, the author here! This is a misrepresentation of my argument. I'm not interested in locking you in at all, I'm actually arguing for the opposite. It doesn't even have to be JSON.

Sanity.io | US and Europe | Full-time | Sr. Front-End Web Developer, Full Stack Developer, Solution Engineer, Support Engineering, Account Executive, Recruiter

Sanity.io is the fastest, most flexible platform for delivering content to digital devices and products. Our platform is redefining the CMS market and changing the way organizations collaborate and work with content. We’re hosting a real-time API for structured content, an open-source editing environment built with React. We’re also building tooling for GROQ (a general query language for JSON), GraphQL, and portabletext.org.

We are growing fast, and are looking for a range of roles:

Sr. Front-End Web Developer

Full Stack Developer

Solution Engineer

Full-stack developer, Integrations

Support Engineer

And more!

Go to https://www.sanity.io/careers

We are a Series A company backed by Threshold Ventures, Ev Williams and more. We’re based in San Francisco and Oslo, running a remote friendly team setup.

Sanity.io | US and Europe | Full-time | Sr. Front-End Web Developer, Full Stack Developer, Solution Engineer, Support Engineering, Account Executive, Recruiter

Sanity.io is the fastest, most flexible platform for delivering content to digital devices and products. Our platform is redefining the CMS market and changing the way organizations collaborate and work with content. We’re hosting a real-time API for structured content, an open-source editing environment built with React. We’re also building tooling for GROQ (a general query language for JSON), GraphQL, and portabletext.org.

We are growing fast, and are looking for a range of roles:

Sr. Front-End Web Developer

Full Stack Developer

Solution Engineer

Support Engineer

And more!

Go to https://www.sanity.io/careers

We are a Series A company backed by Threshold Ventures, Ev Williams and more. We’re based in San Francisco and Oslo, running a remote friendly team setup.

Hugo doesn't have an easy way of making pages/paginating from an API yet, so you'd have to first generate the markdown files. That can be done though. Here’s a demo: https://codesandbox.io/s/rj4y72j34n

Sanity.io | Oslo or San Francisco | Full-time On-site | UI/UX developer, Digital product designer, and Inside sales account executive.

Sanity.io is the fastest, most flexible platform for delivering content to digital devices and products. Our platform is redefining the CMS market and changing the way organizations collaborate and work with content. We’re hosting a real-time API for structured content, an open-source editing environment built with React. We’re also building tooling for GROQ (a general query language for JSON), GraphQL, and portabletext.org.

We are growing fast, and are looking for a range of roles:

  * UI/UX developer. 
  * Digital product designer. 
  * Inside sales account executive. 
  * More positions to come shortly: Marketing Operations.  Specialist, Product Marketer, 
    Developer Relations, Support Engineer

We are backed by Heavybit, an accelerator in SOMA, San Francisco. All positions are onsite either in Oslo or San Francisco.