Back to Blog
· Kevin

IBM Bob did a 30-day Java upgrade in 3 days. Now the database is the bottleneck.

IBM's new SDLC agent compressed a typical month-long Java migration into three days. When agents ship code 10x faster, the database-to-API layer becomes the slowest part of the stack — and most teams haven't noticed yet.

ai-agentsibm-bobsdlcdatabaserest-apideveloper-productivity

On April 28, IBM rolled out global availability of Bob, its “AI-first development partner” that runs across the full software development lifecycle. Persona-based agents, multi-model orchestration, reusable playbooks, governance baked in. The press release leans on a specific number: a Java upgrade that normally takes a developer 30 days finished in 3, saving 160+ engineering hours.

That number is the story. Not because IBM did it — Cursor, Cognition, GitHub Copilot Workspace, and a half-dozen others have demoed similar compressions over the last six months. The story is that 10x compression of the coding phase is now table stakes for any enterprise SDLC pitch. The bottleneck is moving.

If your agent can write a working Spring upgrade in a weekend, what does it spend the rest of the week waiting on?

In our experience: the database-to-API layer.

The compression curve and the part that hasn’t moved

Software delivery used to look like this:

  • Plan: 1 week
  • Code: 4 weeks
  • Test: 1 week
  • Deploy: 1 week
  • Integrate with backend services and data: 2 weeks

Total: 9 weeks. Coding was the long pole.

In 2026, the curve has inverted. IBM’s claim — and similar numbers from Anthropic’s 2026 Agentic Coding Trends Report — puts coding compression at 5x to 10x for well-scoped tasks. Cursor 3, launched April 2, can run an entire agent loop in a sandboxed cloud workspace and hand the result back to the developer. Windsurf SWE-1.5 runs at 950 tokens/sec on Cerebras. Code is no longer the long pole.

What hasn’t moved:

  • Spinning up a REST endpoint that exposes a new table to the agent
  • Adding row-level RBAC so the agent can’t see PII
  • Exposing the same endpoint as an MCP tool so a different agent can call it
  • Documenting the whole thing as OpenAPI so the next agent can discover it
  • Making sure the connection pool doesn’t melt when the agent decides to make 80 parallel calls

These are the steps that used to take a backend engineer two days and now still take two days, because they involve writing handlers, configuring middleware, defining roles, generating specs, and tuning a connection pool. None of that has been compressed by Cursor or Bob, because none of it is the coding part of coding.

The 30-to-3 day compression is real. It just compressed the part that wasn’t the bottleneck for most teams to begin with.

What an enterprise Java upgrade actually involves

Take IBM’s specific example. A “Java upgrade” in an enterprise context isn’t mvn versions:set -DnewVersion=21. It’s:

  1. Bumping the JVM and Spring Boot major versions
  2. Patching deprecated APIs
  3. Re-running the test suite
  4. Re-validating every database call (driver compatibility, JDBC behavior changes, connection pool defaults)
  5. Re-exposing whatever changed to downstream services
  6. Updating the OpenAPI spec your platform team uses to register services in their gateway
  7. Re-running integration tests against the new contract

Bob can plausibly do steps 1-3 autonomously. It can probably do step 4 if you give it shell access to a staging DB. It can attempt step 5 by editing handler code. Steps 6 and 7 — the parts where the contract between the service and the rest of the org changes — are where humans currently get pulled back in.

The compression is real for steps 1-3. The drag is in 5-7.

Why the data layer doesn’t compress the same way

There’s a structural reason coding compresses well and database-to-API work doesn’t.

Coding tasks have closed feedback loops: write code, run tests, iterate. The compiler tells the truth. The test suite tells the truth. An agent can grind on the loop until the loop is green.

Database-to-API work has open feedback loops:

  • Did the new endpoint preserve the previous response shape? (Only your downstream consumers know.)
  • Are the RBAC rules tight enough? (Only a security review knows.)
  • Will the connection pool survive the agent’s call pattern? (Only production knows.)
  • Does the OpenAPI spec match what the handler actually returns? (Only the next consuming agent knows, and by then it’s already broken.)

The truthtellers are external to the agent loop. So the agent can’t grind to green. A human has to step in.

This is why every enterprise rollout of agentic coding tools eventually surfaces the same complaint: “the agents are great at writing code, but our integration team is now the bottleneck.” Salesforce’s Q1 internal survey, referenced in their April analysis, put the data/integration drag at 38% of total agent-driven project time, up from 22% a year prior. The agent got faster. The plumbing didn’t.

What “compressing the data layer” would actually look like

The compression pattern that worked for code — fast feedback loops, deterministic checks, automated iteration — has to work for the data layer too. That means:

  1. Schema → API has to be a build step, not a quarter-long project. If the agent adds a customer_segments table, the REST endpoint and OpenAPI spec should exist by the time the migration finishes running.
  2. RBAC has to be a config file the agent can read. Not a 12-week IAM project.
  3. MCP tooling has to come from the same source of truth as REST. Two agent surfaces, one definition.
  4. Connection pooling has to default to safe values. Agents will absolutely make 80 parallel calls. The framework should expect that.
  5. OpenAPI has to be auto-generated from the live schema. Manual spec-writing is the single biggest source of agent-side hallucinations in enterprise environments.

This is what we’re trying to do with Faucet. Point it at any database (Postgres, MySQL, SQL Server, Oracle, Snowflake, SQLite — single binary), and it generates REST endpoints, OpenAPI 3.1, and an MCP server in one shot. Schema changes propagate to the API on restart. RBAC lives in a SQLite config file. The connection pool defaults to 100 max / 25 idle, which won’t melt under a chatty agent.

What a “Bob + Faucet” run actually looks like

Here’s the rough shape of what we’d want the IBM-style pitch to look like once the data layer catches up. Concrete commands, not slides.

Agent finishes its Spring Boot 3.4 upgrade. New table added: customer_segments. Old table: legacy_customers retired.

# 1. Run the migration
$ flyway migrate

# 2. Restart Faucet — it picks up the schema change
$ faucet server restart
[INFO] Detected schema change: +customer_segments, -legacy_customers
[INFO] Regenerated 14 REST endpoints
[INFO] Regenerated OpenAPI 3.1 spec at /openapi.json
[INFO] Regenerated MCP tools (2 added, 1 removed)
[INFO] Server ready on :8080

That’s it for the API surface. The new table is a REST endpoint, an OpenAPI operation, and an MCP tool — all without an integration ticket.

To verify what’s exposed:

$ faucet api list --filter customer_segments
GET    /api/v1/customer_segments
GET    /api/v1/customer_segments/:id
POST   /api/v1/customer_segments
PATCH  /api/v1/customer_segments/:id
DELETE /api/v1/customer_segments/:id

$ faucet rbac grant role:agent-readonly --table customer_segments --ops read
[OK] Granted read on customer_segments to role:agent-readonly

For the agent that needs to consume the new endpoint:

# Agent fetches the live OpenAPI spec instead of guessing the contract
$ curl -s http://localhost:8080/openapi.json | jq '.paths."/api/v1/customer_segments"'

For an MCP-side consumer:

$ faucet mcp list-tools | grep customer_segments
customer_segments_list
customer_segments_get
customer_segments_create
customer_segments_update
customer_segments_delete

The whole loop — schema change to live REST + OpenAPI + MCP + RBAC — is a restart, not a sprint. That’s what compression looks like on the data side.

The Perplexity counterpoint, briefly

Worth noting: Perplexity’s CTO publicly said in March they’re moving Perplexity off MCP and onto plain APIs and CLIs, citing context-window bloat from tool schemas and authentication friction across servers. The MCP-purity crowd took it as heresy. We took it as obvious: for a single-agent product with a known tool set, plain HTTP is faster, cheaper, and uses less context.

The reason we ship both REST and MCP from the same definition is that the enterprise answer isn’t “MCP everywhere” or “APIs everywhere.” It’s “the same data, exposed through whichever surface the consumer needs.” A B2B product team building a vertical agent wants HTTP. A consultant wiring up Claude Desktop wants MCP. Both should hit the same row, with the same RBAC, against the same connection pool.

If you treat REST and MCP as two separate stacks, you double the integration work right at the moment the rest of the SDLC is compressing. That’s the wrong direction.

The metric that matters in 2026

For most of the last decade, the headline number was “lines of code per developer per day.” Then it became “PRs merged per week.” Now, with agents doing the merging, the meaningful number is shifting again.

The metric I’d watch: time from schema change to the point an agent can safely call the new data.

In the world IBM is selling, the agent ships its code in 3 days instead of 30. If the data layer takes 2 weeks to catch up, you’ve shipped the front half of a feature. That’s worse than not shipping at all, because now you have a half-deployed contract that the next agent will discover and try to use.

The data layer doesn’t have to be the bottleneck. It just has to be treated like a build artifact instead of a project.

Getting started

If you want to see the schema → REST + OpenAPI + MCP loop on your own database, Faucet installs in one line and runs as a single binary:

curl -fsSL https://get.faucet.dev | sh

Point it at any Postgres, MySQL, SQL Server, Oracle, Snowflake, or SQLite database:

faucet server start --db postgres://user:pass@host:5432/mydb

Open http://localhost:8080/admin for the embedded UI, or http://localhost:8080/openapi.json for the live spec. The MCP server is on the same port at /mcp.

If you’re running into the data-layer bottleneck on your own agent rollout, the docs on RBAC and connection pooling are the parts most teams hit first.

The agents are getting faster. The plumbing should keep up.