In this episode, I sat down with Pascal van der Heiden to talk about how fast AI-assisted development is changing the day-to-day reality of building software. We got into his current workflow across Azure, GitHub Copilot, Visual Studio Code, the terminal, MCP servers, and Microsoft Foundry, and explored why he has shifted so much of his work into a CLI-first, agent-assisted setup. We also unpacked spec-driven development, including where it helps teams move from one-shot prompting toward something more structured, reviewable, and production-ready.
We also talked through the practical side of enterprise AI adoption: how customers outside the “AI bubble” are perceiving these tools, where Foundry fits versus personal productivity tools like Microsoft 365 Copilot, how to think about guardrails and monitoring for agents, and what developers should do as usage-based billing becomes more common. Along the way, we covered model choice, testing with Playwright, token efficiency, and why human review still matters. And yes, we also opened with an unexpectedly memorable wellness tip: apparently, cuddling a chicken can lower your stress level.
- Pascal van der Heiden: Pascal van der Heiden | LinkedIn
- Microsoft: https://www.microsoft.com/en-us/
- Azure Functions: https://azure.microsoft.com/en-us/products/functions/
- Azure API Management: https://azure.microsoft.com/en-us/products/api-management
- Azure Kubernetes Service (AKS): https://azure.microsoft.com/en-us/products/kubernetes-service/
- Microsoft Foundry: https://ai.azure.com/?view=foundry
- Microsoft 365 Copilot: https://www.microsoft.com/en-us/microsoft-365-copilot
- GitHub: https://github.com/
- GitHub Copilot: https://github.com/features/copilot
- GitHub Copilot CLI: https://docs.github.com/en/copilot/how-tos/copilot-cli/cli-getting-started
- GitHub Copilot SDK: https://docs.github.com/en/copilot/how-tos/copilot-sdk/getting-started
- Model Context Protocol (MCP) for GitHub Copilot: https://docs.github.com/en/copilot/concepts/context/mcp
- Visual Studio Code: https://code.visualstudio.com/
- Spec Kit: https://github.github.io/spec-kit/
- OpenSpec: https://github.com/Fission-AI/OpenSpec
- Superpowers: https://github.com/obra/superpowers
- Playwright: https://playwright.dev/
- AI Engineering Fluency (Rob Bos): https://open-vsx.org/extension/RobBos/copilot-token-tracker
- Rob Bos: https://devopsjournal.io/
- OpenAI: https://openai.com/
- Gemini: https://deepmind.google/models/gemini/
[00:00:08] Barry Luijbregts:
Maybe you can tell the audience who you are, what you do, what you like.
[00:00:14] Pascal van der Heiden:
Yes, so I'm a solution engineer at Microsoft. What I do, I do mostly everything gets related to deploying applications to Azure. So that's our serverless products, right? So that means from Azure Functions to API Management to AKS, that sort of thing. And also focusing on now, as we all are doing on on AI, of course. So also Microsoft Foundry is also part of my some of the responsibilities that I have. But not only how you host the applications, also how you can build them using, in our case, GitHub Copilot in combination with Visual Studio Code mainly, but also nowadays a lot in the GitHub Copilot CLI mode, so from a terminal.
Lately I'm really occupied with especially spec driven development, that's one of the passions that I have. So last year I got in touch with our internal GBB organization on all spec driven development. And that's where I talk a lot about nowadays with customers on how they can implement that in their own software development life cycle. So if it's brownfield or greenfield applications and how they can do that. On a personal note, I live in Aemness with my wife and children. I have chickens, I have guinea pigs, I have a dog.
So it's a zoo at my home. And that's the way how I like to rewind a little bit from the tech side and and do also some things in yeah. With my family, but also in nature with with the animals around me. So, yeah. I have a nice anecdote about chickens, by the way. So that's that's the one that's that's really nice. If you wanna hear, then I will do it. With this girl. This girl. Okay. So it's a it's a fun fact. Right? So a chicken has a really low heart rate. So what I do in the weekend sometimes is just grab a chicken and the chicken that are really like they're used to be picked up, but they have a really low heart heartbeat, right? So their heart rate is much, much lower than from us humans normally.
And when you have the chicken close to you, the heart rate of the animal gets a little bit transferred to you. So your heart rate will go down as well. So if you're a little bit stressed and well, I'm not that much stressed anymore because I have chickens, of course, but I just grab a chicken and I hold it under my arm for about maybe an hour and my heart rate goes down as well. So at one point the chicken even goes to sleep because it's just underneath my arm. Yeah, it just goes to sleep, but it's really like it's really calming you down to a sense that it's really amazing.
So I can I can recommend everybody get some chickens and cuddle your chicken in the weekends to lower your stress levels? That that's that's that's a cure that works for me.
[00:03:30] Barry Luijbregts:
Wow. I did not know that. And that makes so much sense because there's science about heart coherence where the heart actually has like a force field, an electromagnetic field that can influence other electromagnetic
[00:03:44] Pascal van der Heiden:
fields like your heart, for instance. Yeah. That's so cool. Yeah. It's reciprocal. And it really works. It's it's it's it's a it's a really yeah. You need to yeah. You need to try it out. So come in my home, my buddy, and I will let you cuddle my chicken.
[00:03:57] Barry Luijbregts:
That sounds great. Cool. Alright. I will. I will. Thank you. I think that's a cool fact. So and and just before that, you spoke about all sorts of things, AI. Right? You touched from GitHub Copilot to Foundry to Spectre of Development. That's a lot of stuff. Yeah. Maybe we can focus on, like, what do you use daily? How do you how do you work and how does AI fit in there?
[00:04:24] Pascal van der Heiden:
Yeah. So to be honest, I think this is something that really changed in the last, I would say, five to six months from to where I am right now. So this is a really, I would say, a fast changing environment that we're in. And I keep it keeps reminding me when I talk to customers is that we are sometimes, as from Microsoft's perspective, we are sometimes in a bubble because we are mostly using the frontier yeah, I would say the frontier solutions. And it's really hard to grasp and to imagine what you can already do with it now, especially when you're outside of that bubble, right? So that's what I see a lot with my customers. But for me, I use I'm to be honest, I minimise most of the applications that I have running on my computer, so on my laptop. I only use a few nowadays.
And that's for me, that's Microsoft three sixty five Copilot, where I basically already draft my emails or already use it to, well, to search internal documentation or to find information about things that are relevant to me that I need to look up. So I already use my Microsoft three sixty five Copilot a lot already. I use it on a daily basis. But when it comes to more the development perspective and especially when it comes to the things that I do for Azure in combination with GitHub Copilot and Visual Studio Code, the development parts and the hosting parts, is that I nowadays only sit in the CLI. So only in the terminal using GitHub Copilot CLI and connecting it with Azure via MCP servers, creating skills or getting skills for agents to be more effective and to help me achieve some of the things that I need to do.
And using spec driven development basically to set up some of the things that I want to create. So I have a lot of ideas and I have a lot of things that I like to build. And we are now at the stage where basically everything is possible, right? So you can now create anything that you can think of. So and I think that's the nice thing of this age where we're because I started programming when I was really young. I started in QBasic when I was seven years old. So I was there from the beginning on, I would say.
And I've been a developer and hooked on to development ever since. And I really lost being in the terminal and being sorry, being in Visual Studio Code for example, or being in Visual Studio to create my applications. But that that one changed like in a six or seven months from now where I mostly transfer now to the to the to the CLI and create the things that I that I want to create. And so basically the only things that I have to I have open at the moment is just my browser, my GitHub, my terminal, my GitHub Copilot CLI and Microsoft three sixty five Copilot.
And I'm not and I try not to be as much in our internal systems as they can be confusing and frustrating sometimes as well. So I like to then prompt I to prompt then better than I like to go into an application and look for the things that I need to do. So that's my change. That's how I use it nowadays.
[00:08:06] Barry Luijbregts:
It's weird how it changes, right? So I do the same. I I actively develop also production software. Like, I have a side hustle, which is a podcast hosting platform. I do that, like, in the evening, which is production stuff that actual users use. But, like, six months ago, I used to do Visual Studio. Actually go in and then see, I want this feature. Let me just think about it and build it actually. And now I just basically one shot most things. Don't tell my customer.
[00:08:38] Pascal van der Heiden:
Yeah. But we in a time that we Yeah, sorry.
[00:08:43] Barry Luijbregts:
Yeah. And then I just test it, it works, and then I verify that it works, and then I just check it in and boom, the point, that's it.
[00:08:52] Pascal van der Heiden:
And that's the thing that I think a lot of customers and mostly outside of the bubble, they cannot grasp it. You can achieve so much in such short amount of time and create the things that you could not create before. Because, for example, I'm not a UX designer, but I'm able now to give my agent the skills to be an excellent UX designer because I can just get get that skill from somebody who is and who created that skill. And then you can see that it creates the things that you couldn't imagine, but you have the idea. So that's how it works. And to be honest, I get the one shot farts, But when you use spec driven development, it becomes even better, because then you're gonna make it more concrete and specify it in a certain way that it becomes more production ready.
[00:09:49] Barry Luijbregts:
Yeah. So maybe let's talk about it. Also talk about spec driven development with customers that are interested in it, that they are using it to co pilot, but they want it to be more structured, more more guardrails, production ready. So I teach them, you know, this is for instance, spec kits. These are the steps you do to to, you know, do a feature for instance. How do you use that? And what what thing do you use? Do you use spec kits? Something else? How does Yeah. That
[00:10:18] Pascal van der Heiden:
That's a good question. So so basically, spec driven development is not something that we from Microsoft own, right? It's methodology It's that basically everybody can use. And you can see that some of the frameworks that popped up as like, oh, would say open source frameworks around spec driven development. Just as you mentioned, SpecKit is one of them. But then I've noticed that not all customers like the approach of the, I would say, SpecKit, for example. They sometimes find it a little bit too much, a little bit bloated. There's a lot of things in there you need to get into that structure specifically.
So I, for example, also use OpenSpec as a counter specification mechanism to basically spec my features and also spec the things that I want to create. So, for example, in comparison with SpecKits, OpenSpec is much, much lean and mean. So it basically only has like three operations which are three prompts that you can use, which is basically creating the change proposal, applying the change proposal and then archive it, which is which is pretty simple from a from a standpoint. But the nice thing is that when you when you create that and you archive it, it will it will create like this generic spec for the whole project. So basically, you have created a spec to create a certain like a podcast, a podcast application and you want to add that so when you archive it, it has the contents of what the project is, which you created basically, the podcast application.
And then, for example, when you add a new feature on top of it, it will just open up a new feature spec. And when you apply it and then archive it, it will just embed it into the, I would say, the generic spec to make it consistent across the whole project. So you have feature requests in a sort of a spec way and you have separate specs that just explain the complete project that you're working on. So that's it's different well, spec end uses it in a similar way, only SpecInt uses more the, I would say, the branching mechanism, where OpenSpec doesn't use branching in that case. So it's much more free, it's much more open.
I like to use like the GitHub Copilot plan mode as well. It's also a matter of creating specs in a way that it makes sense to use to make the outcome to be more of a higher quality. So yeah, I use that as well. So basically for me these are the three things. I also heard from some of my colleagues that use superpowers a lot, which is also nice. Superpowers is basically also a set of custom agents, skills and prompts that you can use to basically do brainstorming or creating specifications and applying that. It's a little bit more extensive, but it has really nice features specific for certain use cases.
So for example, the custom agent on brainstorming, that's a nice one, right? I think these are this is how we now nowadays, when we are working with AI, we want to have we want to work with the specialists that can do that task for me, right? So when I want to do specifications or brainstorming, I would like to have an agent that helps me brainstorm on the idea I have to get it as crisp as possible and then generate the spec. So then different methodologies. I use different ones because I think it's good to know what is happening, but you can I see companies also create their own own spec driven approach or pipelines or whatever?
[00:14:22] Barry Luijbregts:
And what I always wondered so I do a lot of GitHub Copilot workshops. Like one day I talk about everything that you can do, including spectrum development and all the features and things that you can do to customize, custom instruction skills, custom agents, all that type of stuff. And I always wonder to myself, what am I doing? Is this really necessary? I can also just talk to the agent, just type in the box. And usually it does a pretty good job at whatever I wanted to do. All of these things, all of these marketing files, skills, instructions, superpowers, plugins, specs, is it really needed? Especially when you use the Frontier models, MPT55, OPUS 4.7.
[00:15:08] Pascal van der Heiden:
What do you think? Yeah, it's a good question. I think I see models getting better. I see the code. So the software, the agent itself. So the like GitHub Copilot or Cloth Code, software around the LM. Yeah, the harness gets better and better, to be honest. So I see that the maybe the need of this will in the future will be much, much less. I don't know. But when I I want the agent to do it in a certain way that I would prefer it. Right? And that's the whole thing. So that's why I use Custom Agent. That's the reason why I use some of the skills is that, for example, when I ask it to create this, I don't know, a real time voice agent, I would like to use the Foundry tools. I know the stack, I know the architecture that I want basically. And that's something that you want to enforce. And basically I think with customers this is the same thing is that they already have a tech stack that they're using and they want to be they want to go into the same stack as well. So that's why I think it still makes sense to use custom instructions and skills and custom agents, etc. Yeah.
[00:16:25] Barry Luijbregts:
I agree. Especially for now, and we're getting memory. GitHub Copilot has memory that can also live in the cloud later on. I think it will learn from what a customer says and what he does. So yeah, let's see. Often find myself thinking, how hard is this? We're just typing in this box and I'm doing a whole course on it the whole day. How you type better into the box, basically. Very strange.
[00:16:54] Pascal van der Heiden:
Yeah, no, I know. But I get that, right? So to be honest, I'm doing the same thing. So I'm explaining to customers like, okay, how can they use it in a better way? And the thing is that when we look at a year or two years ago when we used GitHub Copilot and we did a one shot, the answer or the output was way off of what the things that we wanted to create. I agree that this is why we came up with things like skills and MCP servers and tools to make it more sophisticated on a certain part. But the LLM models also evolved at that time and pace, also very quickly. So I agree that there should be like a healthy balance in it.
Oh, you dropped there for a second for me. Oh, I can still hear you. You're still here for me.
[00:17:53] Barry Luijbregts:
Oh, that's good. That's good. Yeah. So, yeah. Let's see. You know, this stuff keeps evolving. I'm sure we're super close to another batch of new models, who knows? It's been a month or so.
[00:18:05] Pascal van der Heiden:
Yeah. We'll see. Yeah, so I think this is going so quickly, it's really mind blowing to be honest. So yeah, and it's always interesting to hear about like how, especially when you talk to customers, like how they perceive this, right? They see also of course, they see like Microsoft investing a lot in AI, of course. And they say like, okay, but you're saying it is so great because you need to get that return on investment, right? So you need to sell it as well. Of course, that's also part, but it's not the one that drives me the most. It's the thing that it really disrupts. So what it changes in my day to day work that really excites me.
And yeah, this is something where I see like, yeah, we need to bridge that gap a little bit and create that perspective that it's really becoming, especially on the development side, it's getting that good at this moment. Do I see it taking over our jobs? No, because I still think that we are the ones driving the car, right? We are the ones driving the we are steering. And I think that will be eventually that will be still the case. Only what I see now is that I I am much more reviewing my code. I'm much more sometimes deliberately testing a lot more myself because I sometimes do not the fact that I when I can do like I use Playwright, MCP Server a lot to do the testing for me and it does a really good job.
But still, when I tested myself, there are also always things that it didn't cover or still some things that it didn't get right. So this is, I think, still something we need to be mindful of, that we are almost there, but it it isn't a 100% proof. So we still need to be, yeah, still driving need to be driving the car and and validate if it's good or not before we gonna release it or before we gonna put it into production.
[00:20:19] Barry Luijbregts:
Yeah. Now. Two liter. Right. For that that's yes. That that we always end our sentences with for now.
[00:20:28] Pascal van der Heiden:
For now. Yeah. Because you don't know what the future will all do.
[00:20:32] Barry Luijbregts:
So GitHub Copilot, right? Copilot three sixty five, that's all stuff that is happening on your machine for your personal productivity, basically. Yeah. Right. And you also said something about Foundry. You also talk about Foundry with customers. Maybe can you explain what Foundry is? How is it different? When would you use that?
[00:20:53] Pascal van der Heiden:
Yeah, so Foundry is basically our serverless service within Azure that we provide to customers to spin up and provision their own models. So, basically these are the LLMs that, for example, a coding agent uses. So, if you look at my GitHub Copilot CLI agent, it uses models. You can get those models from GitHub itself, but you can also get those models from Foundry. And the thing is that within Foundry, we have a system where we can provision any kind of model from any kind of third party provider. So we have Gemini in there, we have Cloud, we have OpenAI models, we have any kind of model that is out there, we have it in Foundry. So these are like nowadays there are maybe 15,000 models already in the Foundry portal, so it's a lot, right?
But sometimes really dedicated for some of the use cases, which I think is really important because every use case could use a different model for when you're going to build something. So for example, I don't need a frontier model for everything. I could use, for example, mini models or even nano models to use for testing or for doing like really basic stuff or summary or whatever. So this is something where you can think about like, okay, these are the models that you can provision in Foundry. And where would you use Foundry for? It's to create or basically make your own current applications intelligent, more intelligent than they are right now. So if you want to create your own agent or if you want to create your own, I don't know, agentic solution, then you can use Foundry to basically use as a base for your model provider and also the agent service even if you want to host your agents in Foundry as well. And then you can create there your agentic multi agent solutions using Foundry and using maybe your own code base or using it with your own application or embedding it into your own application or whenever is needed.
And we saw this with the for example, the like a few years ago when you saw like JetGPT coming up, people really love that they can just talk to an agent that really gives you that, I would say, that more personal vibe. And this is something that you can create yourself. And this is where we use Foundry for, to basically provide the model interaction, so you can create your own chat application. Maybe a chat application that talks to your data, or a chat application that uses your application's information, or does things for you on your behalf in that application. So these are the scenarios that we see other customers creating with Foundry.
[00:23:56] Barry Luijbregts:
Yeah. So a lot more control models, running agents, guilty agents, including data as well, right? Rack and stuff like that. Evaluation
[00:24:07] Pascal van der Heiden:
as well, like that you can see the performance of your models, that you can tune it, that you can There are all kinds of mechanisms in there that can make it even better. And also that you can tune the model in a certain way. So you can tune your application on how it uses the model. Yeah. Yeah.
[00:24:28] Barry Luijbregts:
And so I hear all these things, right? I always try to see what to use when. So you also like GitHub Copilot SDK. Where does that fit in?
[00:24:39] Pascal van der Heiden:
Basically GitHub Copilot SDK is the way on how to create your own, I would say your own coding agent. And we talked about that harness, right? So that basically the GitHub Copilot SDK already has that harness in it. So that's basically the harness of the agent which has capabilities like shared memory or using sub agents and all these kinds of mechanisms that are already part of the agent, that you can build your own agent with it. And basically get a model from Foundry, like you can get Cloud Opus 4.7 from Foundry and then embed it into your GitHub Copilot SDK to create your own development agent.
So you're basically free then to create it yourself, even if you want.
[00:25:30] Barry Luijbregts:
Yeah. Okay. That's very cool. So in the future, we will have lots and lots of different agents running in an enterprise. GitHub Copilot powered ones. Microsoft's agent framework powered ones, other ones, third party ones, all sorts of stuff that runs around. How do we keep track of all that stuff and make sure that nothing strange happens? Like, you know, somebody deletes a database or something.
[00:25:58] Pascal van der Heiden:
Yeah. Think so. I think this is where I think where we see that Foundry comes in as well, right? So you can build that security layer on. So if you use Foundry as your, I would say your centralized model provider, you can build security measures in on top of there to already make sure that nothing really critical is happening as well. To be honest, I see different approaches here. One of the interesting part is that I see, for example, when it comes to development, a lot of companies are also running it in sandbox environments. So basically, isolated environment, just using a coding agent to do a certain task, but having all the capabilities that they need from that sandbox that they can use. Because when you're giving an AI agent on your machine a lot of access, it can do much, much more. And we saw that, for example, with OpenClaw, is that it can do proactively also a lot of things for your machine as well. And you maybe don't want that, right? So this is where you want to a little bit create like your own corporate harness around the agents or basically your your yeah, I would say maybe your your agents, but also the models that you use to basically secure them a little bit off.
I think, yeah, so and I think using like something like like like Foundry where you can monitor on what it does or what it's capable to do, limiting it with, for example, MCP access, so you can limit the access of or basically prescript the things that an agent can do to a really minimal extent. So it isn't able to do everything, but it can just do enough of what it needs to do. So yeah, I think that this is the way we mostly do it, I would say, on an implementation side. I don't know if it really answers your question, but
[00:28:07] Barry Luijbregts:
I know. What
[00:28:08] Pascal van der Heiden:
are you specifically looking for? I don't know. Yeah, we it. No, it's I'm not talking about like
[00:28:17] Barry Luijbregts:
Yeah? I'm just wondering what this will look like, right? Because this is a whole new world. We never had this. All these new things that run on their own that have incredible capabilities. So how can we control that type of stuff without huge
[00:28:33] Pascal van der Heiden:
security incidents or stuff like that? So Yeah. I I think that it's it's it's just it for me, it's not determined yet. I see that from Microsoft perspective, we have Agents three sixty five. Right? Like this unified console plane where we can add all our agents and have a have an overview of what each agent is doing. So you can embed your your foundry agents in there, you can embed your your your local agents in there that you can see what they are doing and how they are progressing, and you can monitor to that.
But I'm I'm really curious to see if that will be the solution for the for the end one. And I I don't know. I'm a little bit I'm I'm a little bit unsure there what's what the best approach is, to be honest.
[00:29:16] Barry Luijbregts:
Well, thing is this is new for everybody. So I think we're finding it out in real time really. There are some things that can happen that we do offer as Microsoft. We can kind of end on this note. So we're now in May 2026, and around this time ish, when this podcast comes out, GitHub Copilot will have a new billing mechanism, which means that we basically pay by token. OWL's calls slightly different. How can people use their tokens efficiently, effectively? Are there any tips or tricks to reduce your token count, to use more What can we do?
[00:30:06] Pascal van der Heiden:
Good question, good question. So I think it comes to token management, I think it's very important that you try to limit the number of tokens that you spend, right? So you keep the context minimal as possible. Also using the appropriate model for the appropriate task. I think that's also already a way to limit your token usage. Personally, I really like the AI fluency plugin from RobBoss. This is something I use on a daily basis. I already implemented it, for example, in my comments line that I always see the number of tokens I used for the last thirty days.
This already gives me some insights on the spends that I have when it comes to tokens that I use. So, I think from one point, I think it's having insights on what you're using and what you're spending basically. But also on the other hand, I think it's very important to look at what's actually going to the LLM. So if you, for example, in Visual Studio Code you can use, I think it's called chat debug, you can just you can collect, so when you go to your common palette, do chat debug, you can can sketch out what is actually being sent to the LLM.
And here what you sometimes see, and especially I do this when I'm asking a question and the output is pretty much not what I requested. Right? So when it's really it's when it's totally off, but I think you can use it in many, many ways. But then I would just go into the trace of what is actually being sent to the model. And then you see that, for example, there's a lot of maybe MCP baggage that's not really interested for your question, but it still goes to the model, right? And you need to be conscious of what you're sending there.
And you can also there limit a lot of the context in a better way, the quality of the answer would be much better from the LLM. So for me, it's having insight in your tokens, having insight in what's actually being sent to the LLM. And I think from a loss perspective is the model. Think about which model to use for which kinds of purposes. Because Haiku, for example, is really good in when it's just want to summarize or doing a little bit of minimal brainstory. You don't need then a Claude Opus model to do that. So be conscious about what you're using in in what yeah, in which case. And also the AI fluency plugin, I think it's really nice because it gives you also a little bit more context on how you use GitHub Copilot, not only from a token usage, but also gives you stats in how you use it and how even how optimized your requests are in combination with your context window. So it already gives you some insights on, hey, am I an AI expert or not? And I think this is a nice tip.
[00:33:27] Barry Luijbregts:
Yeah. Okay. So those are good tips to use, you know, start exploring, make sure that you optimize your tokens so that you don't run out at the end of the month, right? Because that would be super spent. Yeah. You can't work anymore to close your laptop. Well,
[00:33:44] Pascal van der Heiden:
you can always request more tokens, right? So it's bumping up the limit, right? That's I'm coming from Microsoft, Marie.
[00:33:55] Barry Luijbregts:
Well, no, I know. So we are we were blessed with currently unlimited tokens, which is lovely. Yeah.
[00:34:01] Pascal van der Heiden:
That's that's that's a true blessing. I would I said to I said internally, I said this is even better than the Xbox Ultimate Boss, James Boss. Use it much, much more than than I use my Xbox right now. So, yeah.
[00:34:17] Barry Luijbregts:
Yeah. Alright. So on that note, let's let's end it. Thank you very much for this. You're welcome. Let's maybe reconnect in six months, a year. Let's see what the world looks like then.
[00:34:31] Pascal van der Heiden:
Good idea. Good idea. See if we if we got it right on some points, right? Yeah. And and and after you have cuddled by chicken, so then you know if your heart if your heart rate is is lower or not. Yeah.
[00:34:46] Barry Luijbregts:
Alright. We'll find it.
[00:34:48] Pascal van der Heiden:
You very much. You're welcome. See you.
Maybe you can tell the audience who you are, what you do, what you like.
[00:00:14] Pascal van der Heiden:
Yes, so I'm a solution engineer at Microsoft. What I do, I do mostly everything gets related to deploying applications to Azure. So that's our serverless products, right? So that means from Azure Functions to API Management to AKS, that sort of thing. And also focusing on now, as we all are doing on on AI, of course. So also Microsoft Foundry is also part of my some of the responsibilities that I have. But not only how you host the applications, also how you can build them using, in our case, GitHub Copilot in combination with Visual Studio Code mainly, but also nowadays a lot in the GitHub Copilot CLI mode, so from a terminal.
Lately I'm really occupied with especially spec driven development, that's one of the passions that I have. So last year I got in touch with our internal GBB organization on all spec driven development. And that's where I talk a lot about nowadays with customers on how they can implement that in their own software development life cycle. So if it's brownfield or greenfield applications and how they can do that. On a personal note, I live in Aemness with my wife and children. I have chickens, I have guinea pigs, I have a dog.
So it's a zoo at my home. And that's the way how I like to rewind a little bit from the tech side and and do also some things in yeah. With my family, but also in nature with with the animals around me. So, yeah. I have a nice anecdote about chickens, by the way. So that's that's the one that's that's really nice. If you wanna hear, then I will do it. With this girl. This girl. Okay. So it's a it's a fun fact. Right? So a chicken has a really low heart rate. So what I do in the weekend sometimes is just grab a chicken and the chicken that are really like they're used to be picked up, but they have a really low heart heartbeat, right? So their heart rate is much, much lower than from us humans normally.
And when you have the chicken close to you, the heart rate of the animal gets a little bit transferred to you. So your heart rate will go down as well. So if you're a little bit stressed and well, I'm not that much stressed anymore because I have chickens, of course, but I just grab a chicken and I hold it under my arm for about maybe an hour and my heart rate goes down as well. So at one point the chicken even goes to sleep because it's just underneath my arm. Yeah, it just goes to sleep, but it's really like it's really calming you down to a sense that it's really amazing.
So I can I can recommend everybody get some chickens and cuddle your chicken in the weekends to lower your stress levels? That that's that's that's a cure that works for me.
[00:03:30] Barry Luijbregts:
Wow. I did not know that. And that makes so much sense because there's science about heart coherence where the heart actually has like a force field, an electromagnetic field that can influence other electromagnetic
[00:03:44] Pascal van der Heiden:
fields like your heart, for instance. Yeah. That's so cool. Yeah. It's reciprocal. And it really works. It's it's it's it's a it's a really yeah. You need to yeah. You need to try it out. So come in my home, my buddy, and I will let you cuddle my chicken.
[00:03:57] Barry Luijbregts:
That sounds great. Cool. Alright. I will. I will. Thank you. I think that's a cool fact. So and and just before that, you spoke about all sorts of things, AI. Right? You touched from GitHub Copilot to Foundry to Spectre of Development. That's a lot of stuff. Yeah. Maybe we can focus on, like, what do you use daily? How do you how do you work and how does AI fit in there?
[00:04:24] Pascal van der Heiden:
Yeah. So to be honest, I think this is something that really changed in the last, I would say, five to six months from to where I am right now. So this is a really, I would say, a fast changing environment that we're in. And I keep it keeps reminding me when I talk to customers is that we are sometimes, as from Microsoft's perspective, we are sometimes in a bubble because we are mostly using the frontier yeah, I would say the frontier solutions. And it's really hard to grasp and to imagine what you can already do with it now, especially when you're outside of that bubble, right? So that's what I see a lot with my customers. But for me, I use I'm to be honest, I minimise most of the applications that I have running on my computer, so on my laptop. I only use a few nowadays.
And that's for me, that's Microsoft three sixty five Copilot, where I basically already draft my emails or already use it to, well, to search internal documentation or to find information about things that are relevant to me that I need to look up. So I already use my Microsoft three sixty five Copilot a lot already. I use it on a daily basis. But when it comes to more the development perspective and especially when it comes to the things that I do for Azure in combination with GitHub Copilot and Visual Studio Code, the development parts and the hosting parts, is that I nowadays only sit in the CLI. So only in the terminal using GitHub Copilot CLI and connecting it with Azure via MCP servers, creating skills or getting skills for agents to be more effective and to help me achieve some of the things that I need to do.
And using spec driven development basically to set up some of the things that I want to create. So I have a lot of ideas and I have a lot of things that I like to build. And we are now at the stage where basically everything is possible, right? So you can now create anything that you can think of. So and I think that's the nice thing of this age where we're because I started programming when I was really young. I started in QBasic when I was seven years old. So I was there from the beginning on, I would say.
And I've been a developer and hooked on to development ever since. And I really lost being in the terminal and being sorry, being in Visual Studio Code for example, or being in Visual Studio to create my applications. But that that one changed like in a six or seven months from now where I mostly transfer now to the to the to the CLI and create the things that I that I want to create. And so basically the only things that I have to I have open at the moment is just my browser, my GitHub, my terminal, my GitHub Copilot CLI and Microsoft three sixty five Copilot.
And I'm not and I try not to be as much in our internal systems as they can be confusing and frustrating sometimes as well. So I like to then prompt I to prompt then better than I like to go into an application and look for the things that I need to do. So that's my change. That's how I use it nowadays.
[00:08:06] Barry Luijbregts:
It's weird how it changes, right? So I do the same. I I actively develop also production software. Like, I have a side hustle, which is a podcast hosting platform. I do that, like, in the evening, which is production stuff that actual users use. But, like, six months ago, I used to do Visual Studio. Actually go in and then see, I want this feature. Let me just think about it and build it actually. And now I just basically one shot most things. Don't tell my customer.
[00:08:38] Pascal van der Heiden:
Yeah. But we in a time that we Yeah, sorry.
[00:08:43] Barry Luijbregts:
Yeah. And then I just test it, it works, and then I verify that it works, and then I just check it in and boom, the point, that's it.
[00:08:52] Pascal van der Heiden:
And that's the thing that I think a lot of customers and mostly outside of the bubble, they cannot grasp it. You can achieve so much in such short amount of time and create the things that you could not create before. Because, for example, I'm not a UX designer, but I'm able now to give my agent the skills to be an excellent UX designer because I can just get get that skill from somebody who is and who created that skill. And then you can see that it creates the things that you couldn't imagine, but you have the idea. So that's how it works. And to be honest, I get the one shot farts, But when you use spec driven development, it becomes even better, because then you're gonna make it more concrete and specify it in a certain way that it becomes more production ready.
[00:09:49] Barry Luijbregts:
Yeah. So maybe let's talk about it. Also talk about spec driven development with customers that are interested in it, that they are using it to co pilot, but they want it to be more structured, more more guardrails, production ready. So I teach them, you know, this is for instance, spec kits. These are the steps you do to to, you know, do a feature for instance. How do you use that? And what what thing do you use? Do you use spec kits? Something else? How does Yeah. That
[00:10:18] Pascal van der Heiden:
That's a good question. So so basically, spec driven development is not something that we from Microsoft own, right? It's methodology It's that basically everybody can use. And you can see that some of the frameworks that popped up as like, oh, would say open source frameworks around spec driven development. Just as you mentioned, SpecKit is one of them. But then I've noticed that not all customers like the approach of the, I would say, SpecKit, for example. They sometimes find it a little bit too much, a little bit bloated. There's a lot of things in there you need to get into that structure specifically.
So I, for example, also use OpenSpec as a counter specification mechanism to basically spec my features and also spec the things that I want to create. So, for example, in comparison with SpecKits, OpenSpec is much, much lean and mean. So it basically only has like three operations which are three prompts that you can use, which is basically creating the change proposal, applying the change proposal and then archive it, which is which is pretty simple from a from a standpoint. But the nice thing is that when you when you create that and you archive it, it will it will create like this generic spec for the whole project. So basically, you have created a spec to create a certain like a podcast, a podcast application and you want to add that so when you archive it, it has the contents of what the project is, which you created basically, the podcast application.
And then, for example, when you add a new feature on top of it, it will just open up a new feature spec. And when you apply it and then archive it, it will just embed it into the, I would say, the generic spec to make it consistent across the whole project. So you have feature requests in a sort of a spec way and you have separate specs that just explain the complete project that you're working on. So that's it's different well, spec end uses it in a similar way, only SpecInt uses more the, I would say, the branching mechanism, where OpenSpec doesn't use branching in that case. So it's much more free, it's much more open.
I like to use like the GitHub Copilot plan mode as well. It's also a matter of creating specs in a way that it makes sense to use to make the outcome to be more of a higher quality. So yeah, I use that as well. So basically for me these are the three things. I also heard from some of my colleagues that use superpowers a lot, which is also nice. Superpowers is basically also a set of custom agents, skills and prompts that you can use to basically do brainstorming or creating specifications and applying that. It's a little bit more extensive, but it has really nice features specific for certain use cases.
So for example, the custom agent on brainstorming, that's a nice one, right? I think these are this is how we now nowadays, when we are working with AI, we want to have we want to work with the specialists that can do that task for me, right? So when I want to do specifications or brainstorming, I would like to have an agent that helps me brainstorm on the idea I have to get it as crisp as possible and then generate the spec. So then different methodologies. I use different ones because I think it's good to know what is happening, but you can I see companies also create their own own spec driven approach or pipelines or whatever?
[00:14:22] Barry Luijbregts:
And what I always wondered so I do a lot of GitHub Copilot workshops. Like one day I talk about everything that you can do, including spectrum development and all the features and things that you can do to customize, custom instruction skills, custom agents, all that type of stuff. And I always wonder to myself, what am I doing? Is this really necessary? I can also just talk to the agent, just type in the box. And usually it does a pretty good job at whatever I wanted to do. All of these things, all of these marketing files, skills, instructions, superpowers, plugins, specs, is it really needed? Especially when you use the Frontier models, MPT55, OPUS 4.7.
[00:15:08] Pascal van der Heiden:
What do you think? Yeah, it's a good question. I think I see models getting better. I see the code. So the software, the agent itself. So the like GitHub Copilot or Cloth Code, software around the LM. Yeah, the harness gets better and better, to be honest. So I see that the maybe the need of this will in the future will be much, much less. I don't know. But when I I want the agent to do it in a certain way that I would prefer it. Right? And that's the whole thing. So that's why I use Custom Agent. That's the reason why I use some of the skills is that, for example, when I ask it to create this, I don't know, a real time voice agent, I would like to use the Foundry tools. I know the stack, I know the architecture that I want basically. And that's something that you want to enforce. And basically I think with customers this is the same thing is that they already have a tech stack that they're using and they want to be they want to go into the same stack as well. So that's why I think it still makes sense to use custom instructions and skills and custom agents, etc. Yeah.
[00:16:25] Barry Luijbregts:
I agree. Especially for now, and we're getting memory. GitHub Copilot has memory that can also live in the cloud later on. I think it will learn from what a customer says and what he does. So yeah, let's see. Often find myself thinking, how hard is this? We're just typing in this box and I'm doing a whole course on it the whole day. How you type better into the box, basically. Very strange.
[00:16:54] Pascal van der Heiden:
Yeah, no, I know. But I get that, right? So to be honest, I'm doing the same thing. So I'm explaining to customers like, okay, how can they use it in a better way? And the thing is that when we look at a year or two years ago when we used GitHub Copilot and we did a one shot, the answer or the output was way off of what the things that we wanted to create. I agree that this is why we came up with things like skills and MCP servers and tools to make it more sophisticated on a certain part. But the LLM models also evolved at that time and pace, also very quickly. So I agree that there should be like a healthy balance in it.
Oh, you dropped there for a second for me. Oh, I can still hear you. You're still here for me.
[00:17:53] Barry Luijbregts:
Oh, that's good. That's good. Yeah. So, yeah. Let's see. You know, this stuff keeps evolving. I'm sure we're super close to another batch of new models, who knows? It's been a month or so.
[00:18:05] Pascal van der Heiden:
Yeah. We'll see. Yeah, so I think this is going so quickly, it's really mind blowing to be honest. So yeah, and it's always interesting to hear about like how, especially when you talk to customers, like how they perceive this, right? They see also of course, they see like Microsoft investing a lot in AI, of course. And they say like, okay, but you're saying it is so great because you need to get that return on investment, right? So you need to sell it as well. Of course, that's also part, but it's not the one that drives me the most. It's the thing that it really disrupts. So what it changes in my day to day work that really excites me.
And yeah, this is something where I see like, yeah, we need to bridge that gap a little bit and create that perspective that it's really becoming, especially on the development side, it's getting that good at this moment. Do I see it taking over our jobs? No, because I still think that we are the ones driving the car, right? We are the ones driving the we are steering. And I think that will be eventually that will be still the case. Only what I see now is that I I am much more reviewing my code. I'm much more sometimes deliberately testing a lot more myself because I sometimes do not the fact that I when I can do like I use Playwright, MCP Server a lot to do the testing for me and it does a really good job.
But still, when I tested myself, there are also always things that it didn't cover or still some things that it didn't get right. So this is, I think, still something we need to be mindful of, that we are almost there, but it it isn't a 100% proof. So we still need to be, yeah, still driving need to be driving the car and and validate if it's good or not before we gonna release it or before we gonna put it into production.
[00:20:19] Barry Luijbregts:
Yeah. Now. Two liter. Right. For that that's yes. That that we always end our sentences with for now.
[00:20:28] Pascal van der Heiden:
For now. Yeah. Because you don't know what the future will all do.
[00:20:32] Barry Luijbregts:
So GitHub Copilot, right? Copilot three sixty five, that's all stuff that is happening on your machine for your personal productivity, basically. Yeah. Right. And you also said something about Foundry. You also talk about Foundry with customers. Maybe can you explain what Foundry is? How is it different? When would you use that?
[00:20:53] Pascal van der Heiden:
Yeah, so Foundry is basically our serverless service within Azure that we provide to customers to spin up and provision their own models. So, basically these are the LLMs that, for example, a coding agent uses. So, if you look at my GitHub Copilot CLI agent, it uses models. You can get those models from GitHub itself, but you can also get those models from Foundry. And the thing is that within Foundry, we have a system where we can provision any kind of model from any kind of third party provider. So we have Gemini in there, we have Cloud, we have OpenAI models, we have any kind of model that is out there, we have it in Foundry. So these are like nowadays there are maybe 15,000 models already in the Foundry portal, so it's a lot, right?
But sometimes really dedicated for some of the use cases, which I think is really important because every use case could use a different model for when you're going to build something. So for example, I don't need a frontier model for everything. I could use, for example, mini models or even nano models to use for testing or for doing like really basic stuff or summary or whatever. So this is something where you can think about like, okay, these are the models that you can provision in Foundry. And where would you use Foundry for? It's to create or basically make your own current applications intelligent, more intelligent than they are right now. So if you want to create your own agent or if you want to create your own, I don't know, agentic solution, then you can use Foundry to basically use as a base for your model provider and also the agent service even if you want to host your agents in Foundry as well. And then you can create there your agentic multi agent solutions using Foundry and using maybe your own code base or using it with your own application or embedding it into your own application or whenever is needed.
And we saw this with the for example, the like a few years ago when you saw like JetGPT coming up, people really love that they can just talk to an agent that really gives you that, I would say, that more personal vibe. And this is something that you can create yourself. And this is where we use Foundry for, to basically provide the model interaction, so you can create your own chat application. Maybe a chat application that talks to your data, or a chat application that uses your application's information, or does things for you on your behalf in that application. So these are the scenarios that we see other customers creating with Foundry.
[00:23:56] Barry Luijbregts:
Yeah. So a lot more control models, running agents, guilty agents, including data as well, right? Rack and stuff like that. Evaluation
[00:24:07] Pascal van der Heiden:
as well, like that you can see the performance of your models, that you can tune it, that you can There are all kinds of mechanisms in there that can make it even better. And also that you can tune the model in a certain way. So you can tune your application on how it uses the model. Yeah. Yeah.
[00:24:28] Barry Luijbregts:
And so I hear all these things, right? I always try to see what to use when. So you also like GitHub Copilot SDK. Where does that fit in?
[00:24:39] Pascal van der Heiden:
Basically GitHub Copilot SDK is the way on how to create your own, I would say your own coding agent. And we talked about that harness, right? So that basically the GitHub Copilot SDK already has that harness in it. So that's basically the harness of the agent which has capabilities like shared memory or using sub agents and all these kinds of mechanisms that are already part of the agent, that you can build your own agent with it. And basically get a model from Foundry, like you can get Cloud Opus 4.7 from Foundry and then embed it into your GitHub Copilot SDK to create your own development agent.
So you're basically free then to create it yourself, even if you want.
[00:25:30] Barry Luijbregts:
Yeah. Okay. That's very cool. So in the future, we will have lots and lots of different agents running in an enterprise. GitHub Copilot powered ones. Microsoft's agent framework powered ones, other ones, third party ones, all sorts of stuff that runs around. How do we keep track of all that stuff and make sure that nothing strange happens? Like, you know, somebody deletes a database or something.
[00:25:58] Pascal van der Heiden:
Yeah. Think so. I think this is where I think where we see that Foundry comes in as well, right? So you can build that security layer on. So if you use Foundry as your, I would say your centralized model provider, you can build security measures in on top of there to already make sure that nothing really critical is happening as well. To be honest, I see different approaches here. One of the interesting part is that I see, for example, when it comes to development, a lot of companies are also running it in sandbox environments. So basically, isolated environment, just using a coding agent to do a certain task, but having all the capabilities that they need from that sandbox that they can use. Because when you're giving an AI agent on your machine a lot of access, it can do much, much more. And we saw that, for example, with OpenClaw, is that it can do proactively also a lot of things for your machine as well. And you maybe don't want that, right? So this is where you want to a little bit create like your own corporate harness around the agents or basically your your yeah, I would say maybe your your agents, but also the models that you use to basically secure them a little bit off.
I think, yeah, so and I think using like something like like like Foundry where you can monitor on what it does or what it's capable to do, limiting it with, for example, MCP access, so you can limit the access of or basically prescript the things that an agent can do to a really minimal extent. So it isn't able to do everything, but it can just do enough of what it needs to do. So yeah, I think that this is the way we mostly do it, I would say, on an implementation side. I don't know if it really answers your question, but
[00:28:07] Barry Luijbregts:
I know. What
[00:28:08] Pascal van der Heiden:
are you specifically looking for? I don't know. Yeah, we it. No, it's I'm not talking about like
[00:28:17] Barry Luijbregts:
Yeah? I'm just wondering what this will look like, right? Because this is a whole new world. We never had this. All these new things that run on their own that have incredible capabilities. So how can we control that type of stuff without huge
[00:28:33] Pascal van der Heiden:
security incidents or stuff like that? So Yeah. I I think that it's it's it's just it for me, it's not determined yet. I see that from Microsoft perspective, we have Agents three sixty five. Right? Like this unified console plane where we can add all our agents and have a have an overview of what each agent is doing. So you can embed your your foundry agents in there, you can embed your your your local agents in there that you can see what they are doing and how they are progressing, and you can monitor to that.
But I'm I'm really curious to see if that will be the solution for the for the end one. And I I don't know. I'm a little bit I'm I'm a little bit unsure there what's what the best approach is, to be honest.
[00:29:16] Barry Luijbregts:
Well, thing is this is new for everybody. So I think we're finding it out in real time really. There are some things that can happen that we do offer as Microsoft. We can kind of end on this note. So we're now in May 2026, and around this time ish, when this podcast comes out, GitHub Copilot will have a new billing mechanism, which means that we basically pay by token. OWL's calls slightly different. How can people use their tokens efficiently, effectively? Are there any tips or tricks to reduce your token count, to use more What can we do?
[00:30:06] Pascal van der Heiden:
Good question, good question. So I think it comes to token management, I think it's very important that you try to limit the number of tokens that you spend, right? So you keep the context minimal as possible. Also using the appropriate model for the appropriate task. I think that's also already a way to limit your token usage. Personally, I really like the AI fluency plugin from RobBoss. This is something I use on a daily basis. I already implemented it, for example, in my comments line that I always see the number of tokens I used for the last thirty days.
This already gives me some insights on the spends that I have when it comes to tokens that I use. So, I think from one point, I think it's having insights on what you're using and what you're spending basically. But also on the other hand, I think it's very important to look at what's actually going to the LLM. So if you, for example, in Visual Studio Code you can use, I think it's called chat debug, you can just you can collect, so when you go to your common palette, do chat debug, you can can sketch out what is actually being sent to the LLM.
And here what you sometimes see, and especially I do this when I'm asking a question and the output is pretty much not what I requested. Right? So when it's really it's when it's totally off, but I think you can use it in many, many ways. But then I would just go into the trace of what is actually being sent to the model. And then you see that, for example, there's a lot of maybe MCP baggage that's not really interested for your question, but it still goes to the model, right? And you need to be conscious of what you're sending there.
And you can also there limit a lot of the context in a better way, the quality of the answer would be much better from the LLM. So for me, it's having insight in your tokens, having insight in what's actually being sent to the LLM. And I think from a loss perspective is the model. Think about which model to use for which kinds of purposes. Because Haiku, for example, is really good in when it's just want to summarize or doing a little bit of minimal brainstory. You don't need then a Claude Opus model to do that. So be conscious about what you're using in in what yeah, in which case. And also the AI fluency plugin, I think it's really nice because it gives you also a little bit more context on how you use GitHub Copilot, not only from a token usage, but also gives you stats in how you use it and how even how optimized your requests are in combination with your context window. So it already gives you some insights on, hey, am I an AI expert or not? And I think this is a nice tip.
[00:33:27] Barry Luijbregts:
Yeah. Okay. So those are good tips to use, you know, start exploring, make sure that you optimize your tokens so that you don't run out at the end of the month, right? Because that would be super spent. Yeah. You can't work anymore to close your laptop. Well,
[00:33:44] Pascal van der Heiden:
you can always request more tokens, right? So it's bumping up the limit, right? That's I'm coming from Microsoft, Marie.
[00:33:55] Barry Luijbregts:
Well, no, I know. So we are we were blessed with currently unlimited tokens, which is lovely. Yeah.
[00:34:01] Pascal van der Heiden:
That's that's that's a true blessing. I would I said to I said internally, I said this is even better than the Xbox Ultimate Boss, James Boss. Use it much, much more than than I use my Xbox right now. So, yeah.
[00:34:17] Barry Luijbregts:
Yeah. Alright. So on that note, let's let's end it. Thank you very much for this. You're welcome. Let's maybe reconnect in six months, a year. Let's see what the world looks like then.
[00:34:31] Pascal van der Heiden:
Good idea. Good idea. See if we if we got it right on some points, right? Yeah. And and and after you have cuddled by chicken, so then you know if your heart if your heart rate is is lower or not. Yeah.
[00:34:46] Barry Luijbregts:
Alright. We'll find it.
[00:34:48] Pascal van der Heiden:
You very much. You're welcome. See you.
Microsoft engineering, Azure, and AI focus
Life in Aemness and a calming chicken story
Daily AI workflow shifts to Copilot and CLI
Spec driven development and practical frameworks
Do teams really need specs, skills, and agents
Customer adoption, testing, and staying in control
What Foundry is and when to use it
GitHub Copilot SDK and managing enterprise agents
Token efficient Copilot usage and practical tips
