Our hackathon recap: code, pizza, and music bingo.
The hottest day of the year so far, with the thermometer hovering around 38 degrees, and we were inside working. Not out of obligation, but because a hackathon has its own unique energy that pays little heed to the weather. For a whole day, our usual schedules were put on hold, and there was room for just one thing: taking an idea from the drawing board and turning it into something that actually works. Once again, the entire day was all about AI. You can read about the results below.
Manuals that write themselves.
Creating documentation is on just about every to-do list, and hardly anyone looks forward to it. You walk through an application, document every step, take the corresponding screenshots, and by the time everything is written down, the software has already been updated. One team decided to tackle that task at its root.
What was the result? A solution that automatically generates user documentation based on an existing project: clear explanations, corresponding screenshots, and even interactive tours of the application. They tested it in multiple environments, starting small and then scaling up. By the end of the afternoon, they had something that was nearly ready for use. The first version was already largely accurate and only needed some fine-tuning, whereas before it would have taken hours of typing. You really notice that kind of time savings when you no longer have to write the manual yourself.
Feedback that's right on target.
We’re increasingly delivering designs as interactive prototypes rather than as static images in Figma. That works well, but there wasn’t yet a good way to provide specific feedback on them. A comment like “this button needs to be different” is hard to place if it’s not immediately clear which button on which screen is being referred to. This team built a tool that solves that by linking every comment to the element it refers to. The client posts their feedback directly on the prototype, the team sees everything consolidated in one place, and from there it goes straight into the revision process. By the end of the day, the entire workflow was up and running from start to finish: from setting up a prototype to collecting and processing feedback.
An assistant who works as part of the team.
Think of a colleague in your team channel who always knows when everyone is available, never forgets to schedule anything, and politely follows up on what’s still missing. That was the starting point for this project: an AI assistant that runs locally and simply works alongside the team. The assistant was given access to calendars and documents and could perform specific tasks with them: finding a suitable time, scheduling an appointment, or drafting a document. If something was missing—such as a last name or an address—it would ask for it directly in the channel. When interacting with external contacts, it exercised extra caution, providing a clear confirmation before anything was sent. It was a thorough exploration, during which the team gained a clear understanding of where such a setup truly adds value and where it makes little difference.
A map of the codebase.
When you put an AI agent to work on a large codebase, it faces the same challenge as a new colleague: it lacks an overview. As a result, it ends up guessing or overlooking parts of the code. This team investigated whether a kind of “map” of the code could help with this and implemented it in several ongoing projects.
The result was down-to-earth, and that’s precisely what made it valuable. It didn’t significantly speed up the actual writing of code. But when it came to understanding the big picture, figuring out where something was used throughout the codebase, and restructuring code, the benefits were clearly visible. The agent was able to grasp the big picture more quickly and made fewer mistakes. The lesson: it’s a powerful tool for analysis and research, and an excellent starting point on which to build further.
Old MacBooks Given a Second Life.
You’ll find them in almost every closet: laptops that are no longer in daily use but are too good to write off. This team gave a number of old MacBooks a new role as extra capacity for testing and rolling out software. By the end of the day, a full build of an existing project ran flawlessly, including all the tests. The straightforward conclusion: as a supplement, this is definitely worth it, because you’re making use of hardware that’s already there. It’s not a replacement for your trusted infrastructure, though—such a setup requires too much maintenance for that. And that’s exactly what a hackathon is for: not just to see what works, but also to honestly determine where the limits lie.
Pizza party with music bingo.
Four ideas that were still on a whiteboard that morning were actually up and running by the end of the day. That’s what a hackathon is for: not spending weeks in meetings debating whether something is possible, but just building it and seeing what happens. The BBQ we’d planned couldn’t withstand those 38 degrees. So we moved on to Plan B: pizza boxes on the tables, music playing, and a game of music bingo that got a lot more intense than anyone had anticipated. Another great day!
Ready to build something with Cube?
Tell us what you have in mind and we'll think along with you.
Worth reading next...
Where do you stand on AI? Discover our five phases.
AI-Assisted & Agentic SDLC: The Software Development Lifecycle in the AI Era.