Spec-Driven Development with AI Agents and GitLab

AI agents are changing software development, but the useful change is not that they remove engineering discipline. If anything, they make discipline more visible. An agent can move quickly through a codebase, edit several files, run tests, and come back with a polished-looking result. That is useful. It is also exactly why vague intent becomes dangerous faster than it used to.

Spec Kit is interesting because it gives that speed a shape.

Spec Kit is a specification-driven development toolkit from GitHub. Its core workflow is deliberately plain: describe what needs to be built, refine the intent, turn it into a technical plan, break the plan into tasks, implement the tasks, and verify that the result still matches the specification. I like that framing because it treats the agent less like a magic text box and more like a capable collaborator who needs the same things any engineer needs: context, constraints, and a clear definition of done.

Most AI-assisted development does not go wrong because the generated code has bad syntax. It goes wrong because the agent built the wrong thing, missed a hidden rule, overfitted to one example, changed more than the team asked for, or solved a local problem while breaking a system-level constraint. Those are not new software problems. AI just compresses the timeline.

The point is not to stop using agents. The point is to put them inside a delivery process that can absorb their speed without losing accountability.

The Problem with Prompt-First Development#

Many teams start with AI by asking a coding assistant to do something directly:

Add pagination to the search endpoint.

That looks efficient. It also hides most of the work.

What kind of pagination? Offset or cursor-based? What is the default page size? What is the maximum? Should sorting be stable? How does it interact with authorization? Does it need backward compatibility? Should the response shape change? What happens when the requested cursor no longer exists? Which clients depend on the current behavior?

An experienced engineer often carries those questions around implicitly because they know the system and have been burned by these details before. An AI agent only has what is in its context window, repository access, tools, and instructions. If the task is underspecified, it will usually keep going anyway. It will infer. Sometimes that inference is helpful; sometimes it creates a production bug with beautifully formatted code.

Spec-driven development moves ambiguity to the front of the process, where it is cheaper to deal with. Instead of asking the agent to code immediately, you ask it to help produce artifacts that can be reviewed: a specification, a plan, a checklist, a task breakdown, and finally an implementation. For engineers, that means fewer hidden assumptions in the diff. For managers and product owners, it means the team can inspect intent before implementation cost is already sunk.

What Spec Kit Adds#

According to the official Spec Kit documentation, the default process is:

Spec -> Plan -> Tasks -> Implement

For production work, the fuller flow adds quality gates:

Constitution -> Specify -> Clarify -> Plan -> Checklist -> Tasks -> Analyze -> Implement -> Converge

The useful part is the separation of concerns.

The specification describes what and why. It should focus on user-visible behavior, business rules, constraints, acceptance criteria, and edge cases. It should not decide too early which framework, database pattern, or implementation technique will be used.

The plan describes how. It maps the specification onto your architecture, data model, APIs, testing approach, migration strategy, operational constraints, and delivery path. This is where engineering judgment belongs.

The task list describes execution. It turns the plan into ordered work that an agent or human can complete incrementally. That matters because one large AI-generated change is still one large change; it does not become easier to review because the author was faster.

The analysis and convergence steps create feedback loops. They check whether the spec, plan, tasks, and implementation still agree. In normal project work that alignment is often assumed. In agentic work, I would rather make it explicit.

Why AI Agents Need Specifications#

An AI agent is good at local reasoning over available context. It can inspect files, modify code, run tests, summarize errors, and iterate quickly. Software development, though, is rarely local for long. A small API change can touch contracts, migrations, observability, deployment, compliance, and user workflows.

A good specification gives the agent a stable target. Without a specification, the agent optimizes for the prompt. With a specification, it can optimize for the product behavior.

A plan gives the agent architectural boundaries. It can still make choices, but those choices sit inside the system you actually operate. Tasks keep the work reviewable. Convergence gives the team a moment to compare the result back to the original intent instead of assuming the final diff tells the whole story.

The goal is not to make the agent think less. The goal is to make it think inside better boundaries.

Where Agents Fit in the Software Development Chain#

AI agents can help throughout the software development lifecycle, but they should not have the same amount of autonomy everywhere. The useful model is not "agent writes code." The useful model is a chain of guarded responsibilities, where the agent can accelerate research, drafting, implementation, and verification while humans keep ownership over intent, risk, and acceptance.

1. Discovery and Research#

Early in a feature, an agent can inspect the codebase, read existing APIs, summarize related modules, compare implementation options, and identify likely risks. In GitLab, this fits naturally around issues and work items. Before implementation starts, an agent can comment on an issue with the affected files and services, the patterns already present in the repository, likely test locations, dependencies, integration points, and open questions that still need product or architecture input.

This is a good place to use agents quite actively because the output is advisory. The agent is not changing production code. It is helping the team sharpen the problem statement before anybody starts moving classes around. In practice, this is often where the biggest time saving is: not typing code faster, but finding the right place to make the change.

Example prompt in a GitLab issue:

Research how search pagination currently works in this repository.
Identify existing controller, service, repository, and test patterns.
Do not change code. Post findings and open questions as an issue comment.

That research can feed the Spec Kit specification.

2. Requirements and Specification#

This is where Spec Kit starts to earn its keep.

The /speckit.specify step creates or updates a feature specification from natural language. The documentation is explicit that this step should focus on what and why, not the tech stack. That distinction prevents the team from turning a requirement into a half-written implementation plan before the behavior is clear.

For example:

/speckit.specify
Add cursor-based pagination to the case search API so large result sets can be browsed reliably.
Clients must receive a stable next cursor when more results are available.
Existing filters and authorization rules must continue to apply.
The first release must remain backward compatible with the current response format.

This is already better than "add pagination."

A strong specification usually covers the user journey, functional and non-functional requirements, acceptance criteria, authorization behavior, API compatibility, failure modes, observability expectations, and explicit non-goals. The exact format matters less than the completeness. If a product owner reads it, they should recognize the intended behavior. If an engineer reads it, they should see enough boundaries to avoid inventing requirements during implementation.

The non-goals matter more than people expect. Agents are eager. If the task says "improve search," an agent may refactor ranking, change indexing, alter DTOs, and update UI behavior in one merge request. If the specification says "do not change ranking, filters, or response field names," the agent has a boundary it can respect.

3. Clarification#

Spec Kit includes a clarification step for underspecified areas. This is one of the most valuable parts of the process because ambiguity has a habit of turning into code.

Good clarification questions are specific:

• Should the cursor encode sort direction?
• What is the maximum page size?
• Should deleted or unauthorized records be silently skipped?
• Does the cursor expire?
• Must old clients be able to ignore the new fields?
• Should pagination metadata be included for empty result sets?

In a GitLab workflow, these questions belong in the issue before development starts. That gives product owners, architects, security specialists, and maintainers a chance to answer in the same place where delivery will later be tracked. It also gives managers a clearer view of why a feature that sounded small may carry real integration or compliance risk.

The key discipline: do not treat unanswered questions as implementation freedom. Treat them as risk.

4. Technical Planning#

The /speckit.plan step moves from product intent to engineering design.

This is where you tell the agent about your stack and constraints:

/speckit.plan
Use Java 21, Spring Boot, PostgreSQL, Flyway, and GitLab CI.
Keep controller DTOs backward compatible.
Add integration tests for repository pagination and contract tests for the REST response.
Use the existing ApiError format for validation failures.

A good plan names the files and modules likely to change, the database changes and migration strategy, API design, validation and error handling, security implications, test strategy, rollout and rollback approach, and pipeline impact. That sounds like overhead until you compare it with the cost of finding these mismatches during review, or worse, after release.

This is also where architecture guardrails belong. If the system uses hexagonal architecture, layered services, CQRS, feature flags, contract testing, or specific package conventions, write them into the plan. "Follow existing patterns" helps, but it is often too soft. "New read behavior belongs in SearchQueryService; controllers remain thin; repository methods must return domain objects, not response DTOs" gives the agent something concrete to follow.

For engineering managers, this planning step is where speed and risk meet. A clear plan reduces rework, keeps merge requests smaller, and gives reviewers a way to challenge the design before the implementation becomes expensive to unwind.

5. Requirement Checklists#

Spec Kit's checklist step is useful because it treats requirements as something that can be reviewed before implementation. That is a cultural shift.

Teams often review code carefully while giving requirements a quick scan. AI makes that habit more expensive. If an agent can generate hundreds of lines quickly, weak requirements become expensive quickly too.

A checklist can ask:

• Are all user-visible behaviors testable?
• Are authorization rules explicit?
• Are backward compatibility requirements stated?
• Are error cases defined?
• Are observability requirements included?
• Are migration and rollback expectations clear?
• Are performance constraints measurable?

In GitLab, this checklist can become part of the merge request description or an issue checklist. For important work, require a human reviewer to confirm it before implementation starts. The official Spec Kit docs describe custom checklists as reviewer-owned requirements-quality artifacts, not as implementation progress.

That distinction is subtle and important. The agent can help generate and evaluate the checklist, but it should not silently approve its own requirements. I would apply the same rule here as with code review: assistance is welcome, ownership stays human.

6. Task Breakdown#

The /speckit.tasks step turns the plan into an ordered task list. This is where agentic work becomes manageable because the implementation stops being one giant instruction and becomes a sequence of small, reviewable changes.

1. Add pagination value objects and validation rules.
2. Add repository query support for cursor pagination.
3. Add service-level pagination behavior while preserving authorization.
4. Extend response DTOs with optional pagination metadata.
5. Add integration tests for default, max, empty, and unauthorized-result cases.
6. Update API documentation.
7. Run full test and lint pipeline.

The task list also makes the GitLab merge request strategy visible. For a small feature, one MR may be fine. For larger work, the same task list might become separate MRs for internal model and repository support, service and API behavior behind a feature flag, client adoption and documentation, and cleanup after rollout.

That keeps reviews small and CI feedback fast. It also makes agent output easier to inspect, which matters a lot when the diff was produced in minutes but still needs to live in your codebase for years.

7. Implementation#

Implementation is the obvious place to use AI agents, but by this point the agent should be working from a richer context: spec.md, plan.md, tasks.md, checklist results, repository conventions, GitLab issue discussion, and CI pipeline expectations.

The prompt becomes less magical and more operational:

/speckit.implement
Implement only the repository and service tasks for cursor pagination.
Do not change controller response DTOs yet.
Run the relevant unit and integration tests.
Stop after updating the task list with completed items.

That scope control matters. Large agent runs are harder to review. They are also more likely to introduce unrelated changes. This is one of those places where the old advice still holds: if you would not want a human colleague to put it all in one MR, do not ask an agent to do it either.

In GitLab, an agent can work on a branch, push commits, and open a merge request. GitLab's own Duo Developer Flow is designed for tasks like creating draft merge requests from issues, iterating on review feedback, researching implementation approaches, splitting large merge requests, and resolving merge conflicts. That makes GitLab a natural place to connect issue context, agent execution, CI feedback, and human review.

But the merge request is still the control point. The agent may write code. Humans still own acceptance.

8. Continuous Integration#

CI is where agent output meets reality.

GitLab CI/CD pipelines are configured in .gitlab-ci.yml. Pipelines consist of jobs and stages, and they can run on push, merge request creation, schedules, or manual triggers. That makes CI the natural verification layer for agentic development.

For AI-assisted work, a solid GitLab pipeline should cover formatting, static analysis, unit tests, integration tests, contract tests, security scanning, dependency scanning, container scanning where relevant, migration validation, and build or packaging. The exact mix depends on the system, but the principle does not: the agent's code should pass the same gates as everyone else's code.

Agents can help maintain the pipeline too. GitLab documents agentic flows for converting legacy CI/CD pipelines to GitLab CI/CD and for diagnosing and fixing failing pipelines. There is also a CI Expert Agent listed in GitLab's Agent Platform documentation as a beta or experimental capability.

For managers, this is where automation protects cost. A good CI setup catches cheap failures before they become expensive coordination, release, or production problems.

The principle is simple: agents may propose pipeline fixes, but pipelines must remain the authority.

If an agent changes code and the pipeline fails, the next agent task should be narrow:

Inspect the failed GitLab pipeline.
Identify the failing job and root cause.
Change only what is needed to restore the pipeline.
Do not weaken or remove tests.

That last sentence is worth keeping. Agents under pressure can make tests pass by reducing the value of the test. Your instructions and review process should make that unacceptable.

9. Code Review#

AI-assisted code review is valuable when it is used as an additional reviewer, not as a replacement for ownership.

GitLab has both non-agentic Duo Code Review and agentic Code Review Flow, depending on configuration. The non-agentic review focuses on merge request context and diffs. The agentic Code Review Flow is part of the GitLab Duo Agent Platform and is described by GitLab as having broader repository and cross-file awareness.

Use AI review for the kinds of things where another fast pass helps: obvious defects, missing tests, risky edge cases, inconsistent patterns, security smells, documentation gaps, and large-diff summarization. Do not use it as the final authority for business correctness, acceptable risk, security sign-off, architecture ownership, or regulatory compliance.

The best pattern is layered review:

1. The agent self-checks against the spec, plan, and tasks.
2. CI verifies executable behavior.
3. AI review provides fast secondary feedback.
4. Human reviewers make the merge decision.

That is not slower than traditional development if the work is sliced well. In practice, it often shortens the loop because reviewers receive a smaller MR with better context and earlier automated feedback.

10. Security and Compliance#

Security is one of the strongest use cases for agents, and also one of the areas where overtrust is most dangerous.

GitLab's Agent Platform documentation lists security-focused capabilities such as SAST false positive detection, SAST vulnerability resolution, Secret false positive detection, Security Analyst Agent, and Security Review Flow. The SAST vulnerability resolution flow can analyze vulnerabilities and generate merge requests with proposed fixes. The Security Review Flow is positioned differently: it looks for business logic vulnerabilities in merge requests, such as authorization mistakes or incorrect assumptions in control flow.

These are useful tools, but they produce advisory output. GitLab's own Security Review Flow documentation states that AI-generated results are not a complete or authoritative security assessment.

In practical terms, agents can triage findings, propose fixes, prepare remediation MRs, and help preserve the trail of decisions in GitLab issues, merge requests, approvals, and pipeline results. Humans still need to review risk acceptance, and the scanners and policies in CI should stay in place. Removing a scanner because an agent found no issues is not a security strategy.

For regulated environments, this audit trail may be as important as the code change itself. For managers, that traceability lowers delivery risk because decisions are visible after the sprint is over, not reconstructed from memory when an audit or incident review asks uncomfortable questions.

11. Release, Monitoring, and Operations#

Agents can also help after merge. They can summarize release notes, inspect deployment failures, analyze logs, compare error rates before and after deployment, draft rollback instructions, and identify suspicious trends. The useful boundary is that they should usually prepare decisions, not take irreversible actions.

Good operational prompts are concrete:

Compare the last successful deployment with the failed deployment.
Summarize changed services, failed jobs, and likely causes.
Do not trigger a rollback. Prepare a recommendation for the release manager.

For production operations, the more destructive the action, the stronger the human gate should be. That is not a lack of trust in the tooling; it is basic operational hygiene.

A GitLab-Centered Reference Workflow#

Here is what this can look like in practice.

Step 1: Create a GitLab Issue#

Start with a normal GitLab issue:

## Goal
Add cursor-based pagination to the case search API.

## Background
The endpoint currently returns all matching cases. This causes slow responses and high memory usage for large result sets.

## Constraints
- Existing clients must keep working.
- Authorization rules must not change.
- Search ranking must not change.
- The first release should be safe to roll back.

## Acceptance Criteria
- Clients can request the first page without a cursor.
- Clients receive a next cursor when more results exist.
- Invalid cursors return the standard API error format.
- Page size defaults to 25 and is capped at 100.
- Tests cover empty results, max page size, invalid cursor, and unauthorized records.

Step 2: Use an Agent for Repository Research#

Ask the agent to inspect the existing implementation and comment on the issue. No code changes yet.

Expected output:

• current controller and service flow
• repository query strategy
• existing pagination patterns
• relevant test classes
• risks and open questions

Step 3: Create the Spec Kit Specification#

Run the specification step:

/speckit.specify
Use the GitLab issue as source context. Create a feature specification for cursor-based pagination on the case search API. Focus on external behavior, constraints, acceptance criteria, and non-goals. Do not choose implementation details yet.

Review the generated spec.md. Tighten vague language, remove accidental implementation choices, and add missing edge cases. This is the moment to be a little strict; every vague sentence that survives here tends to become somebody's guess later.

Step 4: Clarify#

Run clarification:

/speckit.clarify
Focus on cursor behavior, authorization filtering, backward compatibility, and error handling.

Answer the questions in the issue or directly through the agent. Commit the clarified spec.

Step 5: Plan the Implementation#

Now plan:

/speckit.plan
Use Java 21, Spring Boot, PostgreSQL, Flyway, GitLab CI, and the existing layered architecture. Keep controller DTO changes backward compatible. Add repository integration tests and API contract tests. Use the existing structured logging and ApiError conventions.

Review plan.md like you would review an architecture decision. The plan is not just agent scratch work. It is a design artifact.

Step 6: Generate a Checklist#

Generate and review a requirements checklist:

/speckit.checklist
Focus on API compatibility, authorization, pagination correctness, and rollback safety.

In GitLab, copy the key checklist items into the issue or MR description if that improves visibility. Mark them only after human review.

Step 7: Generate Tasks#

Run:

/speckit.tasks

Then decide the merge request structure. If the generated task list is large, split it before implementation. This is a human engineering judgment moment.

Step 8: Let the Agent Implement One Slice#

Run a scoped implementation:

/speckit.implement
Implement the repository and service tasks only. Do not change public response DTOs yet. Run the relevant tests.

Push the branch and open a draft GitLab merge request.

Step 9: Use CI as a Gate#

Let GitLab CI run. If it fails, ask the agent to inspect the failed job and fix the cause without weakening tests.

For reusable pipeline logic, GitLab CI/CD components can help. GitLab documents CI/CD components as reusable pipeline configuration units that can be versioned, listed in the CI/CD Catalog, and included with input parameters. If your organization standardizes agent checks, security scanning, or Spec Kit validation, components are a good way to avoid copy-pasting pipeline YAML across repositories.

Step 10: Review with Humans and AI#

Use AI review as an additional pass. Then ask human reviewers to focus on whether the implementation matches the spec, whether the plan still makes sense, whether tests prove the acceptance criteria, and whether any production risk remains.

The MR description should link back to the issue and reference the spec artifacts. That gives reviewers the full chain: intent, design, implementation, verification.

Step 11: Converge#

After implementation, run:

/speckit.converge

This compares the implementation back to the spec, plan, and tasks. If gaps are found, Spec Kit can append follow-up tasks. Implement and converge again until the result is clean.

This step is useful because it fights a very common failure mode: the implementation slowly drifts away from the original intent while everyone is busy reacting to local details.

Governance: How Much Autonomy Should Agents Have?#

Not every step deserves the same permission level.

For most teams, a sensible autonomy model looks like this:

The more irreversible the action, the stronger the gate.

Agents should be able to read widely, write locally, and propose confidently. They should not silently change policy, remove tests, bypass scanners, alter permissions, or deploy to production without a clear approval model.

The Role of AGENTS.md#

Repository-level agent instructions are becoming part of serious engineering practice.

In a GitLab project, an AGENTS.md file can describe how agents should behave in the repository:

# Agent Instructions

## Architecture
- Controllers must stay thin.
- Business logic belongs in services.
- Repository classes must not return API DTOs.

## Testing
- Add tests for every behavior change.
- Do not remove or weaken tests to make CI pass.
- Use integration tests for database query behavior.

## Security
- Preserve existing authorization checks.
- Never log personal data, tokens, or secrets.
- Use existing validation and error response conventions.

## Merge Requests
- Keep changes focused.
- Update documentation when public API behavior changes.
- Include a short risk and rollback note in the MR description.

This file is not a substitute for review. It is a way to make the default agent behavior closer to your team's engineering standards.

GitLab's Developer Flow documentation specifically recommends configuring AGENTS.md and agent-config.yml to improve flow quality and reliability. That recommendation matches the broader pattern: agents perform better when the repository tells them how to work.

A Practical GitLab Pipeline Shape#

You can support this workflow with a conventional GitLab pipeline:

stages:
  - validate
  - test
  - security
  - package

format:
  stage: validate
  script:
    - ./mvnw spotless:check

unit_tests:
  stage: test
  script:
    - ./mvnw test

integration_tests:
  stage: test
  script:
    - ./mvnw verify -Pintegration

sast:
  stage: security
  script:
    - echo "Use GitLab SAST or your approved scanner here"

build:
  stage: package
  script:
    - ./mvnw package

In a real GitLab project, you would normally use GitLab's built-in security templates or approved internal CI/CD components rather than hand-rolling every scanner. The important point is that agent-authored changes must pass the same gates as human-authored changes.

For Spec Kit specifically, teams can add lightweight validation jobs that check whether expected artifacts exist for larger features:

spec_artifacts:
  stage: validate
  rules:
    - if: '$CI_MERGE_REQUEST_ID'
  script:
    - test -f spec.md || echo "Spec may live in .specify; adjust this check for your repository layout"
    - echo "Validate spec, plan, tasks, and checklist conventions here"

The exact paths depend on how you initialize and organize Spec Kit. Do not blindly copy this job. Treat it as a pattern: make the development process visible in CI.

What Can Go Wrong#

Spec-driven agentic development is powerful, but it can fail in predictable ways. The failures are not exotic. They are the same delivery failures teams already know, just happening with cleaner prose and faster diffs.

The Spec Becomes Bureaucracy#

If every one-line change requires a full specification ceremony, people will route around the process. Use the shorter Spec Kit path for small work and the full path for production features with ambiguity, risk, or cross-team impact. A lightweight process that people actually use is better than a perfect process that only appears in architecture presentations.

The Agent Produces Plausible Artifacts#

A well-formatted spec can still be wrong. Review the content, not the polish. This is especially relevant for product owners and managers: a document can sound confident while still missing the business rule that makes the feature useful.

The Plan Freezes Too Early#

Planning is useful, but software still teaches you things during implementation. When reality contradicts the plan, update the plan. Do not pretend the artifact was correct because it came first. The plan is a design tool, not a contract with the past.

The MR Gets Too Large#

Agents can produce large diffs quickly. That does not make large diffs reviewable. Keep merge requests small, especially when AI wrote much of the code. Reviewers still need to understand the change, challenge it, and carry responsibility for accepting it.

CI Is Treated as an Obstacle#

An agent asked to "make CI green" may choose the shortest path. Be explicit: fix the root cause, preserve test value, and do not weaken quality gates. I would put that instruction in the repository guidance, the MR comments, and any agent prompt that touches pipeline failures.

Security Findings Are Overtrusted#

AI security review can find useful issues. It can also miss real vulnerabilities and produce false positives. Use it as a multiplier, not as a sign-off authority. The better pattern is to let agents reduce the manual triage burden while humans keep control over risk decisions.

The Engineering Mindset Shift#

The biggest change is not tooling. It is where you place engineering attention.

Before AI agents, a lot of effort went into typing code. With agents, more effort moves into defining intent, removing ambiguity, constraining implementation choices, slicing work, designing verification, reviewing generated changes, and maintaining operational safety.

That is not less engineering. It is engineering at a higher leverage point.

Spec Kit helps because it gives that work a shape. GitLab helps because it gives the work a delivery system: issues, branches, merge requests, CI/CD, security scanning, reviews, approvals, and audit history.

Together, they create a practical model:

1. Use GitLab issues to capture product and engineering intent.
2. Use Spec Kit to turn intent into reviewed artifacts.
3. Use AI agents to research, plan, implement, and iterate inside those artifacts.
4. Use GitLab CI/CD to verify every change.
5. Use AI and human review together.
6. Use GitLab's audit trail to keep decisions visible.

That is the version of AI-assisted development that scales: not a developer throwing prompts at a codebase, but a team creating a system where agents can contribute without dissolving accountability.

Conclusion#

AI agents are most useful when they are treated as capable collaborators inside a disciplined delivery process. They can research faster, draft more completely, implement repetitive changes, fix pipeline failures, and prepare security remediations. But they need context, boundaries, and verification.

Spec Kit provides the context and boundaries through specification-driven development. GitLab provides the delivery and verification path through issues, merge requests, CI/CD, security features, and agentic workflows.

The result is not fully automated software engineering. That is the wrong target.

The target is better engineering throughput with clearer intent, smaller feedback loops, stronger review artifacts, and less accidental drift between what the team meant to build and what actually shipped.

That is where AI agents become genuinely useful: not replacing the software development chain, but strengthening each link in it.

Verified Sources#

This article was written and checked against the following official documentation on September 2, 2026:

• GitHub Spec Kit documentation
• Spec Kit Quick Start Guide
• Spec Kit Agentic SDD reference
• GitLab Duo Agent Platform documentation
• GitLab Duo Agents documentation
• GitLab Duo Developer Flow documentation
• GitLab CI/CD pipelines documentation
• GitLab CI/CD components documentation
• GitLab Duo Code Review documentation
• GitLab Agentic SAST Vulnerability Resolution documentation
• GitLab Security Review Flow documentation