THE PREVIOUS LOOP AND THE CURRENT ONE
The traditional debugging loop: read the error, search it, review a series of adjacent-but-not-identical cases, form a hypothesis, instrument the code, repeat. The expense was never in typing the fix — it was in testing hypotheses sequentially, one at a time.
The current loop: present the agent with the symptom and access to the actual codebase, and it forms and tests multiple hypotheses concurrently — reading files, tracing data flow, executing checks. What returns is typically not a suggestion but a located cause with its supporting evidence. Sessions that consumed an evening now frequently resolve in minutes.
WHERE THE GAIN IS LARGEST
- Cross-layer failures. Defects that live between layers — an interface expecting a shape the API no longer returns, a database policy contradicting application logic. A person debugs one layer at a time; the agent reads the entire path at once. The row-level security case in BN — 003 was precisely this class.
- Unfamiliar territory. A failure deep inside a less-familiar framework once meant an hour in documentation. The model's breadth now covers the unfamiliarity; human depth is reserved for the decision.
- Silent failures. Nothing crashes; the results are simply wrong. Historically the most expensive class, because there is no error to search. An agent that can instrument code and compare expected against actual behavior compresses these the most.
WHERE IT CONTINUES TO FALL SHORT
Three failure modes recur consistently:
- The model does not know what "correct" means for the business. It can observe that the code returns X, and even flag X as suspicious. It cannot know that the practitioner was meant to see every client while each client sees only themselves. Every defect is a gap between behavior and intent — and only one side of that gap exists in the repository.
- Incorrect fixes arrive with the same confidence as correct ones. When the first hypothesis is wrong, the proposed remedy is delivered with undiminished certainty. Accepting fixes that cannot be explained is not debugging; it is deferring the failure to a worse moment.
- Symptoms get patched where designs need correcting. The model repairs the point of pain. In some cases the honest resolution is that the data model is wrong and this defect is the third one it has produced. Recognizing a defect as a design signal still requires someone who has watched the system evolve.
The standing rule this produced: AI locates; engineering verifies. No fix ships without an explanation of why it is correct — not as principle, but because unexplained fixes return, and rarely at a convenient time.
WHAT THIS MEANS FOR CLIENT SYSTEMS
The visible benefit is speed — production issues in client systems are located in minutes rather than evenings, which matters when a real business depends on the platform. The deeper consequence is what becomes economical to build at all. When diagnosis is inexpensive, proper systems — real databases, real authentication, real infrastructure — become viable for businesses that previously had access only to assembled no-code tooling. The debugging workflow is not an engineering convenience. It is part of why custom infrastructure became affordable.
The tools expanded. The judgment did not move. That remains the operating model.
Related: BN — 003 documents one of these sessions in full. If you operate a system that misbehaves and lacks anyone who can explain why, that is a conversation worth having.