Touching Grass in the Age of Agents — Carter Rabasa ![rw-book-cover](https://d34adp677peecb.cloudfront.net/static/images/article4.6bc1851654a0.png) 🔗 **Source:** [Touching Grass in the Age of Agents — Carter Rabasa](https://www.youtube.com/watch?v=83Mn3jOAZ14) > [!note]+ Document Notes > tags: [developer-relations, developer-empathy, ai-coding-agents, developer-experience, community-building] > author: Carter Rabasa > source: Dev Rel (YouTube) > reference: https://www.youtube.com/watch?v=83Mn3jOAZ14 > 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: Touching Grass in the Age of Agents — Carter Rabasa > <!-- 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--touching-grass-in-the-age-of-agents--carter-rabasa) ## 📝 Summary - **What happened.** The Dev Rel channel published a 25:25 recording (uploaded 2026-10-14) of Carter Rabasa's DevRelCon 2026 talk in NYC. Rabasa is Head of Developer Relations at Box. The talk is stories, not slides of data: an Internet Explorer 9 launch, a Twilio hackathon-era value, a move from DevRel into product, the founding of CascadiaJS, and a May hackathon in Seattle where a developer couldn't name the API their code was calling. - **The claim.** Coding agents now sit between developers and platforms, and DevRel teams are letting AI mediate their relationships with developers. Rabasa's test: "If you can't figure out how to serve one developer, I don't believe that you can serve any." His prescription is to do things that don't scale: build an app without AI, write more, and have managers return to individual-contributor work. - **Why it matters.** Platform companies are optimizing docs, SDKs and support for agents first. If the human developer is no longer the one reading the API reference, the feedback loop DevRel depends on (hackathon questions, meetup complaints, debugging sessions) weakens. The talk names that cost at 00:19:42 and gives one dated example at 00:05:12. - **Key stakeholders.** DevRel teams and their managers, platform and developer-tool companies (Box, Twilio, Microsoft are the named employers), developers who build through coding agents, and community event organizers (CascadiaJS). - **Risks and tradeoffs.** The evidence is first-person anecdote. The Twilio IPO attribution (00:13:11) is a conviction, not a measurement. "Scientifically proven" at 00:23:19 carries no citation. The talk also opens with a hiring plug (00:02:18) for a Box senior developer relations engineer role, which is a disclosed commercial interest the audience can weigh. - **Bottom line.** The core test (can you name the last developer you personally unblocked?) is cheap, specific and worth running on your own team. The causal story behind it (agents cause the distance) is plausible and unproven in this source. ## 📖 Main content **The core argument.** Rabasa dates the AI shift in DevRel to 2023, the ChatGPT moment (00:03:01). He describes early excitement, then a slow-building unease he "couldn't even articulate" (00:03:46). The talk is his attempt to name it: a growing distance between people in DevRel and the developers they serve (00:04:30), not caused by bad intent. Everyone is "doing what they think is the right thing" (00:05:12). **The hackathon anecdote.** At a Box-sponsored hackathon in Seattle in May, a developer asked for help. Rabasa asked which API the developer was calling and got no answer; the developer offered to show the prompt instead (00:05:56). Rabasa's own depth on the API's arguments was thin because he uses AI too (00:07:23). They fixed the problem, but he left uneasy. The point he draws is that the coding agent was "in between them and our platform" (00:06:39), so his usual support questions no longer mapped to how the developer worked. **The counter-example from Twilio.** Twilio's values included "wear the customer's shoes," which on the DevRel team meant wearing the developer's shoes (00:08:49). That meant helping with problems outside the product, such as installing Android Studio for a developer using the iOS SDK (00:09:32). Rabasa hit a wall when the product team didn't prioritize known developer-experience problems, so he moved to product, pitched the head of product, and got two headcount (00:11:00 to 00:11:45). They spent two and a half years fixing rough edges. He credits that work, in part, for Twilio's 2017 IPO (00:13:11). **The community-event parallel.** CascadiaJS started because Seattle developers had to fly to Scottsdale or Amelia Island for a good technical conference (00:14:40). Rabasa says it came from talking to people, "didn't scale," and has run for 14 years because the organizers are developers in the community (00:15:25 to 00:16:07). **The mastery argument.** Rabasa says summarizing instead of reading, and generating instead of writing, erodes mastery (00:17:32). He cites the end of the framework wars (Vue versus React, Rails versus Laravel) as a sign that fewer people argue about tooling trade-offs (00:18:15), and asks whether that silence means the arguments were stupid or the care is gone. His image is a frog in slowly heating water (00:18:58). **The prescription.** Not anti-AI and not anti-scale (00:21:10). Rabasa is "overwhelmingly optimistic" (00:21:53) but wants balance with things that don't scale: build an app without AI (his example is a Java app for Box's enterprise customers), write more, and for managers, return to IC work (00:22:36 to 00:23:19). Close: empathy is the difference between DevRel and marketing because DevRel people are developers serving developers (00:24:02). **Contested or unverifiable in this source.** - The causal claim that AI "is creating this disintermediation" is called "completely indisputable" at 00:19:42. The only evidence is one hackathon and a general observation. - "Scientifically proven that writing is how humans learn to think" (00:23:19) is stated without a study. The idea has research behind it in education literature, but the talk doesn't cite it. - The Twilio IPO link is correlation plus conviction. No attribution analysis is offered. - Auto-captions garble several proper nouns. "Devril" is DevRel, "Telefan" is probably telephony, "Devrocon" is DevRelCon, and the keynote speaker "Swift" at 00:21:53 is unclear. The head of product named "Pat Mallet" at 00:11:00 may be a garble of a different surname; confirm before citing. ## 🗒️ Notes #### ⏱️ [00:00:08](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=8) Introduction and background - First DevRelCon for Rabasa. Works in developer tools since 2009, started at Microsoft, first proper DevRel job at Twilio. - Runs CascadiaJS, a web and AI conference, since 2012. Lives in Seattle. - The transcript shows the Twilio team in the audience at 00:00:51. #### ⏱️ [00:01:35](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=95) Internet Explorer 9 and how DevRel started - Rabasa led developer marketing for the Internet Explorer 9 launch. People told him it was the worst job in the world. - He won developers over "one at a time" by listening and talking, not through an ad campaign (00:02:18). - Plug: Box has an open senior developer relations engineer role, New York City or the Bay Area. #### ⏱️ [00:03:01](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=181) Unease about AI and the "touching grass" frame - The ChatGPT moment in 2023 is the starting point. Early excitement, then a slow unease that kept "ticking up" month over month. - AI tooling is productive, but "hidden dangers" go unnoticed (00:03:46). - The talk is stories and anecdotes by design (00:04:30). He sees a growing distance between people in DevRel and developers. #### ⏱️ [00:05:12](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=312) The Seattle hackathon - Hackathon sponsored in May. Rabasa is experienced and wasn't worried when a developer asked for help. - His first question, which API the developer was calling, got no answer. The developer asked "Can I show you my prompt?" instead. - He knew intellectually this was happening. Living it under a deadline "reoriented my brain" (00:06:39). > [!quote] [00:06:39] > they didn't even know what API they were trying to call and they frankly like weren't terribly familiar with how Box worked #### ⏱️ [00:08:05](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=485) Twilio's values: wear the customer's shoes - Rabasa joined Twilio in 2012. Values there were "an unbelievably ingrained lived thing." - DevRel version: wear the developer's shoes. He wears his old Twilio sneakers on stage. - Empathy meant action, not only listening: stack chairs for a meetup organizer, help install Android Studio (00:09:32). #### ⏱️ [00:10:17](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=617) Hitting a wall and moving into product - DevRel sat in marketing at Twilio. Years of feedback on a suboptimal developer experience did not get prioritized by product. - Rabasa quit the DevRel team, pitched Twilio's head of product, and got two headcount (00:11:00 to 00:11:45). - Motive: developers struggling to debug Twilio applications was "driving me slowly insane." #### ⏱️ [00:12:28](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=748) Impact: developer tools and the 2017 IPO - Two and a half years fixing rough edges. The fixes came from direct contact, not reports or aggregated data. - Twilio was known first as a developer company. IPO in 2017. Rabasa has "tremendous conviction" the DevRel and DevTools work played a big part (00:13:11). > [!quote] [00:12:28] > it came from direct contact with developers, listening to them, seeing what their problems were, and caring about trying to fix them #### ⏱️ [00:13:55](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=835) CascadiaJS origin - Rabasa ran the Seattle JS meetup. Members flew to Scottsdale, Arizona or Amelia Island, Florida for good conferences despite Seattle's large engineering workforce. - He founded CascadiaJS. It was hard, didn't scale, and needed favors (00:15:25). It's still running 14 years later. - The difference from conferences that folded: "by devs for devs" (00:16:07), with developer co-organizers always in the community. #### ⏱️ [00:16:50](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=1010) AI mediation and lost mastery - Teams adopt AI tooling to scale outreach, but let relationships be mediated by it (00:17:32). - Examples of skipped effort: summarize instead of read, generate instead of write. - The framework-wars question at 00:18:15: who still fights over Vue versus React, Rails versus Laravel? #### ⏱️ [00:18:58](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=1138) Disintermediation - Frog-in-boiling-water image: gradual change, unclear whether AI helps or hurts. - Rabasa calls disintermediation between developers and platform companies "completely indisputable" and, personally, "super bad" (00:19:42). - Farther from developers means farther from the applications they build. #### ⏱️ [00:20:25](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=1225) The serve-one-developer test - Rabasa is bullish on the future but wants "eyes open." - Test: when did you or your team last solve a problem for one developer? If you can't remember, "pump the brakes" (00:21:10). > [!quote] [00:20:25] > If you can't figure out how to serve one developer, I don't believe that you can serve any. #### ⏱️ [00:21:53](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=1313) Things that don't scale - Borrowed from Paul Graham and Y Combinator: "do things that don't scale." - Build an app without AI. Rabasa's example is a Java application, because many Box customers are enterprise Java shops (00:22:36). - Write more. Managers: get back into IC work (00:23:19). #### ⏱️ [00:24:02](https://www.youtube.com/watch?v=83Mn3jOAZ14&t=1442) Closing: empathy as the DevRel difference - Empathy is the single most important difference between DevRel and everyone else, because DevRel people are developers serving developers. - Ask: walk in the developer's shoes, understand their goals, act in service of them (00:24:45). - Rabasa says it takes effort and he has had a good experience doing it himself. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [Touching Grass in the Age of Agents — Carter Rabasa](https://www.youtube.com/watch?v=83Mn3jOAZ14): the source video, 25:25, uploaded 2026-10-14 by the Dev Rel channel. - [DevRelCon 2026 NYC](https://nyc.devrelcon.dev/): the event, linked in the video description. - [Box](https://www.box.com): Rabasa's employer, named at 00:00:08. - [Twilio](https://www.twilio.com): the employer behind the values and IPO story (00:08:05 to 00:13:11). - [CascadiaJS](https://cascadiajs.com): the conference Rabasa runs (00:13:55). URL is the conference's public site; the transcript doesn't give it. - Paul Graham, "Do Things that Don't Scale": the essay behind the phrase quoted at 00:21:53. Named as a "famous Paul Graham YC thing," not linked in the transcript. - Internet Explorer 9: the Microsoft browser launched in 2011, named at 00:01:35. ## 🗣️ Paraphrase Rabasa opens with a confession about how he got into DevRel. Working on Internet Explorer 9, he learned that people's attitudes change when you show up, listen, and talk, not when you run a campaign. That habit, he says, is what DevRel is for. He then describes a May hackathon where the habit failed. A developer needed help, couldn't name the API in use, and wanted to show the prompt. A coding agent sat between the developer and Box, and Rabasa, who also uses AI, didn't know the API's arguments well enough to jump straight to the answer. They solved it, but the exchange felt different from every hackathon he'd done before. The middle of the talk is a case for why closeness pays. At Twilio, wearing the developer's shoes meant helping with things that weren't Twilio's problem, and when feedback stalled in marketing, it meant moving into product and fixing the developer experience himself. He ties that work to Twilio's 2017 IPO. CascadiaJS gets the same treatment: built from talking to Seattle developers, hard to scale, still running because developers run it. His warning is that AI is letting teams automate away the contact that produced all of that. People skip reading and writing, stop arguing about tools, and lose track of what developers are doing. His fix is small and personal: build something without AI, write more, and make managers do IC work. The measure is whether you can name the last developer you helped. ## 📰 Newsletter **Touch grass before you ship another agent-ready doc.** At DevRelCon 2026 in NYC, Carter Rabasa of Box gave a 25-minute talk that WordPress contributors can use as a checklist. The story: at a May hackathon, a developer couldn't say which API their code called, because a coding agent sat in the middle. Rabasa's test for any team is blunt. Can you name the last developer you personally unblocked? Where this lands for WordPress work: DevHub and HelpHub readers now include agents reading the page on behalf of someone who never opens it. Theme and plugin authors using Playground, Studio or an AI assistant may not know which hook or REST route their code calls. Support forum volunteers, Meta contributors and docs writers are the people closest to that gap. Rabasa's prescription is cheap: build one thing by hand each quarter, answer one forum thread end to end, and run an office-hours session where you ask "what are you building?" before "which API?" The talk is an anecdote-driven opinion, not a study. The "AI causes distance" claim rests on one hackathon, and the Twilio IPO credit is the speaker's conviction. Still, the question is worth asking your team on Monday. Links: [the video](https://www.youtube.com/watch?v=83Mn3jOAZ14), [DevRelCon NYC](https://nyc.devrelcon.dev/), [Do Things that Don't Scale](https://paulgraham.com/ds.html). ## ✅ Action items #### DevRel - Developer advocacy: run the one-developer test on your own team. Each person names the last developer they personally unblocked and the date. Record the answers and revisit in a quarter. - Education: add an office-hours format where the first question is "what are you building?" and the second is "which API?" The Seattle hackathon exchange at 00:05:56 shows why the order matters. - Developer experience: build one sample app per quarter with no AI assistance, in the language your largest customer segment uses, and log every point of friction. Rabasa's Java example is the model (00:22:36). - Developer marketing: don't cite the 2017 Twilio IPO as proof that DevRel drives revenue. Cite the mechanism he does evidence: direct contact produced specific fixes. - Community management: audit how many support and community interactions pass through an AI intermediary, and sample 20 per month for a human read. - Internal/external: if DevRel reports into marketing and feedback stalls, write down the escalation path to product before it stalls. Rabasa's route (00:11:00) was a direct pitch to the head of product with a headcount request. #### OSPO - Policy and governance: write down whether maintainers are expected to review agent-generated contributions line by line, and who signs off. - License compliance: no direct action from this source; nearest relevance is generated code entering contributions, which raises provenance questions the talk doesn't address. - Security management: no direct action from this source; nearest relevance is developers who can't name the API they call being unable to assess its security properties. - Software inventory: no direct action from this source. - Developer support: track how often a support request starts with a prompt instead of an error message or API name, as a lagging indicator of the gap Rabasa describes. - Community engagement: fund or host in-person events that don't scale, with developer co-organizers (the CascadiaJS model at 00:16:07). - Strategic alignment: add one measure to DevRel OKRs that counts direct developer problems solved per person per quarter, next to reach metrics. #### Community - Maintainers: ask each maintainer to resolve one contributor problem end to end per month without delegating the diagnosis. - Contributors: pair new contributors with a person for a first change, and ask them to explain what the code does before submitting. - Sponsors: show sponsors the one-developer test results (names withheld) alongside the usual attendance and reach numbers. - Ecosystem: run an event or call where organizers are working developers, since that is the stated reason CascadiaJS lasted 14 years. #### WordPress - Core: no direct action from this source; nearest relevance is whether core contributors still hear first-hand developer problems. - Core Performance: no direct action from this source. - Core AI: add a check to AI-feature reviews: can a developer using the feature still name the hook, REST route or ability being called? - **Core Program Team:** put "last developer served directly" on the retrospective template as an optional prompt. - Mobile: no direct action from this source. - Playground: a "build it by hand" Blueprint exercise, with no assistant, would teach the same lesson Rabasa wants from his Java example. - Community: WordCamp and meetup organizers can copy the CascadiaJS test: are the organizers working developers in the community? - Training: add a lesson that pairs "read the docs page" with "ask an assistant" on the same task, then compares what the learner retained. - Marketing: no direct action from this source; nearest relevance is his contrast between marketers and developers at 00:24:02. - Support: have each volunteer pick one forum thread a week to resolve fully, including a reproduction, with no generated answer pasted in. - Design: no direct action from this source. - Documentation: test DevHub pages with one human reader and one agent reader on the same task, and compare where each gets stuck. - Photos: no direct action from this source. - TV: no direct action from this source. - Polyglots: no direct action from this source. - Accessibility: no direct action from this source; nearest relevance is that audits need a person using the product, not a summary of it. - Meta: track which .org tools contributors still touch directly versus through an assistant. - CLI: no direct action from this source. - Hosting: no direct action from this source. - Tide: no direct action from this source. - Openverse: no direct action from this source. - Themes: reviewers can ask authors one question: which functions does your theme call, and why? - Plugins: same as Themes, with a security-focused question on the REST routes and capabilities used. #### The WPOCC - Programs: if The WP Open Community Collective funds fellowships, include direct developer-facing work as an eligible deliverable. - Projects: no direct action from this source. - Funding experiments: fund in-person, non-scaling events and report the outcomes the way Rabasa reports CascadiaJS, by longevity and organizer makeup, not attendance alone. ### FAIR - Technical independence: no direct action from this source. - Policies and covenants: no direct action from this source. - Productized governance artifacts: no direct action from this source. ## 🧪 Hypotheses 1. Developers who build with a coding agent can name the specific API or function they're calling less often than developers who write the code by hand, in a timed task. 2. DevRel teams that log direct developer problem resolutions per person per quarter resolve more product-feedback items into shipped fixes than teams that log only reach metrics. 3. Support tickets that open with a prompt or generated code, instead of an error message or API name, take longer to resolve on a first response. 4. Managers who do IC work at least one day a month report developer pain points closer to those in the public issue tracker than managers who don't. 5. Events organized by working developers in the community show higher repeat attendance after five years than events run by dedicated event staff. 6. Writing a summary by hand improves 30-day recall of an API reference compared with reading an AI-generated summary of the same page. ## 📊 Methodology - **H1.** Recruit 40 developers, half with an agent and half without. Give both groups the same integration task against a mid-sized API. At the end, ask each to list the endpoints and parameters used. Score exact matches against the logged calls. - **H2.** Survey 20 DevRel teams on what they track, then match to a product-feedback tracker. Compare feedback items shipped within 12 months. Control for team size and product maturity. - **H3.** Pull 500 support tickets from a public forum or a company queue. Label the opening message by type (error text, API name, prompt, generated code). Compare time to first useful reply and number of replies to resolution. - **H4.** Interview 12 managers about their last quarter. Code their stated developer pain points and compare to a sample of issue-tracker titles by overlap. - **H5.** Collect event data from 15 community conferences with at least five editions, tagging organizer type. Compare repeat-attendee rate. - **H6.** Randomized comparison with 60 participants. One group writes notes by hand, the other reads an AI summary. Quiz at 30 days. Control for time on task and prior knowledge. - **Controls throughout.** Pre-register thresholds. The talk contains no data, so every design above starts from zero. ## ❓ Questions - How many developers at that May hackathon, or at Box events since, showed the same pattern? One anecdote at 00:05:56 isn't a rate. - What would Rabasa count as evidence that disintermediation is helping, not hurting? He says it's unclear whether AI helps or hurts (00:18:58) and calls the distance "super bad" a minute later. - Which writing research does "scientifically proven" at 00:23:19 refer to, and does it cover professional technical writing? - Is there a point where DevRel with agent-first docs serves developers better than hand-holding? The talk says it's not anti-AI but gives no example of a good trade. - How does the "serve one developer" test scale to a DevRel team of 20 serving a million developers? Rabasa offers no sampling rule. - If a platform's main reader is an agent, is the agent the developer to be served? The talk treats the human as the only developer. - What does Box measure to decide the Twilio-style move into product is worth a headcount, given the Twilio case is a conviction? - Does the build-without-AI exercise teach about customers' real working conditions, or about a pre-AI baseline that customers no longer use? ## 🔮 Future research - **Measuring the distance.** Nobody in this source has measured how often developers fail to name the API they call. A shared instrument would turn the hackathon anecdote into a rate. - **Agent as audience.** DevRel practice for agent readers (docs structure, error messages, tool descriptions) is new. Whether serving agents well also serves the developer behind them is open. - **Feedback-loop decay.** Track the volume and quality of developer feedback reaching product teams before and after agent adoption. - **Writing and mastery for practitioners.** The claim at 00:23:19 needs a study on technical professionals, not students. - **Manager IC time.** Whether returning managers to IC work changes product decisions is untested in DevRel. ## 💡 Implications - **Practice.** Add a recurring, personal developer interaction to every DevRel role, and check it the way you'd check a metric. - **Policy.** Decide what "hands-on" means for DevRel managers and put it in role expectations. Rabasa's version is regular IC work at 00:23:19. - **Security.** Developers who can't name the APIs they call can't reason about permissions or data exposure. Support teams should ask for the API name first. - **Education.** Pair AI-assisted exercises with a no-AI baseline task so learners see what the assistant is doing for them. - **Funding.** Budget for activities that don't scale (small events, pairing, hand-built samples). They won't show up in reach numbers, so they need their own measure. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid grade level near 7 and Flesch Reading Ease near 75, estimated by hand from the spoken transcript, not computed with a tool. Short sentences and plain vocabulary. Spoken-language fillers ("um," "like") lower density but not difficulty. #### 👀 Visual learners - Present: the transcript mentions a QR code (00:02:18), a photo of Rabasa's two Twilio teammates (00:11:45), a billboard (00:12:28) and the old sneakers (00:08:05). Slides existed but the transcript can't show them. - Improve: add a one-slide diagram of developer, coding agent and platform, showing where DevRel contact used to happen and where it is blocked. #### 🔊 Aural learners - Present: the talk is conversational narration with audience interaction (raised hands at 00:00:08 and 00:01:35). - Improve: publish an audio-only version with the three recommendations restated at the end. The close at 00:24:02 has only one ask, to walk in the developer's shoes. #### 🗣️ Verbal learners - Present: stories carry the argument, and key terms ("things that don't scale," "touching grass," "wear the customer's shoes") are explained as they appear. - Improve: define "disintermediation" (00:19:42) in one sentence. It's the word the whole argument hangs on. #### 🧩 Kinesthetic learners - Present: the prescription is activities: build an app without AI, write more, do IC work (00:22:36 to 00:23:19). - Improve: give a concrete first exercise with a time box, such as "build a CRUD app in your customers' main language in one afternoon, no assistant, and write down every snag." #### 🧠 Logical learners - Present: a clear test (serve one developer, 00:20:25) and a sequence: story, symptom, cause, prescription. - Improve: state the causal claim as a testable statement with a measure. The talk leaves "AI is hurting" and "AI is helping" both open. #### 🧑‍🤝‍🧑 Social learners - Present: audience polls, a community-event thread, a hiring pitch, and an invitation to message Rabasa (00:03:01). - Improve: give a discussion prompt, for example "name the last developer you served," and a place for responses. #### 🧘‍♀️ Solitary learners - Present: the "pause and think" moment at 00:20:25 invites personal reflection. - Improve: provide a self-audit worksheet: last developer served, date, what you learned, what changed in the product. #### 🌿 Naturalistic learners - Present: the title metaphor "touching grass" and the "frog in boiling water" image at 00:18:58. - Improve: tie the metaphor to place. CascadiaJS is explicitly regional (Pacific Northwest, 00:13:55), so a local-ecosystem framing would reinforce it. ## 📊 Accessibility assessment Judged as published on YouTube: auto-generated captions, no chapter list (the metadata `chapters` array is empty), and a short description with one link. #### Screen reader semantics - Present: YouTube supplies the page structure and player controls. The description states the talk's premise and links the event. - Improve: add chapters. The 25-minute talk has at least 12 natural segments (see Notes). WCAG 2.2 2.4.5 (Multiple Ways) and 2.4.6 (Headings and Labels) are better served with chapter titles. #### Keyboard navigation - Present: the YouTube player is keyboard operable, so 2.1.1 passes through the platform. - Improve: chapter markers would give keyboard users jump targets instead of repeated seek-key presses. #### Contrast and readability - Present: unverifiable from a transcript. The slide content is not described in speech. - Improve: check slide text against 1.4.3 (Contrast Minimum), especially the QR code and photo captions. #### Text resizing and reflow - Present: the player scales and captions resize. - Improve: any burned-in slide text won't reflow, a gap against 1.4.4 (Resize Text) and 1.4.10 (Reflow). Offer slides as an accessible document. #### Media and captions - Present: auto-captions exist and are the source of this analysis. - Improve: the auto-captions garble proper nouns ("Devril" for DevRel, "Devrocon" for DevRelCon, "Telefan" for what is likely telephony, "Pat Mallet" possibly a mangled surname, "Kusha Tbian" unverified). This is a gap against 1.2.2 (Captions, Prerecorded). The QR code at 00:02:18 and photos at 00:11:45 and 00:12:28 are only visual; 1.2.5 (Audio Description, Prerecorded) isn't met for them. Add a human-corrected caption file. #### Forms and interactions - Present: no forms. The hiring plug and contact route are a QR code to a social account. - Improve: put the contact link and the job-posting link in the description as selectable text. A QR code alone fails the intent of 1.1.1 (Non-text Content) for non-sighted viewers. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (inaccurate captions on names and terms), **1.2.5** (visual-only QR code and photos), **1.1.1** (QR code with no text alternative), **2.4.5** (no chapters), and **1.4.4 / 1.4.10** for any burned-in slide text. The caption fix is the highest impact and cheapest. ## 🌍 DEIB assessment #### Cultural breadth - Present: references span Microsoft, Twilio, Box, and a regional conference. The audience is global enough that Rabasa says people come to CascadiaJS "from all over the country and all over the world" (00:13:55). - Improve: all employers and events are US-based. Add a non-US developer community example, since agent-mediated development is not US-specific. #### Inclusive language - Present: no exclusionary terms in the transcript. "Gray beard" at 00:00:08 is self-description about age and experience. - Improve: idioms such as "touching grass," "pump the brakes" and "frog in boiling water" assume English-language fluency. A one-line gloss of "touching grass" at the start would help non-native speakers. #### Neurodiversity support - Present: story-driven structure with a recognizable pattern: anecdote, lesson, link back to AI. - Improve: the talk has no signposting of the three recommendations before they arrive at 00:22:36. A preview line ("I'll end with three things") would reduce working-memory load. Chapters would help navigation. #### Representation - Present: Rabasa names two teammates (Martin Amps and "Kusha Tbian," per captions) and the Twilio team in the audience. A hackathon participant and a head of product appear in stories. - Improve: the central contrast, DevRel people versus marketers, is drawn without any marketing voice. A quoted marketing perspective would balance it. #### Psychological safety - Present: Rabasa admits his own failing at the hackathon ("I wasn't entirely innocent," 00:06:39) and acknowledges managers under pressure to prove DevRel value (00:21:10). - Improve: telling managers "get back into IC work" (00:23:19) and saying marketing people can't have the same empathy (00:24:02) may make non-developer DevRel colleagues feel excluded. Say how non-developers can contribute. ## ✅ Logical validity #### Strong reasoning - **Concrete test, 00:20:25.** "Serve one developer" is falsifiable by a team: name the last developer you helped and when. It's a clear criterion that doesn't depend on any contested claim. Clarify by adding a recommended maximum gap. - **First-hand case, 00:05:56 to 00:07:23.** The hackathon account is specific (a month, a place, a question and an answer that failed). It demonstrates the phenomenon exists. It doesn't show how common it is. - **Analogy from experience, 00:13:55 to 00:16:50.** CascadiaJS lasting 14 years while other community conferences ended is offered with a mechanism (organizers are community developers). The mechanism is plausible. Strengthen with a comparison of conferences that ended. - **Self-implication, 00:07:23.** Rabasa notes his own API depth was limited because he uses AI too. That makes the argument about a shared habit, not an accusation. - **Scoped claim, 00:21:10.** "This is not an anti-AI or anti-scale talk" limits the argument to a balance, which is easier to defend than a rejection of AI tools. #### Fallacies - **Anecdotal evidence and hasty generalization, 00:05:56.** "He's just like, well, you know, I this is here. Can I show you my prompt?" One developer at one hackathon supports a pattern claim about the industry. *Fix:* collect a count across events and say how many developers fit the pattern. - **Questionable cause, 00:13:11.** "I have tremendous conviction that the work that like me, folks on the Devril team... played a big part in that successful outcome" attributes a 2017 IPO partly to DevRel and DevTools work. Many factors drive an IPO. *Fix:* name a measurable link such as developer-sourced revenue or adoption. - **Appeal to unsourced science, 00:23:19.** "scientifically proven that writing is how humans learn to think. Like, look it up." The instruction to look it up shifts the burden to the audience. *Fix:* cite the study. - **Slippery slope framing, 00:18:58.** "This is the frog, you know, like boiling in the water." The image implies a harmful endpoint without showing the path. *Fix:* name the thresholds that would signal real harm. - **Argument from silence, 00:18:15.** The absence of framework-war arguments is taken as evidence people care less about tooling. Other explanations exist (maturity of the ecosystem, platform shifts to social media). *Fix:* point to a measure of tool-choice discussion over time. - **Overstatement, 00:19:42.** "I think it's completely indisputable" followed in the same paragraph by "we can argue about whether it's good or bad." The disintermediation claim is called indisputable, and the evaluation is left open, but the mechanism itself is only shown by one case. *Fix:* say "I see it in my own work" and offer evidence of scale. - **Disclosed commercial interest, 00:02:18.** The hiring plug for Box is stated openly, so it isn't a hidden-interest fallacy. It's noted because the talk's premise (DevRel should do more hands-on work) aligns with a pitch to hire DevRel engineers. #### Tone of voice - Warm, self-deprecating and conversational. Rabasa uses humor at the start (the Internet Explorer 9 story at 00:01:35, "I'm one of those like gray beard people") and shifts to urgency at 00:19:42 ("I think it's super bad"). First- and second-person throughout: "I," "you all," "folks." He apologizes for anecdotes at 00:04:30 and ends with gratitude and applause at 00:24:45. The strongest claims land in the last third, where the evidence is thinnest, and the first two-thirds are the stories that earn the credibility. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response to accusation or criticism, and this is a conference talk with no accuser. **Deny:** nothing is denied; Rabasa volunteers his own fault at 00:06:39. **Attack:** no critics are named; the contrast with marketers at 00:24:02 is a claim about role, not a personal attack. **Reverse victim/offender:** no such move appears. The talk casts the audience, itself included, as participants in a gradual problem, and says none of it is "caused by bad intentions" (00:05:12). ## 🎯 Conclusion The durable idea is a habit, not a theory: serve one developer, personally, and keep doing it. Rabasa's hackathon story at 00:05:56 gives a vivid example of why, and his Twilio story at 00:10:17 shows the habit changing a company's product. Both are experience, not data, and the talk is honest about being anecdotes. The weaker parts are the causal claims. "Completely indisputable" disintermediation (00:19:42) and "scientifically proven" writing benefits (00:23:19) both arrive without evidence. The IPO credit (00:13:11) is a conviction. Treat those as hypotheses (see the Hypotheses section) and the rest as a practice worth trying. **Next steps for readers:** ask every person on your team to name the last developer they personally unblocked, and the date. If the answer is more than a quarter ago, schedule one hands-on session: build a sample without an assistant, or resolve one support thread end to end. Then compare what you learn to what your AI-mediated channels reported. Get the real names behind the garbled captions ("Pat Mallet," "Kusha Tbian," "Swift") before citing them. ## 🔄 Refactor Appendix — Touching Grass in the Age of Agents — Carter Rabasa > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the Internet Explorer 9 > and CascadiaJS origin stories were folded into H5, and the IPO attribution was dropped > as an unmeasured claim. > > 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] One developer served is the test > [!quote] [00:20:25] > If you can't figure out how to serve one developer, I don't believe that you can serve any. **Context & use**: - 00:20:25, after the disintermediation argument and before the "pump the brakes" prompt at 00:21:10. - A falsifiable team check: name the last developer you personally helped and when. It works without accepting any of the causal claims around it. **Tags**: #xref #aphorisms #share <!-- atomicity: 1 idea ✓ --> #### [H2] AI-mediated relationships weaken developer contact > [!quote] [00:17:32] > we're allowing our relationships with all of these developers and all of these communities to be mediated by AI, right? **Context & use**: - 00:17:32, the start of the mastery argument. Rabasa follows it with summaries replacing reading and generation replacing writing. - Evidence is general observation plus the hackathon at 00:05:56. Hold it as a hypothesis. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H3] Coding agents hide the API from developers > [!quote] [00:06:39] > they didn't even know what API they were trying to call and they frankly like weren't terribly familiar with how Box worked **Context & use**: - 00:06:39, the Seattle hackathon in May, after Rabasa's first question about which API got no answer. - One case, but a concrete one. It changes what support questions work: ask what the developer is building before asking which call fails. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H4] Writing is how humans learn to think > [!quote] [00:23:19] > scientifically proven that writing is how humans learn to think. Like, look it up. **Context & use**: - 00:23:19, part of the "do things that don't scale" prescription, right after "please write more." - No citation is given. Keep the claim, mark the evidence as missing, and find the research before reusing it. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H5] Direct contact produced the developer-experience fixes > [!quote] [00:12:28] > it came from direct contact with developers, listening to them, seeing what their problems were, and caring about trying to fix them **Context & use**: - 00:12:28, closing the Twilio product-team story after two and a half years of fixing rough edges. - The same pattern recurs for CascadiaJS at 00:15:25. The talk's through-line is that the source of good decisions was conversation, not reports. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Name the last developer you served **Claim** (one sentence, Courtney's voice): A team that can't name the last developer it personally helped has lost the contact that its product decisions depend on. **Evidence pointer**: [[#H1]] · [[#H5]] **Scope & conditions**: Holds for developer-facing teams with access to individual developers. Breaks for platforms with millions of anonymous users where individual contact can't scale, and when "serve" is defined so loosely that any interaction counts. The talk offers no counterexample and no threshold for how long a gap is too long. **Links**: - [[Developer relations measurement]] — because extends - [[Feedback loops in developer experience]] — because evidence-for - [[Hands-on work for managers]] — because applies-in DevRel leadership <!-- atomicity: 1 idea ✓ --> #### [P2] Agent mediation hides what developers need **Claim** (one sentence, Courtney's voice): When a coding agent writes the integration, the developer may not know which API they depend on, so support has to start with what they're building. **Evidence pointer**: [[#H3]] **Scope & conditions**: Applies to developers building through agents with prompt-first workflows. Weak as a general rule because it rests on one hackathon anecdote. Test it by sampling support tickets for how they open. **Links**: - [[Agent-ready documentation]] — because contrasts on audience, since docs written for agents may leave the developer out - [[Support ticket triage]] — because applies-in intake questions - [[AI-mediated communication]] — because extends <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Confirm names garbled by auto-captions: "Pat Mallet," "Kusha Tbian," the "Swift" keynote at 00:21:53, "Telefan," "Devril": https://www.youtube.com/watch?v=83Mn3jOAZ14 #fleeting #inbox - [F2] Find the research behind "writing is how humans learn to think" (00:23:19) before reusing the claim #fleeting #inbox - [F3] Open question: how would you measure "distance" between a DevRel team and developers? Count of one-to-one interactions per person per quarter? #fleeting #inbox - [F4] Article seed: "The one-developer test," a short post applying Rabasa's question to WordPress docs and forum work #fleeting #inbox #articleseed - [F5] Does the build-without-AI exercise (00:22:36) teach customers' conditions or a pre-AI baseline? Needs a counter-argument before adopting #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Ask the docs and DevRel team to name the last developer each personally unblocked, with dates: team check-in, 15 min #things - [ ] Verify the garbled names and the writing-research claim from the Touching Grass talk before citing it anywhere: research, 20 min #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Touching Grass in the Age of Agents — Carter Rabasa.md|Touching Grass in the Age of Agents — Carter Rabasa by Carter Rabasa]] ## Highlights - [00:05:56] in the morning or something. Um, so I know exactly what I'm supposed to do, you know, and when a developer came up to me and said that they had a problem, I wasn't worried. I'm like, great, this is what I'm here for, right? You know, like I'm here to support you with whatever you're trying to build. let's figure it out. The problem was that like the world had just changed, right? My questions didn't make any sense. Like I started asking this person, well, tell me about like what API you're trying to call. He had no idea. He's just like, well, you know, I this is here. Can I show you my prompt? Um, and you know, and and trust me, like this is not news. I mean, I'm not trying to act totally surprised by this. um intellectually [00:06:39] like I understood and my team understands and my company understands and you all understand that this is a thing that's happening. I am telling you that it is very different when it happens in front of you and when like there's time pressure for like trying to solve this person's problem because like there's a deadline to submit the project. So, and it just completely reoriented my brain around like how do I even help this person because like they didn't even know what API they were trying to call and they frankly like weren't terribly familiar with how Box worked because the coding agent was sort of like in the way. It was in between them and and our platform, right? Um, and by the way, I wasn't entirely I wasn't entirely innocent here. You know, ([View Highlight](https://read.readwise.io/read/01m50scsq31y4f4w9s8bxp42zc)) - Note: [H3] Coding agents hide the API from developers - Tags: atom/literature/h3 - [00:11:45] incentivized to solve this problem across the board. Please let me help solve this problem. And that's what we did. So I was uh I moved over to product. I was given two headcount uh those people in the photo, Martin Amps and Kusha Tbian. Um two of my best friends. We spent the next two and a half years building amazing developer tools at Twilio fixing all of these rough edges in the developer experience. Um it was maybe some of the best years of my life. Um and once again like this this did not come from you know analyzing uh some kind of report uh or you know aggregating some kind of data. [00:12:28] Um, it came from direct contact with developers, listening to them, seeing what their problems were, and caring about trying to fix them and frankly like going like doing whatever it would take to fix them. Um, and what impact did this have, right? Like who cares? Well, this is a billboard that barely even mentions that Twilio is, you know, at the time basically an SMS and voice API. Twilio was a company that built direct relationships with developers. Twilio was a company that developers loved. People would talk about Twilio first as a developer company and then ([View Highlight](https://read.readwise.io/read/01m50scygdf9ey8vk3nqd2wt8a)) - Note: [H5] Direct contact produced the developer-experience fixes - Tags: atom/literature/h3 - [00:17:32] know? I think that we are we're we're we're we're not we're allowing our relationships with all of these developers and all of these communities to be mediated by AI, right? Um, you know, you uh we are like losing mastery, right? This is this is not unique to uh to Devril, right? Right? I mean I could be giving a very similar talk to engineers or developers or I mean anybody right um why you know you don't have to you don't have to actually read anything you can just sort of create a summary right like why read a blog post why read a tutorial just get it get it summarized you don't you clearly don't have to write code you [00:18:15] can just you can just generate it you don't have to write blog posts you can just generate them right I mean think about this like You does it even matter whether you use Vue or React? Do you remember I mean seriously folks do you remember like the framework wars? Do you remember the emotional do people would fight about like you know the difference between you know Ruby on Rails or Laravel and like you know PH like people would get into like would literally get into huge fights huge arguments huge you know huge internet wars like the when's the last time that that's happened right I mean like who's who's putting energy into thinking about these things and like ([View Highlight](https://read.readwise.io/read/01m50scqhmytqdb0ftp7kda0q6)) - Note: [H2] AI-mediated relationships weaken developer contact - Tags: atom/literature/h2 - [00:20:25] and and by the way, like to be uh to be super clear, um, I'm very excited and very bullish about the future and I we'll we'll talk about that in a second, but I think that like we have to be eyes open that this is happening and we have to be eyes open about like how do we solve it. My general thought is this. If you can't figure out how to serve one developer, I don't believe that you can serve any. Full stop. Right? So, this is just sort of like a pause and like think about it. Like, think about the last time you or your team specifically saw like served one developer, solved a problem for one [00:21:10] developer. if you're kind of like, you know, if you're drawing a blank because you can't remember or like it was just, you know, it's too long ago or, you know, you've just been sort of operating at 10,000 feet for a while now. Um, I think you should pump the brakes. So, uh, this is not an anti- AI or anti-scale talk. Um, I have I have tons of empathy for all of you and people on my team that like have real accountabilities at the companies that they work for, right? There's never been more pressure to figure out how Devril delivers business value, why Devril matters. I was incredibly inspired. Who here uh saw ([View Highlight](https://read.readwise.io/read/01m50scnafew30gbsg4f7nvca0)) - Note: [H1] One developer served is the test - Tags: atom/literature/h1 - [00:23:19] scientifically proven that writing is how humans learn to think. Like, look it up. It's a true statement. The less that you write, the less you can really think about complex ideas. And I think a bunch of these other things are like things that you've all seen. I will say to folks here that are managers like get if you are not directly and repeatably and regularly engaged in IC work, get back into IC work. Like it's incredibly important. Like you cannot just sort of be pushing papers around or you know people managing like you have to absolutely be down in it. Um, and I think that when I think about everything, when I think about, you know, my time at uh at Microsoft or my [00:24:02] time at Twilio, like to me, like empathy is the single most important difference between folks in Devril and everybody else. And I'll tell you, and I'll tell you why. I know that people in marketing can have empathy for developers, but they can't have empathy for developers that way that we do because they're not developers. We are developers and we serve developers. And that's completely unique. You know, marketers generally don't market to marketers, but developers serve who work in DevRel serve developers. So, I guess if I were to leave you with anything, I'd say please take the time to like walk in the developer shoes. Like whatever role you have, like whatever you're doing, take that time, ([View Highlight](https://read.readwise.io/read/01m50scw2hq6r715dnjtprsdpw)) - Note: [H4] Writing is how humans learn to think - Tags: atom/literature/h3