13.07.2026 · 2 min
Loading...
The hackathon from inside: the Blender rig and the night between days.
Let us be honest — we planned for about eighteen people. It was a nice, round, convenient number: six teams of three, one workstation each, exactly as many as there are chairs in the laboratory. We even drew a seating plan (with that special organiser’s pleasure of packing a suitcase the day before a trip and believing everything really did fit).
Then the registrations started coming in. There were noticeably more than eighteen. We looked at the list, exchanged glances and said to each other the line every organiser in the world says: “Never mind, some of them drop off along the way.” That is our professional prayer. It usually works.
This time it did not. And you know what — it was clearly for the better! Around thirty people passed through the hackathon over the two days. Some were there for part of it, some for all of it; at peak moments twenty-three people were in the laboratory at once. Some arrived later, some joined only on Saturday, some brought their own laptop — and that, frankly, saved us. The crowding turned out to be the working kind: the kind where you can hear the table next to you arguing about a trajectory, and someone at the other end of the room laughing because their simulation has just flown into a wall for the third time in a row, with a funny caption on the screen.
I still think it was the best planning failure of my career.
Before the participants arrived, the laboratory team and I spent two weeks building the environment. Not a presentation about a flying body, but a real Blender rig you can get your hands into: a flight simulation with six degrees of freedom, a set of tasks at four difficulty levels, and a scoring system that does not lie but helps us, the organisers, check the scoring system.
Six degrees of freedom is when the craft in the simulation does not “swirl around the screen” but lives in space: it moves along three axes and rotates around them. Roll, pitch, yaw. Three words that sounded to most participants at the start of the hackathon like an incantation in an unfamiliar language, and by the end like the names of tools in their own workshop.
We prepared the tasks in advance, but with one important condition written straight into the rules: if a team goes beyond the problem as set, experiments, rewrites the task to suit itself — it gets extra points in the presentation round, provided it proves to us that everything there is sound and honest. We built that mechanism in more or less on a hunch. It was a door left open just in case, and we honestly did not know whether anybody would even look through it.
Spoiler alert! Everybody did.
Not one team stayed inside the original problem statement. Some made the environment harder, some rewrote the reward function, some decided that a basic trajectory was boring and took on a manoeuvre that was not in our tasks at all. By the end of day two, our neat set of difficulty levels looked like a map that had been drawn over with routes of somebody else’s making.
Now the most important thing to understand about this hackathon, and the thing that usually causes the most surprise: the participants mostly did not write code by hand. Yes, we know that departs from the usual meaning of the word “hackathon”, but we had a live goal — to demonstrate live physics, and to show that it does not end with pages of copied-out notebooks. Every team had access to Claude Code. The real subject being learned was not syntax but prompting — the ability to state a problem in such a way that working physics comes out the other end, rather than plausible text that looks like physics.
That turned out to be a far deeper skill than it looks from the outside. A model is not a genie granting wishes; it is more like a very capable intern who will do exactly what you formulated and will not once ask whether that is really what you meant. So over two days we were effectively teaching four things: how to state a problem so that it has one unambiguous reading; how to break a big goal into steps the model can actually carry; how to check the result instead of believing it; and what the consequences of a careless prompt are when whether your craft stays in the air depends on it.
The participants learned that last point faster than any of the others. The simulation turned out to be a wonderful teacher: it does not argue, does not lecture and does not hand out marks. It simply shows you whether your idea falls or flies. Seeing your own craft confidently fly into the floor because of one imprecise phrase in the problem statement is a better lesson in engineering precision than a whole semester of lectures about it.
In parallel, roles started sprouting inside the teams by themselves. One person took on the prompt architecture, another the simulation settings, another edited the final video. Nobody imposed that division or wrote it into the rules; it grew out of the task, the way a path gets worn where people actually walk.
For me as an organiser, that was the main result. Not the code. The fact that school leavers who did not know each other turned, in two days, into teams that can divide up areas of responsibility and negotiate under deadline pressure.
That is the phrase we heard most often at the start — and almost always in the guilty tone people use to confess to something irreparable. School leavers arrived convinced that physics is something difficult, alien and definitely not for them. That it is a cupboard full of formulas, and the key was handed to somebody else.
Two days later the same people were calmly handling six degrees of freedom, telling roll from pitch, discussing stabilisation, control and reward functions — not as terms from a textbook, but as working parts of their own project.
The recipe turned out to be almost banally simple. Give a real example instead of an abstraction. Build a visual environment where you can see exactly what is happening. Let people train that simulation with their own hands rather than watch it. And add competition and like-minded company, because nothing speeds up learning like knowing that something is already flying at the next table.
And difficult physics stops being difficult. It becomes a tool you make things with. Much the same way a guitar stops being difficult the moment you first play something that sounds like a song.
Some of the participants stayed in the dormitory, and it was the night between day one and day two that gave me the most valuable observation of the whole hackathon.
Formally, the hackathon stopped in the evening. In practice it did not stop anywhere. The teams sat there, came up with new ideas, reworked concepts, looked for a way to surprise the jury — and, judging by their faces the next morning, slept about as much as is possible at sixteen on the eve of a final.
Watching team spirit compete overnight was probably the best part of those two days. Not the presentations, not the results table, but that hum at half past eleven when six separate groups of people simultaneously decide that what they have done is not good enough.
Every participant got a reward: a student record book and a board game. But the winning team got something that is hard to buy — access to the laboratory itself, a month of Claude Code for free and mentorship from the AI-Space team. That is not a souvenir but a continuation. A door that does not close on Sunday evening along with the hackathon)
Most of the participants are from Kyiv, which makes sense: coming to a laboratory on the other side of town for two days is a decision you make in fifteen minutes. But sitting at the tables next to them were people from Fastiv, Pryluky, Mohyliv-Podilskyi, Kropyvnytskyi and Zhytomyr. For some of them the journey here is not just “getting there” but a plan: tickets, somewhere to sleep, negotiations with parents, and the risk of spending your weekend on something incomprehensible and coming back with nothing.
Another charm of those two days was the guests. We deliberately did not turn the hackathon into a closed room: we wanted the participants to see the grown-up world they are about to walk into, not in the format of a “what to become” lecture but in the flesh, at the next table.
Tetiana Vakulenko, director of the Ukrainian Center for Educational Quality Assessment, came to see us. Seeing a real person behind the assessment system, one who is interested in exactly what you are doing with your reward function right now, is an experience that is hard to overvalue.
There was Vladyslav Bandurin, Co-Founder & CEO of abitly — the case where the founder of a product for applicants comes not to “present the product” but to look at his users in their natural habitat: sleepless, absorbed, with three terminals open and one unsolved problem.
And there was Ivan Didur with the Data Root Labs team — people for whom machine learning is not a weekend hobby but daily engineering work. Guests like that are the best at clearing the romantic fog off participants: when a practitioner asks one precise question about your model, you learn more about your project in ten seconds than in half a day of thinking on your own.
And now, briefly, to you, if you have read this far.
If you are choosing where to apply right now and reading this thinking “sounds interesting, but I would definitely not manage it” — this text was written for you exactly. The AI SkyRun participants arrived with precisely that feeling. Two days later they were teaching bodies to fly and explaining to the jury why their reward function was better than their competitors’.
The difference between “I would not manage it” and “I did it” is usually not talent. It is two days, a decent environment, and people nearby who are already a little bit into it.
We publish stories like this, task breakdowns and announcements of the next intakes in the “Vstupnyk FMF” Telegram channel — if you want to make it to the next hackathon as a participant rather than a reader, subscribing is the easiest first step.
📩 Contact for questions, partnerships and taking part in future hackathons: drlaispace@gmail.com
A meetup on Design Thinking: from a problem to a real product.
19.03.2026 · 1 min
NMT weighting coefficients: which subject moves your score most.
03.08.2026 · 5 min
A promo code for 100 UAH off the Admission Simulation. Valid 30 days.
27.07.2026 · 4 min