Developer First = Agent First — Hahnbee Lee  🔗 **Source:** [Developer First = Agent First — Hahnbee Lee](https://www.youtube.com/watch?v=6G3EPodarGc) > [!note]+ Document Notes > tags: [developer-experience, agent-experience, documentation, devrel, llms-txt, mcp] > author: Hahnbee Lee > source: Dev Rel (YouTube) > reference: https://www.youtube.com/watch?v=6G3EPodarGc > date created: 2026-10-15 17:50 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Developer First = Agent First — Hahnbee Lee > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--developer-first--agent-first--hahnbee-lee) ## 📝 Summary - **What happened.** The Dev Rel channel published a 24:17 talk, uploaded 2026-10-14, from DevRelCon 2026 in NYC. Hahnbee Lee, co-founder and CTO of Mintlify, argues that developer experience and agent experience are converging. The auto-captions spell the speaker "Hanbi" and the company "Millify" in places; the video description gives "Hahnbee Lee" and "Mintlify." The talk runs about 13 minutes, then a Q&A of about 10 minutes. - **The claim.** Developer-first design is agent-first design. Companies that won on DevEx in the 2010s (the talk names Stripe and HashiCorp) set the pattern. Now coding agents read docs and call APIs, MCP servers, skills and CLIs on behalf of people, so the same clarity serves both audiences. - **The evidence offered.** A live Mintlify metric (the talk cites a page on the Mintlify site, which the captions garble as "multifeed.com/data") shows agent traffic to docs passing 66% of visits. A Mintlify benchmark of doc formats found accuracy "pretty good across the board," with agents preferring llms.txt and markdown versions. - **Why it matters.** If most doc readers are agents, doc freshness, markdown availability, code examples and agent-only context outrank visual design. DevRel and docs teams are the people who teach this to a broader audience. - **Key stakeholders.** Mintlify (vendor of the docs platform, and the source of every statistic), docs and DevRel teams, API owners, enterprise legal and security teams that gate docs, and coding-agent vendors (Claude Code is named as the top agent by traffic at 00:19:41). - **Risks and tradeoffs.** All numbers come from one vendor's own platform and carry no method. The 66% figure is based on user-agent detection (00:19:41), and the speaker could not say how many humans sit behind the agent traffic (00:18:56 to 00:19:41). The speaker sells the platform the talk recommends. - **Bottom line.** The practical advice is sound and low-cost: ship markdown and llms.txt, add code examples and use cases, keep docs current, and expose APIs, MCP and CLIs. The statistics are claims from an interested party, and the "developer first equals agent first" slogan fits the evidence only partly, because the speaker also says design matters less for agents and recommends agent-only context. ## 📖 Main content **The core argument.** The talk makes a historical case in three steps. Before 2022, developers decided whether a product succeeded, because "you really can't derive any value" from a tool like Stripe until someone integrates it (00:00:50 to 00:01:32). From 2022, LLMs gave developers who could call an API the most leverage (00:02:17). Today, coding agents do much of the implementing, and the high-leverage work is building the context and tools that make agents reliable: MCP, skills, docs (00:03:44). **Why context decides reliability.** A model's intelligence is fixed when it ships, so it doesn't know your endpoints or how your API behaves (00:04:27). What makes a product work for an agent is the context it receives, the tools it can call, the data it can see and clear instructions. MCP is described as "a standardized phone line" between that information and the agent. **The traffic data.** Mintlify tracks agent versus human visits across the docs it hosts and reports the agent share passing 66%. Human traffic is also rising, but more slowly. The most active locations are cloud regions in Virginia, California and Oregon, which the speaker presents as a joke about where agents run. The Q&A adds method: visits are classified by user agent, plus counts of MCP calls and markdown file visits (00:19:41). **The interface model.** Pre-AI, a user reached a product through an API or a UI. Post-AI, the user reaches it through an agent, which then uses API, MCP, skills, CLIs or a UI (00:06:40 to 00:07:23). CLIs gain importance because autonomous agents such as OpenClaw and Hermes (names as captioned) run in sandboxes and prefer command lines. **Two audiences.** For developers, the speaker says the programming language is now English, software costs less, design matters less and freshness matters more. For non-developers, agents make developer-grade tools reachable: the speaker's internal example is salespeople with MCP connections to internal systems, whose callback URLs and API tokens the speaker revoked in a connector cleanup (00:10:18). From that, the speaker concludes that all software companies will build agents and that DevRel has a large teaching job, "a ton of alpha" in explaining these topics simply. **The Q&A adds the most testable material.** - The format benchmark (00:14:37): docs as llms.txt, markdown, or plain HTML. Accuracy was similar across formats, but agents seek out llms.txt and markdown, probably because they're trained to fetch less context, and they hit fewer 404s. - Paywalled docs (00:16:05): the speaker calls blocking agents "a massive disadvantage," suggests paywalling part of an MCP instead, and allows that enterprise audiences may justify exceptions. - Docs that only describe parameters (00:20:24): code examples help agents most, Mintlify offers agent-only context blocks, and "doing what's right for the human is good for the agent as well." - Localization (00:21:50): LLM translation is cheap enough to do, quality verification is still hard, and agents can translate on their own, so agent-side localization matters less. **Contested or unverified in this source.** The 66% figure has no stated denominator (visits, sessions, unique users), no time window and no bot-filtering description beyond user-agent matching. The benchmark gives no sample size, task set or accuracy numbers. The claim that agents are "trained to optimize for less context" is a guess offered with the word "think." The ratio of humans behind agents was not known to the speaker. ## 🗒️ Notes #### ⏱️ [00:00:08](https://www.youtube.com/watch?v=6G3EPodarGc&t=8) Introduction and the pre-AI case for DevEx - Speaker introduces as co-founder and CTO of Mintlify, a developer documentation platform expanding into help centers and knowledge bases. Customers named: Claude Code (captioned "Cloud Code"), OpenRouter, Lovable. - Thesis stated at 00:00:50: being developer-first is being agent-first. - Pre-AI argument: Stripe and HashiCorp won on DevEx because the developer is the final gatekeeper of integration and purchase. > [!quote] [00:00:50] > I'm here to talk about how being developer-first is agent-first. #### ⏱️ [00:01:32](https://www.youtube.com/watch?v=6G3EPodarGc&t=92) 2022 to now: LLMs, APIs and coding agents - From 2022, early AI adopters were developers, and "APIs were king" because the person who could call the LLM API had the highest leverage (00:02:17). - Today: weekly model releases, coding-IDE companies acquired for billions (captions garble the names as "Wind Surfing Cursor," likely Windsurf and Cursor). - The speaker says conference talk has moved from which front-end framework is best to tooling that improves agents. #### ⏱️ [00:02:59](https://www.youtube.com/watch?v=6G3EPodarGc&t=179) Context, MCP and skills as the new leverage - MCP and skills are named as inventions of the past two years. The highest-leverage work is building the systems that hand models context and tools. - A model's intelligence is fixed at ship time and doesn't know your product's endpoints, so reliability comes from context, callable tools, visible data and clear instructions (00:04:27). - MCP is likened to a standardized phone line between information and the agent. #### ⏱️ [00:05:12](https://www.youtube.com/watch?v=6G3EPodarGc&t=312) Agent versus human traffic data - Mintlify powers thousands of docs sites and tracks agent versus human visits live on its website. Captions render the URL as "multifeed.com/data"; it's likely a Mintlify page, so verify before citing. - Agent share recently passed 66%. Human traffic grows too, but slower. - Autonomous agents running in sandboxes (OpenClaw as captioned) are said to speed the shift. > [!quote] [00:05:56] > it just recently like surpassed 66% agent traffic. #### ⏱️ [00:06:40](https://www.youtube.com/watch?v=6G3EPodarGc&t=400) Where agents are, and how people reach products - Most active locations are US East and US West cloud regions (Virginia, California, Oregon), not dense human populations. - Pre-AI, a user reaches a product via API or UI. Post-AI, a user proxies through an agent that calls API, MCP, skills, CLIs or a UI (00:07:23). - CLIs gain importance because of autonomous agents such as OpenClaw and Hermes (names as captioned). #### ⏱️ [00:08:05](https://www.youtube.com/watch?v=6G3EPodarGc&t=485) What changes for developers - English is now the language of choice, software is cheaper, and design matters less for agents while freshness matters more. - The speaker, a CS major, says they miss some of the craft of programming languages. - Traditional DevEx is "evolving": agents now implement what humans build. > [!quote] [00:08:05] > how up-to-date the content is matters a lot more because agents can't really see what your design looks like. #### ⏱️ [00:09:33](https://www.youtube.com/watch?v=6G3EPodarGc&t=573) Every software product needs an agent experience - Claim: all software, not only dev tools, must prioritize agent experience because agents will be the medium for software interaction. - Claim: all software companies will build agents. "We're just at the tip of the iceberg." - Anecdote (00:10:18): while revoking a company connector, the speaker found everyone, salespeople included, had MCP connections to internal systems, with callback URLs and API tokens to revoke. #### ⏱️ [00:11:03](https://www.youtube.com/watch?v=6G3EPodarGc&t=663) Mintlify's standardization work and concluding thoughts - Mintlify says it standardized llms.txt (captioned "lm.txt"), a file LLMs scrape, and is still exploring what the right instructions for agents look like. - Conclusion: the definition of developer is evolving, agents widen access to traditional dev tools, and people now see how much upside those tools carry. #### ⏱️ [00:12:30](https://www.youtube.com/watch?v=6G3EPodarGc&t=750) DevRel's role and closing - DevRel has more to teach, especially topics "gatekept to people who are technical." - The speaker closes with two tweets: building and fixing software quickly for customers, and salespeople sending HTML mockups of future product ideas. - Talk ends at about 00:13:40, and the host opens Q&A. #### ⏱️ [00:13:54](https://www.youtube.com/watch?v=6G3EPodarGc&t=834) Q&A: the format benchmark - Most industry research on this topic has a marketing angle (are you cited by ChatGPT or Claude). Mintlify's angle is whether coding agents reach a success state when setting up a product. - Benchmark: llms.txt versus markdown versus plain HTML. Accuracy stayed good across all three, but agents look for llms.txt and markdown, and they hit fewer 404s (00:15:21). > [!quote] [00:14:37] > agents do look for LLMs.txt and they do look for markdown versions of files. - Planned experiment: run Claude Code against a quickstart and report to the user which changes aren't intuitive to the agent (00:16:05). #### ⏱️ [00:16:05](https://www.youtube.com/watch?v=6G3EPodarGc&t=965) Q&A: paywalled docs - An audience member says their legal team wants docs paywalled to protect competitive advantage, and asks if agent experience is possible. - Answer: it depends on the audience, enterprise cases may justify it, but blocking agents is "a massive disadvantage." Build APIs, CLIs and MCPs, and perhaps paywall part of the MCP instead. - Stated view: a product not reachable through agents is "a huge miss." #### ⏱️ [00:18:56](https://www.youtube.com/watch?v=6G3EPodarGc&t=1136) Q&A: how many humans sit behind agent traffic - The facilitator asks for the human-to-agent ratio behind the 66%. The speaker doesn't have unique-session numbers and promises to follow up. - Method disclosed: Mintlify counts MCP calls (every docs instance ships an MCP server) and visits to markdown files, and classifies bots by user agent. Claude Code is the largest source. #### ⏱️ [00:20:24](https://www.youtube.com/watch?v=6G3EPodarGc&t=1224) Q&A: beginner-friendly versus reference-only docs - Audience member: engineering teams document parameters but skip why and how to use an API, and AI-written docs make it worse. - Answer: humans tend not to update docs, so Mintlify builds tools to keep them current. Code examples help agents "a ton," and Mintlify supports agent-only context blocks. > [!quote] [00:21:08] > doing what's right for the human is good for the agent as well. #### ⏱️ [00:21:50](https://www.youtube.com/watch?v=6G3EPodarGc&t=1310) Q&A: localization - Question: does the 66% agent share change the role of localization? - Answer: LLM translation makes it far cheaper, quality verification still needs people who understand the content, and customers translate heavily into Chinese and Japanese. On-site AI chat answers in the asker's language and search works across languages, so agents partly offset the need. The talk ends at 00:24:02 with applause. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [Developer First = Agent First — Hahnbee Lee](https://www.youtube.com/watch?v=6G3EPodarGc): the source video, 24:17, uploaded 2026-10-14 by the Dev Rel channel. - [DevRelCon 2026 NYC](https://nyc.devrelcon.dev/): the event where the talk was presented, from the video description. - [Mintlify](https://mintlify.com): the speaker's company. The live agent-traffic page the speaker mentions is captioned "multifeed.com/data"; confirm the real URL on the Mintlify site before citing. - [llms.txt proposal](https://llmstxt.org): the convention the speaker calls "lm.txt" in the captions; the talk says Mintlify helped standardize it, which this analysis can't verify from the transcript. - [Model Context Protocol](https://modelcontextprotocol.io): MCP, described at 00:04:27 as a standardized phone line between context and agents. - [Stripe](https://stripe.com) and [HashiCorp](https://www.hashicorp.com): the two DevEx-led companies named at 00:00:50. - [Claude Code](https://www.anthropic.com/claude-code): named as a Mintlify customer's docs and as the top agent by traffic. - OpenClaw and Hermes: autonomous agents named at 00:07:23 and 00:05:56 (spellings as captioned, "open claw"). No links are given; verify the project names before citing. ## 🗣️ Paraphrase Lee, CTO of Mintlify, says the lessons of good developer experience carry over to agents. In the 2010s, a product like Stripe won because developers, the people who integrate and often approve a purchase, found it easy to use. Since 2022, developers have been first to use LLMs, and now coding agents do much of the implementing. Models don't know your product, so what makes a product work for an agent is the context, tools and instructions you hand it. MCP and skills are the delivery channels. Mintlify sees this in its own numbers: more than two thirds of visits to the docs it hosts now come from agents, and the busiest locations are cloud data-center regions. Lee argues that people now reach products through agents, so every software company needs an agent experience, not only dev-tool vendors. Design matters less for readers who can't see, and freshness matters more. In Q&A, Lee reports a benchmark where doc format barely changed accuracy, though agents seek out llms.txt and markdown and hit fewer dead pages. Lee advises against blocking agents from docs, can't say how many people sit behind the agent traffic, says code examples and use cases help both humans and agents, and says AI translation of docs is worth paying for even though verification remains hard. ## 📰 Newsletter **Your docs have a new main reader, and it's not a person.** Dev Rel's 24-minute DevRelCon talk from Mintlify co-founder Hahnbee Lee reports that agents now account for more than 66% of visits to the docs Mintlify hosts. Treat that as a vendor figure, since it comes from one platform's user-agent matching and the speaker couldn't say how many people sit behind it. The advice that follows is cheap and useful anyway: publish markdown versions of pages, add an llms.txt, keep pages current, and write down why someone would call an endpoint, not only which parameters it takes. For WordPress docs teams, the closest fit is DevHub and HelpHub. Code references there list hooks and functions, but "when would I use this" examples are thinner. The talk's Q&A says agents gain "a ton" from code examples, and that doing right by human readers is good for agents too. One more item: the benchmark Lee describes found plain HTML docs still get good accuracy, so this isn't a reason to rebuild anything. It's a reason to add a markdown path and fix stale pages. Links: [the talk](https://www.youtube.com/watch?v=6G3EPodarGc), [DevRelCon NYC](https://nyc.devrelcon.dev/), [llms.txt](https://llmstxt.org). ## ✅ Action items #### DevRel - Developer advocacy: run the same test Mintlify describes. Point a coding agent at one product quickstart, record where it fails, and publish the failure list as a talk or post. - Education: add an "agents read your docs" module to any docs workshop, covering llms.txt, markdown mirrors and code examples with use cases. - Developer experience: add a "why you'd use this" paragraph and a runnable example to every API reference entry, since the talk says examples help agents most (00:20:24). - Developer marketing: don't cite the 66% agent-traffic figure without attribution to Mintlify and a note that it's user-agent based. - Community management: when members share agent-traffic stats, ask for the denominator (visits, sessions or unique users) and the time window. - Internal/external/cross-project: ask docs owners to track MCP calls and markdown-file visits next to page views, as Mintlify does (00:19:41). #### OSPO - Policy and governance: decide whether project docs must ship in a machine-readable form (markdown plus llms.txt), and where that rule lives. - License compliance: check that doc content published for agents carries a clear license, because agents copy it into generated code and answers. - Security management: audit what internal systems employees connect to AI tools. The talk's connector cleanup (00:10:18) found MCP tokens and callback URLs held by non-engineers. - Software inventory: list MCP servers, skills and CLIs per product as supported integration surfaces with owners. - Developer support: write guidance on agent-only context blocks, covering what belongs there and what must stay in human-readable text. - Community engagement: no direct action from this source; nearest relevance: upstream docs tooling vendors that now compete on agent-readiness. - Strategic alignment: add "docs reachable and accurate for agents" to developer-experience KPIs, with a measurable proxy such as the agent 404 rate. #### Community - Maintainers: add llms.txt and markdown output to a project's doc build and compare agent 404 counts before and after. - Contributors: label docs issues that lack examples as "needs use case," so first-time contributors have an obvious entry point. - Sponsors: no direct action from this source; nearest relevance: fund docs freshness work, since the talk ranks freshness above design for agent readers. - Ecosystem: share a common benchmark protocol (format versus agent success rate) across projects so results are comparable. #### WordPress - Core: no direct action from this source; nearest relevance: whether core docs build emits markdown. - Core Performance: no direct action from this source; nearest relevance: agent crawl load on docs hosts. - Core AI: document the agent-readable surfaces core exposes (REST, Abilities, MCP adapters) as a single index. - **Core Program Team:** no direct action from this source; nearest relevance: a cross-team owner for agent-facing docs. - Mobile: no direct action from this source; nearest relevance: mobile app developer docs as agent-read content. - Playground: publish an llms.txt or markdown index for Playground docs, since agents set up reproducible environments from them. - Community: no direct action from this source; nearest relevance: meetup talks on agent-readable docs. - Training: add code-with-use-case examples to lesson pages, and measure whether an agent can complete a lesson unaided. - Marketing: no direct action from this source; nearest relevance: avoid repeating vendor statistics unattributed. - Support: check support-forum threads for agent-generated questions that stem from missing or stale docs. - Design: no direct action from this source; nearest relevance: the talk says design matters less to agent readers, but human readers still need it. - Documentation: add a markdown version and use-case examples to DevHub and HelpHub pages, and run an agent-success test on five high-traffic pages. - Photos: no direct action from this source; nearest relevance: none. - TV: no direct action from this source; nearest relevance: transcript availability, since agents can read transcripts but not video. - Polyglots: the talk reports LLM translation is cheap but hard to verify. Test an LLM draft with locale-team review on one doc set. - Accessibility: no direct action from this source; nearest relevance: agent-readable markup overlaps with screen-reader semantics. - Meta: expose docs in a machine-readable index on WordPress.org. - CLI: no direct action from this source; nearest relevance: the talk says CLIs gain importance as autonomous agents grow, so WP-CLI help text counts as agent-facing docs. - Hosting: no direct action from this source; nearest relevance: log agent user-agents to size the load on docs sites. - Tide: no direct action from this source; nearest relevance: none. - Openverse: no direct action from this source; nearest relevance: API docs examples for agent callers. - Themes: no direct action from this source; nearest relevance: handbook pages with use-case examples. - Plugins: no direct action from this source; nearest relevance: plugin developer docs that explain why to use an API, not only its signature. #### The WPOCC - Programs: no direct action from this source; nearest relevance: fund a docs-for-agents pilot under a documentation fellowship. - Projects: a documentation sprint on adding examples and markdown output to project handbooks. - Funding experiments: no direct action from this source; nearest relevance: tie a micro-grant to measured agent-success rate on funded docs. ### FAIR - Technical independence: no direct action from this source; nearest relevance: machine-readable docs and plain markdown avoid dependence on one docs vendor. - Policies and covenants: no direct action from this source; nearest relevance: the paywalled-docs question at 00:16:05 maps to anti-capture and openness commitments. - Productized governance artifacts: add "docs available to agents" as a row on operator scorecards. ## 🧪 Hypotheses 1. Providing llms.txt and a markdown mirror cuts an agent's failed page fetches (404s) by at least 30% compared with HTML-only docs, on the same site. 2. Doc format (llms.txt, markdown, HTML) changes agent task success by less than 5 percentage points when the content is identical, matching the speaker's "accuracy is pretty good across the board." 3. Adding a worked use case and code example to an API reference page raises agent task success more than adding the same effort to visual polish. 4. Agent share of docs traffic on a non-Mintlify site, measured by user agent, lands within 15 points of 66%, so the Mintlify figure generalizes. 5. At least a third of what user-agent matching labels agent traffic comes from search or AI-answer crawlers, not coding agents acting on a person's task. 6. Agent-only context blocks add accuracy only on pages where the human text omits a constraint, and add nothing on pages with complete examples. ## 📊 Methodology - **H1 and H2.** Pick 20 doc pages with matching content. Serve each in three formats on separate paths. Run a fixed set of 10 setup tasks through the same coding agent, three runs each, and record fetch errors, task success and token use per format. - **H3.** Choose 20 API reference pages without examples. Randomly add a use case plus example to half. Compare agent success on tasks needing those pages. Blind the grader to which arm each page belongs to. - **H4.** Collect server logs from three docs sites with different audiences (a framework, a SaaS API, a CMS handbook). Classify user agents with a published bot list and report visits, sessions and unique IPs separately. - **H5.** Sample 500 agent-labeled requests. Hand-classify by user-agent string and fetch pattern into coding agent, search crawler, AI-answer crawler and unknown. Report the share of each with a confidence interval. - **H6.** For 20 pages, write the agent-only context block, then run tasks with and without it. Compare success, and record whether the block repeated information already on the page. - **Controls.** Fix the model, prompt and temperature. Pre-register the success definition (for example, the setup completes and a test passes) before running. ## ❓ Questions - What is the 66% measured over: visits, sessions or unique users, and across what time window? - How does Mintlify tell a coding agent from a search crawler or an AI-answer fetcher when both identify by user agent? - How many people stand behind the agent traffic? The speaker didn't have the figure at 00:18:56. - What sample size and task set did the format benchmark use, and what were the accuracy numbers? - Does the fewer-404s result hold for sites without llms.txt that have clean sitemaps? - What belongs in an agent-only context block, and does it create a second, drifting version of the docs? - If docs are paywalled, can an authenticated MCP deliver the same agent experience, and what does that do to discovery? - Does the agent-first shift change who gets credit for docs work when human traffic is a third of visits? ## 🔮 Future research - **Agent success states.** The speaker plans experiments on whether agents reach a working setup from a quickstart. A public, repeatable protocol would let projects compare results. - **Unique-session accounting.** Agent request counts mean little without a ratio of requests per human task. A shared metric for "tasks supported" would replace raw visit share. - **Doc format effects over time.** Agents may shift their fetching habits as vendors retrain, so a one-time benchmark ages quickly. Re-run on a schedule. - **Prompt injection through docs.** If agents read docs and act on them, a page can carry instructions aimed at the agent. The talk doesn't address this surface, and agent-only context blocks make it explicit. - **Localization verification.** The speaker says LLM translation is cheap but verification is hard (00:21:50). Studies of agents answering from translated versus English docs would show whether translation matters for agent readers. ## 💡 Implications - **Practice.** Docs teams add markdown, llms.txt, examples with use cases and freshness checks to the definition of done, and track agent success next to page views. - **Policy.** Blocking agents from docs becomes a product decision with a stated cost: the speaker calls it a "massive disadvantage." Legal and product need to weigh that against competitive-exposure concerns. - **Security.** The connector cleanup at 00:10:18 shows MCP tokens and callback URLs spreading to non-engineers. Token inventory and revocation processes need to cover everyone, not only developers. - **Education.** DevRel gains a teaching job: explaining developer-grade tools to a broader audience, as the speaker says at 00:12:30. The curriculum includes agent context, not only API use. - **Funding.** Teams that fund docs by page views may under-count their readers. Funding models that count agent-served tasks would price the work more accurately. - **Vendor literacy.** The traffic statistic is a useful teaching case: a precise number from an interested party, with no denominator, shown to an audience of docs professionals. ## 🧠 Learning styles assessment - **Reading level estimate.** Estimated by sampling the transcript, not computed: Flesch-Kincaid Grade Level about 8 and Flesch Reading Ease about 70. Spoken delivery has long, run-on sentences and fillers, but the vocabulary is plain. Terms like MCP, llms.txt, skills and user agent go undefined, so effective difficulty is intermediate for non-developers. #### 👀 Visual learners - Present: the speaker shows a live traffic graph (referenced at 00:17:31 and 00:18:15) and meme slides (00:08:05, 00:12:30), which the transcript can't show. - Improve: add a diagram of the user, agent, then API, MCP, skills, CLI or UI path described at 00:06:40, and a labeled before and after traffic chart with the denominator on screen. #### 🔊 Aural learners - Present: spoken narration throughout, plus audience Q&A that works as a second voice. - Improve: a 2 minute audio summary of the three recommendations (markdown, examples, freshness) would help podcast listeners. The transcript shows [laughter] cues over three jokes the audio-only listener may miss. #### 🗣️ Verbal learners - Present: the "standardized phone line" analogy for MCP and the pre- and post-AI interface description are clear verbal framings. - Improve: MCP, skills, llms.txt and user agent are undefined. One clause each would help newcomers. #### 🧩 Kinesthetic learners - Present: the planned experiment (run Claude Code against a quickstart) is a concrete exercise, and the benchmark describes a repeatable setup. - Improve: no checklist, repository or step-by-step test is given. A "test your docs with an agent in 10 minutes" worksheet would convert the talk into practice. #### 🧠 Logical learners - Present: a three-era timeline (pre-2022, 2022, today) and the cause chain from fixed model knowledge to context dependence. - Improve: the key numbers (66%, benchmark results) have no method. Give the denominator, window, sample size and results table. #### 🧑‍🤝‍🧑 Social learners - Present: a 10 minute live Q&A with four audience questions and a facilitator follow-up shows peer discussion. - Improve: no community channel or follow-up venue is offered for the research the speaker offers to run on request (00:16:05). #### 🧘‍♀️ Solitary learners - Present: the talk is short enough to watch alone and rewatch. - Improve: add a reflection prompt, for example "How many of your last 100 doc visits were agents, and how would you know?" #### 🌿 Naturalistic learners - Present: the agent-traffic map follows cloud regions rather than population centers, a geography-based observation. - Improve: no energy or environmental angle appears. Agent-heavy traffic raises a compute-per-doc-fetch question that this group would care about. ## 📊 Accessibility assessment #### Screen reader semantics - Present: YouTube provides landmarks and player controls, and a transcript exists. - Improve: the key traffic graph and meme slides carry information the narration doesn't fully state. WCAG 2.2 AA 1.1.1 (Non-text Content) and 1.2.5 (Audio Description, Prerecorded) apply, because the speaker says "let me get the graph up" without reading the values. #### Keyboard navigation - Present: the YouTube player is keyboard operable with visible focus, which passes 2.1.1 and 2.4.7 via the platform. - Improve: the video has no chapters (the metadata chapter list is empty), so keyboard users must scrub linearly. Add chapters, which supports 2.4.5 (Multiple Ways) and 2.4.6 (Headings and Labels) for navigation. #### Contrast and readability - Present: unverifiable from a transcript. Slides and charts are likely shown at conference-room scale. - Improve: charts shown to a live room are often low-contrast when compressed. Check 1.4.3 (Contrast Minimum) and 1.4.11 (Non-text Contrast) on the traffic graph. #### Text resizing and reflow - Present: the player scales and captions resize independently. - Improve: text baked into slides doesn't resize or reflow, which fails 1.4.4 (Resize Text) and 1.4.10 (Reflow) for any information shown only on slides. #### Media and captions - Present: auto-captions exist and cover the full 24:17, including the Q&A. - Improve: auto-captions garble the speaker name ("Hanbi"), the company ("Millify"), the standard ("lm.txt"), a URL ("multifeed.com/data") and an agent name ("open claw"). That fails 1.2.2 (Captions, Prerecorded) in substance. Audience questions are inaudible in places, so questions appear without speaker identification. Human-corrected captions are the fix. #### Forms and interactions - Present: none in the video. - Improve: the live traffic page the speaker cites should be linked in the description as selectable text, since the spoken URL is garbled. If that page has a chart, 1.1.1 applies there too. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (captions wrong on every proper noun), **1.2.5** (no audio description for the graph and memes), **1.1.1** (chart data conveyed visually only), **2.4.5** (no chapters), **1.4.4 / 1.4.10** (slide text). Caption accuracy is the highest-impact and cheapest fix. ## 🌍 DEIB assessment #### Cultural breadth - Present: examples span the US cloud regions, and the localization answer mentions Chinese and Japanese translation demand (00:23:18). - Improve: the stats and examples center on US companies and English docs. Add data on non-English docs traffic, which the localization question points toward but the speaker doesn't supply. #### Inclusive language - Present: plain, direct, second-person language with no exclusionary terms in the transcript. - Improve: "gatekept to people who are technical" (00:12:30) frames technical knowledge as a gate. It also states the inclusion goal, so keep it, but define who is outside the gate. "Wild opinion" (audience question) and "voodoo" (00:21:08) are idioms that don't translate well. #### Neurodiversity support - Present: the argument follows a time order, and each Q&A answer starts by answering the asked question. - Improve: the main talk has false starts and restarts ("Sorry, let me collect my thoughts a little bit," 00:11:03), and the video has no chapters. Chapters and a one-line outline would help viewers who rely on predictable structure. #### Representation - Present: one speaker, plus a facilitator and at least four audience voices across the Q&A, including a facilitator who pushes back on the data. - Improve: audience members aren't named or described in the captions, so the video can't credit who raised which point. Add attribution in the description. #### Psychological safety - Present: the speaker admits not knowing the answer at 00:18:56 and offers to research it, and the room asks sharp questions without hostility. Laughter cues show a relaxed room. - Improve: the claim that products not reachable by agents are "a huge miss" could leave practitioners in constrained environments (regulated, enterprise) feeling judged. The speaker partly softens it at 00:17:31 by granting "a valid argument" for enterprises. ## ✅ Logical validity #### Strong reasoning - **Causal chain, 00:03:44 to 00:04:27.** A model's knowledge is fixed at ship time, so it can't know your endpoints, so reliability depends on the context you supply. The premises are stated and the conclusion follows. To strengthen it, say which context formats were tested. - **Historical analogy, 00:00:50 to 00:01:32.** Developers gatekept integration and purchase in the 2010s, so developer-first design won. Agents now implement, so the same gate moves to agents. The analogy is reasonable for tools that require integration, and it needs a boundary: it doesn't cover products used only through a UI. - **Empirical test with disclosed method, 00:14:37.** Comparing llms.txt, markdown and HTML on agent accuracy is a controlled design, and the speaker reports the unflattering part (accuracy was similar across formats). Publishing the sample would complete it. - **Admitted ignorance, 00:18:56.** The speaker says they don't know the unique-session count and offers to follow up. That concession raises credibility of the surrounding claims. - **Practical inference, 00:21:08.** Examples help human readers follow reasoning, and LLMs benefit from the same structure. This is plausible and consistent with the benchmark's advice. #### Fallacies - **Unsupported statistic, 00:05:56.** "it just recently like surpassed 66% agent traffic." No denominator, window or classification method appears in the talk. The method surfaced only in Q&A at 00:19:41 as user-agent matching, which can't separate an agent acting for a person from a crawler. *Fix:* state visits versus sessions, the window and the agent classification list. - **Equivocation in the thesis, throughout.** "Developer first equals agent first" asserts equivalence, but the speaker also says design matters less for agents, freshness matters more (00:08:05) and agent-only context is worth adding (00:21:08). Those are differences. *Fix:* restate as "developer-first is a good foundation for agent-first, with these additions." - **Hasty generalization, 00:10:18.** One internal anecdote (a company connector cleanup) supports "the definition of people who strive to leverage these softwares is increasing." A single company is thin evidence for a population trend. *Fix:* cite adoption data across companies or label it as an illustration. - **Undisclosed interest, throughout.** The speaker's company sells the platform that hosts the docs measured, runs the benchmark, and proposes llms.txt as a standard. The talk doesn't state this tension. *Fix:* a one-line disclosure, and independent replication of the benchmark. - **Bare assertion, 00:18:15.** "I think that's just a huge miss" applies to any product not reachable by agents. No evidence or boundary (regulated products, security tools) accompanies it. *Fix:* name the product types where the claim holds, and give a counterexample. - **Appeal to scale, 00:00:08 to 00:00:50.** Naming Claude Code, OpenRouter and Lovable as customers implies the approach works, but a customer list isn't evidence of agent success. *Fix:* link a case study with a measured result. - **Guess presented as mechanism, 00:14:37.** "I definitely think that they've been trained to kind of optimize for less context." This explains why agents prefer markdown but it's an inference about model training, not an observation. *Fix:* label it a hypothesis, and cite agent-vendor documentation if it exists. #### Tone of voice - Warm, conversational and candid, with filler words and false starts in the prepared talk ("Sorry, let me collect my thoughts a little bit," 00:11:03). The register is enthusiastic about change ("these are all very exciting changes," 00:12:30) while acknowledging fear of it, and humor lightens the room (laughter cues at 00:06:40 and 00:13:11). In Q&A the speaker is more careful: answers carry qualifiers ("I would say," "it depends on who your audience is"), concede gaps and promise follow-up. Marketing enthusiasm sits in the main talk, and the evidence caveats sit in the Q&A. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response pattern to accusation or criticism. This is a conference talk with audience Q&A, and no one accuses the speaker of wrongdoing. The sharpest challenge is the facilitator's question about how many humans sit behind the agent traffic (00:18:56), and the speaker answers it directly. For completeness across the three prongs: **Deny**: nothing is denied; the speaker says "I don't have an exact answer on that" and offers to follow up. **Attack**: no critic is attacked; the paywalled-docs question gets a reasoned reply that grants enterprise cases a "valid argument." **Reverse victim/offender**: no such move appears. ## 🎯 Conclusion The durable point is practical: if agents read most of your docs, then markdown availability, llms.txt, current content and examples with use cases matter more than layout, and the effort that serves a human reader also serves an agent. The benchmark in the Q&A (00:14:37) supports a modest version of this, since accuracy held across formats and agents preferred the smaller, cleaner files. The numbers don't carry the weight the slogan puts on them. The 66% agent-traffic figure comes from one vendor's platform, is based on user-agent matching, and has no stated denominator. The speaker also couldn't say how many humans sit behind it. "Developer first equals agent first" is partly contradicted by the speaker's own list of differences. **Next steps for readers:** run one agent against your quickstart and record where it fails. Add a markdown path and an llms.txt, and track 404s for agent fetches before and after. Ask any vendor quoting an agent-traffic share for the denominator and window. Verify the garbled names (Mintlify, OpenClaw, the traffic page URL) before citing this talk. ## 🔄 Refactor Appendix — Developer First = Agent First — Hahnbee Lee > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 4 Literature, 2 Permanent. Resonance filter applied; the Stripe and HashiCorp history and the localization answer were dropped as context, not claims. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Agent traffic to docs passes two thirds > [!quote] [00:05:56] > it just recently like surpassed 66% agent traffic. **Context & use**: - 00:05:56, after the speaker describes a live metric on the Mintlify site that tracks agent versus human visits. - The method (user-agent matching, MCP calls, markdown visits) surfaces only in Q&A at 00:19:41, and the speaker can't give a human-to-agent ratio at 00:18:56. Record the figure with those caveats or it misleads. **Tags**: #xref #share #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Design matters less than freshness for agent readers > [!quote] [00:08:05] > how up-to-date the content is matters a lot more because agents can't really see what your design looks like. **Context & use**: - 00:08:05, in the speaker's list of what changes for developers (English as the language of choice, cheaper software, design mattering less). - This is a concrete difference from human-oriented DevEx, and it undercuts the equivalence in the talk's title. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] Agents seek out llms.txt and markdown > [!quote] [00:14:37] > agents do look for LLMs.txt and they do look for markdown versions of files. **Context & use**: - 00:14:37, the finding from Mintlify's format benchmark; accuracy was similar across formats, but agents prefer smaller files and hit fewer 404s (00:15:21). - No sample size or accuracy numbers are given, so treat it as a lead to replicate. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H4] Good human docs are good agent docs > [!quote] [00:21:08] > doing what's right for the human is good for the agent as well. **Context & use**: - 00:21:08, answering a question about docs that list parameters but skip use cases. The speaker adds that agent-only context is worth including as well. - The reusable principle behind the talk; the speaker's own caveat (extra agent context) means it's not strict equivalence. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Write docs for humans first, then add agent context **Claim** (one sentence, Courtney's voice): Docs written to answer a human's "why would I use this" also serve agents, and the agent-specific additions are a thin layer on top. **Evidence pointer**: [[#H4]] · [[#H3]] **Scope & conditions**: Holds for reference docs with examples and clear use cases. Breaks when docs are generated from code and skip the why, when content is stale (the talk ranks freshness above design for agents), or when the product is reached only through a UI the agent can't see. **Links**: - [[Diataxis documentation framework]] — because extends - [[Agent-readable documentation]] — because evidence-for the markdown and llms.txt preference - [[Docs gap audit]] — because applies-in checking whether use cases and examples exist <!-- atomicity: 1 idea ✓ --> #### [P2] A traffic share without a denominator is not a finding **Claim** (one sentence, Courtney's voice): An "X% agent traffic" statistic means nothing until you know whether it counts visits, sessions or people, over what window, and how agents were identified. **Evidence pointer**: [[#H1]] **Scope & conditions**: Applies to any vendor traffic claim. The talk's own method (user-agent matching plus MCP and markdown counts) is disclosed in Q&A, so the claim is checkable in principle, but request counts can't show how many humans stand behind agents. **Links**: - [[Reading vendor benchmarks]] — because extends - [[Every claim carries a fact]] — because applies-in writing standards - [[Self-limiting disclosure raises credibility]] — because contrasts on direction of interest; the speaker admits not knowing the ratio at 00:18:56 <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Confirm the real names behind the captions: "Hanbi" and "Millify" (Hahnbee Lee, Mintlify), "multifeed.com/data" (the live traffic page), "lm.txt" (llms.txt), "open claw" (OpenClaw): https://www.youtube.com/watch?v=6G3EPodarGc #fleeting #inbox - [F2] Find the Mintlify benchmark behind the llms.txt versus markdown versus HTML claim at 00:14:37 and check for sample size and numbers #fleeting #inbox - [F3] Open question: how many humans stand behind the 66% agent traffic? The speaker couldn't say at 00:18:56 #fleeting #inbox - [F4] Try the quickstart test on one P1 or docs page: point a coding agent at it and log where it fails, per the speaker's planned experiment at 00:16:05 #fleeting #inbox - [F5] Article seed: "Developer first equals agent first, except where it doesn't." List the differences the speaker concedes (design, freshness, agent-only context) #fleeting #inbox #articleseed - [F6] Check whether agents reading docs creates a prompt-injection path that agent-only context blocks make explicit #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Verify Mintlify, OpenClaw and the live agent-traffic page URL before citing this talk: research, 15 min #things - [ ] Run one coding agent against a docs quickstart and log the failures: docs agent-readiness test #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Developer First = Agent First — Hahnbee Lee.md|Developer First = Agent First — Hahnbee Lee by Hahnbee Lee]] ## Highlights - [00:05:56] it every day, and it just recently like surpassed 66% agent traffic. And it's not like the human traffic isn't increasing, too. It's just that it's increasing at a far slower rate than the agent traffic is. And I would say, you know, like innovations like open claw and autonomous agents that are kind of running within sandboxes really expedited this as well, where agents are just now there's somewhat of a human behind them, but they're kind of out here just like scraping and exploring the web. Another interesting stat that I want to share is that the most active locations are no longer, you know, where dense human populations are, but it's actually where US East 1 and US West 1 are located. [00:06:40] >> [laughter] >> And so, yeah, you can see like Virginia and then California and Oregon is where the density of uh agent traffic is put. And so, how does this all go back to how developer first equals agent first? Um want to quickly describe how I would describe like people interact with products um pre-AI. I would say that there's a user, and then there's two different ways in which you can kind of interface with the product, either through an API or a UI. Post-AI, I would say now there are users are leveraging agents to then connect with your product, whether that's ([View Highlight](https://read.readwise.io/read/01m50sgnte27gymcb9yj3tb1tp)) - Note: [H1] Agent traffic to docs passes two thirds - Tags: atom/literature/h1 - [00:07:23] through API, MCP, skills, even CLIs or UIs. Um they're all now there as a way for for for human to then proxy through an agent to then access your product. And one thing I want to emphasize is that, you know, of course It's like everything that's not an MC pure skill has existed pre-AI, but I would say that like CLIs have like increased in importance because of like autonomous agents like open claw and Hermes. Um and I think there are two different angles in which you can view this. You can view this from like the angle of the developer or you can also view it from the angle of the rest of the world that [00:08:05] isn't a developer. And arguably from the view of the developer, there is so much changing. You know, the programming language of choice is now English, software is a lot cheaper, and I would say even design matters a lot less for agents, and how up-to-date the content is matters a lot more because agents can't really see what your design looks like. Um and so as agents are the ones implementing and leveraging the software tools made by humans, the definition of traditional dev ex is also evolving. And yeah, and I kind of wanted to show a meme of how I feel as somebody who was a CS major and really like, you know, spent time ([View Highlight](https://read.readwise.io/read/01m50sgr1w57t6xx1ky88b6fsk)) - Note: [H2] Design matters less than freshness for agent readers - Tags: atom/literature/h2 - [00:14:37] benchmark that we did is we set up different formats of docs of hey like does the LLMs.txt actually do anything? Does providing your docs in markdown actually do anything? Or does pure HTML docs just do the trick for you? And after running this experiment, we came to the conclusion that accuracy is still pretty good across the board, but that agents do look for LLMs.txt and they do look for markdown versions of files. And so I definitely think that they've been trained to kind of optimize for less context for for grabbing things that like have that are smaller. Um and there is value in that and there is like they run into far less like 404s [00:15:21] uh like uh like pages that don't exist essentially. Um and yeah, so we were kind of like we're able to like kind of back up like our standardization with like with facts and numbers of why why we do this. And then some you know future explorations that we're doing is if you have a quick start and an agent pulls your quick start and your um you want to see how like whether it gets to a success state or not. Like agents have like you know short attention spans. They don't stay on pages for long and they you know go through multiple pages at once. Like how does that behavior impact like how the adoption of your product specifically is another experiment that we plan on doing ([View Highlight](https://read.readwise.io/read/01m50sgtec55bn7p8qcq55skve)) - Note: [H3] Agents seek out llms.txt and markdown - Tags: atom/literature/h3 - [00:20:24] beginner-friendly or user-friendly docs versus just pure like this is the functional way it works? >> Um, yes. So uh, generally speaking I would say that you know, human tendency is to just not update the docs. So we're trying to kind of solve that too by like providing tools to keep them up to date and uh, correct. Um, what I've noticed in specific examples with APIs is that having code examples helps the agent a ton which typically you know, would have been quite difficult to grok for a human. But we also have uh, functionality where you can add context just for the agent. Um, which I think is super valuable in terms of making sure that the agent does the right thing. Um [00:21:08] but also generically speaking, I would say that um doing what's right for the human is good for the agent as well. Like there isn't like it isn't like some magic voodoo type type thing here. Um like having examples of why this is useful clearly also helps with the train of thought for LLMs, too. So, I would say you you hit it on the dot. Like that's like putting the extra thought, going the extra mile, and really trying to like put in the use cases is still beneficial for humans and agents. Although I would throw extra context in for the agent as well. >> Thank you so much for sharing all this data about consumption and where traffic ([View Highlight](https://read.readwise.io/read/01m50sgwrm7v16b7a21xgs01cw)) - Note: [H4] Good human docs are good agent docs - Tags: atom/literature/h3