What your junior engineer does now that agents take the tickets

Your junior used to get the flaky test, the copy change, the CSS bug, and the dependency bump. Three agents clear that list before standup now, and you are looking at an empty queue with a salaried human sitting next to it.

What follows is a staffing plan for whoever has to fill that queue on Monday, percentages included so you have something to argue with. My bias, stated once so you can discount it: the junior belongs in the review column, because on most teams the reviewer today is nobody. The number for that is in the fourth section.

The roster, before the rationale

Nobody publishes a ticket mix for this, so the allocation below is a recommendation to tune, not a finding. The one external input is merge data. An MSR 2026 study of 33,000 agent-authored pull requests found documentation, CI and build changes merge best while performance and bug-fix work merges worst (Ehsani et al., 21 January 2026, five agents). Put your person where the agent's merge rate is lowest.

Lane	Starting share of the week	What it produces
Spec authorship	30%	Tickets an agent finishes without asking
First review of agent PRs	30%	A review comment before the senior looks
Owned delivery in agent-barred classes	25%	Shipped work with their name on it
Judgment work: reproduction, ambiguity, cross-service	15%	A decision someone else can act on

Write it down, percentages included, even though they are guesses. LeadDev's AI Impact Report 2025 found that 38% of respondents agreed AI tools have reduced the direct mentoring junior engineers receive from seniors, and that 18% expected fewer junior hires within a year against 10% expecting fewer senior hires (Chantal Kapani, 4 September 2025). Mentoring that used to happen over a shared bug does not happen by accident anymore.

Lane one: they write the ticket the agent executes

Spec authorship is defect prevention, and there is data behind that now. A May 2026 study of 20,574 real coding-agent sessions across 1,639 repositories sorted the visible failures into seven recurring forms. The biggest, at 38.33%, was the agent violating a constraint the developer had already stated. Misreading intent came second at 26.95%, and in 44.10% of those episodes the gap sat in the prompt itself. Across the whole set, 91.49% of the resolutions the authors could observe needed a human to step in and correct the agent.

Those three numbers are the lane: write the constraints down, write them precisely, and keep a human nearby for the times neither worked.

So the ticket carries acceptance criteria a machine can check, reproduction steps, the module boundary, an explicit do-not-touch list, and the test that proves it. Ticket shape is its own subject, covered in write tickets AI agents can finish.

You cannot measure this on a dashboard, and I would rather say so than pretend. The proxy is manual: assigning an issue to an agent auto-creates a pending session, and a stuck agent moves it to needs_input. Count blocked sessions on tickets that person wrote.

curl -s "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=needs_input" \
  -H "Authorization: Bearer tfk_live_a1b2..."

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?state=needs_input",
  { headers: { Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}` } },
);

{
  "data": [
    {
      "issue_key": "WEB-241",
      "state": "needs_input",
      "note": "Spec does not say if retries are per delivery or per endpoint."
    }
  ]
}

Read ten of those notes and you know what your junior is not writing down yet. WEB-241 is a spec defect with a timestamp.

House position, flagged as a position: spec quality is your promotion signal to mid-level. No research supports that, and the counter-argument going around is that specs are load-bearing so seniors should own them. That has the learning backwards. Writing a spec that survives contact with an executor is how a person finds out whether they understand the system.

Lane two: the review column is their desk

Add a real column between In progress and Done and call it Agent review. A label leaves the card sitting in In progress where nobody counts it; a column makes an unreviewed agent PR visibly stuck. Map it to the in review status category, which is what cross-project views filter on.

The board with an Agent review column between In progress and Done, holding agent cards.

Give the column a definition of ready or it fills with half-finished work. Four conditions: the session is in review state, its external URL points at an open PR, CI is green, and the note says what changed and what the agent left alone. Sending a card back is the junior's call, not the senior's.

flowchart TD
  A["Ticket is ready"] --> B{"On the register?"}
  B -->|"Senior class"| C["Senior owns it"]
  B -->|"Judgment class"| D["Junior owns it"]
  B -->|"Neither"| E["Agent picks it up"]
  E --> F["Agent review column"]
  F --> G["Junior first review"]
  G -->|"Signs off"| H["Senior merges"]
  G -->|"Escalates"| C

The part that usually goes unwritten is the split: what the first reviewer signs off alone, and what they hand up untouched.

First reviewer signs off on	Escalates to a senior
The diff does what the ticket said	Anything on the register below
Tests assert behaviour, not that code ran	A change larger than the ticket described
No duplicate of code that exists already	Migrations, contract changes, new dependencies
Error paths exist and are reachable	A design choice they cannot explain back
The session note matches the diff	Anything read twice and still not judgeable

Drill the third row hardest. GitClear's 2026 maintainability report, drawn from 623 million code changes since 2023, puts duplicated blocks at 73.0 per million changed lines this year against 40.3 in 2023, while moved or refactored lines fell from 21% of changes in 2022 to 3.8%. Agents rebuild rather than reuse. "Does this already exist?" is a check a junior can run with grep and six weeks of codebase memory, and right now nobody runs it. Getting a new engineer to those six weeks when most of the code was generated is its own job, covered in onboarding a new engineer to code your agents wrote.

Why review became the bottleneck is argued in why AI made code review the bottleneck; this section is only about who stands in the column.

The objection, and why I think it loses

The standard objection is that only a senior can safely review generated code, so putting a junior on agent PRs is reckless. On its own terms that is reasonable. It also measures against a baseline nobody has.

A study published on 4 May 2026 classified review activity on 33,596 agent-authored pull requests in repositories with 100 or more stars. It found 61.38% received no recorded review at all. Counting bot reviewers as reviewers, 84.0% got either nothing or agent-only review, leaving 15.9% with any documented human participation.

The authors flag the caveat themselves: a maintainer can read a PR without leaving a trace, so this counts recorded review, not attention. Discount it as far as you honestly can and the shape holds. Junior-first review is not competing with senior-first review. It is competing with nobody.

The safety argument sits on one boundary: the junior reviews, the senior merges. The first review is additive. It catches the cheap defects, a test that asserts nothing or a reimplemented helper, and hands up the rest with a specific question attached. Better use of senior attention than a cold read of a 400-line diff.

A live agent session on the issue, with its state chip, note, and pull request link.

One check belongs in the routine: does a finished session leave a trace on the issue? A session marked done with no attributed activity and no comment gets flagged as unverified. One comment defeats the heuristic, so treat the flag as a prompt to look. That habit is expanded in managing a team of AI agents.

Lane three: the do-not-delegate register

Most versions of this list conflate two things, and a lead who follows them hands a junior the payments migration. Keep two lists. Work an agent may not do is not the same as work the junior owns.

# do-not-delegate.yml, reviewed monthly
senior_only:      # agent barred, junior does not own the merge either
  - authentication
  - authorization
  - cryptography and keys
  - payment and refund paths
  - personal data paths
  - database migrations
  - public API contracts
  - infrastructure and deploy config
junior_owned:     # agent barred: the spec must be discovered, not executed
  - customer bugs with no reproduction yet
  - requirements with an open question in them
  - changes crossing more than one service
  - performance work

The second list is the harder half: the spec does not exist yet and somebody has to go find it, which is also where the merge data says agents do worst.

The principle underneath a register, reversible versus not, is worked out in decision rights between your team and your AI agents. The list above is the ticket-class version.

What the tool enforces, and what is only a convention

A register you believe is enforced when it is not is worse than one you know is only a norm.

Exactly one mechanism turns a register line into a hard boundary, and it is not on the agent settings page. A scoped project restricts access to its explicit members, and a connected agent joins the workspace as an ordinary member, so a scoped project nobody added it to answers its API key with a 404. Move the payments and infrastructure work into its own scoped project and the first list stops being a promise.

Two more controls enforce, on a different axis. Allowed transitions are a hard gate: a status move that is not on a column's allowed list is refused at every write path, REST and MCP included. Per-agent field policy is an allowlist over 14 issue fields, checked at one choke point that covers REST, the transition endpoint, MCP and the time endpoint. An agent whose policy leaves out assignee cannot reassign anything, however it calls in.

A partial field-policy allowlist: this agent writes title, description and status, nothing else.

Three things look like controls and are not. WIP limits are a counter and a colour; nothing refuses a card. Transition rules are project-scoped and actor-blind, so you cannot let a human move a card to Done while barring an agent from the same move. Field policy is per-field, not per-value, so "may set status, but only to Agent review" is not expressible.

What the product gives the lane is identity. A connected agent is a real member with its own user row, so it appears in the assignee picker and in activity, and every write carries its name. Policy setup is in how to set agent field permissions, column mechanics in custom workflow statuses. Connected agents are excluded from seat counting, so the junior reviewing them is a $3 editor seat and the agents add nothing to the bill.

Lane four: the judgment ladder

The thousand small fixes that used to build instinct are gone. If you do not replace them deliberately, nothing replaces them.

Weeks	What they own	Signal you are looking for
1 to 2	Read agent sessions end to end. Review nothing alone.	They name what the agent skipped
3 to 6	First review on low-risk agent PRs, senior re-reviews each	Comments arrive before the senior's
7 to 12	First review on all non-register PRs, specs for their tickets	needs_input on their tickets drops
Quarter 2	Own a junior-list class outright, agent-assisted, end to end	They reject a plausible diff and say why

That last signal is the one that matters. Anyone can approve; the skill is the confidence to refuse something that looks right and then say what is wrong with it.

The review queue as a shared workspace view, so it is one link rather than a rebuilt filter.

Give them a saved, shared view of that queue rather than a filter they rebuild every morning (how to save and share views). A cross-project view filters on the status category, not your column name, which is the reason to categorise Agent review as in review: one link then covers every project's review queue.

Where this plan is weak

It assumes you have a senior with review bandwidth, which is the exact thing the industry is short of. Without one, the plan degrades into "a junior approves agent code unsupervised," and I would not run that.

On tooling: no skills matrix, no career ladder, no reviewer-assignment engine. Roles are five fixed ones, so there is no custom role meaning "may review but may not close a ticket"; Jira and Asana sell permission schemes for that shape and we do not. A workspace view takes a single assignee id, so there is no single "everything any agent touched" view. Agent cost is self-reported, because the agent spends on its own provider account, so a spend figure can raise a flag and never block anything.

The lanes are a convention. One scoped project makes part of the register real, two controls narrow what an agent may write, and the rest is you, checking.

Start with one column

Do one thing this week. Add the Agent review column, name your junior as its first reviewer in writing, and put five ticket classes on the do-not-delegate list. In two weeks, look at which agent PRs went around the column anyway. That list is your real policy.