Inspiration
I noticed that most developers around me who use LLMs to fix a bug or build a feature do not really understand the code behind the implementation. This made it difficult for reviewers handling PRs, and the engineer could easily forget what they did. So I had the idea of building a sort of learning tool that enables developers to learn while they build.
What it does
CodeRecall checks the diff between the current branch and the base branch, asks the developer specific questions about the changes, and generates a report based on the answers provided. This report outlines the gaps and strengths in the user's response, allowing them to go back and cross-check the specific files where they have understanding gaps.
How I built it
Firstly, I had a session with ChatGPT Sol to outline the gaps in my idea and come up with project specifications. Once this was done, I downloaded these specifications to a blank repository and created an MVP document with the expected features and flow for the Contest MVP. After that, I created another product specification document containing the product use cases and user experience mapping. I then created an architectural document and a breakdown of each task needed to complete the features with the help of Codex 5.5 and 5.6 Sol.
Then I started implementation iteratively, one task after the other, using skills for test-driven development and code review.
Challenges I ran into
The biggest challenge faced on this project was handling the heuristic approach to evaluating diffs and mapping them against the user's response. I committed early to a deterministic evaluator, which meant every judgment had to come from lexical matching against concepts extracted from the diffs.
Accomplishments that we're proud of
Building an installable package and being ready to use within 4 days is a great accomplishment. This is literally my first time doing something like this, especially for a tool that will be useful for other engineers out there.
What I learned
What I learned is that having an idea and developing it into a fully usable product are two distinct realities that don't always go as expected. Theoretically, quizzing developers about their code changes sounded simple, but most of the work went into evaluating text answers against repository evidence without using an LLM, giving false praise, or making assumptions. The first time I tested CodeRecall on a real project, it asked me about a planning document and failed to recognize a correct answer written in my own words. The idea still worked, but several of my initial assumptions did not.
What helped me close the gap was using the right tools and following a disciplined process. I wrote the specification and broke the work into tasks on the first day. I then completed each task in a small branch, with tests, linting, and type checks passing before moving forward. That process helped me turn the initial concept into a product I could actually demonstrate.
What's next for CodeRecall
- Add an opt-in semantic mode using local or hosted OpenAI compatible models, while keeping repository evidence authoritative.
- Extend symbol analysis beyond Python, JavaScript, and TypeScript, with clear warnings when analysis is limited.
- Publish CodeRecall on PyPI with proper versioning for simple installation and updates.
Built With
- codex
- python
- rich
- ruff
- typer
- uv


Log in or sign up for Devpost to join the conversation.