alt Hacker NewsYesterday I updated our dependency on the sqlx crate and put up a PR, and it failed in the CI build in a way I couldn’t reproduce locally.
I asked codex to take a look, and it:
- Grabbed the CI logs on its own to figure out what the CI error was
- Looked at my local setup
- Looked at the changes in sqlx from 0.8 to 0.9
And figured out that sqlx depends on an updated version of the “whoami” crate but doesn’t specify default features, which causes it to fall back on a stub implementation that makes the default user “anonymous”, which was failing to authenticate to the UNIX socket we use in our CI Postgres server. It patched the environment variable for our docker container to explicitly specify a username and the issue was fixed.
It would’ve taken me probably several hours to figure this out on my own. It took codex maybe 5 minutes.
Tell me again how LLM’s “don’t work”?
Replies
You used it in a way where the result was simple and you could verify its correctness. You used it as a super-search tool, it's good at that. It's a different use case than having it generate a lot of code from scratch.
I agree with your point in the broad sense, but the example might be bad. If sqlx is an important crate, and not stable yet, upgrading it without reading the changelog is honestly a flaw in your team process. Using the AI to fix organisational issues is typically one of the reasons I'm very skeptical of AI improving productivity in the long run.
I'm not taking a shot, to be clear, we had a similar issue a few years ago and we made sure this wouldn't happen again, that's absolutely not a shot, nor do I think it's a character flaw to use AI, au contraire, this is a very good use. I'm just worried that because AI is so good at fixing minor issues caused by governance/organisation flaws, we will be stuck using it to fix those and be trapped in mediocrity (that's not an issue for me, mediocrity is where I work best, but I'm a bit sad for the great Devs I've worked with.)