AI in the Developer Workflow What’s Actually Working

AI in the Developer Workflow: What’s Actually Working 🔗 **Source:** [AI in the Developer Workflow: What’s Actually Working](https://www.youtube.com/watch?v=xyg67PH_K5g) > [!note]+ Document Notes > tags: [ai-development, developer-workflow, software-engineering] > author: Sentry > source: YouTube > reference: https://www.youtube.com/watch?v=xyg67PH_K5g > date created: 2025-01-13 14:30 > > # 🏷️ Title: AI in the Developer Workflow: What's Actually Working >  ## 🧰 Action Inbox - [H1] Measure AI productivity gains through concrete metrics like code review speed — 52:30 #measurement #productivity - [H2] Implement agent workflows for domain-specific expertise serialization — 40:15 #agents #workflow - [H3] Establish company-wide AI adoption training with tip-of-spear practitioners — 58:45 #training #adoption ## 🧭 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) ### 🔗 References - [Sentry](https://sentry.io) - [Unity](https://unity.com) - [Adobe](https://adobe.com) ## 📝 Summary - A panel discussion featuring CTOs and principal engineers from Sentry, Unity, and Adobe discussing practical AI adoption in enterprise development workflows - Focus on what's actually working vs. hype, with emphasis on individual productivity gains rather than role replacement - Key themes: context loading, debugging assistance, documentation generation, and the transition from individual tinkering to organizational adoption - Concerns include security, code literacy, and maintaining critical thinking as AI tools become more powerful - Bottom line: AI is most effective for smaller, well-defined building blocks rather than large-scale feature development ## 📖 Main Content The discussion centers on how large engineering organizations are successfully integrating AI tools into their development workflows in 2024-2025. The panelists represent different scales: Sentry (~200 engineers), Unity (thousands), and Adobe (40+ year old company with massive codebases). Key successful use cases include using AI for context loading in unfamiliar codebases, debugging assistance, documentation generation, and rapid prototyping. The tools excel at parsing existing code and explaining functionality, significantly reducing the time needed to understand legacy systems. The conversation highlights a maturation from early 2024's "build me an app" approach to more structured, phased implementations focusing on productivity enhancement rather than role replacement. Organizations are moving from individual experimentation to systematic adoption with proper training and measurement. Concerns focus on security implications, maintaining code literacy among developers, and ensuring critical thinking remains central to the development process as AI capabilities expand. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/xyg67PH_K5g?t=0) — [H1] Panel Introduction and Context Setting - Key idea: Discussion focuses on practical AI adoption in enterprise development workflows - Evidence: "We want to focus on this conversation around what's actually working" #### ⏱️ [02:30](https://youtu.be/xyg67PH_K5g?t=150) — [H2] Panelist Backgrounds and Organizations - Key idea: Representatives from different scales of engineering organizations - Evidence: "Sentry is about a 400 person company roughly and we have a core engineering team of about 200" #### ⏱️ [08:45](https://youtu.be/xyg67PH_K5g?t=525) — [H2] Legacy Codebase Challenges with AI - Key idea: AI tools struggle more with older, complex codebases than new projects - Evidence: "It's been interesting trying to figure out how to get AI tools to work for big more legacy code bases versus just the hey I spun up a project two weeks ago" #### ⏱️ [12:15](https://youtu.be/xyg67PH_K5g?t=735) — [H1] Current Adoption Patterns at Organizations - Key idea: Uneven distribution of AI usage with power users and non-adopters - Evidence: "There's definitely that kind of like zero distribution of users... there's that one person that's cost us a lot of money" #### ⏱️ [18:30](https://youtu.be/xyg67PH_K5g?t=1110) — [H1] Unity's Organizational AI Approach - Key idea: Mix of top-down infrastructure investments and bottom-up RFC-driven adoption - Evidence: "When it comes to larger investments, often those are pushed top down... but often like engineers are also encouraged to kind of try different tooling" #### ⏱️ [22:45](https://youtu.be/xyg67PH_K5g?t=1365) — [H2] Adobe's Enterprise-Scale Considerations - Key idea: Large organizations require different approaches due to scale and legacy - Evidence: "Adobe's over 40 years old... AI is kind of interesting because it's going to start pointing around some good and bad engineering decisions" #### ⏱️ [26:00](https://youtu.be/xyg67PH_K5g?t=1560) — [H1] Biggest Misses in AI Adoption - Key idea: Focus on productivity enhancement rather than role replacement - Evidence: "The biggest miss has been setting up a phased approach in terms of what you expect the tool to do" #### ⏱️ [30:15](https://youtu.be/xyg67PH_K5g?t=1815) — [H1] Context Loading as Key Success Pattern - Key idea: AI excels at quickly downloading context about unfamiliar code - Evidence: "The AIs are so good at sort of downloading a bunch of context around a piece of code or an issue quickly" #### ⏱️ [33:45](https://youtu.be/xyg67PH_K5g?t=2025) — [H2] Documentation Generation Success Stories - Key idea: Automatic documentation generation provides immediate, low-risk value - Evidence: "I used cursor to document code bases that were legacy barely documented and did it so quickly" #### ⏱️ [37:20](https://youtu.be/xyg67PH_K5g?t=2240) — [H2] Automating Mundane Development Tasks - Key idea: AI most valuable for boring, repetitive tasks developers don't want to do - Evidence: "One of the main benefits has been automating all the mundane boring stuff that I don't want to do" #### ⏱️ [40:15](https://youtu.be/xyg67PH_K5g?t=2415) — [H1] Agent Workflows and Serialized Expertise - Key idea: AI agents can encode domain knowledge and decision-making processes - Evidence: "You could start serializing domain knowledge expertise where you could have an agent that specializes around your UI framework" #### ⏱️ [45:30](https://youtu.be/xyg67PH_K5g?t=2730) — [H2] Prototyping and Speed to Market - Key idea: AI dramatically accelerates prototyping and product iteration cycles - Evidence: "The ability to do that really quickly and not spend like a month on version one is very exciting" #### ⏱️ [52:30](https://youtu.be/xyg67PH_K5g?t=3150) — [H1] Measuring AI Tool ROI and Adoption - Key idea: Developer productivity measurement remains challenging with traditional metrics failing - Evidence: "Developer productivity is famously hard to measure anyway and I don't think AI tools really changes that much" #### ⏱️ [58:45](https://youtu.be/xyg67PH_K5g?t=3525) — [H1] Organizational Training and Culture Change - Key idea: Companies implementing structured training programs for AI tool adoption - Evidence: "We're doing a like two or three day... all of engineering... people that are the tip of the spear people give some talks" #### ⏱️ [65:15](https://youtu.be/xyg67PH_K5g?t=3915) — [H1] Security and Production Readiness Concerns - Key idea: Major concern is ensuring AI-generated code meets security and compliance standards - Evidence: "Whether it will do it in a way that complies with how you normally write code and whether the code is secure" #### ⏱️ [70:30](https://youtu.be/xyg67PH_K5g?t=4230) — [H1] Code Literacy and Critical Thinking Risks - Key idea: Risk of developers losing ability to critically evaluate AI-generated code - Evidence: "Code literacy and critical thinking... we might not be able to actually fully understand the code that gets produced" ## 📚 References - [Sentry Developer Experience](https://docs.sentry.io/) - [Unity Engineering Blog](https://blog.unity.com/) - [Adobe Developer](https://developer.adobe.com/) - [Cursor AI IDE](https://cursor.sh/) - [Claude Code](https://claude.ai/) ## 🗣️ Paraphrase - Large engineering organizations are transitioning from individual AI experimentation to systematic adoption with structured training and measurement approaches - AI tools are most effective for context loading, debugging, documentation, and mundane task automation rather than large-scale feature development - The key to successful AI adoption is focusing on productivity enhancement through smaller, well-defined building blocks rather than attempting to replace entire roles or processes ## 📰 Newsletter **AI Development Tools: From Hype to Production Reality** Leading engineering organizations at Sentry, Unity, and Adobe are moving beyond AI experimentation to systematic adoption. The key insight? Focus on productivity gains through specific use cases rather than wholesale role replacement. **What's Actually Working:** - Context loading for unfamiliar codebases - Automated documentation generation - Debugging assistance and legacy code exploration - Rapid prototyping and iteration cycles **Implementation Strategy:** Start with low-risk, high-value tasks like documentation before moving to production code generation. Invest in proper training programs and measurement frameworks. **Watch Out For:** Security compliance, maintaining code literacy, and ensuring critical thinking remains central to your development process. Resources: [Sentry Docs](https://docs.sentry.io/), [Unity Developer Hub](https://developers.unity.com/), [Adobe Developer](https://developer.adobe.com/) ## ✅ Action Items #### DevRel - Developer advocacy: Create AI tool adoption success story presentations, track productivity metrics through token usage analysis - Education: Develop workshops on effective AI prompting techniques, legacy codebase context loading strategies - Developer experience: Document AI tool integration patterns, create debugging workflow templates with AI assistance - Developer marketing: Showcase "tip of the spear" practitioners, create content around productivity measurement frameworks - Community management: Facilitate Slack channels for AI tool sharing, moderate discussions on tool effectiveness #### OSPO - Policy & Governance: Establish AI-generated code contribution policies, create security review processes for AI tools - License Compliance: Review AI tool training data licenses, establish guidelines for AI-assisted code generation - Security Management: Implement security scanning for AI-generated code, create incident response for AI-related vulnerabilities - Software Inventory: Track AI tools in use across organization, maintain SBOM for AI-assisted development - Developer Support: Provide training on secure AI usage, create consultation framework for AI adoption - Community Engagement: Share AI adoption best practices with upstream communities, establish cross-organization learning groups #### Community - Maintainers: Develop guidelines for AI-assisted contributions, create templates for AI-generated documentation - Contributors: Establish onboarding programs incorporating AI tools, create mentorship for AI-assisted development - Sponsors: Create transparent budgets for AI tool procurement, develop impact reports for AI productivity gains #### WordPress - Core: Establish AI-assisted development guidelines, create performance budgets for AI-generated features - Core Performance: Use AI for profiling analysis, automate performance regression detection - Documentation: Generate API documentation with AI assistance, create interactive code examples - Support: Implement AI-powered issue triage, develop automated response systems for common problems - CLI: Use AI to generate command scaffolding, create interactive help systems #### The WPCC - Programs: Create AI literacy fellowships, fund microgrants for AI tool experimentation - Projects: Support governance clinics for AI adoption, fund documentation sprints using AI assistance #### FAIR - Technical independence: Ensure AI tools don't create vendor lock-in, maintain provenance tracking for AI-generated code - Policies: Develop transparent policies for AI tool funding, create anti-capture mechanisms for AI vendor relationships ## 🧪 Hypotheses - Organizations with better test suites will achieve higher AI adoption rates in production code generation - AI tool effectiveness correlates inversely with codebase age and complexity - Companies implementing structured AI training programs will see more uniform productivity gains across teams - Agent-based AI workflows will become standard for domain-specific expertise serialization within 2 years ### 📊 Methodology - Survey engineering teams before and after AI tool adoption measuring specific productivity metrics - A/B test different AI training approaches across similar engineering teams - Longitudinal study tracking code quality metrics for AI-assisted vs traditional development - Case study analysis of AI adoption patterns across different organization sizes ### ❓ Questions - How can organizations measure AI productivity gains without relying on flawed metrics like lines of code? - What security frameworks are needed for AI-generated code in production environments? - How do we maintain developer critical thinking skills as AI tools become more capable? ### 🔮 Future Research - Development of standardized AI productivity measurement frameworks for enterprise environments - Security analysis of AI-generated code patterns and vulnerability detection methods - Long-term impact studies on developer skill retention with heavy AI tool usage ### 💡 Implications - Practice: Shift from "build me X" to structured, phased AI integration focusing on specific productivity gains - Policy: Need for new governance frameworks around AI tool procurement and security compliance - Security: Critical importance of maintaining security review processes for AI-generated code - Education: Organizations must invest in structured AI literacy training programs - Funding: Budget allocation should prioritize AI tools with measurable productivity impacts over experimental technologies ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Panel discussion format with clear speaker identification - Improve: Add organizational charts, AI adoption timeline graphics, productivity measurement dashboards #### 🔊 Aural learners - Present: Full audio discussion with natural conversation flow - Improve: Add chapter markers, create audio summaries of key takeaways #### 🗣️ Verbal learners - Present: Rich analogies about AI as "context downloaders", clear definitions of technical terms - Improve: Create glossary of AI development terms, add more concrete examples #### 🧩 Kinesthetic learners - Present: Discussion of hands-on tool trials, practical implementation steps - Improve: Create hands-on labs for AI tool evaluation, step-by-step adoption checklists #### 🧠 Logical learners - Present: Structured discussion of organizational approaches, clear cause-effect relationships - Improve: Add decision trees for tool selection, create measurement frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Panel format encouraging multiple perspectives, community-driven tool evaluation - Improve: Create discussion guides for team AI adoption planning, peer review frameworks #### 🧘‍♀️ Solitary learners - Present: Individual success stories, self-directed tool exploration encouraged - Improve: Add reflection questions for personal AI adoption journey, self-assessment tools #### 🌿 Naturalistic learners - Present: Organic conversation flow, ecosystem thinking about tool interactions - Improve: Connect AI adoption to broader technology evolution, sustainability considerations ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear speaker identification and context changes - Improve: Add time-based navigation markers, detailed speaker descriptions #### Keyboard navigation - Present: Standard video controls available - Improve: Add keyboard shortcuts for section navigation, ensure all interactive elements are accessible #### Contrast and readability - Present: Video format with clear audio - Improve: Provide high-contrast transcript options, ensure subtitle readability #### Text resizing and reflow - Present: Scalable video player --- ## Full Transcript [00:00] Hello everyone. My name is Cody [00:02] Darkland. I look after developer [00:03] experience of Century. Uh we're pretty [00:05] excited for this one. Uh we're going to [00:07] jump into a pretty cool AI conversation [00:10] with some some new friends uh and talk a [00:13] little bit about how AI has changed the [00:15] way that they're they're working inside [00:17] of inside of their organizations. So, in [00:19] about a moment here, we'll go ahead and [00:21] get started. Uh just a couple of quick [00:23] uh quick housekeeping items. This is [00:25] going to be recorded, so you can come [00:27] back and watch this later if you want [00:29] to. Again, I'm I'm from Century. I'm [00:31] joined by Dave Rosenthal. We'll do a [00:33] little intro for for him and and the [00:35] rest of people in a moment. Uh we're [00:37] gonna we're going to guide through this [00:38] conversation a little bit and talk about [00:41] uh AI and the developer workflow. Uh we [00:44] want to focus on this conversation [00:45] around like what's actually working. you [00:47] know, like I think last year was a [00:48] pretty big year and a lot of stuff [00:50] changed and so we really want to uh kind [00:52] of capture all of that and start to look [00:53] forward and start to see like as larger [00:56] organizations start to adopt all this, [00:58] how do things how do things start to [00:59] shift. So pretty excited for that. Like [01:01] I said, it's going to be recorded, so if [01:03] you have to bail halfway through or [01:04] midway through, you can definitely do [01:05] that. Come back and watch it. Uh we have [01:08] people in the Q&A from my team who are [01:11] willing to answer questions. So, if [01:13] anything uh anything pops up that you [01:15] want uh specific information on, feel [01:17] free to ask uh and we will do our best [01:19] to to answer those answer those live. [01:24] So, we're about a minute in. So, we'll [01:26] go ahead and uh we'll kick this off [01:28] because we do have a a pretty [01:29] action-packed agenda to get through. Uh [01:32] so, I want to make sure we have enough [01:33] time to cover everything. Like I said, [01:34] my name is uh Codyland. I look after [01:37] developer experience at Century. So what [01:39] that actually translates down to is [01:41] finding the the hard parts of of getting [01:43] software up and running and helping [01:44] people helping people fix those uh [01:46] whether it's inside a century or inside [01:48] of their platform. So it's a pretty cool [01:50] gig. Uh love love to do it. I've been [01:52] here about a year. Uh but a lot of my [01:53] background is in both startups and I [01:55] spent about 10 years in a major utility [01:58] doing everything from software to to [02:00] infrastructure automation. So no no [02:02] stranger to to large and small [02:04] organizations. Uh Dave, love for you to [02:07] for you to kick us off. Tell us tell us [02:09] a little bit about you at Sentry. [02:10] >> Uh yeah, thanks Cody. Um I've I'm the [02:13] CTO at Sentry. I joined Sentry a couple [02:15] of years ago after a career mostly [02:17] mostly starting companies and running [02:19] startups. So uh I've worked with sort of [02:21] teams of all sizes from you know us in a [02:23] garage up to big teams. So uh it's [02:25] exciting to be at Sentry and kind of uh [02:28] working to build a tool used by so many [02:30] developers as this kind of era of AI [02:33] hits us. It's uh kind of crazy times. [02:37] >> Awesome. Uh Yona, you want to take us [02:39] away too? [02:40] >> Yeah, perfect. Thanks. So, my name is [02:41] Yona Roco. Currently working as a [02:43] principal engineer at Unity. Uh been [02:45] doing software engineering for about 15 [02:47] years or so. Uh been at Unity. Well, I [02:50] was there for seven years earlier and [02:51] then I took two years uh working in [02:53] generative AI companies. Uh and then I [02:56] very recently returned back to Unity. [02:58] So, I guess uh back back in where we've [03:00] started, right? And uh I've done like [03:02] management kind of roles uh VP of [03:04] engineering roles and then uh but most [03:06] of my career I've spent as an IC just [03:08] overseeing larger architectures and so [03:09] forth. So yeah, that's kind of my [03:11] wheelhouse. [03:14] >> Awesome. Jose, what about you? [03:16] >> Uh hi Jose. Um I'm a principal scientist [03:20] at Adobe. I've been at at Adobe a little [03:22] bit over three years. Uh before Adobe I [03:25] worked at Twitter uh in Google primarily [03:28] focus also like Jonas SNIC [03:31] uh and on basically building uh [03:34] consumerfacing product and features. [03:39] >> Awesome. Well really excited for [03:41] everybody. I think what's really cool [03:42] about this group is we have a bunch of [03:43] different kind of representations of [03:45] company size. Uh and so I want to unpack [03:48] that a little bit just to give some more [03:49] context around like kind of the lens [03:50] that we're looking at AI theories. I [03:52] think you know when we all talked before [03:53] this call and started planning things [03:55] out we all use AI in different different [03:57] levels but I think things start to [03:59] change a little bit when you look at how [04:01] uh how things are adopted on an [04:03] individual level versus organizations [04:05] that that start using it across across [04:08] different teams and with everything that [04:10] changed in 2025 there was uh there's a [04:12] lot of things that shifted in here and [04:14] so I think this is going to be the year [04:15] where organizations start adopting it a [04:17] lot more uh and I think it's just good [04:19] framing to to think a little bit about [04:21] uh about what teams look like. So, so [04:23] Dave, I'd love to start off with you and [04:25] take a little bit of a step back uh as [04:27] far as like hosting this. Talk to me a [04:29] little bit about like Century as an [04:31] organization, our size, and kind of your [04:34] lens on the way we're using AI and [04:36] building with it. [04:37] >> Yeah, I mean, I feel like there's a [04:38] couple things here that are that are [04:40] relevant. One is team size and how many [04:42] people are contributing to some project. [04:43] Probably the other is like the age of [04:44] the codebase. Uh they probably go hand [04:47] inand, you know what I mean? But um [04:49] Sentry is about a 400 person company [04:51] roughly and we have a core engineering [04:53] team of about 200 that's you know [04:56] dedicated to you know whatever slinging [04:58] code and working on the product all day [04:59] but then we also have a bunch of other [05:01] people within the company that are all [05:02] using AI tools and even like coding up [05:04] little things like our sales team built [05:06] a little tool the other day with claude [05:07] code. So um uh the other thing though is [05:11] Centry's been around for a little while. [05:12] So um you know we have a we have a [05:14] codebase that's probably 10 years old. [05:16] Um and obviously it's newer in places [05:18] but uh it's been interesting trying to [05:20] figure out how to you know get AI tools [05:22] to sort of work for sort of big more [05:24] legacy code bases versus like just the [05:27] you know hey I spun up a project two [05:29] weeks ago and you know uh it it seems to [05:32] be going well and there's not that much [05:34] debt yet. You know what I mean? So um uh [05:36] yeah that's the that's the background [05:38] though for how for the you know the [05:40] environment we're trying to make it work [05:42] in. [05:43] >> Totally. Uh awesome. How how are you are [05:46] you feeling good about AI adoption [05:47] internally? Are you feeling like we're [05:49] we're making I think everyone's making [05:50] strides on this. How are you feeling? [05:51] >> I think so. You know um we were just uh [05:53] actually um the the founder of Sentry [05:55] actually just built a tool to help us [05:57] monitor uh adoption across the company [06:00] which was pretty cool because nothing [06:01] really existed. And yeah, I mean there's [06:03] definitely that kind of like ze [06:05] distribution of users, you know what I [06:06] mean? There's that one person that's [06:08] like cost us a lot of money, you know [06:10] what I mean? And maybe we should talk [06:11] about that, right? And then all the way [06:13] down to, you know, there's probably [06:15] like, you know, a third of the team [06:16] that's like, I don't know, touched it [06:18] once or twice, but really hasn't gotten [06:19] into the work their workflows. But I [06:22] think you know the people in our [06:24] organization that are kind of at the tip [06:25] of the spear trying to incorporate you [06:28] know cloud code cursor all of these [06:30] tools into their daily workflows. I mean [06:33] they're starting to get what I would [06:35] call some like major wins you know of [06:38] being able to oh wow that that really [06:40] got built fast. You know what I mean? Or [06:42] that was a two-year-old bug that you [06:45] know we've kind of been putting off. it [06:47] was in the backlog and somebody just [06:48] like speed ran fixing it like in 20 [06:51] minutes, you know what I mean? And so, [06:53] uh, we're, you know, this is probably a [06:56] year for us where we really make a [06:58] concerted effort to to kind of like help [07:01] train everybody up on the workflows that [07:04] are working and that are starting to [07:05] get, you know, success in the company. [07:07] So, um, we're hoping for adoption that, [07:10] you know, is a little bit more uniform [07:11] probably in 2026. [07:14] um maybe both on the low end and the [07:15] high end [07:17] now that like I think it's an [07:19] interesting thing like obviously century [07:20] being very much like a a developer tool [07:22] software company uh I want to talk to [07:24] you a little bit about unity like this [07:26] is a very different different [07:27] organization a different kind of [07:28] engineering maybe maybe it's really [07:30] maybe it's really not at the end of the [07:31] day you know tell me a little bit about [07:32] how uh organization size overall of [07:35] unity obviously thousands of employees [07:37] let's talk about like how how is the [07:38] engineering team structured how is AI [07:40] adoption looking for you guys how are [07:42] you looking at it Yeah. Uh we have like [07:44] two larger engineering organizations. [07:46] One is more focused on the editor which [07:48] is the gaming engine itself and then we [07:50] have another another one working on [07:51] services and ads. Uh so that's kind of [07:53] how we're organized. Uh beyond that like [07:56] engineering organization sits separately [07:58] from the product and design [07:59] organization. Uh but we basically make [08:01] cross functional parts out of the out of [08:03] the uh the the teams right. Um beyond [08:06] that I think like we used to be way more [08:09] hierarchical before. Um and I think like [08:11] we are focusing more on like just having [08:13] a lot of talent but recently we've been [08:15] focusing on having more senior talent [08:16] and then using AI tools to actually have [08:19] high uh productivity in a sense right um [08:23] what else can I say I think uh beyond [08:25] that I think we have a lot of technical [08:27] like more senior principal engineers at [08:29] the company as well and we are expected [08:31] to kind of crisscross and applesauce [08:33] across the different organizations uh [08:34] within the company to kind of connect [08:36] the dots and be be that connectivity [08:38] issue as well. So that's kind of how we [08:40] organized. Um I guess in terms of the [08:42] the AI adoption in general, I think [08:44] there's like both top down and kind of [08:46] bottoms up approaches. So when it comes [08:48] to and then in infrastructure tooling [08:50] and stuff in general, um when it comes [08:52] to like larger investments, often those [08:55] are pushed top down. Let's say what is [08:57] infrastructure provider. So if it if [08:58] we're discussing kind of like [09:00] investments in the order of millions, [09:01] usually that gets pushed down top down. [09:03] But often like engineers are also [09:05] encouraged to kind of uh try different [09:07] tooling and then if they like it for [09:08] example write an RFC more senior [09:11] principal engineers will then take that [09:12] those ideas and sponsor them to get them [09:14] pushed up uh to procurement and uh [09:17] eventually to use at a wider company [09:19] level. So that's I guess a brief desript [09:22] uh description. [09:24] I like it. Jose bring us home. Tell us a [09:26] little bit about about organization size [09:28] at at Adobe. Uh what you're what you're [09:31] working on, how you guys are looking at [09:32] it. [09:33] Yeah. So I think uh obviously I think uh [09:36] we're quite different than than than [09:39] some of these uh given that Adobe's over [09:42] 40 years old um now. So the the way that [09:46] the organization is broken down uh [09:49] really comes down to the product. Um and [09:52] those then tend to be very big. Uh so [09:55] for example I work on Acrobat and you [09:57] have the native versus the web app uh in [10:00] mobile apps and so these things um tend [10:03] to have very massive groups uh in terms [10:06] of who's working on on the features. Um, [10:09] you know, as with the legacy code base, [10:12] um, you know, I think Dave touched up on [10:14] some of this is it's um, I think AI is [10:17] kind of interesting because it's going [10:19] to start pointing uh, around some good [10:22] and bad engineering decisions that [10:24] you've made in terms of how you [10:25] structure code. Um, I think if you write [10:28] something new today, it's probably going [10:31] to be really good with AI because it [10:33] could basically start in a green field [10:36] uh kind of way versus something that is [10:39] decades old and has some uh not uh [10:44] current uh decision making uh in in its [10:48] history and then AI will struggle with [10:50] that. Um so you know in terms of like [10:53] where we are um I think we spent a lot [10:55] of last year uh on kind of what I would [10:58] like to think on like individualistic uh [11:01] tinkering with AI meaning everybody got [11:04] tools and then people did stuff with it [11:08] and now we're asking what stuff did you [11:10] do is it actually productive can we now [11:13] discuss how we scale that and so a lot [11:16] of the um time that we're going to spend [11:19] in 2026 is going to be around saying [11:23] well let's try to scale the things that [11:26] actually make people productive and [11:29] defining uh what is productivity how we [11:32] measure it and make it consistent and so [11:35] I think we're kind of at the beginning [11:37] of that um you know I think century is [11:40] actually part of like what I'm going to [11:43] be using um to roll some of these things [11:46] out uh but you know I think uh how we [11:50] roll out uh really depends on the age [11:53] and the size of the codebase that you [11:56] have. [11:57] >> You know, I think you you kind of led us [11:59] into sort of what I I would say like the [12:01] next the next section of this and we [12:02] talk a little bit about like the tools [12:04] that we all use and the ways that we [12:05] adopt things. I think what was really [12:07] interesting to me about the last year [12:09] is, you know, we've seen this gradual [12:11] like growth of the capabilities of AI [12:14] overall, but I think there's a a really [12:16] noticeable improvement, especially in [12:18] like the second half of 2025 where the [12:20] tools kind of went into overdrive and we [12:22] saw, you know, Codeex came out from [12:24] OpenAI and made made a pretty big [12:26] splash. We saw cloud code start getting [12:28] people to rethink how they actually like [12:29] build software and like kind of the [12:31] return of like the the CLI based coding [12:33] coding approach. Cursor had some some [12:36] big gains. The models themselves change. [12:37] Codex for as a model got better. We had [12:40] Opus 45 drop. We had Composer from [12:43] Cursor and then and then integrations [12:45] inside of there. And so there's been a [12:47] lot of like change there, but the [12:48] downstream of that is also really [12:49] interesting. I'm sure Adobe's had [12:51] changes in how and how AI is integrated [12:53] inside of its products. we've watched [12:56] not not to make this an entire Century [12:58] show, but like the amount of [12:59] capabilities we've added into into [13:01] Century from like a CER standpoint and [13:03] how we how we debug has has rapidly [13:05] changed as those models have changed. [13:08] And so I think it's like it's really [13:08] interesting to think through like how [13:10] the tool functionality growth has really [13:13] like impacted the way uh the way that we [13:16] all build software and the way we all we [13:18] all use these tools. Uh, but on like the [13:22] negative of that, I'd love to talk [13:23] through like some of the kind of missed [13:25] opportunities or the biggest miss that [13:27] we all experienced like using AI and [13:29] things that kind of went wrong along the [13:31] way that we're hoping to watch out for [13:32] as we cruise into 2026. Uh, love, we'll [13:36] start off with uh with Jose on that one [13:37] because you had some good insights just [13:38] now on on some areas. We'll start off [13:40] with you and we'll move through and [13:42] everyone should feel free to jump in as [13:43] much as they want. It's these [13:44] conversations are always great when [13:46] everyone jumps in. So feel free to take [13:47] it away, Jose, and we'll see where I [13:48] where I jump in. [13:50] >> Yeah. So I think in in terms of uh I [13:53] wouldn't necessarily say misses, but [13:55] it's uh a little bit of structure. Um I [13:58] think a lot of people um I think uh [14:02] someone even has a question there around [14:05] writing like robust code using AI. Um I [14:08] think that has been like the biggest [14:09] miss not just in an organization but I [14:14] think a lot of engineers um you know I [14:16] think we you know I've spoken with [14:18] people and they have some kind of [14:20] general bad uh thoughts uh or feedback [14:24] in terms of AI writing uh code and a lot [14:27] of it has to do with write me an app and [14:31] you're providing it completely like no [14:33] structure no context um and so you I [14:37] think when you look at something that is [14:41] a bit of a black box uh such as AI, um I [14:46] think the biggest miss has been setting [14:48] up uh um a phased approach in terms of [14:53] what you expect the tool to do and how [14:55] it contributes to your workflow. Um I [14:58] think everybody's waiting to jump in on [15:00] saying we don't need engineers anymore [15:03] uh or we don't need this role anymore. [15:06] uh versus taking the approach of like [15:08] can we just make these people more [15:09] productive [15:11] um and making that be the focus, right? [15:14] And so part of what I'm going to be [15:17] doing this year is figuring out how we [15:20] measure productivity [15:22] uh measure gains in that language of [15:26] enabling productivity and uh kind of [15:30] compounding the return of investment [15:32] that we make on AI without the focus of [15:35] can you replace a rule can you do that I [15:37] think the the focus has to be hey you [15:40] know I think you mentioned like this bug [15:42] that's been around for two [15:45] someone solved it in 20 minutes. My goal [15:47] is someone did a code review in one [15:49] minute. Uh because that's part of what [15:52] um ironically some of my goals are for [15:55] this year, which is leveraging [15:57] production uh data around errors. Can we [16:00] have AI fix the easy ones? Like I I [16:04] think AI is almost at that point where [16:06] it could say, "Hey, like fix type [16:08] errors, fix these kind of errors that it [16:11] should be able to do. And if it's not [16:12] doing them, then you should say this [16:14] model is horrible. We're not going to [16:16] use that. Right? So like I think we're [16:18] at that point. Uh I don't think we're at [16:20] the point of like Adobee's able to go [16:22] and say, "Hey, build me the new version [16:24] of Photoshop." Like I I don't think [16:27] we're I don't think we're I don't think [16:29] we're there. I don't think we're going [16:30] to be there uh in in quite some time. So [16:34] I think people need to recalibrate, step [16:36] back, and define, hey, there are a 100 [16:40] building blocks, right? But some are [16:42] smaller and some are bigger. Let's give [16:44] AI those really small ones because we [16:47] know we could make sure that they're [16:48] good and let's keep people on the bigger [16:51] ones. So, sorry if I kind of went [16:53] around, but I think that that [16:55] calibration of like what is expected and [16:58] what you could depend on has been the [17:00] biggest miss industrywide, I think. [17:03] >> Yeah. You know, I think uh that's a it's [17:04] a really good call. It's really [17:05] interesting too because I think I saw [17:07] this a lot in the first half of the year [17:09] and I think like the first half of the [17:10] year we were all so like enamored by [17:11] like this thing can go and build for us [17:13] and so you just go in and you ask it go [17:15] build thing and then we're shocked when [17:17] it the thing that comes out like roughly [17:19] looks like what we wanted like the UI or [17:21] the component but ultimately is just [17:24] kind of slopped together and it's very [17:26] broken. Like [17:27] >> I think as we got into the latter part [17:29] of the year, people started figuring out [17:30] how to use plan functionality better to [17:32] start scaffolding out ideas a little bit [17:34] more. And I I saw like as we got towards [17:36] the end of the year, we started to focus [17:38] a lot more on how we create better scale [17:40] in individuals. Instead of looking at [17:43] this as how do I go and stand up a [17:44] bunch, it's how do I start orchestrating [17:46] multiple things that I would normally [17:48] normally have to do or normally want to [17:50] do. And so like I'm hopeful as we go [17:51] into 26 2026 like this will be more of a [17:54] focus. I definitely agree like first [17:56] three4s of the year I think either half [17:58] to threequarters of the year was a lot [18:00] of like cool just go build things but [18:03] now we're getting to a place like how do [18:04] I do this a little bit more little bit [18:06] more [18:07] >> you contribute to a big code base right [18:09] like that's [18:09] >> because we all know you can build a [18:11] little prototype I don't know but Jose [18:12] maybe when you said oh you we can't [18:14] build like Photoshop for you I'm like I [18:16] wonder what version of Photoshop AI [18:18] could it could it build Photoshop one [18:19] like maybe that's like a good like test [18:22] we should we should have Photoshop two I [18:24] don't Yeah, it look like [18:27] >> Yeah, I was going to say like the uh I [18:29] think the one of the biggest challenge [18:31] is the fact that like with AI for [18:32] example, yeah, you can get like uh in a [18:34] very quick amount of time you can get [18:35] something that looks like 85 or 90% [18:38] there but actually like code and [18:40] production readiness wise it's probably [18:41] like 20% in and it's almost like creates [18:44] this false expectation to product and [18:46] design and other stakeholders where like [18:48] oh it's felt it was so close but yet [18:50] it's not. So I think like that's been a [18:52] challenge sometimes explaining like you [18:54] can build a prototype very fast but [18:55] actually getting to a production state [18:57] takes a bit longer. [18:59] >> I sorry there's an interesting question [19:02] here about what is the you know use [19:03] cases that have that have uh you know [19:06] been the most powerful. I I mean one [19:08] interesting trend I've seen is sort of [19:10] the AIS are so good at sort of like [19:13] downloading a bunch of context around a [19:16] piece of code or an issue quickly that [19:18] that's that's one of the things where [19:19] I've seen the biggest like productivity [19:21] wins. You know, normally if you were [19:23] going to venture into a part of a [19:25] codebase that maybe you were unfamiliar [19:27] with, I mean like maybe you're a [19:28] principal engineer jumping from place to [19:30] place, you know, and you're like, I [19:31] don't really know this codebase, right? [19:33] Um, you don't have to ask the these [19:35] tools to make code. You can also ask [19:38] them questions about the code and [19:39] they're really good at um, you know, [19:41] just parsing all of that. I think [19:43] debugging is the other side of this that [19:46] like when I think about my all the time [19:47] I've spent coding you know when you're [19:49] building code all the context is loaded [19:51] into your head but oftentimes when you [19:53] have to go debug a problem like the [19:56] first hour of debugging some problem is [19:58] just trying to load all the context [20:00] about who was calling what and what this [20:02] means into your head and then you can [20:04] fix it in like 10 minutes. So often I [20:06] feel like these tools are really [20:08] powerful at just kind of the like [20:10] initial kind of like context download. [20:12] And so um yeah, debugging has been one [20:14] of the things that's been pretty [20:15] powerful I think with with this and you [20:18] know the like I said the two-year-old [20:19] bugs being just kind of like squashed [20:21] quickly. [20:22] >> Yeah. You know, I I I love that because [20:24] I think um something is that I was [20:26] talking to someone earlier today about [20:27] this is [20:29] it shocks me how uh and I think it's as [20:32] plan becomes more powerful and as people [20:34] go through that process a little bit [20:36] more than just running out to build [20:37] something. Um how few people actually go [20:39] in and use this as a tool to learn about [20:42] the thing you're working in. because [20:43] I've used it with like our SDKs [20:44] internally to go and learn a lot about [20:45] like how tracing is wired up inside of [20:47] them and like even aside from just [20:49] century just learning how these things [20:51] work under the hood. Uh it helps inform [20:54] better questions. It helps me think [20:55] better about design of of things that [20:57] I'm building and new software parts that [20:59] I'm putting together. Uh and so I think [21:01] like the query engine of this and again [21:03] getting into like the plan of like how [21:05] do I slow down a little bit? It's still [21:06] going to be faster than going and doing [21:08] it manually regardless, but spending [21:10] that time to go and and plan things out [21:12] is is huge. [21:14] >> Yeah. [21:14] >> Yeah. [21:16] >> Yeah. I think one one of the things I [21:17] wanted to say in terms of like the ROI [21:19] and and use cases um you know I think [21:22] someone put in here some of the stuff [21:24] that we're actually doing. So I wrote um [21:28] and and used cursor to document code [21:30] bases that were legacy barely documented [21:35] uh and did it so quickly and then we [21:37] were able to go in and and review what [21:38] it generated make adjustments uh and [21:41] then what was very interesting is that [21:42] then I said why don't we create a script [21:44] that will automatically update those [21:46] documents when people check in more code [21:48] um and so I think you know not to say [21:52] that this is what you should be doing [21:53] but this is the level of helpful [21:55] fullness that will probably integrate [21:58] into your codebase almost immediately [22:00] because there's almost no reason and [22:02] it's not going to hurt your codebase, [22:04] right? Because it's going to be [22:05] generating markdown files. You're not [22:07] going to have production issues and you [22:09] can start trusting what you build, [22:11] right? Because it's just going to write [22:12] a Python script, generate some markdown, [22:15] and it's going to make you a little bit [22:16] more productive and ironically generate [22:18] data that then your sub agents that you [22:21] generate later could leverage to build [22:23] stuff. So um you know I think uh you [22:26] know somebody's asking about like what [22:28] are some of the steps or things you [22:29] could do is actually defining those [22:31] building blocks that you will need for [22:33] later on and doing them now because if [22:35] you don't it's going to be harder for [22:37] you to go and say hey I want this to now [22:39] build features for me [22:41] >> if you if you can't even just write a [22:43] test or write documentation what are the [22:45] odds that it could actually build a [22:46] feature for you right and so I think [22:48] that those are the things people really [22:49] need to be thinking about. Yeah, I was [22:52] going to add to that Jose as well is [22:54] like the uh you had the example kind of [22:56] creating documentation for code I assume [22:58] APIs and this type of stuff for example [23:00] or or beyond that as well like yesterday [23:02] I had an example where I had a piece of [23:03] code for example it was less [23:05] documentation for engineers but I wanted [23:07] to produce documentation for customers [23:09] on how to run some integration steps [23:11] manually uh like I had basically code [23:13] that basically automates the integration [23:15] but if the user doesn't want to give [23:16] like service account access to us for [23:18] example they can do a bunch of steps [23:19] manually but just looking at the code [23:21] they we were able to like produce kind [23:22] of the the steps on like oh this is what [23:24] you need to do in GCP and X and YZ tool [23:26] that was super useful. Um for me the the [23:29] one of the main benefits has been kind [23:31] of automating all the mundane boring [23:33] stuff that I don't want to do or making [23:35] it faster. So for example, like oh like [23:37] here's my code and like well I want to [23:38] move constants to a constance module and [23:40] I want to extract these utilities into a [23:42] utility module and please see if there's [23:44] something in the code base that already [23:45] exists that I should be using and then [23:47] voila you get to something much more [23:50] production ready way way faster uh which [23:52] has been really helpful uh but obviously [23:54] like we didn't talk about feature [23:55] generation but obviously these tools are [23:57] very good for just generating new [23:59] features as well. I think where it [24:00] usually stumbles is kind of the uh if [24:03] you have a large code base and a lot of [24:05] like bespoke logic, it will get lost and [24:08] start making mistakes and then you [24:10] probably have to start reading the code [24:11] yourself anyway. [24:13] >> Yeah, D, I want to throw a little bit of [24:14] a curveball question at at you and [24:16] thinking about like somebody who who [24:19] runs a number of engineering teams, has [24:20] a pretty sizable engineering [24:22] organization yourself. uh when somebody [24:24] talks about a way that they're using AI, [24:26] what's one of those that really excites [24:28] you? Like as a as a leader when you hear [24:29] like somebody says, "Oh, I used it in [24:31] this way to do this thing, what's one [24:33] that really like you're like, man, that [24:35] that's a really I'm excited to hear [24:36] you're actually doing it that way." Like [24:38] tell me about one of those. [24:39] >> Yeah, I mean I I guess I just get [24:41] excited when people get excited, right? [24:43] But um you know, it's possible the other [24:46] day that I somebody who I won't name was [24:48] like, I don't think I'll ever write [24:49] documentation again. Do you know what I [24:51] mean? after trying to build some [24:53] documentation with uh with AI. So um no [24:57] I mean I I think also I get excited when [25:00] people can um you know sort of speed [25:02] running speedrun the prototyping part of [25:05] um of the process because a as you know [25:09] Cody like I mean a lot of a lot of [25:11] startups and smaller companies [25:12] especially are are struggling I mean [25:14] they're struggling like product market [25:15] fit and uh it's it's kind of there's all [25:19] this like like you know lean startup [25:21] stuff about you know only only build the [25:22] sort of surface area that you need to [25:24] sort of first get it in front of [25:26] customers and then figure out what [25:27] buttons they're going to click on and [25:28] build those buttons, right? Um uh even [25:31] our design team which might have done [25:33] something in the past in Figma as a [25:35] draft is like now just like working with [25:37] an engineering team or themselves even [25:39] just like mock you know building a [25:41] really quick prototype of something to [25:43] figure out how some interactions will [25:44] work. So um a lot of times you know at [25:47] Century we're trying to build new things [25:48] and iterate on product market fit which [25:50] you know might not be as relevant for [25:52] like a big established company but uh [25:54] the ability to do that really quickly [25:56] and not spend like a month on version [25:58] one uh is is very exciting to me. Yeah, [26:01] I to I think like the you mentioned the [26:05] example of design team basically using [26:06] AI for creating prototypes and stuff [26:08] like not at Unity but the one of the [26:11] startups that I work with like the the [26:12] product management was essentially using [26:14] like I think lovable or cloud code or [26:17] something like that to basically build [26:18] the prototypes for the features that [26:19] they features that they wanted and then [26:21] they would uh do like a voiceover video [26:24] narration for example talking about the [26:26] features and then um based on the [26:29] narration and the feature and the video [26:31] and everything. It basically created a [26:32] PRD with the requirements and stuff for [26:34] the engineering to basically take on [26:35] kind of like okay please go and execute [26:37] this vision that I have in mind and I [26:39] think that was pretty like really cool [26:40] use of AI that I saw myself. Obviously [26:43] downsides there as well is like [26:44] sometimes some of these tools that were [26:46] built by product management were taken [26:48] into production use directly and then [26:51] some bigger holes in security wise but [26:54] like at the same time productivity [26:55] productivity wise it was very useful. [26:58] L luckily local host is not accessible [27:00] everywhere. So uh uh I think for for me [27:04] uh in terms of what excites me um just [27:07] to get a little bit more technical is uh [27:10] kind of the uh rapid iteration and [27:13] adoption of agents. Um I think uh when [27:17] you go back to last year uh you know [27:20] before summer um that really wasn't part [27:23] of the vocabulary when it came to what [27:26] we were doing. uh and it's a large part [27:29] of what we're going to be doing this [27:30] year. And what excites me about it is [27:34] that it, you know, in terms of AI, uh a [27:37] lot of things have been very similarly [27:39] done, meaning you're talking to OpenAI, [27:42] you're talking to claw, you're doing [27:44] this, and it does that for you, right? [27:46] Um the new uh Agent workflows allow you [27:49] to define and serialize um uh decision [27:55] making and expertise [27:57] um and potentially disseminate that [27:59] across teams and I think that that's the [28:02] part that gets me a little bit excited [28:04] because you could imagine that you know [28:07] and I think we'll discover whether this [28:09] is good or bad but you could start [28:12] serializing domain knowledge expertise [28:15] where you could have an agent that [28:16] specializes around your UI framework, [28:19] one that specializes around security, [28:22] and then when you're making a change or [28:25] you're writing a feature, you could tell [28:27] these agents, hey, check this out. And [28:30] when this person is done, you review it. [28:32] And when they're done, you review it. [28:34] And it kind of goes into the whole like [28:37] if you tell AI to do something 10 times, [28:39] eventually we'll get it right. But if [28:41] you could compound that with the [28:44] different uh kind of hats that a team [28:47] would have uh with the ability to kind [28:50] of serialize some of that, I think it [28:52] starts becoming a little bit powerful. [28:54] Um but again, it goes back to you the [28:58] way to compound it is to define building [29:00] blocks that actually add value and not [29:02] detract value. [29:04] >> Are you doing this today or is this like [29:06] more specul speculative in terms of what [29:08] would be useful in the future? [29:10] So we're starting to view some of that [29:12] today. Um you know I think the the [29:15] analysis that we're trying to do uh is [29:18] around which flavor we want to do. So um [29:21] you know claw is very tied to this kind [29:25] of CLI runtime aspect versus cursor [29:29] allows you to define it in a way that's [29:31] actually more friendly to run in the [29:33] IDE. They become kind of more like [29:34] scripts that you could run. Um, and so [29:38] they kind of work a little bit [29:39] different. Uh, but they all have their [29:42] own advantages. There are no [29:43] disadvantages. And so, um, again, it [29:47] part of what I'm trying to do is figure [29:50] out how that becomes productive as a [29:54] team in our organization and how we set [29:56] up the part where we continuously [29:58] serialize what you learn, right? Because [30:01] that's that gets that's basically what [30:03] gets lost right now. If I create an [30:05] agent and we deploy it [30:06] >> and that agent runs for one month, but [30:09] it never gets updated, [30:11] >> that agent will eventually become [30:12] obsolete, [30:14] >> right? And so that's part of the the [30:17] things that we're looking at on how do [30:20] we improve that or maybe claude and open [30:23] AI will figure that out for us, right? [30:26] But that that's part of the the element [30:28] that I'm hoping we could solve because [30:30] then you could really deploy and scale [30:32] them. I think if they become sca uh [30:34] stale then it makes no no point to [30:37] really deploy them because within a [30:39] couple of months your codebase will [30:41] change your codebase will change so much [30:43] that that original context will become [30:45] obsolete. [30:47] >> Yeah. You know I I think you've all hit [30:49] on something that like I'm I'm pretty [30:51] passionate about. It's like this idea of [30:53] creating like the amount of scale we can [30:55] create in individuals now and the amount [30:57] of things you can have your deep domain [30:59] knowledge in something like a designer [31:01] can be a very very good great designer [31:04] but now they can start to like expand [31:06] their their scope and their like their [31:08] impact radius as far as they want, [31:10] right? Like these these areas are things [31:11] they can dabble and they can prototype [31:12] ideas out. They can bring they can bring [31:15] mock uh real mocks to to their review [31:18] cycles to go and like actually have [31:19] checked out instead of just building [31:21] them out in Figma if they want to, [31:22] right? Like they can go a lot deeper. [31:24] You can have a product manager who's [31:26] also able to go out and prototype the V1 [31:28] of the feature can use AI to pull down [31:31] customer insight stuff. All these things [31:33] can be happening at the same time. You [31:34] can be debugging problems while you're [31:36] building building new features. And I [31:38] think like creating uh better scale in [31:40] individuals is something that's that's [31:41] really exciting. Uh, and that brings me [31:43] to kind of my next thing I want to talk [31:45] a little bit through, and that's when we [31:47] think about like how we pick these tools [31:49] and the ROI we get out of them. I want [31:51] to talk with each of you a little bit [31:52] about this one. This is one I'd love for [31:54] everyone to to answer. Uh, when you [31:56] think of when someone comes up and says, [31:57] "Hey, there's a new tool I want you to [31:59] check out." How do you determine like if [32:01] that was one that was really like worth [32:03] digging further into, you take it for a [32:05] spin and you want to keep using it? like [32:06] what are the things you're looking for [32:08] and the things that you found really [32:10] move the needle for for your [32:11] organization internally both your [32:13] workflow and as you like recommend it to [32:15] your teams and start rolling it out to [32:16] teams. Uh Yona I'd love I'd love to [32:18] start with you. [32:19] >> Sure. Like um I think I'm going to use [32:23] the example from from layer for example. [32:25] So I think what we used to do like when [32:27] we're like looking into different kind [32:28] of tooling is like I wanted people to [32:30] well I gave them the company credit card [32:32] and say go use whatever tooling you can [32:33] find that you think will add value to [32:36] your workflow essentially and I'll give [32:38] you two weeks and then at the end of two [32:39] weeks we'll all get together for a [32:40] couple of hours and I expect everybody [32:42] to give a presentation on the tooling [32:43] that they used. we got get got together [32:46] and then obviously based on the feedback [32:47] then we took another week basically to [32:49] try the tooling that everybody found [32:51] useful and then based on that we like [32:53] basically aligned on like which are the [32:54] ones that we're going to actually [32:55] procure uh so it's not a very [32:58] quantitative quantitative way of [32:59] actually measuring like okay which one [33:01] produced the most value more qualitative [33:03] I guess in this regard uh but then [33:05] obviously I mean that's that's kind of [33:07] how we ended up with some of the tools [33:08] that we used there so uh I think that [33:11] was very useful kind of like a community [33:12] effort in a way [33:14] >> Jose what about too. [33:16] >> Uh yeah, so we can't do that at a [33:19] company this big. Uh so it's a little [33:21] bit more complicated. Um it also depends [33:24] on the on the tool. Um but yeah, a lot [33:27] of it um [33:29] we do have the ability to individually [33:31] analyze certain things, but in terms of [33:35] even pushing for adoption, uh especially [33:37] with AI in particular, um that really [33:39] has to come almost like top down in [33:41] terms of what um we're getting licenses [33:45] for uh because our company is so big. Um [33:48] so, you know, I think you guys know [33:50] that. So, it it works a little bit [33:53] different uh uh for us. So uh but it [33:56] doesn't mean that we can't go and and [33:58] ask for a license or a trial or [34:01] something. In fact, I mean uh we ended [34:04] up uh adopting Sentry was me looking at [34:07] it and working with some of your team um [34:10] uh to do a trial. So we're able to do [34:12] some of that. when it comes to the [34:14] broader roll out and adoption um you [34:17] know uh you you you will go through the [34:20] same process that you would expect a [34:21] 40-year-old company to go through uh in [34:24] terms of procurement. So [34:25] >> yeah know I can 100% empathize with you [34:28] at Unity it's the procurement process [34:30] and going through legal and security [34:31] reviews and all this type of stuff. So [34:33] when you want to use a tool you really [34:35] want to use it because going through the [34:36] process is just like a a pain in the [34:38] ass. [34:39] >> Yeah. you know, we we actually sort of [34:41] started maybe more big company [34:43] conservative on this than you might [34:44] expect. [34:45] >> Um with a little bit like, well, let's [34:47] not do too much. Let's make sure [34:48] everything's approved. But, um I would [34:50] say probably I don't know, maybe even a [34:53] year ago, we we really um realized the [34:56] importance of letting people try out all [34:58] this stuff and went to a much more open [35:01] sort of freewheeling model of like you [35:03] need to spend some money, spend some [35:05] money, let's you know, just get it [35:06] going. [35:07] I think it's it's hard to it is hard to [35:10] measure the impact of all this. I mean [35:11] developer productivity is famously hard [35:13] to measure anyway and I don't think AI [35:16] tools really changes that much. I mean [35:19] if anything some of the traditional like [35:21] bad metrics that you might look at like [35:23] number of PRs and amount of lines of [35:25] code you added. I mean, first of all, we [35:27] all know these are trash already. And we [35:29] all we now know that somebody can like [35:31] add a 100,000 lines of code to a [35:33] codebase like [35:34] >> in a in a in a week. And it I mean, it [35:37] might not be for the better, right? I [35:39] mean, large code bases are liabilities, [35:41] not um not assets in and of themselves. [35:43] So, um but yeah, we've been pretty [35:45] freewheeling lately about letting people [35:46] try out a lot of things. And we just [35:48] have like as coding knows like we have [35:49] like big Slack channels where people [35:51] just kind of talk about like, hey, like [35:53] what's working, what's not. I tried [35:54] this, I tried that. But it is funny to [35:57] me in a way how much everybody kind of [35:59] has their own preferred flavor. [36:01] >> You know, there's certain people that [36:02] are like, "Oh, I think model A is better [36:04] than model B or model B is better than [36:06] model C." And it's definitely not like [36:09] internally consistent about what [36:11] everybody thinks. It's kind of just like [36:13] what's working for you. So, I don't [36:14] know, maybe there'll be some convergence [36:16] over time, but with the rate that the [36:17] models are changing, um, uh, I don't [36:20] know, we don't worry about about that as [36:21] much as sort of just like what are the [36:23] actual methodologies. And that's where I [36:24] think I was really interested to hear [36:26] Jose mention the the idea of trying to [36:27] start running some automations. You know [36:29] what I mean? Where, you know, it's not [36:31] just a ripple, you know, with with a [36:34] developer running one of these tools or [36:36] integrated into an IDE. You're starting [36:38] to get to the point where you're you [36:39] have a behavior and and you know, you [36:41] want it to continuously happen and [36:43] you're trying to figure out how to [36:44] actually automate that. I think we're [36:45] going to see a lot more of that in this [36:46] coming year. [36:48] >> Question to you Dave. you mentioned [36:49] about kind of having a more uniform kind [36:51] of AI adoption across the company in the [36:53] next year or like well this year I guess [36:55] >> yeah this year yeah [36:56] >> this year because it's 2026 but like um [36:58] I was curious like if if you're doing [37:00] anything with your organizations to [37:02] organization to like promote AI use [37:04] because obviously you're tracking if you [37:05] know that there's kind of some [37:07] distribution of AI usage [37:08] >> because like back in the startup for [37:10] example I made it like an evaluation [37:11] criteria in a way where like I'm [37:13] expecting people to use the AI tooling [37:14] for example or try to adopt it because [37:16] we're an AI company and whatnot. Yep. [37:18] >> I'm wondering if you if you guys are [37:20] doing anything in that regard, right? [37:21] >> Yeah, we are. Um, I mean, you know, [37:23] Sentry does an amazing hackathon every [37:26] year. [37:26] >> Um, which already last fall kind of [37:29] like, you know, was definitely [37:31] encouraged to try to, you know, explore [37:33] the AI tools as part of the hackathon. [37:35] But, um, but actually this year, um, [37:38] actually it's your question's timely [37:40] because coming up we're doing a like two [37:42] or three day. I think we're still [37:43] figuring it out, but we're doing like an [37:45] all of engineering. Um, [37:48] >> I don't know. It's not a hackathon [37:49] really because the point isn't hacks, [37:50] right? But it's it's a process where [37:52] we're going to have the people that are [37:53] again the tip of the pier spear people [37:55] give some talks to the organization. [37:57] Teams are going to work together to try [37:59] to do things like I see a lot of [38:01] comments people ask how do you deal with [38:02] blur code bases? You know, these cloud [38:05] MD files or other markdown files. I [38:07] mean, teams are going to work to try to [38:08] put like good signposting into their [38:10] code bases for agents to work with, you [38:13] know, and we're going to do some lessons [38:14] learned there. So, yeah, we have like a [38:16] a drop your pencils, you know, we're [38:18] going to spend a few days working on [38:20] making these tools work well for us. [38:22] It's like an explicit, you know, company [38:24] >> kind of like a combination of educating [38:26] the rest of the folks, but also [38:28] spotlighting desired behaviors like, [38:29] hey, like if you are at the frontier [38:32] basically pushing this tooling and um [38:34] like telling everybody else what to do, [38:36] you get this opportunity to basically [38:37] show your seniority and all this sort of [38:39] stuff, right? [38:40] >> Absolutely. Or or show your juniority [38:42] because sometimes it's the people that [38:44] are, you know, a year out of school that [38:46] have just like jumped into this and like [38:48] figured out how to make it work. So, um [38:50] so that's awesome, too. Yeah, [38:52] >> I think it's like a very positive [38:53] culture like thing about and I think [38:55] like organizations that start leading [38:57] with this like we uh David Kramer the [39:00] co-founder century he he vi coded [39:02] together this tool that looks at like [39:03] token usage takes in all of our billing [39:06] data from the different ones and shows [39:07] like who in the company is like using [39:10] using the most tokens right and the [39:12] questions weren't like god Cody what why [39:15] are you spending this much or you know [39:17] Joe why are you why why are you costing [39:19] so much in tokens it was what like what [39:21] tricks are you guys picking are you guys [39:22] picking up out of this and using? I'm [39:24] like and the amount of calls that came [39:26] out when that uh when that list came out [39:29] of like hey show me how you're show me [39:30] how you're doing this I I want to learn [39:31] more. I think it's like a really like a [39:33] positive inspiration thing like how do [39:35] we how do we teach people how to go and [39:37] use these in like really effective ways [39:38] and and ineffective ways like what are [39:40] some of the ways that have like led you [39:41] down some of the the sc the scary paths [39:44] of like I broke a thing in prod because [39:46] I because I built it this way like how [39:48] do we teach people to avoid that stuff [39:50] and I think it's a it's a really really [39:52] really a really cool thing u but I think [39:55] it does bring us to like another another [39:57] topic as we think about the the upcoming [40:01] here. What are some of the areas that [40:03] you are worried about AI impacting and [40:05] that you you have a little bit more? I [40:06] think we're all pretty leaned forward on [40:08] it. We want to see this grow inside of [40:09] our organizations, but what are areas [40:11] that you are a little scared of or a [40:13] little bit concerned about as as it [40:15] looks at like the development process [40:16] and like areas you want to make sure are [40:19] are treated with a little bit more care [40:21] than just tossing tossing some generated [40:23] code out into it. [40:25] >> I'll start with uh with Jose. [40:29] I think that there are many but I think [40:31] uh primarily is one which is that I [40:34] expect this year to be the year that it [40:37] actually writes code that people want to [40:39] ship into production. But I think the [40:42] area that I foresee being the most [40:46] problematic is whether it will do it in [40:50] in in a way that complies with how you [40:53] normally write code and whether the code [40:56] is secure. Um, I think the, [41:01] you know, being [41:04] in in a position where you're asking [41:08] someone that's not necessarily part of [41:10] your company to write something for your [41:12] company does become a bit of the issue [41:15] here. And so figuring out how to feel [41:19] comfortable with that, but also making [41:21] sure that you have the right checks and [41:23] balances to do that. um it becomes kind [41:27] of the the area not of concern but I [41:31] think it is the challenge that will [41:34] really ultimately define how much more [41:36] productive you could be as an [41:37] organization right so um can you say hey [41:42] stand up a new API endpoint that returns [41:45] X from this table [41:48] um and if it could do that in a way [41:51] where you feel comfortable shipping that [41:53] into production that becomes super [41:55] powerful, right? Can it do that today? I [41:58] would say no. Uh, you know, I think it [42:01] could do some of it and then you have to [42:03] go through and make sure that it has all [42:05] the right things that it would need to [42:06] do. And you know, I think we all work at [42:08] very big companies where you are not [42:10] necessarily looking at a singular [42:12] codebase in terms of how you ship and [42:15] you distribute something. Um, and so I [42:17] think solving those challenges of how [42:20] does a CSP change actually get [42:23] distributed and propagated because it [42:25] might not be in the same codebase but [42:27] you're going to make a change that does [42:29] both. Um, how do you orchestrate that, [42:32] right? And I think that in itself [42:34] becomes the part where I I I don't think [42:37] I'm concerned. I think it just becomes [42:39] the biggest challenge to unlock that [42:42] productivity. And that's why I said [42:43] you're stuck with the smaller building [42:45] blocks that you could manage, but you [42:47] still need all that people power still [42:49] to do everything because you're still [42:51] needing that orchestration layer. [42:54] >> If if I could follow up on that [42:55] actually, um what you know, as as you [42:58] speak to that, it really makes me just [42:59] also think about um test suite quality [43:03] as as a huge driver in how much you can [43:07] you can trust code. And you know I I've [43:09] worked on projects in the past that you [43:11] know have had like no test suites and [43:13] I've worked on projects in the past [43:14] where we spent four years building the [43:16] best possible testing environment in the [43:18] world. And um you know in the latter [43:22] case I remember we used to say like hey [43:24] it would be fine if we had like any [43:27] intern come in on their first day we [43:29] would feel comfortable with them [43:30] committing code to the codebase because [43:32] we know that if they messed it up the [43:34] test suite would fix it right. And so I [43:37] it makes me think in general like what [43:38] are the more and less testable parts of [43:41] a program and I guess I mean there's a [43:44] lot of more nuanced answers but it is [43:46] super high level like UIs are kind of [43:47] like hard to test and like backends are [43:50] kind of easy to test often right because [43:52] there's like a set of like fixed [43:53] properties that you want to hold on a [43:55] backend and so I think if there are like [43:57] you know properties of your system or [43:59] strong test suites that you can have for [44:01] like this API always returns the value [44:03] that we put in it um That are the those [44:06] are the places where I feel like um I'm [44:08] optimistic that we can be a little bit [44:10] more like aggressive with letting AIS [44:14] go, you know, make make that set of [44:16] improvements knowing that we're sort of [44:18] confident in the test suite. Um again, I [44:21] guess like you know, UI testing is sort [44:22] of famously hard to define a a [44:25] correctness criteria for. Um so that's [44:27] hard, but uh that's one of the big [44:30] that's kind of I don't know, one of the [44:31] big sort of optimisms I have, I guess, [44:33] right? is that is that maybe if there's [44:35] a place that where you really can define [44:36] good tests um we'll be able to take a [44:39] lot of steps and execute big plans and [44:42] take big swings at code bases. So [44:44] >> you are where are you worried about [44:47] inside of all this? I think worry is [44:49] probably a strong word in this case [44:51] worry for sure. [44:52] >> Never mind. [44:53] >> Just worry for sure. I think security I [44:55] mean to say security but I'm not going [44:56] to expand on that. I guess the the big [44:58] biggest issue is that you know these AI [45:00] tools don't generally necessarily [45:01] consider too much of the security. [45:03] Sometimes obviously if you use like code [45:05] review tools and stuff it will tell you [45:06] like hey maybe you should have like you [45:07] know protection here for these [45:08] environment variables because otherwise [45:10] you will write stuff into production or [45:11] whatever but uh I think like this is [45:14] more of a existential topic I guess but [45:17] like I'll make it more code specific is [45:18] like code literacy uh and then also [45:20] critical thinking where today we're not [45:24] in a place where I mean most people who [45:26] work in engineering in software have [45:28] reviewed bunch of code they read code [45:30] but there's a new wave of like new wave [45:32] AI engineering essentially where we [45:34] produce goals based on like natural [45:36] language essentially, but we might not [45:38] be able to actually fully understand the [45:40] code that gets produced. Um, and [45:42] especially if you're reviewing [45:43] somebody's else's code, we just rely on [45:45] the AI telling us whether it's correct [45:46] or not without actually having the human [45:49] intervention where the human becomes [45:50] basically a checkbox clicker. It's like [45:53] looks good to me, looks good to me. And [45:54] that's how issues end up in production [45:56] and not necessarily even issues. some [45:58] often issues but in many cases the [46:00] example of Dave like you know we can [46:02] produce 10,000 lines of code but maybe [46:04] no lines of code had to be produced [46:05] because critical thinking wasn't [46:07] actually like employed uh at the right [46:09] place um and I think another thing which [46:12] is relates to this as well is that [46:14] because it becomes ever so easier to add [46:16] features [46:18] we question and less whether those [46:20] features should even be added uh because [46:22] it's just easy to keep adding more and [46:24] more craft and more features uh instead [46:27] of uh thinking like what is actually [46:29] necessary for the product to be good and [46:30] functional. So I think like uh I think [46:32] and then obviously that the existential [46:34] crisis there the extential topic there [46:36] is like this expands to obviously like [46:38] way more into like uh you know writing [46:41] TDDs or writing PRDS or um essentially [46:46] even critical thinking in general uh in [46:48] society. But not not only that is if [46:51] something breaks in production, right, [46:53] and you need to go and jump, who's going [46:55] to be quicker? A human that knows the [46:56] code [46:57] >> or you writing a prompt to AI, right? So [47:00] I I agree with you on that. [47:02] >> Yeah. Yeah. [47:03] >> I worry I worry a lot about curiosity [47:05] atrophy. you know, I think we we can ask [47:07] for things, we get a quick response, but [47:09] um the want to go and like learn how [47:11] this stuff works to to your point, Jose, [47:13] like to learn the codebase and to know [47:15] how for for us like Dave, like how [47:16] century works under the hood, how how [47:18] does ingestion work, how do we move [47:20] things through, how does how to see or [47:22] go and and and debug the things that it [47:24] does, like the want to go and learn that [47:26] stuff gets dep prioritized because it's [47:27] just so easy to go and ask for it to go [47:29] and do do the thing. And so I think [47:31] being really intentional about fostering [47:33] curiosity in people and teaching people [47:34] how to do like the research and plan [47:36] phases and like are is a is a PRD really [47:39] written good and do they really [47:41] understand the PRD or did they generate [47:42] the PRD also which is not the point like [47:45] all of those things. I mean just to be [47:47] contrary though I mean I think the AI [47:49] can be an unbelievable tool for [47:50] curiosity [47:53] being brought into a 1015 year old [47:55] codebase like I mean I would be like [47:57] traditionally you'd be like well it's [47:59] going to be a few years till I kind of [48:00] know my way around but I mean man these [48:02] and I don't want to distract this senior [48:04] engineer who wrote this thing. Do you [48:06] know what I mean? But it's like now you [48:07] can you can kind of dive in and I mean I [48:10] you spend a few days just like like I [48:12] said asking questions. you you don't [48:14] have to be kind of like code adding slop [48:17] to the codebase, you know, you can you [48:18] can just you can uh use these things to [48:20] kind of navigate quickly. And so I kind [48:22] of feel like the people who are [48:23] intrinsically curious have found at [48:26] least in our team I've seen them find [48:27] lots of amazing ways to to figure things [48:30] out and be curious with the tools. [48:31] Another [48:34] in like well this is more of like a [48:36] shower/bet thought which has been like [48:38] daunting me or I've been thinking about [48:40] sometimes uh is kind of like how will [48:42] tech evolve now that AI is in place [48:45] because all of these LLM have been [48:46] trained based on existing material [48:48] that's out there in the internet. So [48:50] let's take I'm taking like an more [48:52] practical example like let's say take [48:54] take React for example. So if you're [48:55] building UI, it's going to be amazing to [48:57] if you're using React and LLMs to [48:59] produce code and so forth because it has [49:00] examples and best practices, [49:02] documentation and everything, but then [49:04] what incentive there is to build another [49:07] framework or build another component [49:08] library because that material doesn't [49:10] exist in the internet. So even if [49:12] practically the tooling would be faster [49:14] or better, there's not enough material [49:16] out there where the the how do you say [49:19] it like the LMS will not produce as [49:21] quality of a code anymore compared to [49:23] like some historical stack for example. [49:25] So I'm wondering like how how that [49:28] bridge will get like crossed eventually. [49:30] Right. [49:30] >> Yeah. If you need a React app with a [49:32] gradient purple, you're good. like right [49:35] and you're gonna we should just never do [49:37] any other gradients now because like [49:39] >> they take an example of this more [49:40] bespoke language like Elm for front end [49:42] for example like you probably like these [49:44] LLMs will not produce great quality code [49:46] when it comes to some very bespoke [49:48] language but in in the future if there's [49:49] some new new developments and stuff how [49:52] will these LLMs actually like um perform [49:56] >> yeah definitely not as well but you know [49:58] I don't know they're making there's been [50:00] some math proofs and stuff and but [50:03] you're right I do think It's harder to [50:04] build a a firstofits-kind thing with an [50:06] LLM. You know what I mean? You need to [50:08] you you'd need a really good plan [50:10] yourself, I think. [50:11] >> Yeah. Yeah. [50:12] >> Yeah. [50:13] >> Well, I want to cruise into a couple of [50:15] Q&As's and then we'll at the we'll close [50:17] out probably the last say three minutes [50:18] with a with a speed round of of [50:20] predictions predictions for next year. [50:22] But we got a lot of questions that have [50:23] come through. I like this one here. I'm [50:25] going to go ahead and just ask it out [50:26] and we'll take a quick again quick [50:28] answers on these so we can get through [50:29] get through a bunch of them. [50:31] We had a uh what should a junior or [50:33] mid-level engineer focus on to amplify [50:35] value? And I think framing this inside [50:37] of like in this world of of AI things [50:39] what what should they focus on? Uh first [50:42] one who wants to jump in on that go for [50:43] it. [50:45] >> I guess I can quickly like say my [50:47] thoughts. I think like get very good at [50:49] prompt engineering and be willing to [50:51] change your uh kind of not opinion but [50:54] kind of your perspective of what can be [50:56] prompted because a lot of the things [50:58] that you could prompt and say a year ago [50:59] you would never get anywhere val like [51:01] anywhere good but today these like [51:03] language models are way more [51:04] performance. So you kind of you can go [51:06] more abstract over time u as these [51:09] language large language models improve. [51:12] >> Um I think for me there there are two [51:14] ways of answering that. So you know [51:16] because the question is around their [51:18] value. So one would be around the value [51:21] they generate uh to the company. So it [51:23] would be to leverage a tool to get [51:26] consistent results and do it better than [51:28] anyone else. And I think junior [51:30] engineers are probably more uh equipped [51:34] to try stuff and know how to do trial [51:36] and error until they get some [51:37] consistency with the prompt. And I think [51:39] that that will really shine right now in [51:41] an organization. I think in terms of [51:43] your own value, um, you want to get [51:46] back, I think, something either Dave or [51:48] Jonah said in terms of like reasoning [51:50] with documents and stuff like that, get [51:52] really good at using AI to figure out [51:54] how the entire codebase works. Uh, you [51:57] know, because I think one of the parts [51:59] that's being lost right now, uh, is once [52:01] you start automating all these other [52:03] things, how do you go from an entry- [52:05] level engineer to a senior engineer if [52:08] you're basically going to be prompting [52:10] away? because in theory everyone could [52:12] be very very curious and you learn but [52:17] can you actually reason the with the [52:18] code base and I think that that would be [52:21] a very key area where you start learning [52:24] you know if you're a front end engineer [52:25] you learn how the APIs actually work and [52:27] why they work that way and so don't want [52:30] to get winded but I think that there are [52:31] two ways of looking at that which is the [52:34] output value and kind of the input value [52:36] to yourself [52:38] >> I'll maybe append very briefly that as [52:40] well to the output value in essence [52:42] right I talk about prompt engineer it's [52:43] very specific skill set you can get good [52:45] at but I think from junior mid level to [52:48] senior or beyond like staff and [52:50] principal levels I think it becomes less [52:51] about the code output and it becomes [52:53] more of this convergence of roles where [52:56] historically we used to have like [52:57] infrastructure engineers database [53:00] engineers backend engineers frontend [53:02] engineers and so forth and even QA right [53:04] and then eventually like a lot of these [53:06] roles got collated into what we now call [53:08] like a full stack engineer right but [53:09] with the use of like AI tools. I think [53:11] like what's happening now there's a lot [53:13] of convergence of fullstack engineer [53:15] design and product into we can call it [53:17] like a product engineer in some regard [53:19] where you're expected to kind of like be [53:21] a product owner part designer and also [53:23] an engineer because now you have all [53:24] these productivity tools. So I think [53:26] another thing that's very important um [53:28] if you want to like ascend the technical [53:30] ranks essentially is like having [53:31] curiosity also towards the product and [53:33] design and the end end goal in mind not [53:36] just the technical side of things. [53:39] Yeah, I won't add too much. I mean, I [53:41] think with the AI slant, just to kind of [53:43] sum sum up some of what these guys said, [53:45] like I think, you know, when you use [53:48] some of these tools that they'll they'll [53:49] do a plan and then they'll write the [53:51] code. Figure out how to tell the [53:52] difference between a good plan and a bad [53:54] plan. [53:54] >> Yeah. [53:55] >> And and and and that means knowing your [53:57] code base. It means knowing your [53:59] corporate goals. It means all of that. [54:00] But I think if if you're a junior [54:02] mid-level engineer who who can really [54:04] understand the difference between that [54:06] was a good plan and a bad plan for the [54:08] agent, that would be a pretty powerful [54:10] position to be in. [54:14] >> Now, this one I grabbed this one for [54:16] specific reason. I want to talk to Jose [54:17] a little bit about this and it's really [54:19] like how are we handling PRs at this [54:21] point? And there's a there's a deeper [54:22] question here that I want to like unpack [54:23] because I think the way we debug [54:24] software is changing is changing a lot. [54:26] And like obviously we have a we have a [54:28] stake in this in the sense of what [54:30] Sentry does and how we're looking at at [54:32] the problems space overall. But Jose, I [54:33] think you have some some interesting [54:34] ways that you guys are are debugging [54:36] problems. You might you may or may not [54:38] be using the the code review components [54:40] of of SE at this point, but you're using [54:42] Seir in some interesting ways. And so [54:43] love to hear from everyone like how how [54:45] are we talking about like these baseline [54:46] engineering tasks of like PRs bringing [54:49] code into the codebase reviews how does [54:51] all that stuff play up and then also [54:52] just wider how are we debugging software [54:54] now. [54:56] >> Yeah. So I think I have a couple of [54:58] interesting examples and I'll try to be [54:59] quick. So I think one is around some of [55:01] the tooling that we just wrote. So like [55:03] I said, uh we, you know, I leverage AI [55:06] to document our codebase, uh and [55:09] actually then help me write a test suite [55:11] to make sure that uh what the code that [55:15] was written and the documentations match [55:17] up and whenever you make a change, they [55:20] both get updated. And um that actually [55:22] is part of our flow uh for one of our [55:25] particular codebase. And um I think that [55:28] in itself is like super productive [55:30] because you you get an automation where [55:33] um you get this script that will review [55:36] a PR. It assesses a certain risk value. [55:39] It tells you how you should test your [55:41] code. Um and then the reviewer could [55:43] view this and then they will have more [55:46] uh signal on whether this is an easy [55:48] ship it or this is a I need to probably [55:50] spend a couple hours reviewing this. And [55:53] so I think that in itself is a really [55:55] big one. Um the other one is kind of [55:58] what we're trying to bring in right now. [55:59] So you know we're using Sentry to [56:01] collect uh production errors and [56:04] obviously that in itself should be [56:06] informing how we uh are able to fix [56:08] that. And so one of the things that we [56:11] trial uh late last year was leveraging [56:13] the Sentry MCP server so that uh we [56:17] could use a tool like cursor uh to uh [56:20] prompt what are the current issues in [56:22] production and then create a PR uh with [56:25] the fix and document that. And so part [56:28] of what we're trying to do this year and [56:31] kind of going back to uh to the building [56:33] blocks is to create a filter in terms of [56:36] what are the issues that we feel [56:38] comfortable [56:39] um having like automated PRs drafted [56:42] based on the sensory data and then a [56:44] workflow that will allow engineer to [56:46] review it and approve it and merge it [56:48] into the codebase. And so our goal is to [56:50] eventually have almost no um what we [56:54] call like lowline or like low-level [56:56] production issues. Um and you know I [56:59] think that's one of the things that I [57:01] I'm most excited about. And I think the [57:04] other part um that we're looking at like [57:06] I discussed before is kind of the [57:08] agentic uh approach in terms of creating [57:11] more expertise and then incorporating [57:13] that into the workflow that would [57:16] actually be PR. All right. Like you [57:17] could imagine that you're going to have [57:19] a security agent, that you're going to [57:20] have a UI agent, and whenever you get a [57:23] PR, they would at least post some sort [57:26] of comment that lets a real human say, [57:29] "All right, well, I would have said [57:31] that." So AI said, and hopefully this [57:33] person already made those changes, [57:35] right? And so I think that that's the [57:37] part that we're hoping to get to and [57:39] measure. [57:42] >> Yo, what about what about you all? uh on [57:45] our side like we have I think on the [57:46] code review tooling we have different [57:48] ones I don't remember exactly when which [57:49] ones are there uh I think something from [57:51] GitHub uh co-pilot I guess and then I [57:54] think I've used like code drop it in the [57:56] past before so those have been very [57:57] useful was like reviewing tools like uh [58:00] I just came back I don't know century [58:01] just released the code review tool as [58:02] well so something that we might look [58:04] into as well um but yeah I mean like [58:07] beyond that like reviewing wise code [58:08] review wise like not using much much [58:10] beyond that [58:12] >> awesome we are about uh two minutes up [58:14] from the end. So I want to I want to [58:16] speed round predictions real fast. So [58:17] kind of one oneliner oneliner [58:19] predictions real fast and then we'll uh [58:21] we'll we'll cruise out for it. So So [58:23] Dave, what's your what's your 2026 AI [58:26] hot take? [58:27] >> Oneeliner. Oh, that's so hard. Um [58:29] >> give me three three liners. [58:30] >> Oh, we all do. I mean, I guess what I'm [58:32] looking for I feel like there's a [58:33] disconnect right now between with big [58:36] code bases, we know how to use AI tools [58:38] to uh you know, try to make an [58:41] incremental change like PR. It's, you [58:43] know, it's a delta, right? We also know [58:45] how to use AI tools to basically like [58:48] oneshot a whole app into existence. Um, [58:52] I'm really looking forward to kind of [58:54] all the exploration that happens around [58:56] tooling that kind of bridges that gap [58:58] and that lets us essentially write like [59:00] a a significant scale PRD or something [59:03] like that and then compile that into a [59:06] largecale app and then maybe like make [59:08] changes to that PRD and maybe there's [59:10] some technology that allows more [59:12] incremental compilation so to speak of [59:15] the spec into the actual written code. [59:17] But I'm I I think this is I think this [59:20] is possible. is on the frontier and I'm [59:22] really looking forward to being able to [59:24] build sort of nonplay thing scale apps, [59:28] you know, in in one click um with AI. [59:31] So, that's something that I'll I'll be [59:33] keeping a very careful eye on in 2026. [59:36] >> I like it. Yona, you're up. uh something [59:39] super integrated that somehow integrates [59:41] Slack and Google Docs and different [59:43] document sources as I'm writing code so [59:45] it can tell me if there's changes to [59:47] specs or some relevant communication the [59:49] feature that I'm specifically working on [59:51] a given point in time that would be [59:52] amazing [59:54] >> I love it Jose [59:56] >> I think keeping with the agent workflow [59:58] um I think I I would love to see um or I [60:02] don't I'm not saying I would love to see [60:04] I think we will get to um like a high [60:07] level of concurrency uh with with agents [60:11] that will actually get us to the [60:13] productivity that we expect AI to be. Um [60:16] I think the question would be how [60:17] expensive will that be? So, but I I [60:21] really think with with whatever [60:24] everyone's trying out with agents, I [60:26] think things will standardize and it'll [60:29] be something that will compound and uh [60:33] you know, I think uh will be kind of the [60:35] biggest win that we get uh from AI this [60:38] year. [60:39] >> Awesome. Well, we are at time. This was [60:41] a blast, guys. I really enjoyed this. [60:42] This was this was a ton of fun. We had a [60:44] lot of questions that we that we [60:45] unfortunately didn't get through. We [60:46] might might have to run this back [60:47] sometime in in the future and get you [60:48] guys back here to talk with us some [60:50] more. But I know I really appreciate you [60:51] coming through and talking to us about [60:53] what you're doing at Unity and Adobe. [60:54] And Dave, thanks for taking the time to [60:56] talk a little bit more about Century. So [60:58] this was great, everyone. [60:59] >> Thank you for having us. [61:00] >> You thanks very much. Have a great