12 Hours, One Hackathon, and a Lot of Learning - Our Hacktoberfest Experience

Shresth Juyal — Sun, 01 Nov 2026 00:58:18 +0000

Hackathons always sound exciting before they actually begin. You imagine building something amazing, writing code with your teammates and finally presenting a working product. But once you get into it, things rarely go exactly as planned.

That was pretty much our experience at the Hacktoberfest hackathon, which took place from 31st October to 1st November.

Our project was called DevTrace, and we chose Problem Statement 6: Open Source Decision Intelligence and Knowledge Recovery.

Finding a problem worth solving

One thing I found interesting about our problem statement was that it wasn't asking us to build another coding assistant. It was about something developers often overlook: understanding why a particular technical decision was made.

Think about joining an existing open-source project. You can read the code, explore pull requests and look through issues, but understanding why the team selected one approach over another can be difficult.

Maybe someone proposed MongoDB, another contributor suggested PostgreSQL, and after a long discussion the team decided to use PostgreSQL. The reasoning might be buried somewhere in hundreds of comments.

That was the problem we wanted to solve.

DevTrace aims to recover these decisions, identify rejected alternatives, explain the reasoning behind them and connect everything to the relevant source discussions and code.

Turning the idea into an actual product

One thing we learned quite early was that having a good idea and implementing it within a hackathon deadline are two very different things.

We spent time discussing different approaches, comparing ideas and figuring out what we could realistically build. There were disagreements about how certain parts should work, but those discussions helped us narrow down the direction.

Eventually, we decided to focus on building the AI pipeline and backend first, then integrate GitHub, and finally work on the frontend.

This gave us a clearer direction instead of everyone trying to build different things without a proper connection between them.

Building the AI pipeline

One of the interesting parts was getting the AI to understand engineering discussions.

We wanted it to do more than summarise conversations. It needed to identify actual decisions, understand which alternatives were rejected and extract the reasons behind those rejections.

We worked on an AI pipeline that processes discussion information and produces structured results.

We also decided to run our model locally using Ollama instead of depending entirely on external AI APIs. We experimented with a smaller Qwen model so that inference could run on our available hardware.

Getting the model to produce useful, structured responses was an important part of the work. A response that simply sounds convincing isn't enough for our use case. We need the reasoning to be connected to actual discussion evidence.

Connecting GitHub

Once the backend and AI pipeline started taking shape, we moved towards GitHub integration.

We used Octokit.js to communicate with GitHub through its official APIs.

This allowed us to work with repository information, issues, pull requests and discussions. We also explored GitHub's GraphQL API because discussions contain nested comments and replies that are important for understanding the complete conversation.

Something I found useful was understanding the difference between fetching information and actually making sense of it. GitHub gives us the source data, but DevTrace needs to process that information and recover the engineering knowledge hidden inside it.

That distinction became central to our implementation.

The frontend and bringing everything together

After getting the backend and GitHub integration in place, we started connecting everything through the frontend.

This was the stage where the different pieces began to feel like one product rather than separate components.

We wanted the experience to be simple. A developer should be able to investigate an engineering discussion and understand the decisions, alternatives and supporting evidence without manually searching through hundreds of comments.

Of course, connecting different parts of an application under a tight deadline comes with its own challenges. We had to keep testing how information moved between the frontend, backend, GitHub and our local AI model.

Things I learned beyond writing code

One of my biggest takeaways was understanding how important the development workflow is.

We also had to work with GitHub branches, pull requests and CI pipelines. Setting up and understanding CI was a learning experience in itself. It made us realise that writing code is only one part of building a project. Making sure that changes are tested and integrated properly is equally important.

Building a CI pipeline completely on my own was a new experience for me, and it was very good. I added our tests to the pipeline so that every change to the backend and frontend is checked automatically, and I learned that a check only means something if it actually runs. Seeing those checks pass end to end was one of the most satisfying parts of the project. Later, Ivan, the founder of XERJ, reviewed my CI work and asked whether it could be integrated into their much larger repository. XERJ also selected it for their public Corpus Hub, which was a great validation of the work.

There were moments when something that looked simple took much longer than expected. Sometimes the problem wasn't even in the feature itself, but in how two different parts of the application communicated.

Those moments taught us to debug more carefully, communicate better and avoid making assumptions.

What made the experience memorable

Looking back, I think the best part wasn't just what we managed to build. It was the process of taking an idea that initially existed only as a problem statement and gradually turning it into something usable.

We had to make decisions, reconsider approaches, divide work, fix unexpected issues and keep moving despite the limited time.

Not everything was perfect, and there were definitely things we would have liked to improve with more time. But that is also what made the experience valuable.

DevTrace gave us an opportunity to explore AI, GitHub APIs, backend development, local model inference and software engineering workflows in one project.

More importantly, it reminded me that building software is rarely a straight line. A lot of the learning happens in the moments when something doesn't work and the team has to figure out why.

It was a long night, a lot of debugging, plenty of discussions and a genuinely memorable experience.

And that's probably what I'll remember most about this Hacktoberfest.

DEV Community: Shresth Juyal