An agent can build a screen in minutes. Getting it to build a screen that feels like your product, uses the right components, and gives a person enough context to make a decision is much harder.
That's why I wanted to look closely at PostHog. The company has a clear idea of where software is going, and it has made some of the design and engineering rules behind that idea public. Looking across its product, component libraries, and agent instructions, you can see the work required to turn an AI vision into a product that still has a point of view.
In this teardown, I'll connect PostHog's 2030-shaped software vision to the design systems it uses today, then look at the repository guidance that helps its agents build UI without drifting away from the product.
Table of contents
- How does PostHog's design system support agents?
- What changes when agents do more of the work?
- Why PostHog's brand matters to generated UI
- What LemonUI and quill reveal
- PostHog's rules for agent-first product engineering
- The agent rules behind the interface
- What the UI component skill adds
- What product teams can take from this
How does PostHog's design system support agents?
PostHog's agent-first design system combines reusable UI components with written rules that tell coding agents where those components live, when to use them, and how they should behave. LemonUI serves the main web app, while quill supports newer surfaces such as MCP apps and PostHog Desktop. Repository instructions connect each agent to the right system.
That last part matters. A component library can be beautifully organized for a designer and still leave an agent guessing about which button, table, or interaction belongs in a specific part of the product. PostHog's public frontend agent guide makes those decisions more explicit. The instruction to search for an existing component before creating one is small, but it changes what the agent is likely to ship.
As I went through the product and its public documentation, I kept seeing the same question from two directions. What should a person be able to understand when an agent has done the work? And what should the agent understand about the product before it builds anything? PostHog's answer is still evolving, but the connection between those two questions is what makes this a useful design system teardown.
What changes when agents do more of the work?
PostHog's 2030-shaped software essay proposes that agents will handle more of the doing while people spend more time judging, deciding, and checking what changed. That is a product design problem as much as an engineering one. If an agent can create an experiment, investigate a drop in traffic, or propose a product change, the person opening the product needs a clear way to understand its work and decide what happens next.
Chat is the front door; generated UI is inside
I keep coming back to PostHog's distinction between chat and generated UI. A conversation is a useful way to ask for work, but a chart, comparison, or preview can make the result easier to assess. The interface has to help someone answer concrete questions: What did the agent use? What changed? Is the result safe to approve? Where should I look more closely?
One example I looked at is a question about falling traffic. Instead of making someone navigate through dashboards before they know where to look, the agent can bring the relevant product data into the response and present it visually. The underlying context matters just as much as the chart: repository knowledge, documentation, past decisions, and customer information give the agent a way to interpret a result for this particular product.
PostHog is testing that direction in PostHog Desktop, using its existing product data and infrastructure on a newer surface. Its public vision also describes persistent places for human review, such as approvals and verification. I find that more useful than imagining every future interaction as a chat transcript. Product teams still have to design the moment when a person takes responsibility for the outcome.
The product can start with a request
There is a more fundamental shift underneath that UI. Today, many teams still start in a product screen, click through a workflow, and call on an agent somewhere along the way. PostHog is exploring the reverse: start with the request, let the agent use product capabilities and data, and show a screen when the result needs visual inspection. In that model, the product's knowledge and actions matter even when the customer is talking to it through another surface.
I don't read this as a claim that every dashboard should disappear. If someone asks why traffic changed, a visual result can be far more useful than a paragraph in chat. The design challenge is deciding which part of the answer should be conversational, which part should be generated as UI, and where the person should be asked to judge or approve what happens next.
That is also why context matters so much. PostHog's data can tell an agent what changed, but a useful answer may depend on the team's repository, documentation, previous decisions, and customer conversations. We have been building a similar product brain with our own customers. When those materials are scattered, the agent can produce a technically plausible answer that misses the reason a team made the last decision.
Why PostHog's brand matters to generated UI
Before I looked at the component libraries, I spent time with PostHog's brand guidance. Its product has a recognizable personality: playful illustrations, distinctive assets, an opinionated voice, and a visual language that feels made for builders. That matters to this story because generated interfaces can easily lose the details that make a product feel like itself.
The brand guide goes beyond a palette. It describes how PostHog wants to sound and what kind of taste the team values. I like that they make those choices inspectable. If an agent is going to write copy, assemble a page, or choose components, it needs access to more than a hex value. It needs to know what kind of interaction would feel too generic, too polished in the wrong way, or simply off-brand.
I see this often when teams add an AI builder to an established product. The first generated screen can look clean, and everyone is excited that it appeared so quickly. Then someone notices that the density is wrong, the illustration style belongs to another company, or the interface uses a reassuring tone where the product normally asks people to inspect the evidence. PostHog's investment in brand makes the gap between a plausible screen and a PostHog screen easier to see.
What LemonUI and quill reveal
LemonUI supports the current app
The contrast between PostHog's two UI systems was the most revealing part of my review. LemonUI supports the established main app, which has accumulated a huge range of products and flows. Its Storybook reflects that breadth. As someone who spends a lot of time in component libraries, I found the amount of material a little overwhelming. That's an observation from browsing the library, rather than a claim about how PostHog's team uses it internally.
The PostHog AI examples were more concrete. I liked the starter prompts that help someone begin asking a question, the thread states, and the way the interface shows what data it read. Those details make the interaction easier to enter and easier to inspect. I still wanted clearer foundations alongside the examples: guidance on voice and tone, when each AI pattern should be used, and what a person should understand before acting on an answer. I could see the states, but I had to infer some of the product judgment behind them.
That distinction matters when the library is used by an agent. A Storybook page can show the welcome screen and every visible state, while leaving the reason for each state in someone's head. A person familiar with the product may fill in the gap. An agent is more likely to pick the nearest example and continue. My reaction to LemonUI was not that PostHog lacks components; it was that I wanted a clearer route through a very large system and more explanation of when its AI patterns should be used.
Quill supports new agent surfaces
Quill, the newer system used for MCP apps and Desktop, felt easier to scan. Its primitives and components had a clearer hierarchy, including the pieces you would expect for chat and generated interfaces. PostHog's quill package guide describes a layered structure of tokens, primitives, components, and blocks. The structure gives both people and agents a more legible path from a basic control to a product-level pattern.
In its Storybook, I could move from a button or badge to a chat bubble, card, or larger composition without wondering where a pattern belonged. I also noticed how much easier it was to see the intended states. That doesn't automatically make Quill the better system for every job; it is designed for different surfaces. But as an artifact someone or something needs to navigate, its organization felt closer to what I would want when building an agent-facing library.
One detail is especially important: PostHog's root repository rules say quill is for MCP apps and Desktop, while the main app continues to use LemonUI. A coding agent needs to know that boundary. Without it, two well-built libraries can still lead to a screen that feels out of place.
PostHog's rules for agent-first product engineering
PostHog's agent-first product engineering principles helped me understand why its UI systems and repository instructions are being shaped this way. One principle is to let agents do the work that users can do, rather than exposing only a thin set of read-only answers. Another is to meet agents at the level of detail they need for the task. Both have design consequences.
If an agent can create a feature flag or explore product data, the human interface needs a way to make those actions understandable and reviewable. An answer with no source or visible change leaves the person guessing. A result that shows the data it read, the action it proposes, and the point where approval is needed gives the person a real decision to make.
The level of detail matters on the building side too. PostHog argues against handing an agent an enormous, rigid script for every step. The guidance should give it the product's vocabulary, constraints, edge cases, and standards of taste while leaving enough room to solve the actual problem. I think that balance is harder than it sounds. Too little context gives you generic UI; too many mechanical instructions can make the agent follow a recipe even when the workflow calls for a different shape.
This is where design and engineering need to work together. An agent's tool access is an engineering decision, but what it can show, what it can change, and what a person must review are product decisions. The generated screen is the visible end of a much larger system of capabilities and judgment.
The agent rules behind the interface
The most practical example sits in PostHog's frontend/src/AGENTS.md. Before creating a new UI element, the agent is told to search LemonUI and other shared components. The guide names common reinventions, such as a table or status badge, and points to the existing PostHog components. It also tells the agent to study two or three comparable screens before building a new one, use generated API types, and raise a missing component rather than quietly inventing a fork. Read the frontend guide.
That is much more useful than a generic instruction to "follow the design system." If the task needs a table, the guide points to the existing table. If it needs a colored status indicator, it points to the badge. If the component does not fit, the agent is supposed to say so and propose an extension. The rule prevents a small mismatch from quietly turning into another one-off component that nobody maintains.
I also like the instruction to look at two or three comparable views before making a new one. Components alone do not tell you how dense a PostHog page should be, how a toolbar is composed, or where an action belongs. Existing screens carry those decisions. Asking an agent to inspect them is a practical way to give it examples of the product's working grammar.
The guide routes the agent between LemonUI and Quill, tells it to use generated API types, and keeps business logic in the right layer. Some of that is engineering detail, but the effect is visible in the UI. A screen built with the wrong library, a made-up data shape, or a shortcut around the product's interaction patterns can be superficially convincing while being expensive for the team to adopt.
The companion writing UI components skill goes further into file structure, reuse, naming, states, and visual discipline. A loading state, an empty state, and an error state each need their own treatment. That is the kind of detail an agent can easily flatten into one generic screen unless the team writes down the rule.
I like that this is product-specific guidance. A generic frontend prompt can make something polished, but it cannot know why PostHog uses a particular table, which UI system belongs on which surface, or what the product considers an unacceptable shortcut. Their approach is also consistent with PostHog's agent-first product engineering principles, which argue for giving agents useful capabilities and context at the level they need. The agent needs enough room to solve the task, with clear boundaries around the product's language, components, and edge cases.
What the UI component skill adds
The UI component skill answers a slightly different question from the frontend guide. The guide helps an agent choose where to work and what to reuse. The skill helps it make or change a component in a way the team can live with: where the file belongs, when repeated markup deserves extraction, what a rename needs to update, and what to render before data arrives.
That last point is easy to overlook. Loading, empty, and error are separate experiences. A page that has not received data yet should not quietly look like a page with no results. If an agent collapses those states, the screen may appear finished in a screenshot while communicating the wrong thing to a real user. This is a design decision written in a form an implementation agent can apply.
The skill also names anti-patterns, including the generic custom component that fills a design-system gap with whatever looks familiar from a Tailwind tutorial. I smiled at that one because it describes a failure mode I see constantly: the code works, the UI looks competent, and it still does not belong to the product. Naming that mistake gives an agent a chance to catch it before another off-brand component becomes the default.
I would not treat a skill file as a substitute for reviewing the output. It is a way to make accumulated team judgment available at the moment the agent needs it. The most useful rule may be the one you add after a review exposes the same mistake for the second time.
What product teams can take from this
I wouldn't copy PostHog's setup wholesale. The useful exercise is to inspect where your own agent has to guess. We have seen this with B2B SaaS teams: the components exist, but the agent still makes a new button or an off-brand layout because nobody told it where to look or what to do when the system has a gap. I wrote about that pattern in our agentic design system guide.
If I were starting with an existing product, I would work through these steps with design and engineering together:
- Pick one real agent task. Choose a screen or workflow your team actually builds, such as an analytics view or an approval flow.
- Trace every place the agent has to guess. Look for missing component names, unclear usage rules, absent loading or error states, and product decisions that only one teammate knows.
- Write the routing rules into the repository. Tell the agent which library applies to this part of the product, where to find similar screens, and what to do when no component fits.
- Review the result as a user would. Check whether the interface shows what the agent did, where its information came from, and what decision a person needs to make.
- Feed the misses back into the system. If the agent keeps inventing the same pattern, improve the component guidance or add the missing pattern where the team can find it.
For example, imagine asking an agent to add an approval state to an analytics card. I would first point it to a real card in the product, the existing badge and button components, and a nearby screen that handles review. Then I would ask it to show what happens while data loads, when no result is found, and when the action fails. Finally, I would review whether a person can see the source of the recommendation and understand what approval changes. That is a much better test of the system than asking whether the screenshot looks on-brand.
PostHog's two libraries also suggest a useful question for teams with an established product. Which parts of the current UI should an agent continue to build with, and where are you deliberately testing a new interaction model? Those boundaries can change over time, but leaving them implicit makes it too easy for generated work to mix the old and new systems without anyone deciding to do so.
That process gives a design system a job beyond keeping screens visually consistent. It helps preserve product judgment as more UI and more product work are generated. For another example of how we structure that context, see our guide to agent skills for design systems and our piece on design.md for AI agents.
We work through this with B2B SaaS product teams from both the design and engineering sides, because the missing rule is often somewhere between the two. If your team is trying to make its component system usable by agents, tell us what your agents keep getting wrong. That is usually the most useful place to begin.
PostHog's work is still evolving, and I think that's part of what makes it interesting. The company is testing a different relationship between agents, people, and interfaces while making many of its design decisions inspectable. For product teams building with AI now, the immediate question is practical: if an agent started building in your product tomorrow, would it know which system to follow and what a person needs to see before approving its work?
