AI Engineer World's Fair 2026
Content Is Code
Read the talk
Content Is Code
AI makes code a practical medium for technical communication, but accurate changelogs, polished videos, and reusable content pipelines still depend on a carefully structured source of truth.
From a talk by Matt Palmer
Before you start: Basic familiarity with React components and pull requests is helpful for the code example and release workflow discussion.
Choosing a medium
Should this explanation be a blog post, a video, or a conference talk? The choice often follows the creator’s existing skills: writers write, video creators record, and speakers present. Code introduces another possibility—a medium for producing the assets through which an explanation travels. Matt Palmer frames its growing accessibility in 2026 as a departure from a world where creating content through code usually required a professional software engineer, whose time was mostly devoted to engineering.
Technical communication explains what problem a product solves. It includes documentation, changelogs, product marketing emails, video, and the broader work associated with developer relations, but anyone can do it. The standard is usefulness to the reader or viewer: documentation for a data access framework, for example, should accurately cover the whole framework, not merely introduce its most visible features.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A changelog starts with knowing what changed
A timely changelog with useful supporting assets depends on something less visible: an accurate product diff. Before explaining a release, someone—or some system—must establish what actually changed. Without that foundation, the work falls to a person combing through pull requests to reconstruct what shipped. Writing the announcement is only the last part of the job.
Once the changes are understood, they can be summarized over a longer period in product updates and emails. The same communication problem also extends beyond text: a homepage can show a product tour instead of a static screenshot. These formats all explain what a product does or how it has changed, using written material, code, and distinct visual assets.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Recreating a product surface in React
Video overlays are a relatively small application of this approach: code supplies an engaging element inside a larger production. The next step is to build the entire demonstration in code. Palmer shows a tour of Conductor made with React and Remotion. He recreated the product surface inside a Remotion scene and used it to walk through a sample user flow. The result is an authored interface demonstration, not a screen recording of the live product.
Remotion’s frame-driven React model makes the mechanism concrete: a component can select the interface state to display from the current video frame. A minimal illustrative scene might move a sample workspace from a preparation screen to a review screen:
tsx
import { AbsoluteFill, useCurrentFrame } from 'remotion';
export const WorkspaceTour = () => {
const frame = useCurrentFrame();
const reviewing = frame >= 90;
return (
<AbsoluteFill
style={{
backgroundColor: '#111827',
color: '#f9fafb',
padding: 64,
fontFamily: 'sans-serif',
}}
>
<h1>Sample workspace</h1>
<nav>Prepare → Review</nav>
<section>
<h2>{reviewing ? 'Review changes' : 'Prepare changes'}</h2>
<p>
{reviewing
? 'Inspect the proposed update before merging.'
: 'Describe the update you want to make.'}
</p>
</section>
</AbsoluteFill>
);
};
Here, the frame changes the rendered scene; it does not execute a product operation. This is the basic distinction that lets a recreated interface become a controllable video asset.
Palmer describes his tour as a prototype: it is a little buggy, and the flows are not fully worked out. His expectation is that this kind of production will become normal. Coming from data engineering, then leading DevRel at Replit and, at the time of the talk, developer experience at Conductor, he describes the broader change as content shifting left toward code as the source of truth.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From handcrafted assets to scarce engineering time
Palmer divides content production into three eras: handcrafted assets, expensive code, and inexpensive AI-assisted code. In the handcrafted era, the available levers are time, money, and skill. You make the asset yourself or hire someone with the expertise you lack—an agency or a professional motion graphics creator, for example. Personal effort eventually runs into the limits of the working day.
In the second era, code and cloud infrastructure are mature, but engineering becomes the bottleneck. Palmer associates this with the zero-interest-rate, or ZIRP, period: organizations pay heavily for engineers, and producing sophisticated assets requires access to their time. The supplier changes from an agency to an engineer, while the dependency on scarce expertise remains.
Robust documentation and polished websites compete with other engineering priorities. Palmer dismisses the earlier low-code website services as inadequate for the quality he wanted; in his account, a good website still needed a front-end engineer. That opportunity cost also explains his view of Remotion’s earlier limited adoption: the framework existed, but few people had both the time and the role of a content engineer. This is his explanation of the adoption pattern, rather than a measured usage history.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
TypeScript becomes a creative medium
In the third era, more of that production spending goes to providers such as Anthropic or OpenAI. Claude can help create videos, documentation, websites, and motion graphics. But access to generation does not guarantee a good result. Palmer emphasizes an engineering mindset and an understanding of the systems involved as the means to produce high-quality assets.
For Palmer, code or code generation is now the fastest way to prototype videos, websites, slides, images, and other creative assets—a practical judgment without a timing comparison in the talk. Preparing this presentation led him to a surprising conclusion: his favorite medium was TypeScript. Apart from recording himself and writing, he made the ancillary assets with React or TypeScript.
That preference did not come from deep prior expertise in the stack. His background is Python and data engineering, and he readily admits that his TypeScript is not especially strong. Nevertheless, React, TypeScript, CSS, and HTML have become the tools he needs to learn because they give him a route to high-fidelity visual assets. The medium follows what he can now produce with assistance, rather than only what he already knows how to make by hand.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Structure is the expensive input
If code becomes inexpensive, what remains expensive? Palmer declines the familiar answer of taste and points to structure. Producing a polished asset depends on maintaining the inputs that constrain it: a well-organized codebase, consistent brand guidelines, and design tokens kept distinct from front-end and back-end implementation. Those inputs give repeated generations a shared foundation instead of requiring each asset to reconstruct the design system.
The same discipline applies to the record of product changes. Clean pull requests need tags and useful descriptions. A feature should be distinguishable from a bug fix, and a reverted pull request should not disappear from the organization’s understanding of what happened. Palmer says none of the organizations he has worked at maintained the full discipline he describes. Internal documentation matters for the same reason: even capable agents need documentation or skills that explain how to accomplish the work.
These practices support different parts of the output:
| Structured input | What it helps preserve |
|---|---|
| Brand guidelines and design tokens | Consistent visual decisions |
| Separated code responsibilities | Clear sources for different concerns |
| PR tags, descriptions, and revert history | An intelligible account of changes |
| Internal documentation and skills | Knowledge needed to perform the task |
Together, they explain the difference Palmer draws between generic AI purple gradients and professional polish: the generated artifact inherits the quality of the material and instructions available to it. He connects that care to conscientiousness.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Care moves from making to checking
Conscientiousness means being meticulous, careful, and guided by a sense of moral or professional duty. In this workflow, its practical expression is checking that the outcome matches the intended result. As model capabilities improve, Palmer expects exceptional technical skill to become less decisive than the care given to those expectations and their fulfillment.
That is why he connects AI’s rewards to organizational excellence and structure, including the structure of AI skills themselves. A generated skill is not automatically useful: its contents and organization need attention. Palmer criticizes skills produced without that care, then returns to the assets shown at the beginning. He attributes them to design tokens, structured code, and structured assets, describing production without those inputs as “exponentially harder”—an expression of difficulty, not a quantified scaling result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Toward declarative content pipelines
Content can move toward the codebase only if the codebase is a structured source of truth. Moving production upstream does not remove the need for accurate product knowledge, consistent design, or operational instructions. It puts those responsibilities inside the process of creating software. The code can then serve both the product and the communication derived from it.
Palmer predicts that the best-communicating teams in 2026 and beyond will be the ones that instill discipline and rigor in software creation and bring content closer to that work. He calls 2026 the year of the creative technologist in DevRel and forecasts 2027 as the year of the content engineer. The distinction points toward a more systematic production role: building declarative, robust pipelines that produce walkthroughs, documentation, screenshots, and product updates. Previously manual assets become outputs created through code and React with AI assistance, grounded in the same structured material that defines the product.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Learn how React components, frame numbers, and composition metadata define a programmatic video.
Introduction to Conductor's coding-agent workspaces and review workflow.
Further reading
Official guidance for installing and using Remotion skills with coding agents to create, preview, and render videos.
Generate release summaries from merged pull requests and organize them with labels, categories, and exclusions.
Palmer's public post presenting a changelog concept created with Remotion and Replit.
Read the complete timestamped transcript
- 0:00
So if you've ever created content, you know it can be hard. And what's often most hard is choosing a medium for how you'd like to communicate. Do you write a blog post?
- 0:09
Do you create a video? Do you go out and speak at a conference? And even of these things, you're likely to select something that you're good at or you have experience doing.
- 0:17
But the idea I want to present to you today is that increasingly, code is becoming the way that we communicate. Now, this might seem obvious in twenty twenty-six, but I want to point out that even a couple of years ago, this was wild because the only people that were writing code to create content were professional software engineers.
- 0:34
And often, professional software engineers are spending their time doing mostly engineering and are not getting that deep on content. Now, what do I mean when I say content? Well, I'm talking mostly about technical communication, and that could be documentation, it could be things like changelogs, emails, product marketing.
- 0:51
It could be video, which I create a lot of. Um, and it could be other things associated with a typical DevRel motion, but it's not restricted to DevRel, right?
- 1:00
Content or technical communication is the act of communicating what a, what problem a product really solves, and that can be done by anybody. That might mean really complete accurate documentation that covers every part of the data access framework.
- 1:14
It could be changelogs shipped timely, um, with robust assets that cover all areas of a product. This is something that's often overlooked. This is actually really hard because to have an accurate changelog, you have to have an accurate diff of your product.
- 1:28
Or you could just have someone that spends a lot of their time combing through PRs to try to figure out what was shipped. It could be things like timely product updates, emails which kind of follow from a changelog, right?
- 1:40
If you understand what changed, you can then summarize that over time for your users. It could be something as simple as a homepage product tour instead of a static screenshot.
- 1:53
These are all ways that we're communicating products. We're communicating what this thing does or how it's changed via either written content, um, uh, free-- via code, via distinct assets.
- 2:09
It could also be something like video overlays, right? Something like, uh, adding a bit of, um, engaging material to the content that you create. But increasingly, where I think this is headed is entire product surfaces and entire videos generated via code.
- 2:26
And in front of me, I have a product tour for Conductor that was built entirely with React and Remotion. So basically, I recreated the product surface. I used a Remotion scene to recreate the product and do a full walkthrough, um, of a sample user flow.
- 2:43
Now, it's not perfect, it's a little buggy, and the flows aren't quite there yet, if I'm being honest, but I think we're moving towards a world where this is normal.
- 2:52
So my name is Matt. I was previously a data engineer, then I led DevRel at Replit, and now I lead developer experience at Conductor. And today, I wanna talk about how content is shifting left to code as the source of truth.
- 3:07
And so I think there are three distinct eras we can think about here. Era one, the handcrafted era of content. Era two, an era where code existed, but it was quite expensive.
- 3:17
And era three, where code exists, but it's very cheap, and that's where we are today with AI. So in the handcrafted era, right, everything is manual. The only levers we really have are time and money and skill.
- 3:31
And so if I want something, I either need to create it myself, but there are only twenty-four hours in a day, so likely I'm gonna go out and seek an expert, someone that does know how to create this thing.
- 3:40
Maybe that's an agency or someone who creates these assets professionally, if I'm thinking about, like, motion graphics, for example. Now, post era one, when we had expensive code, code and cloud are mature assets.
- 3:55
These are things that have existed for a while and most professional software engineers know how to use. Engineering is now the bottleneck. This is like Zerp era. Everybody's paying a lot for engineers, and to get anything done, you really need professional software engineers.
- 4:11
So you'd better pay someone, maybe not an agency, but an engineer. And that included things like, you know, um, robust documentation or even just a website, right? You-- Back in the day, it's hard to imagine before AI, you wanted a website, a good website, you needed a front-end engineer or, like, a low-code website service, but those weren't
- 4:29
any good to begin with. So you needed a professional engineer to have a really nice website. And what that meant was that content is really not the priority, right?
- 4:38
Because if you're a professional engineer, you have better ways of spending your time. And I think this is reflected by, um, libraries like Remotion, frameworks like Remotion, um, not proliferating the way that they are today.
- 4:51
Because really, who has the time and energy to put into these things? There aren't a ton of what I'd call content engineers. Now, in era three, most of these things, you're not paying a human, you're paying Anthropic or OpenAI or whoever, right?
- 5:05
You can create videos with Claude. You can create documentation with Claude. You can design websites with Claude, and you can create motion graphics with Claude. Now, the problem is that none of the-- all of these things are good, right?
- 5:16
We'll talk about that later. But if you know what you're doing, if you have an engineering mindset, if you understand the systems, you can create high-quality assets with these systems.
- 5:24
And I'm gonna talk about how to do that in the rest of this presentation. So today, code is cheap, and we talk about code as communication. So code is communication.
- 5:36
The fastest way to build an asset today is through code. And it's not just to build software, right? It's really to build anything. If I want to prototype a video, a website, slides, um, I mean, really any asset, any creative thing that I can think of, images, video, the fastest way to do that is gonna be through
- 5:58
code or code generation. And I was thinking about this presentation. I was thinking about how I was going to create all the assets for this presentation, and I realized that my favorite medium is actually TypeScript.
- 6:10
Aside from recording myself talk or writing, every ancillary asset is React or TypeScript. And I just want to take a moment because that is the most insane statement to hear myself say if I was thinking about this two or three years ago, right?
- 6:26
I don't even really know [chuckles] how to write that good of TypeScript, you know. My background's in data engineering. I come from Python land. Well, I better learn TypeScript. I better learn React because the best way for me to get these high-fidelity assets is React, TypeScript, CSS, um, and HTML, and that's wild.
- 6:44
That's wild to say. So if code is inexpensive, what is the expensive thing? Now, you might think I'm gonna say taste here. I'm not gonna say taste because everybody says taste.
- 6:53
Structure is expensive. This is maybe a bit of a contrarian set- statement here because the hard thing is maintaining a very structured code base, maintaining brand guidelines and keeping those guidelines consistent, keeping design tokens in your project, separating even front-end code from back-end code from these design tokens.
- 7:15
Merging really clean PRs, which, like, nobody does, right? Tagging PRs, PR descriptions, knowing what's a feature and what's a bug fix, knowing if you reverted a PR. How many organizations do this?
- 7:25
I've worked at a number of organizations. None, right? And maintaining accurate internal documentation so that anybody can accomplish anything. Even if you have really good agents, they're not gonna know how to solve these problems if they don't have documentation or skills, right?
- 7:40
And so structure often is the difference between AI purple gradient slob, right, and something that looks professional and polished. And I would even go a little bit further and I would say that this is conscientiousness.
- 7:55
And the dictionary of definition for conscientiousness is the quality of being meticulous, careful, and guided by a strong sense of moral or professional duty. And so it's less about comp-- like software engineering skill today.
- 8:09
It's less about the skill of being able to create these, these assets and more about the meticulousness and care given to making sure that an outcome matches your expectations.
- 8:23
And that, you know, increasingly with each model generation is not predicated on being the smartest person in the room or being the s- the person in the room with the most technical skill.
- 8:34
So what does AI reward? AI rewards conscientiousness. AI rewards organizational excellence. AI rewards structure. And ultimately, these are the things that go into good AI skills.
- 8:51
There's a lot of, like, not very good AI skills out there. Um, and most of them are just generated without any regard for what's in their contents or, or how they're structured.
- 9:01
And so all the assets that I showed you at the beginning of this video are a byproduct of design tokens, structured code, um, structured assets, and they get exponentially harder to create when we lack those things.
- 9:16
And so code, again, is communication, and we're seeing a shift left movement for content where content is moving to code. And if code, right, is the source of truth, if our code base is the source of truth, we have to have a structured source of truth in order to create content from code.
- 9:37
In order to communicate, we need structure and conscientiousness around the way that we create code. And again, this only works with organizational excellence. And so I think what we'll see in twenty twenty-six and the years beyond is that the highest performing, the best communicating teams are the ones that are able to instill discipline and rigor
- 10:01
into the process of creating software and then shift their content left towards the code through content engineering. And so twenty twenty-six, I think, was the year of the creative technologist, at least in the DevRel space.
- 10:18
This is the term that got thrown around a lot. I think twenty twenty-seven is the year of the content engineer, and I'll close on that because I think what we're gonna see next year are declarative and robust content pipelines capable of producing content walkthroughs, capable of producing documentation, screenshots, product updates.
- 10:38
All of the things that were really manual can now be created through code, through React, and ultimately because of AI. Again, I'm Matt with Conductor. Thanks for sticking around for my talk.
- 10:51
I'll catch you next time. Peace.