Avoiding CI/CD Anti-Patterns in Platform Engineering

There’s an old engineering joke that the two hardest programming problems are cache invalidation, naming, and off-by-one errors. While the third point is what gets the laughs, the challenge of naming deserves a deeper look. Naming challenges aren't just a quirk; they're a symptom of deeper complexity in defining boundaries within socio-technical domains. 

In platform engineering, naming is how we encode those boundaries, especially between platform and application teams. And nowhere is that tension more visible or more consequential than in managing software delivery, continuous integration, and continuous delivery (CI/CD) pipelines.

When we talk about internal developer platforms (IDPs), we’re often talking about abstracting complexity away from application teams, as explored in our post on platform democracy. But how far should that abstraction go? If you stop too early, application teams are left wiring environments and juggling Terraform modules. Go too far, and they’re trapped in rigid golden pipelines that can’t adapt. In both cases, delivery slows, support tickets pile up, and teams lose faith in the platform.

Poorly defined CI/CD abstractions can stall delivery and erode platform trust. This post examines how platform teams can avoid common pitfalls and design flexible, composable abstractions that empower developers while ensuring consistency and compliance.

The Role of Abstraction in CI/CD

Abstraction isn’t a one-time decision. It’s a spectrum of choices made at every layer, from infrastructure and environments to pipelines and deployments. Good abstractions create a contract where producers deliver reliable, flexible services, while consumers build and deliver value without needing to understand the underlying machinery.

This contract is especially sensitive when managing application CI/CD. Applications depend on pipelines that are fast, secure, and tailored to their needs. Organisations want to enforce compliance, manage costs, and reduce operational toil. The collaboration between consumer application teams and producer platform teams in managing both sets of goals is paramount in designing the right abstractions to support the necessary delivery velocity.

Two Common Anti-Patterns when solving the Platform–Application Boundary Problem

At the heart of CI/CD friction is a simple question: where should platform responsibility end, and application team responsibility begin?

This isn’t just a technical decision. It’s a sociotechnical boundary, shaped by team capabilities, organisational complexity, compliance needs, and product diversity. Drawing it well is what Team Topologies describes as “enabling fast flow with well-defined boundaries.”

The tension arises when platform teams either stop short and leave teams with too much undifferentiated heavy lifting or go too far and box developers into wrongly shaped golden cages.

1. Infra Hand-off That Goes Too Low

This pattern is common in early-stage platforms. The platform team identifies and understands its own pain points, including excessive requests for help or resources, excessive toil during infrastructure provisioning, and challenges when approaching upgrade requirements for functional or security reasons. In order to overcome these challenges, the team aims to reduce their ownership surface area by exposing raw infrastructure at the level of cloud accounts or Kubernetes clusters/namespaces, and they may also provide infrastructure as code (IaC) templates to enable teams to build more specific resources more quickly.

This approach is effective and reduces requests to the team for resources and responsibility in managing upgrades. For a while. But as the patterns roll out past early adopters, many teams need help using these primitives and even those teams that are self-sufficient start being challenged by the hours spent wiring up their own environments, managing their own secrets, and reinventing the same patterns as other teams rather than focusing on unique business outcomes. Cognitive load grows. Drift sets in. Support tickets return. Compliance suffers.

2. Golden Pipelines That Go Too Far

On the flip side, some platforms swing toward heavy standardisation and centralisation. To reduce confusion and support stringent business security requirements, they ship a golden pipeline that defines a single path from build to deploy. For basic apps, this feels magical. But once again, as adoption extends beyond early adopters, real-world application variance becomes more challenging to manage. All of a sudden, features like manual gates are required for some applications. And others need to run soak tests before deployment. And still others need to integrate ML training mid-pipeline.

Suddenly, the golden pipeline (path) becomes a brittle bottleneck. Platform teams struggle to respond quickly enough to feature requests that unblock development teams, which leads to developers working around the provided solution. Or when they do manage to introduce more features, they introduce confusion and regressions for their original target audience, which makes more teams opt out altogether.

Building Platforms Involves Defining High-stakes Abstractions

The boundary between platform and application teams in CI/CD is a high-stakes abstraction. Failing to get this abstraction right can result in two issues. First, passing on too much cognitive load to application developers by offering infrastructure-supported platforms and second, designing golden cages by providing full application orchestration from the platform, ultimately leading to velocity stalls. 

However, if you get the abstraction correct, both application and platform teams can move faster, safer, and more independently.

Check out our previous blog, “The 4 CI/CD Abstraction Models: How They Work and When to Use Them”, for two more balanced approaches which provide a more effective CI/CD abstraction. 

In the end, abstractions are an ever-present way to de-risk falling into these traps. To achieve this, focus on building platform services that can compose or decompose into the right level of abstraction for the organisation, even as it evolves, thereby providing the foundations for long-term success. 

And of course, you can learn how Syntasso Kratix Enterprise (SKE) enables composable platform design.