Some of the most useful ideas at work do not begin as official projects. They start as small experiments: a frustration, a gap, or a question of “wouldn’t it be useful if…?”
That is exactly how two of my recent side projects began.
In my spare time, I built ReviewG33k and TestG33k. They were both created to solve very practical problems we were running into day to day, and both have ended up being useful well beyond the original idea. What made that possible was not just the idea itself, but the speed at which I could turn it into something real with the help of Codex.
Codex has been a huge part of making this kind of extra-curricular work realistic. It helps me move from rough concept to working tool much faster, which means I can spend more time shaping something useful and less time getting stuck in repetitive setup work.
ReviewG33k: helping code reviews start faster
Code reviews are an important part of software development, but they also take time and concentration. A reviewer is often trying to spot common issues, inconsistencies, missing tests, or areas that could be tidied up before they give more detailed feedback.
ReviewG33k was created to make that first pass quicker and easier.
It gives developers and reviewers a practical way to scan code changes and highlight likely issues before too much time is spent digging through everything manually. That might mean spotting missing tests, identifying areas that could become harder to maintain, or flagging small issues that are better fixed early.
The important part is that it is not there to replace human judgement. It acts more like a helpful second pair of eyes. It gives the team a head start.
That has turned out to be useful in two ways:
- Reviewers can use it as a first-pass aid when looking at code that has been shared for review.
- Developers can use it before they even raise a pull request, which helps catch issues earlier and improves the quality of the code going in.
Several team members are now using ReviewG33k in exactly that way. It helps reduce some of the repetitive review effort and lets people focus more of their attention on the bigger-picture questions that matter.
TestG33k: making automation easier to see
Our testing landscape is not all in one place. We have several products, and our automation is run in different ways, including Python scripts and PowerShell-based workflows. That flexibility is useful, but it can also make it harder to get a simple answer to a simple question: what ran, and what happened?
TestG33k was built to make that picture clearer.
It brings automation results together into one lightweight web page so that people can quickly see the current state of testing across products. Instead of digging through separate tools or outputs, the team gets a clearer shared view of recent runs and outcomes in one place.
That visibility is valuable for more than just developers. Product owners, QA, and engineers can all benefit from being able to glance at one page and understand the current position. It supports quicker conversations, easier check-ins, and a better shared understanding of how our automation is performing.
In other words, it turns scattered information into something much more usable.
What Codex changed for me
The most interesting part of this story is not just that these tools exist, but how quickly they were able to go from idea to something genuinely useful.
Codex has helped me prototype faster, explore ideas more confidently, and spend less of my spare time wrestling with the repetitive parts of building software. It makes it much easier to try something, improve it, and keep moving.
That matters because side projects usually live or die on momentum. If the gap between “this might help” and “this works” is too large, many useful ideas never get built at all. Codex has made that gap much smaller.
For me, that has meant I can create tools that are not just interesting experiments, but practical things people at work actually use.
