Using AI to consider the options

I use AI (I apologize if you saw this as a raw AI post that was a mistake that AI created). Ultimately I'm trying to find the balance of using AI to help me do things faster while keeping understanding of the project and issue (which is what I think is the optimal spot of AI usage).

There was a recent problem with dependabot highlighting a circular import and then leading me astray, ultimately guiding us to do the thing that we were hoping to avoid.

Problem

Dependabot opened [PR #1164][1164] against render-engine. There were three dependencies, more-itertools, python-frontmatter, and rich that needed updates.

× No solution found when resolving dependencies:
╰─▶ Because render-engine-cli==2025.11.1 depends on your project and
    render-engine[cli] depends on render-engine-cli==2025.11.1, we can
    conclude that render-engine[cli] depends on itself at an incompatible
    version (render-engine>=2025.11.1a1).

    hint: The package `render-engine-cli` depends on the package  
    `render-engine` but the name is shadowed by your project. Consider
    changing the name of the project.

Why uv re-resolves when pyproject.toml changed

uv run first checks whether the lockfile is consistent with pyproject.toml. The PR modified pyproject.toml but not uv.lock (dependabot leaves the lock alone unless configured otherwise), so uv detects the drift and re-resolves from scratch.

What setuptools_scm sees in a shallow clone

The project's version is computed by setuptools_scm:

[tool.setuptools_scm]
local_scheme = "no-local-version"
version_file = "src/render_engine/__version__.py"

setuptools_scm shells out to git describe --tags and parses the result. Locally that works because my clone has the full history. In the workflow:

- uses: actions/checkout@v6.0.1

No fetch-depth. The default is 1 which is a shallow clone with no tags. With no tags, git describe has nothing to describe, and setuptools_scm falls back to something like 0.0.dev0. That value does not satisfy >=2025.11.1a1 which is why the dependency error.

Did AI want to do

Claude gave me three options:

1. remove the extra dependency
2. change the fetch-depth to 0 so that all history and tags is grabbed
3. set an artificial version number as a fallback (v9999.9999.9999) that will always satisfy the import

the artificial number was an "ABSOLUTELY NOT" moment and I wasn't sure how eager the team of contributors would be to make a change to how the cli was used to import render-engine. That left the fetch-depth: 0 option which seemed like the only reasonable choice. I told Claude to implement the change and we filed an issue and then submitted a PR. Dan left me the best and most honest review that I've seen.

I hope this does what you think it does because I have no idea.

I couldn't prove it

And this is the problem when LLM driven coding is preferred over collaboration. Instead of having the conversation with the team, I biased towards action and made a development choice that others based on the justification and valid code, accepted.

If fetch-depth:0 was the answer, I wanted to prove it.

Quick search of Github review a similar comment on Magick.NET [issue #1528][magick-comment] that pointed out fetch-tags was something that existed and would pull in tagging information.

This presented a different problem in that fetch tags only guarantees the tag refs are downloaded. The commits between HEAD and those tags would not be included that means that while there would be a list of tags, I'd need custom code to make it work and I was against any custom code.

I wanted to verify this

I decided to create two draft repos with the two changes. I'd push them and see if the test would run correctly. One that had the tags-only and one with full history.

$ git clone --depth=1 https://github.com/render-engine/render-engine
$ cd render-engine && git fetch --depth=1 --tags
$ git tag | wc -l
116
$ git describe --tags
fatal: No tags can describe '0a4585d81bf95788901890a546d944573b34b711'.
Try --always, or create some tags.

The latest tag (2026.5.2a2) was two commits behind HEAD and there had been changes so uv.lock still needed to be regenerated.

The other repo was a basic repo with full history

$ git clone https://github.com/render-engine/render-engine
$ cd render-engine && git describe --tags
2026.5.2a2-2-g0a4585d
$ uv run --with setuptools_scm python -c \
    "from setuptools_scm import get_version; print(get_version())"
2026.5.2a3.dev2+g0a4585d81

This one worked. Armed with this information I had AI generate a new PR comment and the very rough draft of this post. I also pushed the the steps to duplicate my steps. And I shared it with the team.

The end result...

In the end we decided to do the easiest thing and remove the extra. 🙃

After showing the options and evaluating the tradeoffs we realized that it would be easiest to do that and update the instructions.

Things to remember

A few takeaways I want to keep in mind.

• The right answer can still be wrong when given all the factors.
• Our usage of AI slowed us down and made us intentional about about our decision.
• AI helped us learn and setup an experiment faster than had we done it on our own.
• AI combined with team collaboration helped us evaluate our choices and come to come up with a solution that.