Migration Background
According to a case study published on the Dameng database forum, FM-Agent analyzed 163 functions in two hours for $10.39, with 31 reported defects manually confirmed as real bugs.
This article is adapted from the original Dameng forum post. Evaluation figures and effort estimates below are reported by the case-study authors.
Many telecom, government, and transport applications use Sybase CT-Library. Migrating them to Dameng can mean replacing calls spread across hundreds of source files, or implementing a compatibility driver over Dameng DPI so applications can keep their existing API calls and switch the linked library.
Application → ct_* → compatibility driver → DPI → DamengThe team chose the compatibility layer. Implementing interfaces against official manuals offers clear specifications, but AI-generated implementations still need careful verification.
The Verification Bottleneck
The driver contains tens of thousands of lines of C across the CS, CT, and BLK APIs, including type encoding, LOB streaming, and bulk protocols. Passing a simple example does not establish production reliability.
Compatibility bugs may silently store incorrect data while returning success, or fail only on a second invocation. Across 163 functions, execution paths, type mappings, and call-order state machines yield thousands of potential tests. Some failures require five conditions to coincide; test construction, diagnosis, fixes, and regression can take days per cycle.
The authors estimate that manually reaching 90% unit-test coverage would take one to two person-months. This estimate describes the testing effort, not a claim that automated analysis proves every function correct.
Specifications and Reasoning
FM-Agent follows the idea of the Hoare triple {P} C {Q}: describe preconditions and postconditions, then reason about whether the implementation satisfies them. Specifications state what callers need, not how the implementation should achieve it.
For dm_stamp_to_time, the input is a populated timestamp and an output buffer large enough for CS_TIME. The specification requires:
- Integer conversion of hours, minutes, seconds, and subseconds into ticks, discarding any remainder without rounding up.
- Success only for valid hour, minute, and second ranges (0–23, 0–59, and 0–59); on failure, the output is not trustworthy.
- Identical outputs for identical inputs.
- No allocation, retained pointers, or diagnostic side effects.
Unlike a vague requirement to “handle timestamps correctly,” these conditions can be checked with concrete inputs. FM-Agent generates specifications from documentation and code, reasons about implementation behavior, and diagnoses defect locations and root causes.
Reported Results
Using the DeepSeek Flash model, the run covered 21 files, 163 functions, and 10 modules. It identified 181 points of concern and reported 98 defects; 31 had been manually confirmed. The reported duration was two hours and the cost was $10.39.
The confirmed bugs cover memory safety (including heap writes after 32-bit multiplication overflow), data correctness (stale caches and silent truncation), observability (successful return codes despite incorrect data), and resource lifetimes (partial initialization and handle leaks).
The case study describes detailed defect reports and executable reproduction tests, giving developers concrete failures to investigate and repair.
Engineering Takeaways
The workflow combines compatibility interfaces defined from official documentation, AI-generated implementations, and FM-Agent verification. For this team, it turned unknown risks into an actionable defect list and helped address the verification bottleneck as code generation accelerated.