Somewhere in most companies there is a person who, every Monday, exports a report from one system as a CSV and feeds it into another. They open the first tool, run the same saved view, download the file, open the second tool, line up the columns, fix the date format the importer doesn't like, and press go. It takes fifteen minutes if nothing has changed since last week. Something usually has.
Everyone knows this step exists. Nobody automates it. The reason is not stupidity or laziness. It's arithmetic. The script that would replace the Monday ritual is too small to be a project, too specific to buy, and too dull for anyone to volunteer their afternoon for. So the ritual survives, year after year, in the gap between worth building and annoying enough to keep doing by hand.
That gap was real. I'm not going to pretend the old maths was wrong. A developer's afternoon has a cost, and the integration that saves one person fifteen minutes a week does not clear it. Multiply by a small team and you might get there, but only after the meeting to decide whose afternoon, on whose backlog, owned by whom afterwards, and that meeting costs more than the script. The economics that kept the CSV ritual alive were sound economics.
What changed is the cost of the afternoon, not the soundness of the maths.
Why the glue went unwritten
Integration glue has always been the least glamorous code there is. It carries no algorithm worth discussing, demonstrates no technique, and reads, when you find it years later, like a list of apologies for two systems that were never designed to meet. It exists only because System A emits what System B can almost, but not quite, consume.
The "almost" is the whole problem. If the formats matched, you wouldn't need the script. Because they don't, the script has to know one specific thing about each end: that this field is a string here and an integer there, that this API paginates and that one doesn't, that the date is DD.MM.YYYY on the left and ISO on the right, that an empty value means zero in one place and "not yet known" in the other. None of that knowledge transfers anywhere. It is bespoke by definition, and bespoke is expensive.
So the work landed in a no-man's-land. Too small to scope as a project and assign an owner. Too particular to satisfy with an off-the-shelf connector, which solves the eighty-percent case and leaves you with exactly the twenty percent that mattered. And too tedious to attract a volunteer, because the person who'd benefit usually couldn't write it and the person who could had better things to do.
We learned to live in that no-man's-land. A shared folder with a naming convention. A wiki page describing the manual steps. A calendar reminder. These are the load-bearing structures of a surprising amount of business, and the reason they persist is that each individual instance is, on its own, not worth fixing.
The script is now cheaper than the meeting about the script
Randall Munroe drew the canonical version of the old maths back in 2013. xkcd 1205, "Is It Worth the Time?", is a grid of how long you can spend automating a routine task before you've spent more time than you'll save over five years . Shave thirty seconds off something you do daily and you get roughly a day of budget to build the fix; shave a second off a yearly task and you get about five seconds. For a decade it has been the chart engineers link at each other to justify not building something, and the justification was .
What the table never questions is the number it quietly prices the automation at: the cost of a person sitting down to write it. Every cell in the grid assumes the build is the expensive half of the trade. Drop that cost by an order of magnitude and the whole table shifts upward: tasks that sat comfortably below the line, not worth the time, move above it without the time saved changing at all.
Here is the part that flips it. The cost of producing a small, single-purpose integration script has collapsed, and it has collapsed specifically for the kind of code that glue is made of.
This is the work are best at. The task is bounded. The shape is well-known: read from one place, reshape, write to another. The two are documented, so the agent isn't guessing at intent; it's faithfully implementing something that already has a spec. There's no novel design to get right, no architecture to argue about. There is a known input, a known output, and a list of fiddly transformations between them. Hand that to a competent agent with the two API docs and you have a working draft in twenty minutes, most of which you spend reading the output rather than writing the code.
The number that matters isn't "twenty minutes" in isolation. It's twenty minutes measured against the meeting you used to need before anyone wrote a line. You just build it and find out.
When building the thing is cheaper than the conversation about whether to build the thing, the conversation stops being worth having.
That reverses the default. For two decades the default answer to "should we automate this little step?" was no, it's not worth it, and the answer was usually correct. The default answer now is probably, try it, and that is also correct more often than not. A great many gaps that everyone had quietly agreed to tolerate are suddenly worth closing.
The constraint moved
The scarce resource used to be engineering capacity. Now it's noticing. The friction you've stopped seeing (the Monday CSV, the manual re-key, the export-and-reimport) is the thing worth building, and the hard part is remembering it bothered you.
A worked shape from my own bench
The Fiken Proxy exists because of exactly this kind of mismatch. Fiken is an accounting system I wanted to call from a small client using a bearer , the way modern tools expect to authenticate. Fiken's interface, on the side I needed, wanted a browser-style form login with a cookie session it would manage on your behalf. The two halves did not line up. Neither half was wrong; they were built for different worlds.
The bridge is a proxy that takes a bearer token on one side, signs in through the form flow, holds the cookie session, and forwards the request to the upstream endpoint. To the client it looks like a normal token-authenticated API. Behind it sits the awkward login dance, contained where I don't have to think about it again. That was an afternoon. Not a project, not a quote, not a backlog item that would have died of neglect. An afternoon, because the protocol on each end was documented and the only real work was the translation in the middle.
The ExaProxy is the same family of move, and it's worth describing precisely because it broke the pattern. It presents over the , so that any tool which already speaks (, DBeaver for diagnostics) can query Exasol with no native driver. The payoff is enormous: you write one adapter and inherit a whole shelf of tools on the other side.
But it was not an afternoon, and the reason is instructive. A has corners. Postgres clients ask catalog questions, expect particular type metadata, and lean on behaviour Exasol doesn't provide directly. A proxy that handles the happy path and falls over on the catalog query is the worst kind of tool, because it works in the demo and fails in production for reasons that are baffling until you've stared at a packet trace. That project is still active, and the open work is exactly those edges: large-query behaviour, first-row timing, schema compatibility. The cheap part was the idea. The expensive part was the twenty percent the demo never hits.
So the renaissance is real, but it isn't uniform. Some glue collapses to an afternoon. Some glue looks like an afternoon and turns out to be a quarter, and the skill is telling them apart before you commit.
The renaissance is also a renaissance of rot
Here is the downside, and it's not a small one.
A world where the glue script is cheap is a world where the glue script is everywhere. Every team that couldn't justify these tools last year can justify dozens this year. Most of them will be undocumented, owned by whoever happened to be in the chat that afternoon, and invisible until the day they stop working.
Glue is load-bearing precisely because it disappears. The Monday CSV ritual was painful but legible: a human did it, a human noticed when it went wrong, a human knew what it was for. Replace it with a script and the pain goes away, which is the point, but so does the attention. The script runs silently. It keeps running silently right up until the upstream API adds a required field, or renames a column, or starts paginating where it didn't before, and then it fails silently too, or worse, succeeds with wrong data, which nobody catches because nobody was watching a step that "just works."
Silent glue fails silently
The script that quietly moves your numbers every night is the one you'll forget exists. You'll rediscover it the morning a downstream report is wrong and the trail leads back, eventually, to a forty-line file nobody remembers writing, holding a credential nobody remembers issuing. The cost of producing glue collapsed. The cost of not knowing your glue exists did not.
There's something almost comic in how cheerfully we recreate old mistakes with new tools. We spent years building data platforms with lineage and governance and audit trails, exactly so that nobody would have to wonder where a number came from, and the same people will happily wire two systems together with an unlogged script run from a personal laptop because it took twenty minutes and felt too small to mention. The smallness is the trap. Small is how things slip under the governance you built for the big stuff.
The discipline that keeps it sane
You don't fix this by going back to copying data by hand. You fix it with a small amount of discipline that costs far less than the script saved you.
A script that touches anything important needs three things. A name, so it can be referred to and found. A home (a repository, not a laptop) so it isn't lost when someone changes jobs. And a one-line note on what breaks it: which two systems it joins, what it assumes about each, and the change at either end that would make it fail. That last line is what matters, because it's the knowledge that lived in the head of whoever wrote it and evaporates the moment they move on.
This is most of the maintenance an agent will not do for you. An agent will write the glue in twenty minutes; it will not remember, six months later, that this particular script depends on a field the upstream team is about to deprecate. That accounting is a human responsibility, and it is cheap only if you do it at the moment of writing, when you still hold the whole thing in your head.
The good news is that the same tool that made the rot possible makes the discipline cheap. The agent that wrote the script will, if asked, write the README, the one-line dependency note, and a basic alert that fires when the thing stops doing its job. Most people skip that step because it's boring and the script "works." It's the part I'd skip last.
What the renaissance asks of you
The glue script came back not because it got interesting but because it got cheap. Nothing about joining two reluctant systems is more elegant than it was; the code is the same list of apologies it always was. The only thing that changed is the price, and the price changed enough to move thousands of small, sensible automations from the wrong side of the ledger to the right side.
The skill that's now scarce isn't writing the script. Any agent will do that. It's the judgement above the script: deciding which gaps deserve one and which are telling you something worse. A gap you bridge for the third time with a third script is a gap that wants fixing upstream: a shared model, a real integration, a conversation with the team that owns the other end. Cheap glue makes it tempting to paper over structural problems one afternoon at a time, and a stack held together by forty disposable scripts is its own kind of debt, just distributed where it's harder to see.
So the question to keep asking is the one the cheap script lets you dodge: is this a gap worth bridging, or a seam worth removing? Sometimes the answer is that the script is fine and the gap is permanent. Sometimes it's that you've just written your third workaround for a problem that deserves a proper fix, and the cheapness of the workaround is what keeps you from it.
The Glue Script Renaissance · June 2026. Examples drawn from the author's own projects: the Fiken Proxy (a bearer-token-to-form-login bridge) and the Exasol Postgres Proxy (a PostgreSQL-wire-protocol adapter for Exasol). Both are active, working software; the ExaProxy edge-case work described is ongoing.
References
- 1Randall Munroe, "Is It Worth the Time?", xkcd 1205, 2013 (CC BY-NC 2.5). xkcd.com ↗