AI-Assisted Integration Development: Shipping Connectors at Scale

Integration work has a reputation for being unglamorous. You connect product A to product B, you write some glue, you move on. The reality on a serious integration program is the opposite: every platform has its own model of the world, its own primitives, its own limits, and its own documentation that is never quite complete. Shipping deep connectors across a whole catalogue of platforms with a small team should not be possible in a reasonable timeframe, and a year ago it probably would not have been.

This is the story of how the build loop changed when we leaned on AI tooling for exactly the part of integration work that used to be slowest. That slowest part was understanding a new platform well enough to build something real inside it.

Apify wanted its web data extraction to run inside the automation builders, AI agent platforms and CRMs that teams already use. That was not an expose-an-API-and-call-it-a-day job. Each connector had to be a deep, platform-specific implementation. It had to speak the platform's own language — listing actors, running pre-configured tasks, fetching dataset items, wiring up key-value stores and webhooks — rather than hiding everything behind one thin generic adapter.

That depth is what makes integrations actually useful, and it is also what makes them expensive. A thin wrapper you can copy-paste across platforms in an afternoon. A deep connector means learning how this platform models a workflow, where it puts its execution-time limits, how it expects authentication, and which of its features your users will actually reach for. Multiply that by 10+ platforms across three categories — automation tools, AI agent platforms, and CRM — and the bottleneck is obvious. It is not typing the code. It is the time it takes to understand each new platform before you can write a single useful line.

The unlock was speed of comprehension: AI collapsed the time from new platform to working mental model.

Standing up a connector for an unfamiliar platform used to start with days of reading — documentation, SDK source, community threads, half-answered forum posts, the lot. With coding agents like Claude Code and Cursor in the loop, that exploration phase shrinks fast. You point the agent at a platform's docs and SDK, ask the questions you would otherwise spend an afternoon answering yourself, and get to a working understanding (and a first running call) far faster. The same shift shows up in our work on large refactors with AI. The value is less in raw code generation and more in how quickly you can build an accurate picture of an unfamiliar system.

That compression is what made the small-team math work. Instead of one developer serialising through platforms one at a time, the team could keep several platform integrations moving forward in parallel. When the slow part of each integration — getting your head around the platform — shrinks, parallelism stops being a staffing problem and becomes a tooling one.

One pattern worth calling out: the most useful AI setups on the project were not a single all-purpose assistant. They were several, each loaded with platform-specific context for a specific job.

Concretely, that meant keeping separate, purpose-built environments. One was tuned for the business-analysis side of assessing a platform: is this integration worth the depth, and what traction would it see? The other was tuned for the actual plugin and connector development, each carrying the context relevant to its task. The lesson generalises well beyond integrations: an agent with the right narrow context for one job consistently outperforms a broad assistant trying to do everything with none. This mirrors the broader shift we have written about from AI assistants to AI agents: the gains come from giving the tool a real, scoped job rather than a vague one.

AI paid off in two more places in the workflow, and both mattered as much as the build loop:

It would be dishonest to claim AI shipped these integrations. It did not. The parts that decide whether a connector is good or merely present are still firmly human.

Execution-time limits are a clear example. Several platforms impose hard caps on how long an operation can run. The right answer was not to push that constraint onto the user, but to design around it with workflow-based waiting. That was a judgement call about user experience and platform behaviour that no agent made on our behalf. The same is true of the core principle that held across every platform in the catalogue: build the deep, platform-specific implementation, not the thin wrapper. Knowing which of a platform's primitives matter, and resisting the temptation to flatten everything into one generic adapter, is product and engineering judgement. AI gets you to the point where you can make that judgement faster; it does not make it for you.

Language choice stayed human too. TypeScript carried most of the work, with Python, Ruby and C# where a platform demanded it. Those choices followed what each platform actually supported, not what was easiest to generate.

If you are looking at an integration roadmap that feels too big for your team, the takeaway is not "buy more AI." It is more specific than that:

Shipping deep connectors for 10+ platforms with a small team is still hard. But when AI tooling takes the slowest, least differentiated part of the work — getting up to speed on each new platform — the team's actual expertise gets to spend its time on the parts that matter. That is what AI-assisted integration development bought us here: the same engineers, aimed at harder problems.