Every bug report ever written was a memory test. Something broke, and a person had to reconstruct, after the fact, what they clicked, what the screen said, and what they had tried in the ten minutes before it went wrong. They write down the best version they can remember. Then an engineer reads it and starts the real work, which is not fixing the bug. It is trying to make the bug happen again.
That is where engineering time actually dies. Not in the repair, in the reproduction. And the reports that never get written at all are worse: the awkward extra step, the thing that took four tries instead of one, the button that is in the wrong place. Filing those costs more effort than living with them, so nobody files them, and the product team never hears about the paper cuts that quietly drive people away.
The best witness to a software failure is not the person who saw it. It is the software that was doing the work.
The witness was already in the room
Something changes when the place work happens is an AI teammate instead of a set of screens. In Soarcery that teammate is the Familiar, the agent you ask for an outcome in plain English. It shows you a plan, you approve it, and then it builds and casts the Spell, the saved automation that does the work across your stack.
Which means that when something fails, the Familiar is not a bystander taking notes afterward. It is the participant with the complete account. It does not have to remember the incident. It wrote down what it did while it was doing it, because writing down what it did is how it works in the first place.
Once you accept that, a bug report stops being a document a human composes and becomes a record the software hands over. And once the report is that good, the thing that reads it does not have to be a human either.
Loop engineering
We have started calling this loop engineering, because the unit of product development stops being the feature and becomes the loop.
A loop is the whole path from a person getting stuck to the fix reaching them: detect, try to heal, offer, consent, file with the record, review, build, approve, ship, credit back. You do not improve a loop by adding features to it. You improve it by making each hop faster and more honest than it was last month, and by refusing to remove the gates that make the speed safe. Humans design the loop and hold its review gates. AI runs the body of it.
Our loop, hop by hop
It tries to fix itself first. Before anything gets reported, the Familiar attempts to resolve its own problem: retry, take a different route, or walk you through the repair when the fix is on your side. Whatever it can heal never becomes a ticket. That matters more than it sounds, because it means the reports that do get filed are the ones that genuinely need engineering.
It offers to report what it cannot heal. When it is truly stuck, it says so in the conversation and offers to file the report. You can also just tell it to report something at any moment, including the things that are not broken so much as annoying.
It classifies the report itself. Bug, missing feature, or improvement. That triage is normally somebody's Tuesday.
Nothing is filed without one yes. It shows you exactly what it will file: the classification, the summary in plain language, and the record it will attach. You confirm once. Secrets and credentials are stripped before anything leaves. One yes, and nothing behind your back.
The report carries the complete record. Not a description of what happened, the record of it: the conversation, the actions the Familiar took, the results it got back, in a form another machine can read.
A person reads every report each morning, and an AI builds the fix. The engineering agent works from the record instead of from a memory, and a human approves the change before it ships. The loop is built to turn most reports into shipped fixes in about a day, and we measure ourselves against that target daily. It is a target, not a track record. The program is young, and we would rather tell you what we are building toward than quote you a number we have not earned yet.
The credit goes back to the reporter. When the fix ships, the update that carries it names you, if you want the credit. Consent runs both directions in this loop.
What the record cannot do
This is the part that decides whether any of the above is worth believing, so here is the honest shape of it.
The record buys diagnosis, not teleportation. It is a complete account of what our software did and saw, not a copy of your environment, your data, and your timing. It is built so an engineer can usually work the problem without going back to the reporter with questions. That is a very different claim from reproducing your world on our machines, and we are not making the second one.
A recorder cannot record its own failures. If the layer that captures the record is the thing that broke, the record is the last place you should look for what went wrong. So a report path that does not depend on any of this always exists: a plain form, reachable when the clever machinery is the problem.
And the volume can be tuned. How often the Familiar offers to file a report is a threshold we set, which means report counts describe how the loop is behaving, not how well we are doing. We read them as a signal, never as a score. Any number a system computes about its own performance needs an audit standing next to it.
We run under the same law we sell
There is a strategy underneath this, and it is not really about bug reports.
We run our own development under the same law the product enforces: the AI investigates, builds, and proposes; a fixed policy decides what needs a person; a person seals anything that touches production. In the product, that gate is the Seal, the approval where a named human signs off and the decision leaves a receipt. It is a fixed safety policy that sits outside the AI, not an instruction inside it, which is the whole reason a model cannot talk its way past it.
The set of things we refuse to let the AI touch is the product's thesis demonstrated on ourselves.
A vendor that would let an agent ship to production unsupervised has told you exactly how much it believes in its own guardrails. We hold the same two gates on our own work that we ask you to hold on yours: a human reads the report, and a human approves the change. Everything between those two gates can move as fast as the machines can move it. Nothing crosses either gate without a person.
Development becomes interactive
Run this loop for a while and the relationship inverts. People stop being ticket writers and start being contributors, without doing any of the work that used to make contribution expensive. Getting stuck becomes a five second act: you say report this, you read the summary, you say yes. The friction that kept the small stuff invisible is gone, so the small stuff finally gets fixed.
The version of the product you use next month is shaped by the moments you got stuck in this month, and none of that required you to write a bug report. That is what we mean by loop engineering. Software stops being something that arrives finished and becomes something you are quietly, effortlessly building with us.
The loop runs today inside our design-partner program. See it live at Black Hat USA, August 4 to 6 in Las Vegas: request a demo, tell us you will be there, and we will find somewhere quieter than the floor.