Poslední měsíce stavím aplikaci pro precizní zemědělství. Webová aplikace s mapami, API, mobilní režim pro práci v terénu bez signálu, vlastní infrastruktura v cloudu. Backend je v Pythonu, což je jazyk, ve kterém jsem patnáct let nic produkčního nenapsal.
Šlo to mnohem rychleji, než by to šlo před dvěma lety. Tohle není marketingová věta, je to prostě fakt.
Zajímavější než ta rychlost je ale něco jiného: kde přesně AI přestala stačit. Protože právě na těch místech se ukázalo, za co mě klienti vlastně platí.
Co AI zvládla
Skoro všechno, co se dá popsat zadáním.
Komponenty, formuláře, validace. Endpointy API i s ošetřením chyb. Migrace databáze. Konfigurace sestavení, pipeline, infrastruktura jako kód. Testy. Práci s knihovnou, kterou jsem nikdy nepoužil — stačilo popsat, co má dělat.
Python pro mě přestal být bariéra. Ne proto, že bych se ho naučil, ale proto, že znalost syntaxe přestala být to úzké hrdlo. Vím, jak má vypadat dobře navržené API, a to je přenositelné mezi jazyky. Zbytek je překlad a ten dnes zvládne stroj.
Kdybych měl spočítat, kolik řádků jsem v tom projektu napsal sám, vyšla by mi nula. Občas jsem něco přenastavil nebo sáhl do konfigurace. Všechno ostatní napsala AI — a když se někde zasekla, pustil jsem na to druhý model. Dva modely se zaseknou na různých věcech a i to je samo o sobě užitečné zjištění.
Kde to přestalo stačit
Tady začíná ta zajímavá část.
Datový model. AI navrhne tabulky podle toho, co jí popíšete. Problém je, že správný návrh vyžaduje vědět, co se v tom byznysu mění a jak často. Pozemek je stabilní entita. Plodina na něm se mění každou sezónu. Zásah, který na tom pozemku proběhne, je událost s časem a vazbou na obojí. Tohle rozlišení nevyplývá ze zadání — vyplývá z toho, že jste viděli, co se stane za tři roky, když ho neuděláte.
Tuhle chybu jsem v kariéře udělal dost na to, abych ji poznal dřív, než se stane.
Souřadnicové systémy. AI vám bez mrknutí oka napíše práci s mapou v tom systému, který je na webu obvyklý. Že zdrojová data z úřední evidence přicházejí v jiném a je potřeba je převádět, nenavrhne, protože se jí na to nikdo nezeptal. A ona se nezeptá sama.
Tohle je obecnější vzorec: AI neumí položit otázku, která v zadání nezazněla. Zato ji umí zodpovědět, jakmile ji položíte vy.
Co musí fungovat offline. Technicky to není těžké. Těžké je rozhodnout, které operace to jsou. Odpověď nezjistíte z dokumentace — zjistíte ji z toho, že víte, jak vypadá pracovní den uživatele. Člověk v terénu potřebuje zapsat, co udělal, a vidět, co má udělat. Nepotřebuje tam editovat číselníky.
Každá věc, kterou pustíte do offline režimu, je navíc zdroj konfliktů při synchronizaci. Rozhodnutí „tohle offline nebude" je často cennější než to opačné.
Jak to vlastně vypadá v provozu. Uživatel je venku, na displeji má slunce, možná rukavice. To nejsou detaily, které se doladí na konci — to jsou vstupy do návrhu.
Co se tím mění
Dřív jsem při odhadu projektu počítal hlavně implementaci. Dnes se těžiště posunulo jinam: nejdražší částí je rozhodnout, co se vlastně má postavit a jak to má být uspořádané, aby to vydrželo.
Ta část se nezlevnila. Spíš naopak — když zbytek jde rychleji, je vidět, že ona byla tím podstatným celou dobu.
Pro mě to znamená, že patnáct let analýzy, architektury a porozumění byznys procesům najednou není něco, co doplňuje schopnost psát kód. Je to to hlavní, co nabízím. Kód je dnes nejlevnější část projektu.
Jedna poznámka k opatrnosti
Nic z toho neznamená, že výsledek nemusíte číst. Čtu každý řádek, který jde do produkce — ne proto, že AI dělá hodně chyb, ale proto, že ty, které udělá, vypadají správně. Chybu v kódu, který nevypadá dobře, najdete hned. Chybu v kódu, který vypadá naprosto standardně, najdete v provozu.
Zrovna u datového modelu to platí dvojnásob. Špatně navržená tabulka se neprojeví, dokud v ní nejsou data, na kterých závisí někdo další.
Jestli řešíte podobnou věc — ať už je to aplikace na míru, nebo rozhodnutí, co ještě postavit na platformě a co už mimo ni — ozvěte se na vit.lachner@email.cz nebo přes LinkedIn.