This closing topic assembles everything from the module into one continuous workflow: a developer pushes a branch, an AI agent handles the MR paperwork, CI runs and gets monitored, failures get triaged automatically, and review comments get drafted before a human ever opens the GitLab web UI. None of the individual steps are new — what matters here is how they chain together into something you'd actually run daily, and where you should keep a human explicitly in the loop rather than letting the chain run unsupervised.
Workflow Overview: From Code Push to Merged MR Using AI
The end-to-end shape looks like this:
1. Developer pushes feature branch
2. AI agent: reads diff, drafts MR (title, description, labels, reviewers)
3. GitLab CI runs the pipeline automatically (unchanged — MCP doesn't touch this)
4. AI agent: monitors pipeline, triages any failure, posts a status comment
5. AI agent: on request, reviews the diff and posts inline comments
6. Human: reviews AI-assisted MR, approves or requests changes
7. AI agent: once approved + pipeline green, merges per policy
The critical design decision is where automation stops and a human decision starts. Steps 2, 4, and 5 are genuinely safe to automate — they're additive (comments, labels, descriptions) and don't change what gets merged. Step 7 is where you need real guardrails: branch protection rules, required approval counts, and — my strong recommendation — never letting an agent merge without an explicit human approval already recorded in GitLab, even if your token technically has merge_merge_request access. Use the agent to check conditions and report readiness; keep the actual merge action as an explicit, deliberate command a person gives (or, for genuinely mature teams, a scheduled/triggered automation with its own audit trail, distinct from ad-hoc agent chat).
This workflow assumes the GitLab MCP server is already configured (Topics 1–5 in this module) and that you've settled on scoped tokens per the security guidance in Topic 1 — a merge-capable agent token should be a project or group access token, not a personal one, and should exist behind branch protection regardless.
Tips
- Automate the additive steps (description, labels, status comments, review drafts) freely; treat the merge action itself as a deliberate, explicit human-triggered step.
- Rely on GitLab's branch protection and approval rules as the real enforcement layer — agent judgment is a helpful signal, not a substitute for platform-level guardrails.
- Document this workflow (which steps are automated, which need a human) somewhere your team can see it — an undocumented AI workflow that quietly merges things is a support incident waiting to happen.
Step 1: AI-Generated MR Description, Labels, and Reviewers
Once a branch is pushed and ready, the agent's job is to produce an MR that a human reviewer can act on immediately — not a placeholder that still needs manual rewriting.
I just pushed feature/async-order-processing to my-group/order-service,
branched from main. Create a merge request:
1. Read the actual diff between this branch and main.
2. Write a description with: what changed, why, and any migration/config
steps a reviewer needs to know about.
3. Add labels based on what changed — use "backend", "needs-migration" if
there's a database migration file in the diff, and "needs-review".
4. Suggest 2 reviewers based on git blame on the files most heavily
changed (whoever touched them most recently, excluding me).
5. Don't merge or request review notifications yet — just create the draft.
This prompt is deliberately specific about grounding the description in the real diff (not the branch name), conditionally applying the needs-migration label based on actual file contents, and using git history (git blame/git log, which the agent can run locally alongside the GitLab MCP calls) to suggest reviewers rather than guessing from a static team list. The "don't merge or request review notifications yet" line matters — GitLab MCP's create_merge_request can optionally trigger reviewer notifications immediately, and you often want a beat to sanity-check the draft first.
A realistic generated description looks like this — expect to lightly edit it, not accept it verbatim:
## What changed
Adds async processing for order fulfillment via a new Celery task queue.
Orders over $500 now route through `process_order_async()` instead of
the synchronous `process_order()` path.
## Why
Synchronous processing was blocking the request thread for orders
requiring fraud-check API calls (p95 latency was 4.2s on this path).
## Migration
Adds `orders.async_status` column — migration `0047_add_async_status`.
Run `python manage.py migrate` before deploying. No backfill needed;
column defaults to NULL for existing rows.
## Testing
Added unit tests for the new task; no changes to existing sync path tests.
Applying the MR once you've reviewed the draft:
That description looks good, add one clarification: mention that the
Celery worker count needs to be at least 2 in production config. Then
finalize the MR and request review from the two people you suggested.
Tips
- Ground every generated description in the real diff, never the branch name — call this out explicitly in the prompt if you notice the agent skipping the diff-read step.
- Use git blame/log for reviewer suggestions, not a static team roster — it naturally accounts for who's actually been in those files recently.
- Hold off on triggering reviewer notifications until you've glanced at the generated draft — a two-second human check before pinging reviewers avoids embarrassing typos or wrong migration claims going out.
Step 2: Pipeline Status Monitoring and Failure Triage with MCP
Once the MR exists, GitLab CI runs automatically — MCP doesn't trigger or replace this, it just gives your agent eyes on the result.
Setting up a monitoring check (run manually or on a loop/schedule depending on your tooling):
Check the pipeline status for MR !312 in my-group/order-service. If it's
still running, tell me which stage it's on. If it finished, tell me
pass/fail and, if it failed, pull the failed job's log and give me a
root-cause hypothesis.
For a failure, a good triage response distinguishes between failure classes rather than defaulting to "there's a bug":
Pipeline #58291 failed at stage "test" on job "pytest-integration".
Log excerpt shows: `psycopg2.OperationalError: could not connect to
server: Connection timed out`. This looks like a transient
infrastructure/database-connectivity issue in the test environment, not
a code regression — the test file itself wasn't modified in this MR's
diff. Recommend: retry the pipeline once. If it fails again with the
same error, escalate to infra rather than debugging the test code.
That last sentence — checking whether the failing test file is even part of the diff — is a genuinely valuable triage signal a careful agent can surface: a failure in code you didn't touch is much more likely infrastructure or a pre-existing flaky test than something your change caused. Ask for this explicitly if the agent doesn't volunteer it:
Before suggesting a fix, check: was the failing test file or the code it
tests modified anywhere in this MR's diff? If not, treat this as likely
unrelated to my change.
Acting on the triage:
Since this looks infrastructure-related and unrelated to my diff, retry
the pipeline once. If it passes on retry, post a brief note on the MR
explaining the retry was due to a transient DB connection issue in CI,
not a code problem.
Posting that explanatory note matters more than it sounds — a reviewer who sees a red-then-green pipeline history without context reasonably wonders what happened. A one-line note closes that loop.
Tips
- Have the agent check whether the failing test/file is even part of the MR's diff before hypothesizing a code-level cause — unrelated-file failures point strongly toward infra or flakiness.
- Post a brief explanatory MR comment whenever you retry a pipeline — it prevents reviewer confusion over an unexplained red-then-green history.
- Cap automatic retries at one; a pipeline that fails the same way twice needs a human or infra team, not a third automatic retry.
Step 3: Automated Code Review Comments on Merge Requests
The highest-leverage and highest-risk automation in this whole workflow is AI-generated review comments — genuinely useful for catching mechanical issues fast, genuinely risky if treated as a substitute for a human reviewer's judgment on design and correctness.
A well-scoped review request:
Review the diff for MR !312 in my-group/order-service. Focus only on:
error handling gaps, missing null checks, and any hardcoded values that
should be config. Don't comment on style or naming — we have a linter
for that. Post inline comments for anything you find, and a summary
comment at the top listing what you checked.
Scoping the review to specific concerns (error handling, config, null safety) rather than "review this code" produces sharper, less noisy output — a completely open-ended review prompt tends to generate a mix of genuinely useful catches and low-value style nitpicks that erode trust in the tool over time.
A generated inline comment, for context on what good output looks like:
On line 84 of order_processor.py: this call to
`external_api.check_fraud_score()` doesn't have a timeout or
try/except around it. If the fraud-check API is slow or down, this
would block the async task indefinitely rather than failing gracefully
into the existing manual-review fallback path. Worth wrapping in a
timeout + except block that routes to `flag_for_manual_review()`?
And the summary comment posted at the top of the MR:
AI review summary (scoped to error handling, null checks, hardcoded
config only):
- 1 potential issue: missing timeout on external fraud-check call (see
inline comment on order_processor.py:84)
- No missing null checks found in the modified files
- No hardcoded values found that should be config
This is an automated first pass — please still review for logic and
design correctness.
That last line is not boilerplate CYA — it's an accurate statement of what the review did and didn't cover, and it should be in every AI-generated review summary your team ships. An AI review pass is a fast, cheap first filter for mechanical issues; it is not a substitute for a human thinking about whether the change is the right change.
Closing the loop once a human has weighed in:
I agree with the timeout comment, I've pushed a fix. Reply to that
discussion thread confirming it's addressed, and re-check the diff for
anything else that changed in the fix commit.
Tips
- Scope AI review prompts to specific concern categories (error handling, security, config) rather than an open "review this" — sharper signal, less noise, and it keeps the linter's job separate from the agent's.
- Always label AI-generated review summaries as an automated first pass explicitly in the posted comment — sets correct expectations for the human reviewer and avoids over-trusting it.
- Reply into the existing discussion thread when a fix is pushed for a specific comment, not a new top-level note — keeps the review history readable for whoever's approving.
Tips
Tips
- Keep the merge action itself as an explicit, human-triggered step regardless of how much of the rest of the pipeline you automate — branch protection plus a deliberate human "yes, merge it" is the guardrail that actually matters.
- Scope every automated step (review focus, retry count, label conditions) narrowly and explicitly in your prompts — vague instructions are where agentic workflows drift into doing more than you intended.
- Revisit this workflow's token scopes periodically (Topic 1's security guidance) — a workflow that started read-only and grew write permissions over time is exactly the kind of scope creep worth auditing every quarter.