Agentic Software Engineering: When AI Agents Become Software Developers

A year ago, an agent-authored pull request was a novelty worth screenshotting. Today, in many of the engineering organisations we work with, agents open a steady share of pull requests every week: dependency upgrades, test fixes, small features and bug fixes from well-written issues.

At that point, agents are no longer just tools individual developers use. They are contributors to the codebase, and they raise questions that belong to engineering management as much as to engineering.

#Agents need a defined role

The teams that get consistent value from agents are explicit about what agents are for. A typical role definition:

• In scope: dependency and framework upgrades, test coverage, flaky test fixes, lint and type errors, small bugs with reproductions, well-specified features behind flags, documentation updates.
• Out of scope: architecture changes, security-sensitive modules (authentication, payments, cryptography), database migrations in production, CI/CD configuration.
• Always: changes arrive as pull requests; nothing merges without human review.

Writing this down prevents both under-use ("we tried it once") and over-reach ("the agent refactored the auth service").

#Onboarding an agent

New human engineers get an onboarding plan. Agents need one too, and it looks surprisingly similar:

• A project guide: how to build, test and run the project; conventions; directories to avoid; how to name branches and write commit messages. Most agent tools read an instructions file in the repository.
• A working environment: a reproducible development container with dependencies and test data, so the agent can run the full test suite.
• Examples of good work: well-structured PRs and tests it can imitate.
• Feedback: reviewers' comments on agent PRs, captured in the project guide when patterns recur.

# AGENT_GUIDE.md (excerpt)
- Build: `make build`   Test: `make test` (must pass before opening a PR)
- Style: follow existing patterns in /internal/billing; prefer table-driven tests
- Never modify: /internal/auth, /deploy, .github/workflows
- PR description must include: what changed, why, how it was tested, open questions
- If a task needs a schema change, stop and ask for human confirmation

#Assigning work

Agent-sized work has three properties: it is well specified, verifiable by tests or clear criteria, and bounded in scope. Good teams:

• keep a labelled backlog of agent-suitable tasks,
• write issues with acceptance criteria and reproduction steps,
• break larger work into agent-sized pieces, and
• reserve ambiguous, cross-cutting or high-risk work for humans.

#Identity and access

Each agent integration should have its own identity: its own bot account or app, with commits and actions attributable to it. Permissions follow least privilege: open pull requests, comment and push to its own branches, with no merge rights, no access to production secrets and no ability to change CI configuration.

#Accountability

The question that matters most: who is responsible when agent-written code causes an incident?

The answer we recommend is simple and unambiguous: accountability stays with named humans.

• The task owner who assigned the work is responsible for its specification.
• The reviewer who approved the pull request is responsible for its correctness and safety, exactly as for human-written code.
• The agent owner (often a platform or developer productivity team) is responsible for the agent's configuration, permissions and guardrails.

flowchart LR
  TO[Task owner<br/>specifies] --> AG[Agent<br/>implements]
  AG --> PR[Pull request]
  PR --> RV[Reviewer<br/>approves: accountable<br/>for what merges]
  AO[Agent owner<br/>configures & constrains] -.-> AG
  RV --> Main[Main branch]

#Measuring agent contribution

Volume is a poor measure: agents can produce a lot of code quickly. Better measures:

• merge rate: what share of agent PRs are merged,
• rework: how much reviewers had to change,
• durability: how often agent changes are reverted or rewritten soon after,
• defect rate: incidents or bugs traced to agent changes,
• cycle time for agent-suitable tasks, and
• cost per merged change.

These numbers tell you where agents are genuinely helping and where their output creates more review work than it saves.

#What happens to the team

Teams with productive agents change shape gradually:

• engineers spend more time on specification, review and design,
• someone owns agent configuration and quality as part of developer productivity,
• review becomes a more visible, valued skill, and
• deliberate effort is needed to keep junior engineers learning by doing, not only by reviewing.

#The bottom line

When agents become regular contributors, managing them well looks a lot like managing any contributor: a clear role, a good onboarding, well-specified work, appropriate access, honest measurement and clear accountability, which always rests with people. Organisations that treat agents this way turn a powerful tool into dependable engineering capacity.

Our secure SDLC team runs agent-assisted engineering on client projects under exactly these practices, and our agentic AI security practice helps organisations set them up.