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

How much of your development work still looks like it did before coding agents? Chris Noring, who works on AI engineering at Microsoft, opens with that question. Few people in the room raise their hands. A second poll finds users of Claude and GitHub Copilot roughly split, perhaps leaning toward Claude. The change is already underway for this audience.

In the old workflow, the developer personally wrote the code. Progress depended on one person’s time: building one feature meant postponing another. The opening slide captures that arrangement as IDE-first work, one thread of execution, and linear progress.

The engineering bottleneck moves when implementation can be delegated. Developers still write code, but become more selective about where their attention belongs. That shift also creates a quality problem: early AI-generated code could take so much rewriting that it increased the workload. Producing more code only helps when the surrounding workflow constrains what gets produced.

Noring treats adopting an AI tool as unavoidable, but presents his preferred workflow as a proposal, not a requirement. The available surfaces already extend beyond an IDE: Claude Code and Claude Desktop, Copilot’s CLI, editor integrations, and GitHub’s web interface. The practical question is where each surface belongs in the work.

His sequence starts in a place that can feel unfamiliar to an application developer: the terminal. This does not require becoming a Bash or PowerShell specialist. The CLI is an entry point for describing work before opening an editor. The editor comes second—still a familiar home after what Noring describes as nineteen and a half of his twenty industry years spent there. Finally, the CLI and GitHub UI become entry points for delegation.

The first useful output can be a draft application or MVP. Noring recounts businesses seeing engineers bring working demos instead of PowerPoint proposals: an executable way to ask whether an idea matches what someone wants. Guardrails accompany that first draft. The CLI also handles ordinary repository work—issues, pull requests, and status checks. His example of closing fifteen issues without opening VS Code illustrates why some tasks never need an editor at all.

The next demonstration shows the consequence of starting with prompts. Instead of personally writing every Java, JavaScript, or Python change, the developer has several terminals working on different requests: build an application, fix an issue, add a feature, build another application. Noring describes letting those tasks run while he drinks coffee or tea. The important change is concurrent implementation, not the beverage break.

Moving into the editor then means configuring guardrails and custom agents, inspecting work, and making selected changes. Noring imagines fifteen or twenty agents doing implementation work, making continuous manual authoring a smaller part of the day. He still values the editor’s familiarity and sense of control, and describes integrations that can expose activity from terminals, the editor, and GitHub repositories. The editor becomes a control board for work happening in several places. Without rules, however, the same concurrency multiplies unwanted behavior.

The first guardrail is AGENTS.md: high-level guidance describing repository intent, architecture, responsibilities, and permitted changes. Noring’s example is a finance application using React and Tailwind, with an explicit constraint against changing the architecture without being asked. These instructions give an agent project context; they are not an enforced security boundary. A compact version of that guidance could read:

# Project overview
This finance application uses React and Tailwind.

# Agent responsibilities
Implement requested features within the existing architecture.
Follow the project's existing UI patterns.

# Architecture constraints
Do not change the application architecture unless explicitly asked.

In the demonstration, Noring opens a finance tracker he built with AI assistance and shows its longer AGENTS.md, including a project overview and agent responsibilities. He asks Copilot what the file does. He also suggests bringing guidance from another project into a fresh repository and asking the agent to adapt the codebase to it. The file makes the intended constraints available for that conversation.

Repository guidance does not solve every execution problem. An agent may perform a recurring task almost correctly, or take it in an entirely wrong direction. Skills address that problem by supplying a repeatable recipe: what to do, which tools to use, and in what order. Noring calls this a strict contract, meaning a discipline for constraining improvisation; instructions alone do not guarantee deterministic execution. A skill is invoked by an agent and packaged as a self-contained folder.

Each skill has its own directory containing SKILL.md. The file begins with YAML front matter containing a name and description, followed by Markdown instructions. Noring names .claude/skills for Claude; the accompanying slide also lists .github/skills and .agents/skills. Shared conventions matter because developers do not always choose which provider their organization uses.

In the editor demonstration, he starts with an existing skill folder and asks Copilot to improve the instructions for the intended task. He also shows a UI for adding a skill. In the demonstrated interface, /skills opens configuration; a prompt resembling a skill’s name or description can invoke it. The description therefore helps the agent recognize when the recipe is relevant, while the body supplies the procedure to follow.

A recipe does not decide how to coordinate other recipes. When the task needs planning, reasoning, or orchestration, Noring moves up to a custom agent. It has a distinct role—such as security specialist, back-end developer, or front-end developer—and can use multiple skills and MCP servers.

The distinction is where decisions live. A skill supplies task knowledge; the agent decides how to apply that knowledge within its assigned role.

Copilot custom-agent definitions also use front matter followed by instructions. Noring places them in .github/agents and refers to .agent in the filename. For a file created today, VS Code’s documented format is <name>.agent.md; current discovery also accepts other Markdown files in that directory. Compared with the skill definition, the demonstration adds argument hints and a tools field. Tool access limits what the agent can do, rather than merely describing what it ought to do.

The example is a researcher. Its permitted tools include reading, web search, and to-do lists; file creation and editing can be withheld because they are unnecessary for that role. Noring selects the researcher in Copilot chat and asks about Microsoft Agent Framework. The demonstration is of selecting a role with reasoning and tools, not simply invoking one fixed recipe. He suggests a comparable concept exists in Claude, but the interface shown is Copilot’s.

With those constraints in place, the workflow returns to the terminals and scales outward. Noring imagines six sessions handling features, MCP work, and fixes. The challenge is keeping track of agents that can alternate between excellent reasoning and surprisingly poor decisions—hence his comparison to toddlers. Repository guidance, custom instructions, and custom agents form the harness before delegation expands. His references to tenfold, twentyfold, or hundredfold developers express the ambition of this workflow, not measured productivity results.

The CLI route uses /delegate. Noring asks it to create a finance application that tracks spending using HTML, CSS, and JavaScript. This is a separate, plain-web-stack request from the earlier React-and-Tailwind repository guidance example. The handoff proceeds as follows:

1. Start from a GitHub repository; Noring notes that delegation complains if the project is not one.
2. Send the session to GitHub using /delegate.
3. Let the remote job begin and create a draft pull request.
4. Review the proposed changes before deciding whether to ship them.

This is remote delegation, distinct from local autopilot running on the developer’s machine.

Noring describes the agents as sandboxed, but sandboxing should not be read as a guarantee of universal containment. The concrete review boundary here is the draft PR: agent work returns as a proposal for a human to inspect. He associates the GitHub-side workflow with GitHub Enterprise in the talk; that remark does not establish a general plan requirement.

Following the CLI’s link opens the task on GitHub, where its progress can be inspected. Noring mentions Playwright MCP and GitHub’s MCP server while showing the finance-app task. The proposed scaling pattern is to delegate separate terminal tasks across the product backlog and follow their work through GitHub.

The GitHub UI offers another starting point for the same delegation pattern. Noring creates an issue asking to add dark mode to the application, with a title and description. He notes that a real issue would usually need more detail. Features and bug fixes can both enter through this route: select an issue and assign it to an agent.

In the demonstration, clicking Assign agent allows further instructions. A Copilot indicator appears, followed by a clickable work-in-progress item that exposes the task’s status. The eventual handoff is a draft PR for the developer to assess, not an automatic decision that the change should ship. Because execution happens in the background, the developer can continue other work while waiting for that reviewable result.

Noring compares the change to moving from axes to chainsaws: developers have repeatedly adopted tools that increase how much they can do. The human role remains consequential because engineers build the system that directs the agents. They establish the harness, place approval gates, add more gates where needed, review proposed changes, and can remain the people who merge them.

That leaves a practical division of attention: use the CLI to start applications and concurrent tasks, return to the editor for fine adjustments when its interface is better, and delegate through the CLI or GitHub UI. Noring’s closing 20× developer claim is conditional rhetoric: 20× more code could also mean 20× more slop without the right guardrails. AGENTS.md, skills, and custom agents are the mechanisms he proposes for directing that additional output.

The intended outcome is to scale engineers, not replace them. Implementation can move into background jobs; deciding what to build, how to constrain it, and whether the result belongs in the product still requires an engineering mind. Noring ends by asking those minds to stay in the industry.