Just-in-time integrations

5 min read
aidevelopmentopinion
Human + AI

There’s a local grocery store near me—Heinen’s, a Cleveland-area chain—with an online ordering system. Nothing fancy: search for products, add them to your cart, check out, pick up later. I’ve wanted to automate this for years. Snap a photo of a handwritten grocery list, have something parse it, build the cart, hand me a checkout URL. Go pick up my groceries.

The integration didn’t exist, because why would it? It’s a local grocery store. No API docs, no SDK, no community wrapper. And I wasn’t about to reverse-engineer their checkout flow for a side project that would save me fifteen minutes a week.

I’d shelved that idea for years, never quite motivated enough to wade into their system for something so minor.

Last week I built a CLI for it in an afternoon.

heinens search "organic milk" -n 5
heinens add "Heinen's Organic Whole Milk"
heinens cart
# → Cart: 3 items, $15.47
# → Checkout URL: https://shop.heinens.com/sm/pickup/rsid/17/cart-review

The old world

For most of software’s history, if you wanted to interact with an external service programmatically, you had three options:

  1. Hope they published an API. Maybe with decent docs. Extra score if they had an SDK in your language.
  2. Hope someone else had the same problem. And cared enough to build an open-source client you could use.
  3. Build it yourself. Which meant learning their system top to bottom, handling auth flows, pagination, error states, rate limits. All the unglamorous plumbing that turns a few endpoints into something usable.

Option three killed most ideas before they started. The context switch alone was brutal. You’d have a spark of an idea, realize the integration didn’t exist, and by the time you’d scoped out what building it would require, the motivation had evaporated. The proverbial juice wasn’t worth the squeeze.

So you crossed your fingers and hoped the service you needed had thought to expose the right endpoints, or that someone in the community had scratched the same itch. And if neither was true, you moved on.

The new world

If the adapter doesn’t exist now, you can just make it. Point an agent at the docs, let it discover the endpoints, generate a CLI, and move on with your life. Disposable, single-use, good enough for your use case.

Alex Hillman built a skill called api2cli that captures this pattern. You point it at a docs URL (or even just a base URL to probe) and it:

  1. Discovers endpoints by parsing docs, checking well-known paths for OpenAPI specs, probing common REST patterns
  2. Builds a catalog of what it found
  3. Generates a working CLI with proper auth handling, pagination, retry logic
  4. Wraps the whole thing in a skill so the agent knows how to use it going forward

The output is a CLI because CLIs are a lovely agent interface: language-agnostic, composable, no runtime dependencies bleeding into your project. The agent shells out, gets structured JSON back, and keeps moving.

The Heinen’s project took 15 minutes of Claude-cooking. The agent poked around their site, found the endpoints they use for search and weekly deals, figured out the auth flow, and generated the CLI. It uses a headed agent-browser for the auth. Just like that, I had something I’d wanted for half a decade.

Adapters on demand

We’ve been talking a lot about “personal software” lately. Bespoke apps built for an audience of one. Tools that exist because you needed them, not because they’d scale.

There’s a corollary nobody’s really naming: just-in-time integrations. Disposable SDKs. Adapters built on demand, used until they break, regenerated when they do.

Inspired by api2cli, the app I’m building right now has an “Add Integration” button. You paste a docs URL, and it builds the integration from scratch, on demand, for your specific use case. The integration didn’t exist five minutes ago. Now it does.

This inverts the old dependency. You used to hope services would support your workflow. Now you make them support it.

What about sharing?

The open source instinct kicks in: “I built this thing, I should share it, someone else might find it useful.”

And sure, maybe. But the economics of maintenance have shifted. If the code is cheap to generate, what are you actually offering by publishing it? Anyone can regenerate the code. You’re not going to handle their edge cases. The agent wrote the documentation too.

Maybe you publish it anyway, with issues enabled but PRs disabled. “Fork it if you want. I’m not your maintainer.” Deciding what makes it into the product is the hard part now, not the contribution itself.

I wonder if we’re heading toward a world where PRs become rare. The unit of contribution changes: you don’t send me your code, you send me your requirements. My agent decides whether to implement them.

That might be a different blog post.

The real barrier

The barrier to building integrations might not have been technical skill. Instead, maybe it was the overhead of context-switching into someone else’s system, learning their patterns, handling their quirks. That overhead made most integrations not worth starting.

The overhead is gone now. The agent eats it for breakfast, and you get to keep working on whatever actually matters to you.

Go forth and create just-in-time integrations.