LangChain har gjort mycket bra för AI-utveckling. Det har sänkt tröskeln för många och gjort det möjligt att komma igång snabbt. Men ramverket passar inte alla skeden av ett projekt lika bra, och det finns pragmatiska skäl till att fler team landar i egen kod ju längre de kommer.
Abstraktioner som inte alltid passar verkligheten
LangChain bygger på begrepp som chains, agents och memory. De abstraktionerna är generella nog att täcka mycket men sällan specifika nog att exakt passa hur ett enskilt team tänker om systemen de bygger. Ett vanligt mönster är att man lägger tid på att förstå hur LangChain vill att man ska göra något, istället för att bygga det man faktiskt behöver.
När man börjar omfaktorera ramverket istället för att använda det är det ett tecken på att man har växt ifrån det.
Versionsfrekvensen kostar
LangChain har under perioder brutit bakåtkompatibilitet ofta. Det betyder att utvecklartid går åt till att uppdatera paket istället för att bygga nytt värde, eftersom nya versioner kräver omtestade agenter, lästa migrationsguider och lagade edge cases. Det är värt det om man får mycket tillbaka för besväret. Många team som växer ur ramverket tycker inte att de gör det.
Ett litet, fokuserat bibliotek räcker långt
Ett eget bibliotek behöver inte vara ambitiöst för att vara användbart. Prompt-rendering, modell-anrop med retries, structured output, verktygsanrop, kostnadsspårning och loggning är den typen av kärnfunktionalitet som täcker det mesta ett AI-team gör i vardagen. Det som är specialiserat skrivs specifikt när behovet faktiskt uppstår, i stället för att generaliseras i förväg.
Vad man borde tänka om val av ramverk
I tidig fas, när man behöver komma igång snabbt, är det rationellt att börja med ett etablerat ramverk. Det sänker risken och ger fungerande mönster att lära av.
När man börjat förstå vad man egentligen bygger, och märker att ramverket sätter käppar i hjulet, är det läge att överväga eget. Poängen är att äga sin egen stabilitet, inte att det ska kännas häftigt.
Den övergripande lärdomen
Den största kostnaden för ett komplext beroende är sällan själva integrationen. Det är att den mentala modellen över systemet blir svårare att hålla. Kod man förstår fullt ut är ofta värd mer än elegant ramverkskod man bara delvis förstår, särskilt i AI-byggande där felmeddelanden ofta är svaga och man behöver kunna gräva snabbt.