Ok: sometimes someone explains to you in five minutes on the phone what you have been thinking about for two weeks. A colleague wrote a formula down for me, three letters and a dash, and since then I see git histories differently. I am writing this down as a light thought, not as a blueprint. Whoever wants the blueprint has to call.
The call
Last week I wrote that software is a film and all tools only take a photo. And that at NeoCoder we are trying whether a small model, we call it NeoTemporal, can learn the movement of a project from the git history. The colleague read that and said: what you are building is a flip book. That is not wrong. But there is another way to learn movement.
The flip book
A normal sequence model learns: state now, state next. Picture one, picture two, picture three. If you flip fast enough it looks like movement, but it is single frames in fixed steps. That works, and for many things it is enough. It has only one weakness, which you notice only when you look at real data.
A git history has no fixed steps. Three commits in an hour, then nothing for two days, then twenty in one afternoon. A flip book has to smooth that artificially so the frames are evenly spaced. And something gets lost in the smoothing. What exactly, in a moment.
The current chart
The colleague's formula says something else: do not learn the pictures. Learn the speed and the direction in which the state is changing right now. Imagine a current chart, like at sea: if you are here and this happens, you drift there, this fast. The model does not learn where the boat is next. It learns the current.
The practical trick: with a current chart you can ask for any time span. Where am I in ten minutes? Where am I in three days? The chart just keeps calculating. The flip book cannot do that, it only knows the next step. In the field this model class is called a Neural ODE, the model learns a differential equation instead of a jump table. That has been published for years, none of it is new. What is new is only what you apply it to.
Delta t
Delta t simply means: the time elapsed between two events. Commit at 9:14, the next at 9:22, delta t is eight minutes. Then nothing until the day after tomorrow, delta t is two days.
Most sequence models throw this information away. For them the history is an order: event one, two, three, no matter whether seconds or weeks lay in between. Yet the gap often holds the real signal. Five commits a minute apart on the same file tell one story: hectic fixing, probably something is on fire. Five commits over five weeks on the same file tell another: calm, planned development. Same order. Completely different meaning.
At NeoTemporal we decided early not to throw that gap away but to attach it to every event. Not because of a formula, but because the sentence "this area is getting unstable faster" cannot even be formulated without the time gap. Acceleration is a delta t statement. And that is exactly the bridge: the current chart needs real time as an ingredient. Whoever captures it cleanly from the start can later feed both worlds, the flip book and the chart, and let them compete.
The honest downside, which I asked the colleague about right away: these models are more expensive to train and more temperamental with noisy data. So the same rule applies as always. First the proof against the simple variant, then the elegance. I told in the podcast what happens when a model does not pass the proof: it stays on the shelf. Even if the formula is prettier.
Am I giving away too much?
I asked myself that before writing this. The answer is no, and the reason matters. The ingredients are all public. Neural ODEs have been in papers for years. That commit histories carry signal has been researched by a whole community for over ten years. The idea is in the air, and it belongs to nobody.
What is not in the air is your own data. Events from real projects, with the truth for free, because the build says what happened afterwards. And the machine that collects it cleanly, every day. That is NeoCoder: the agent sees not only the code, it sees the whole chain, state, action, result, next state, and writes it down. You cannot copy that, you can only build it. That is why I can tell the thought and keep the blueprint.
And because I otherwise never advertise, here once, briefly: if you have a development team and want to know where your project is heading, not just what it looks like today, that is exactly the question we are working on with NeoCoder. First with your rhythm, later with a model that knows only your data and never leaves your house. We are still looking for partners for this: teams with real projects who want to look at their rhythm with us. Write to me if you have such a project. Not to buy something. Let us see whether we can benefit from each other.
What stays
Look at your own git history once not as a list but as a rhythm. Where does it get fast? Where is it quiet for a long time and then suddenly loud? You can see that without a model, with the naked eye, and it tells you more about your project than any complexity number. The model afterwards only does what you just did. Just for all files at once, and without getting tired.
A flip book learns pictures in fixed steps. A current chart learns speed and direction and can ask for any time span. The difference lies in one number almost everyone throws away: the time between two events. Whoever keeps it can build both models. Which one wins is decided by the measurement, not the formula.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by a twin model of my own, trained on my texts. Sometimes that turns into a mix. Of course I read everything again, but nobody is infallible. Whatever stays in is mine too.