The Coder added a new function to an existing file. The pipeline told me it succeeded. All the existing functions in that file were gone.
No error, no warning, no exception in the pipeline output. The pipeline wrote the file, ran the tests, and 48 tests failed with _reset is not a function. The file that used to export seven functions now contained one.
What happened
The pipeline has a reconstruction step. When the Coder targets a specific function in an existing file, the pipeline looks up that function’s location in the registry, splices in the new version, and leaves everything else untouched. This has worked reliably on every ticket that modified existing functions.
The bug appeared when the Coder added a new function. The reconstruction logic assumed every symbol already existed in the registry. When it did not find one, it fell back to writing the Coder’s raw output as the entire file. Everything else was overwritten.
The fix was adding fallback logic so the reconstruction step handles new symbols, not just existing ones. If the registry has no record of the symbol, the pipeline now finds the right insertion point rather than replacing the entire file.
Why this class of bug matters
This is the scariest category of failure in agentic systems: silent data destruction. The pipeline reported success. The file was written. If the test suite had not caught it, the commit would have gone through with a destroyed module.
The test suite caught it because the destroyed functions were imported by other test files. If the destroyed code had no tests, the damage would have been invisible until someone opened the file.
Every write path in an agentic pipeline needs to be tested against the “symbol does not exist yet” case. The happy path (modify existing code) works. The edge case (add new code to an existing file) is where data gets destroyed.
The bug existed because the reconstruction path was only tested with existing symbols. Adding new symbols to existing files was a case nobody had written a test for, because every previous ticket either created new files or modified existing functions.
Numbers are from real runs against a TypeScript blog API fixture. The pipeline runs inside Docker with no human in the loop between ticket input and reviewed, committed code.