Skip to content

Back to Blog

8 min read ·

Glue code is the job

Most of the software that keeps a company running is code that makes two systems agree about one record: one customer, one appointment. Engineers call it plumbing, and this winter's "AI software engineer" pitches leave it out of the demo.

Engineers and vendors both have it backwards. Glue is the job.

If you've never had to write it, glue code is the stuff in the middle. The nightly job that copies customers from the sales tool into billing. The webhook that tells the warehouse an order was paid. The script that turns one vendor's spreadsheet export into another vendor's API calls. Nobody buys software for its glue. Every business runs on it anyway.


There's a belief most engineers hold and few say out loud. Call it the greenfield fantasy. Real engineering, it says, happens inside one system you control: a fresh repo with nothing in it to argue with. Connecting the old systems is plumbing, and plumbing goes to interns, to contractors and, as of last month, to bots.

On December 10, Cognition made Devin generally available, "starting at $500 a month for engineering teams." Cognition had been calling it "the first AI software engineer" since its debut in March. It shipped with a Slack integration, an IDE extension and an API. So somebody at Cognition wrote a lot of glue to sell it.

Read the launch post past the headline, though, and the advice is modest. Start Devin on "small frontend bugs and edge cases." Have it create "first-draft PRs for backlog tasks." Point it at "targeted code refactors." Give it "tasks that you know how to do yourself," and keep sessions "under ~3 hours."

I give Cognition credit for the honesty. That's a fair list of what these tools are good at. It's also the greenfield fantasy's job description, and not one item on it asks the agent to make two systems agree.

Then Mark Zuckerberg sat down with Joe Rogan this month and said that Meta, probably in 2025, will have "an AI that can effectively be a sort of midlevel engineer that you have at your company that can write code."

Write code. Sure.

That's the cheap part.

I say that with a chat model open in a side window. Ask any of them for a function that maps one system's fields onto another's and you'll have it before you finish typing the field names. It'll be decent, too. If glue were only about mapping fields, the bots could have it today and I wouldn't argue.


The mapping is the part you can see. Here's the part you can't.

Say you run three physiotherapy clinics. The front desk books patients in one system. A second system, from a different vendor, sends the text reminders and charges the no-show fees. You ask someone to keep the two in sync. It looks like an afternoon of work: read appointments from one API, write them to the other.

Then the questions start.

What counts as cancelled? The front desk has one button for it. The reminder system has three statuses: cancelled by the patient, cancelled by the clinic, and no-show. Only one of them charges a fee. Which one does the front desk's single "cancelled" turn into?

Whose time zone is the slot in? One system stores 10:00 in the clinic's local time. The other stores it in UTC, the world's reference clock, and the sync converts with a fixed offset that someone typed in during the winter instead of the clinic's actual time zone. It works until the clocks change in March. Then every reminder goes out an hour wrong, and patients start showing up for appointments that already happened.

Which copy wins when both change before either hears about the other? At 9:58 the patient cancels by replying to a text. At 9:58 the receptionist, on the phone with the same patient, moves the visit to Friday. Two writes, two systems, one appointment. The usual default is that the last write wins, and no timestamp can tell you which of the two the clinic meant.

Does deleted mean gone or hidden? One system erases the record. The other only hides it. Your sync job looks for the record, can't find it, decides it must be new, and creates it again. Now you have a zombie appointment and a patient getting reminders for a visit nobody booked.

Neither vendor will change its product for you. The day one side accepts a change that the other side rejects, you have two truths about one patient, and the code in the middle has to decide which truth to tell.

bookedfront deskgluecancelledreminderswhich one is true?
Two systems hold the same appointment, and they disagree about it. Both answers flow into the low block in the middle, and nothing in the picture picks a winner. That choice is the job.

No ticket describes that decision. It's a business rule, what the clinic actually means by "cancelled," and it gets made by whoever writes the sync. Usually at six in the evening. Usually without asking anyone.


If that sounds like a small-business problem, NASA lost a spacecraft to it.

In September 1999 the Mars Climate Orbiter reached Mars and was never heard from again. JPL's preliminary finding was "a failure to recognize and correct an error in a transfer of information between the Mars Climate Orbiter spacecraft team in Colorado and the mission navigation team in California." One team used English units, pounds and feet. The other used metric. The numbers crossed from one team to the other, and nothing at the handoff asked which units they were in. Nobody had checked that both sides meant the same thing by them.

The quote from Edward Weiler, then NASA's head of space science, is the one I'd pin above every integration team's desk: "People sometimes make errors. The problem here was not the error, it was the failure of NASA's systems engineering, and the checks and balances in our processes to detect the error."

That's a glue failure. Each side was right by its own definition. The handoff between them was the one place the mistake could be caught, and nobody owned the handoff.


The "AI software engineer" demos are cooking shows. The raw chicken goes into one oven, and a golden one comes out of another.

Nobody films the part where the two ovens disagree about what "done" means.


The most useful AI release of 2024 was a boring protocol for glue. On November 25, Anthropic open-sourced the Model Context Protocol, MCP for short, a standard way for AI assistants to talk to outside tools and data. The announcement was blunt about the problem: "Every new data source requires its own custom implementation, making truly connected systems difficult to scale."

Do the arithmetic. If every assistant needs its own connector for every tool, five assistants and twenty tools means a hundred of them, each one somebody's weekend. Agree on one protocol, and each assistant learns it once and each tool learns it once. Twenty-five pieces instead of a hundred. That's a real win.

It launched with ready-made connectors, which MCP calls servers, for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. Every one of those is glue, and somebody will patch it every time the API on the other side changes.

But a protocol standardizes the plug. It doesn't tell you what a field means. MCP can hand an agent the clinic's appointment in a perfectly well-formed message. It can't tell the agent whether "cancelled" should cost the patient a fee. The orbiter's numbers were well-formed too.


The greenfield fantasy is older than AI. Engineers sold it to each other long before any vendor did, because it flatters us. New code gets a launch post and a line on a resume. Glue gets noticed once, on the day it breaks, and the rest of the time it belongs to whoever had the least standing to refuse it.

That's exactly backwards. Glue is where a company's real rules live, because it's the only place where two versions of the truth meet and somebody has to pick. The person writing it makes product decisions whether anyone told them to or not. You want that person to be the one who stops and asks "what do we mean by cancelled?" before they write the if statement.

The bots will get better at writing the mapping. Let them. Somebody still has to know what cancelled means.

Stop calling it plumbing. Give the glue to your best engineer.