You ask an AI coding tool to add an automated build. It writes a small workflow, explains the steps, and points to a successful run.
A week later, the workflow file has exactly the same text. Does that mean it will run exactly the same outside code?
I would want a beginner to pause before answering yes.
A version label in a workflow can point somewhere different later. You might have reviewed the recipe while leaving one ingredient supplier free to change what arrives.
On October 14, GitHub introduced workflow dependency lockfiles in public preview. The announcement addresses this gap: tags and branches can move, while a lockfile records the commits an onboarded workflow should execute. GitHub lists Free, Team, and Enterprise Cloud plans, including Enterprise Cloud with data residency, as eligible for the preview.
My beginner takeaway is this: keep the friendly dependency label for understanding, but give execution a specific code identity you can review.
That is a useful question to ask your AI assistant before accepting its next deployment workflow. If you need a structured way to ask questions like that, my $3 AI App Builder Starter Prompts provide forty guided prompts for planning and checking a first build. You can do the exercise below without buying anything.
The version name and the actual code are different things
Imagine a hypothetical action called example-org/package-app@v3.
The left side identifies a repository. The v3 part is a tag. Your workflow asks for that reference, and the service resolves it to code.
A commit identifies a particular revision. A tag is a label attached to a revision, and the label can move. That difference matters even when you have no plans to become a release engineer.
Picture an AI-generated workflow that packages your app every time you merge a change. You inspect the workflow on Monday. On Wednesday, the upstream tag points to another revision. On Thursday, your unchanged workflow runs again.
Your own app diff does not tell the whole story of what changed between those runs.
This is an illustrative scenario, not a claim that a particular action has been compromised. It explains why “we did not edit the workflow” is incomplete evidence about the code it executes.
Your direct dependency can bring friends
The first outside action in a workflow may call other actions. Those indirect dependencies are part of the execution story too.
GitHub's lockfile documentation explains that the repository's generated .github/workflows/actions.lock records dependency references, commits, and source-repository identities. It covers transitive action dependencies, with an important boundary: dependencies inside a called reusable workflow are covered by that workflow's own repository lockfile.
I read that boundary as a practical ownership question. If my build calls another team's reusable release workflow, who maintains the dependencies inside it?
A beginner does not need to memorize the entire graph. You do need to know where your review stops and someone else's starts.
For a hypothetical booking app, I would write a short inventory in plain English:
- Our workflow checks out the app and runs its tests.
- An outside action packages the result.
- A reusable workflow handles deployment.
- We own the first workflow's dependency record.
- The reusable workflow's maintainers own its internal record, which we need to assess separately.
That small inventory makes “the build system” less mysterious. It also gives your AI assistant a concrete object to inspect instead of a vague instruction to make everything secure.
The first exercise I would give an AI assistant
Start with one existing test workflow in a practice repository. Keep production deployment out of the first exercise.
My prompt would be:
“Read this workflow and its referenced action definitions. List the outside executable dependencies, their readable references, and the exact revisions currently selected. Identify indirect actions and called reusable workflows. Mark anything you could not inspect. Explain the lockfile ownership boundary before proposing changes.”
The output should be a dependency map with evidence. If the assistant cannot inspect a source, an explicit unknown is more useful than a confident invented answer.
Then ask it to show one hypothetical update. Which resolved revisions would change? Does the change add another outside action? Does it alter the commands that run or the access they need?
Those questions put the review on executable behavior. A tidy YAML file alone cannot answer them.
Generate the record, then inspect what changed
GitHub supplies the gh-actions-lock CLI extension. Its repository documents installation through the GitHub CLI, generation with gh actions-lock, and a nonwriting check with gh actions-lock --verify. The tool is pre-1.0; its authors warn that behavior, flags, and the format can change during the preview. GitHub Enterprise Server is currently unsupported.
I would follow the current setup instructions in a branch, generate the files with the tool, and inspect the diff before committing. I would not ask AI to handwrite a plausible-looking lockfile. GitHub's documentation specifically says the file should be generated rather than edited manually.
For the exercise, a useful review note would say:
“Our test workflow now uses the generated dependency record. These are the outside revisions it selects. This reusable workflow has a separate ownership boundary. The test run completed against this app revision.”
Keep the last sentence factual. If the run failed, write that it failed and investigate. The lockfile's existence does not transform a failed build into a passing one.
Updating is a new review decision
A dependency record is useful because it makes a change deliberate. Eventually you will want newer dependency code, so you need an update path too.
The extension's README says normal generation preserves existing locked pins; --relock resolves legitimately moved references again. It also distinguishes online verification from the narrower offline --verify-local check.
That means I would not tell a beginner to regenerate everything blindly whenever CI complains. First understand whether you added a dependency, changed a reference, or encountered a failed identity or reachability check. A verification failure deserves an explanation before an update.
For an ordinary update, I would want the proposed diff to answer three questions:
- Which dependency revisions changed, including indirect ones?
- Why do we want the new behavior?
- What app-level build or test result supports accepting it?
This is different from choosing an update time. It is about making the selected code visible at the moment you accept a change.
What locking cannot promise
GitHub's announcement explicitly cautions that locking does not establish whether a dependency is safe. You can consistently execute code that was a bad choice in the first place.
A lockfile also is not a claim that the whole environment is frozen. Your app packages, runner environment, external services, and deployment settings need their own reasoning. Keep the scope of the evidence clear: you are recording workflow dependencies, not proving that every possible input to a release is identical.
The tradeoff is another generated artifact and another review responsibility. For a small practice app, start with one workflow so you can explain the result. If the preview does not fit your environment, review GitHub's established full-commit pinning guidance and its limits rather than pretending the new mechanism is universally available.
Your next build should be easier to explain
Open one AI-written workflow and point to an outside uses reference. Can you explain whether it is a moving label or a specific revision? Can you identify who owns the dependencies behind a reusable workflow?
If you cannot, that is a useful next task for your assistant.
For guided practice, the $3 Starter Prompts are the immediate next step and carry a $20 buyer benefit toward the planned Bootcamp Bundle. The $9 standalone AI App Builder From Zero e-book provides the organized path from idea through testing and publication, with a $30 benefit. The standalone book excludes the separate forty-prompt workbook.
The $10 Gumroad learning bundle includes both complete resources and carries a $70 benefit.
Bootcamp Bundle (Review Radar) is coming soon, planned at $399 for one app project or $999 for three. Checkout remains closed. See the public preview and manually request waitlist updates by email; sending a request is not automatic registration. These are planned toolkits, not a promise of a finished app or revenue.
Benefits require verified purchases, apply once per buyer when checkout opens, do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued benefits remain preserved.
My practical rule: when you review automation, name the code you are accepting as well as the job you want it to do.
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim
Top comments (0)