There's a pitch that's easy to reach for and mostly false: "after six months, this tool knows your codebase better than a new hire." It sounds good. Sales likes it. And it's the kind of claim that's almost impossible to disprove in a demo, which is exactly why we made ourselves prove it before saying it.
The honest version turned out to be more interesting than the inflated one. TrueMend's actual strength is day one, not month six. On the first run, with zero history, it already knows things a new engineer won't know for months: every call path, every duplicate cluster, every orphaned file, every place the project's own structure disagrees with itself. That doesn't get better with age because it was never age-dependent. A project graph built from scratch on run one thousand looks the same as run one.
The rule we hold ourselves to: don't describe accumulation the engine doesn't act on. A written log is not memory. If nothing reads it back to change a decision, saying the product "learns" is a green-looking lie.
What actually accumulates, and what doesn't
Most of what TrueMend writes to disk across runs is exactly that, a log. A progression file, a trend file, a commit tracker. Useful for a human to look at, read by nothing downstream. We don't get to call that memory just because it grows.
Two things are different, and they're honestly the more interesting story because they come with real, measured limits instead of a vague "it learns" claim.
A recorded verdict. Mark a finding "won't fix" once, and it's suppressed from every future audit, matched by the shape of the code rather than a line number, so it survives a harmless edit nearby. But we measured how well that survives real edits, and published the number instead of rounding it up:
Roughly half the time, an edit near a suppressed finding means the system asks the human again. That's not a bug we're hiding, it's a deliberate tradeoff: the matcher refuses to bind to a "probably the same finding" guess, because silently losing a verdict costs one re-confirmation, but silently misattributing one hides a real problem forever. We'd rather ask twice than hide once.
Reopen history. If a fixed finding comes back, that fact changes which issue gets surfaced first the next time someone asks "what should I work on." It does not change the finding's severity, does not remove it from an audit, and does not touch the score. It's a tiebreaker, worth exactly one flat point, that only flips the order between two findings already within a point of each other. A reopened finding at a low score doesn't leapfrog a serious one sitting at a high score. We tested that boundary directly and it's pinned by a test named exactly what it checks.
// the claim we didn't make
"TrueMend learns your codebase over time and gets smarter with every run."
// what we say instead
"On day one, TrueMend knows things about your codebase that no
new engineer will know for months."
"Waive a finding once and TrueMend remembers the decision
across edits, so your team isn't asked the same question twice."
Notice the second version doesn't need a qualifier. It's true today, it was true on the day it shipped, and it doesn't imply a growth curve the product doesn't have. That's the actual bar: not "is this impressive," but "is this still true if someone reads the source code right after reading the sentence."
Why bother writing this down at all
Because the temptation compounds. Once you've shipped one small accumulating feature, the next paragraph writes itself: "and naturally, this gets even better over time." It's the path of least resistance in a product doc, and it's exactly how green-looking lies get into a sales deck one reasonable-sounding sentence at a time. We keep a standing document whose entire job is holding that line, re-verified against the actual code, with the grep commands included, so the claim doesn't drift the next time someone's writing copy under a deadline.