So: every development tool I know looks at the same moment. Now. The code as it is today. The build as it is running right now. The dependencies as they stand in the graph today. A photo. And a photo is good when you want to know what something looks like. It is useless when you want to know where it is heading. Software moves. Every day. And the tool that measures that movement I have not found so far. So I am trying to build one. Whether it works, I do not know yet.
The photo
Static analysis, linters, dependency graphs, test coverage, security scans: all photos. They tell you where it is stuck today. Cyclomatic complexity of this class, coverage of this module, this library has a hole. Good tools, I use them every day, and with agents that write two thousand lines in minutes you need them more than ever.
But they all have the same blind spot. They know no time. A module with complexity 40 is, to them, a module with complexity 40. Whether it was at 12 a year ago and has been rising faster every week for five weeks, they do not see. That is written nowhere. You would have to compute it from the history, and nobody does, because no tool is built for it.
The film
Software is a film. A module that looks healthy today may have been getting less stable for five weeks, and accelerating. A domain nobody has on their radar has been pulling in more and more dependencies for months, each one harmless, together a knot. Two areas that, according to the architecture, have nothing to do with each other have been touched in the same commit almost every time for half a year. Those are not states. Those are movements. And you only see movements when you watch the film, not the photo.
What the architect feels
An experienced architect feels it. He has been in the project for two years, he has seen the pull requests, and at some point he says in the stand-up: leave the billing module alone, it is getting hot. Or: if you touch the address check, look at the export too, those always hang together here. He has no number for that. He has a feeling from a thousand commits. And when he leaves the project, the feeling is gone, and none of his tools has stored it.
I wrote it in the article about the architect: the hard question is not how to implement a pattern, but where you need which one, and how you make sure the decision holds across the whole system. This is the continuation. The architect sees the movement because he has watched the film. The question is whether you can show that film to a small model.
The experiment
This is what we are trying at NeoCoder right now, and I write it as it is: an experiment, not a feature. We call it NeoTemporal, and it is a small model of our own that is not meant to learn the state of a project but its dynamics. We have the food for it because NeoCoder, as an agent, sees the whole chain, not just the code: state, action, result, next state. Plus years of git history. From that sequence the model should learn how projects move. Which areas swing together. Which rhythms repeat. Where change accelerates.
And the important part, because it is the first question every customer asks: it does not learn from the source code. It learns from structure data. Which file was changed when together with which, how big the change was, what happened afterwards. Not a byte of code leaves the house for it. The model is small enough to run locally in milliseconds, like the fifty micro models I have written about. Small, one task, and you understand it.
What it should bring, if it works
Three things, and I write "should" with each, because none of them does it yet.
The context is ready before you ask. If the model can say where the next change will probably land, the agent can load the knowledge for exactly those areas beforehand. The first answer would come faster and cost less, because the tools and files are already there. It is the same idea as in the MCP article: not everything into the context, but the right thing.
A warning before the problem, not after. "This module is hot right now, plan for buffer." "In this project a change to X is almost always followed by one to Y, and that one is still open." Those are not rules anyone maintains. That would be learned experience from your own project, the way the architect has it in his head, only stored.
Technical debt gets a trajectory. Static analysis says where it is stuck today. The model should show what is getting worse in motion, before the state tips. Not "complexity 40", but "complexity 40, and at this pace 60 in eight weeks".
If one of these works, the experiment was worth it. If none works, I will write that too. Like with the test data prototype, where I only saw three mistakes with some distance.
The rules before it joins
This is the part that matters more to me than the idea. A model that makes predictions about your project is dangerous if you believe it before it has proven itself. So the same rules apply as everywhere with us.
It decides nothing. It proposes. The team decides. No agent signs off on its own work, and a model that guesses the future certainly not.
It has to beat a baseline. The dumbest prediction is: what was changed often recently will be changed again. That is the statistical baseline, and it is surprisingly good. The model only joins when it is measurably better on frozen test data, and that on projects it has never seen. Otherwise you just have an expensive procedure for "recently changed".
Every training run has a budget and a deadline. No run without a cost cap. A watchdog that ends the pod when no heartbeat comes anymore. Every pod dies with its run. That is the emergency protocol from the article about the rules, here in the training console.
Every run is reproducible. Dataset, code revision, config: the three stand in every model card. Whoever asks in half a year why the model decides this way can repeat the run.
The numbers come when there are numbers. Not before. That is why there is none in this article, and the screen above shows sample data. When the measurement is there, I will add it here, with the baseline next to it.
What stays
Other tools answer the question: what does my project look like? I want to answer the other one: where is it heading? Whether a small model can learn that from the film a project shoots over years, I will know in a few weeks. What I already know: the question is right. I have seen too many projects tip where every photo was fine.
Software is a film, and all tools look at a photo. The architect sees the movement, but he cannot show it, and when he leaves, it is gone. I am trying whether a small local model can learn that movement from structure data: where it gets hot, what hangs together, what tips. It proposes, it decides nothing, and it has to beat a baseline before it joins. Numbers come when there are numbers.
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.