A talk by Eyal Blum (Figma) on driving engineering organizations to adopt coding agents responsibly. Covers why the strongest engineers adopt agents last (they carry undocumented institutional context and see failure modes first), and argues for investing in verification first, encoding what works into deterministic flows, and using a testing pyramid for agent review. Also addresses the human costs: reduced developer agency and bloated AI-generated communication, with a convention of opening pull request descriptions with a human-written line followed by generated text. Themes include planning instead of prompting, writing plans agents can follow, handing skeptics the roadmap for making agents safe, and attention-aware communication. # Channel Identity Observations — Eyal Blum, Figma ## Source Overview - **Title**: "How to Get Your Org to Adopt Coding Agents (Without Shipping Garbage) — Eyal Blum, Figma" - **Format**: Conference talk (live audience, applause, references to other talks "here in all the talks" throughout the day) - **Speaker self-identification**: "My name is Alon Blum. I am a software engineer at Figma." ## Explicit Self-Description - The speaker explicitly frames his role as internal to Figma's engineering organization: > "In this talk, I'm not going to talk about our product. I'm going to talk more about our internal organization and how our engineering org has been adopting AI agents." - Figma is described as: > "the browser-based editor where design and engineering and now AI agent collaborate together to ship code... Figma has pivoted very strongly from being a traditional tool to an AI-first tool." - The speaker notes his tenure: "I've been working in the valley for the last 15 years." ## Intended Audience - **Engineering leaders and practitioners adopting AI coding agents**, evidenced by the practical organizational framing: "how we've adopted or are adopting agent into our workflow at Figma while maintaining high quality for our code base." - **An in-person conference audience already familiar with AI tooling**: "a lot of the people in this room who have been... using AI for a while." - Assumes shared context with other conference talks: "a lot of the speakers here have touched upon this" and "I think I've heard it for multiple talks." ## Claimed Scope - Covers **organizational AI adoption**, not product content: - A "three-act process of AI adoption" (initial success → failure at scale → skilled, guardrailed use). - Friction points: uneven team adoption, reduced developer agency and job satisfaction, expert engineers becoming bottlenecks, and inflated AI-generated communication volume. - Engineering practices: investment in verification, deterministic encoding of agent-discovered checks, TDD-style prompting, planning-heavy workflows, attention-aware communication norms, and involving skeptics in the improvement roadmap. - Claims concrete results with a specific figure: > "It's basically six weeks of of coding work... only took 1 week, so that's where I got the 5x speed up." - Explicitly limits claims — the journey is presented as ongoing: > "This is a journey. We have not come out through the other end... Our automation story is not fully there yet." ## Demonstrated Presentation Patterns (Observable) - **Evidence-driven but informal**: mixes structured frameworks (testing pyramid analogy, plan anatomy) with anecdote ("this is a screenshot that I randomly picked up a plan"). - **Candid self-correction**: recounts a personal failure in AI communication etiquette ("they got very upset... I took immediately like I apologize. I realize I should have marked it clearly"). - **Empathetic toward skeptics**: advises giving skeptics ownership — "let's have them be in charge of the road map to make AI safe your organization." - **Cultural framing over pure tooling**: "It's a culture shift, it's an engineering shift and... this is the biggest change by orders of magnitude of everything that I've seen." ## Metadata - No curated metadata was supplied; all observations derive from the title and transcript. ## Claims vs. Demonstration Distinction - **Creator claims**: 5x speedup, three-act adoption model, Figma's AI-first pivot — asserted by the speaker without external verification in the material. - **Demonstrated**: practical, experience-based lessons, tolerance for uncertainty, and a communication style that models the "attention-aware" norms being advocated. # Delivery Observations — "How to Get Your Org to Adopt Coding Agents (Without Shipping Garbage)" ## Tone & Register - **Conversational, informal conference-talk style.** The speaker opens with a plain greeting and self-introduction: *"Good afternoon. My name is Alon Blum. I am a software engineer at Figma."* - **Frequent verbal fillers and restarts**, suggesting an unscripted or lightly-scripted delivery: *"Um,"* appears throughout (e.g., *"Um what we we found internally is..."*; *"Uh so, um I think I this..."*). Repeated words like *"we we found"* and *"have have been noticing"* occur regularly. - **Self-corrects mid-sentence**, e.g., *"I'm sure everybody can resonate or in Sorry, I'm sure everybody here will resonate."* ## Recurring Vocabulary & Phrases - **"Really" as an intensifier** — used repeatedly: *"really helpful,"* *"really important,"* *"really successful,"* *"really powerful thing,"* *"really reintroduce the joy."* This is one of the most stable verbal habits in the talk. - **"Um so" as a transition marker** between topics: *"Um so, I'm going to spend uh the next few minutes..."*; *"Um So, they need to coexist..."* - **Repeated framing of stages/gates**: *"validation gate,"* *"executive summary at the top,"* *"left shift"* — verification vocabulary recurs. ## Teaching Habits & Structure - **Narrative framing device**: the "three-act process" of AI adoption introduced early (*"there's kind of a three-act process of AI adoption"*) and referenced back to (*"getting everybody to the third act of the story"*). - **Problem-list-then-lessons structure**: spends the first half cataloguing friction points (uneven adoption, lost developer agency, burdened experts, communication bloat), then pivots explicitly: *"I'm going to spend uh the next few minutes talking about some of the lessons that we've learned."* - **Concrete personal anecdotes as evidence**, told in first person: - The PR-comment analysis story: *"they got very upset. They're like, 'Why is sending I did not expect somebody um that I respect this much to send me something that's clearly this sloppy.' And then like I I took immediately like I apologize."* - The "cup of coffee" heuristic for PR size: *"kind of like the test is I'm going to get need to get a cup of coffee before I read this. That means it's too big."* - **Quantified claims for impact**: *"10x faster,"* *"six weeks of of coding work... only took 1 week, so that's where I got the 5x speed up,"* *"20 PRs here."* ## Rhetorical & Audience-Engagement Patterns - **Direct audience appeals**: *"this one I'm sure everybody here will resonate"*; *"I've heard it for multiple talks"* — repeatedly situating his points within the conference itself (*"all the stuff that we've been talking all day about here in all the talks"*). - **Colloquial metaphors and imagery**: *"mental duct tape"* (*"they are like holding together with with like their mental duct tape"*); *"how much slop can you expect."* - **Hedged, humble claims**: *"This is a journey. We have not come out through the other end"*; *"I don't know about you."* Repeated hedges: *"kind of,"* *"probably,"* *"basically." ## Occasional Delivery Hiccups (Isolated Moments) - An apparent mid-sentence interruption near the plan-screenshot discussion: *"Oh-oh. No, thank you."* — likely an isolated moment (possibly an AV or timer interruption); not a recurring pattern. - Occasional dropped or tangled syntax, e.g., *"they end up getting out of the burden"* and *"make AI safe your organization"* — these appear to be isolated slips rather than a pattern. ## Uncertainty Notes - Disfluency frequency appears high throughout the transcript, but without audio, it's uncertain whether the speaker paused smoothly or truly stumbled; only the transcript-level markers are observable. - Title discrepancy: the video title says "Eyal Blum" while the speaker self-introduces as "Alon Blum" — noted as observed, not resolved. # Position Extraction: "How to Get Your Org to Adopt Coding Agents (Without Shipping Garbage)" **Speaker:** Alon Blum (introduced as "Alon Blum"; talk title metadata says "Eyal Blum"), software engineer at Figma. ## Overview - The talk concerns Figma's **internal engineering organization** adopting AI agents, not Figma's product. - Figma has "pivoted very strongly" from a traditional tool to an **AI-first tool** (contextual framing, not the talk's focus). ## The Three-Act Adoption Process (speaker's stated model) 1. **Early wins:** People pick up AI tools, get simple things working "10x faster." 2. **Failure and lost trust:** Applying the same practices to bigger problems; AI "fails pretty badly," produces bugs, trust breaks down. 3. **Real skill:** Learning guardrails, prompting, and context to build at scale. - Adoption within Figma is **uneven**: some teams are fully AI-forward; others are still in earlier acts or have lost confidence — and all must coexist and ship together. ## Friction Points Observed at Figma - **Reduced developer agency:** Engineers lose job satisfaction as coding/flow state shifts to a prompt-and-wait cycle; some are getting burned out. - **Best engineers as bottlenecks:** Engineers holding the most context in their heads absorb the burden of patching agent failures ("mental duct tape"). Blum claims they become bottlenecks, frustrated, and are the **slowest to adopt** because they see problems firsthand. - **Communication inflation:** Design docs, Slack messages, and emails have become 3–4x longer and 2–3x more numerous while conveying roughly the same content; quality markers are harder to navigate. ## Lessons / Recommendations ### 1. Invest in verification - Verification investment is "probably the highest value thing" in the codebase; shift work from humans to agents (e.g., Playwright + MCP letting agents explore code instead of humans). - Encode agent-discovered useful steps into **deterministic flows** — saves tokens and time. - **TDD-style prompting** (red-green-red-green) "almost always" beats writing code then tests, because the latter fits tests to code rather than code to verification criteria. - Apply the classic testing pyramid: push as much as possible down to linting, compilers, unit tests; agents can review against encoded architectural standards; reserve **human review** for functionality and "is this the right thing to build." ### 2. Planning over prompting - Writing detailed plans restores developer agency and the "joy of building." Not uncommon to spend a week on a plan, iterate, get teammate review, then hand to the agent. - **Good plan attributes:** a "why" / executive summary at the top (prevents agent drift — and don't let the agent change it); break into small parts each independently verifiable; personal sizing heuristic: if reviewing the corresponding PR needs "a cup of coffee first," it's too big; include a validation gate/exception criterion per phase. - Once planned, any loop/workflow can implement it; sub-agents can work on phases independently. - **Claimed result:** ~20 PRs (roughly 10–100 lines each), from two plans; roughly "six weeks of coding work" done in one week including review — Blum's stated basis for "5x speed up." - On standardization: diminishing returns in centralizing everyone on one workflow; letting people build what works for them, as long as others can iterate with them, "generally works very well." ### 3. Bring skeptics in - Skeptics see where validation is lacking and tools fail; their feedback is "basically the roadmap" for improving agent interaction with the codebase. Put them in charge of that roadmap rather than pushing them to use AI. ### 4. Attention-aware communication - Human attention is the scarce resource in the AI age. - **Mark AI-generated vs. human-written content** so readers know expected "slop" levels and where to focus. - Team practice: every PR description starts with a short hand-written summary; AI description follows below it. - Anecdote: Blum sent senior AI-skeptic engineers AI-generated analysis of PR comments without labeling; they were upset by the sloppiness. He apologized and learned labeling AI content and stating intention ("this is what I wrote, this is what AI wrote, I need your feedback") is as important as engineering challenges. ### 5. Meet people where they are - Letting people use AI for everyday tasks normalizes use and reduces friction. - Most powerful concrete tactic: tagging an agent in a Slack thread with a colleague ("let's see if the agent can get it this time" — non-passive-aggressively) and letting the agent close the loop; a good experience encourages independent adoption. ## Qualifications and Unresolved Tensions - Blum explicitly frames this as a **journey not concluded**: "We have not come out through the other end." - Figma's automation story is "not fully there yet"; still figuring out how to use cloud agents effectively given dependencies in "bell system" (transcript garble; likely "build system") — unresolved. - Uneven adoption across teams remains an open coexistence problem. - Speaker's closing claim: over 15 years in Silicon Valley, this is "the biggest change by orders of magnitude" in culture and technology he has seen. ## Contradiction / Ambiguity Notes - Speaker introduces himself as **Alon Blum**, while the talk title lists **Eyal Blum** — recorded as-is per source. - Quantitative claims (5x speedup, six weeks of work in one week, "two plans not one") are speaker self-reports with acknowledged imprecision, not independently verified. # Speaker Attribution Record ## Video **Title:** How to Get Your Org to Adopt Coding Agents (Without Shipping Garbage) — Eyal Blum, Figma ## Speakers | Speaker | Role | Evidence | |---|---|---| | Presenter (introduced as "Alon Blum"; title metadata says "Eyal Blum") | **Creator / Presenter** — sole speaker | Opens: *"My name is Alon Blum. I am a software engineer at Figma."* | | Audience | Non-speaking (applause at end) | `>> [applause]` | > ⚠️ **Name discrepancy:** the transcript self-introduction says "Alon Blum" while the video title metadata says "Eyal Blum." Identity is uncertain; role (Figma software engineer, presenter) is consistent. No guests, narrators, or other identified speakers appear. ## Roles Referenced (not speaking) - **Figma engineering organization** — internal teams, AI-forward and skeptical teams described as adoption examples. - **Senior engineers / skeptics** — anecdotal feedback sources ("they got very upset..."). - **Other conference speakers** — presenter references prior talks ("a lot of the speakers here have touched upon this"); no individuals named. ## Provenance & Source Facts - All claims are **first-person internal anecdotes** from Figma; no external sources, citations, or third-party claims are named. - Tools mentioned: **Playwright, MCP, Slack, cloud agents** — referenced as workflow context, not promotional endorsements. - One slide reference: *"This is a screenshot that I randomly picked up a plan"* — internal artifact, not a third-party source. ## Promotional Segments - Brief employer framing: *"Figma has pivoted very strongly from being a traditional tool to an AI-first tool"* — presenter explicitly disclaims product promotion: *"in this talk, I'm not going to talk about our product."* - No other promotional segments detected. ## Availability Limits - **No curated metadata supplied** beyond the title. - **Comment availability:** unknown / not recorded. - Speaker's precise name remains **uncertain** due to transcript-vs-title mismatch. \>\> Good afternoon. My name is Alon Blum. I am a software engineer at Figma. And in my talk today, we're going to talk about how we've adopted or are adopting agent into our workflow at Figma while maintaining high quality for our code base. So, as you may know, Figma is the browser-based editor where design and engineering and now AI agent collaborate together to ship code. Uh this Figma has pivoted very strongly from being a traditional tool to an AI-first tool. But in this talk, I'm not going to talk about our product. I'm going to talk more about our internal organization and how our engineering org has been adopting AI agents. Um what we we found internally is both organizations, companies, and individual there's kind of a three-act process of AI adoption. You start with picking up something, whether it was a lot of the people in this room who have been doing using our AI pal and have been using AI for a while and they picked up something and got some simple things to work very well. 10x faster. Then you start applying those same practices to bigger problems and AI fails pretty badly at that, gives you bad stuff, lots of bugs, and the trust that you build breaks down. And then from that point, you start building the real skill, which is learning how to use AI correctly and put the right guardrails and the right prompting and the right context and all the stuff that we've been talking all day about here in all the talks in order to actually build a real scale. And one thing that is happening internally as we we adopted whether teams or individuals the adoption is uneven. We have teams that are very AI forward and have already transformed their entire workflows and then we have teams that are still experimenting in the earlier act and or have lost confidence and they all need to work together in order to ship our product. Um So, they need to coexist in the organization and we need to find a way to support them and while bringing on everybody along for the journey and getting everybody to the third act of the story. Aside from that main friction point, we have also noticed other friction points that happened as we adopt AI. One thing that we've heard a lot from developers and managers have have been noticing is that reduced developer agency causes um engineers to lose some of their job satisfaction. So, if a lot of people used to take a lot of pride and enjoyment in writing code and getting into the flow and a lot of people feel like that's been lost or they're losing a lot of that element and getting into more of a prompt cycle where they just wait on output from AI and then speak to the AI that like not as much fun as they used to have and they're getting burned out. Um we've noticed another interesting thing. It's actually our best engineer, the one that hold all their contacts in their brain. Um they end up getting out of the burden. What ends up happening is they they know where all the pitfalls are. They are like holding together with with like their mental duct tape all the places that agents are not working well and they're preventing all the really bad stuff from coming in or all they they have all the institutional contact that have never written down in their head and they get so much burden and and become bottlenecks and gets really frustrated. So, they actually end up being slowest to adopt because they see all the problem uh first hand. That's another big big issue that we've seen. Um and this one I'm sure everybody can resonate or in Sorry, I'm sure everybody here will resonate. Um that all of a sudden all the design docs and all the Slack messages you know, this the emails have gotten three or four times as long and we've gotten two or three times as many emails and they say basically as much as they did before. So, communication has gotten quite inefficient and some of the markers of like what is high quality and important things versus not so much high quality um has become challenging to navigate. Um so, I'm going to spend uh the next few minutes talking about some of the lessons that we've learned and how we've been trying to apply this. This is a journey. We have not come out through the other end, but we've seen some really interesting progress along a lot of these lines. Um I think this uh a lot of the speakers here have touched upon this, but investing in verification is probably the highest value thing we can do in our code base. Um anytime that we can lift a left shift anything in our workflow from a human needing to do it to an agent being able to verify it. So, for example, when uh Playwright and MCP came out, instead of having humans navigate the code, now the agent can explore the code. That was a big win unlock for productivity in a lot of our team. That's really That's always a a big win for us. The other thing is um it's even better if when you find something that the agent has found to be useful, take the time to take that and encode into a deterministic flow. A deterministic flow that can be easily repeated is saved on tokens, save on time for the and then it also you also know that you're using the the LLM when it needs to reason, but when you have something that is already known and basically can be encoded into a test, spending that time always always pays dividends. Um And another tip, if you tell your scale your agent to write the code that you're writing um like at the red to green to red to green at the TDD style, it almost always gives you better results because you set a goal, then you tell the agent to strive toward that goal, it will almost always give you better results than writing the code and then writing the test afterward because then it will fit the test to the code rather than fit the code to pass the verification criteria. Um this is the testing pyramid that uh can't the classic testing pyramid from the previous uh just when you think about the testing themselves, which you had the end-to-end test and the integration test and the unit test. This is very similar. Move as much as you can down to the deterministic analysis where that's linting, the compiler, um the unit test themselves. Whatever that can come be covered easily, you can have engine agent do reviews on it based on on criteria, so um architectural standards that that have been easily encoded into the code base, you can move into the agent. And then only at the very top you need to have some sort of human review, which is usually around the functionality and this is the right thing to build. That like only leave the human to do what the humans need to actually be involved in. Um Another really important thing is the planning versus prompting. This is really tied into the giving agency back to developers and finding a replacement to the craft of writing code. Um spending a lot of time writing the plan and then sending enough to the agent basically as a as an implementation that can be done automatically is something that we find to really kind of reintroduce the joy of of building back into the process. And so it's not uncommon to spend a week writing a very detailed plan, making all the decisions, flushing it out, iterating, sending it out to teammates to review. And then only when it's ready and you've flushed out all the decision, you can send it to the agent. The agent will um send it back to you when it's implemented. And that that has been really successful also in accelerating and also really restoring some of the joy into the development process. Uh so what makes a good plan? Um really important to start with a why at the top. It really helps preventing agent drift. If you have like a bold big section of kind of like it when you write a design doc, you want to have the executive summary. Put that in there for the agent. Otherwise, they'll start drifting over time and make sure that the agent don't go back and change that because they feel like it. Uh so we start with a why. Make sure that the plan can be broken down into small parts that can each be verified independently. And my personal way of knowing what is a good size would I want to review that the PR that will correspond to that part? If it's going to be too big for me to want to review in one sitting, it's kind of like the test is I'm going to get need to get a cup of coffee before I read this. That means it's too big and I'm going to want to have it broken down into pieces. And then I make sure that each part can be validated independently cuz what I don't want to have is have five stages and then the first one is written but not validated, and then everything else is is built on top of all the assumptions. So, having kind of a validation gate or an exception criteria for each phase really helps and make the plan uh resilient to drift. And all and and there's all kind of technique on how to manage the contacts and doing a a software factory on top of that. But once you have the plan, you can use whatever loop uh you want or whatever workflow you want in order to implement it. Uh this is a screenshot that I randomly picked up a plan, but this is what I usually look for. The executive summary at the top, the phases break it down, and then each one of them I would go into lots of details so that I can just fit it into a sub agent, and the sub agent can independently work on that and not have to worry about it. Um that's that's it. There are other workflows that would work or other structure to the plan. I find that part of the things that great about uh AI workflows is that everybody can set up the thing that works best for them. Oh-oh. No, thank you. Everybody can very easily set up the workflow that work exactly for them for them. So, there's diminishing return in trying to centralize everybody on one thing, but as long as it works for their flow and other people can iterate with them, I find that it generally works very well. And this is just an example kind of a brag of like this is uh could be a result from a plan. Um there are probably 20 PRs here. Some of them would be maybe 10 lines, and some of them would be 100 lines. There's probably nothing bigger than that, and that allows us to This is in the pre-AI world, this plan probably worked in that for a week. I aligned with the other with three other teams for another week on that, and then I just sent it to an agent to implement overnight, and it came back. This is probably from two plans, not one, but it's it's basically six weeks of of coding work just It's um only took 1 week, so that's where I got the 5x speed up. If I include the review cycle at the end that we always have to remember. Um moving on from planning back to the issue that we had with the skeptics and the people who are burdened with the most work, make sure that you bring them in and take their feedback really seriously. They're skeptic because they're seeing the the way you are lacking validation, where your tools fail. So, and their feedback is basically the road map of how to improve your agent interacting with the code base. So, just make sure to bring them in rather than trying to um figure out how to make them use the AI. Just let's have them be in charge of the road map to make AI safe your organization, and they will come along once they see that that the improvement that they're making actually making their life better. Um and as you can see, they'll not be shy about telling you what you need to fix. This is Latin hour sitting with a bunch of people, and this is the result of brainstorms. Um another thing that's been really helpful with my team specifically, and we're working to adopt it in the broader organization as well, is to make sure that you have an attention-aware communication. In the age of AI, human attention is a scarce resource. I think I've heard it for multiple talks, and a lot of people have have come to the same conclusion. You can't get more human attention. So, where you spend your time and what you're reading is really becomes really important. Um so, since it's such a scarce resource, marking what was generated by AI versus what was written by human is really helpful to know how much time you need to spend reading this, and how much slop can you expect in this part of the communication? Um and that can building a new culture around that self-communication that really helps. Um So, for example, um the team that team that I work with, we've decided we always every PR description will start with something like that, something that I wrote by hand. It could be very short that I describe what this is in code and what this is doing. And then the AI description is going to come after that, which is I will probably read it. I will probably edit it to remove uh some wrong things, but they didn't write every line here, so they should be more suspicious and they should pay more attention to what I wrote in the top and they should override it. Things like that in Slack, in email, it's like leaning into the fact that everybody knows that you're using AI to to craft your communication, but just let them share about it, tell them what they should read and what you they should pay less attention to. And I remember early on, maybe like earlier in this year, I tried to I had some senior engineers in our org that had kind of were very much AI skeptic and I tried to reach out to them to see what was the problem, what was going on. I said, "I tried to run an analysis on some of the PR comments that you've run." And obviously I used the AI to do that. And then I didn't distinguish very clearly what I wrote versus what they what AI generated. And they got very upset. They're like, "Why is sending I did not expect somebody um that I respect this much to send me something that's clearly this sloppy." And then like I I took immediately like I apologize. I realize I should have marked it clearly and marked my intention like this is what I wrote. This is what the AI wrote and I need your feedback on that because I don't have the context to know if it is sloppy or not and that's what I'm asking you for, so lesson like that and change the culture is just as important as some the engineering challenges that we've been facing. Um another thing that's really helpful around the adoption is um as you progress through adoption, there's a lot of very fancy tools and a lot of very fancy workflow that we've we've been implementing, but one of the really effective thing is just letting people use the AI where they're at. So, uh it help it really helps normalize uh the use of AI for everyday tasks and it helps reduce the friction. And really one of the most powerful thing is being able to tag an agent in the Slack message with somebody and they can you just do this for me? And have the agents to close the loop in the thread. Um that that's kind of thing is really powerful. And then you can go on top of that and have all this thing automated and do all kind of fancy things, but if you have a new conversation with somebody who's not fully bought in and then you can tag it in a non like non-passive-aggressive way. You can tag it and say, "Let's try to see if the agent can get it this time." And they close the loop and if it's a good experience, that really helps people try it out on their own in other cases. And our journey continues. We're still learning even though we're shipping AI externally, our AI adoption um we're experimenting with with so many things all the time. Our automation story is not uh fully there yet. We're still trying trying to figure out when we should use how we can use cloud agent effectively given all the dependencies we have for some of our bell system. And so we are continuing to learn. It's a culture shift, it's an engineering shift and I don't know about you, but for I've been I've been working in the valley for the last 15 years and this is the biggest change by orders of magnitude of everything that I've seen in term culture and technology. So, um we're all here together and we're all figuring it out and that's that's what I wanted to talk to you today. Thank you. \>\> \[applause\]