AI coding agent umí během několika minut vytvořit migraci, nový endpoint i kus datového modelu. To je přesně důvod, proč jsou tak užitečné. Zároveň ale mohou velmi rychle rozšířit systém způsobem, kterému už nikdo pořádně nerozumí – zvlášť když agent nevidí celé schéma, obchodní pravidla ani provozní historii aplikace.
Na tento problém upozornil text DeepSQL o databázích, které mají začít „přemýšlet“. Autor v něm popisuje zkušenost ze Stayflexi, kde podle jeho tvrzení coding agenti během několika měsíců výrazně rozšířili počet tabulek i náklady. Zmiňuje také údajný únik osobních údajů z nepoužívaného endpointu.
To všechno je zatím potřeba brát jako popis a interpretaci DeepSQL, nikoli jako nezávisle potvrzený incident. Ve veřejně dostupných podkladech nejsou přesná čísla, audit databáze ani vyjádření Stayflexi. Přesto je to dobrý začátek pro mnohem širší otázku: kdo odpovídá za změny, které navrhne nebo provede AI agent?
Databáze není jen hromada tabulek
V původní rychlé zprávě na Radyz jsme shrnuli hlavní myšlenku DeepSQL. Databáze by podle ní neměla pouze hledat nejrychlejší způsob, jak provést jednotlivý SQL dotaz. Měla by rozumět také tomu, co tabulky znamenají, jak spolu souvisejí, kdo je používá a co se v systému změnilo.
To zní jako slovní hříčka, ale rozdíl je praktický. Klasický optimalizátor ví, že existuje tabulka `customers`, sloupec `status` a index. Nemusí ale vědět, že hodnota `active` znamená něco jiného pro zákaznickou podporu než pro finanční oddělení. Neví ani, že stejný zákazník existuje ještě v jiné tabulce pod historickým identifikátorem.
Když pak agent dostane úkol „přidej přehled aktivních zákazníků“, může vytvořit novou tabulku nebo nový sloupec, i když podobná logika už v systému existuje. Nemusí to být chyba modelu. Může jít o důsledek chybějící dokumentace, špatného přístupu ke schématu nebo procesu, ve kterém nikdo nekontroluje dopad změny na celý systém.
Nejprve přišlo text-to-SQL
Nejviditelnější využití kontextu je převod běžné otázky do SQL. Manažer se zeptá: „Jak se změnil churn u velkých zákazníků po změně ceníku?“ Jazykový model může vytvořit syntakticky správný dotaz, ale to ještě neznamená, že odpověď odpovídá tomu, co firma skutečně považuje za churn nebo velkého zákazníka.
Výzkum text-to-SQL dlouhodobě ukazuje, že model potřebuje znát vztahy mezi tabulkami, nejen seznam názvů sloupců. Benchmark Spider testuje převod přirozeného jazyka na SQL nad různými databázemi. Novější BIRD benchmark zase připomíná, že reálné databáze mají větší schémata, nejasné hodnoty a potřebují znalost širšího kontextu.
Praktické nástroje už tímto směrem jdou. Snowflake Cortex Analyst pracuje se sémantickými modely, které popisují tabulky, dimenze, metriky a synonyma. Databricks AI/BI Genie zase umožňuje dodat vybrané tabulky, instrukce a příklady pro konkrétní doménu.
Semantic layer je slovník firmy
Tím se dostáváme k pojmu semantic layer. Nejde o další chatbot nad databází, ale o vrstvu, která popisuje obchodní význam dat. Firma v ní může jednou definovat, co je aktivní zákazník, jak se počítá tržba nebo kdy už je předplatné považováno za ukončené.
dbt Semantic Layer staví na definicích metrik, dimenzí a vztahů mezi entitami. Podobnou roli má LookML v ekosystému Lookeru nebo semantic layer od Cube. Smyslem je, aby stejnou metriku nepoužíval každý dashboard, analytik a AI agent trochu jinak.
To je také odpověď na problém, který DeepSQL popisuje. Agent nemusí pouze vidět strukturu databáze. Potřebuje dostat schválený výklad toho, co struktura znamená. Jinak bude sice rychle generovat SQL, ale může automatizovat několik vzájemně neslučitelných definic stejného čísla.
Provozní kontext může ušetřit peníze
Druhá část návrhu se týká provozu. Databáze by měla vědět, které dotazy běží často, co se změnilo po posledním releasu, kde rostou náklady a které tabulky nebo indexy už nikdo nepoužívá.
Část toho už existuje v tradičních databázových nástrojích. PostgreSQL používá statistiky tabulek a odhady selektivity při výběru plánu dotazu. SQL Server Query Store uchovává historii dotazů, plánů a runtime statistik, takže lze hledat regrese po změně aplikace. Azure SQL nabízí také automatické ladění indexů a plánů.
Novinkou není samotná automatizace. Novější je snaha propojit ji s tím, co se děje mimo databázi: s deploymentem, konkrétní službou, uživatelem, dashboardem nebo incidentem. Nástroje jako Datadog Database Monitoring a standard OpenTelemetry se snaží spojovat databázové operace s aplikačním provozem.
Pro firmu to může znamenat docela konkrétní úsporu. Místo obecného „databáze je dnes pomalá“ lze zjistit, že konkrétní migrace přidala nový join, ten změnil plán pěti nejdražších dotazů a zároveň zvýšil objem dat replikovaných do záloh. Takový kontext je užitečnější než další chatbot, který pouze převypráví chybový log.
Bezpečnostní problém nemusí být v tabulce
DeepSQL ve svém textu zmiňuje také únik osobních údajů z nepoužívaného endpointu. I toto tvrzení je potřeba připisovat autorovi textu, protože bez incident reportu neznáme rozsah ani přesný průběh. Samotný příklad ale ukazuje důležitou věc: problém nemusí být v databázovém schématu, ale v tom, že staré rozhraní stále vrací data.
Kontextová databáze by proto neměla řešit jen tabulky a indexy. Potřebuje také vědět, odkud data pocházejí, kdo je vlastní, jak jsou citlivá, které služby k nim přistupují a jak dlouho se mají uchovávat. K tomu slouží katalogy, data lineage a governance nástroje, například Microsoft Purview, DataHub nebo otevřený standard OpenLineage.
To je také důvod, proč nestačí agentovi jednoduše říct, aby „nezakládal zbytečné tabulky“. Musí mít přístup k aktuální dokumentaci, ale zároveň nesmí dostat neomezené oprávnění číst nebo měnit citlivá data. Odpověď na problém s příliš autonomním agentem nemůže být další autonomní vrstva bez auditní stopy.
AI agent je rychlý junior, ne vlastník systému
Nejpřesnější přirovnání je možná AI agent jako velmi rychlý juniorní vývojář. Umí připravit změnu, najít podobný kus kódu a během chvíle napsat migraci. Zároveň ale nemusí vědět, proč v systému existují dvě zdánlivě stejné tabulky, který endpoint používá důležitý zákazník nebo co se nesmí dostat do logu.
To neznamená, že za chybu může agent. Agent nemá právní ani organizační odpovědnost. Odpovědnost zůstává u firmy, vlastníka systému, člověka, který změnu schválil, a týmu, který nastavil oprávnění a kontrolní procesy.
Pokud agent pouze navrhuje migraci a člověk ji projde, je situace jiná, než když agent sám zapisuje do produkční databáze. Stejně tak je rozdíl mezi novou tabulkou v testovacím prostředí a změnou, která zvětší produkční databázi, zálohy, replikaci a účet za cloud.
Téma dobře doplňuje i příklad nástroje ripwire, který se snaží agentům dodat mapu repozitáře a dopadu změn. U databází jde o stejný princip: agent potřebuje mapu systému, ne jen několik souborů a seznam tabulek.
Kde to dává smysl už dnes
- analytik se ptá na firemní data přirozeným jazykem a systém používá schválené definice metrik;
- databázový tým hledá, proč se po releasu zpomalil důležitý report;
- vývojář dostane před vytvořením migrace upozornění, že podobná struktura už existuje;
- bezpečnostní tým hledá staré endpointy, nepoužívané tabulky a osobní data bez jasného vlastníka;
- finance sledují, zda změny schématu nezvyšují náklady na úložiště, zálohy a replikaci.
Co by měla firma kontrolovat
Před nasazením agentů s přístupem k databázi by firma měla znát alespoň několik základních odpovědí:
- Kdo schvaluje změny databázového schématu?
- Může agent pouze navrhovat migrace, nebo je také spouštět?
- Existuje aktuální katalog tabulek, metrik a citlivých údajů?
- Umíme zjistit, která tabulka, endpoint nebo index se skutečně používá?
- Logujeme, který agent a který člověk změnu vytvořil a schválil?
- Máme limity na náklady a možnost rychlého návratu změny?
Bez těchto odpovědí je debata o „inteligentní databázi“ trochu předčasná. Nejdřív je potřeba vědět, co v databázi máme, proč to tam je a kdo za to ručí. Teprve potom má smysl přidávat model, který bude navrhovat další změny.
DeepSQL pojmenovává skutečný problém, ale není to důkaz řešení
DeepSQL podle všeho správně upozorňuje, že samotné schéma nestačí. AI agent, který nezná vztahy mezi tabulkami, obchodní pravidla a provozní dopady, bude dělat chyby rychleji než člověk. To je reálný problém, se kterým se budou vývojové týmy setkávat častěji.
Zároveň je dobré hlídat, kdo tento problém popisuje. DeepSQL má přirozený zájem představit databázi s větším kontextem jako odpověď. To ale zatím neříká, že existuje hotový produkt, který umí spolehlivě rozumět firemní logice, zabránit schema sprawl nebo odhalit bezpečnostní chybu.
Případ Stayflexi proto není důkazem, že AI agenti obecně ničí databáze. Je to varovný příběh, který otevírá správnou otázku: když vývoj zrychlí natolik, že změny vznikají rychleji než jejich kontrola, kdo bude hlídat celkový tvar systému?
Databáze budoucnosti možná nebude „myslet“ jako člověk. Měla by ale umět vysvětlit, co obsahuje, kdo její data používá, jak se mění náklady a jaký dopad bude mít další migrace. A pokud to neumí databáze sama, musí tuto roli zajistit kombinace dokumentace, semantic layer, observability, governance a odpovědného člověka.
