Complex Requirements Are Not the Biggest Problem Anymore: Why Workflow Quality Matters More in the AI Era

How we used AI to make CI stricter, more observable, and easier to improve across repositories.

Having worked across both implementation and delivery, I’ve learned that complex requirements are not necessarily the biggest problem in the current AI era.

AI can help us break down requirements, explore unfamiliar repositories, and generate implementation ideas. That makes the implementation step much easier.

But implementation is only one part of delivery. The feature still has to move through a real engineering system.

It has to fit the repositories, CI rules, review process, and deployment path that deliver it.

As implementation gets faster, the surrounding engineering system becomes more important. The real challenge is making sure every change is tested, reviewed against the requirements, and safe to merge.

Beyond the Fear of Replacement

There is a lot of fear around AI replacing developers.

Some of that concern is reasonable. Entry-level opportunities may become more limited when routine implementation tasks can be generated, tested, and reviewed with AI assistance.

That is an important challenge, especially for people who are trying to get their first opportunity in software development.

But I do not see this as the end of the developer role.

I see it as one of the most exciting periods to work in software.

The value is shifting.

Writing routine code is becoming less differentiating. Understanding a problem, asking the right questions, validating behavior, making trade-offs, and taking responsibility for the result are becoming more important.

AI can produce an implementation, but it does not automatically understand the business context, the hidden constraint, the operational risk, or whether the solution is appropriate for the team.

That is why workflow quality matters.

The developers who benefit most are not necessarily the ones who ask AI to generate the most code. They are the ones who can use AI inside a disciplined process: define the requirement, inspect the evidence, test the result, review the risk, and improve the system around it.

For junior developers, the path may change, but it does not disappear. Fundamentals, debugging, communication, product understanding, and the ability to work effectively with AI will matter even more.

That shift in perspective changed how we approached our CI. We did not start by asking how to make it run faster. We asked how to make it catch more of the right problems.

The Real Work Was Strengthening the CI Workflow

Recently, we worked on a GitLab CI workflow with several responsibilities:

• Move linked issues to Status::In Review when a merge request is created.
• Move issues to Status::Done after the merge.
• Run an AI review for the entire merge request.
• Block the pipeline when the AI review confirms a critical or high-severity finding.
• Leave a comment when the merge request does not contain a closing reference.

The important part was not simply adding more CI jobs.

We used AI to inspect the workflow itself and ask better questions:

• Does Status::In Review prove that the merge request is actually connected to a ticket?
• Does Status::Done run only after a real merge to the default branch?
• Can an AI finding block a merge without concrete evidence?
• What happens when a merge request is missing a closing reference?
• Which checks are generic policy, and which checks belong to one repository?

These questions changed the CI from a collection of commands into a quality control system.

The goal was not to make CI more complicated. It was to make each decision more explicit: what is checked automatically, what evidence is required, and what should block the merge.

How AI Is Actually Used in the Pipeline

The AI review is not a separate tool that developers have to run manually. It is a GitLab CI job that runs when a merge request targets the default branch.

The setup has four simple parts:

1. A pinned AI CLI is installed in the CI job.
2. A small repository script collects the merge request context.
3. The AI returns a structured JSON report.
4. A separate job evaluates that report and decides whether the pipeline passes.

The job uses a pinned version of the AI CLI instead of installing whatever happens to be latest:

ai_review:
  image: node:22-bookworm-slim
  before_script:
    - npm install --global @openai/codex@<pinned-version>
  script:
    - python scripts/ai_review.py review

In this case, the AI is accessed through the OpenAI Codex CLI. The exact CLI can vary, but the important parts are that the version is explicit and the job runs in an isolated CI environment.

The repository script does not send the entire repository blindly to the model. It collects only the context needed for the review:

• the merge request description;
• linked closing issues and their requirements;
• the changed files and diff;
• relevant file content around the changes;
• the current commit SHA and target branch.

The prompt also defines what the AI is allowed to conclude. For example, a requirement is marked as Covered, Partial, Missing, or Not verifiable. A finding must include its category, severity, affected path, evidence, impact, and recommendation.

The response is validated against a JSON schema before it is used. The report is then saved as a CI artifact and posted as a merge request comment. This makes the reasoning visible and gives the next job a stable input.

The credentials are separated by responsibility:

• an AI access token allows the review job to call the AI tool;
• a GitLab automation token allows the workflow to read merge request data and update comments or labels.

Both are managed as masked group-level CI variables. The review job uses the AI token. The gate job does not need to call the AI, so it consumes the report artifact and removes the AI token from its environment.

This separation is useful for two reasons. It limits where sensitive credentials are exposed, and it prevents the final gate from making another AI request whose result could differ from the report that was reviewed.

In practice, the flow looks like this:

Merge request
    -> collect GitLab context
    -> AI review with structured output
    -> report.json artifact and comment
    -> deterministic gate
    -> pass or block the pipeline

AI is therefore used for analysis and explanation. GitLab CI remains responsible for validating the output, checking the commit, updating the merge request, and enforcing the final policy.

Package the Improved Workflow, Not the Repository

The shared component was a useful result, but it was not the main improvement. The main improvement was making the CI policy explicit and enforceable. Once that was clear, we could package the reusable parts.

After improving the workflow, the next question was simple:

Do we really need to set up the same workflow manually in every repository?

The answer was still no.

Instead of copying the improved .gitlab-ci.yml logic into every repository, we created a shared GitLab CI component.

The consumer repository only needs to include the shared template:

include:
  - project: your-group/ci-components
    ref: v0.1.0
    file: /templates/issue-ai-review.yml

The shared component provides:

• issue_status_in_review
• issue_status_done
• ai_review
• ai_review_gate

The repository still owns its own build, lint, unit test, E2E, and deployment jobs.

This separation is important.

A Go repository should not be forced to use a Python repository structure. A frontend repository should not inherit a backend test command.

But both repositories may still need the same merge request policy.

The reusable part is the quality policy, not every command in the pipeline.

AI Review Needs a Deterministic Boundary

AI review is useful, but an AI response should not directly decide whether a merge request can be merged.

The AI reviewer produces a structured report. It evaluates ticket coverage, correctness, regression risk, security, performance, maintainability, and other categories.

Critical and High findings are then independently verified.

The final gate checks deterministic conditions:

• Is the report for the current commit?
• Was the finding independently confirmed?
• Is the severity still blocking?
• Was a human override added after the report was generated?

This gives us a better boundary.

AI is useful for reasoning over a large merge request.

The pipeline is responsible for enforcing the policy.

That distinction matters because AI output is probabilistic, while a merge gate should be predictable.

Making the Workflow Safe to Reuse

The quality of the workflow does not come from the AI step alone. We also need to make the automation predictable and safe to reuse.

Missing closing references become visible

If a merge request does not contain a reference such as Closes #123, the pipeline automatically leaves a comment explaining what is missing.

The job also fails, so the problem is visible before the merge. After the description is updated, the pipeline can be retried.

Pin the shared component

Each repository uses a specific component version, such as v0.1.0, instead of silently following the latest changes.

This means an update to the shared CI does not unexpectedly change every repository. A repository can update the version when the change has been reviewed.

Use a dedicated bot for automation

The workflow needs credentials to update issue labels and comments. Those credentials are stored at the group level and belong to a dedicated CI bot instead of a developer's personal account.

This keeps ownership with the team and makes the automation easier to maintain when people or responsibilities change.

Keep repository-specific checks local

The shared component handles the common merge request policy. Each repository still defines its own build, lint, unit test, E2E, and deployment jobs.

Labels can also be configured per repository. A Go project and a TypeScript project do not need to use the same commands just because they share the same review policy.

The result is a common quality bar without pretending that every repository has the same structure.

What Changes in Engineering Leadership?

AI changes the bottleneck.

Before, a large part of the work was translating requirements into code and manually checking whether the CI workflow captured the intended policy.

Now, AI can reduce much of that implementation friction.

The engineering leadership role becomes more focused on:

• defining reusable boundaries;
• deciding which checks must remain deterministic;
• turning repeated policy into automation;
• making AI output verifiable;
• preserving flexibility between repositories; and
• ensuring that speed does not remove evidence from the process.

The work is still complex.

But the complexity can be organized into smaller, reusable systems.

Final Takeaways

Complex requirements still need careful thinking.

AI does not remove the need for architecture, testing, or review.

But it changes what is practical.

A review process that depended on manual inspection can become an automated, evidence-based gate.

Once that quality policy is clear, the repeated CI logic can become a versioned shared component.

The biggest improvement is not just writing code faster.

It is creating a system where complex work becomes easier to coordinate, verify, and reuse.

That is where AI creates the most leverage for engineering teams.