Wie vandaag een AI-toepassing opent, krijgt steeds vaker dezelfde keuze voorgeschoteld: welk model moet worden gebruikt? Het ene model blinkt uit in programmeren, het andere in redeneren of design. Volgens Lovable wordt die aanpak stilaan een doodlopende straat. Gebruikers zouden helemaal niet moeten weten welk AI-model achter de schermen het meest geschikt is. De software moet dat zelf uitzoeken.
De ontwikkelaar van het AI-platform voor het bouwen van apps kiest daarom voor een andere filosofie: niet één model voor alles, maar een intelligent systeem dat tijdens het werk bepaalt welke AI het beste bij een bepaalde taak past.
The model picker is a dead end | LovableHere's what model independence means at Lovable. |
Het beste AI-model bestaat niet
De AI-markt verandert razendsnel. Een model dat vandaag uitstekend scoort, kan enkele weken later worden ingehaald door een concurrent. Bovendien betekent een hoge positie op een benchmark niet automatisch dat hetzelfde model ook de beste keuze is voor het bouwen van een complete applicatie.
Sommige modellen zijn bijvoorbeeld sterk in het opsporen van complexe programmeerfouten, terwijl andere betere interfaces ontwerpen. Nog andere modellen presteren goed bij korte opdrachten, maar verliezen tijdens langdurige projecten sneller de context.
Lovable wil die complexiteit bij de gebruiker weghalen. In plaats van mensen vooraf een model te laten selecteren, probeert het platform verschillende modellen zo in te zetten dat hun individuele sterke punten maximaal worden benut. Dat betekent volgens het bedrijf niet dat alle modellen zomaar uitwisselbaar zijn. Integendeel: voor ieder model worden instructies, tools en projectcontext aangepast aan de manier waarop dat specifieke model het beste functioneert.
Interne tests illustreren hoeveel verschil dat kan maken. In een evaluatie voltooide een nieuw frontiermodel opdrachten 15 procent sneller dan zijn voorganger, had het daarvoor 40 procent minder interactierondes nodig en lag de uiteindelijke score 2 tot 3 procent hoger.
De echte intelligentie zit in de orkestratie
Daarmee verschuift de aandacht van het individuele AI-model naar wat Lovable de ‘control plane’ noemt.
Wanneer iemand bijvoorbeeld vraagt om betalingen aan een applicatie toe te voegen, moet achter de schermen veel meer gebeuren dan alleen code genereren. Het systeem moet begrijpen wat de gebruiker bedoelt, de juiste bestanden vinden, een plan maken, code schrijven, de applicatie uitvoeren en controleren of alles daadwerkelijk werkt.
Wanneer onderweg iets fout gaat, ontstaat vervolgens een nieuwe keuze. Moet het systeem opnieuw proberen? Het plan aanpassen? Een andere tool gebruiken? Een ander AI-model inschakelen? Of toch aanvullende informatie aan de gebruiker vragen?
De control plane volgt daarom voortdurend hoe een bouwproces verloopt. Wanneer een AI-agent vastloopt of in cirkels begint te werken, kan het systeem ingrijpen. Verschillende onderdelen van hetzelfde project kunnen daardoor uiteindelijk door verschillende modellen worden afgehandeld.
Wisselen van model is niet altijd beter
Opvallend genoeg betekent die vrijheid niet dat Lovable voortdurend tussen AI-modellen wil springen.
Bij langere projecten bouwt een AI-agent namelijk een geschiedenis op. Het systeem heeft bestanden bekeken, fouten ontdekt, oplossingen geprobeerd en geleerd welke onderdelen belangrijk zijn. Bij een overstap naar een ander model moet een deel van die context mogelijk opnieuw worden opgebouwd of samengevat.
Een theoretisch beter model kan daardoor in de praktijk juist een slechtere keuze zijn. Lovable probeert daarom niet zoveel mogelijk modellen te gebruiken, maar alleen te wisselen wanneer de verwachte verbetering groter is dan het verlies aan context en extra werk.
Ook de oorzaak van een probleem speelt daarbij een rol. Wanneer een AI-provider tijdelijk overbelast is, kan dezelfde modeltechnologie eventueel via een andere provider worden aangesproken. Maar wanneer het model zelf de opdracht verkeerd heeft geïnterpreteerd, lost zo'n overstap niets op. Dan moet bijvoorbeeld de context, planning, tool of het model zelf veranderen.
Niet het antwoord, maar de applicatie is de benchmark
Lovable stelt bovendien een fundamenteel andere manier van evalueren voor. Een AI-model kan indrukwekkende code produceren die er op het eerste gezicht uitstekend uitziet, terwijl de uiteindelijke applicatie helemaal niet goed werkt.
Daarom beschouwt het bedrijf niet het antwoord van het model, maar de afgewerkte applicatie als de belangrijkste benchmark. Er wordt gekeken naar het volledige traject: welke stappen werden uitgevoerd, waar liep het systeem vast, hoe herstelde het zich, hoeveel tijd kostte het proces en werkt het eindproduct daadwerkelijk zoals de gebruiker had gevraagd? Daarmee krijgen ook begrippen als ‘snel’ en ‘goedkoop’ een andere betekenis. Een snel model kan uiteindelijk traag blijken wanneer er drie keer zoveel correctierondes nodig zijn. Een goedkoop AI-verzoek kan juist duur worden wanneer het systeem daardoor een verkeerde richting inslaat.
Publieke benchmarks blijven nuttig om interessante modellen te ontdekken, maar volgens Lovable vertellen ze onvoldoende over hun prestaties binnen een compleet AI-ontwikkelplatform.
Lovable bouwt daarom ook eigen modellen
Het bedrijf beperkt zich ondertussen niet meer uitsluitend tot modellen van externe AI-aanbieders.
Voor bepaalde terugkerende en duidelijk afgebakende taken ontwikkelt Lovable eigen gespecialiseerde modellen. Die worden onder meer gebruikt voor het routeren van opdrachten, het samenvatten van resultaten en het schrijven van commitberichten.
Inmiddels nemen eigen post-trained modellen volgens het bedrijf een betekenisvol deel van het werk binnen productieomgevingen voor hun rekening. De volgende generatie moet complexere onderdelen van het bouwproces kunnen uitvoeren.
Ook die eigen modellen krijgen echter geen voorkeursbehandeling. Ze lopen door dezelfde control plane. Wanneer een extern model een bepaalde taak beter uitvoert, kan dat model opnieuw de voorkeur krijgen.
De AI-laag wordt belangrijker dan het AI-model
Daarmee tekent zich een bredere ontwikkeling af. Naarmate steeds meer krachtige foundationmodellen beschikbaar komen, verschuift het concurrentievoordeel mogelijk van het model zelf naar de softwarelaag die bepaalt hoe al die intelligentie wordt ingezet.
Toegang kopen tot een geavanceerd AI-model kan vrijwel ieder technologiebedrijf. De moeilijkere opdracht is een systeem bouwen dat begrijpt welk model, welke context, welke tools en welke werkwijze nodig zijn om consequent tot een betrouwbaar resultaat te komen.
Iedere fout kan daarbij nieuwe informatie opleveren. Een mislukte bouwpoging kan worden omgezet in een test waarmee wordt onderzocht of de prompt, context, tool, evaluatiemethode, orkestratie of het onderliggende model moet veranderen. Wanneer vervolgens een nieuw AI-model verschijnt, hoeft het hele systeem niet opnieuw vanaf nul te beginnen. Het nieuwe model kan worden getest binnen een omgeving die al heeft geleerd wat een goede applicatie moet zijn.
De gebruiker hoeft uiteindelijk alleen nog te zeggen wat hij wil
Lovable ziet de klassieke modelkiezer daarom als een tussenfase in de ontwikkeling van AI-software.
Foundationmodellen zullen steeds krachtiger worden, maar waarschijnlijk niet allemaal op hetzelfde moment en voor dezelfde taken. Het ene model kan plots een grote sprong maken in redeneren, terwijl een ander sneller, goedkoper of beter in programmeren wordt. De gebruiker zou die wedloop niet voortdurend zelf hoeven te volgen.
In de visie van Lovable beschrijft iemand simpelweg welke software hij wil bouwen. Het platform bepaalt vervolgens achter de schermen welke combinatie van modellen, tools en context daarvoor het meest geschikt is. De strijd om het ‘beste AI-model’ maakt zo plaats voor een interessantere vraag: welk systeem is het beste in het voortdurend kiezen, sturen en combineren van alle beschikbare AI-intelligentie?
