Skip to content

AI

Do I Really Need AI for Automatic Dependency Updates?

Dependency updates are one of those areas where AI is often presented as an obvious win. But when you look closely, the value proposition can be surprisingly thin.

Every few months I find myself looking at a piece of automation I wrote and asking a dangerous question:

“If I deleted this today, would I miss it?”

Recently that question came up while looking at some code that uses AI to assist with commit messages for automatic dependency updates.

It’s undeniably cool. And if we’re being honest, “cool” has probably justified more engineering decisions than we’d like to admit. ✨ Somewhere, a developer is about to spend three days adding AI to a workflow that already takes five seconds, and nobody is stopping them.

When a bot updates a dependency, AI can inspect the diff, generate a polished commit message, summarize release notes, estimate risk, and even draft a pull request description. Give it another six months and it’ll probably offer unsolicited opinions about my coding style, too. Beep-boop-beep-beep. 🤖

But do I actually need any of that?
For dependency updates specifically, I’m not convinced.

The Diff Already Explains Everything

Most dependency update pull requests are boring.
That’s not a criticism. Boring is good. In fact, “boring” is one of my favorite qualities in infrastructure. Right up there with “predictable”, “consistent”, and “unlikely to trigger a sensory response.” 😌

A typical update looks like this:

- Newtonsoft.Json 13.0.2
+ Newtonsoft.Json 13.0.3

Or:

- actions/checkout@v3
+ actions/checkout@v4

The dependency changed. The version changed. The automated tests passed.
What more needs to be said?

An AI-generated commit message such as:

Update Newtonsoft.Json from 13.0.2 to 13.0.3 to incorporate the latest improvements and fixes.

is objectively more polished than:

chore: update thing

and considerably less polished than the commit messages written by developers who own more than one ergonomic keyboard. ⌨️

But it doesn’t add information.
It’s merely a longer version of the diff.

The Cost of Automating the Obvious

AI systems are not free.

Even when the direct cost is negligible, there is still operational complexity:

  • Prompt engineering
  • API keys
  • Rate limiting
  • Error handling
  • Monitoring
  • Dependency on external services
  • Additional maintenance burden

For a feature whose main purpose is generating text that developers may never read, that’s a surprisingly long list.

The irony is hard to ignore.
I’m adding dependencies to manage dependency updates.

Once an Xzibit meme accurately describes your architecture, it’s probably time for a design review. 😅
Or at least a moment of honest self-reflection and perhaps a nice cup of tea. ☕

Most Dependency Updates Require Validation, Not Summarization

The real value in dependency management isn’t explaining what changed.
It’s determining whether the change is safe.

Questions such as:

  • Did tests pass?
  • Are there breaking changes?
  • Did security vulnerabilities disappear?
  • Has runtime behavior changed?
  • Should this be rolled out gradually?

Those are useful questions.
An automatically generated paragraph of prose is not.

If I had to choose between:

  • AI-generated release summaries
  • Better test coverage

I’d take better tests every time.

Where AI Actually Helps

To be clear, I’m not arguing that AI is useless in dependency management.
There are situations where it genuinely provides value.

For example:

Large Version Jumps

Updating from:

React 17 -> React 19

is not the same as:

React 19.1.0 -> 19.1.1

That’s the difference between “let’s merge this before lunch” and “let’s spend the next three hours reading documentation for fun.” 😅

The first update may involve deprecations, migration guides, and behavioral changes spread across hundreds of pages of documentation.
Having AI summarize those changes can save time.

Dependency Investigation

When a vulnerability appears in a transitive dependency, AI can help answer questions like:

  • Why do I have this package?
  • Which component pulls it in?
  • What are my upgrade options?

That’s actual analysis.

Pull Request Triage

In environments processing hundreds of updates per week, AI can prioritize and categorize changes:

  • Security-related
  • Major version updates
  • Low-risk patch releases
  • Updates requiring manual review

Again, this is valuable because it’s helping people make decisions.

The “Because We Can” Trap

One of the easiest mistakes in engineering is automating something because it is technically possible. AI makes this temptation even stronger.

You add a model call.
The output looks impressive.
Everyone nods.
Nobody wants to ask whether the feature is genuinely useful. Which is ironic, because asking uncomfortable questions is usually how I ended up adding the feature in the first place. 😅

Six months later nobody reads the generated text, nobody remembers why it exists, and the system is carrying around a feature whose primary function is making demos more interesting.

That’s usually the moment when the dangerous question returns:

“What would happen if I deleted this?”

If the answer is “nothing,” deletion should be a serious option.

Simplicity Is a Feature

The software industry currently has a tendency to ask:

“How can we add AI to this?”

A more useful question is:

“What problem exists that AI uniquely solves?”

For routine dependency updates, I’m not sure there is much of a problem to solve.

  • A dependency bot opens a pull request.
  • The diff shows the change.
  • CI validates the result.
  • Humans review anything important.

That’s already a remarkably effective system.

The AI-generated commit message may be neat. It may even spark a ten-minute discussion about style, consistency, and aesthetics that is somehow completely unrelated to dependency management. But aesthetically pleasing is not the same thing as necessity.

And sometimes the best engineering decision is not building something new.
Sometimes it’s deleting code and discovering that nothing got worse.

Maybe Open Source Instead of Delete?

Just because I’m questioning a feature’s place in my workflow doesn’t mean the code itself has no value.

What started as an experiment in AI-generated commit messages evolved into a working GitHub Action. It takes a diff, calls an LLM, and produces a commit message that is often more polished than what most developers would write themselves.

The question isn’t whether it works. The question is whether it solves a problem I still have. For routine dependency updates, I increasingly think the answer is “not really.”

For routine dependency updates, the diff already tells the story. The generated explanation rarely influences whether I merge a change. Most of my confidence still comes from test results, release notes, and experience with the dependency itself.

But that doesn’t mean the idea is universally useless.

Some teams maintain hundreds of repositories. Some want consistent commit messages. Some value automated summaries and release notes. Others simply enjoy experimenting with AI-assisted workflows.

So rather than keeping an optional AI component embedded in a critical workflow, I have extracted it into its own repository and made it public on GitHub:

https://github.com/amedee/ai-commit-message

That has a few benefits:

  • My dependency update process stays simple.
  • The action remains available for anyone who finds it useful.
  • Future development can happen independently.
  • The project can stand on its own merits. Or fail gloriously on its own merits. Open source is wonderfully impartial that way. Besides, releasing a side project to the public is significantly cheaper than buying another keyboard, graphics card, or suspiciously expensive cardigan. 😅

In a way, open-sourcing it feels like a more honest outcome than quietly keeping it around forever. If the idea is genuinely useful, people will adopt it. If not, that’s valuable feedback too. I’ve spent enough time collecting niche interests to know that “a surprisingly specific audience of twelve people” can still be a community. 🌈

Sometimes publishing a project is the fastest way to discover whether you’ve built a product, a feature, or simply an interesting experiment.

Not because I’m convinced AI-generated commit messages are essential, but because software doesn’t have to be essential to be useful. Sometimes an experiment is worth sharing even after you’ve decided not to keep it in production.

Worst case, it becomes a small open-source artifact of a particular moment in the industry’s AI enthusiasm.

Best case, somebody finds a use for it that I never did.

A Note on How This Post Was Written

Some honest truth: was this blog post (co-)written by AI?

Yes.

I gave Copilot (don’t shoot me! I also use other Large Language Models) an abstract, a rough outline of the argument I wanted to make, and the source code of the GitHub Action discussed in this article. It generated an initial draft. Which, to be fair, is also how I approach many hobbies: start with an overwhelming amount of information and then spend hours reorganizing it until it feels right. 😅

After that, though, the process looked a lot like editing any other piece of writing. I rewrote sections, changed wording, moved paragraphs around, added examples, removed points that didn’t fit, and generally shaped the article into something that reflects my own opinion. In other words, the AI produced a draft and I spent the rest of the time refining presentation details until they felt correct. If that process sounds familiar, no further questions. ✨

I can’t escape the irony of using AI to help write a blog post that questions whether AI is needed for a particular problem.

That irony is intentional.
In fact, it reinforces the point I’m trying to make.

The problem was never “AI bad” versus “AI good”. The question is whether AI adds enough value to justify its complexity. For writing, brainstorming, editing, and turning rough ideas into a first draft, I often find that it does. For generating commit messages for routine dependency updates, I’m much less convinced.

AI helped me write this post faster.
I’m not sure it helped me review dependency updates any better.

And that distinction is precisely why this blog post exists.

In Defense of the Em Dash — A Beautiful Line of Thought ✍️

Lately, I’ve noticed something strange happening in online discussions: the humble em dash (—) is getting side-eyed as a telltale sign that a text was written with a so-called “AI.” I prefer the more accurate term: LLM (Large Language Model), because “artificial intelligence” is a bit of a stretch — we’re really just dealing with very complicated statistics 🤖📊.

Now, I get it — people are on high alert, trying to spot generated content. But I’d like to take a moment to defend this elegant punctuation mark, because I use it often — and deliberately. Not because a machine told me to, but because it helps me think 🧠.

A Typographic Tool, Not a Trend 🖋️

The em dash has been around for a long time — longer than most people realize. The oldest printed examples I’ve found are in early 17th-century editions of Shakespeare’s plays, published by the printer Okes in the 1620s. That’s not just a random dash on a page — that’s four hundred years of literary service 📜. If Shakespeare’s typesetters were using em dashes before indoor plumbing was common, I think it’s safe to say they’re not a 21st-century LLM quirk.

The Tragedy of Othello, the Moor of Venice, with long dashes (typeset here with 3 dashes)

A Dash for Thoughts 💭

In Dutch, the em dash is called a gedachtestreepje — literally, a thought dash. And honestly? I think that’s beautiful. It captures exactly what the em dash does: it opens a little mental window in your sentence. It lets you slip in a side note, a clarification, an emotion, or even a complete detour — just like a sudden thought that needs to be spoken before it disappears. For someone like me, who often thinks in tangents, it’s the perfect punctuation.

Why I Use the Em Dash (And Other Punctuation Marks)

I’m autistic, and that means a few things for how I write. I tend to overshare and infodump — not to dominate the conversation, but to make sure everything is clear. I don’t like ambiguity. I don’t want anyone to walk away confused. So I reach for whatever punctuation tools help me shape my thoughts as precisely as possible:

  • Colons help me present information in a tidy list — like this one.
  • Brackets let me add little clarifications (without disrupting the main sentence).
  • And em dashes — ah, the em dash — they let me open a window mid-sentence to give you extra context, a bit of tone, or a change in pace.

They’re not random. They’re intentional. They reflect how my brain works — and how I try to bridge the gap between thoughts and words 🌉.

It’s Not Just a Line — It’s a Rhythm 🎵

There’s also something typographically beautiful about the em dash. It’s not a hyphen (-), and it’s not a middling en dash (–). It’s long and confident. It creates space for your eyes and your thoughts. Used well, it gives writing a rhythm that mimics natural speech, especially the kind of speech where someone is passionate about a topic and wants to take you on a detour — just for a moment — before coming back to the main road 🛤️.

I’m that someone.

Don’t Let the Bots Scare You

Yes, LLMs tend to use em dashes. So do thoughtful human beings. Let’s not throw centuries of stylistic nuance out the window because a few bots learned how to mimic good writing. Instead of scanning for suspicious punctuation, maybe we should pay more attention to what’s being said — and how intentionally 💬.

So if you see an em dash in my writing, don’t assume it came from a machine. It came from me — my mind, my style, my history with language. And I’m not going to stop using it just because an algorithm picked up the habit 💛.

📚 Automating Ansible Role Documentation with GitHub Actions and AI

Maintaining documentation for Ansible roles can be a tedious and easily neglected task. As roles evolve, variable names change, and new tasks are added, it is easy for the README.md files to fall out of sync. To prevent this and keep documentation continuously up to date, I wrote a GitHub Actions workflow that automatically generates and formats documentation for all Ansible roles in my repository. Even better: it writes its own commit messages using AI.

Let me walk you through why I created this workflow, how it works, and what problems it solves.

🤔 Why Automate Role Documentation?

Ansible roles are modular, reusable components. Good roles include well-structured documentation—at the very least, variable descriptions, usage examples, and explanations of defaults.

However, writing documentation manually introduces several problems:

  • Inconsistency: Humans forget things. Updates to a role do not always get mirrored in its documentation.
  • Wasted time: Writing boilerplate documentation by hand is inefficient.
  • Error-prone: Manually copying variable names and descriptions invites typos and outdated content.

Enter ansible-doctor: a tool that analyzes roles and generates structured documentation automatically. Once I had that, it made perfect sense to automate its execution using GitHub Actions.

⚙️ How the Workflow Works

Here is the high-level overview of what the workflow does:

  1. Triggers:
    • It can be run manually via workflow_dispatch.
    • It is also designed to be reusable in other workflows via workflow_call.
  2. Concurrency and Permissions:
    • Uses concurrency to ensure that only one documentation run per branch is active at a time.
    • Grants minimal permissions needed to write to the repository and generate OIDC tokens.
  3. Steps:
    • ✅ Check out the code.
    • 🐍 Set up Python and install ansible-doctor.
    • 📄 Generate documentation with ansible-doctor --recursive roles.
    • 🧼 Format the resulting Markdown using Prettier to ensure consistency.
    • 🤖 Configure Git with a bot identity.
    • 🔍 Detect whether any .md files changed.
    • 🧠 Generate a commit message using AI, powered by OpenRouter.ai and a small open-source model (mistralai/devstral-small:free).
    • 💾 Commit and push the changes if there are any.

🧠 AI-Generated Commit Messages

Why use AI for commit messages?

  • I want my commits to be meaningful, concise, and nicely formatted.
  • The AI model is given a diff of the staged Markdown changes (up to 3000 characters) and asked to:
    • Keep it under 72 characters.
    • Start with an emoji.
    • Summarize the nature of the documentation update.

This is a small but elegant example of how LLMs can reduce repetitive work and make commits cleaner and more expressive.

Fallbacks are in place: if the AI fails to generate a message, the workflow defaults to a generic 📝 Update Ansible role documentation.

🌍 A Universal Pattern for Automated Docs

Although this workflow is focused on Ansible, the underlying pattern is not specific to Ansible at all. You can apply the same approach to any programming language or ecosystem that supports documentation generation based on inline annotations, comments, or code structure.

The general steps are:

  1. Write documentation annotations in your code (e.g. JSDoc, Doxygen, Python docstrings, Rust doc comments, etc.).
  2. Run a documentation generator, such as:
  3. Generate a commit message from the diff using an LLM.
  4. Commit and push the updated documentation.

This automation pattern works best in projects where:

  • Documentation is stored in version control.
  • Changes to documentation should be traceable.
  • Developers want to reduce the overhead of writing and committing docs manually.

🔐 A Note on OpenRouter API Keys

The AI step relies on OpenRouter.ai to provide access to language models. To keep your API key secure, it is passed via secrets.OPENROUTER_API_KEY, which is required when calling this workflow. I recommend generating a dedicated, rate-limited key for GitHub Actions use.

🧪 Try It Yourself

If you are working with Ansible roles—or any codebase with structured documentation—and want to keep your docs fresh and AI-assisted, this workflow might be useful for you too. Feel free to copy and adapt it for your own projects. You can find the full source in my GitHub repository.

Let the robots do the boring work, so you can focus on writing better code.

💬 Feedback?

If you have ideas to improve this workflow or want to share your own automation tricks, feel free to leave a comment or reach out on Mastodon: @amedee@lou.lt.

Happy automating!