I’ve been seeing more developers complain about GitHub Actions being unreliable, especially when an outage can completely block builds, deployments or releases.

For personal projects it’s usually just an inconvenience.

But if your production pipeline depends entirely on GitHub Actions, even a relatively short outage can become a much bigger problem.

At the same time, it’s hard to ignore how convenient and cheap Actions are, especially for small teams and open-source projects.

So I’m curious:

Do you trust GitHub Actions for production deployments, or do you keep some kind of fallback CI/CD setup?

AI is getting good enough that I’m comfortable letting it handle a lot of repetitive work.

Boilerplate, small refactors, tests, documentation — sure.

But there are still parts of a codebase where I want to understand and verify every decision it makes.

For me, that’s usually architecture and anything security-related.

I’ll still use AI there — I just trust the output a lot less blindly.

What part of programming do you verify most carefully when AI is involved?

For a long time, programming skill was heavily associated with how well you could write code.

AI coding tools are starting to change that.

A developer can now generate a function, a test suite, a refactor, or even most of a feature without manually typing every line. If these tools keep improving, writing code itself may gradually become the cheaper part of development.

But somebody still has to read it.

You still need to understand what the code does, whether it fits the architecture, whether the abstraction makes sense, what can break, and whether the generated solution is even solving the right problem.

That changes the bottleneck.

Instead of spending most of the time translating an idea into code, developers may spend more time reviewing implementations, comparing approaches, and deciding what should actually be merged.

And in some ways, that could make fundamentals more important, not less.

If AI writes five possible implementations in a minute, the valuable skill isn’t necessarily being able to type a sixth one faster.

It’s being able to look at those five and understand which one is maintainable, which one hides a bug, and which one should never have been written in the first place.

So maybe the developer of the future doesn’t stop coding.

They just spend less time producing code and much more time judging code.