GitHub's pipeline agents leave developers approving and accepting, not coding

In an agent pipeline, a developer's main job can shift from writing code to deciding what moves forward and whether the result is accepted. Jose Palafox, a Field Copilot Specialist at GitHub, described this design on the AI Engineer podcast. The episode is "From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot."

What was said

Palafox walked through a flow built with GitHub Agentic Workflows. A first agent runs on a schedule and scans a repository for improvements. His example was duplicated code. He said agents often cause that problem themselves: "The agents are lazy about implementing functions, and they're really lazy about namespacing, so they'll just create constant duplication inside the code base."

The agent reports what it finds. The developer reads the findings and decides which are worth fixing. They signal that choice with a slash command, typed as a comment on the issue. A product-manager agent then scopes the feature and writes a plan. It hands the plan to Copilot to implement. The developer returns at an acceptance phase to look at the code and decide whether to take it in.

Palafox said the framework adds checkpoints so people can "review and decide when you're actually going to spend money" on the next phase. He called GitHub's own Agentic Workflows project the maximalist case. Agents built it entirely, he said, and its team aims to work only from mobile devices through those slash commands.

Why it matters

The checkpoints also work as cost controls, going by Palafox's remark about spending money. For buyers, a useful question about any agent pipeline is where a human decides, and who that person is.

The other side

Palafox works at GitHub and helps companies adopt Copilot. This is a vendor describing its own design. His strongest example is GitHub's own project, not a customer's.

By his own account, the code being reviewed has flaws, since agents produce duplication. In his flow, agents also find the work and plan it, so the human judges what the agents surface. The talk did not say how well reviewers catch problems, or how people learn to judge code they no longer write. That training question stays open.