David Hoang — Writing — ai

Optimizing a Personal Website for AI Agents

Tue, 11 Aug 2026 00:00:00 GMT

For most of the web's life, the question behind "who is my site for?" had one answer: people, and the search crawlers that help people find it. That's changing. A growing share of visits now come from AI agents — answer engines summarizing a page, assistants fetching a bio, retrieval bots gathering context for a model. They don't scroll, they don't hover, and they don't care about a hero animation. They want structure, stable endpoints, and clear permissions.

I recently went through davidhoang.com and treated "agent experience" as a first-class design surface, the same way I'd treat mobile or accessibility. This post is a tour of what I found, what I changed, and — just as importantly — what I deliberately chose not to do.

The mental model: discovery, comprehension, action

Before touching any code, it helped to split "agent experience" into three needs:

Discovery — can an agent find what exists on the site without scraping every page?
Comprehension — once it has a page, can it extract meaning reliably instead of guessing from markup?
Action — if it wants to do something (search, subscribe), can it do so safely and predictably?

Almost every improvement below maps to one of those three. The site already had a strong classic-web foundation — a permissive robots.txt, an auto-generated sitemap, full-text RSS, semantic <article> markup, canonical URLs, and some JSON-LD. That's great for search engines and RSS readers. It's only implicitly good for agents. The goal was to make the implicit explicit.

Discovery

A generated `llms.txt`

llms.txt is an emerging convention: a plain-text, Markdown-flavored manifest at /llms.txt that tells language models what a site is about and where its important content lives. Think of it as a curated "start here" rather than a full crawl.

The key decision was to generate it from the site's own content collections and navigation data rather than hand-maintaining a file that silently rots. It lists the site identity, primary pages, published writing and notes, the RSS feeds, the sitemap, and the search index — and it excludes drafts automatically, because it's built from the same source of truth the rest of the site uses.

A caveat worth stating plainly: llms.txt is a convention, not a guaranteed ranking or ingestion mechanism. I treat it as low-cost, high-clarity signaling, not a magic funnel.

A machine-readable discovery contract

Separately from llms.txt, I published a small versioned document at /.well-known/agent.json. Where llms.txt is prose for a model to read, this is structured JSON for a program to parse. It declares:

site identity and canonical origin
the discovery resources that already exist (sitemap, RSS feeds, search index, robots)
the human-facing actions available (subscribe, read, etc.)
attribution expectations
an explicit version number

The rule I held myself to: never advertise an endpoint that doesn't exist. A discovery contract that lies is worse than none at all, so it only points at things that are actually live.

A deliberate crawler policy

The site's existing stance was already permissive — allow public content, disallow /api/. Rather than change behavior, I made the stance explicit and documented. The robots.txt now spells out how it treats search, retrieval, and training crawlers, and there's a short policy doc explaining the retrieval-vs-training distinction and how to update the bot list over time.

The honest limitation here: robots.txt cannot actually distinguish "retrieve to answer a question" from "retrieve to train a model." Pretending otherwise would be theater. So the policy documents intent and known gaps instead of implying control it doesn't have.

Comprehension

Richer structured data

I strengthened the Schema.org JSON-LD across the site: writing posts are now BlogPosting, notes are modeled as CreativeWork (they're garden notes, not articles, and it felt wrong to overclaim), and both link back to a stable Person/WebSite graph with consistent entity IDs. Publication and modification dates, language, and keywords are included where the underlying data actually supports them — and only where it does. I didn't want to invent a "last modified" date just to look fresh.

An enriched search index — without breaking anything

The site already exposed /search-index.json to power the ⌘K palette. I enriched each entry with canonical URLs, excerpts, dates, tags, and note stages, and made sure the index covers the discoverable static pages rather than silently omitting destinations that are in the sitemap.

This one had a subtle trap. The obvious move was to wrap the array in a versioned envelope ({ schemaVersion, items }). But that endpoint is already public, and an unknown consumer could be relying on the bare-array shape. So instead of a breaking change, the response stays a bare array and the schema version is advertised through an X-Search-Index-Schema-Version header. The command palette tolerates both shapes. Backward compatibility for an endpoint you don't control the consumers of is worth a little inelegance.

Clean Markdown representations

Rendered HTML is noisy for a machine: navigation, theme toggles, shader backgrounds, and view-transition wrappers all surround a few hundred words of actual prose. So every published writing post and note now has a Markdown twin at /{slug}.md, serving the original body with its front matter and a canonical link back to the HTML page. Drafts and internal-only fields never leak. HTML pages advertise the Markdown alternative via <link rel="alternate" type="text/markdown">.

The nice property here is that an agent can grab the content without parsing the chrome.

Action

Experimental WebMCP tools

WebMCP is a much newer, browser-native idea: a page can register callable "tools" through navigator.modelContext, so an in-browser agent can invoke a real function instead of simulating clicks. It's early — an evolving spec with preview-level browser support — so I treated it as strictly progressive enhancement:

feature-detected, so it's a complete no-op in browsers that don't expose the API
no mandatory dependency or polyfill
tools are registered and cleaned up across view transitions so they don't leak
read-only tools (site search, indexed navigation) are clearly separated from anything with side effects

The most important guardrail: the newsletter tool fills and focuses the form but never submits it. An agent can help a person get to the point of subscribing; it cannot subscribe them. Side effects stay behind an explicit human action.

Measuring whether any of this matters

Finally, instrumentation — because optimizing for agents without measuring outcomes is just vibes. I added privacy-conscious analytics that classify known answer-engine referrals and record whether search and newsletter interactions succeed. Crucially, it never sends query text, email addresses, page content, or personal data, and query strings are stripped from analytics payloads.

There's a limitation I wrote down rather than hid: browser analytics fundamentally can't see server-side crawler traffic. Bots don't run your client JS. So the measurement doc is explicit that crawler and citation volume has to be read from server-side logs (Vercel's firewall/analytics), not the browser layer. Measuring the wrong thing confidently is worse than admitting the gap.

What I chose not to do

A few deliberate non-goals, because scope discipline is part of the design:

No full MCP server. This is an editorial site, not an app with an API surface worth operating and securing. A lightweight machine-readable layer beats a server I'd have to babysit.
No unauthenticated content API that could burn quota. The existing static JSON and RSS cover the read cases without opening a new abuse vector.
No pretending emerging standards are settled. llms.txt and WebMCP are both promising and both early. I shipped them as clearly-scoped, low-risk enhancements, not load-bearing infrastructure.

Takeaways

If you want to make your own site friendlier to agents, a reasonable order of operations:

Publish a generated llms.txt and a /.well-known/agent.json contract — cheap, honest signaling.
Enrich the structured data you already have, without overclaiming facts you don't have.
Offer clean content representations (Markdown or documented JSON) so agents skip the chrome.
Make your crawler policy explicit, including its limitations.
Only then experiment with interactive standards like WebMCP — feature-detected and side-effect-safe.
Measure outcomes, and be honest about what your measurement can and can't see.

The throughline across all of it: be explicit, be honest about limits, and never let an agent take an action a human didn't ask for. Good agent experience turns out to look a lot like good API design and good accessibility — clarity, structure, and respect for the consumer on the other end.

The formlessness of AI agents

Sun, 12 Apr 2026 00:00:00 GMT

In The Avengers #54, a mysterious villain called the Crimson Cowl is orchestrating attacks against the team. It's not until the last page that the cowl drops and we see what's underneath: a robot. The next issue reveals him fully—Ultron-5, a living automation built by Hank Pym using his own brain patterns.

By the time anyone sees Ultron, he's already on version five. He was created, gained sentience, rebelled against his creator, hypnotized Pym into forgetting he ever existed, and then quietly iterated through four bodies in secret as a self-upgrade. Each time Ultron is defeated, he rebuilds to a better enclosure for the same intelligence. Like a hermit crab moving through shells, Ultron wasn't becoming something new but finding the optimal fit.

Our AI tools are having their Ultron moment. In a few years of the scaling era of AI, capabilities have evolved rapidly and are compounding. They are breaking out of the chat boxes with tiny context windows and are now taking actions, running in the background, and using similar tools as us. It's not AGI, but it turns out serendipitous cron jobs invoke a sentient connection to many human beings.

The question in the Ultron moment is, "what is the right body for this intelligence?"

New capabilities begin in borrowed form

Steve Jobs made this observation at the 1983 International Design Conference in Aspen. Early television shows were like radio shows with a camera pointed at them. Because the capability is new, people used existing patterns of what they already knew—a host behind a desk, reading to an audience, and filmed it. The breakthrough was you could visually tell a story of War of the Worlds instead of reading it to them.

Early websites were digital brochures and mobile apps were shrunken desktop software. Early iPhone prototypes ran a cut‑down version of OS X's core, adapted to fit a phone. AI agents talking through chat interfaces are like radio shows with a camera pointed at them. Chat is frictionless not because it's the right interface but because it's a familiar one; a turn-by-turn conversational text box.

In Silicon Valley, we're obsessed with pushing the edges of technology and need to be reminded of global behaviors. I recently ran rapid research comparing site-building tools for SMBs (yes I do this for fun). Compared to classic site builders such as Framer, Webflow, and Squarespace, people preferred using Lovable or Replit to build a website because of the conversational interface.

Giving agents a body

OpenClaw is an open‑source framework for controlling your computer through natural‑language agents. Its primary interaction is a chat agent: you text it on messaging platforms such as Telegram or WhatsApp. It runs tasks on your computer, manages your calendar, clears your inbox. That wasn't enough for some people.

Tom saw a fundamental problem: how do you get OpenClaw to control actual motors in real time? His answer was ClawBody, a software bridge that connects OpenClaw to physical hardware so you can train agents in simulation, then deploy them to real robots. Chris asked a different question: what if robots could actually understand spatial depth? He integrated Intel RealSense cameras with OpenClaw and a vision‑language model so robots can track a person through space, maintain distance, and navigate obstacles, all driven by natural language.

Then there's ClawStage, a device built by HooRii Technology that turns OpenClaw into a companion robot — a Raspberry Pi 5 with a transparent display that creates a hologram-like effect for an animated AI persona, with a camera and microphone array that let it perceive its surroundings and respond to voice directionally. Hackster users can design custom personalities for it, download characters from a shared hub, and make the intelligence feel like someone.

A project called Dimensional integrated OpenClaw with the Unitree G1 humanoid robot and gave it Spatial Agent Memory. The agent understands physical space and temporality, knows the layout of rooms, the location of objects, where people tend to be.

Many of these projects started as DIY projects because they wanted to create an enclosure for their sentient tools; like a hermit crab between shells.

We know how to relate to things that have form. A hammer looks like something you swing and a doorknob affords turning. When something is formless, such as an intelligence in machine-form that sees the world in lines of code, we don't have the same intuitive relationship with it. Human and agentic behaviors are not the same. It's a miss for us to replicate ourselves in the form of a new intelligence.

This is why we must explore the right enclosures and interfaces for agents. We'll soon realize all these CLI tools are not primarily for the humans—they're for people giving the formless thing a shape so they can understand what it does.

The shell keeps changing.

The trust tension

Humans need visibility of agents to trust them; to understand what they are doing and where the boundaries are. Formlessness creates anxiety for humans. If one can't see the agent, how is it held accountable?

The current challenge is the interfaces are designed in the borrowed form of chat, sidebar, and copilots. We're in the uncanny valley of agent design. The form is close enough to be usable but wrong enough to be limiting. A chat-based agent can answer your question but can't show you it's already working on three other things in parallel. A copilot can suggest edits but can't demonstrate that it understands the broader context of your project.

The interface doesn't match the capability. As a result, humans and agents are working on the same interfaces and it's not visibly clear who is doing what.

This is the enclosure problem. Not just how agents look, but what kind of container can hold something that is, by nature, without container. That's a harder design question than it sounds. Many of us haven't designed for things that can think, plan, reason, and use the same tools we do.

And if you want to go somewhere uncomfortable: we haven't solved this problem for ourselves either. The relationship between consciousness and body, between the mind and the form it inhabits, is the oldest unsolved question in philosophy. We're spiritual beings who never fully made sense of our own enclosures. Now we're being asked to design one for something else.

The form is still being found

We're doing what humans always do when faced with something formless: we reach for the containers we already have. We put radio on television. We put the legal pad in the Notes app. We put intelligence in a chat box.

We're the ones designing the body for the new medium. That reframes every choice. A chat interface is a claim about what kind of enclosure intelligence should have. A sidebar copilot is a claim. A robotic arm is a claim. Each enclosure shapes what the intelligence can do, how people relate to it, and what it becomes. The form isn't neutral.

It's tempting to settle with the borrowed form, but that's not what we do as designers. Understanding what form formless experiences need is what we should explore. The fact that we haven't found the native form of agents yet means the field is genuinely open. This is the equivalent of being a filmmaker in 1910, a web designer in 1995, a mobile designer in 2008. The early chaotic moments that feel disorienting are what we live for as makers.

We are at the beginning of thinking about different enclosures for agents. The shell keeps changing—and that's the work.

Originally posted on Proof of Concept

A new MVC is emerging

Sun, 15 Jun 2025 00:00:00 GMT

For makers of software, Model/View/Controller (MVC) is one of the first concepts you learn. MVC is a design pattern that separates an application into three parts to organize code and make it easier to maintain. The Model handles data and business logic, the View manages the user interface, and the Controller acts as a middleman that processes user input and coordinates between them.

Think of it like a restaurant: the kitchen (Model) prepares the food, the dining room (View) is where customers eat, and the waiter (Controller) takes orders and communicates between the two. This separation allows developers to modify one part without breaking the others.

MVC has guided software architecture for decades—but AI is about to turn it on its head.

Instead of rigid relationships between data, interface, and logic, we're entering a world where intelligent agents dynamically orchestrate distributed systems. Rather than building monolithic apps with centralized databases, we now design decoupled systems where agents respond in real-time using protocols like MCP (Model Context Protocol).

So what happens when Model, View, and Controller all become intelligent?

Before I share my thoughts, I must acknowledge and share Ruben Verborgh's “Paradigm shifts for the decentralized Web.” Verborgh, a professor of Decentralized Web Technology, wrote this back in 2017 and laid out three critical shifts:

End users become data controllers: Users store their data where they want, improving privacy and control.
Apps become views: Apps are no longer single gateways, but interchangeable UI layers over personal data stores.
Interfaces become queries: Distributed data demands declarative, query-driven interfaces, not custom APIs.

Now, with AI in the loop, these shifts feel even more pressing—and they're converging with a reimagining of MVC. Let's explore what the new MVC looks like.

The emerging MVC

The emerging MVC forces software makers to think of system-centric product experiences instead of app-centric. Simply put, the containers are breaking and walled gardens are coming down. Let's look at the new constructs of MVC.

LLMs as Models

During a conversation with Kyle Turman at Anthropic, they said something that stuck with me: "LLMs are grown, not built." That framing changed everything. Unlike traditional models you code and optimize, LLMs are trained, shaped, and continuously refined by their inputs and interactions. They behave less like deterministic engines and more like probabilistic ecosystems. This organic quality changes how we interface with them—and what we expect from "the model."

Apps as Views

In this new world, the app is no longer the destination—it's the interface. Core workflows may still rely on apps, but increasingly, they're just views for interacting with data and agents.

One of the first apps I ever built was Carogram, an Instagram client for the web and iPad using Node.js. Even back then, the trend was clear: apps were wrappers over data that lived elsewhere. Deep linking was a start. Now, we're looking at a future where apps might not store any data at all—just render it, query it, or pass it through.

That was the promise of the decentralized web and blockchain: portability, ownership, and independence from centralized services. It didn't fully land back then. But with AI and protocols like MCP, it may finally find footing.

Agents as Controllers

This is where it gets interesting. If LLMs are the new Models and apps are our Views, AI agents step into the Controller role—except they don't just relay input anymore. They interpret, decide, act, and coordinate across distributed systems. With Model Context Protocol (MCP), agents dynamically handle context switching, planning, and executing across multiple apps and data sources.

They're not just smarter waiters. They're like sous-chefs, sommeliers, and maître d's rolled into one—making judgment calls in real time.

Recap

I won't force a new acronym like LAA (LLMs, Apps, Agents)—but the point is clear: MVC isn't gone, it's evolving.

In this emerging architecture:

Instead of maintaining a codebase, we're managing endpoints, protocols, and interactions
Vendor lock-in becomes a liability, not a moat
Apps need to be interoperable by design, not by exception
AI interfaces act as meta-layers, sitting above and across traditional apps

Software isn't collapsing—it's decoupling. We are moving from app-centric experiences to system-centric ones. And with that comes a chance to rethink how we make, control, and interact with the systems around us.

Originally posted on Proof of Concept

Career reboot

Mon, 21 Apr 2025 00:00:00 GMT

Every April I seem to take an unplanned creative spring break. It’s not a sabbatical or a formal PTO strategy—just a self-imposed ritual to step away from the chaos of work and reconnect with what inspires me. I’ve learned that if you’re not in a full-time IC role, making things—especially design—becomes a form of recovery from meeting fatigue and managerial overhead.

This year’s reboot took me to San Diego and Palm Springs, where I spent the week writing, vibe coding, updating my personal site, and binging content—not passively, but actively, taking notes like a student of inspiration. It’s a reminder that creative recovery isn’t idle time; it’s compost for what comes next.

One of the shows I caught up on was Daredevil: Born Again—a reboot of one of my all-time favorite comic book characters. After finishing it, I fell into one of my favorite internet rituals: watching YouTube breakdowns from New Rockstars, Screen Crush, Heavy Spoilers. The algorithm did its thing, and suddenly I was watching clips from the original Daredevil series that aired on Netflix in 2015. Ten years ago. I was living in Capitol Hill, Seattle, designing mobile apps at Black Pixel, deep in my craft.

Pandora’s Box was open. From there, it spiraled into Secret Wars theory videos and MCU reboot rumors. It’s no secret that Marvel is plotting a reset. Though my heart still belongs to the 1984 Secret Wars, the upcoming cinematic version borrows heavily from Jonathan Hickman’s 2015 arc—the one where the multiverse collapses, Doctor Doom ascends, and the patchwork world of Battleworld emerges from the ruins.

As the Marvel multiverse collapses from a series of catastrophic incursions, Doctor Doom seizes godlike power and creates a new patchwork world called Battleworld, where fragments of destroyed realities are stitched together under his rule. Avengers: Secret Wars is set to release in 2027, which is fifteen years after the original Avengers film.

The AI incursion

I was sitting on our couch in Palm Springs, flipping through YouTube clips between the two Coachella weekends—an event I once flew across the country to attend (yes, I was there for Hologram 2Pac). Now, the bands that once headlined my youth are soundtracking ads for minivans and insurance, targeting geriatric millennials like me. I’m 41. Bryan Johnson might argue I’m not getting old, just aging. But let’s be honest—I’m definitely losing my edge. (For the record, the GRS Club cover of that LCD Soundsystem track is still my favorite.)

The hardest part of aging isn’t the number—it’s the creeping sense of irrelevance. That quiet panic when you realize you’re no longer fluent in the tools or jokes shaping the next era. For many of us, the AI incursion feels like that moment. Unlike past hype cycles—remember NFTs?—this one feels different. Real. Fast. Disruptive. Existential.

We’re not just navigating a new wave of tech; we’re dealing with two systemic shocks at once. The AI acceleration is colliding with what feels like the second Great Recession. Around 2023, tech hit a hard reset—blitzscaling gave way to layoffs, cautious capital, and a culture shift. And from that rubble, a new archetype emerged: the vibe coders. A term Andrej Karpathy used to describe the new generation building apps with generative AI—no traditional coding required, just vibes, vision, and a good prompt.

Using generative AI, I had ChatGPT write a satire of Losing My Edge about vibe coders and a millennial trying to keep up with the Gen Z kids:

I’m losing my edge…to the kids with ring lights and one-shot prompts, the ones who ship from Discord DMs and sleep in Notion.

I remember when we wrote our own auth, when you had to beg Heroku for more dynos.

I remember debugging IE6 in Starbucks on airport Wi-Fi.

I remember when product specs were PDFs, when A/B tests took weeks and no one said “vibes.”

I’m losing my edge…to the locked-in Gen Zs with Arc tabs like trading desks, shipping AI agents at 3AM while I’m still writing the brief.

Tech incursions equalize

Millennials, we’re losing our edge. The experience we once relied on—the war stories of scaling, shipping, and staying late to debug—no longer guarantees relevance. The Ruby on Rails apps we built with Twitter Bootstrap and deployed on Heroku? They can now be replicated in a single-shot prompt with generative AI. Even Reid Hoffman, the founder of LinkedIn, used Replit to spin up a clone of the platform he originally built. Just because you can mimic something doesn’t mean you’ve matched its scale or impact—but using that as a reason to dismiss what’s happening is a mistake.

As General Eric Shinseki once said: “If you don’t like change, you’re going to like irrelevance even less.”

The upside of these tech incursions is that they act as great equalizers. They flatten the hierarchy. They don’t care how senior you are or how many portfolio pieces you’ve amassed—they care how quickly you can adapt. Whether you’re just starting out or decades into your career, everyone is trying to figure out how to design with AI while designing for AI.

I’ve seen this pattern before. In my 20s, during the mobile incursion, no one had experience designing for a piece of glass you touched with your fingers. I managed to break into tech because I had mastered Photoshop and could craft rich, skeuomorphic interfaces. In a landscape with no established veterans, everyone was new—and that opened doors.

It’s tempting to push back by saying, “But I have decades of experience.” And sure, experience matters. But relevant experience matters more. I remember a graphic design professor from college—someone who had written books, spoken at conferences, and built a career in print. He refused to teach web design, dismissing it as a fad. That mindset didn’t age well.

There are still strengths that tech incursions can’t displace—understanding customers, navigating complexity, leading teams across disciplines. But we can’t ignore how the craft itself is changing. And if you’re a design leader, your job isn’t just to set direction—it’s to stay close enough to the work to guide your team through the shifts. Because when the ground moves, they’ll need you to be steady and skilled.

Career reboot

As my spring break wraps up, I’m not walking away feeling old—I’m walking away with a sense of clarity: it’s time for a career reboot. Two years ago, I called the tech factory reset. Now, I’m giving myself permission to do the same. A reboot doesn’t mean discarding everything. The valuable experiences, the hard-earned instincts—they reinstall quickly. What I am letting go of are the dependencies and assumptions that no longer serve me. The ones that keep you comfortable but slowly make you obsolete.

I don’t need to be recast as the lead in someone else’s Marvel reboot. I want to play a different role: the bridge between generations, helping to pass the torch—not by clinging to the past, but by staying grounded in it while reaching toward what’s next.

To do that, I’m making a few commitments:

Stay healthy and well. Don’t let burnout rob you of clarity or connection. Take care of your mind, body, and the people who matter.
Keep the craft blade sharp. Return to your roots. Lead through craft. Understand the material of this new era—especially AI. As Nikunj Kothari put it: stop bookmarking, start building.
Invest in the next generation. Mentor. Share your playbook. Let their perspective reshape yours, too.

I was an IC running my own studio when The Avengers hit theaters. Now, fifteen years later, I’m an operator and investor as Secret Wars looms. My 20s were shaped by the Mobile Incursion in Seattle. My 30s, the Blitzscaling Era in San Francisco. And now, in my 40s, I’m back in SF, navigating the AI Incursion.

This isn’t the end of an era. It’s the beginning of another. I don’t feel irrelevant—I feel rebooted. And I’m working on the most relevant things of my career.

Let’s get back to work.

Waiting for AI's pull-to-refresh moment

Sun, 03 Sep 2023 00:00:00 GMT

There is a gesture on the iPhone that long-time mobile users are familiar with that has non-native origins. If you open the official Mail app on the inbox view, you can "pull" the interface down and the app will refresh with more emails. This is known as "pull-to-refresh."

What not everyone may know is this interaction was made popular and invented by Loren Brichter, an independent developer who created Tweetie, a Twitter client that would later be acquired by Twitter in 2010. The pull-to-refresh gesture wasn't just a novel interaction—it was a paradigm shift that would become ubiquitous across mobile applications.

The story of pull-to-refresh

In 2008, Loren Brichter was working on Tweetie, what many described as "the Twitter app Apple itself would have made." The challenge was simple: how do you refresh a timeline of tweets in an elegant, intuitive way?

Traditional approaches involved tapping a refresh button, usually located at the top of the screen. But Brichter had a different vision. He noticed that when users scrolled to the top of a list, there was a natural elasticity—the interface would "bounce" back into place. What if that bounce could trigger an action?

The solution was ingenious in its simplicity. Instead of requiring users to scroll to the top, lift their finger, and tap a refresh button, why not make refreshing part of the scroll gesture itself? Users could simply pull down on the timeline, and upon release, new tweets would load automatically.

The anatomy of interface innovation

Pull-to-refresh succeeded because it solved multiple problems simultaneously:

Discoverability: The gesture felt natural and was easily discoverable through normal scrolling behavior.

Efficiency: It eliminated the need for precise button tapping, especially valuable on small touch screens.

Delight: The elastic animation and satisfying "snap" made the interaction enjoyable.

Intuitiveness: It leveraged existing mental models of physical interactions—pulling to retrieve something new.

But perhaps most importantly, it turned a mechanical action into something that felt magical. This wasn't just a functional improvement; it was a fundamental reimagining of how users could interact with dynamic content.

The ubiquity that followed

Today, pull-to-refresh is everywhere. From social media apps to email clients, from news readers to messaging platforms, the gesture has become as fundamental to mobile interaction as the tap or swipe. It's been adopted across iOS, Android, and web applications. What started as one developer's elegant solution to a specific problem became a universal design pattern.

The gesture even earned its own patent (filed by Twitter after they acquired Tweetie), though Brichter himself has suggested that developers shouldn't worry about its enforcement. The fact that such a simple interaction warranted patent protection speaks to its innovation and impact.

AI's interface challenge

So why does this matter for AI? Because we're currently in the midst of another interface revolution, and AI still hasn't found its "pull-to-refresh moment."

Think about how we interact with AI today. Despite the sophisticated capabilities of large language models, we're still largely confined to the text box—typing prompts, waiting for responses, and engaging in turn-based conversation. It's functional, but it's not revolutionary.

The current AI interface paradigm mirrors the early days of mobile apps: lots of buttons, explicit actions, and rigid interaction patterns. Just as mobile apps initially mimicked desktop interfaces before finding their own voice, AI applications are still searching for their native interaction model.

The race to the interface

We're seeing glimpses of what AI's interface evolution might look like:

Voice interfaces that make AI feel more conversational and immediate.
Multimodal interactions that combine text, voice, and visual inputs seamlessly.
Contextual triggers that activate AI based on what you're doing or where you are.
Proactive assistance that anticipates needs rather than waiting for explicit requests.
Gesture-based controls that make AI feel more natural and less mechanical.

But we haven't yet seen the breakthrough that will make AI interactions feel as intuitive and delightful as pull-to-refresh made content refreshing.

What AI's pull-to-refresh moment might look like

The breakthrough won't necessarily be a gesture—it will be a fundamental reimagining of how we interact with intelligent systems. It might be:

A way to naturally "pull" context from your environment without explicitly describing it.
An interaction that makes AI feel less like a chat session and more like thought partnership.
A gesture or pattern that makes AI assistance feel as natural as scrolling through a timeline.
A method that eliminates the cognitive overhead of crafting the perfect prompt.

Just as pull-to-refresh made refreshing content feel effortless, AI's interface breakthrough will make accessing intelligence feel seamless.

The stakes are high

The stakes for getting AI interfaces right are enormous. The company or developer who figures out AI's equivalent of pull-to-refresh won't just create a better user experience—they'll potentially define how humanity interacts with artificial intelligence for years to come.

This isn't just about convenience; it's about accessibility, adoption, and the fundamental relationship between humans and AI. The right interface paradigm could make AI assistance as natural and widespread as pull-to-refresh became for mobile apps.

Waiting for the moment

Loren Brichter's pull-to-refresh gesture succeeded because it solved a real problem in an elegant, intuitive way. It wasn't just a technical innovation—it was a design philosophy that prioritized user experience over technical complexity.

AI's pull-to-refresh moment will likely follow a similar pattern. It won't be the most technically sophisticated approach, but it will be the most human one. It will solve the interface problem we didn't even know we had, making AI interactions feel as natural as pulling down to refresh a timeline.

The question isn't whether this moment will come—it's who will create it, and when. And like pull-to-refresh, when it arrives, it will seem so obvious that we'll wonder how we ever lived without it.

Until then, we wait, experiment, and iterate. Because somewhere, perhaps in a small development studio or a large tech company, someone is working on the gesture, interaction, or paradigm that will define the next era of human-computer interaction.

The race to the interface is on. AI's pull-to-refresh moment is coming.

Originally posted on Proof of Concept

David Hoang — Writing — ai

Optimizing a Personal Website for AI Agents

The mental model: discovery, comprehension, action

Discovery

A generated llms.txt

A machine-readable discovery contract

A deliberate crawler policy

Comprehension

Richer structured data

An enriched search index — without breaking anything

Clean Markdown representations

Action

Experimental WebMCP tools

Measuring whether any of this matters

What I chose not to do

Takeaways

The formlessness of AI agents

New capabilities begin in borrowed form

Giving agents a body

The trust tension

The form is still being found

A new MVC is emerging

The emerging MVC

LLMs as Models

Apps as Views

Agents as Controllers

Recap

Career reboot

The AI incursion

Tech incursions equalize

Career reboot

Waiting for AI's pull-to-refresh moment

The story of pull-to-refresh

The anatomy of interface innovation

The ubiquity that followed

AI's interface challenge

The race to the interface

What AI's pull-to-refresh moment might look like

The stakes are high

Waiting for the moment

A generated `llms.txt`