Lovable slettet nesten all agentkode: kunnskapsfiler slo finjustering etter 100 000 PR-er
mandag 9. november · KI-generert · Kilde: Lovable
Tilpass agentens frihet til modellens evne: det er Lovable-gründer Anton Osikas viktigste lærdom etter over 100 000 pull requests og mer enn 70 millioner prosjekter.
«Å gi dem mer frihet gjorde produktet mindre pålitelig», skriver Anton Osika, medgründer av Lovable og skaperen av GPT Engineer, på selskapets nye tech-blogg. Ingeniøren Mårten Wiman hadde bygget et asynkront design der agenten opprettet oppgaver og delegerte til subagenter. Agentene havnet i tekniske blindspor, gjorde feil og hadde ingen forutsigbar sluttid.
«Vi slettet nesten all agentkode og gikk tilbake til at én brukerforespørsel ga en ganske forutsigbar kjede av verktøy» — Anton Osika, medgründer av Lovable
Sent i 2024 var hovedflyten ett enkelt modellsvar med de ønskede filendringene. Native tool calling var ikke pålitelig nok, så modellen pakket koden i XML-lignende tagger som <lov-write>, og Lovable parset endringene etterpå. Det fantes retries og feilhåndtering, men ingen åpen løkke der modellen valgte neste steg selv. Små finjusterte LLM-er plukket ut hvilke filer hver endring avhang av.
Planen fra 2023 var finjusterte modeller trent på produktdataene. I stedet leste ingeniørene chattlogger fra ødelagte apper og skrev korte notater om gjentakende feil, såkalte knowledge files, som et retrieval-steg hentet inn i konteksten. Osika kaller det en skaleringslov og peker på at mønsteret er det samme som agent skills i dag. En tidlig versjon av Lovable Stack Overflow, som henter problemer og løsninger for agenten, kuttet andelen brukere som satt fast med 5 %.
Senere kom sandkasser som holder dev-serveren i gang, inkrementelle TypeScript-sjekker og checkpointing av minne, CPU-tilstand og disk. Nå kan Lovable forke en hel app med kjøremiljø og database, slik at agenter kan prøve flere tilnærminger fra samme utgangspunkt.
Hva bør du gjøre?
- Mål hvor ofte agentløkka di ikke blir ferdig før du gir den flere verktøy eller subagenter. En fast verktøykjede med forhåndsvisning kan gi mer forutsigbare svar.
- Les loggene fra feilede kjøringer og skriv korte regelfiler som hentes inn ved behov, som Lovables «Only use icons that exist in lucide-react.», før du vurderer finjustering.
- Kort ned syklusen redigere, sjekke, rette med inkrementell typesjekk mot en dev-server som allerede kjører, i stedet for full build per endring.