That’s my policy too. I see way too many Jenkins/Actions scripts with big logic blocks jammed into YAML. If the entire build and test process is just a single script call, we can run it locally, in a GitHub workflow, or anywhere else. Makes it less painful to switch CI systems, and devs can debug easily without pushing blind commits. It’s surprising how many teams don’t realize local testing alone saves huge amounts of time.
I’ve seen many teams get stuck when they rely too heavily on GitHub Actions’ magic. The key issue is how tightly your build logic and config become tied to one CI tool. If the declarative YAML gets too big and tries to handle complex branching or monorepos, it devolves into a maintenance headache—especially when you can’t test it locally and must push blind changes just to see what happens.
A healthier workflow is to keep all the logic (build, test, deploy) in portable scripts and let the CI only orchestrate each script as a single step. It’s easier to troubleshoot, possible to run everything on a dev machine, and simpler if you ever migrate away from GitHub.
For monorepos, required checks are maddening. This should be a first-class feature where CI can dynamically mark which checks apply on a PR, then require only those. Otherwise, you do hacky “no-op” jobs or you force your entire pipeline to run every time.
In short, GitHub Actions can be powerful for smaller codebases or straightforward pipelines, but if your repo is big and you want advanced control, it starts to feel like you’re fighting the tool. If there’s no sign that GitHub wants to address these issues, it’s totally reasonable to look elsewhere or build your own thin orchestration on top of more flexible CI runners.
Over the next five years, intelligent code assistants like GitHub Copilot will significantly transform software development by automating repetitive tasks and enhancing developer productivity. These tools, built on advancements in AI and large language models (LLMs), will help developers focus more on problem-solving and less on manual coding. While LLMs won’t replace developers, they will streamline workflows, making programming more accessible globally, especially with innovations in personalized models and natural language interfaces. The future of coding may evolve into a collaborative process between humans and AI, reshaping the development landscape.
I think this is a very useful framework to write about on Wikipedia on how not to use HTML in your python code. There's a canonical reason on why we shouldn't.
I'm not sure I understand your perspective, we've been using HTML + template library for a while with great success as an industry, across multiple languages.
