
Renaming a database column or changing a field's type sounds simple. In a real system it is one of the riskiest changes a team makes. Search tools like grep miss places that use the name indirectly, and they flag unrelated fields that happen to share the name. Type checkers only check the code you touched, not SQL, docs or config. So teams either put off the change or ship it and find out in production what broke. SystemDNA solves this in five steps: 1. Map. It connects to a Git repository and builds a knowledge graph of every part of the system: database tables and columns, types, fields, functions, API routes, components, pages, tests, docs and business use. The links come from the TypeScript compiler's "find all references", not text search. That means it can tell apart two fields with the same name. 2. Predict. You pick a change: rename, change a type, change a function signature, delete, or describe it in plain words. SystemDNA shows the ripple: what breaks, how badly, in what order, which business process is affected, and a risk score. It also shows which files grep would miss and which false alarms it would raise. 3. Fix. IBM Bob Shell runs as one Fixer agent per affected file, wave by wave, in dependency order. Each agent has a permit for its own file only. Edits outside the permit are reverted and shown as blocked. Every edit is type-checked. A failing edit gets one retry, then it is rolled back. For database changes, Bob writes a new migration. The Bob Inspector reviews the final diff, and the Bob Cartographer finds links the parser cannot see. 4. Govern and watch. Protected layers wait for a person to approve. Each run has a spending limit. The Agent City view shows every agent working live. 5. Prove. The result is one draft pull request built from exactly the diff you previewed, plus an impact report and an audit trail. SystemDNA is for engineering teams with large codebases, for platform and data teams making schema changes, and for tech leads who review risky refactors.
27 Sep 2026