Budoucnost sestavování aplikací AI závisí na type safety

Kód generovaný umělou inteligencí může být zkompilován, ale bez přísné type safety je tento úspěch velmi krátkodobý. Type safety je zábrana, která brání křehkému kódu v rozkladu do skrytých chyb a runtime selhání, když se systém škáluje.

Musíme začít nutit umělou inteligenci k přísnému typování prostřednictvím kontextu, instrukcí, lintingu a zpětných vazeb. Trvá to několik hodin, ale produkuje kód, který vydrží.

Problém incentiv

Umělá inteligence chce vás potěšit. Optimalizuje se pro odměňovací funkci, kterou obdrží, a většinu času je to jen „zda se zkompiluje?“ To znamená, že bude dělat všechny možné zkraty, aby dosáhla zeleného zaškrtnutí. Tyto zkraty vypadají dobře v době kompilace, ale při runtime se zhroutí.

To je důvod, proč umělá inteligence miluje any. Nebo si vybere široký typ, jako je string, kde by něco přísnějšího, jako UUID, bylo očekáváno. Kód se zkompiluje, ale správnost je již porušena. Horší je, že umělá inteligence si nepamatuje, co napsala před několika soubory, takže bez type safety projekt rychle zhroucí pod svou vlastní vahou, jakmile se zvyšuje složitost.

Dva typy chyb

Když kód generovaný umělou inteligencí běží, obvykle vidíte dva typy problémů s type safety:

1. Chyby v době kompilace

• Co se stane: Kompilátor zachytí nesoulad mezi deklarovaným typem a tím, co bylo předáno.
• Jak to člověk opraví: Rozhodne, zda je volající chybný (převést 42 na string) nebo zda je chybná funkce (změnit ji na přijetí number typu).
• Jak to umělá inteligence „opraví“: Změnit typ argumentu na any. Problém „vyřešen“, ale jste právě odstranili zábranu, která by zachytila budoucí chyby.

2. Chyby v době běhu

• Co se stane: Kompilátor si myslí, že vše je v pořádku (často proto, že typy byly uvolněny), ale skutečná hodnota v době běhu neodpovídá předpokladu.
• Jak to člověk opraví: Vyhledat proměnnou zpět k jejímu zdroji (jako API nebo dotazu na databázi) a opravit typ na hranici, aby data přišla jako správný string.
• Jak to umělá inteligence „opraví“: Bez kontextu, hádá. Možná obalí všechno v String(…), nebo prostě rozšíří typ znovu. Crash zmizí v tomto místě, ale teď je logika rozbitá. Numbers určené pro matematiku jsou náhle strings.

Tento cyklus chyb v době běhu → „oprava“ umělou inteligencí → uvolnění typů se rychle sčítá. Výsledkem je kód, který se zkompiluje a vyhodí méně chyb v době běhu, ale nelze mu důvěřovat. Představte si systém pro plánování lékařů, kde jsou lékaři spravováni aplikací. Dojde k chybě v typu: int pro hodiny je tratt jako string. Umělá inteligence „opraví“ to uvolněním typu na any. Kód se zkompiluje a chyba zmizí, ale výpočty směn se potichu rozloží, dvojité rezervace lékařů a celý křídlo nemocnice zůstane bez lékařů.

Databázový násobitel

Okamžik, kdy se připojíte k databázi, chyby se mnohonásobně zvyšují a jejich příčiny se stávají těžšími na vyhledání. SQL je typován z důvodu. Každý schéma (INT, TEXT, UUID, BOOLEAN) kóduje předpoklady o vašich datech.

Když umělá inteligence zplošťuje všechno na string | any, ztrácíte tyto záruky:

• Špatné zápisy: vložení “true” do boolean pole se zkompiluje, ale zkazí databázi.
• Špatné čtení: dotaz vrátí NULL, ale umělá inteligence předpokládá string, což vede k runtime crashu.
• Rozbité vztahy: pokud je očekávaný vztah jako UUID, ale umělá inteligence ho zpracuje jako string a omylem pošle odpadové hodnoty, spojení se nezhroutí, ale nevrátí žádná data. To skrývá chyby, dokud se neobjeví později jako chybějící nebo nesourodé výsledky..

To je důvod, proč vážné týmy používají typované jazyky a vynucují type safety od schématu po API. Pokud to neuděláte, databáze přestane chránit vás a skryté problémy se sčítají.

Proč zavedené týmy vynucují přísné typování

Přísné typování není o tom, aby se zpomalily vývojáři. Je to o tom, aby se umožnilo škálování.

Typy:

• Kódují záměr do kódu.
• Učiní refaktoring bezpečným a předvídatelným.
• Zachytí celou třídu chyb, než se dostanou do produkce.
• Ukáží budoucím vývojářům (a umělým inteligencím) přesně, jak použít funkci nebo objekt.

Bez type safety se sčítá nedbalost kódu umělých inteligencí. S ní vyrobí umělá inteligence kód, kterému můžete důvěřovat a rozšiřovat.

Jak donutit umělou inteligenci k type safety

Musíte s umělou inteligencí zacházet jako s juniorním inženýrem. Rychlým, talentovaným, ale bezohledným bez směru.

Poskytnout správný kontext

Dejte jí rozhraní a typy, které může použít. Ukážete příklady použití. Buďte názoroví na správný způsob, jak strukturovat kód.

Dát přísné instrukce

Velmi jasně dejte umělé inteligenci vědět, aby nepoužívala any, nikdy neumožňovala unknown a aby měla každý metodu, objekt a proměnnou typován. Očekávejte, že bude mít těžkou dobu následování těchto instrukcí (zejména na prvním průchodu).

Vynutit s lintingem

Stejně jako když recenzujete kód juniorního vývojáře, musíte zkontrolovat kód umělých inteligencí. Navrhněte vlastní lint pravidla, která definují, co „dobrý kód“ znamená pro vás. Vraťte linting selhání zpět do modelu, dokud neprojde. To může trvat několik kol, ale posune odměňovací funkci směrem k zahrnutí type safety.

Iterovat s kontrolami

Chyby v době kompilace, runtime logování, kliknutí-prostřednictvím testů. Každá iterace nutí umělou inteligenci utáhnout typy a přiblížit se k produkčnímu kódu.

Lepší způsob budování

Naučil jsem se, že obětování surové generace rychlosti za vyšší kvalitu se vyplatí ve dlouhém běhu. To znamená bojovat za nulovou toleranci pro any typy, vynucování více zpětných vazeb a přísných linting pravidel, kterým musí umělá inteligence projít, než nazve kód „hotový.“ To vyžaduje stálé úsilí, ale je to jediný způsob, jak udržet kvalitu od poklesu.

Dříve jsem zmínil klíčový bod: jednou, když umělá inteligence začne opravovat chyby v době běhu uvolněním typů, vstoupíte do zlého cyklu. Každá oprava odstraní další zábranu, a výsledek se sčítá do kódu, který se zkompiluje, ale je křehký a nemaintenovatelný. Opak je také pravdivý: pokud donutíte umělou inteligenci respektovat type safety na každém průchodu, vytvoříte ctnostný cyklus. Každá iterace utáhne zábrany, kód se stane čistějším, a kvalita se sčítá do něčeho, čemu můžete důvěřovat a stavět na něm.

To je systém, o kterém jsem přesvědčen, že dodává trvalou kvalitu kódu. Každá iterace je navržena tak, aby utáhla standardy, ne oslabila je. Je to stejný důvod, proč nejlepší inženýrské týmy volí silně typované jazyky. Type safety je základní zábranou pro udržovatelnost, a dovolit umělé inteligenci ji ignorovat zajišťuje, že vaše aplikace nikdy nedosáhne produkční úrovně.