The Missing Link in AI Coding Tools with Dennis Pilarinos! ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article4.6bc1851654a0.png) 🔗 **Source:** [The Missing Link in AI Coding Tools with Dennis Pilarinos!](https://www.youtube.com/watch?v=vwxpgY9TXuA) > [!note]+ Document Notes > tags: [ai-coding-tools, developer-context, agentic-development] > author: [MISSING] > source: Overcommitted Podcast > reference: https://www.youtube.com/watch?v=vwxpgY9TXuA > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: The Missing Link in AI Coding Tools with Dennis Pilarinos! > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - Dennis Pilarinos, founder and CEO of Unblocked, discusses how context gaps—not code writing—are the real bottleneck in software development - Only 14% of developer time is spent actually writing code, with most time lost to context gathering and understanding existing systems - AI agents face the same context problems as humans, often operating like "50 First Dates" scenarios where they lose context between sessions - Unblocked provides contextual code intelligence that helps both developers and AI agents understand the "why" behind code decisions - The future requires developers to understand fundamentals while leveraging AI tools, similar to construction workers using nail guns instead of hammers ## 📖 Main Content Dennis Pilarinos brings nearly two decades of experience building developer tools at Microsoft (Azure), AWS, and Apple (through BuddyBuild acquisition). His current company, Unblocked, addresses what he identifies as the core problem in software development: context gaps rather than code generation. ### The Context Crisis The traditional developer workflow involves significant time spent interrupting colleagues or digging through documentation to understand existing systems. A recent DX survey found that only 14% of developer time is spent actually writing code. This context problem has become even more acute with AI agents, which often operate without the tribal knowledge that human developers accumulate over time. Pilarinos uses the analogy of "50 First Dates" versus "Memento" to describe how AI agents currently function—they restart context gathering with each session, unlike humans who build understanding through continuous exposure to systems, meetings, and collaboration. ### Unblocked's Approach Unblocked integrates into existing developer workflows through multiple surfaces: - Slack integration for help channels - Web dashboard and standalone Mac app - Q&A experiences that break into natural workflow patterns The platform has helped customers reduce support load by 50% by providing high-quality answers without human intervention, particularly valuable for geographically distributed teams. Beyond human assistance, Unblocked has expanded to help AI agents stay "on track" with better context, and recently launched a context-powered code review product to handle the bottleneck of reviewing AI-generated code. ### The Fundamentals Debate Pilarinos argues against pure "vibe coding" without understanding fundamentals, using construction analogies: workers use nail guns instead of hammers but still need to understand proper framing techniques. He observes an interesting pattern where companies are hiring more interns who are skilled with AI tools while senior engineers who embrace these tools thrive, but mid-level developers who resist adoption struggle. The real challenge isn't building greenfield projects (which AI handles well) but working within existing, complex systems where understanding context and tribal knowledge becomes crucial for success. ## 🗒️ Notes #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=vwxpgY9TXuA?t=192) Context gap as the real bottleneck - Only 14% of developer time spent writing actual code according to DX survey - Most time lost to interrupting colleagues or digging through information - Same problem applies to AI agents who lack tribal knowledge #### ⏱️ [00:08:45](https://www.youtube.com/watch?v=vwxpgY9TXuA?t=525) AI agent context problems - Agents operate like "50 First Dates" - restarting context each session - Real world is more like "Memento" - fragmented information everywhere - Agents are expert at writing code but strangers to existing systems #### ⏱️ [00:15:30](https://www.youtube.com/watch?v=vwxpgY9TXuA?t=930) Unblocked's workflow integration - Slack integration reduces support load by 50% - Multiple surfaces: web, Mac app, natural Q&A experiences - Breaking into habit loops is hardest part of developer tool adoption #### ⏱️ [00:22:15](https://www.youtube.com/watch?v=vwxpgY9TXuA?t=1335) Social fabric concerns - AI reducing natural touchpoints for colleague interaction - Need conscious effort to maintain relationships in remote work - Value of friction and pushback in creative workflows #### ⏱️ [00:28:40](https://www.youtube.com/watch?v=vwxpgY9TXuA?t=1720) Developer maturity spectrum - Range from tab-complete to fully autonomous agents checking in code - Sharing adoption patterns within organizations is valuable - Most prolific engineer used AI for rubber ducking, not code generation #### ⏱️ [00:35:20](https://www.youtube.com/watch?v=vwxpgY9TXuA?t=2120) Vibe coding limitations - Can handle initial 80% but struggles with last 20% of projects - Legacy codebases require understanding of existing systems - When AI hits "doom loops," fundamental knowledge becomes essential #### ⏱️ [00:42:10](https://www.youtube.com/watch?v=vwxpgY9TXuA?t=2530) Career insights and building for developers - Started Azure as grassroots project with static IP and domain name - Self-described "mediocre developer" and "impatient person" - Key insight: balance simplicity with ability to drill into details ## 📚 References - [Unblocked](https://getunblocked.com) - Contextual code intelligence platform - [DX Developer Survey](https://getdx.com) - Research on developer productivity and time allocation - BuddyBuild - Mobile CI/CD platform acquired by Apple, now Xcode Cloud ## 🗣️ Paraphrase Dennis Pilarinos argues that the software development industry has misidentified the core productivity challenge. While much attention focuses on AI's ability to generate code, the real bottleneck lies in understanding context—the accumulated knowledge about why systems work the way they do. His company Unblocked addresses this by providing contextual intelligence that helps both human developers and AI agents access tribal knowledge without interrupting colleagues. The future requires developers who understand fundamentals while leveraging AI tools effectively, similar to skilled construction workers who use power tools but still understand proper building techniques. ## 📰 Newsletter 🔧 **Context is King in AI-Assisted Development** This week we're diving deep into why your AI coding assistant keeps missing the mark. Dennis Pilarinos from Unblocked reveals that only 14% of developer time goes to actual coding—the rest is context hunting. His platform integrates with Slack and other tools to give both humans and AI agents the "why" behind code decisions. Key insight: Companies are hiring more AI-savvy interns while senior devs who embrace these tools thrive. The middle tier that resists? They're struggling. Think nail guns vs. hammers—better tools, same fundamentals required. Worth exploring: Unblocked's approach to contextual code intelligence and how they're solving the "50 First Dates" problem where AI agents restart context from scratch every session. ## ✅ Action Items #### DevRel - Research integration patterns for AI-assisted development tools in developer workflows - Create educational content around balancing AI assistance with fundamental understanding - Develop workshops on context management in legacy codebases #### Community - Document tribal knowledge and decision-making processes to support both human and AI understanding - Create mentorship programs pairing AI-experienced developers with those learning to adopt these tools - Establish guidelines for maintaining social connections as AI reduces natural collaboration touchpoints #### WordPress - **Core:** Evaluate how AI coding tools can accelerate contribution while maintaining code quality standards - **Documentation:** Improve context documentation to support AI-assisted development in WordPress core - **Training:** Develop curriculum balancing AI tool usage with WordPress architectural understanding ## 🧪 Hypotheses - Organizations with better documented context and tribal knowledge will see higher success rates with AI-assisted development - Developer productivity gains from AI tools plateau without fundamental understanding of underlying systems - The most valuable developers will be those who combine strong fundamentals with advanced AI tool proficiency - Context-aware AI tools will reduce interruption-based knowledge sharing while requiring intentional relationship building - Companies that invest in contextual intelligence platforms will see measurable improvements in developer velocity ## 📊 Methodology - Survey developers across experience levels on AI adoption patterns and productivity impacts - Measure correlation between documentation quality and AI tool effectiveness in codebases - Track time allocation changes as organizations adopt context-aware development tools - A/B test different approaches to maintaining social fabric in AI-augmented development teams ## ❓ Questions - How do we preserve institutional knowledge as AI reduces natural knowledge-sharing touchpoints? - What's the optimal balance between AI assistance and deep system understanding for different developer roles? - How will the definition of "senior developer" evolve as AI tools become more sophisticated? - What new forms of technical leadership emerge when code generation becomes commoditized? ## 🔮 Future Research - Long-term career trajectories for developers with different AI adoption strategies - Impact of context-aware tools on software quality and maintainability - Evolution of code review practices as AI generates increasing amounts of code - Social and cultural changes in engineering teams as AI handles more routine tasks ## 💡 Implications - **Practice:** Development teams need intentional processes for knowledge sharing and relationship building - **Policy:** Engineering organizations should invest in context documentation and tribal knowledge capture - **Education:** Computer science curricula must balance AI tool proficiency with fundamental understanding - **Tooling:** Developer tools need to solve context gaps, not just code generation challenges ## 🧠 Learning Styles Assessment Reading level estimate: Grade 12 (using Flesch-Kincaid formula) - technical content with accessible explanations. #### 👀 Visual learners - Present: Interview format with clear speaker identification and topic transitions - Improve: Add diagrams showing context flow between developers, AI agents, and knowledge sources; visualize the "50 First Dates" vs "Memento" analogy #### 🔊 Aural learners - Present: Podcast format with conversational tone and verbal explanations - Improve: Provide transcript with timestamps; add audio summary of key takeaways #### 🗣️ Verbal learners - Present: Analogies (construction workers, movies), defined terminology, conversational explanations - Improve: Add glossary of technical terms; expand on construction and movie analogies #### 🧩 Kinesthetic learners - Present: Discussion of hands-on development experiences and tool usage - Improve: Create interactive demos of context-aware tools; provide step-by-step guides for implementing better context practices #### 🧠 Logical learners - Present: Clear problem-solution structure, statistical evidence (14% coding time), logical progression of ideas - Improve: Add decision trees for when to use different approaches; provide frameworks for evaluating AI tool adoption #### 🧑‍🤝‍🧑 Social learners - Present: Interview format with multiple perspectives, discussion of team dynamics and collaboration - Improve: Add discussion questions for engineering teams; provide frameworks for group evaluation of AI adoption strategies #### 🧘‍♀️ Solitary learners - Present: Detailed analysis suitable for individual reflection, career insights and personal development focus - Improve: Add self-assessment questions about AI adoption readiness; provide individual action planning templates #### 🌿 Naturalistic learners - Present: Systems thinking approach to software development, ecosystem analogies - Improve: Expand on software development as ecosystem; discuss sustainability of different development approaches ## 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings hierarchy, descriptive content structure - Improve: Add ARIA landmarks for major sections, ensure timestamp links have descriptive text #### Keyboard navigation - Present: Standard web navigation patterns - Improve: Ensure all timestamp links are keyboard accessible, add skip links for major sections #### Contrast and readability - Present: Standard text formatting with good information hierarchy - Improve: Verify sufficient contrast ratios, consider larger font sizes for technical content #### Media and captions - Present: Full transcript provided with timestamps - Improve: Add speaker identification in transcript, consider audio descriptions for any visual analogies ## 🌍 DEIB Assessment #### Cultural breadth - Present: Discussion includes global perspective on remote work and distributed teams - Improve: Include examples from diverse geographic regions, acknowledge different cultural approaches to knowledge sharing #### Inclusive language - Present: Gender-neutral examples, accessible explanations of technical concepts - Improve: Expand glossary, avoid tech industry jargon without explanation #### Neurodiversity support - Present: Clear structure with consistent formatting, logical information flow - Improve: Add visual section breaks, provide multiple ways to consume information (audio, text, summary) #### Representation - Present: Interview format shows diverse perspectives on technical challenges - Improve: Include perspectives from different career stages and backgrounds in developer experience ## ✅ Logical Validity #### Strong reasoning - **Analogical reasoning**: Construction worker tool evolution (hammer to nail gun) effectively illustrates how fundamental skills remain important even as tools improve - **Inductive reasoning**: Pattern observation about intern hiring and senior developer success with AI tools supports broader conclusions about adaptation requirements - **Causal reasoning**: Clear connection established between context gaps and productivity bottlenecks in software development #### Fallacies - **Appeal to authority**: Heavy reliance on personal experience at major tech companies without broader industry validation - **False dichotomy**: Presents "vibe coding" vs "fundamentals" as binary choice when reality likely involves spectrum of approaches - **Survivorship bias**: Focus on successful AI adoption stories may underweight challenges and failures #### Tone of voice - Conversational and approachable while maintaining technical credibility; uses humor and analogies effectively to explain complex concepts; balances optimism about AI tools with realistic assessment of limitations ## 🛡️ DARVO Analysis No evidence of DARVO tactics present. The discussion maintains balanced perspective on AI tools, acknowledging both benefits and limitations without defensive positioning or attacking critics of AI adoption. ## 🎯 Conclusion The conversation reveals that successful AI-assisted development requires solving context gaps rather than just improving code generation. Organizations and individuals who combine strong fundamental understanding with effective AI tool adoption will likely see the greatest productivity gains. The key insight is that context—the accumulated tribal knowledge about why systems work—remains the critical bottleneck that needs systematic solutions rather than hoping AI will eventually figure it out independently. Practical next steps include investing in context documentation, maintaining intentional knowledge sharing practices, and developing skills that complement rather than compete with AI capabilities. --- ## Full Transcript [00:00] Welcome to the Overcommitted Podcast,<br>[00:02] your weekly dose of real engineering<br>[00:04] conversations. I'm your host, Bethany,<br>[00:06] and I'm joined by Hey, I'm Britney. I'm<br>[00:08] Erica.<br>[00:09] We met while working on a team at GitHub<br>[00:12] and quickly realized we were all<br>[00:13] obsessed with getting better at what we<br>[00:15] do. So, we decided to start this podcast<br>[00:17] to share what we've learned. We'll be<br>[00:19] talking about everything from leveling<br>[00:21] up your technical skills to navigating<br>[00:23] your professional development, all with<br>[00:24] the goal of creating a community where<br>[00:26] engineers can learn and connect. Today<br>[00:28] on Overcommitted, I am so excited. We<br>[00:30] are joined by Dennis Pillarinos, founder<br>[00:33] and CEO of Unblocked, a contextual code<br>[00:36] intelligence platform that helps<br>[00:37] developers understand the why behind<br>[00:39] their code. Dennis has spent nearly two<br>[00:42] decades building developer tools at some<br>[00:44] of the biggest names in tech. He helped<br>[00:46] build Azure at Microsoft, worked on AWS,<br>[00:48] and then founded BuddyBuild, a mobile<br>[00:50] CI/CD platform that Apple acquired in<br>[00:53] 2018 and turned into Xcode Cloud. Now<br>[00:56] he's tackling what he calls the real<br>[00:57] bottleneck in software development. Not<br>[01:00] writing code, but understanding it.<br>[01:01] Welcome, Dennis.<br>[01:02] >> Thanks so much for having me. I'm<br>[01:03] excited to have this conversation. I'm<br>[01:05] >> so excited. To kick us off, what's<br>[01:07] something you're currently building or<br>[01:08] learning that has you excited right now?<br>[01:10] >> Um, I mean, I think it's a handful of<br>[01:12] different things. They're all pretty<br>[01:14] much some form of automation of some<br>[01:16] internal tooling. Um, I found in the<br>[01:18] past we would look for we'd have to<br>[01:21] assign engineering resources to<br>[01:23] accommodate or accomplish I would say<br>[01:25] like non-product tasks and what I'm<br>[01:27] excited about now is the fact that I can<br>[01:28] basically just do that very very quickly<br>[01:30] myself off the side of my desk and so<br>[01:33] endless number of examples. It's amazing<br>[01:35] to see other engineering leaders kind of<br>[01:36] get back to their kind of core roots and<br>[01:39] build these little mostly internal tools<br>[01:41] that help um help the company.<br>[01:43] >> That makes a lot of sense. I mean you've<br>[01:46] said previously that writing code was<br>[01:48] never the main challenge but it's<br>[01:50] finding that context. So what really<br>[01:54] does that context gap look like<br>[01:56] day-to-day is it different for these<br>[01:57] leaders compared to engineers or is it<br>[02:00] uh quite similar?<br>[02:01] >> I think so when I think about you know<br>[02:04] historically how software has been built<br>[02:06] like you mentioned I've been building<br>[02:07] developer tools for the better part of<br>[02:09] 20 years as an engineer as an<br>[02:10] engineering manager as a business leader<br>[02:12] or what have you. One of the things that<br>[02:14] I found personally frustrating was the<br>[02:16] inability to get the information I need<br>[02:17] to get my job done, right? And as an<br>[02:19] engineer, your job is ultimately to like<br>[02:22] write code, right? You're either fixing<br>[02:24] bugs, implementing features, whatever it<br>[02:26] might be. And the way that you would get<br>[02:27] that information historically was<br>[02:29] typically interrupting your co-workers,<br>[02:31] or spending a bunch of time like digging<br>[02:32] through information. But like you spend<br>[02:35] a ton of time doing that, especially if<br>[02:37] you're working in a legacy codebase with<br>[02:39] a lot of other people. And the actual<br>[02:40] coding part of it is like relatively<br>[02:42] insignificant. I think DX released a<br>[02:44] survey that said 26 a developer survey<br>[02:46] just a couple of weeks ago where they<br>[02:48] said 14% of an engineer's time is<br>[02:50] actually spent writing actual code,<br>[02:51] which I thought was an interesting stat.<br>[02:53] And so that context gap is quite pain.<br>[02:56] Um it's actually funny. When we started<br>[02:58] unblocked, we were going to call the<br>[03:00] company bother, which is like you don't<br>[03:02] bother me, I don't bother you, right?<br>[03:04] It's just like we can use bother, get<br>[03:06] the answers for the things that we need<br>[03:08] and move on with our days very, very<br>[03:10] quickly. So, you know, it's an<br>[03:12] interesting time. I think there's an<br>[03:13] interesting transition where while it's<br>[03:15] been historically true that engineers<br>[03:17] are the folks writing code, increasingly<br>[03:20] it's their agents, right? And so, we're<br>[03:23] seeing that same problem arise with<br>[03:25] agents. If you use any of these tools, a<br>[03:28] lot of them struggle with the context.<br>[03:30] And what do they do? Well, the same<br>[03:32] thing a person does. They kind of guess<br>[03:33] and play kind of whack-a-ole trying to<br>[03:35] figure out what things are things need<br>[03:37] to go get done uh or what context they<br>[03:39] need in order to to do their things. And<br>[03:41] so we're finding that context gap is<br>[03:43] even more acute, I would say, um today<br>[03:45] as increasingly agents are writing even<br>[03:48] more code than than developers that they<br>[03:50] kind of work for.<br>[03:51] >> Absolutely. How do you handle the<br>[03:53] situations where you don't have enough<br>[03:55] information? Like the answer is still to<br>[03:57] like ask somebody. Um like I find that<br>[04:02] um like the overconfidence in sort of<br>[04:04] like AI assisted workflows can be really<br>[04:07] misleading of it says a really confident<br>[04:10] answer, it's found all the all the<br>[04:12] solutions and then I start asking it,<br>[04:14] well how do you know that? And it's like<br>[04:15] well actually I guessed.<br>[04:16] >> Yeah. Yeah. It reminds me I think like<br>[04:19] in my career I think I've gone through<br>[04:21] these stages in my career as well but at<br>[04:23] at some point I was like overly<br>[04:25] confident and probably didn't have the<br>[04:27] skill to measure with the confidence<br>[04:29] right and so that's you're not you're<br>[04:31] not quite necessarily right out of<br>[04:32] school but probably shortly thereafter<br>[04:34] you're like I've been there I've done<br>[04:35] that I can like absolutely nail this<br>[04:37] thing and you go down your merry way and<br>[04:39] then you're like I didn't I haven't<br>[04:41] experienced this problem or this scale<br>[04:42] issue or this like security<br>[04:44] vulnerability or any number of things<br>[04:46] and So that's I feel like a lot of<br>[04:48] people have this impression of these<br>[04:50] agents where they're like actually very<br>[04:52] very I would argue expert level at<br>[04:54] writing code but like strangers to the<br>[04:57] to the system. They don't have the<br>[04:59] tribal knowledge and so they're like I<br>[05:01] know based on like what I've been<br>[05:02] trained that this is the right way to do<br>[05:04] things and you're like actually not here<br>[05:05] it's not. So yeah and you end up yeah<br>[05:09] this kind of almost like uncanny valley<br>[05:10] where it's like we should do it this way<br>[05:12] and here it is. Then you realize nope<br>[05:14] not even close. Yeah, I definitely feel<br>[05:16] that. And you're kind of restarting over<br>[05:19] whenever you start a new agent session.<br>[05:21] Basically, it's not even that. It builds<br>[05:23] this context as it goes. Most typically,<br>[05:25] it just kind of you have to restart that<br>[05:28] process uh every time you you pick up<br>[05:30] one of these tools.<br>[05:33] >> Yes. Oh, yeah.<br>[05:35] >> I was like, it's one of those funny<br>[05:36] things where just like as people, we are<br>[05:39] a context engine, right? like we sit in<br>[05:42] scrum meetings, we learn and like evolve<br>[05:45] our thinking and our awareness, right?<br>[05:46] That's why folks who've been around code<br>[05:48] bases for a long time are really really<br>[05:50] valuable. But imagine I wrote this blog<br>[05:53] post the difference between like 50<br>[05:54] first dates and momento imagine that<br>[05:56] like you know the way the the technology<br>[05:58] works right now certainly is that you<br>[06:00] every time an agent gets spun up it<br>[06:02] needs to basically recreate that context<br>[06:05] right it is and you're babysitting it.<br>[06:07] constantly spoon feeding it like this<br>[06:09] information in you know 51st dates that<br>[06:12] was Drew Barrymore right waking up every<br>[06:16] morning and like there's a system around<br>[06:17] her for her to like boot up her<br>[06:19] effectively memory right but in reality<br>[06:22] most of these systems are in<br>[06:23] environments that look more like momento<br>[06:24] if you remember that movie where it's<br>[06:26] like the guy had like tattooed stuff and<br>[06:28] like he has notes and like stuff all<br>[06:30] over the place that's actually the real<br>[06:32] world right so these agents have no<br>[06:35] working set basically they're like oh<br>[06:36] let's see around there. Um, and and they<br>[06:39] face a momento world, which is<br>[06:40] horrifying. Great movie. But<br>[06:43] >> yeah, you're right though. I mean, and<br>[06:45] and that that also can happen to me when<br>[06:47] I like even if I like don't look at a PR<br>[06:50] or something or like an area of the code<br>[06:52] for a couple weeks and then I come back,<br>[06:53] I have to like similarly like, oh wait,<br>[06:56] what does this mean? And like what how<br>[06:58] does this connect to that? Yeah, it's<br>[07:00] it's a it's a it's a people and an agent<br>[07:03] problem.<br>[07:05] Yeah.<br>[07:06] >> Yeah. Uh I I feel like it's like we have<br>[07:08] limited context windows, right? Like I I<br>[07:11] typically don't remember what I did even<br>[07:13] a week ago. Uh these days I have a<br>[07:14] newborn, so my context window is<br>[07:16] progressively getting smaller because I<br>[07:18] don't sleep much. But, you know, there's<br>[07:20] all these external factors that play<br>[07:21] into it. But yeah, it's exactly right. I<br>[07:23] often don't remember the decisions that<br>[07:25] we made that influenced, you know, why<br>[07:27] we built the system a certain way or any<br>[07:29] number of these types of types of things<br>[07:31] that like is actually codified, right?<br>[07:32] It's it's in these system and records.<br>[07:34] It's in our poll requests. It's in<br>[07:36] Slack. It's in our documentation. It's<br>[07:37] in the source code, but we don't for<br>[07:39] whatever reason we don't want to give<br>[07:42] agents a holistic view of that typically<br>[07:44] right now. So that that's kind of the<br>[07:46] the pain point and they're really good<br>[07:47] at it once they have it.<br>[07:48] >> You also don't want it to be like<br>[07:49] deterministic. Like you don't want it to<br>[07:51] be like, oh, because we did it this way<br>[07:53] now we always have to do it this way.<br>[07:54] Like there is some nuance there of like<br>[07:57] this is a decision that we made but<br>[07:58] we're going to recognize that that was<br>[08:00] >> Yeah. Absolutely. Absolutely. I think<br>[08:02] too Britney and I went to the pragmatic<br>[08:04] summit which uh there was a really good<br>[08:06] conversation there about um adoption and<br>[08:10] how companies with good systems tend to<br>[08:12] adopt AI better than companies with<br>[08:15] maybe like systems that need work still.<br>[08:18] So I think if you're solving that human<br>[08:20] issue with context, it often helps the<br>[08:23] AI also solve the context issue for<br>[08:26] those sessions. How exactly does<br>[08:29] Unblocked combat this? Or does it also<br>[08:31] help the human side of things as well as<br>[08:33] just the AI agent things side of things?<br>[08:36] >> Yeah. No, it does both actually. We<br>[08:37] help, you know, engineers save time and<br>[08:40] agents kind of stay on track is the way<br>[08:42] that we think about it, right? Because<br>[08:43] they just like they go all over the<br>[08:45] place. But yeah, we started by helping<br>[08:47] engineers, right? Like I don't want to<br>[08:48] have to be interrupted or interrupt my<br>[08:50] co-workers. So we have a handful of<br>[08:52] surfaces that give people a very natural<br>[08:56] Q&A experience. They can ask questions<br>[08:57] in a web experience. They I mean I think<br>[09:00] one of the hardest parts about building<br>[09:01] developer tools is breaking into the<br>[09:03] habit loop of an engineer, right? Like<br>[09:05] having someone have to remember to do<br>[09:07] something in order to get some value. It<br>[09:10] takes a while. It's actually a really<br>[09:11] really hard problem to solve. And so we<br>[09:14] created an experience where in Slack and<br>[09:16] this is super popular in like help<br>[09:18] channels, right? If you we have<br>[09:19] customers who have five, seven, 10,000<br>[09:22] people in a help channel. And what do<br>[09:24] people do? Actually, I can think of one.<br>[09:25] It's like help-gub. Ironically, these<br>[09:28] this organization has a help- GitHub and<br>[09:30] people come in and they just ask their<br>[09:32] question, right? Like it's the first<br>[09:34] time it's ever been asked. It hasn't<br>[09:36] been, but Unblocked, you know, that's<br>[09:37] their workflow. They go in, they type<br>[09:40] their question, they're waiting for<br>[09:41] someone on the support team to answer<br>[09:42] it. Unblocked helps alleviate that<br>[09:45] support load because it sees that it can<br>[09:47] answer that question. And people love<br>[09:49] it, especially if they're geographically<br>[09:50] distributed, time zone shifted, any of<br>[09:52] those types of things where they're<br>[09:53] getting a high quality answer very, very<br>[09:55] quickly. And so breaking into a person's<br>[09:57] like workflow where they're getting AI<br>[09:59] providing value to them, especially at a<br>[10:01] time where they're they're trying to<br>[10:02] like move on with their work, right?<br>[10:04] They're they're stuck on something. We<br>[10:06] had a customer say that they've reduced<br>[10:07] their support load by like 50% because<br>[10:10] unblocked is helping them, right? That's<br>[10:11] just people. And so we started with<br>[10:14] that, right? making it part of the<br>[10:16] workflow where you are you know if you<br>[10:18] you can ask questions in Slack teams in<br>[10:21] this web dashboard a standalone Mac app<br>[10:22] any number of ways for people to ask<br>[10:24] questions and I would say I don't know<br>[10:26] maybe the last 6 to 8 months it's been<br>[10:29] very clear that agents suffer from that<br>[10:31] same problem and so we plug into that<br>[10:34] agent workflow as well it's kind of<br>[10:36] crazy right because quickly you you can<br>[10:38] help solve that problem where people and<br>[10:40] agents get this information the next<br>[10:42] thing and I think a lot of teams are<br>[10:43] experiencing this is that you're now run<br>[10:46] into this bottleneck where you're stuck<br>[10:47] on pull requests, right? All this code<br>[10:49] is getting generated. Now you have a ton<br>[10:52] of pull requests that have been and we<br>[10:53] see this in the open source community a<br>[10:54] whole bunch of places, right? Yeah. We<br>[10:57] we were we had kind of felt that<br>[10:58] ourselves and we built a code review<br>[11:01] product that's based on the context,<br>[11:03] right? Like I want code reviews as if<br>[11:05] they came from like the best engineer on<br>[11:06] the team. And so we built it internally<br>[11:08] just for ourselves because we weren't<br>[11:10] happy with kind of what what existed in<br>[11:11] the market. We gave it to a handful of<br>[11:14] folks um that were customers to be like<br>[11:16] what do you think of this and people<br>[11:17] absolutely lost their mind and so we're<br>[11:18] kind of helping people you know not only<br>[11:20] write more code but like actually make<br>[11:22] sure that it's the right code for their<br>[11:24] organization and we offer this code<br>[11:25] review like context powered code review<br>[11:27] product that helps as well. So it's a<br>[11:29] crazy time. Yeah, for sure.<br>[11:30] >> I think that's super interesting and I<br>[11:32] feel like it's solving one of the<br>[11:33] biggest problems with AI which is like<br>[11:35] making sure that it has the right<br>[11:36] context. But I'm curious your thoughts<br>[11:38] on like how people maintain<br>[11:41] relationships with their co-workers now<br>[11:43] when we're moving towards this world<br>[11:45] where we can use AI to get all the<br>[11:46] answers. Previously, I used to reach out<br>[11:48] to my co-workers and that was like our<br>[11:49] interaction now. And now I'm finding<br>[11:51] myself like I have to like deliberately<br>[11:52] try to build those relationships and be<br>[11:54] like, "Hey, how are you?" Like instead<br>[11:56] of just relying on, you know, the the<br>[11:59] touch points where I'm like, "Hey, can<br>[12:00] you can you review this PR for me?"<br>[12:02] >> Yeah.<br>[12:02] >> Do you have any thoughts on that or how<br>[12:03] that's changing? I mean I think you know<br>[12:05] with every technological shift there is<br>[12:08] um I think there's some like unfortunate<br>[12:10] casualties right that we have to be<br>[12:12] mindful of and figure out like how do we<br>[12:14] maintain people are inherently social<br>[12:16] creatures um I'm actually somewhat of an<br>[12:19] introvert and so you know I have a<br>[12:21] certain amount of social tendencies and<br>[12:22] after a while I'm tired of it right but<br>[12:24] like I think a lot of the technology<br>[12:26] that we see today it's very easy for<br>[12:28] people to just become siloed especially<br>[12:30] if you're not working in an office with<br>[12:31] people right if you're working from home<br>[12:33] you have to make conscious efforts to<br>[12:35] like continue to build that social<br>[12:36] fabric because at the end of the day<br>[12:38] that is in in my opinion how like the<br>[12:40] best teams operate. So, I don't know<br>[12:42] that I have like a a concrete solution<br>[12:45] for that, but it's definitely something<br>[12:46] we're seeing, right? We see people who<br>[12:48] say that they are kind of AI fatigued.<br>[12:51] It's not it's not like working with a<br>[12:52] person in many ways. So, yeah, I don't<br>[12:55] I'm curious to see how that plays out<br>[12:56] over the next I actually have a<br>[12:57] moratorium on stating any kind of<br>[12:59] timelines now because it's so so<br>[13:00] incredibly difficult to predict over the<br>[13:02] next little while. I'm going to say 3<br>[13:04] months, six months, a year, who knows? I<br>[13:06] think of it a little like um there's the<br>[13:08] whole discussion of like what's valuable<br>[13:10] to talk about in person versus remote.<br>[13:14] Um, and like you're talking about like<br>[13:16] shifts in technology, like video call<br>[13:19] technology changed the way we work. And<br>[13:21] a lot of what I've heard of what's<br>[13:23] valuable to have in person is these<br>[13:26] brainstorming sessions really like<br>[13:28] building those personal connections sort<br>[13:30] of like the higher level thinking<br>[13:32] questions like the procedural stuff like<br>[13:34] everyone get on a PowerPoint and look at<br>[13:36] these slides. You know, nobody's got<br>[13:39] time for that. Like but in a video call<br>[13:41] you can probably kind of put it on the<br>[13:42] background. it's it's probably fine to<br>[13:44] have that in some kind of like a a<br>[13:47] remote meeting or something like that.<br>[13:49] And I I think I think of it a little bit<br>[13:51] similarly with sort of conversations<br>[13:53] with my co-workers in AI assisted<br>[13:55] working environments where like I might<br>[13:58] kind of do the investigation with the<br>[14:00] agent. I might, you know, like do some<br>[14:02] spelunking, look at some of the code,<br>[14:04] like build sort of that mental model and<br>[14:06] then when I do have that conversation<br>[14:08] like hey what what do you think about<br>[14:10] this? Like it's still valuable to have<br>[14:12] that human input of like checking that<br>[14:15] you know sanity checking like does this<br>[14:16] align with your design values? Does this<br>[14:19] align with our like system values? Um<br>[14:22] like is there anything that I'm missing<br>[14:24] here that like that kind of stuff I<br>[14:26] think is still valuable conversations to<br>[14:28] have with another another<br>[14:30] >> I think. Yeah. I I really like this idea<br>[14:31] of honing in on like kind of the<br>[14:32] creative type workflows. Anything that<br>[14:34] requires some level of creativity. I<br>[14:36] think it would also add like I think<br>[14:37] there's a lot of value in friction,<br>[14:40] right? And so like actually evolving<br>[14:42] your idea by talking to someone who<br>[14:44] might actually have a different<br>[14:44] perspective. I think a lot of the tools<br>[14:46] today you know to your point it's like<br>[14:48] absolutely you're right there. So this<br>[14:50] constant like positive affirmation and<br>[14:52] sometimes maybe not the friction or push<br>[14:54] back that you need to really evolve the<br>[14:56] idea you know for now I think people are<br>[14:58] a great way to to combine those two.<br>[15:01] >> I completely agree. I've um I found as a<br>[15:04] fellow interpreter that I have um bit<br>[15:08] felt more and more siloed lately just<br>[15:10] because we're removing a lot of those<br>[15:12] touch points now with agentic<br>[15:13] development. And so recently I've found<br>[15:16] it's helpful to even push beyond to like<br>[15:19] force yourself to actually pair with<br>[15:21] people even though it's not as much of a<br>[15:23] need anymore because you've got your uh<br>[15:26] your programming buddy. But you learn so<br>[15:28] many cool things about the codebase or<br>[15:30] things that you might not be touching or<br>[15:32] even tricks on how to use agents uh when<br>[15:34] you're parroming. So it's been uh really<br>[15:37] helpful to push past that and try to<br>[15:39] force myself to to talk to people. For<br>[15:42] sure. Yeah, it's I find the the I think<br>[15:45] of like there's kind of almost like an<br>[15:46] AI adoption maturity model where people<br>[15:49] go from like very very exploratory kind<br>[15:52] of like I'm using AI to help me do kind<br>[15:54] of tab complete to like people in the<br>[15:56] middle who are like we've got MCPs and<br>[15:58] skills and like you know I'm running<br>[16:00] agents locally on my machine maybe a<br>[16:01] handful of them all the way at the very<br>[16:03] end of the spectrum which is like we<br>[16:04] have fully autonomous orchestrated<br>[16:06] agents that are checking in code into<br>[16:08] production we don't even look at the<br>[16:09] code right that kind of that whole<br>[16:11] spectrum<br>[16:12] And I don't know maybe with the<br>[16:13] exception of one or two companies that<br>[16:15] like everyone is on like on the same end<br>[16:18] of that spectrum. And so to your point<br>[16:20] around even sharing how people are using<br>[16:22] these things and like helping navigate<br>[16:25] well this is why we do it this way or<br>[16:27] we've adopted this part of that spectrum<br>[16:29] has been really um eye opening even for<br>[16:31] us right our we did this exercise a<br>[16:33] month and a half ago two months ago<br>[16:34] where our most prolific engineer in<br>[16:36] terms of lines of code which is you know<br>[16:38] whatever he didn't use any AI coding<br>[16:40] tools none like all the code that he's<br>[16:42] written is all handwritten he used AI as<br>[16:45] a means to um rubber duck basically to<br>[16:48] like talk to someone and and get<br>[16:50] feedback and input. And then we had<br>[16:52] other folks who are like we have this<br>[16:54] internal like full orchestration system<br>[16:56] that will like you know kick off these<br>[16:58] longrunning jobs will implement features<br>[17:00] for us. So we're like you know you you<br>[17:02] should try this. He's like oh this is<br>[17:04] amazing. We're like yeah you know even<br>[17:06] sharing that is is like this kind of<br>[17:08] very um eye openening experience I think<br>[17:10] for people within organizations.<br>[17:12] >> Absolutely. Kind of diving into that<br>[17:14] like future of being a software<br>[17:16] engineer. I know you recently had a post<br>[17:20] on Twitter about devs who rely primarily<br>[17:22] on vibe coding eventually hit a wall if<br>[17:24] they don't understand the fundamentals.<br>[17:26] And I'm curious like what is the line<br>[17:30] between leveraging AI to move fast or<br>[17:33] even just autonomously committing code<br>[17:35] and checking in code versus<br>[17:38] understanding and needing to understand<br>[17:40] what's um what's under the hood. Yeah, I<br>[17:43] think there's a lot of there's a lot of<br>[17:46] noise in the ecosystem around like you<br>[17:48] can vibe code anything, right? Like I<br>[17:50] could, you know, one of the folks that<br>[17:52] we work with used to work at GitHub and<br>[17:53] it's like yeah, I mean GitHub is just<br>[17:56] like a layer over top of Git. You could<br>[17:58] go and try and build that and see what<br>[18:00] that looks like, right? There's it's far<br>[18:02] more complicated than that. And so I<br>[18:03] think even in the macroeconomic climate,<br>[18:06] there's a lot of SAS businesses who are<br>[18:08] taking massive hits in terms of their<br>[18:11] stock price because people think they<br>[18:12] can be replaced or supplanted by people<br>[18:15] who are just building their own internal<br>[18:16] apps. I think these are like extreme<br>[18:18] views of the world, right? I think um<br>[18:21] you know building certainly in existing<br>[18:24] code bases like legacy teams and trying<br>[18:26] to build something without knowing how<br>[18:28] that system works. You can probably do a<br>[18:30] handful of things up to a certain point,<br>[18:32] but then when it goes wrong, how do you<br>[18:35] get yourself out of that corner? And so<br>[18:37] I think it's very exciting for a lot of<br>[18:39] people to be like, look what I'm able to<br>[18:41] do from scratch. Most, you know, I've<br>[18:43] been building software for 20 some odd<br>[18:46] years. It's very rare that you have to<br>[18:48] go file new project. Let's start<br>[18:50] something from scratch. It's always<br>[18:51] within an existing system. And so if you<br>[18:54] use these tools without understanding<br>[18:55] how that system works, when something<br>[18:57] goes wrong, how do you how do you figure<br>[18:59] out how to resolve that, right? When the<br>[19:01] AI is like, I don't know, and it just<br>[19:03] goes into this like AI doom loop where<br>[19:05] it just keeps like going back and forth<br>[19:06] between solutions that don't resolve the<br>[19:08] issue, then what happens? It's probably<br>[19:09] good for you to understand the system.<br>[19:11] That's kind of my perspective. Do do you<br>[19:12] folks feel differently?<br>[19:13] >> Yeah. I also think of like the familiar<br>[19:16] kind of adage or I don't know if this is<br>[19:20] how widespread this is but I I feel like<br>[19:22] I learned pretty early on that like the<br>[19:24] last 10 to 20% of a project is always<br>[19:27] the hardest part and yeah that first the<br>[19:30] initial like the initial commits getting<br>[19:32] like the bulk of the work usually goes<br>[19:34] pretty fast and then you try to finish<br>[19:35] it up and there's always like all these<br>[19:37] last little things that are kind of<br>[19:39] tricky and you have to figure out how to<br>[19:41] fit them back in and um have to figure<br>[19:43] figure out how to deploy it like and<br>[19:45] yeah, I mean it it kind of reminds me of<br>[19:47] the same sort of percentage logic I've<br>[19:49] heard with like LM assisted coding where<br>[19:53] they'll get you 80% of the way and then<br>[19:55] the rest of the 20% you have to do<br>[19:57] yourself. Yeah. Whenever I hear people<br>[19:59] say like SAS is dead, I'm like I don't<br>[20:01] think you've ever built software. Like I<br>[20:03] don't think you've ever like actually<br>[20:05] deployed anything to production cuz<br>[20:07] that's just not how like sure maybe like<br>[20:10] running something locally but like<br>[20:12] something that's at scale that other<br>[20:14] people are going to use like what do you<br>[20:17] I don't think you know what you're<br>[20:18] talking about.<br>[20:19] >> Yeah. Yeah. Yeah. I mean even simple<br>[20:21] little apps that I build like for myself<br>[20:23] you know I was hacking away on something<br>[20:25] over the holidays like in in Christmas<br>[20:28] right to like automate some home<br>[20:29] automation stuff that I've been doing.<br>[20:30] it gets deployed to like some AWS<br>[20:33] infrastructure, calls a handful API, so<br>[20:34] on and so forth. It broke and I was<br>[20:36] like, I don't know exactly how that all<br>[20:38] works. I was like, I've long paged that<br>[20:41] out and like what who knows what API it<br>[20:43] is and like and now I'm sitting there<br>[20:45] having to go and maintain it and like<br>[20:47] update it and I was like that's one<br>[20:49] project. What if I had 50 or 100 of<br>[20:50] these things, right? You know, if my<br>[20:53] wife walks in and presses a button and<br>[20:55] the lights don't turn on, that's not a<br>[20:56] good place to be. like it has to work<br>[20:59] and like I can't I need to make sure<br>[21:01] that it's it is reliable right so um<br>[21:04] these production kind of scenarios are<br>[21:06] reality checks I think for a lot of<br>[21:08] folks<br>[21:08] >> absolutely I think one of the best parts<br>[21:11] of these systems is that you basically<br>[21:14] have a super knowledgeable like we were<br>[21:16] talking about before a super<br>[21:17] knowledgeable co-orker and so it's been<br>[21:20] really interesting to be able to poke<br>[21:22] its brain like really dive in and<br>[21:24] understand how things work it would be<br>[21:26] easy to fall into the trap of just<br>[21:28] pushing it up and sometimes sometimes<br>[21:31] for small things I am like it's probably<br>[21:32] fine but then uh I'll read the code and<br>[21:35] I'll be like oh no actually wait nope<br>[21:37] it's not fine so it is just so important<br>[21:40] to still have an understanding beyond it<br>[21:43] and I think it's just the same as people<br>[21:45] who said oh you can just copy and paste<br>[21:47] from Stack Overflow and it'll just work<br>[21:50] the thing is you have to know what to<br>[21:51] copy and paste from Stack Overflow for<br>[21:53] it to work so I think at least now it's<br>[21:55] hard to imagine a future where that<br>[21:57] won't be the case anymore. But who<br>[22:00] knows? I mean, I'm curious what your<br>[22:01] thoughts are if the role of a developer<br>[22:04] is going to change meaningfully in the<br>[22:06] next 3 to 5 years with these tools or if<br>[22:10] um it likely, like we're saying, will<br>[22:12] still rely on having these the<br>[22:14] knowledge, the fundamentals to um<br>[22:16] diagnose these issues.<br>[22:17] >> For sure. I think like again with every<br>[22:20] technological shift I think people in<br>[22:23] whatever trades that they are need to<br>[22:25] like uplevel their skills right so I use<br>[22:28] this example I think about this all the<br>[22:29] time which is you drive by construction<br>[22:31] sites and you see people who are framing<br>[22:33] houses or putting up buildings right<br>[22:35] it's very very unusual to see them using<br>[22:38] a hammer to do framing right they're<br>[22:41] using nail guns because they can get<br>[22:43] their job done faster but like you<br>[22:45] really want to understand how you line<br>[22:47] up the 2x by fours and make sure that<br>[22:49] everything is plum because at the end of<br>[22:51] it if you get something done very very<br>[22:53] quickly but like it's slanted that's not<br>[22:56] an acceptable outcome right and so like<br>[22:59] while these tools help you uplevel the<br>[23:02] skill I think you still need to have<br>[23:03] that underlying skill you know I<br>[23:05] remember probably a year ago people felt<br>[23:08] like that there was going to be like<br>[23:10] this that people who were coming out of<br>[23:11] university or colleges didn't have jobs<br>[23:14] right they're like if you don't you know<br>[23:15] and so there was like this fear here I<br>[23:17] think in the economy and and I had<br>[23:19] friends who had who whose kids were<br>[23:21] having difficulty getting internships or<br>[23:23] entry- level positions. Um and I think<br>[23:26] that's you know there was some concern<br>[23:28] around well AI is just going to take<br>[23:29] these jobs away. What we've actually<br>[23:31] seen play out and I've seen this at a<br>[23:33] number of companies. There's a company<br>[23:35] that I know that went that plans to hire<br>[23:37] 1,000 interns this year, right? because<br>[23:41] those folks are getting exposure to<br>[23:43] those tools and learning how to like<br>[23:46] update their like use their develop<br>[23:47] their skills materially with the<br>[23:49] assistance of those tools in that<br>[23:51] organization. They also have these very<br>[23:53] senior folks who've recognized that<br>[23:55] these tools can be helpful and are<br>[23:57] quickly upleveling their skills as well.<br>[23:59] The observation from the CTO was it was<br>[24:01] the folks that in the middle that<br>[24:03] actually were kind of reluctant or<br>[24:06] weren't picking up these skills. like<br>[24:08] those folks are the ones who are kind of<br>[24:09] stuck, right? So, they have to like<br>[24:12] figure out what they're going to do<br>[24:13] otherwise they won't be able to keep up<br>[24:15] with the with the direction which the<br>[24:17] industry is moving. I thought it was an<br>[24:18] interesting like shift between like<br>[24:20] you're new, no jobs because AI replaces<br>[24:23] you to actually you know how to use this<br>[24:24] tool really well. We're going to teach<br>[24:26] you the fundamentals while you show us<br>[24:28] how to use this this tool. I thought it<br>[24:30] was super super cool outcome. Yeah, I<br>[24:32] think that also we go through these<br>[24:34] periods of time every few years too<br>[24:36] where we're like, "Oh, there's no<br>[24:38] entry-level jobs." Like I remember that<br>[24:39] when I graduated from college, too, and<br>[24:41] it was, you know, it's like feast or<br>[24:43] famine. I think it's just a cyclical<br>[24:45] nature of everybody saying like, "Oh,<br>[24:47] we're going to offshore everything to,<br>[24:49] oh, no, wait, it's better to have things<br>[24:51] here." And then, oh, AI is going to do<br>[24:52] everything. And like, oh, wait, no, we<br>[24:54] still need humans to do to do this work.<br>[24:56] So, but I do talk to a lot of, you know,<br>[24:58] folks in college right now studying<br>[25:00] computer science that are like, "Do I<br>[25:01] need to go do something else?" Like, "Do<br>[25:03] I need to pick something else?" I'm<br>[25:04] like, "No, I don't. I think it's going<br>[25:06] to be fine."<br>[25:06] >> Yeah. Like, you should probably<br>[25:08] >> Well needed. You know what I mean? Like<br>[25:10] >> Yeah. Exactly. Yeah.<br>[25:11] >> said it's like don't come out of there<br>[25:13] with like a rock or a hammer, right?<br>[25:16] Like, learn how to use a nail gun, but<br>[25:18] like those fundamentals still need to<br>[25:19] exist.<br>[25:20] >> Definitely.<br>[25:21] Um before we wrap up, I actually wanted<br>[25:24] to pivot to ask a bit about your career.<br>[25:26] You've had such a cool path in dev tools<br>[25:29] with building Azure, working on AWS and<br>[25:31] starting buddy build. Um did you have<br>[25:34] any particular moment where you knew you<br>[25:37] wanted to leave big tech and go build<br>[25:39] something yourself? Was there anything<br>[25:41] that inspired you or gave you that itch<br>[25:43] to go off and uh and do that?<br>[25:45] >> That's a that's a great question. I<br>[25:47] think I've been very fortunate in my<br>[25:48] career even working in like big<br>[25:50] companies where I've had the um<br>[25:52] flexibility and opportunity to like<br>[25:54] start early stage projects like kind of<br>[25:57] like quote unquote a startup within a<br>[25:59] large company. Um, and so that's a lot<br>[26:00] how the Azure project actually started,<br>[26:02] which is like, you know, I had a direct<br>[26:04] internet connection in my office and I<br>[26:05] was like, "Oh, it'd be really cool if we<br>[26:06] had these APIs the developers could like<br>[26:08] copy." And I remember like campaigning<br>[26:10] the Microsoft IT folks to be like, "Can<br>[26:12] I just get a static IP address and I'm<br>[26:14] going to register this domain name?" And<br>[26:15] they're like, "What the hell are you<br>[26:16] doing?" And I was like, "It'll be fine.<br>[26:17] It'll be fine." And so like, you know,<br>[26:18] that rolled into to this crazy kind of<br>[26:21] cloud platform. But same thing with AWS.<br>[26:23] I started the Vancouver office here. I<br>[26:25] was the first AWS uh employee and I<br>[26:27] think there's like three and a half<br>[26:28] thousand folks that are here now. Um and<br>[26:30] so and just working for AWS, let alone<br>[26:32] Amazon. And so the next kind of<br>[26:34] opportunity was um buddy build. If I<br>[26:38] look back in my career, like I think<br>[26:40] that I'm just a very mediocre developer<br>[26:42] and like a very impatient person. That's<br>[26:44] what it comes down to. I was like, why<br>[26:46] is this so freaking hard, right? So I<br>[26:48] was like, I'm going to call these APIs<br>[26:49] or like you know what I mean? Like I<br>[26:51] want to do get push and a build happens<br>[26:52] and I get it deployed to my device. It's<br>[26:54] like what? This is shouldn't be rocket<br>[26:55] science. And so when I run into these<br>[26:57] problems or like even now I was like I<br>[26:59] don't want to have to interrupt the<br>[27:00] co-workers. I just want to get this<br>[27:01] stuff done or like I don't want to have<br>[27:02] to dig through this. So just get the<br>[27:03] agent to do it but like do it right. You<br>[27:05] know what I mean? Do it the way that we<br>[27:06] do it here. Um and so ultimately those<br>[27:10] two things I'm like again not a prolific<br>[27:12] engineer by any stretch of the<br>[27:13] imagination. I'm like okay and I'm very<br>[27:15] impatient. So I I try to find these I<br>[27:17] think the intersection of those two<br>[27:19] characteristics are are what resulted in<br>[27:21] in the in the career that I've had<br>[27:23] today.<br>[27:23] >> That definitely makes sense. I think<br>[27:25] that's such a cool experience and so<br>[27:27] cool to see to build a lot of the things<br>[27:30] that we use day-to-day that are just a<br>[27:32] given from the ground up. What a cool<br>[27:34] experience. I'm curious for all your<br>[27:37] experience building these dev tools and<br>[27:39] a lot you it sounds like you um are were<br>[27:43] building with yourself in mind as a<br>[27:45] developer but do you have any lessons<br>[27:47] that you took away from what developers<br>[27:49] actually want versus what they say they<br>[27:51] want as we know developers are an<br>[27:53] opinionated bunch so I'm curious how you<br>[27:55] sort through those uh those in your head<br>[27:59] >> yeah I think it's always I think you<br>[28:01] know I have lots of friends who started<br>[28:03] different companies I think if like if<br>[28:04] you can build a product for developers<br>[28:06] that they love. I think that's a pretty<br>[28:08] remarkable thing because I think human<br>[28:10] nature in general is not to say nice<br>[28:12] things like positive feedback is pretty<br>[28:14] hard to get and I think developers are a<br>[28:16] special breed where you know we still<br>[28:17] argue about like tabs and spaces like<br>[28:19] these the most arcane things right and<br>[28:21] so like if you can get a developer to<br>[28:23] say man I really love this thing that's<br>[28:25] like an extra compliment because you're<br>[28:26] like you're not going to be breed as a<br>[28:28] person let alone as in this profession<br>[28:30] and so some of the lessons I think you<br>[28:32] know what people say versus what they<br>[28:34] want there's always this tension between<br>[28:36] being able to like<br>[28:39] like obfuscate a lot of the complexity<br>[28:41] but still give people the option to like<br>[28:44] doubleclick and drill into the details.<br>[28:46] My favorite example of this is when we<br>[28:48] launched Buddy Build, the signup<br>[28:50] experience was like you pointed to a<br>[28:51] repo and at the end of like a couple of<br>[28:54] minutes, whatever it was, you'd get a<br>[28:56] green build and people thought thought<br>[28:58] it was They're like, "No, no,<br>[28:59] there's no way you could have possibly<br>[29:01] done that." And we're like, "No, no, it<br>[29:02] actually is like a legit build. You can<br>[29:03] deploy it to your device." And people<br>[29:05] were highly highly skeptical. And so<br>[29:07] we're like, "Okay, well, we'll just show<br>[29:08] them like the build output." So like we<br>[29:10] literally had to figure out a way to<br>[29:12] stream build logs off of like some<br>[29:14] remote machine to like a person's<br>[29:16] browser so they could actually believe<br>[29:18] that it was actually happening. And so<br>[29:20] like once they saw that, they're like,<br>[29:21] "Oh, okay. This is actually real." So<br>[29:23] there's always this tension between make<br>[29:25] it just work, but some folks want to be<br>[29:28] able to like I want to change the prompt<br>[29:30] or convince me or show me, prove to me<br>[29:32] that it's actually doing the thing that<br>[29:34] that you that you you say that you're<br>[29:36] doing. So finding that on a spectrum<br>[29:38] like I I find folks who work in<br>[29:40] non-engineering roles are actually very<br>[29:43] happy not knowing how it works whereas<br>[29:45] engineers who are inherently tinkerers<br>[29:47] and be like h I want but you know which<br>[29:50] things people want to know about is hard<br>[29:51] to figure out sometimes.<br>[29:52] >> Absolutely. I feel like these tools<br>[29:54] almost have to be like an iceberg. Like<br>[29:56] simple enough that you can just run with<br>[29:58] it and then uh complex enough under the<br>[30:01] surface that you can really tinker and<br>[30:03] uh and configure it the way you like it.<br>[30:06] >> That's exactly right. Yeah, that's a<br>[30:08] great great way of thinking about it.<br>[30:09] For sure. Actually, I think in one of<br>[30:11] the talks that that's actually the slide<br>[30:12] that I use, which is like what you see<br>[30:15] versus what exists underneath. Yeah,<br>[30:17] it's a perfect<br>[30:18] >> amazing. Maybe that's where I got it<br>[30:20] from. Right. Well, this has been such a<br>[30:22] cool conversation. It has been great to<br>[30:24] pick your brain about your experiences<br>[30:25] and how you're thinking about software.<br>[30:27] As we wrap up, we always like doing a<br>[30:30] little fun segment. And so for this<br>[30:33] episode, we're doing a little game<br>[30:36] called Merge, Fork, Deprecate. So merge<br>[30:39] is the one you'd integrate into your<br>[30:41] life permanently. Fork is the one you'd<br>[30:44] take the best parts from and then go<br>[30:46] build your own thing. And then deprecate<br>[30:48] is the one you'd sunset and move on<br>[30:51] from. So this first one, it's not at all<br>[30:54] inspired by any other game. It's fine.<br>[30:56] >> I don't know what you could possibly be<br>[30:57] relating here.<br>[30:59] >> Exactly. Exactly. Okay. So round one, it<br>[31:02] can be interpreted however, but we've<br>[31:05] got Microsoft WS and Apple. I'm happy to<br>[31:09] go first if you want to noodle on it a<br>[31:12] bit and then we can go in a in a little<br>[31:14] circle. So, I think I would I would<br>[31:18] merge Apple. I was a lifelong Android<br>[31:20] user and switch to Apple a few years ago<br>[31:23] and honestly have not looked back. You<br>[31:25] just like you kind of have to to<br>[31:27] actually use Apple products. You just<br>[31:30] have to say, "Yep, I'm integrating those<br>[31:32] into my life permanently." Microsoft I<br>[31:34] would fork and AWS I would deprecate.<br>[31:38] All right, Erica, what you got? Yeah, I<br>[31:42] think I think I'm also merging Apple. It<br>[31:46] kills my soul a little bit, but I guess<br>[31:48] I'm with you. I've I've made the choice,<br>[31:50] so I guess I have to live with it now.<br>[31:53] >> What?<br>[31:56] >> Wait, what?<br>[32:01] >> I don't know. I mean, I think just like<br>[32:03] the like the there's just a lot a lot of<br>[32:07] like I think mostly like the the<br>[32:09] production line and a lot of the like<br>[32:11] business ethics around like this is why<br>[32:13] it kind of feels like a like a devil's a<br>[32:16] devil's choice here. I'm like there are<br>[32:18] parts of these that I don't like about<br>[32:20] all of these. So<br>[32:22] >> yeah, they're all they're all not the<br>[32:23] best decisions of the world. So you can<br>[32:26] ignore the Yeah.<br>[32:27] >> Yeah. But as far as integrating into my<br>[32:29] life, yeah, I am an Apple user. I think<br>[32:32] I would fork AWS and deprecate<br>[32:35] Microsoft.<br>[32:40] >> Maybe you go next.<br>[32:41] >> Uh, okay. I Let's see here. I think I<br>[32:45] would merge AWS. Actually, I think I I<br>[32:49] wish I could fork two. I don't think I<br>[32:51] really want to merge either of them, but<br>[32:53] I would merge AWS, fork Microsoft, and<br>[32:56] then deprecate Apple because I don't<br>[32:58] need Apple in my life. There's nothing I<br>[33:00] mean, I guess I'm working on a Mac, but<br>[33:01] that's about it. I could easily move to<br>[33:03] Windows computer.<br>[33:04] >> Sure. Um, so having Yeah, having worked<br>[33:06] at all those three companies, there's so<br>[33:08] many different ways of looking at them,<br>[33:09] right? Um, and I have friends who work<br>[33:11] still at all three of these companies,<br>[33:13] so I'm kind of in this precarious<br>[33:14] position. One of the things that like I<br>[33:16] I have a sense for the culture and it's<br>[33:18] not something you can extrapolate for<br>[33:19] the entire organization but certainly<br>[33:20] for broadly speaking. So I'll kind of<br>[33:23] speak to like culture and or focus on<br>[33:26] customers. So we care a lot about an<br>[33:30] enduser experience um with our software.<br>[33:33] Um, so when I think about the AWS<br>[33:37] console, that's something I would like<br>[33:38] absolutely deprecate. That is just like<br>[33:40] brain damage upon brain damage, right?<br>[33:42] Like I don't know how to use that thing<br>[33:44] every single time. Like something<br>[33:46] honestly AWS in general doesn't really<br>[33:49] care about what it looks like. It just<br>[33:51] needs to kind of work. When I think<br>[33:53] about culture though, I would absolutely<br>[33:55] merge aspects of AWS AWS's culture. like<br>[33:59] they have these leadership principles<br>[34:00] that are very very strong, highly<br>[34:02] referenced in their day-to-day like<br>[34:04] operating and and I think that's I<br>[34:06] really really respect that and kind of<br>[34:07] admire it. But from a user experience,<br>[34:09] not not a single AWS product has been<br>[34:11] like, "Oh, this is amazing." That Apple,<br>[34:13] I would probably deprecate because they<br>[34:17] don't they have very strong opinions for<br>[34:19] how they think the world should work.<br>[34:21] And having seen this play out in the<br>[34:23] past at a place like Microsoft, I think<br>[34:25] their lack of customer focus, certainly<br>[34:28] for the developer ecosystem, I find a<br>[34:30] little bit not something I'd want to<br>[34:31] like merge or fork. Microsoft, I have a<br>[34:34] soft spot in my heart for Microsoft.<br>[34:36] It's when I was probably most naive in<br>[34:39] my career. It's probably some of the<br>[34:40] most fun. I've had the longest<br>[34:42] relationships with folks that I've met<br>[34:44] there. I think Microsoft would be<br>[34:46] probably fork maybe merge. I don't know<br>[34:49] what Microsoft is like today. This is,<br>[34:50] you know, kind of on the order of 20<br>[34:52] years later. There seems like a lot of<br>[34:54] people working on the same thing that<br>[34:56] hurts my head from the outside, but I'm<br>[34:58] sure it's it's understood from the<br>[34:59] inside. Um, I don't know that I gave a<br>[35:02] super straight answer like you know on<br>[35:04] those couple of dimensions. That's how I<br>[35:06] think about those companies. You can<br>[35:08] learn from all of them. Uh some things<br>[35:10] you want to like take with you, some<br>[35:12] things you alter, some things you're<br>[35:14] like, I just think that's like<br>[35:15] fundamentally broken. Um I don't know.<br>[35:17] Does that answer the question?<br>[35:18] >> I think that does. It adds a lot of<br>[35:20] nuance to your decisions and um that<br>[35:23] effectively it's very complex what you<br>[35:25] see on the surface versus what you<br>[35:27] experience internally. So that does make<br>[35:29] sense.<br>[35:29] >> Yeah. Yeah, for sure.<br>[35:32] >> All right. For round two, we've got vibe<br>[35:35] coding, pair programming with AI and<br>[35:39] Aentic AI. I can kick us off again and<br>[35:42] we can go in a circle, but um I would<br>[35:44] say probably I would merge aentic AI<br>[35:49] because that's just how it seems like<br>[35:51] we're going and that's what I use most<br>[35:53] day-to-day. Um I would fork vibe coding<br>[35:57] and deprecate parroming with AI. I think<br>[36:00] just because vibe coding has some<br>[36:02] interesting things to take just by kind<br>[36:05] of not worrying as much what's happening<br>[36:07] in the code and letting AI do what what<br>[36:10] you do but also validating what the<br>[36:13] output is and I think that's something<br>[36:14] that will become more important as we go<br>[36:16] along and seems to be some what some<br>[36:19] people are thinking in the industry but<br>[36:21] yeah right Erica I would at this point<br>[36:25] merge pair programming a lot of this<br>[36:27] like rubber ducking that we're talking<br>[36:28] about it would fork agentic AI and<br>[36:32] deprecate vibe coding. Interesting. Feel<br>[36:34] like I would need a more nuanced<br>[36:36] definition of both of them on vibe<br>[36:38] coding. Maybe that's I'm going to fork<br>[36:40] vibe coding just for that reason. I<br>[36:42] would merge agentic AI just like<br>[36:44] Bethany. That seems like the direction<br>[36:46] everybody's going. So would love to<br>[36:47] figure out what that is. And uh yeah,<br>[36:50] deprecate pair programming with AI. I<br>[36:52] think that there's still like a lot of<br>[36:53] value from it. Uh but I find that I am<br>[36:57] giving more and more of the reins over<br>[36:58] to AI anyway. I feel like I'm going more<br>[37:00] towards the vibe coding side anyway. So<br>[37:03] >> I think I'm basically exactly line uh<br>[37:06] with Bethany. I would like merge aentic<br>[37:09] deprecate pair and like fork vibe for<br>[37:12] the same reasons. Actually we see it<br>[37:13] almost identically.<br>[37:14] >> Yeah, absolutely. I do think there's<br>[37:16] value in uh parroming with AI, but this<br>[37:18] is about having strong takes, no nuance.<br>[37:21] All right, finally a very relevant one.<br>[37:24] reading the docs, grapping through<br>[37:26] source code, or asking the person who<br>[37:28] wrote it.<br>[37:29] >> Yes.<br>[37:30] >> Um, so I think I would say I would um<br>[37:35] merge Grepping through the source code<br>[37:38] because that's always going to be the<br>[37:39] most the source of truth. I would fork<br>[37:41] asking the person who wrote it because I<br>[37:43] do like social interaction and they tend<br>[37:45] to have the most context um as we were<br>[37:48] talking about today, but maybe an agent<br>[37:50] will replace that soon enough. And then<br>[37:52] I would deprecate reading the docs<br>[37:54] because they get out of date a lot.<br>[37:56] Yeah. Erica, what you think? Same same<br>[37:59] reasons. Yeah. I mean, I love docs. I<br>[38:01] love well-written docs, but they're so<br>[38:04] often out of date and yeah, it's<br>[38:07] unfortunate. I think I would merge<br>[38:10] gripping through the source code, but I<br>[38:11] think that that's probably a new answer<br>[38:13] for me because I would use an AI tool to<br>[38:15] grip through the source code. I would<br>[38:16] never do that myself. maybe read through<br>[38:18] it and like glance through it, but like<br>[38:20] if I have to type something in a<br>[38:21] terminal, it's a bad day for me. So,<br>[38:23] wouldn't use that. But I would fork<br>[38:25] reading the docs. I think I think that<br>[38:27] there's more parts of like documenting<br>[38:31] that I hope are, you know, I feel like<br>[38:33] it's taking off more and more now as<br>[38:34] we're like, oh yeah, context is<br>[38:36] important. So, I feel like docs<br>[38:37] hopefully are getting better. Um, and<br>[38:39] then I would deprecate asking the person<br>[38:40] who wrote it because that's often not<br>[38:43] even an option, you know, and I don't<br>[38:45] remember what I wrote three months ago<br>[38:47] and why I wrote it. So, if it's not<br>[38:49] written down somewhere, then then I'm<br>[38:51] going to have some problems. Dennis,<br>[38:53] >> I think so, it's interesting like um, as<br>[38:56] you know, users and customers come on to<br>[38:57] unblock, one of the first things they<br>[38:59] ask is like how how like what do we need<br>[39:01] to do in order to get our docs to like<br>[39:03] be AI ready or what have you. And I was<br>[39:06] like, I've never met a single team ever<br>[39:08] that says our docs are up todate and<br>[39:10] well organized. Like it just does not<br>[39:12] exist, right? And so I think just that's<br>[39:14] the kind of state of the world. A<br>[39:15] minutes after you've written the doc,<br>[39:17] it's kind of out of date. So um I think<br>[39:19] I would probably like probably<br>[39:23] deprecate that. I kind of also want to<br>[39:26] deprecate merging like the source code<br>[39:29] or sorry grapping through the source<br>[39:31] code. Um, but I would probably merge<br>[39:33] that because I think that is like the<br>[39:35] the source of of truth and then I would<br>[39:37] fork asking the person who wrote it<br>[39:39] because I I do think there is still<br>[39:40] value in human interaction especially to<br>[39:43] the points you were talking about<br>[39:44] earlier around like creativity, right?<br>[39:46] Understanding why was why did we build<br>[39:48] it this way? Have you thought about<br>[39:49] doing this? Should we try that? You<br>[39:52] know, that thing might have been written<br>[39:53] two years ago and there's opportunities<br>[39:56] for improvement. So, that's how I think<br>[39:58] where I would end it.<br>[39:59] >> Yeah, that makes a lot of sense. I think<br>[40:00] that's a really great point that<br>[40:03] hopefully asking questions to co-workers<br>[40:06] will not be a interrupt thing anymore,<br>[40:08] but actually a really fruitful<br>[40:09] discussion of tools like the ones that<br>[40:11] you're building with Unflocked. All<br>[40:13] right, Dennis, this was such a fantastic<br>[40:15] conversation. It was so great to to chat<br>[40:18] with you. Where can folks find you if<br>[40:20] they want to hear more?<br>[40:20] >> Sure. Um, so yeah, first, thank you so<br>[40:23] much for taking the time. I really<br>[40:24] enjoyed this conversation as well. I<br>[40:25] love thinking about both like the<br>[40:26] technical and human aspects of like how<br>[40:28] this technology is impacting our our<br>[40:31] ecosystem. You can find me Dennis at<br>[40:33] getunblock.com. You can go to<br>[40:34] getunblock.com. I'm on Twitter, but I<br>[40:37] have a giant long Greek last name, so<br>[40:40] good luck trying to spell it, but it's<br>[40:41] Dennis Pillarinos. Uh, so you can try<br>[40:43] that as well. Yeah. And obviously you<br>[40:44] can hit me up on LinkedIn or or email.<br>[40:46] I'm I'm definitely findable. It's not<br>[40:48] quite a unique like kind of a gooid type<br>[40:51] identifier Dennis Perinos, but there's<br>[40:53] only like two or three of us, so you'll<br>[40:55] find me.<br>[40:55] >> Awesome. And we'll make sure to link all<br>[40:57] of those in the show notes.<br>[40:58] >> Awesome.<br>[40:59] >> Well, thank you again for joining and<br>[41:01] thank you so much for tuning in to<br>[41:03] Overcommitted. If you like what you<br>[41:04] hear, please do follow, subscribe, or do<br>[41:06] whatever it is you like to do on the<br>[41:08] podcast app of your choice. Check us out<br>[41:10] on Blue Sky and share with your friends.<br>[41:12] Till next week. Bye. <!-- deep-read:sections end --> ## Highlights - Heavy reliance on personal experience at major tech companies without broader industry validation - Note: 🔍 Fallacy: Appeal to Authority #fallacy/appeal-to-authority