From Writing Code to Designing Systems: How the Developer Role is Changing — Chris Noring, Microsoft

[upbeat music] Hey, folks.

We are starting a little bit early as we are at capacity, so thank you all for showing up. My name is Chris Noring. Uh, my daytime job is at Microsoft, where I work a lot with AI engineering.

Um, right. So this session is called From Writing Code to Designing Systems. So show of hands, how many of you are coding like you normally do?

Not many hands, right? So most of you, I think, have shifted into more of a systems approach, right? So maybe I'm talking to the, uh,

uh, to people who have already done the shift. That's not always the case, by the way. So sometimes when you go out at conferences, people are like, "I'm hacking away.

I've tried Claude. I've tried Copilot." Interesting. How many are using Claude, by the way? No judgment. [chuckles] How many are using Copilot? Okay, half and half. Maybe more Claude. That's fine.

We are very good friends with Claude, I should say that. We are even showing up at events together. So Anthropic, good stuff.

So what I mean to tell you today is maybe tell you a story that you already know. You know that your world has changed. You know that in the old days, one hundred percent on keyboard, and you might still be on the keyboard, you just do different things with your time.

But we all knew that we were the limitation, right? We were brilliant engineers. We did one hundred percent of the code, but linear progress, it was just you trying to advance things.

It was up to you whether a feature was being built or not. And sometimes you had to choose a scenario where, well, I don't have time to build this feature because I'm doing this over here.

That's no longer a limitation. So what's happening? Um, I think most of you still have a job, right? So you know that your job didn't disappear. You know that your center of gravity has moved.

So you are no longer one hundred percent developers, but you are now in a different position, which some people might argue... I mean, many of us, I think, have chosen our profession because we love coding, right?

Right? [chuckles] I think so. So to some extent, we're still writing code. We just are ve-very, very precious with our time what we write, right? Because we now have so many helpers, but many of you have heard the term AI slope, right?

I see nods here. So you understand in the early days of these AI tools, you were like, "Oh my God, I can't believe it produced this kind of code.

It gives me more work than before. I had to rewrite all that code." But now we're coming into a place where guardrails is a big thing of our existence.

So you are stuck with an AI tool. There is no longer an option not to use one. But of course, you are thinking, "Which AI tool am I using?"

Right? And if you're using Claude, like many of you were using, you might use Claude Code or Claude Desktop. If you're using Copilot, you might know that we have a CLI.

We got the GitHub UI. We have the editor and so on and so forth. So you're like, "I'm trying to fit all of this into my world," right? Because my world was editors, right?

Text editors, IDs. So I'm proposing a new workflow, and some of you might already be using this workflow, but this is where I am at. And you might tell me, "Hey, Chris, you're wrong," and that's completely fine.

This is an idea of mine. So I think that many of us are probably here today where we start with a CLI, and that's just a weird idea, right?

Because as developers, like, editor used to be our first entry point. Why, why should I be in a CLI? That's weird. Like, I'm not a Bash person, right? I mean, many of us are just building features or noth-nothing wrong with Bash or PowerShell, but that used to be other people, right?

They used to manage other things. But as developers, the CLI could be a good entry point because I don't start my editor anymore, uh, 'cause I don't need to.

So I can sit, just sit there, and I started my CLI. That's what I propose. And then I go to the editor because here is where I'm used to working, right?

I've spent twenty years in the industry. Twenty of those years, or at least nineteen and a half, I've spent in an editor because that's my home. So I'm saying that's the second point here.

And the third point is where scaling come in today, and I think many of you are already using agents to scale. But here's where I'm saying the CLI could be your point of scale, and also the GitHub UI could be your point of scale.

So here's where we start. Here's where I think we could start. And again, like, I don't know if you got eggs or not, whether you like this idea, so [chuckles] I have something to hide behind.

So what I'm saying is GitHub Copilot CLI, or any kind of CLI for that matter if you, if you're using Claude, is where your new starting point could be.

And as you know, when you code today, you create your first draft maybe. Maybe it's a new MVP. I've heard, uh, some business where they say, "Hey, do you know what?

My engineers are no longer bringing me PowerPoints. They're bringing me working demos." Right? That is a big shift. Like, I don't need to ask a crowd full of developers if you like PowerPoint or not because I know you won't, right?

You'd rather bring them a working demo. Is this what you mean, right? So I create my first draft. I set up my guardrails, right? So without the guardrails, it's mayhem.

It's chaos. But of course, and this is maybe where y- my first, uh, thought was a few months ago. A CLI. Okay, fair enough. I'll start a CLI, uh, because I can manage my issues, my, my GitHub issues, my PRs.

So maybe this is a good place to be, right? Because I don't need to pop open VS Code if I can just close fifteen issues without even seeing the, you know, user interface.

So that's definitely a use case I, I wanna use. Issues, PRs, you know, status checks.

But of course, you've noticed as we start using, uh, agentic tools is that we don't write in Java or JavaScript or Python so much anymore. It's prompts, and we say stuff like, "Build me an app, add this new feature, or fix this."

How many, uh, recognize yourselves here, right? How many have this? Bunch of terminals open, building, build me an app. That, right? That's our next MVP. That's how my company's gonna make a lot of money, or maybe me.

Maybe that's my side project. Fix an issue, right? That's another use case, and here we have add a new feature and build another cool app. And meanwhile, I'm sipping my, uh, cup of coffee or tea or whatever my favorite beverage is while it's kicking away, right?

So this is literally my world today, and if it's not your world, I would have a think and say, "Could it be my world?"

And of course, the editor might be one place out of many where, you know, it, it, it could also be in there. So when we continue on now from the CLI to the editor, what we're trying to do, uh, just like the CLI, by the way, is that we need to set up guardrails.

We need to, uh, set up custom agents. And, and let me also explain what custom agents are. And then here's where I propose that we spend less and less time with the editor because it doesn't make sense anymore for us if we've got 15, 20 agents that do our bidding, that we sit there and, you know, trying

to figure out what, what code to write. But I still love the editor, right? As I said, 19 and a half years I spent, uh, out of 20 with an editor, so I feel more in control.

I feel more used to it, so I'm not gonna let go of it. And the good news is that regardless of what AI editor you're using or AI, you know, provider, you probably have something that listens to your CLI streams, your streams from the editor, maybe your streams that happens over in, in the GitHub repos.

So I kind of like it as the control board, if you will, right? That's how I kind of see the editor.

And you know this, right? I, I mentioned AI slop before, and I see some nods, and then I saw some pain, right? Like, we, we know this pain. Without rules, agents run amok.

So what do we do? We add guardrails.

Guardrail number one, this is the absolute bare minimum, right? AGENTS.md. Should have this in all your GitHub repos or whatever kind of repo structure you have. This is your high-level guidance explaining repository intent, application architecture constraints, the do's and don'ts, right?

There are things in here. For example, we could explain what the agents should not do. For example, you should never change the architecture unless I tell you, or here in the high level we say, "Well, this project is this and that."

This may be some finance app that uses React, maybe it's using Tailwind, and so on and so forth, right? There are many things that goes into an agents, but AGENTS.md, but I kind of see it as a high-level thing.

And just very, very high level here, uh, you see a demo here. You see a repo. I built a little finance tracker, bytecoded, right?

Um, have a little AGENTS.md. You can see how I have this project overview, agent responsibilities, and so on and so forth. Quite a long file.

Just to take you through it. And I can query here in the bottom right and say, "What does this AGENTS.md do?" And of course, if I am in a fresh project, I might have an, AGENTS.md from another project, so I can just copy it in and say, "Use this one."

Uh, adopt my maybe old code base or my present code base into adhering to AGENTS.md, right? So AGENTS.md is, is one of those things that's a bare minimum thing to do.

Another problem I have is that agents don't do things correctly. I, I think you've noticed this as you work with agents, is that it's almost the same, right? Or, or sometimes it just goes in this direction.

It's definitely not correct. So for situations like that, we need to use skills. How many are using skills?

That's a good show of hands, so I'm preaching to the choir, as they say, right? Well, I'm not gonna sing, I promise. So the idea with a skill is to give it a recipe, something that's repeatable, and you want the agent to use this one each time.

Do not make things up. We want to constrain the agents as much as humanly possible. So a skill, as maybe a majority of the room already know, is a, a contract, right?

Something that the agent can invoke. So instead of improvising logic, because we know as developers we want to mitigate risk, right? We know that the agent should have a harness around it and say, "Don't do things that I don't want you to do.

Don't be creative. Don't do anything," right? So now we can also say, "These are tools that you should use," and, uh, yeah. So we should definitely be using skills for these,

um, uh, for these tasks that are repeatable, that we do often, that needs to happen in a certain order. So, uh, a skill is called by an agent. It has a strict contract.

It's self-contained because it just lives in a folder, and it's intentionally constrained because we don't want agents to do things, right? We want it to be as much as a human developer as, as possible while being fast.

And about creating skills, if you haven't done that before, and this is how it works within GitHub Copilot, but if you're on Claude, which half the audience is, you usually have .claude/skills.

That's usually where you place the skills. You have folders, one folder for each skill, and then you have a skill.md, and it comes with some front matter with name and description, what it does, and then a long Markdown instruction,

what should happen. So skills are a great thing. I think it's great that we are all in agreement, all the big vendors, whether you are Anthropic or Microsoft or anyone else, because ultimately, as developers, you know, we don't always decide what, uh, vendor that, that we use.

So creating a skill is therefore pretty straightforward, and yeah, this might be VS Code specific, but I'm sure in Claude this is equally simple. So we're just here. We have a folder already.

We have a skill, skill.md, and we can just... A- and one of my favorite things to do, because I'm really bad at writing these instructions, is simply to ask Copilot, "How do you write a better instruction for what I aim to do?"

And, uh, I can definitely bring up a user interface to add a new skill, and I think whether you use VS Code or IntelliJ, it's pretty much the same thing.

Um, and, and here I'm invoking the skills, by the way, and there are different ways of doing that. So either I'm calling /skills, in which case it allows me to configure the skills, or I'm just typing a prompt that resembles the name or description of the skill, in which case it will be invoked.

Another problem I have is that sometimes I need more than skills. How many are using AGENTS.md and skills and then nothing more?

Okay, so you probably are using something more. So you're probably using agents, and you might not know what I'm after, but we have this thing in GitHub Copilot called the custom agent.

That's when we feel like the skill isn't enough, when we need the next level. So what I'm saying is that a skill is limited in what it can do.

It can't really orchestrate itself with others. That's when you need an agent, right? You need something that's able to reason. So here with a custom agent, you have a persona, right?

And an agent can use, uh, N number of skills. So it has a distinct role and purpose, so think security expert, back-end, front-ender. Think also that it's able to use MCP servers.

So you can see at this point an agent becomes a higher level concept than a skill.

So just to compare and contrast, we see that the agent is more of an orchestrator. It's more broad in its scope. It has a personality, it's able to plan, it's able to reason.

And we also see that it's, uh, yeah, it's different on the autonomy level. And you see that the skill is great. A skill might be great in many times, but it simply doesn't have all these other higher level functioning.

And of course, just like a skill though, a custom agent has a front matter, it has instructions, and now the question is where do we place it? So let's go t- into another demo.

So, um, how many of you were using Copilot? It's like half the room, right? Right. So if you started using custom agents already, you would know that you have .github/agents, even though you can, I think, choose where to place it.

The important part is that you call it .agent. That, that's what makes it find it, right? But this is the, the custom place where it should live. But if we compare that a second to the skill, we see that the skill had name and description up here, whereas here we have argument hints and we have tools.

Tools is an important concept because that's able to constrain the agent what it can do or not, right? So in this case, the agent can read, it can search the web, it can create to-do lists and much more.

Um, I'm sure a similar concept ex- exists in Claude, by the way. So what I'm trying to say here is that this is much more than a skill as you can see, right?

Because it's able to go off and do things and maybe play well with other agents. In this case, it's a researcher. That's why we constrain it to work on the web and maybe not necessarily be able to create files or edit files or do things like that.

So a good use case here is maybe when I, I want to find out something, right? So were I to use it, I would go into my chat here and ask it questions maybe about the, yeah, for example, Microsoft Agent Framework or whatever I'm interested in.

So here I have a prompt, and I should get some kind of prompt response. And then I've also selected the researcher down here, so that's an important part. And this is very, of course, Copilot specific.

But if you look at the idea, I think you see that this is more than a skill, right? It's a thing that has tools, it has reasoning and so on and so forth.

Right. So now we're kind of approaching our,

uh, final chapter out of three because we're starting in the CLI. We started with saying, "Hey, maybe I have six different terminals that does things for me," everything from adding features to working on the latest MCP to fixing things to the scale part.

And here is where it gets interesting, right? Hopefully most of you still have a bunch of colleagues, but here is a lot of other colleagues and you need to keep track of them.

It f- it, uh, you've noticed that, and I'm gonna use an interesting word for agents here. I have heard people refer to them as toddlers. I don't know if [laughs] you've heard the same.

But the idea with agents is that sometimes we think they're super smart and sometimes they're just plain dumb, right? They literally go between genius and, "Oh my God, I can't believe you did this," right?

So you understand the harness, right? You need to understand the need for a harness. So what I'm trying to say here is that yes to all scaling, yes to all delegation, but you saw the need for adding guardrails.

So now that we feel good about this, now that we feel good about AGENTS.md, custom agents, custom instructions, we've laid the groundwork. Now we come to the interesting part of scaling ourselves because that's ultimately what it means, right?

Each of us could be the ten time developer, the 20 time developer or even 100 time developer. So we can scale in one of two different ways if you use Copilot, right?

We can either scale directly from the CLI or we can scale from the UI when we are looking at our GitHub repository. So we're in here, uh, and what we're doing here to scale is to call /delegate.

So here we simply say, "Create a finance app that tracks my spending. Use HTML, CSS and JavaScript." So here we're telling it to go build us an app, and this is just one of many terminal windows that we have open.

So by calling delegate then I should mention that this needs to be a proper GitHub repo or it's gonna complain. 'Cause if it's not it's gonna be like, "Hey, Chris, I can't do this.

I'm not a GitHub repo yet. Make me one." So here we, it just says, "Send this session to GitHub," and it does. So now it's gonna create a bunch of things.

It's try to... It starts a job, it creates a draft PR, and this is important Most of our agents work in sandboxes or all of them, right? So they can't really break out of the sandbox and do a bunch of weird stuff, but they can create the PR, and that brings us in as humans, as humans in

the loop. And of course, this can happen from GitHub also, if you have GitHub Enterprise. I don't know how many it does, but...

So this is by the way, what it looks like in, in, uh, GitHub. I just wanted to show you this. So had I clicked the link from the CLI, I would've ended up here.

It would've said, "Hey Chris, I'm working on your task. I'm trying to build you that finance app." So here is me using MCP servers like Playwright, GitHub's MCP, so on and so forth, right?

So that's the beauty, right? So imagine now that I had all these terminals open, I delegate this, I delegate that, and suddenly we worked on the entire product backlog.

Here's the other modality, and this is pretty much the same thing. We're just doing it from the GitHub user interface instead. So here we are simply saying, "I have created an issue."

The issue usually has more description than this, but I'm just showing you the principle. So here I'm saying, "Add dark mode to my app." I have a title, I have a description, and I have this thing over here.

So here I can assign to agent. So essentially if I'm in the user interface for a repo, I can just say, "Oh, here's a bunch of issues. Each of these issues are a next, uh, feature or a bug, uh, fix or whatever."

Delegate, delegate, delegate, delegate. And I go have a coffee, right?

So, whoop. So if we kick this off, you can just, uh, see me here having created this issue, and then I click Assign agent, and I can give it further instructions if I need.

That kicks things off. The first thing that's gonna happen is I'm gonna see this one. I'm gonna see this little icon here that says, "Ooh, Copilot. You called my name, right?"

So now Copilot is, uh, giving it a few seconds and you can see how it works on this WIP, this work in progress. You can click it, you can see exactly where it is, and this is where the human in the loop comes in, right?

'Cause once it's done, it's giving you a draft PR and say, "Hey Chris, what do you think of this? Is this something we can ship?"

So after a while it's gonna come back to me and, but the good part is this happens in the background and I can keep working on other things.

So this is really the power of delegation, right? This is how we scale ourselves to utilize our minds better. I usually compare this whole age, the strange age we live in, to people who used to cut down trees with axes.

I see we are now at the point where we're throwing the axes, we're using a chainsaw instead 'cause we are so much faster. This is not something that's new to us as developers, right?

We are used to better tools, and that's why I'm saying human in the loop. We are still important because we have built the system, right? We have built the system that instructs the agents to run amok within our harness.

We have approval gates our, ourselves, and we can probably add more approval gates,

and the agent is literally asking us for a review before and, and we can still be the ones that merge.

So in summary, if you haven't used any kind of CLI product before for agents, see what I showed you, six different terminals or more. You can get so much stuff done, whether it's your side project at home, whether you're working at, you know, a big enterprise company.

You can build new apps from the CLI if you dare venture out from the editor. Um, in your editor, I t-tend to use that less and less, but more like fine adjustments because sometimes an editor experience is just better, you know?

And, uh, yeah, the CLI or the GitHub UI can scale, it can delegate and, you know, we are 20 times the developer we used to be.

Providing, of course, we provided the right guardrails, right? Because 20 times more code, that could be 20 times more slop, and we don't want that. And, uh, yeah, the guardrails I'm introducing today, which I think many of you might know about, is AGENTS.md skills, custom agents and so on and so forth, and all about this is about

scaling you now that we have AI, not replacing you. So hopefully I'm landing you with a good message to say, "We want the engineering brain, so please stay in this industry," right?

So thank you so much, folks. [applause] [outro music]