When you work close to complex application data, you eventually run into one of those situations: something is clearly wrong, but the underlying structure is only partly familiar. You know the bug is somewhere in the library, somewhere in the database, somewhere behind a layer of abstractions — but finding the right object quickly is the real challenge.
That happened to me often enough at work that I wanted a better way to search through large datasets for specific objects, especially in cases where the data model was not yet fully clear to me. Instead of manually digging through records, guessing relationships, or writing one-off helper scripts every time, I decided to build a small tool for exactly this purpose.
The result is oid-finder.
Why I built it
In day-to-day troubleshooting, speed matters. If you are dealing with a large database and a complex library or application layer, it helps enormously to have a tool that can locate relevant objects fast — even when you do not yet fully understand every detail of the surrounding data structure.
That was the main motivation behind this project. I wanted something focused and practical: a tool that helps narrow down the search space and makes debugging less tedious.
Interestingly, I did not write the first version completely by hand. I had it designed with the help of an AI assistant, then refined it into something usable for real-world debugging. To be honest, it worked better than I expected. What started as an experiment turned into a genuinely helpful utility.
What oid-finder does
At its core, oid-finder is meant to help identify and locate specific objects in large amounts of data. It is a small, targeted debugging aid rather than a full framework, and that is exactly what makes it useful: it solves one concrete problem without adding unnecessary complexity.
For me, tools like this are most valuable when they reduce friction during investigation. If I can move from “I suspect this object is involved” to “here it is” much faster, that already saves time and mental overhead.
AI as a practical tool
There is still a lot of hype around AI-generated code, and in many cases that skepticism is justified. But for small internal tools, prototypes, and focused utilities, it can already be surprisingly effective — especially when you know the problem well enough to review, correct, and shape the result.
That was exactly the case here. I used AI to accelerate the initial design and implementation, then adapted the tool to fit the actual debugging workflow. The interesting part was not that AI replaced development work; it was that it shortened the path from idea to something useful.
Final thoughts
oid-finder came out of a very practical need: finding the right objects quickly when debugging large and not always fully transparent data structures. It is a small tool, but one that has already proven more useful than I originally expected.
If you are interested, you can find the project here:
https://github.com/RalfBeckesch/oid-finder