By Knut Melvær
Published
We want to tell the stories from building the AI Content Operating System. And how we think about agents helping us out.
Jump to section
As I stepped through the door of Sanity’s first office, back in 2017, I walked right into a micro-brewery connected to… Sanity. In some ways, the space fit the old startup garage-cliché, a former train-carriage depot turned burlap sack shop
It was a space giving ”clever people work here.”
If you peeked at the screens of the two-and-a-half handfuls of people working there, you’d see them coding on the systems that make it possible for me to write, edit, and publish the very post you are reading now. The beginning of what became the AI Content Operating System, powering the content ops for the businesses whose logos you can look at on our homepage, and many many more.
They were coding on a real-time document store
All of this to say, engineering culture is at the heart of Sanity.
We figured it was high time to give these engineering stories their own place and share more from what we learn when building for and with agents.
If you want your startup to succeed, you have to focus and prioritize. That’s probably why it took us about nine years to make an engineering blog. We have mostly spent our attention on ways to unpack why and how to use Sanity to solve your content operation challenges through our product blog, documentation, and learning academy.
But there has always been this nagging feeling that it would be cool to publish more about the work that goes into our products, features, fixes, and experiments. Lab notes of sorts. Tales from the trade.
And this, this blog, that is, is what that is.
We have already told some of these stories to give you an idea of what you can expect going forward. Some recent examples:
- Rosti on how he solved the “logo soup” problem with good old maths
- Vincent reflected on how AI has changed his, and his team’s, engineering practices
- Apropos agents, Even and I wrote about how to write for them
- Jon told us how we implemented feedback mechanisms for MCPs
- Cody unpacked why we had to fork Styled Components
- And Simen (and his agent) told the story of solving the agent-memory problem (before it was cool)
These posts inspired discussion. Which is also our goal with this blog.
Except us to write a good deal about agentic engineering, but there will also be stories that doesn’t touch on AI as there is still plenty of engineering challenges to be had outside the real of Large Language Models.
But you don’t simply ship an engineering blog in 2026 without addressing the token-slurping elephant traversing multi-dimensional vector space on behalf of most of us who produce code as a professional trade.
If you have followed the discourse online lately, you know that there is a lot of talk about “AI-slop”: Claude watermarks, the new “report slop” affordance on LinkedIn, and the changing work-place dynamics of asking colleagues to engage with your LLM output, by some called “being a meat proxy.”
Recently, the prolific Sophie Alpert shared Clay’s internal AI writing policy, which resonated with a lot of folks. The heart of the policy is that the act of writing is how you can hone your ideas and sharpen your arguments. Case in point, what you’re reading now is the fifth iteration of this blog post.
“Good writing is a tool to clearly communicate ideas from your brain into someone else’s.”
I have noticed engineers getting “slop-fatigued,” and frankly, I can relate too. No wonder, as we spend our days reading AI output. In our #ai-chatter channel, I have even seen my teammates choosing models based on communication style, and not coding evals. So it feels like an engineering blog should offer some relief, and something that carries the unique voice and feel of our unique authors.
But does it mean we should just ban AI from the writing process? I’m not so sure.
My colleague (and Sanity co-founder) Even offered some interesting perspective when I discussed earlier drafts of this post with him. My first drafts started with the position of “no AI-slop in this shop.” He pointed out that reading AI-generated texts published under a human handle still takes us to the uncanny valley, but for cognition. It’s hard to tell what is the direct result of your fellow human’s thinking, and what is the statistical by-product of their prompting and specific context window. And this uncertainty makes us uncomfortable.
I relate to feeling somewhat “tricked” when realizing I’m reading what someone copy-pasted from their agent’s response. It spawns some uncertainty around whose thoughts you are engaging with. And certainly, you don’t need to scroll much on social media before you spot content that obviously wasn’t read carefully, nor critically, before it went out. But that is not new behavior, nor is it the fault of AI.
Posting AI-slop is a very human behavior.
The fact that people are using AI as a shortcut to post uninspired nonsense on the web for clout can hardly be taken as an argument against exploring how AI can help us to tell stories from our engineering work.
Tempting as the absolutist stance of banning AI-generated writing altogether can be, it doesn’t feel particularly “engineery” either. Especially not for a company that invests a butt-load of time and tokens figuring out how AI can help us with content operations.
Rather, it is a worthy intellectual pursuit to figure out how we can use AI to help us tell these stories with rigor, curiosity, and taste. And report on what we learn along the way.
And if you read Sophie’s blog post closely, you’ll notice that she holds the door open that “AI-writing” might read better in the future. For us, that future is now, with a few asterisks.
npx skills yourself out of slop
We have tried most of the tricks to make agents write well. Sophisticated skills that ask an agent to check for all the AI-tells, giving it hand-written samples to mimic, telling it to use ASD-STE100 Simplified Technical English, adjusting temperatures against base models, even experimenting with fine-tuning a model on your own pre-2023 writing.
These might take out the most obvious stuff, but if your audience is discerning readers—which a lot of engineers tend to be—you will find yourself peeling the onion of AI-tells far enough until there is nothing left.
Then again, it’s not like publishing texts with some AI-tells hasn’t worked for us.
We are just going to own this outright: If you run our blog content through Pangram, you will find that we indeed have published posts that are more or less AI output. But it is a mistake to assume that they weren’t products of care and critical thinking.
Some of these posts did great in gaining readership, they inspired discussions on places like Hacker News, and they made us real business. Some of these posts wouldn’t have happened if it wasn’t for AI letting us write them from transcripts from internal presentations, slide decks, Slack threads, and deliberate prompting.
Dismissing an argument because of its AI-tells is its own kind of lazy.
What we learned is that the best results tend to come from giving agents a lot of natural language to transform into structured prose. Then you work on it with agents and your human colleagues, until you have something you feel good about. Finally, it does help to do a good old editorial pass on the keyboard before pressing publish.
What doesn’t work is to give agent a bunch of context and ask it to one-shot you a blog post. But that is the case when you sit down with your fancy pen scribbling down your stream of consciousness into your Moleskine notebook too.
AI is not a shortcut to good writing, but it can help you make it happen.
If you think twice about the “writing is thinking” argument, it’s a somewhat ableist stance. Far from everyone feels super-confident to sit down and type out their thoughts into a blank document. It’s not necessarily super common to “think” within the typing-on-a-keyboard-reading-on-a-display-feedback-loop like some of us have become used to.
On the contrary, what I have observed is that more and more of my colleagues sit down to talk their ideas and thoughts out with an agent that they employ to challenge their arguments, or act as a personal secretary. From this angle, AI feels like empowering technology.
A lot of thinking has been done throughout history, without the writing part. In fact, as Even explores in this AI-generated—but human-edited—blog post, some of the old wisdom-loving Greeks weren’t too enthused by the idea of writing either.
But half-baked ideas will always be half-baked, regardless if you use AI. And we do understand that readers who interface with a lot of AI content become sensitive and tired from the same word choices and stylistic devices that tend to come out of our current models. So we will try our best to avoid those load-bearing genuine AI-tells that seem to rub some folks the wrong way as they delve into our posts.
Engineering posts, as with most prose, generally get better when someone takes the time to read them carefully with the right contextual awareness. The latter is where agents most often have a hard time, and we humans still have somewhat of an edge.
How a blog is built is maybe not the most exciting piece of engineering we do, but we should talk about it still. Of course, under the hood, we are using Sanity for content. We have equipped our Portable Text Editor with custom blocks like the usual suspects (image/video/codeblocks), but we also have things like footnotes
The frontend is built with Astro and the various visual elements are generated from the Portable Text payload with different programmatic rules to avoid pattern repetition. If you are reading this in a desktop browser, you’ll notice the that the table of contents has subtle hints at different blocks in the post.
export function collectTocEntries() {
const entries: TocEntry[] = []
for (const block of blocks) {
if (block?._type !== "block" || !block._key) continue
if (block.style !== "h2") continue
const title = (block.children ?? [])
.map((c) => c?.text ?? "").join("").trim()
if (!title) continue
entries.push({
id: scrollableKey(block._key),
number: String(entries.length + 1).padStart(2, "0"),
title,
})
}
return entries
}The code example above is simplified, but serves as an example of what you can do when your block content is structured data.
If you add .md to the URL of this post, it will return the Markdown version. This is primarily for our agentic readers who might swing by. Generated from the same Portable Text payload using the @portabletext/markdown package. And if you stick Accept: text/markdown in your request header, you'll get exactly that back. You can head over to our course on Sanity Learn to learn how to do this.
The generative drop caps that you see in some of the sections started as a hand-painted alphabet in Figma. Kevin then took Lars’ direction and encoded it in code with some subtle animation when you hover over them.
Furthermore, we added some algorithmic rules to when they should render to ensure they only come after an H2-heading and not if the section is short. In fact, there are a lot of these algorithmic design mechanics throughout this site.
If you are on a desktop, you’ll notice that the left-side scrollbar is in fact a min-map hinting at the block types and headings. You can hover it to quickly orient yourself in the text. We wanted to build a blog that could hold long reads comfortably.
We look forward to developing and experimenting on these blog surfaces even more. We have already planned to power a newsletter, and add other features and easter-eggs that tell a broader story of our engineering culture.
The concept of a Ralph loop (aka the agent loop) is now an important paradigm within agentic engineering. It’s one of those simple, but powerful ideas: Just put the model in a loop with a set goal, and don’t let it escape before the goal is met by some criteria. It is adopted by pretty much every agent harness out there.
Similarly, this engineering blog is our human loop where someone shares their work, talks it out with their agents and colleagues, gets feedback, writes it out, iterates until the argument and story feel solid. Then we publish.
And this is where you, dear reader, gets to run the next iteration, and tell us if we met your criteria for what is an interesting read.
You can subscribe via RSS to get notified about new posts in the future, and follow us on social to tell us what you think (we really want you to!).
More from Engineering