blog·5 min lezen

Een maand bouwen met de assistent: de cijfers

Vier weken, vier demo-sites, acht bouwruns. Hoe lang elke opdracht werkelijk kostte, wat er misging en wat de cijfers zeggen over het verschil tussen de modellen.

Installeer WordPress met de titel Schildersbedrijf Van der Berg en bouw een
eigen thema met homepage, diensten, portfolio en contact.

Sinds half september bouwen we elke week een complete website met de Invoker Assistant en schrijven we op wat er gebeurt. Niet als demo met een geknipte opname, maar met een logboek per opdracht: de letterlijke tekst, de tijd in seconden, de stappen die hij zette, de screenshots die hij zelf maakte en wat er misliep. Dit is wat daar na vier weken uit komt.

Alle getallen hieronder komen uit die logboeken, tot en met 11 oktober. Niets is geschat.

Drie sites, 1 uur en 33 minuten

Site Model Opdrachten Tijd
Leeg domein naar kapsalon met online reserveren Codex, GPT-6-Astra 4 47 min
Site uit 2012 opnieuw opgebouwd Claude Opus 4 26 min
Export uit een website-bouwer naar WordPress Claude Sonnet 4 19 min

Samen 12 opdrachten en 1 uur en 33 minuten machinetijd voor drie werkende websites. Gemiddeld 31 minuten per site. Dat is sneller dan de reeks heet, en toch is het gemiddelde het minst interessante getal van dit artikel.

De spreiding per opdracht is enorm

De snelste opdracht kostte 24 seconden. De langzaamste 25 minuten. Dat is een factor 60 binnen hetzelfde soort werk.

De langzaamste was een WordPress-installatie. Die liep vast op de grenzen van de sandbox, waarna de assistent de installatie met de hand afmaakte, bestand voor bestand. Het eindresultaat was goed, de weg erheen was de slechtst mogelijke.

De snelste was het inlezen van een bestaande site. Die ging zo snel omdat de notities van een eerdere poging er nog stonden. In de poging daarvoor kostte dezelfde opdracht 82 seconden. Dat is geen ruis, dat is het hele punt van notities per website: wie zijn site één keer laat verkennen, bespaart dat elke keer daarna.

Wat de modellen deden

Je zou een duidelijk verschil per model verwachten. In onze cijfers zie je dat niet, en dat komt doordat de opdracht meer bepaalt dan het model.

Model Gemiddeld per opdracht
Codex, GPT-6-Astra 11 min 47 s
Claude Opus 6 min 38 s
Claude Sonnet 4 min 45 s

De bovenste regel was wel de enige die bij nul begon: leeg domein, WordPress installeren, thema bouwen, reserveringsplugin bouwen. De onderste twee bouwden een bestaande site om, met de inhoud al op de server. Vergelijk dus niet de modellen, maar de taken. Wat we er wel uit halen: bij lange taken wachtte de langzaamste er minutenlang op zijn eigen tussenstappen, en dat zie je terug in elke opdracht van die run.

Wat er misging

Dit is het deel dat bij een demo altijd wordt weggelaten, en voor ons het nuttigste.

Acht runs voor vier sites. Drie sites zijn af. De vierde is tot en met 11 oktober vier keer achter elkaar gestrand op de eerste opdracht. Dat zijn geen kleine hikjes, dat zijn hele avonden.

Eén run gestopt door werk dat op de achtergrond verdween. De assistent besteedde het bouwen van het thema uit aan een achtergrondtaak en meldde dat hij het zou laten weten zodra het klaar was. Dat moment komt nooit, want de opdracht eindigt bij het antwoord. Opdracht 3 en 4 kwamen daarna uit op een lege WordPress. Resultaat: 2 van 4 opdrachten in 56 minuten. We hebben daarna in de assistent vastgelegd dat hij niets meer op de achtergrond start en dat hij afmaakt voordat hij antwoordt. De tweede poging liep in 19 minuten foutloos door.

Nul fouten in de logboeken. Niet één van de geslaagde opdrachten gaf een foutmelding of een paginafout. Dat klinkt mooi en het is precies het probleem: een opdracht die vastloopt, meldt dat niet als fout. Hij meldt dat hij klaar is. Daarom controleren we nu per run of de site echt doet wat de opdracht vroeg, en niet of er fouten in het log staan.

Nul goedkeuringen, en waarom dat eerlijk is

In alle runs staat het aantal goedkeuringen op nul. Dat komt doordat deze runs in de automatische stand draaien: wijzigingen gaan direct door en verschijnen daarna als kaart met de verschillen.

Dat is dus geen bewijs dat de assistent niets riskants deed. Het is de stand die je kiest als je wilt meten hoe snel hij werkt. Werk je zelf met goedkeuring per wijziging, dan klik je ongeveer zo vaak als er bestanden veranderen, en dat zijn bij een thema-opdracht tientallen keren. Zie Goedkeuren in de assistent voor de standen.

Twee getallen die ons verrasten

42 screenshots, zelf gemaakt. Over de drie geslaagde runs maakte de assistent 42 schermafdrukken om zijn eigen werk te bekijken, desktop en mobiel. Niet omdat wij dat per opdracht vroegen, maar omdat het in de opdracht stond dat hij moest controleren. Dat is de goedkoopste kwaliteitscontrole die er is.

30 vervolgvoorstellen. Elke opdracht sluit af met wat hij daarna zou doen. Over de drie runs waren dat 30 voorstellen, en bijna allemaal hetzelfde soort: echte foto's aanleveren, het juiste mailadres instellen, een testbericht sturen. Dat is precies de lijst die je bij een echte klant ook overhoudt.

Veelgemaakte fouten

Een gemiddelde als belofte lezen. 31 minuten per site is het gemiddelde van drie runs met vier opdrachten. Eén installatie die vastloopt verdubbelt dat.

Geen controle in de opdracht zetten. Vraag je niet om een screenshot of een test, dan krijg je ze niet, en dan hoor je pas van een bezoeker dat de helft niet werkt.

Een lege foutlijst vertrouwen. Nul fouten betekent dat niets is omgevallen, niet dat de opdracht gelukt is. Controleer het resultaat, niet het log.

Modellen vergelijken op verschillende taken. Onze eigen tabel hierboven nodigt daartoe uit, en toch mag je hem zo niet lezen. Wil je modellen vergelijken, laat ze dan hetzelfde doen; dat is precies wat er in een latere aflevering gebeurt.

De afleveringen zelf, met de opdrachten en de screenshots per site, staan op Gebouwd in een uur.

MK
Maarten Keizer

Oprichter van Invoker. Ruim twintig jaar hosting, systeembeheer en webdevelopment; bouwt de Claude-hosting zelf en test alles eerst op de eigen servers.

over maarten