# From Writing Code to Designing Systems: How the Developer Role is Changing — Chris Noring, Microsoft AI Engineer · 2026-07-11 Chris Noring from Microsoft argues that the developer role is shifting from writing code to designing systems and orchestrating AI agents, using tools like GitHub Copilot and Claude. He proposes a workflow starting with the CLI rather than the editor, employing agents.md for high-level guidance, skills for repeatable tasks, and custom agents for orchestration. Noring demonstrates scaling by delegating tasks via /delegate in the CLI or assigning issues to agents in the GitHub UI, allowing developers to become 20x more productive. He stresses that guardrails are essential to prevent agents from producing 'slop', and that human-in-the-loop oversight remains critical. The episode emphasizes that developers must encode standards and constraints into their workflows to maintain consistency and quality at scale. ## Questions this episode answers ### How is the developer role changing with the rise of AI coding assistants? Chris Noring explains that developers are shifting from being 100% code producers to planners, system designers, and orchestrators of AI agents. Instead of writing every line, they set intent, enforce standards, and coordinate autonomous agents to deliver features faster and with higher consistency, becoming '10-time' or even '100-time developers.' [1:42](https://aie.addtry.com/32a0af99-61ec-4ccc-ab53-eb75e49be770?t=102000) ### How do I prevent AI coding agents from producing inconsistent or incorrect code? Chris Noring recommends using guardrails: an agents.md file with high-level project intent, architecture constraints, and do's/don'ts; skills for repeatable tasks with strict contracts; and custom agents that combine reasoning, tools, and multiple skills. These harnesses keep agents from improvising and ensure they follow company standards. [8:00](https://aie.addtry.com/32a0af99-61ec-4ccc-ab53-eb75e49be770?t=480000) ### How can I delegate entire features or bug fixes to AI agents in bulk? Chris Noring demonstrates using GitHub Copilot’s '/delegate' command in the CLI or assigning agents to GitHub issues. This kicks off agentic workflows that create draft pull requests with human-in-the-loop review gates, allowing developers to work on many tasks in parallel and effectively scale themselves. [17:36](https://aie.addtry.com/32a0af99-61ec-4ccc-ab53-eb75e49be770?t=1056000) ## Key moments - **[0:00] Intro** - **[1:13] Role shift** - **[3:06] CLI first** - [3:06] Chris Noring proposes a new AI development workflow: start in CLI, move to editor, then scale with agents. - [4:55] Chris Noring reports engineers now bring working demos instead of PowerPoints. - [5:48] "We don't write in Java or JavaScript or Python so much anymore. It's prompts." - **[7:58] Guardrails** - [8:15] agents.md is a high-level guardrail file for repository intent, architecture, and constraints. - **[9:30] Skills** - [10:13] A skill acts as a contract that agents invoke to prevent improvisation, mitigating risk. - **[12:50] Custom agents** - [13:09] Custom agents have personas, use multiple skills, and integrate MCP servers for broader autonomy. - **[16:12] Scaling** - [16:30] "I have heard people refer to agents as toddlers," says Chris Noring, highlighting unpredictability. - **[18:20] Human review** - [19:32] "Delegate, delegate, delegate, delegate, and I go have a coffee," says Chris Noring on using AI agents. - [20:59] "We are now at the point where we're throwing the axes, we're using a chainsaw instead," says Chris Noring. - **[21:45] Takeaways** - [22:05] "We are 20 times the developer we used to be, provided we provided the right guardrails," says Chris Noring. - [22:37] "All about this is about scaling you now that we have AI, not replacing you," says Chris Noring. ## Speakers - **Chris Noring** (guest) ## Topics Multi-Agent Orchestration, Agent Skill Design, Guardrails ## Mentioned Anthropic (company), Microsoft (company), Claude (product), Copilot Chat (product), GitHub (product), GitHub Copilot (product), GitHub Copilot CLI (product), VS Code (product) ## Transcript ### Intro **Chris Noring** [0:15] Hey folks, we're 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, 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, heh. 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. ### Role shift **Chris Noring** [1:13] 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, 100% 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 100% 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 100% 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? I think so. So to some extent, we're still writing code, we just are 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's no longer an option not to use one. But of course you are thinking, "Which AI tool am I using?" Right? 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. ### CLI first **Chris Noring** [3:22] 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 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, because I don't need to. So I can sit, just sit there, and I start in 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 20 years in the industry, 20 of those years, or at least 19 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 comes 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 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'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 my first 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 15 issues without even seeing the, you know, user interface. So that's definitely a use case I want to use. Issues, PRs, you know, status checks. But of course, you've noticed as we start using 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 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 going to 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 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 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 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 out of 20 with an editor, so I feel more in control, I feel more used to it. So I'm not going to 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 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 mentioned AI slope 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. ### Guardrails **Chris Noring** [8:15] 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 go into an agent's, 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, vibe coded,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 bottomright 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? ### Skills **Chris Noring** [9:30] So agents.md 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 think you've noticed this as you work with agents, is that it's almost the same,right? 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 going to 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 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 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 vendor 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, 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 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. ### Custom agents **Chris Noring** [12:50] 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, you're probably using agents, and you might not know what I'm after, but we have this thing in GitHub Copilot called a 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 an n number of skills. So it has a distinct role and purpose. So think security expert, backend, frontender. 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 a 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 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'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 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 want to find out something,right? So where I'd 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. ### Scaling **Chris Noring** [16:12] 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 do things for me," everything from adding features to working on the latest MCP, to fixing things, to the scale part. And here's where it gets interesting,right? Hopefully most of you still have a bunch of colleagues, but here's a lot of other colleagues, and you need to keep track of them. It, it, uh, you've noticed that, and I'm going to use an interesting word for agents here, I have heard people refer to them as toddlers. I don't know if 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 10-time developer, the 20-time developer, or even 100-time developer. So we can scale in one of two different ways if we 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, and I should mention that this needs to be a proper GitHub repo, or it's going to complain. Because if it's not, it's going to 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 going to create a bunch of things. ### Human review **Chris Noring** [18:20] It's tried 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 a 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 GitHub. I just wanted to show you this. So had I clicked the link from the CLI, I would have ended up here. It would have 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 feature or bug fix or whatever. Delegate, delegate, delegate, delegate," and I go have a coffee,right? So, oop. So if we kick this off, you can just 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 going to happen is I'm going to see this one. I'm going to see this little icon here that says, "Ooh, Copilot, you called my name,"right? So now Copilot is giving it a few seconds, and you can see how it works on this VIP, 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? Because 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 going to 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, this 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, because 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 this system,right? We have built this system that instructs the agents to run a mock within our harness. We have approval gates 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. ### Takeaways **Chris Noring** [21:45] 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 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 theright 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. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.