The Problem with YAML
Think about how most software teams run their CI/CD pipelines today. A developer makes a change, pushes it to GitHub, and then waits — sometimes for 10 minutes — to find out if the pipeline passed. If it fails, they tweak the YAML config, push again, and wait again. This cycle can repeat a dozen times for a single change. Engineers have a name for this: the "Push and Pray" loop.
The root cause is that CI/CD configuration files — GitHub Actions workflows, GitLab CI pipelines, CircleCI configs — are written in YAML, a data serialization format designed for configuration, not logic. YAML is excellent at describing static structure. It is terrible at expressing dynamic behavior.
Here is what that looks like in practice:
- No abstraction: YAML has no concept of functions, loops, or variables (beyond basic anchors). If you need to build five microservices the same way, you copy-paste the same 30-line block five times. When you need to change one thing, you change it five times — and inevitably miss one.
- Vendor lock-in: A GitHub Actions workflow file is meaningless on GitLab. A Jenkinsfile cannot run on CircleCI. Your pipeline logic is permanently coupled to your CI provider. Switching vendors means rewriting everything.
- No local execution: You cannot run a GitHub Actions workflow on your laptop. The only way to test a pipeline change is to commit it, push it, and wait for the cloud runner to execute it. This is the "Push and Pray" loop in its purest form.
The deeper problem is that YAML pipelines treat CI/CD as configuration when it is actually software. A build pipeline has logic, branching, error handling, and reusable components. It deserves to be written in a real programming language.
Enter Dagger
Dagger is a programmable CI/CD engine that lets you write your pipelines as code — in Go, Python, TypeScript, or other supported languages — instead of YAML configuration. It was created by Solomon Hykes, one of the original creators of Docker.
Dagger makes one central promise: if it runs on your laptop, it will run exactly the same way in CI. Not approximately the same. Not "mostly the same, except for that one environment variable." Exactly the same, because the execution environment is containerized and fully defined by your code.
Interviewers often ask: "How do you ensure your CI pipeline is reproducible?" A weak answer is "we pin dependency versions." A strong answer introduces the concept of containerized pipeline execution — where the pipeline itself runs inside a defined container, not on a bare host runner. Dagger is the canonical example of this approach. Mention that it eliminates the "works on my machine" problem at the pipeline layer, not just the application layer.