GitLab

A living handbook is used as the single source of truth for processes and decisions.

How it works

Decisions, processes and role definitions live in handbook pages and changes are discussed through merge-request-like workflows.

Why it is used

Creates time-zone-independent access and organizational memory.

Trade-off

Unwritten knowledge becomes invisible; without clear ownership the handbook decays quickly.

Best fit

Distributed, scaling teams that repeatedly transfer decision context.

Written communication and durable records precede synchronous discussion.

How it works

Written, open channels come first; synchronous discussion is reserved for ambiguity or relationship needs.

Why it is used

Protects equal access to information and focused work blocks.

Trade-off

Risks slow feedback and weaker social connection; escalation channels must be designed separately.

Best fit

Teams spanning time zones with strong documentation discipline.

Results and customer impact are evaluated instead of hours worked.

How it works

Performance is read through role outcomes and customer impact rather than hours worked.

Why it is used

Reduces visibility bias in remote work.

Trade-off

Poor outcome metrics can undervalue invisible work and team contribution.

Best fit

Roles with explicit outcomes and accountability.

Team members are expected to own outcomes without daily supervision.

How it works

Individuals own priorities and daily progress without waiting for constant managerial instruction.

Why it is used

Reduces decision latency and micromanagement in distributed teams.

Trade-off

Without context autonomy becomes drift; the bar for capability and onboarding rises.

Best fit

Teams with high autonomy, explicit goals and strong written context.

GitLab’s AI-Assisted Development Playbook, added on 27 March 2026, splits agent use into five levels: Baseline, Pair, Conductor, Orchestrator and Harness. A repo should not move past Baseline until it reaches maturity level 2 on all four dimensions: CI and constraints, context and docs, testing depth, and review practice.

How it works

Rules live in CI: if an agent can break a rule and still pass the pipeline, the rule does not exist. Bad output is fixed in the environment (a lint rule, a test, a doc), not the prompt; a guard that fails unlabelled MRs when the test count drops, three-layer AGENTS.md context and weekly automated clean-up are recommended.

Why it is used

Prompts are lost between sessions while CI checks persist; tying autonomy to infrastructure maturity limits unreliable output and compounding technical debt.

Trade-off

The playbook is guidance for R&D teams, not mandatory policy; internal examples are team-level and how level changes are audited is not defined.

Best fit

Engineering organizations scaling coding agents that can prioritize CI, testing and review infrastructure accordingly.