Inside the AI-Augmented Developer Workflow

Walk one ordinary ticket through eleven steps (ticket, context gathering, agent draft, local test, security scan, pull request, AI review, human review, CI gate, deploy, monitor) and the pattern is consistent: automation takes the mechanical checks, and the human reviewer's attention moves to domain judgment. This is an illustrative scenario, not a measured case study.

The scenario below is illustrative, written to show the workflow, not a report of a real project.

Demos of coding agents are almost always the best case: a clean greenfield function, a clear spec, a green checkmark. The interesting failures, and the interesting wins, show up on an ordinary ticket in an existing codebase with real constraints. Here is one, walked through in full, the way it actually happens rather than the way it looks in a product video.

The ticket: "Support agent responses sometimes cite a document that was archived more than 90 days ago. Add a filter so archived documents older than 90 days are excluded from retrieval unless a user explicitly asks for historical policy."

This is a good AI-augmented ticket: well-scoped, testable, touches a known subsystem (the RAG retrieval layer described in Production RAG architecture), and has a clear wrong answer if it goes badly (silently changing which documents are excluded in a way nobody notices).

1. Ticket

The ticket above is well-specified enough that a coding agent can act on it directly. A vague ticket, like "make the RAG answers better," is not. The first job in an AI-augmented workflow is often turning a vague ask into something this concrete, and that's frequently a human-only step, because it requires understanding what "better" means to the person who filed it.

2. AI context gathering

Before writing anything, the engineer points a coding agent at the ticket and lets it gather context: which files implement retrieval filtering, how document metadata (including archive date) is currently modeled, and whether a similar filter exists elsewhere in the codebase to follow as a convention. This step is where agents are genuinely strong: reading across a large codebase faster than a human would, and surfacing the two or three files that actually matter instead of the twenty that mention "document" somewhere.

3. Coding agent draft

Given the ticket and the gathered context, the agent proposes a diff: a new filter predicate in the retrieval query layer, a metadata field check (archived_at), a default 90-day cutoff, and an override path for the "explicitly asks for historical policy" case, which it implements as a simple intent flag rather than trying to infer the user's intent from free text, a reasonable, conservative choice.

def apply_recency_filter(candidates: list[Document], want_historical: bool, now: datetime) -> list[Document]:
    if want_historical:
        return candidates
    cutoff = now - timedelta(days=90)
    return [
        d for d in candidates
        if d.archived_at is None or d.archived_at > cutoff
    ]

The agent also drafts unit tests: documents archived 91 days ago are excluded, documents archived 89 days ago are kept, non-archived documents are always kept, and the historical override bypasses the filter.

4. Local test

The engineer runs the tests locally rather than trusting the agent's own report that they pass. A coding agent's summary of test results is not itself a test result. Two of four tests pass; the boundary test at exactly 90 days fails, because the agent used > instead of >= in a way that didn't match the ticket's stated cutoff. This is normal, not a failure of the tool: it's exactly the kind of off-by-one a fast first draft produces, and exactly why local verification is not optional.

5. Security scan

Because this change touches the retrieval query layer, an automated scan checks for the class of risk that matters here: does the new filter apply consistently to every retrieval path, or could a differently-constructed query bypass it? In this case the scan flags a second retrieval path (a "related documents" sidebar feature) that calls a lower-level function directly and would skip the new filter. That's a real finding a human would likely have also caught in review, but catching it before review, not during, saves a review round-trip.

6. Pull request

The engineer opens the PR with the fix for the boundary condition and the second retrieval path applied, and writes a description that states the intent plainly: what changed, why, and what was verified locally. This step matters even when an agent could technically generate the description: the PR description is a communication to the human reviewer, and a vague AI-generated summary of "updated retrieval filtering" gives the reviewer nothing to check against.

7. AI review pass

An automated review pass runs against the PR before a human looks at it: checks for style consistency, flags that the new archived_at comparison should use the same timezone-aware datetime handling as the rest of the module (it didn't, initially), and confirms test coverage includes the boundary case that failed locally. This pass is fast, mechanical, and catches exactly the kind of consistency issue that's tedious for a human reviewer to spot but trivial for a tool to check every time.

8. Human review

A human reviewer reads the diff with the AI review comments already resolved, which means they can spend their attention on the part that actually needs judgment: is excluding a document based on archived_at the right signal at all, or should the retrieval layer instead check the document's effective status (a document can be archived but still the authoritative answer for a discontinued but still-supported product line)? This is the conversation an AI review pass isn't equipped to have, because it requires domain knowledge about what "archived" means in this business, not just whether the code is internally consistent.

9. CI/CD gate

CI runs the full test suite plus the evaluation regression set described in LLM evaluation fundamentals for production, since this change affects which documents reach the model as context. The regression set includes a case exactly like the one from Why good retrieval still produces bad answers: a policy question where the correct document was recently un-archived. The gate passes.

10. Deploy

The change rolls out to 10% of support-assistant traffic first, with retrieval recall and evidence-retention metrics monitored against the pre-change baseline for two hours before the rollout continues: a small, reversible step for a change that touches what evidence the model can see.

11. Monitor

A week later, observability catches a secondary effect nobody scoped for: a small number of support queries about a specific discontinued-but-still-supported product now retrieve zero documents, because every relevant document for that product line had been archived more than 90 days ago and none of the tickets flagged "historical policy" intent. This is the human reviewer's earlier concern, now showing up in production data: a case for a follow-up ticket, not a rollback, but a real reminder that the review conversation in step 8 was catching something real.

• Tickets handed to a coding agent are scoped concretely enough to have a checkable right answer
• Test results are verified independently of the agent's own summary
• An automated review pass runs before human review, and its findings are resolved first
• Human review time is spent on domain judgment, not mechanical consistency checks
• Changes touching retrieval, prompts, or model config pass through an evaluation regression gate
• Deploys are progressive, with monitoring on the specific metric the change could affect
• A "this looked fine but might have a subtle scope gap" comment from review gets a follow-up ticket, not silence

What does an AI-augmented developer workflow look like? An ordinary ticket moves through context gathering by a coding agent, an agent draft, local tests run by the engineer, an automated security scan, a pull request, an AI review pass, human review, a CI evaluation gate, a progressive deploy and monitoring.

Can I trust a coding agent's test results? No. A coding agent's summary of test results is a claim, not a result. Run the tests yourself, locally and in CI, on infrastructure the agent does not control.

What does the human reviewer do once AI reviews first? They spend their attention on domain judgment: whether the change is right for the business, such as whether archive date is the correct signal, rather than on style or boundary conditions that automation already checked.

Which changes need an evaluation regression gate? Any change that affects what the model sees or does: retrieval settings, prompts, or model version. Here the filter changed which documents reach the model as context.

Why roll out to a small share of traffic first? A small, reversible step lets you watch metrics such as retrieval recall and evidence retention against the pre-change baseline before the rollout continues.

Is the ticket in this article a real project? No. It is an illustrative scenario written to show the workflow.

• The Enterprise AI Engineering Blueprint (Part 1 of this series)
• The AI-Native SDLC (Part 2)
• Enterprise AI Guardrails (Part 4)
• The 90-Day Enterprise AI Adoption Playbook (Part 5)
• AI agent loops, stopping conditions and guardrails
• Why good retrieval still produces bad answers