PulseFlow Tecnologia
← Insights
·6 min read·framework-playbook·agent-adoption·coding-agents·software-engineering
PulseFlow Tecnologia

A playbook for adopting AI agents in software engineering

Most teams don't fail by picking the wrong coding agent - they fail by jumping straight to "putting an agent to work" without first designing the flow it will operate inside. Two real cases show the two ends of that spectrum: the GitHub Copilot coding agent, built to operate inside a team's existing PR flow, and OpenAI's harness engineering experiment, where an entire repository (~1 million lines, 1,500+ PRs) was built by agents alone. Most companies will travel somewhere between those two points.

How the flow actually works (Copilot coding agent)

GitHub describes the Copilot coding agent's operation in five concrete steps: (1) someone assigns an issue to Copilot via GitHub.com, GitHub Mobile, VS Code, or the agents panel; (2) the agent opens a draft pull request, marked [WIP], on a dedicated branch (copilot/*); (3) the agent explores the repository, makes changes, and runs tests and lint; (4) it updates the PR with a title and description and requests human review; (5) the team iterates by commenting @copilot directly on the PR. As GitHub puts it, the agent "operates directly within GitHub's pull request flow," and "every step is logged, visible, and open to team participation" - nothing happens outside the review process that already exists.

The other extreme: legibility at scale (harness engineering)

OpenAI's experiment shows how far this path can go when a repository is designed from day one to be read by agents, not humans. Over five months, three engineers driving agents produced roughly a million lines of code and more than 1,500 merged PRs - with no line written manually. The central lesson wasn't about which model was used, but about "legibility": the team had to move context that normally lived in Slack conversations into the repository itself, because it was as invisible to the agent as it would be to a new hire.

A ten-step playbook

Combining both ends - incremental adoption inside an existing flow, and the more mature case of agentic execution at scale - a realistic adoption playbook runs through:

  1. Diagnosis - map where the bottleneck is today (bugs, test coverage, refactoring - the same task types GitHub recommends as an entry point)
  2. Use-case selection - start with low-to-medium complexity issues, not the most critical item in the backlog
  3. Agent definition - who does what (a bug-fix agent isn't the same as a refactoring agent)
  4. Tool definition - what the agent can access and run
  5. AGENTS.md - the artifact that gives context and boundaries, as in both the Copilot example and OpenAI's case
  6. Spec-driven workflow - an issue becomes a spec before it becomes code
  7. Tests - mandatory before any PR is considered ready for review
  8. Observability - every step logged and visible, as in Copilot's PR flow
  9. Metrics - PRs per period, approval rate without rework, cycle time
  10. Scale - only after validating the previous steps on small repositories, expand to more teams and more autonomy

The practical point

The difference between "having an agent" and "having real agent adoption" isn't the tool - it's how much of the surrounding process (context, review, tests, observability) already existed before the agent arrived. Teams that try to jump straight to high autonomy without that process tend to accumulate rework; the ones that start from the existing PR flow, as the Copilot coding agent proposes, get a far more predictable ramp toward the maturity level OpenAI documented.

Sources