Non-Linear Productivity

Intro

This page documents the initiatives engineering is pursuing to increase productivity using AI.

Why “Non-Linear” Productivity

Generating code is becoming trivial. The difficult part is getting that code into customers’ hands in a production-ready manner: A/B tests, rollout plans, rollback plans, and everything else that surrounds a change once it exists. Those steps, not authoring, are where the bottleneck now sits, and today at GitLab that includes the time it takes to review code.

A related premise is that syntax will matter less over time. Agents may write code that looks unoptimized from a maintainability, readability, or modularity perspective, but agents are also the ones reading, maintaining, and changing it. Some of our reviews today still spend their effort on exactly those characteristics.

This project is the engineering-practice counterpart to the argument Bill Staples makes in When code is abundant: code production is becoming abundant while good software is not, so the constraint moves from producing code to trusting it. That post also names the economic unit this project optimizes for - cost per accepted change, which includes generation, environment setup, context, verification, review, remediation, and governance. Collapsing only the generation term moves the queue rather than shortening it.

If productivity is going to scale non-linearly, the constraint has to move away from human throughput at each step of the delivery path.

Long-Term Initiatives

Shift review left

It is already the author’s and their agents’ responsibility to produce code that would be acceptable to others, humans and agents alike. This initiative will help to make that process easier for authors by building tooling to help generate higher quality code from the onset. When the first iteration of a merge request is already good, reviewers spend less time going back and forth, and authors spend less calendar time getting their change in.

The foundation for this is /review in GitLab Duo, which allows a change to be reviewed and fixed locally before a merge request is even created. Early iterations will not be perfect; the intent is to improve them continuously.

Reduce the pipeline bottleneck

Once better code can be generated more quickly, it also needs to reach production quickly. The goal is to use agents at every step of the pipeline to automate work and remediate failures, for example:

1. Flaky merge pipelines, which can be handled automatically.
2. Merge requests sitting idle and waiting on something, where an agent can take action: reviewing, fixing, or finding another approver when the first one is unavailable.

This is the same shift described in When code is abundant: the pipeline stops being a gate at the end of development and becomes the system that runs the development loop itself - generate, build, test, validate, review, remediate, repeat - close to the code, the context, and the controls.

Architectural modularization

For there to be no human in the loop, the architecture has to make it safe to roll out a change in minutes to a defined corpus of customers without affecting any other customer. This is not only feature flags and not only cellularization, but broader than both. It requires tooling investments as well as architectural change, and it will not happen overnight.

Removing the human from the loop is a governance problem as much as an architectural one. When code is abundant frames this as autonomy being governed rather than granted: the agent can be creative, and the system decides where creativity stops. Deterministic gates, isolation, verification, policy, and evidence are what let autonomy expand safely.

Expected Trade-Offs

In the near short term, this direction may mean spending more time reviewing code rather than less. That is accepted as short-term pain while the agents, models, and foundations improve toward operating without human intervention.

Further Reading

• When code is abundant - Bill Staples on why the constraint moves from producing code to trusting it, the three modes of agentic development, and the durable layer of context, verification, and governance an enterprise needs around agents.

Measurement

The metrics we are measuring are:

1. The time from when an MR is marked Ready till it is Merged
2. The time from when an MR is marked Ready till it is Assigned
3. The time from when an MR is Assigned till it is Reviewed
4. The number of iterations of an MR
5. The size of the MR

Out of these, the most important is (1) - The time from Ready to Merged.

These metrics are faceted by:

1. The type of change (docs vs code vs config)
2. The Engineering Organization of the team member that submitted the MR

Exclusions from being measured:

1. Any community contributions
2. Any MRs in Draft state
3. Any time an MR spends in Draft state prior to being marked Ready

View page source - Edit this page - please contribute.