So, a perfectly normal day: no incident like the 169 files, no study, no foreign article. Just a day in the workshop, the way it really was, with what we planned, what went wrong, and what came out in the evening. I tell it because it shows better what NeoCoder is than any description: not the features, but the discipline with which you find your own faults, name them and turn them into laws.
The plan: a receiver without a producer
The day started with a measurement run that was honest. Seven metrics, and not all green. The capture is in place: everything agents and humans do in the project is recorded as an event, state, action, result, next state. But the layer above it, the one that is supposed to recognise when a human corrects, rejects, improves the machine, existed as a receiver without a producer. The evaluation was there. Only nobody produced the signal it was supposed to evaluate. Tests green, dashboard green, and still empty.
The guiding sentence in the test plan, which I now write above every measurement run: missed metrics are not failure. They are the purpose. Each gets a ticket.
The test: a short sentence
So a test, deliberately small and deliberately real: unit tests for a helper class. Phrased the way normal people write, a short sentence, no souped-up special prompt with twenty lines of context. That is a law with us, and it has a name, the everyday-prompt law: if the system stumbles on the short sentence, that is a finding about the platform, never a problem with the prompt. The customer will not write a special prompt either.
The sentence, by the way, comes from me rejecting a test prompt that was too big, with the reasoning that otherwise it is not a real test for me. From one sentence in the chat came a law. That is how most of them come about.
The correction: tests that copy from themselves
The agent delivered, and the proposal had a real reasoning error. Not a typo, a reasoning error: tests that read their expected values from exactly the code they are supposed to test. A circular argument. Such tests are always green, because they ask "is the result the result", and they prove nothing. That is the mistake an agent makes that wants to deliver, and that a human with experience sees in two seconds.
I rejected. With a reason, in one sentence, no secret code, no form. And now came the real test of the day: the platform has to recognise that as a correction by itself. Not me marking it as a correction. It has to derive from what happened that a human corrected the machine here.
The hunt: nine bugs in one day
On the way to that proof we found nine real bugs in one day. Not in the test, in the living system, each backed with real data, each fixed, each nailed down forever with a named test. Nine sounds like a bad day. It is the opposite. Nine bugs we find are nine bugs the first customer never sees.
The fault classes
This is the part I keep, because it comes back in every project, not only ours.
Receiver without producer. The evaluation exists, but nobody produces the signal. "Tests green" proves nothing when the source is missing. Since then we accept every feature that has leverage on both sides: who produces, and who receives.
Two truths. A preview promises something different from what the execution then does. A list shows what a filter has long since discarded. Cure: a single server-side logic for display and decision. Never two.
Silence. A process that gives up wordlessly on errors. A source that silently drops out of rotation. A tool that reports failure as empty success. With us that is the silence ban: every component reports "I am alive and doing X", or it counts as broken.
Invented test data. An agent did not find delivered real data and cobbled together similar ones. The tests went green, and would have hidden the actual finding, a time window that was too short, forever. Since then a law: if the real fixture is missing, the result is an error message. Never a substitute.
Two clocks. Two event sources with their own sequence numbers. Sort by number instead of by time, and the effect happens before the cause. Chronology is a decision, and you have to make it the same way everywhere.
The retroactivity illusion. Captured raw data is sacred. A fix in the capture does not repair the past. Whoever reinterprets old events more cleverly afterwards has to do it conservatively: in doubt, no signal.
The moments in between
What is in no ticket but makes the day. The decision to wait for a fix instead of taking the workaround, with the sentence: then we have tested that one too, clean. The question of how long a hand edit may come after the agent's work and still count as a correction, and the realisation that this is not a technical decision but a product decision. We said: one working day. And the ratio that occupied me most in the evening: one typed sentence from a human, and from it four training signals.
The finale: one sentence, four signals
In the evening the platform derived by itself, from what had happened over the day, what had happened. From the typed "stop, this approach is wrong", from a green test run after it and from two commits by hand: rejected, improved, accepted, changed by human hand. Four signals. No form, no labelling tool, no manual step. Nobody marked anything. The correction simply happened, the way work happens, and the system recognised it as what it is.
What it is all for: the temporal training pipeline
So that it is clear why a day full of bug hunting matters so much: the four signals from the evening are not for the dashboard. They are food. I described in "Software is a film" and in the flip book piece that we want to train a small model on how a project moves over time, from the chain of state, action, result and next state, with real time gaps. That chain is exactly what the capture records. And the feedback layer, which in the morning was still a receiver without a producer, is the piece that turns the chain into a trajectory with truth: here the agent proposed something, here a human said no, here it was improved, here it was accepted, this much time lay in between.
That is why the fault classes above are no side issue. Two clocks ruin a trajectory, because the effect comes before the cause. Invented test data poison it, because a green test without real data enters a false truth. The retroactivity illusion is the reason old events are never reinterpreted afterwards: whoever feeds training with a retroactively smoothed past trains with the exam questions. Each of these laws protects the same thing in the end, the training data that falls off the work.
The state after three weeks: over twenty complete work trajectories from real sessions, a frozen, curated set of a good 14,000 training pairs, each with provenance on both sides, sessions that now rotate so that none runs 23 days in a row, and a share of unassignable events below seven percent. That is not a model yet. That is what has to come before the model and what most people skip: data you can trust, with time as part of the data. Only when that stands may the flip book compete against the current chart, and both against the baseline.
The numbers nobody sees
A few of them, rounded, all from our own measurements, because with us every piece of work carries its cost report. A perfectly normal task, "add unit tests": twenty prompts, around a hundred thousand tokens. Measured, not estimated. A single agent working context: over two million tokens of input, almost all of it from the cache. That is the reality of agentic work nobody sees, and the reason I wrote about context in the MCP article.
In three weeks around 125,000 semantic events captured from real development work, not a single one produced by hand. One single uncut session: 23 days, over a thousand events, the reason we now rotate sessions. In one night over 31,000 duplicates removed deterministically, then a frozen state with a good 14,000 verified training pairs, each with provenance on both sides. A heap dump of just under two gigabytes that revealed a memory leak, found because we read dumps instead of restarting services. Three times the process killed hard, three times restart and first upload after about a minute, zero manual steps. A backup emergency rehearsed: all database collections back, every checksum identical.
And the frame around it: around 2,300 classes of platform code, plus over 500 test classes, almost 1,500 test methods, around 3,400 tests that have to be green before every commit. Over 500 commits on the leading branch, more than 140 of them since the beginning of October alone, every single one on explicit go, none by an agent on its own. By now over forty tools through which agents talk to the platform, and a catalogue of around 55 event types where the unknown lands in quarantine, never in the bin. Around 85 numbered findings in three weeks, each in the living system, each with a named test.
What stays
None of this is a feature. You cannot put it on a slide, and on a dashboard a day with nine bugs looks bad. But that is exactly what I sell when I sell NeoCoder: not that the agents make no mistakes. That we find them before the customer does, that every fault becomes a law, and that a human's correction is not lost but makes the next model better. This discipline is the product.
A measurement run with red numbers, a test with a short sentence, an agent with a circular argument, nine bugs, six fault classes, and in the evening a typed sentence from which the platform made four training signals by itself. That was the day. Not spectacular. But honest, and honest is the only thing that carries over years.
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.