AI-asistovaný vývoj integrací: konektory ve velkém

Vývoj integrací má pověst nezáživné práce. Propojíš produkt A s produktem B, napíšeš pár řádků lepicího kódu a jdeš dál. Na vážném integračním programu je realita opačná: každá platforma má vlastní logiku, vlastní primitiva, vlastní limity a vlastní dokumentaci, která nikdy není úplná. Postavit hluboké konektory pro celý katalog platforem s malým týmem by v rozumném čase nemělo jít — a před rokem by to pravděpodobně opravdu nešlo.

Tohle je příběh o tom, jak se změnila vývojová smyčka ve chvíli, kdy jsme se opřeli o AI nástroje přesně u té části integrační práce, která bývala nejpomalejší. Šlo o to pochopit novou platformu natolik, abychom v ní mohli postavit něco reálného.

Když v Apify chtěli, aby jejich web data extraction šlo spouštět přímo v automatizačních nástrojích, AI agentních platformách a CRM, které týmy už používají, nešlo o „vystav API a hotovo“. Každý konektor musel být hluboká, platform-specific implementace. Musel mluvit jazykem dané platformy — vypisovat actory, spouštět předkonfigurované tasky, stahovat dataset items, napojovat key-value stores a webhooky — a ne schovávat všechno za jeden tenký generický adaptér.

Právě tahle hloubka dělá integrace skutečně užitečnými — a zároveň drahými. Tenký wrapper překlopíš na další platformu za odpoledne. Hluboký konektor znamená naučit se, jak tahle platforma modeluje workflow, kde má limity na dobu běhu, jakou čeká autentizaci a po kterých funkcích uživatelé reálně sáhnou. Vynásob to deseti a víc platformami ve třech kategoriích — automatizační nástroje, AI agentní platformy a CRM — a úzké hrdlo je zřejmé. Není jím psaní kódu. Je jím čas, který potřebuješ, abys novou platformu pochopil dřív, než napíšeš jediný užitečný řádek.

Zlom byl v rychlosti pochopení: AI smrskla čas od nové platformy k funkčnímu mentálnímu modelu.

Stavba konektoru pro neznámou platformu dřív začínala několika dny čtení: dokumentace, zdrojáky SDK, komunitní vlákna, napůl zodpovězené posty na fórech. S kódovacími agenty jako Claude Code a Cursor se tahle průzkumná fáze dramaticky zkracuje. Nasměruješ agenta na dokumentaci a SDK platformy, položíš otázky, nad kterými bys jinak strávil odpoledne, a k funkčnímu pochopení — i k prvnímu běžícímu volání — se dostaneš výrazně rychleji. Stejný posun vidíme i u naší práce na velkých refaktoringách s AI. Hodnota není ani tak v generování kódu jako spíš v tom, jak rychle si dokážeš udělat přesný obrázek neznámého systému.

Právě tahle komprese je důvod, proč to malému týmu vyšlo. Místo aby jeden vývojář řešil platformy jednu po druhé, mohl tým posouvat několik integrací najednou. Když se pomalá část každé integrace — dostat platformu do hlavy — zkrátí, přestává být paralelismus otázkou náboru a stává se otázkou nástrojů.

Jeden vzorec stojí za zvýraznění: nejužitečnější AI setupy na projektu nebyly jeden univerzální asistent. Bylo jich několik, každý nabitý platform-specific kontextem pro konkrétní úkol.

Konkrétně to znamenalo držet oddělená, účelově postavená prostředí. Jedno bylo vyladěné na business-analytickou stranu hodnocení platformy (vyplatí se do té integrace jít do hloubky? kolik lidí by ji reálně používalo?), druhé na samotný vývoj pluginů a konektorů — každé s kontextem relevantním pro svou roli. Poučení platí i daleko za hranicemi integrací: agent se správným úzkým kontextem pro jeden úkol spolehlivě porazí širokého asistenta, který se snaží dělat všechno bez kontextu. Odráží to širší posun, o kterém jsme psali — od AI asistentů k AI agentům: přínos je v tom, že nástroji dáš reálný, ohraničený úkol, ne vágní.

AI se vyplatila i na dvou dalších místech workflow, stejně důležitých jako vývojová smyčka:

Bylo by nepoctivé tvrdit, že tyhle integrace dodala AI. Nedodala. Části, které rozhodují o tom, jestli je konektor dobrý, nebo jen existuje, jsou pořád jednoznačně na lidech.

Jasným příkladem jsou limity na dobu běhu. Několik platforem klade tvrdé stropy na to, jak dlouho smí operace běžet. Správná odpověď nebyla přenést to omezení na uživatele, ale obejít ho čekáním, které řídí workflow. To je rozhodnutí o uživatelské zkušenosti a chování platformy, které za nás žádný agent neudělal. Totéž platí o základním principu, který držel u každé platformy v katalogu: stav hlubokou, platform-specific implementaci, ne tenký wrapper. Vědět, která primitiva platformy jsou důležitá, a odolat pokušení splácnout všechno do jednoho generického adaptéru, je produktový a inženýrský úsudek. AI tě k tomu úsudku dostane rychleji; neudělá ho za tebe.

Na lidech zůstala i volba jazyka. Většinu práce odnesl TypeScript; Python, Ruby a C# přišly na řadu tam, kde je platforma vyžadovala. Rozhodovalo to, co každá platforma reálně podporovala, ne to, co se nejsnáz vygenerovalo.

Pokud koukáš na integrační roadmapu, která se zdá moc velká pro tvůj tým, závěr není „kup víc AI“. Je konkrétnější:

Postavit hluboké konektory pro deset a víc platforem s malým týmem je pořád těžké. Nejpomalejší částí práce — dostat se do obrazu u každé nové platformy — se stejně nikdo neodliší. Když ji vezmou AI nástroje, zbyde reálné expertíze týmu čas na to, na čem záleží. Tohle nám AI-asistovaný vývoj integrací přinesl: stejné inženýry namířené na těžší problémy.