Never ship AI code you do not understand

The fastest way to ship a vulnerability or a 2 a.m. page is to commit AI output you cannot explain. Generated pipeline config and infrastructure code look authoritative and often run on the first try — which is exactly why the unreviewed ones are dangerous.

There is a documented reason to be careful. Security researchers scanning public repositories found that pipeline files created with AI assistants had measurably higher rates of misconfiguration than hand-written ones, because models reproduce the most common patterns in their training data, and the common pattern is usually the insecure one: hardcoded tokens, unpinned action versions, and overly broad permissions.

So treat every generated change as a proposal, not a commit. Before it merges:

• Read every line and be able to say what it does and why.
• Ask the model to explain its own output, then verify the explanation against the real docs.
• Check the risky defaults: permissions, token scope, pinned versions, and what runs on untrusted input.
• Prefer small diffs you can fully review over a large block you skim.

A good habit is to ask for the change and the reasoning together:

Generate the workflow, then list every permission it needs and why, and flag anything that runs on a pull request from a fork.

If you cannot explain a line to a teammate, it is not ready to merge. Understanding is the review; speed without it just moves the bug downstream.