IBM Bob moves engineering work faster. IBM cites research showing that speed relocated the bottleneck to review and validation. This is an assessment of what fills it.
IBM Bob is an agentic development environment that plans, writes and modernises code, with claimed delivery gains of 20–40% faster and 50–80% less effort. Those gains are real and they create a second problem, which IBM states in the same announcement.
85% of DevSecOps professionals surveyed agree that AI has shifted the bottleneck from writing code to reviewing and validating it. GitLab 2026 AI Accountability Report, cited by IBM Newsroom, 9 July 2026
Bob ships gates for that shift, and they are process gates: approval checkpoints, policy enforcement, sensitive-data scanning, red-teaming, an ambiguity check on specifications. They govern how work proceeds. None of them measures the condition of the artifact that comes out.
maintainability-agent is a deterministic product gate. Same tree in, same number out, every time — which is the property that lets a build fail on it. It scores against a reference corpus of 180 repositories across 13 languages, withholds a grade when the evidence cannot support one, and states what examined every value. It is a local process, not a service.
The two do not overlap. Bob produces; MA verifies what was produced. And the integration path exists today: Bob supports MCP, and MA ships an MCP server.
Stated fairly, because the argument is weaker if it is unfair. Bob is a substantial platform and is ahead of MA on every axis below.
Three states, kept distinct on purpose. Not documented is not a claim that a capability is absent — only that IBM's public documentation does not describe it. Anyone presenting this should say so plainly.
| Capability | IBM Bob | maintainability-agent | Why it matters |
|---|---|---|---|
| Generates and modernises code | Yes | No, by design | MA never writes code. It produces a bounded remediation prompt for an agent that does. |
| Reproducible run-to-run result | Not documented | Yes — published promise P1 | A build cannot fail on a judgment that changes between runs. |
| Calibrated numeric score | Not documented | 180 repos, 13 languages | A score means nothing without a reference population you can inspect. |
| Withholds a grade on thin evidence | Not documented | Yes — ADR 005 | The failure mode of every quality tool is scoring well because it looked at little. |
| States what measured each value | Not documented | Yes — promise P8 | Which analysers ran, which did not, and what nothing measured at all. |
| Process gates: approvals, policy, red-team | Yes | No | Bob's territory. MA has no view on who may approve what. |
| Compliance mapping (SOX, PCI, HIPAA) | Yes | No | Bob's territory entirely. |
| Security analysis | Yes | Delegated, with a contract | MA declares security out of scope and reports a sibling tool's measurement rather than guessing. |
| Runs with no server or cloud account | Metered platform | Local stdio process | Matters for air-gapped estates and for cost at scale. |
| Records why a finding was declined | Not documented | Yes | A backlog closed by judgment is only credible if the judgment is written down. |
Not "does better" — cannot, as a property of what a language model is.
Same tree, same config, same pinned analyser versions → the same evidence, findings and score. An LLM reviewer is not reproducible, so it can advise but it cannot be the thing that fails a build.
The scale is fitted to 180 mature repositories pinned to exact commits across 13 languages. The constants are re-derivable offline from checked-in inputs, so nobody takes them on faith.
When the evidence cannot support a grade, none is issued — never a dash, never a zero, both of which read as a result. A shallow clone of a real project drops the grade entirely and says why.
Which analysers ran, which were not applicable, which concepts nothing measured. Silence is reported as silence. A clean section with nothing behind it is the defect this design exists to prevent.
A gate proves each newly cited test fails at the base commit. A fix whose proof passes before the fix is not a proof, and the build says so.
Practice level (is anything enforced?) and condition (what did the scanners find?) are reported side by side and never averaged. Their combination is the finding — a clean scan with no enforcement is unverified, not healthy.
Bob's 20–40% acceleration lands upstream of review. The survey IBM cites puts 85% of DevSecOps professionals on the other side of that shift. Adding review capacity to match generation capacity is the obvious answer and the wrong one; the affordable answer is a check that runs in seconds and does not get tired. MA audits a 722-file project in 12 seconds and a Go CLI in 2.
Bob's gates ask may this proceed. MA asks what is the condition of what came out. A team can have every approval in place and still ship a module nothing tests; a team can have perfect metrics and no change control. Both are needed and neither substitutes.
Bobalytics answers what the AI consumed. It cannot answer whether the codebase got better. For an engineering organisation reporting on code health, the second question is the one leadership asks and the one that currently has no number attached.
The uncomfortable question about agentic development — how do we know the volume it produces is any good? — cannot be answered by another agent, because the answer would carry the same non-determinism as the thing under review. It needs an instrument. That is the entire argument in one sentence.
Bob uses external tools through MCP. MA ships an MCP server as its primary surface. A Bob user adds it as a tool and audits from inside the IDE — no pipeline change, no new platform. The CLI is there for the build.
MA has a COBOL scanner — PROCEDURE DIVISION paragraphs, fixed-form card columns — which matters directly to Bob's IBM i and Z audience. It also reports that COBOL is outside its reference corpus, permanently, with the evidence: GitHub holds one COBOL repository above 500 stars, and what is public is curriculum and Java parsers rather than COBOL codebases. Findings hold; the grade is marked provisional. That disclosure is the product working.
Absence from documentation is not absence from the product. Every "not documented" cell above means IBM's public materials do not describe the capability. Bob may do these things. If someone in the room knows otherwise, they are right and this table is out of date.
MA is much smaller. It does one thing. It does not generate, modernise, orchestrate, or handle compliance. It has no enterprise support organisation behind it. Against Bob's scope it is an instrument, not a platform — which is the point, but it should not be oversold as anything more.
The measured numbers are from one repository. The evidence below comes from MA auditing itself and five public projects. That is honest sampling, not a benchmark study.
Every figure here was measured, not estimated. All are reproducible from the checked-in repository.
Five public projects, none in the corpus, none previously scanned — audited with the analyser pool, full history:
| Project | Languages | Time | Grade | Estimate | Files |
|---|---|---|---|---|---|
| tiangolo/typer | JS + Python | 12s | B | 4.4 | 722 |
| spf13/cobra | Go | 2s | B | 4.2 | 53 |
| encode/httpx | Python | 5s | C | 4.2 | 91 |
| BurntSushi/ripgrep | Rust + Ruby | 3s | C | 3.7 | 134 |
| pallets/jinja | Python | 6s | D | 4.0 | 70 |
Jinja scores D at an estimate of 4.0 while ripgrep scores C at 3.7, because the grade is computed on the evidence floor rather than the point estimate. That is the tool refusing to credit what it did not measure — and it is the most useful thing on this page for explaining what a quality number is and is not.