AI has moved developers' work toward planning, system design, and deciding what code is worth writing.
2
A repository needs explicit guardrails such as agents.md, skills, and custom agents so delegated work follows its architecture and standards.
3
GitHub Copilot CLI and the GitHub UI can delegate tasks to agents that work in sandboxes and return draft pull requests for human review.
Summary
Chris Noring argues that AI has changed the developer's center of gravity. Developers still write code, but they spend less time producing every line and more time deciding what should be built, how the system should fit together, and how work should be divided among agents. He proposes starting in a CLI, using the editor for control and fine adjustments, and scaling through the CLI or GitHub UI. This workflow needs explicit constraints. Noring presents agents.md as repository-level guidance for architecture, intent, and rules. Skills provide repeatable recipes with strict contracts. Custom agents operate at a broader level, with roles, tools, planning, and reasoning. Delegated work runs in a sandbox, creates a draft pull request, and leaves approval and merging to a human. Noring is direct about the risk: faster code without guardrails can produce more slop.
Noring says developers are no longer limited by their own ability to write every feature. Their job has shifted from being "100% developers" toward deciding where their time matters. They still write code, but they are "very, very, very precious" with what they write because AI tools can produce much of the implementation. He describes this as a change in the center of gravity rather than the disappearance of the developer role. The work now includes setting direction, reviewing output, and managing the helpers that produce it.
The CLI can become the first entry point for development
Noring proposes starting projects from a command-line interface instead of opening the editor first. The CLI can handle work such as creating and managing GitHub issues, pull requests, and status checks. He gives the example of closing 15 issues without opening a visual interface. The editor remains familiar ground after nearly two decades of Noring's own work there, but he sees it as a second point in the workflow. Scaling can happen through multiple CLI sessions and through the GitHub UI.
Noring says agents can produce incorrect or inconsistent work, so projects need rules before they scale. His minimum recommendation is an agents.md file in every repository. It should explain the repository's intent, application architecture, constraints, and dos and don'ts. An example might say that an agent must not change the architecture without permission, then describe a finance application built with React and Tailwind. He also shows copying an agents.md file from an older project and asking an agent to bring a new codebase into compliance with it.
A skill is a recipe for work that needs to happen in a repeatable order. Noring describes it as a contract that an agent can invoke instead of improvising logic. A skill can specify which tools to use and constrain the agent's behavior. In GitHub Copilot, a skill lives in its own folder with a skill.md file containing front matter, a name, a description, and detailed instructions. Skills can be invoked with "/skills" or through a prompt that matches the skill's name or description.
When a skill is too limited to coordinate a task, Noring recommends a custom agent. A custom agent has a distinct role and purpose, such as security expert, back-end developer, front-end developer, or researcher. It can use multiple skills, reason about a task, plan, and connect to MCP servers. Noring contrasts this broader scope with a skill's narrow contract. In Copilot, custom agents can specify tools, which constrains what they can do. His researcher example can read and search the web without necessarily creating or editing files.
Delegation works through sandboxes and draft pull requests
Noring demonstrates calling "/delegate" from the CLI to ask Copilot to create a finance app with HTML, CSS, and JavaScript. The session is sent to GitHub, where a job starts and a draft pull request is created. Agents work in sandboxes, so they cannot freely alter everything around them. The draft pull request brings a person back into the process. The same pattern can start from a GitHub issue, where an agent is assigned to implement a feature such as dark mode and then reports its progress through a work-in-progress change.
Noring says delegation does not remove the developer from the process. The developer designs the system, writes the instructions, creates the harness, and sets approval gates. The agent asks for review before the change is merged, and the developer can still be the person who merges it. He recommends using the editor for fine adjustments while letting the CLI and GitHub UI handle scale. The benefit depends on the guardrails, because producing 20 times more code could also produce 20 times more unwanted code.
"You are no longer 100% developers, but you are now in a different position."01:50
Who should watch
You are deciding whether your team should start agent work from the CLI, the editor, or the GitHub UI.
Your agents produce code that is technically plausible but does not follow your architecture, tools, or repository rules.
You want to delegate issues and feature work while keeping sandboxing, draft pull requests, and human approval in the workflow.
