Developer

The developer owns the code they ship, whoever or whatever typed it. AI (artificial intelligence) changes this role in two ways. First, a coding agent joins the work, and it must work inside guardrails that the developer did not have to think about before. Second, the developer starts to build products that contain a model, and those need controls that ordinary features never needed.

A coding agent can write a change; it cannot approve one. Numbers on this page are illustrative.

Guardrails first, agent second. Set up the instructions file, scoped context, secret blocking and protected paths before the first delegated task, then let the CI (continuous integration) pipeline and branch protection enforce what the agent might skip.

1. At a glance

Line: 1st line · Family: Build · Variants: application developer, full-stack developer

2. Your journey: first steps to fully adopted

The developer moves from asking the assistant to explain code to delegated changes inside enforced guardrails; each stage adds controls and evidence, never the right for an agent to approve.

Start here: your first steps

1. Complete acceptable use and install the approved tool configuration for your repository.
2. Merge a reviewed instructions file, with secret blocking and protected paths turned on.
3. Turn on the reuse advisory, and merge your first reuse-decision.yaml.
4. Ask the agent for unit tests from the acceptance criteria and the temporal test matrix, then check each case.

Fully adopted: how the work runs

What changes for the organization

In any organization

• Who covers it: in a small or unregulated organization, one or two developers and a lead do this work; a second person still approves every merge.
• What scales: sandboxes, evaluation sets and code-owner rules can shrink to simple repository settings. What never drops: human approval of every merge, no secrets or customer data in unapproved tools, and a kill switch for any AI feature.

3. Your decisions

4. Two kinds of adoption

Coding agents inside guardrails

Set these up before the first delegated task. Some are advisory (they guide the agent and can be skipped). Some are enforced (they run whether or not anyone used an agent). See reuse first for the full layered design and tools for how each tool names these features.

When the product contains AI

These controls belong in the code, not in the prompt. A prompt is a request to the model; the code decides what actually happens.

A tool definition with its permission scope, as the developer would commit it (illustrative):

{
  "name": "search_policy",
  "description": "Search approved, current policy sections. Read-only. Returns section ids and text.",
  "input_schema": {
    "type": "object",
    "properties": {
      "question": { "type": "string", "maxLength": 500 },
      "max_results": { "type": "integer", "minimum": 1, "maximum": 5 }
    },
    "required": ["question"]
  },
  "x-permission": {
    "scope": "policy-index:read",
    "identity": "end-user",
    "entitlement_check": "at-execution",
    "writes": false
  }
}

The x-permission block is read by the team's own tool router, not by the model. The router refuses the call if the signed-in staff member lacks the scope.

5. Your ladder

Stays human-operated at Stage 5: approving a merge, deciding to create a new shared asset, and responding to a leaked secret (rotation, report, clean-up). An agent may draft the steps; a developer with the authority does them.

6. Priority scenarios

7. The due-date ask from your seat

The developer carries the change from accepted stories to merged pull requests. The full story is in the worked example.

A negative path you will meet. The agent suggests pasting production customer records into an unapproved tool "to reproduce the bug." You refuse, use synthetic data and report a near miss. The egress policy would also block the tool; your report is what lets the team improve the instructions file.

8. Hand-offs and separation of duties

Separation of duties. When a coding agent opened the pull request, the person who asked the agent is the author. That person cannot approve it. Branch protection enforces this, not the agent's own settings.

9. Evidence and records

Templates: team instructions file, reuse decision record, hook specification.

10. Skills and learning path

11. Measures and incentives

The developer is evaluated on changes that stay correct, not on lines or pull requests produced with AI.

12. Cost, capacity and workforce

13. Anti-patterns and stop conditions

14. Action kit and 30/60/90

A starter instructions file section the team can adapt (illustrative). Lab L1 builds the full file.

## Rules for the coding agent · v1
- Before writing any helper or utility, query the asset catalog for the capability.
- Write reuse-decision.yaml for every new file under a utility path.
- Dates: the due date is date-only (LocalDate). Never parse it into a date-time.
- The cutoff is an Instant from payment-schedule-service. Never calculate it. Format it only with formatPaymentCutoff(cutoffInstant, customerZone).
- Never read .env, key files or anything under /secrets.
- Do not edit: CI configuration, branch rules, migrations, this file.
- Use synthetic data only. Never request or paste customer records.
- One concern per pull request. Note "AI-assisted" in the description.
- Run the test command before proposing a pull request.

Questions to ask your enablement lead

• Which coding agent configuration is approved for this repository's data classification?
• Where is the near-miss register, and who reads it?
• Which evaluation set and threshold apply before we delegate a task at Stage 3?