Not really. No one’s itching to go back to clicking around in Jenkins or Bitrise UIs for every pipeline change.

The principle behind CI/CD as code is still solid. The real issue is how fragile and fragmented it becomes without structure, tooling, and conventions.

What we need isn’t less automation, it’s smarter automation.

Time to Treat CI/CD Like Code, Just Not Hand-Written Code

If you’re spending hours debugging YAML or hunting through multiple .yml files across repos, you’re not alone. The irony is: developers automate everything except the automation itself.

What if new pipelines didn’t start from scratch? What if your Android app’s structure- its modules, dependencies, testing setup, could define the pipeline logic for you?

Subtle Upgrade: Tools That Build Pipelines for You

There’s a quiet movement happening: tools that generate your CI/CD pipelines based on your codebase, rather than making you write everything manually.

Instead of hand-coding every build job, you define your intent, test these modules, build these variants, and deploy here, and the tool handles the structure, syntax, and even caching logic for you.

Some teams are using tools like NativeBridge to do exactly that. It doesn’t replace your CI, it sits above it, translating project details into reproducible, optimized CI configs.

You can still customize as much as you want, but you're no longer starting from an empty YAML file and a prayer.

Final Thoughts

CI/CD as code sounded like a dream, and for many, it still is. But as projects scale and complexity grows, treating your CI system as “just another script” doesn't cut it.

The goal isn’t just CI/CD as code. It’s CI/CD as maintainable, testable, and sharable code, and that means adding guardrails, automation, and tooling to help you focus on shipping features, not debugging pipelines.

If your team is spending more time writing .yml than writing code, maybe it’s time to rethink how your automation gets built.

Sometimes, the best code is the one you didn’t have to write.