The Integration Bill Nobody Budgets For

When I quote an integration, the number people react to is the build. Fair enough — it's the number with a line item next to it. What almost nobody asks about is what happens in month fourteen, when a vendor changes a field type, or a piece of infrastructure you built on top of quietly stops existing under you. That's not a hypothetical. It happened to my own site three times in one evening this week.

What broke, on my own site, in one sitting

None of this was a client engagement. This was fieldmappings.com, mine, breaking in ordinary ways:

• I switched from Docker Desktop to Colima this weekend and never updated the build script to match — so the next deploy just failed cold, pointed at a socket that no longer existed.
• I wired up basic analytics, and the site's own Content Security Policy blocked the script from loading. A CSP written for a site with no third-party scripts doesn't know what to do the first time you add one.
• The contact form had been writing submissions to a file inside the container the whole time — with no persistent volume behind it. Every deploy was a small chance of quietly deleting someone's message before I ever saw it.

Not one of these was hard to fix. Each one took minutes once someone was looking at it. That's exactly the point — the cost was never the difficulty, it was the interval. A stretch of nobody looking at a working system is a stretch where "working" quietly becomes "half working," and you find out from a symptom, not a warning.

Why the bill hides

At the time of the build, everything is visible: the requirements, the systems, the price. Later, the failure is invisible until it isn't — nobody's watching a docker script that hasn't changed in weeks, until the day the thing underneath it changes and the script doesn't know. The bill doesn't show up as an invoice. It shows up as a stale build, a blocked script, a lost message, sitting there until someone happens to look.

How that changes with an AI coding agent in the loop

This week, all three of those got caught and fixed in the same conversation I was using to do something else entirely — commit a change, watch it deploy, notice the build failed, ask why. I was talking to Claude Code, running on Anthropic's Sonnet 5 model, wired into my repo and my CI/CD pipeline. It read the failed build, found the mismatched assumption, fixed it, and pushed again — the same evening, without me ever scoping a maintenance ticket first.

That doesn't erase the bill. It changes its shape. The part of integration maintenance that's mechanical — a stale path, a missing CSP entry, a config that assumed infrastructure that moved — gets cheap and fast to fix, because an agent doesn't need the interval between "it broke" and "someone noticed" to be measured in months. What doesn't get cheaper is the judgment part: deciding that a customer's "Account Number" and a vendor's "Customer ID" are the same field, except for the eleven records where they aren't. That's still a human question, and it's the one I actually get hired for — an agent can fix the plumbing at 9pm; it can't tell you what your data means.

So the honest version of the pitch is: the maintenance tax on the mechanical stuff is dropping, fast. The value of understanding your own systems well enough to catch when they mean something different than they used to — that part just went up, because it's now the part nobody's automated away.