ControlTheory CTO Eric Anderson describes a production chat failure investigated with Dstl8 and passed to Claude Code. His written answers explain what evidence the coding agent received, why closing an incident does not prove an automated repair, and which decisions remain with the engineering team. The account provides a concrete workflow, but not an independently verified repair or a measured improvement in recovery time.
Authentication succeeded, but starting a chat could still fail. On September 25, ControlTheory's own production system was intermittently rejecting chat-session requests because some connections lacked a newly required user identifier.
The failure illustrates a practical problem for teams using coding agents: access to the repository does not necessarily explain what is happening in the running application. The agent also needs evidence of the failed request, the conditions around it and the places worth investigating.
In written answers to Let's Data Science, Eric Anderson, CTO of ControlTheory, describes how the company's Dstl8 platform assembled that evidence and made it available to Claude Code. His account follows ControlTheory's September 22 launch of Dstl8, which connects information from running systems with engineers and their coding tools.
The useful distinction throughout the interview is between finding evidence, making a change and establishing that the change repaired the service. Those are separate steps, even when a product presents them within one incident workflow.
The missing field behind the chat failure
Anderson says Dstl8 detected the issue at approximately 10:45 a.m. Central Time on September 25. This was an incident in ControlTheory's own production environment, which the company monitors with Dstl8, rather than an outside customer's deployment.
Anderson told LDS: "Authentication was working OK, but a new required field was now missing in some calls (but not all), which would cause sporadic and occasional problems for some users."
The supplied incident description identifies a missing user_id in some authenticated WebSocket connection claims. WebSockets keep a connection open between a client and a server. Here, the subsequent call to create a chat session reached an upstream API that required the identifier and returned HTTP 400 when it was absent.
Two supplied log excerpts make the diagnosis concrete: one records successful authentication without a user ID in the claims; another records a failed session-creation request because the field was required. Dstl8 also identified code locations to inspect and suggested checking the connection handling, the upstream endpoint's requirements and whether the problem affected other organizations.
These are useful investigative leads. The log excerpts support the description of the failure; by themselves, they do not establish which code change ultimately corrected it.
What Claude Code received
Anderson describes an incident record containing a summary, a fuller explanation, code references, evidence and suggested actions. Related patterns, anomalies and deployment events can add context. Engineers can inspect it in the interface, copy a formatted account for an agent, or make it accessible through the Model Context Protocol, or MCP, which lets an AI tool work with connected data and services.
In this case, Anderson says Claude Code used the incident information after being asked to investigate.
"So in this case, the human only needed to ask Claude to look, and the incident provided a clear enough picture for Claude to resolve the issue."
That is ControlTheory's account of the outcome. The interview package includes incident details and screenshots, but does not provide the resulting patch, deployment record or before-and-after test results. LDS has not reproduced the repair. The material therefore illustrates the handoff from production evidence to a coding agent, rather than proving a recovery-time improvement or unattended production remediation.
What the 328-incident figure actually measures
The launch announcement reports 328 incidents across 13 Kubernetes clusters at an early fintech customer over two months. LDS asked what resolution meant and how much of the work was performed by people or agents.
Anderson's answer makes an important distinction: Dstl8 can close an incident when the symptoms disappear. That could follow a human's code change, an external API ceasing to return errors, or infrastructure recovering without a new application patch.
He says about 70% of the reported incidents were closed from Dstl8 and about 5% were marked as duplicates. Other records had no reason supplied, were marked fixed or were marked as not an issue. The response does not supply a complete breakdown linking those categories to verified repairs by humans or coding agents.
The figures describe incident handling, not an autonomous code-fixing rate. A disappearing symptom can justify closing a record without showing that its underlying cause has been permanently removed. Teams evaluating this workflow should keep detection, diagnosis, approved change, service recovery and later recurrence as separate measurements.
More context can help, but diagnosis quality still needs testing
Anderson says multiple agents investigate and triage issues, followed by a validation stage that checks the evidence and other factors. He gives an example of an ambiguity the system must handle: a service with a single running replica may briefly become unavailable during deployment. Errors from services calling it can resemble a separate failure.
Deployment events and known operating behavior can help interpret that window. They do not, on their own, prove that a particular deployment caused every nearby error.
The answers do not include measured false-alarm rates, missed-incident rates, diagnosis accuracy or a controlled comparison with an existing monitoring setup. Those remain evaluation questions for a pilot, rather than demonstrated advantages of the product.
Where the data goes and who can change the code
According to Anderson, Dstl8 reduces telemetry at the collection point, retaining patterns and evidence used in incident investigation. It scrubs some sensitive data and runs its own fine-tuned model within ControlTheory's cloud infrastructure. Engineers can explore the associated evidence through the interface or MCP.
That description should not be read as a guarantee that all information stays within the customer's infrastructure or that every sensitive field is removed. Anderson also says customers can pass Dstl8 context to external model providers through their chosen coding agents.
The coding agent's authority is a separate decision:
"Because the coding agent lives entirely within the customer’s control and environment, it is completely up to them what level of control they provide."
Anderson says Dstl8's own agents cannot modify the customer's code. A connected coding agent may have different permissions. For an engineering team, the practical checks are which evidence it can read, which repository or environment it can modify, who approves deployment and how a failed change is reversed. Supplying a diagnosis does not settle those controls.
A pilot should prove recovery, not just produce a plausible explanation
For LDS readers considering this approach, a useful evaluation would start in a controlled staging environment with a known, recoverable failure and preserved original evidence. A missing required field, similar to Anderson's example, is one possible test. This is an LDS recommendation, not a test performed for this article.
- •Record what the existing tools reveal, then check whether the new workflow detects the issue and identifies the correct cause.
- •Inspect the evidence behind the diagnosis and include a case where similar symptoms have a different cause.
- •Review the proposed patch, reproduce the failed request, test the corrected behavior and check for regressions before approving a rollout.
- •Measure engineer effort, time to a verified recovery, incorrect diagnoses, repeat incidents and the total cost of the workflow.
ControlTheory's current pricing page lists Pro at $50 per month and Scale at $250 per month, with Enterprise priced separately. It identifies Pro as bring-your-own-model, while Scale and Enterprise use the hosted model. That distinction matters when interpreting the interview's broad statement about no additional model or token costs. Teams should confirm the applicable plan, included resources and any separate coding-agent or model-provider charges before budgeting.
The interview's strongest contribution is a specific account of the information an agent needs when code meets a running system. The test for a team adopting it is equally specific: can that information lead to a correct, reviewed change whose effect is demonstrated in the service?
Reporting note
This LDS Exclusive is based on six written answers from Eric Anderson, supplied through ControlTheory's communications representative, together with the company's launch announcement and current product information. The production incident and customer figures are company-reported. LDS did not access the production systems, reproduce the repair or independently audit the incident totals. The pilot checks above are editorial recommendations.
Key Points #
- 1ControlTheory describes a real failure in its own production chat service: authentication succeeded, but some session requests lacked a required user identifier.
- 2The supplied incident evidence was passed to Claude Code. The company reports a repair, but has not supplied the patch or tests needed to verify that outcome independently.
- 3Automatic incident closure can follow a human fix or the disappearance of symptoms. It is not an autonomous code-repair rate; deployment permissions and validation remain separate responsibilities.
Scoring Rationale #
A named original interview provides a concrete production-evidence workflow and explains incident-closure limits, data handling and practical evaluation criteria. No independent performance improvement is established.
Sources #
Original reporting, with the public references used alongside it.
LDS Exclusive
Reporting based on written answers given directly to Let's Data Science by Eric Anderson, CTO of ControlTheory.
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.