903: Fork Yeah! Microsoft Open Sourcing Copilot  ## Metadata - Author: [[Syntax - Tasty Web Development Treats]] - Full Title: 903: Fork Yeah! Microsoft Open Sourcing Copilot - Category: #podcasts - URL: https://share.snipd.com/episode/88f438dc-5c5f-49cb-8b97-acee78ebc3e2 ## Document Notes ## Highlights - **Scott's Editor Switch Story** - Scott Tolinski switched from Sublime Text to VS Code after initially advocating for Sublime. - His move exemplified convincing developer adoption of VS Code through community influence. Transcript: Scott Tolinski Oh, well, it worked. You were just telling me a story about how, like, I'm a web developer. I'm probably a target audience. I moved over from Sublime Text many years ago. Are you able to tell that story really quickly? Because I thought that was kind of funny. Yeah, no, you were one of the Sublime evangelists eventually, right? Erich Gamma And you saw that, I guess you wrote a book, had a theme about it. And you really talked about how can we convince the community with VS Code, right? And we saw you and we said, yeah, if you were able to convince Vest Boss to talk about VS Code, that's a good milestone, right? And then I guess you wrote the theme and you gave feedback. And so we somehow accomplished that. ([Time 0:01:42](https://share.snipd.com/snip/9a226163-e533-4c50-82d7-d497b56e3a46)) - **VS Code's Growth Journey** - VS Code’s "overnight success" was actually a decade of steady growth and monthly releases. - This approach steadily built a strong developer base leading to 40 million active users. Transcript: Erich Gamma We sometimes talk about it. It's an overnight success, 10 years in the making, right? So we've worked quite a bit before, right? So when we announced it, we worked for five years on it in a monthly rhythm shift every month and we then gradually have grown right it wasn't a big bang right so and it was always this um Growth approach right we have continually growth and we are now at 40 million 40 million 14 million like 40 yeah Yeah. Oh, yeah. That's nuts. Kai Maetzel The growth rate, right, when you compare it to today's growth rates for some of the other tools, right, then maybe it was not that big, right? ([Time 0:03:09](https://share.snipd.com/snip/85072c7c-345f-4a7e-8795-a3436d06e5b0)) - **Open Sourcing Copilot AI Features** - Microsoft will open source AI features from GitHub Copilot integrated into VS Code. - This extends the open source ethos that has driven VS Code’s success to its AI-powered capabilities. Transcript: Erich Gamma Well, it's about open sourcing. VS Code is open source since 10 years. And we want to now open source the AI features from copilot to copilot in VS Code. So it's about open source, which we talked about VS Code success before. And open source is one of the reasons I think we got all this development off, right? We try hard. We try hard to be a good open source project. We try to be transparent, make PR submission easy, listen to feedback, and so on. And yeah, open sourcing is very important dear to our heart. It's a way how we develop. And that's why this announcement is so exciting to me. That's ([Time 0:05:39](https://share.snipd.com/snip/fb83f853-2971-4778-a739-439df972f5e2)) - **Copilot’s Open Core Architecture** - Copilot currently uses an open core model: VS Code is open source but Copilot is a closed-source extension. - They plan to open source the Copilot prompting and client logic for transparency and community contributions. Transcript: Scott Tolinski Really exciting so what that means is that like like explain to us how copilot and and vs code works right now because it's it's like a is it a plug-in or is it like a was it a closed part of Erich Gamma Vs code let me explain how it is and then you explain the whole business story because you initiated the whole thing and you can tell this very well. So today it's an open core pattern we are using. VS Code is open source, of course. It has some AI enabling features in there which are open source, but it's open core the copilot is a closed source extension and there was a good read there is a good reason why we started Kai Maetzel Like that and why there is an evolution and that's where i jump in yes yeah exactly so yeah the um you know when you think about the the story as such right it started actually with GitHub Copilot just completions, right? Yeah. And there at the time, we had really close working relationships, actually, with the folks at GitHub Next who did this in the beginning, right? Because it was about what should the UI look like, right? And this is when ghost text came in, ghost text completions, right? Before we really just had suggest widgets, right? So, and there it was, in a way, like a lot of the smarts were actually just in the extension. It was a fine-tuned 3.5 model, right? So there was a lot of craft, actually, in the prompt creation and all of these kinds of things. And Copilot was, when I say Copilot in this case, the completions, they were really runaway success. You saw a lot of folks kind of seeing this and saying, oh, this is great. This is magical. There were still some who were kind of upset that it was not correct and sometimes proposed something that was not quite spot on. But overall, I think it was a runaway success. And then the GPT-4, right? So JetGPT announcement and GPT-4 came, right? And I think at this moment, everyone really, even the last person started thinking about what are all the other things that you actually can do with AI, right? And what became relatively obvious was that I think the UI pieces of AI need to be really within the flow of what you actually do. So it really starts permeating all of this, right? But at the same point in time, it was still extremely hard to actually get reasonably functioning AI functionality. So there was still a lot of work that actually you had to put in the prompts, the pre-processing of the data in order to create the prompt, then actually post-processing. The models were really bad in actually answering in a format that you wanted them to answer. So there was a of code that you actually had to write in order to make that happen, right? Many different kinds of problems for all different kinds of use cases and so on, right? So that was in a way the technical side, right? On the business side, I think you also have to think about no one really knew how to make a business out of this site. Early on, it was like, oh, this is insanely expensive to run, right? So what do we do? We don't want to give anything away because no one really knows where the market goes and so on, right? So in the end, we ended up, as Eric said, in this kind of open core approach, which is that the UI elements, a whole bunch of the UI elements actually started more and more moving into core. We had to enable some of them through, for example, APIs, right? So we created more APIs and so on. And then parts were in the co-pilot extension. When you then actually think about what really happened over the last few years, right? I mean, you just go, let's say you go to OpenAI and the OpenAI cookbook, right? It literally tells you, oh, here's the best ways of how you write your prompt in order to get, you know, reliable answers. Anthropic, the same story, right? Google just had this 68-page PDF, right, for how to prompt and so on, right? Then you have something like Codex, that OpenAI open source, right, where you literally can follow along how the whole prompt is created and all of these kinds of things. I think the landscape really massively shifted over the last year, maybe two years, right? In a way, how mature it is, how good the models actually became, even working with small little prompts, right? Prompting overall became much simpler. Yeah. So, and if you look if you take this all together right then and now also better understanding of the business models right that what you really have to have on the servers right and that Is pretty much your your secret sauce and what you have on the clients and they became more and more of the way of I should say, not too much specific pieces in there that really differentiate You. And from that point of view, right, we think it's really a time, right, to put all of this in open source. Yeah. You want to have people to be able to kind of go and say, oh, VS Code, I clone it. Now I have cloned it. Now I built it. Now I launch it. Now I have code OSS. This is the out-of kind of version that you run. And with that, you can pretty much type something in the chat and follow along. You can debug all the way how that actually makes it then finally to the server, right? And what the server actually responds, right? And then you can see how these things actually come. You can optimize for it, right? You can find problems. You can fix issues. You can quit PRs if you want, right? ([Time 0:06:26](https://share.snipd.com/snip/a3600b10-38ce-4f81-9b20-e9bc69097544)) - **Context Management in Copilot** - Copilot includes complex logic to decide what context to send to AI models, balancing clutter and relevance. - They now use tool calling to retrieve information dynamically rather than sending all contexts upfront. Transcript: Scott Tolinski Correct me if I'm wrong, but I was always curious about, and we've had the folks from Windsurf on and whatnot, And we always ask them, like, what do you send? Like, are you looking at my clipboard? Are you looking at the open tabs? How do you crawl for that perfect context and how all that works? So with Copilot being open source, we'll be able to see exactly what is being sent to the model and how those, and then also improve upon? Is that one of the big ideas here? Kai Maetzel Certainly one of them, right? Yeah. It changed a little bit, right? In the beginning, for example, you were absolutely right, right? The models didn't support reasonably tool calling, right? And from that point of view, you had to pretty much pack up everything up front that you needed and send it to the model. But then there was also the needle in the haystack problem that when you send too much, the model kind of got confused and these kinds of things. We still do this for completions, that we pretty much pack all of the context up front and then let the model complete that. And there's still a lot of thinking going into it, what needs to be sent along, like, for example, opening tabs, we compute some additional kind of context, depending on if the language Server actually supports that, you know, what types, for example, should be sent along in a stripped-out way and so on. But then there are also other parts that are very, where that doesn't play so much into it anymore, like agentic flows. In agentic flows, you use something that we sometimes internally refer to as breadcrumbs prompts, where you pretty much say, so there is a problem in the problems panel. There's output in the terminal. And so you really just say these things, and then you give the model tools in order to retrieve this information when it thinks that it actually needs that information. Scott Tolinski Oh, okay. Kai Maetzel And that is a much simpler approach, actually. And sometimes you have to help a little bit along with the right prompting approach to say what kind of aspects to prioritize in its considerations and so on. But overall, right, that tool calling made that much simpler. Interesting. Erich Gamma Now, when you say prioritization, kind of what you also have infrastructure, right? We use kind of TSX to describe prompts. It's not just string concatenation. And this gives us flexibility, right? That we can say the nodes in a tree have a priority and we can add more or less depending on the context window. Kai Maetzel Yeah. This is how we render prompts, right? What I was saying is more like in the prompt itself, you tell the tool or you sell the model what tools first to look at, right? For example, check, you know, if there is some problem in the problem, do this first, right? Don't look, for example, in the output of the terminal or something along those lines, right? So you give it some guidance how to proceed through the context. What Eric is referring to is, of course, right, we still have limited context windows, right? And there's a real trade-off here, right? You have context windows that are either technically constrained by the model, right, or you actually want to constrain it so that you get a certain throughput. So the rule of thumb clearly is with the smallest possible prompt that you can send, you want to have the best possible outcome. And so if you pump the full context window, right, then the real question is, and you get a certain outcome, how small can you make it in order to get the same outcome, assuming that the Outcome actually is good, right? And so that is then where pretty much our whole prompt rendering story comes in, right? What are parts in the prompt that you can drop at which points in time, right? Once you hit the context window, once you hit a certain size for a certain portion, like think about history, right? You don't want to just pump, pump, pump history into the context window until the context window is full, right? So what's a natural way of capping this, right? At which point did the conversation flip, for example, to be about something else? And this is not relevant anymore, right? So these kinds of things. ([Time 0:14:57](https://share.snipd.com/snip/24b1b553-3e6c-4493-8eb5-54de103dd48f)) - **Language-Specific Prompts in Copilot** - Copilot prompts are mostly generic, but context for completions remains language-specific due to distinct syntax and types. - Older models needed language-specific 'cookbooks' but newer models require less specialized prompting. Transcript: Scott Tolinski And does that include logic for different types of programming languages? Or is that left up to the model? Like, does the copilot extension have logic for how to treat TypeScript and JavaScript versus like Java? Kai Maetzel So actually, the prompts are not too specific. So there's a history here. And the history is in the early days, absolutely. We had an approach that we called, for example, cookbooks, where we're saying, oh, different languages, different language tools have, for example, different linters have different Errors and different error messages and so on. And then we created these kinds of cookbooks by saying, oh, if you're in a Python file and you use PyLint and you see the particular kinds of errors, here are ways of how you can fix it and What this really means and how you can fix it. And that was quite language specific, right? Sometimes you had to give also hints about syntax and so on. And finally, not finally, just what I said before, on a maturation curve, these kinds of things are way less necessary these days. What we still do clearly, language-specific, is what we talked about, completions, context, because that's clearly language-specific. If a language supports type, let's say interfaces, right? ([Time 0:19:23](https://share.snipd.com/snip/9291945f-2057-4c16-a02a-d67c335c32f7)) - **Open Source Impact on Copilot Pricing** - Open sourcing Copilot client code does not affect paid features since compute costs remain for backend AI services. - Users can bring their own API keys to use Copilot with customizable model access and pricing. Transcript: Kai Maetzel So now, first of all, co-pilot today has a free So you just can sign up and you're on free. There are some limits associated with this, how many premium requests you can get to premium models. There is a base model that we actually have in Copilot where you can continue. There are no limits on those calls and so on. With free, you can also bring your own key. So you put it in whatever API key you already have and you pay for it, you can actually use. So is there a relationship between you paying for really advanced co-pilot functionality and open source. No, not really, right? Because the point is still someone has to pay for the compute, right? To run the LLMs and all of this, right? And that is really unrelated from the open source question, right? Open source means that you can follow along everything that happens on the client and you can see what we send to the servers. And what you pay for then in the end, assuming that you pay and you're not on free, is pretty much the compute on the backend. ([Time 0:21:41](https://share.snipd.com/snip/63376b25-89fa-4a16-a94b-d721eb31f19e)) - **Behind Copilot's Backend AI** - Copilot’s "secret sauce" lies mainly on the backend: indexing GitHub repos and using custom fine-tuned models for specific tasks. - Large foundational models are complemented by specialized smaller models for efficiency and scalability. Transcript: Kai Maetzel There. There are several. Think about it this way. Yes, you can have bring your own key. There are additional services that co-pilot. So the GitHub co-pilot service gives us, right? And Eric made a reference to one of them, like finding relevant source code snippets. So what happens, right, is GitHub, when I say GitHub, the team on the GitHub side is actually indexing all of those repositories that are all open source repositories. You can opt in for your private repositories to be indexed and so on. But what indexing really means, as I'm pretty sure you've heard that before, is the code pretty much gets chunked, and then embeddings are computed for each of those chunks. And then when we look for relevant code, for example, what happens is we take that query that the user types in, and then we compute the embeddings for that query. And then we pretty much go and find embeddings that are relatively close to this in the repository. And that, for example, is functionality that GitHub provides us. Is that secret sauce? There are some clever things that are being done. But I wouldn't call it secret sauce, but it's clearly about scalability of all of this. Think about this. I don't know what the latest numbers, but something like 500 million repositories on GitHub and so on, right? So there's a massive scaling infrastructure behind that, right? Then there are some other use cases where, for example, new models are really good in editing files, for example, right? So Sonnet has the replace string. So you can search for a certain string, find it, and then replace it with something else. And the model's very reliable in giving you this. The new 4.1 models that OpenAI, they give you something like, it's called apply patch. So they really give you this kind of diff patch format to something, right? And they're also very good in doing this. So, but there's a lot of other cases where models actually are not good in doing something like this. But then there's another technique where you just go and tell the model, hey, pretty much give me a rewrite of the file and align all of the code that is pretty much the same of stuff that Has not changed. Just say, here's existing code, right? And then you pretty much give it the original file plus that kind of rewritten file with the alighted spaces. You give this to a model and now fiddle it all together so that the reasonable outcome comes out, right? And that, for example, is a custom model that does that, right? And we do that many times a day, right? So that needs to be cheap to run and so on. And when you want to run it cheap, right, then you need to have custom models that you, the smallest possible model that does a really good job at it, right? So that, right, that's, for example, and then the completions models are clearly custom, right? Then next edit suggestion, right? That is the tap, tap, tap kind of functionality, right? You had some particular plate, you made a change. Here are all the subsequent changes that you should make in order to make it consistent again, right? That is a custom model. I think this is what you will see more and more, right? What really happens is you can take one big model, right? And the big model is really smart at doing things, but it's also really expensive at doing things. And it's slow at doing things, right? And what you want is you want to make it for the use of fast. And for you, as you know, you want to put little load on your service infrastructure. So you've got to then pretty much distill and distill, distill, right? ([Time 0:24:00](https://share.snipd.com/snip/9475cf6b-92e0-4d0c-bb76-1e775fc5b2a1)) - **Balancing UI Innovation and Consistency** - VS Code weighs innovation against UI consistency and platform extensibility when integrating AI features. - They study other forks’ interfaces but prioritize a scalable, lean UI that respects existing design patterns. Transcript: Wes Bos Okay. I do wonder about the UI bit of it because we've seen kind of the rise of the VS Code fork and experimenting in different UIs for these types of things. How much do those design choices modify your thinking in terms of what the VS Code's interface and how it should relate to working with AI? Or do you have your own experiments? I mean, I'm sure you do, but is everything that comes out into VS Code informed by your own experiences or is there influence coming in from others in the space working in these types of UIs? Kai Maetzel Mark, clearly it's informed by others as well, right? I mean, even today, issues for Copilot, for example, are open, right? There's the VS Code Copilot release repository where, you know, you can look at issues. People make feature proposals there. In the VS Code core repo, right, many issues actually land directly in the open source VS Code repo. Lightrun saying, oh, I do this, right? And you have this button here, but I really like to have this button over here because there are two others who put the button over there. So from that point of view, clearly, right? Their influence comes also from others. But I wouldn't say that this isn't the, this is just like tool development always happens, right? You take good inspiration from others, right? You would be stupid not to do so. But at the same point in time, you need good scrutiny in what you actually really do and what you don't do because you need to maintain your identity. You need to think about the users that are already there, the UI patterns, they already do understand. Then also a big difference for us is our extensibility story. Like for example, we always need to think about something like, oh, if we put a button here, who else wants to put a button here? And then in the end, you have 15 buttons, and then, right, that doesn't work. So how do we make UI scalable, keep it still lean and clean, don't lose our own design language by still picking smart ideas that other folks had, right? ([Time 0:29:02](https://share.snipd.com/snip/014e93e4-356c-4cb7-b7b9-d77aba056e12)) - **Open Source Builds Trust, Shifts Competition** - Open sourcing AI client code empowers enterprises to audit Copilot’s behavior fostering trust. - Business competition shifts to backend AI services and infrastructure rather than client-side code. Transcript: Scott Tolinski You know, what happens there? Erich Gamma What do you mean by have the rest? Sorry. Scott Tolinski Like, so they fork VS Code and then add their own AI stuff on top of it. And now you're saying, well, here's our AI stuff as well. You can have that as well. Like anybody can have it. Anybody can build upon this as well. Is there like a strategic business reason that Microsoft is doing this? Erich Gamma Maybe one thing is what we heard from some organizations, they really don't like closed source IDEs. So by making the other pieces open source, I think we address that need, right? But that's more for these bigger organizations. And of course, they have a choice between closed source and open source. Kai Maetzel You put the disclaimer up front, right? We're engineers on the project. Yeah. A pure business person might answer that somewhat differently. Yeah. But when I think about this, the part is really, could they take whatever we have, right? The whole thing. Could someone take the whole thing, put a new batch on it, and say, this is now ours and mark it under their name? Sure. Right? But we also know how pretty much the open source community has reacted for, for many years when someone tried to do this with VS code proper, right? There was always immediately this question, why would you go some, why would you do this? Why would you not bring the changes back to VS code? Why would you not work in, favor of the overall developer ecosystem? I think the competition, at least that's my point of view, right? Will move more and more to the services that you actually provide around this and really what's running on the backends and all of these kinds of things, right? Right now, for example, we have, and I'm purely speculating here, of course, right, but right now we have access all to the best frontier models. So OpenAI, Anthropik, Google, all of them give the models out. But you could also imagine a world where that is not the case, where people actually try to create very, very specific models and keep certain kinds of secret model source just to themselves And to their own AI tools and so on, right? So I think, again, as it was in many other cases, right, what really matters, right, is on the servers, how that is done. This is how you scale, how you provide in the end lasting value to your customers, right? And what happens on the client, those things you want to trust. You want to see what is happening there. If you're a big enterprise, you want to see and pretty much audit those things, right? And make sure everything is good, right? Like we have discussions, right? With enterprises that come and say, yes, so what do you put in your prompt? What really is this, right? And like you, you ask, so what's the context you put in there? And people are like, whoa, really suspicious about what you put in here and all of this, right? I was like, yeah, have a look now, right? Go, look, right? So it's all there. You can do it, right? You can see it. So I cannot really tell you what it does to Cursor's business, but it's also their business, not mine. That's where real competition happens, right? And what we do on the clients, again, right? ([Time 0:33:30](https://share.snipd.com/snip/2c09d31d-b459-42de-a11d-6ccd912a4444)) - **API Limits Spur VS Code Forks** - VS Code’s API limited deep AI UI innovation, prompting forks that integrated AI in their core rather than bolted on. - Microsoft prefers stability and performance, making some UI extensions intentionally unsupported. Transcript: Erich Gamma So I find it a missed opportunity that there was no collaboration on that, right? Because we're a small team. The other forks are small teams. And I think both talented people. So we could have done maybe something even better for the whole thing because the whole value is in the back end in the end. Wes Bos Yeah. In that regard, was it a surprise when these forks started popping up or was it something you all had anticipated? Erich Gamma That was a surprise, right? And it's, of course, a fork for an open source do it like KindR is not a pleasant experience, right? And when you see about, and of course you want to understand why, and of course one is the API thing. Yeah. But I must say, even though the API is not really made for deep UI innovations, what we see is the community innovates a lot on top of our existing APIs. Right. This is some nice AI editors extensions also. So this always blows me away how much creativity our community has to do innovation on top of our UI. But it's only true. Deep innovation below it is challenges. Yeah, this was one reason. The other thing, of course, is what others make me jealous about them. ([Time 0:38:23](https://share.snipd.com/snip/a47a3374-ae27-4ce4-89ac-5f877c2e303f)) - **Use VS Code AI APIs** - VS Code already supports AI integration APIs allowing extensions to participate in chat and use AI models. - Developers should leverage these public APIs to extend AI features across diverse tools. Transcript: Kai Maetzel Actually a couple of things here. The first one is we actually made that available before. So there is, for example, in the VS Code API namespace, there is an LLM namespace. So you can create, for example, chat participants, and then those actually can participate in a normal chat conversation, right? The tools, for example, that models can call, right? Those tools are already public APIs. So extensions can contribute tools. MCP servers can contribute tools, right? There is a way you can just, as an extension, just read all of the tools that are available. You can craft your prompt, send it through the model, through our APIs. That is actually stuff that already exists today. And there's a good ecosystem around this. When you look at Klein, for example, they use some of that API. In their dropdown, they can say, yeah, use the models that you get through Copilot. But they also do some other custom pieces. But will there be more APIs going forward? Probably. Do we know right now what they will look like? No, not quite yet. Erich Gamma But the mindset, right? It's still like in VS Code. ([Time 0:40:30](https://share.snipd.com/snip/ae36ff8e-b16b-48ba-90de-ef82f1005f9f)) - **Transparency Enables Community Fixes** - Open sourcing Copilot will let developers inspect, debug, and improve AI prompt logic themselves. - This transparency enables community-driven fixes and enhancements improving Copilot’s reliability. Transcript: Scott Tolinski Totally, I agree. I'm excited about it because, I don't know, a couple of years ago, there was a bug in Copilot where it was adding like an extra curly bracket at the end of all the tabs. And I was losing my mind over it. And I was like, if we just had access to this thing, and I couldn't even fathom how it was working or what was going on or how edits get applied. That's all kind of black box to me. So I'm very curious now to actually dive into the code and see how that stuff works. Erich Gamma Maybe we should say, right, we announced that we will make it open source, batteries work ahead of us. ([Time 0:42:47](https://share.snipd.com/snip/d031face-4255-482e-8be6-46c0d5806d89)) - **Challenges in Open Sourcing AI** - Open sourcing AI code requires cleaning proprietary test cases and handling stochastic LLM tests with special simulation tests. - They commit to a transparent rollout process with public updates and community interaction. Transcript: Kai Maetzel What do we do with the, like, for example, we invented this whole mechanism of what we call S-test. Think about it, this unit tests that can deal with the stochastic behavior of models, right? So you don't run the test just once, you run it several times, right? You cache responses from LLM. And it's very interesting what we did there. That's cool. Erich Gamma But now there is a lot of- S-test, Emma. So as a person who worked on unit testing, right? So the big problem is when you have in a test anything with LLM, then the test becomes stochastic. And testing, the worst thing in unit testing is flaky tests, right? You hate flaky tests, right? But as soon as you have an LLM in there, your test is by definition flaky, right? And that's what we try to address with what Kai explained, the simulation test, right? Which is pretty cool technology, but also that will require work to package and make available and think about that. Kai Maetzel Make available then the actual test cases, right? So how do we get good test cases, right? That is usually from internal kind of flights, right, where we can actually really look at the at the concrete prompt that was being sent, right, with a concrete source snippets and So on. Right. I'm saying, oh, in these particular cases, it failed. Right. Then we added it, for example, to our S test suite. Now we've got to clean this all out, right? We cannot make these things available publicly. So there's no work to be done, right? So we'll start pretty much today, right? With the announcement that that work is starting, right? And then we'll make sure step by step by step, right? That we go. I think our main point here is we make the announcement. We don't throw it over the fence, That's not how we work, but we will provide transparency in every single step that we take here, right? So do you know exactly what to expect, right? And you know all of our iterations plans are public, right? There are even pinned on the issues, right? For every single month, GitHub repo. There will be entries in there. You can follow along. You can ask questions. That's how we operate. So we will make sure that there's a fully transparent process. Will you see everything right now? No. I just mentioned why there's things that we need to do first. ([Time 0:45:38](https://share.snipd.com/snip/1917636b-21e8-4743-9b35-7a62430b6e47)) - **Future Devs as Multi-Level Creators** - AI will expand software creators, requiring fluency across multiple abstraction levels from ideation to debugging. - Developers must adapt to quickly shift focus between high-level design and deep technical detail. Transcript: Scott Tolinski I do have to ask, just like switching things, because you're in this AI space, obviously. Do you have any opinions on what future of software engineering looks like with AI? Are we out of a job? What are your personal opinions and thoughts there? Kai Maetzel Oh, if he only would knew. No. I had this conversation just the other day with someone, and I made a statement there where, independent of what it will look concretely, I think you will not have just people who are Just at one particular level of abstraction, right? Really deep, just do, I don't know, optimization for one particular aspect. Maybe a few of them will survive, right? But you could make a good living as a developer by being quite specialized, right? And I don't know if this will remain true, right? What I believe is that as a developer, you need to be what a developer will be in the future, or creator, maybe we should just call them creators, right? We'll be going across many different levels of abstraction in pretty much speed of light, right? So you think about a product idea, you've scuffled something out, you run it, it fails a little bit. So you went all the way down, right? Just to fix a tiny little issue. Then you go up again and think about your customer, right? And think about changes and think about design. You go down again, right? And this, I think this flexibility, right? The thinking about your users, I think developers will become a little bit more entrepreneurial in their whole way of how they think about this holistic, how they have to approach a Problem, right? And I think that's where that, I would guess where that really goes, right? Where you live on all of those levels of abstractions very, very quickly. And today you could make a comfortable life to kind of just sit here and never go down or just be a PM and sit up here and never really, you know, go down. So it's like, I think that that will go away, right? Interesting. I think that the most powerful people will be those that can think in all of these levels of abstractions pretty much fluently going up and down yeah you're not the first person that said Erich Gamma That to me so what's definitely true for me is there will be more creators right given all that i think there will be more creators but i also think if i look i i like to explore it by looking Back and looking forward, right? ([Time 0:49:10](https://share.snipd.com/snip/306f7988-fcaa-4577-bef3-907920bdc7a7)) - **Wider Cursor Made for Scott** - Kai Maetzel personally followed Scott Tolinski on Twitter to quickly implement a requested feature: wider cursor for visibility during presentations. - This story highlights open communication between VS Code developers and users to improve the editor experience. Transcript: Kai Maetzel And I mean, we started with this, right? Thank you for helping us making Vs.coot great, right? I remember the one feature that we just built for you. What was it? Oh, I think because I forgot where it came from, maybe from a tweet or something, Eric might remember. It was like, oh, you know, when I present in my courses and so on and talk, then people cannot see my cursor. So I need a little bit of a wider cursor. So we made an option to make the cursor wider. And that was literally just for you. I love it. That was just for you. Yeah, I was, I appreciate that. Scott Tolinski I was like, I think I was hacking it with CSS at the time. Because like my students needed to see where I was with the cursor. So I just made a huge, big, blocky one and threw it in there. So you appreciate that. And then we gave you a setting for it. Man, we were tracking you on Twitter, right? We were following you. ([Time 0:56:05](https://share.snipd.com/snip/abd83038-e84a-4746-be8a-ee243aa3384c))