We're All Builders Now  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: We're All Builders Now - Category: #podcasts - URL: https://share.snipd.com/episode/531227dc-7a52-43c3-b026-2bb4b217a75f ## Document Notes ## Highlights - **Amanda Silver's Leadership Journey** - Amanda Silver shared her journey at Microsoft, starting in systems and API design before moving into management. - She emphasized the importance of people in software development and maintaining personal integrity as a leader. Transcript: Jerod Santo What does it all mean? Amanda Silver What does it all mean? I mean, I think at the end of the day, there's a group inside of Microsoft that's focused primarily with developers as our primary customers. And so when you think about what does Microsoft actually deliver to customers? Visual Studio Code, Visual Studio, you know,.NET, TypeScript, you know, our Azure application platform, you know, our DevOps solutions, right? We work very, very closely with a GitHub team, do a lot of product integration across our products. So that's kind of what the gig is. Adam Stacoviak How do you feel about leading people? Is it fun for you? Amanda Silver I love leading people. I mean, I've actually done it since fairly early in my career. I think maybe two or three years in, I started to be a manager of people. When I first started at Microsoft, I was working on the interop layer between.NET and unmanaged code. And so I kind of think about it as like I started at like the systems level. And then I started working more and more on programming language design and API design. And then from there, I got more involved in the editor experience, the debugging experience. And that's about when I started to become a manager. And, you know, for me, I think initially it was a way for me to have more control and more, you know, more influence over the product. So that was exciting. But I think over the years, I think I've, you know, I think anybody who's been in the industry long enough recognizes that like software is 90%, 95% about people. And how do you construct the team? And how do you motivate them day to day? How do you have the right balance in terms of trying to push them to do what they may not be ready to do on their own versus when do you take the temperature off and let them kind of recoup from An intense period? So I find a lot of joy in the act of management. And I also will say I've come across a lot of managers in my history that are much more self-serving. That's their primary objective. And empire building, a lot of people call them. And for me, I think it's really important that I maintain my personal integrity. And I have to check my ego a lot to make sure ([Time 0:03:55](https://share.snipd.com/snip/24ead366-a6ad-40cb-980b-a0bad75c9be4)) - **TypeScript's Open Source Strategy** - TypeScript was created to align internal Microsoft developers with the broader JavaScript ecosystem. - Open sourcing TypeScript helped overcome community hostility toward Microsoft and gained adoption. Transcript: Amanda Silver But open source wasn't in the vernacular. It wasn't a thing at the time. At the same time, I think it was.NET, ASP.NET, that was the first to actually include open source in the product, jQuery. Everybody had to use jQuery to be able to manage the different browser experiences. And so we first started to ship jQuery as part of ASP.NET, I guess in the 2008, 2009 kind of era. At the time, I was moving more, I kind of moved into the JavaScript space. I started to work on, around 2009, 2010, I started to work on the Chakra JavaScript engine that was inside Internet Explorer at the time. And that was like a really big change in terms of the day-to competitive atmosphere that we were working in, right? Enterprise software moves much more slowly than the pace of the web at that time. And so it really changed the cadence for what we had to think about. And that's actually when we started to work on TypeScript. TypeScript, you know, originally when we first started was really trying to answer the challenge that we had inside Microsoft, which was that we were building what we now call M365, Which is like, you know, the web experience for Excel and PowerPoint and, you know, SharePoint and everything. But we had this challenge that we had a lot of developers inside Microsoft that had deep, deep, deep familiarity and decades of experience with C++ and C Sharp. But they really didn't know how to build for the browser. They didn't know how to build complex applications in JavaScript. And actually, at the time, the industry didn't really either. There wasn't really... Do we now? We're a lot better. We're getting there. But a lot of the challenges were really about encapsulation and modularity and how do you create modules. And so that's where TypeScript came from. And that's when we, TypeScript was really our first open source project that we did fully open source from the get go. And I remember in that era, it took me like six months to convince the muckety mucks that we should. How did you finally convince them? What was the winning argument? I think the argument was, so our objective at the time was to make sure that our internal developers didn't end up on a different path than the broad open source ecosystem that was benefiting From the evolution of JavaScript. Right? Had decades of experience at that point of building our own C++ compiler that kind of became really more the internal Microsoft C++ compiler and was divorced from other paths of C++ Compilers that were being used more broadly in the industry. And there was a challenge in terms of trying to keep them aligned. And so over time, the internal Microsoft developers didn't get to benefit from what was happening in the broad industry on the C++ compiler. So with that experience, looking at this problem of how do we address this large-scale JavaScript solution challenge, we decided, first of all, we have to kind of stay in line with what The broad web industry is going to end up using. But then secondly, we also thought that if that was going to be the case, if we wanted to create something where we call it first party equals third party, meaning that our developers Internal to Microsoft use the same tools that our third party developers use, our external developers use. If we wanted to accomplish that, then we had to build something that the JavaScript community would actually use and like. And at that time, there was still a fair amount of hostility towards Microsoft in that community. ([Time 0:08:26](https://share.snipd.com/snip/91fb48ea-642f-44d9-a59e-17f3ac5c79d2)) - **Manage AI Coding Complexity** - Design AI coding agents to limit cognitive load by controlling how much code they generate. - Use both synchronous (agent mode) and asynchronous (coding agent) workflows tailored to developer preferences. Transcript: Amanda Silver I think that's something, first of all, that we need to think about in the design of the tool itself, right? We need to make sure that we are not introducing something that creates so much cognitive load for you to ingest in terms of change management that like it's beyond your ability to reason Over. Right. So we, we are very intentional in terms of like how we guide the prompts to, to kind of control just how much code is actually going to be generated. Other reasons that we do that as well. But I think the other thing is, you know, we really want to make sure that we are working with the workflow that you're used to right so another thing that we introduced today is the coding Agent where you know if you think about agent mode in vs code as the experience that allows you to give it a prompt and then you can do synchronous supervision over how it's completing All the tasks in that prompt. The coding agent is asynchronous. And so you can almost think about it as agent mode is your peer programmer. It's looking over your shoulder. It's accelerating your capabilities. But the coding agent is your peer programmer where you can assign tasks to it as though it was another member of the team. And so it's just like in GitHub, if you're assigning an issue to your colleague, you would instead assign it to Copilot and it can asynchronously go and execute that task and figure out What it, come up with a plan and go and create a pull request and complete that task for you, right? And so what that I think enables is for you to then still think about the tasks that you're assigning to the agent in the same granularity that you would assigning it to another developer On your team. Right. Adam Stacoviak So you could theoretically do a multi-file edit, like build something, prompt it for that, and then run an agent against that and say, debug this, make sure it's sound code. Correct. So versus, you know, like your question was the fear of the code sucking, basically. Right. I got my code review agent. I got my coding agent. Well, don't worry, because at the end, you can just unleash your agent and just say, agent, check that. Amanda Silver I mean, you could certainly have parallel, you know, adversarial agents kind of working against each other. You could set up that kind of system where, you know, you basically start to build your code. ([Time 0:31:38](https://share.snipd.com/snip/cae905aa-110f-474d-860c-e52d10838bd6)) - **AI Amplifies Developer Talent** - AI can help erase technical debt, freeing developers to build new innovations. - There is still a global shortage of developers with system-level reasoning skills, making AI an amplifier for talent. Transcript: Amanda Silver I mean, I think in a lot of senses, like we've been struggling. I wouldn't say struggling. I would say limited by the available developer talent in the world. We still have a shortage of developers, in my opinion, right? A significant shortage of developers across the world. And especially developers who have higher level systems thinking and reasoning capabilities, right? And so I think that in a lot of senses, what this all represents is an opportunity to kind of spread that knowledge a bit more broadly. And like think about all of the apps that, you know, your organizations wanted you to write, but you never got to because your backlog was so long. Right. I think there's huge amounts of demand and need in the industry overall that is just not getting addressed today because developers are saddled with like technical debt and they, you Know, what they already have on their plate is significant enough to occupy them. Right. And so if we can actually erase a bunch of that, I think that's going to make a, make a huge difference overall. ([Time 0:40:20](https://share.snipd.com/snip/09b79cfb-6d3e-478c-9028-6443965b452b)) - **Control and Audit AI Agents** - Ensure AI-driven agent workflows are fully auditable and controllable. - Implement model testing and common control layers to prevent agents from going astray. Transcript: Amanda Silver A fantastic question. Jerod Santo Guys. Well, just the team. Amanda Silver So I think generally what our approach is is that we want to make sure that every agentic workflow is completely auditable so that we can see what the agent is actually executing, look Over it in history, that we do have controls over it to be able to say, these are the resources that you have access to. And we also have to think about things like ways of testing the models themselves, whether it's a model that we build or it's a model that you build for your software. And that's part of what we build with the AI Foundry that allows you to actually evaluate the models against all different kinds of checks, whether that's, you know, safety and security Checks, whether that's responsible AI kinds of harassment kinds of scenarios or, you know, language that's inappropriate. A lot of that is really what has to get built as a part of kind of building and evaluating models themselves. And then we also want to have this common agentic control layer across all of the software that uses agents so that we can see what those agents are actually actively doing, what resources They have access to, and restrict what they have access to if they start to go astray. ([Time 0:52:53](https://share.snipd.com/snip/8736cdae-b470-4825-8f4e-38396827c18c)) - **The Emerging Builder Team** - AI enables designers and PMs to contribute code, blurring traditional roles in software teams. - Future software may focus more on models with views defined declaratively, changing development architecture. Transcript: Amanda Silver So what does that mean for how we think about the evolution of the software development team? And what canvases do we think we need to do collaboration? Adam Stacoviak I think of it like giving somebody who the whole team or the whole group of people you just mentioned, they all speak a language. Let's just say it's English, for just lack of better terms for this analogy. I think of it like these folks have a limited vocabulary. These folks have a limited vocabulary and they're all specialized. And now they have a more shared language spectrum because you have the words, we have the words, we can share the words. That's called speaking, of course, as you know. But I feel like that's what it does. You now give them, they all spoke English already because they all understood some of the code, some of the design, some of these different features, but now they can all speak a certain Language. Amanda Silver I completely agree with you. You know what I mean? But I think that part of what's going to happen is that everyone is going to start contributing to the code base more easily, right? Adam Stacoviak Which is better for the product. Amanda Silver I mean, and the user, obviously. I think so too. But I think we're already starting to see designers contribute code, right? In terms of like, rather than handing a design over the wall and say, engineer, go implement it. No, the designer can actually go. And if they want rounded corners, they can get rounded corners to happen, right? Even if a PM has an idea around a new feature that they want to experiment with, maybe they can go build an initial prototype with that without having to go bother the engineers to go get That done, right? And I think that starts to kind of raise interesting questions around how do you think about architecting different kinds of systems. I think, you know, maybe one of the things that might happen is that there's a difference between solutions that are more sitting at that SaaS level versus services that are more at the Systems level, right? I think that that SaaS level is going to start to be something that is more easily extended. You know, today, when we think about something like a Microsoft Office or M365 or we think about something like GitHub itself, it's essentially an end user experience, a SaaS, that Is being provided and it has extensibility points. Painstakingly crafted. Because every time that you expose a new API that allows you to customize the environment, it both empowers your users to go build other things, but it also represents kind of a boat anchor That you're stuck with the back compatibility for that contract, right? But I think that what this is now kind of enabling is for you to start to build other systems, other automation on top of other systems much more easily, even without the API, to be frank. Because now it can just like traverse the DOM or whatever it needs to do. And I think that means that like a lot more software becomes a lot more extensible. And I think that that means also that the way that you build software itself is going to end up changing over time. The other thing that I think is super interesting is like, we also spend a huge amount of time right now on the view, creating the view. Jerod Santo Sure. Amanda Silver Right? Like an MVC kind of model, right? Yeah, totally. I think in the future, like, it might just be that you focus on the model. And the view, you actually go and specify with a design system. Well, ([Time 0:59:05](https://share.snipd.com/snip/00b42723-ca8d-4fd5-893e-8407019e9d36)) - **Open VS Code Shapes AI Coding** - Microsoft's open-source VS Code ecosystem fosters competition and collaboration. - AI capabilities like GitHub Copilot are now table stakes and integrated openly into VS Code. Transcript: Jerod Santo Are these just like the cockroaches that you just say, get out of here, cockroach? Or how do you guys view it? How do you view it? Kelsey, I'd tell her that one. I love you, Kelsey. Amanda Silver I think that there's real that's happening in the industry and a level of competition that we haven't seen for a long time. So I have a tremendous amount of respect for the competition that we're seeing right now in the code editing space. I will say, yes, I think that there is a lot that has been built on top of the open source code base of VS Code. And I think that is creating a foothold that allows others to kind of go and create additional features or differentiation on top of it. But that's, I think, one of the reasons why we've decided to actually open source the GitHub Copilot extension for VS Code and build it directly into the VS Code code base is, you know, We really do think that the AI experience is now table stakes for any code editor. And in the same way that VS Code has been open from the get-go, we think that now the AI capabilities in VS Code also need to be part of the open source code base. And I think that, you know, we certainly believe in, you know, whether it's VS Code or TypeScript or, you know, anything that we do in like the Azure SDKs or.NET, like all of that's open Source. So like half of what my team works on is done in the open and open source. You know, we certainly see that when, especially when you're trying to build a community around a technology, an ecosystem around the technology, building in the open actually creates Better products. You know, it allows more people to contribute, whether they're contributing pull requests and code contributions, or if they're just logging issues and just, you know, they care Enough to actually follow through with really great issue descriptions. That's an important way to contribute to the code base. And we see that across all of our open source code bases. And I think what we hope to see now is there's a tremendous amount of innovation that's been happening in AI-based coding. What we hope to see is more of the community contributing back to the VS Code code base to really advance the state of the art for everybody. Adam Stacoviak I'm not sure I would call them competitors, though. Jerod Santo You don't think Windsurf is a competitor of Copilot? I would say... I'm going to use one or the other, aren't I? I guess so. Adam Stacoviak But is that your customer, for lack of better terms? Jerod Santo Oh, they want all the customers, don't you? Adam Stacoviak I don't think so. I think... Let her answer. Well, this is what I assumed you were thinking. And you said a lot of things, but you didn't say this. But if I read between the lines, and I think if I were you, I wouldn't see it as competitors because you are focused on developers using VS Code. And I don't think they're not developers, but if you're vibe coding, it's not a developer action. It's a different way to get the end result. Yeah. Right. A developer writes code and cares about the code, whereas the other way is not so much less about the code. It's a different way to get there. That's how I'd look at it. Amanda Silver So I think there's kind of two pivots to that. First of all, I would say I think that code editors generally, if your primary task is to write code, then I would say any of the popular code editors are competitors in a sense. But to the point earlier that we were talking about, we believe that we live or die by day-to product truth. And we have to basically win every developer based on their usage and experience with our products. And we strive to make the best products we possibly can. I think to your point around vibe coding and how does that relate, I see vibe coding as a really interesting evolution, right? It's not quite... Adam Stacoviak I'm throwing zero stones at that. I'm an agnostic when it comes to all innovation. Whatever gets us to the next place, we all love it. That's what I'm for, right? And if Vibe Coding is one of the ways we get there, or it invites more people in to build software, cool. Amanda Silver I think Vibe Coding invites a lot of people in to go build more software. ([Time 1:03:55](https://share.snipd.com/snip/07386e08-7c97-4b22-beaa-6bae3a499f11)) - **Formalizing Spec-Driven Development** - Spec-driven development is becoming formalized with specs and design decisions checked into codebases. - Conversations and decision histories may be persisted alongside code to improve understanding and documentation. Transcript: Jerod Santo I think that's really insightful. And one of the things that I've noticed as an experienced developer trying to adapt and adopt the tools is that software isn't built in like a chat scenario. Like we don't chat your way to a software system because there's just like so much chatting that goes up. You know, you design specifications and yeah, you may have conversations that lead to that design decision that you make. Once you make that, you don't want that to be like one moment in a conversation that was way up here. You got to tell your coding agent to scroll back and remember what I said back then. You want to actually have tangible outputs. A spec that gets created through whether it's a vibe session or just a peer programming session. Now I have this written document that evolves. It would be so cool to be able to take that spec and be like, all right, here's a different model. You know, start fresh. We don't need to use the code. We have the spec. Yeah. And like you write the same pro you can take the same spec, six different models, write the program, you know, may take the best one on each or whatever it is, have something that you could Like start from. So you're actually building out an architecture. Yeah. Amanda Silver But I think is that formalized? Yeah it is. I mean, we now are starting to do more spec-driven development. We have.prd files that would be the description of the spec. And those kinds of things are starting to get checked into the code bases. But I think also there was a nugget in what you were talking about in terms of like design decisions that are made throughout the process. Sometimes it's not just the spec that you actually use. Well, it's the conversation. Or another engineer on the team in terms of how something should work, maybe over time the history of that conversation should actually be something that's persisted into the code Base in some senses. Jerod Santo And hopefully in a summarized fashion. Yeah. So it's actually grokkable. Yeah, exactly. I know there's some people that keep actual, I can't remember what's called, a why document, but it's basically around their decisions. Not the decision we made, but why we made the decision. Right. And so you can go back to that and be like, no, here's why there's this fence here. Exactly. You see a fence, you're like, why is the fence there? It doesn't need to be there. It's like, well, there was a reason. And none of us know why it's lost to history. Right. But now you could go back to that chat or that context and at least link it somehow, whether it's summarized or linkable or whatever it is, to be like, here's our spec. And then this part of the spec here, why is it like that? Well, here's the why. Yeah. Amanda Silver Maybe in that world, developers don't have to write documentation. Jerod Santo Now you're selling me. Adam Stacoviak Oh my gosh. Or they write one. They write one, the initial spec. That's right. Yeah. I was thinking about that too. Amanda Silver All ([Time 1:09:43](https://share.snipd.com/snip/15e61c62-f0c0-462c-9eb9-9ef1a66d82ae))