Glossary.
Short, straight explanations of the terms we use every day — platform engineering, DevOps, developer experience and modern software delivery.
AGENTS.md
AGENTS.md is a short file in the root of a repository written for coding agents rather than people: how the project is built, tested and run, which conventions apply and what must not be touched — what the agent needs to know before it changes anything.
Blameless post-mortem
A blameless post-mortem is a structured review after an incident that focuses on systems, processes and decisions — not on finding a scapegoat — so the organisation actually learns from what happened.
CI/CD
CI/CD stands for continuous integration and continuous delivery/deployment: automated flows where code is built, tested and delivered to production in small, frequent steps instead of big, risky releases.
Coding agent
A coding agent is an AI tool that does more than suggest code: it carries out tasks in a repository on its own — reading files, running commands and tests, changing code and opening pull requests — steered by an instruction and the rules found in the codebase.
Developer experience (DX)
Developer experience (DX) is the sum of how it feels and how long it takes for developers to do their job: starting a service, finding documentation, getting feedback from tests and deploying to production.
Developer portal (Backstage)
A developer portal is the internal website where an organisation's services, teams, ownership, documentation and self-service templates are gathered in one place. Backstage, open-sourced by Spotify in 2020, is the most common framework to build one on.
DORA metrics
The DORA metrics are four key measures of software delivery: deployment frequency, lead time for changes, change failure rate and time to restore. They come from the DORA research programme — DevOps Research and Assessment.
Error budget
An error budget is the amount of failure or downtime a system may have over a period without breaking its reliability target, the SLO (service level objective). While budget remains the team can take risk and ship fast; once spent, stability comes first.
Feature flags
Feature flags (feature toggles) are switches in the code that let functionality be turned on and off without a new deploy — decoupling deployment from release and giving control over timing, audiences and risk.
GitOps
GitOps is a way of working where Git is the source of truth for both infrastructure and application configuration: desired state is described in code, reviewed in pull requests and rolled out automatically by tools that keep reality in sync.
Golden path
A golden path is a ready-made, recommended, self-service route through a common developer workflow — for example from new repo to service in production — with standards, security and automation built in.
Infrastructure as Code (IaC)
Infrastructure as Code means environments, networks, permissions and resources are defined in version-controlled code instead of being clicked together manually — making infrastructure traceable, testable and repeatable.
Inner source
Inner source means taking ways of working from open source and applying them inside the organisation: open repos, open contributions, clear ownership and shared standards between teams.
Internal developer platform (IDP)
An internal developer platform (IDP) is the combined set of tools, services and self-service flows an organisation builds for its own developers — from creating a new repo to deploying, monitoring and operating services.
Lead time
Lead time is the time from a change being finished in code to it running in production — one of the four DORA metrics. It measures how much waiting, manual handling and queueing sits between the developer and the customer, not how fast anyone codes.
Model Context Protocol (MCP)
The Model Context Protocol (MCP) is an open standard that lets AI assistants and agents connect to tools, databases, documents and internal systems in a structured way — so the AI can act in your real environment, not just answer in general terms.
Observability
Observability is the ability to understand what's happening inside a system from what can be observed — metrics, logs, traces and events — so you can answer questions nobody anticipated when the system was built.
Platform as a product
Platform as a product means an internal platform is run like a product with developers as its customers: someone owns it, adoption is voluntary and measured, there is a roadmap and support — not an IT project that gets ”finished” and is mandated for everyone.
Platform engineering
Platform engineering is the discipline of building internal platforms, tooling and workflows that make it easy for development teams to deliver software safely, quickly and consistently.
Platform team
A platform team builds and runs the internal platform other teams deliver on, so they don't each solve infrastructure, CI/CD and operations alone. In Team Topologies it is one of four team types, alongside stream-aligned, enabling and complicated-subsystem teams.
Progressive delivery
Progressive delivery means changes are rolled out gradually — for example via canary releases or percentage-based rollouts — measured in production and scaled up only when the signals are right.
Site Reliability Engineering (SRE)
SRE is a way of making operations systematic and measurable: reliability is expressed as objectives (SLOs) and error budgets, and the team actively works with alerting, automation and improvement instead of reactive firefighting.
Trunk-based development
Trunk-based development is a way of working where all developers integrate small changes into a shared main branch (trunk) several times a day, instead of working for long periods in separate feature branches.
Got a problem worth solving?
Chat with us on WhatsApp. We reply within 48 hours.