Claude Opus 5.5 mot GPT-6.1 Sol i virkelige prosjekter: mitt personlige inntrykk

Jeg ville bygge en app for å snakke med agentene mine fra mobilen. Jeg satte begge modellene i arbeid med prosjektet. Claude Opus 5.5 startet to timer etter GPT-6.1 Sol og ble ferdig en time tidligere. Jeg syntes også at Claudes prototype var bedre.

Jeg legger ikke frem dette resultatet som en vitenskapelig test. Et konkret prosjekt avhenger av oppdraget, sammenhengen hvert system får, verktøyene og beslutningene som tas underveis. Men episoden satte ord på en forskjell jeg allerede hadde sett i andre prosjekter.

GPT-6.1 Sol kan gjøre en utmerket jobb når jeg gir den en konkret oppgave. Likevel har enkelte prosjekter jeg har startet med Sol som ansvarlig for den overordnede koordineringen, endt med å stoppe opp. Når jeg har gjennomgått det som skjedde og overlatt orkestreringen til Claude Opus 5.5, har jeg fått dem i gang igjen. Når jeg begynner med Opus i den rollen, er mitt inntrykk at jeg kommer raskere frem til et bedre resultat.

Å være en god utfører betyr ikke nødvendigvis at man er en god koordinator

Å utføre en oppgave og å lede et prosjekt krever ulike ting. En utfører kan få et avgrenset mål, utvikle en løsning og levere den til gjennomgang. Koordinatoren må ha oversikt over helheten: bestemme hva som skal gjøres først, fordele arbeidet, oppdage hindringer, kontrollere at delene passer sammen og vite når noe faktisk er ferdig.

Dette skillet har vært mer nyttig for meg enn å spørre: «Hvilken modell er best?» I enkelte oppdrag er GPT-6.1 Sol en svært effektiv utfører. Når flere arbeidsløp skal koordineres, et prosjekt som har stoppet opp skal gjennomgås og neste steg skal avgjøres, taler min nylige erfaring for Claude Opus 5.5.

«Sjef» er her en kortform for en funksjon i systemet. Den endelige beslutningen og ansvaret ligger fortsatt hos meg.

Parallelle sammenligninger lærer meg mer enn å velge av vane

Mitt råd er å ikke binde seg til én modell. Hvis et prosjekt er viktig, er det verdt å gi to KI-systemer det samme oppdraget og sammenligne det de leverer. Det holder ikke å se på hvem som svarte først eller skrev mest kode. Jeg vil vite hvem som raskest leverte et brukbart resultat, hvilke rettelser som måtte til, hvor mye tid jeg måtte bruke på gjennomgang, og hvilke problemer som oppstod da arbeidet skulle innarbeides.

For at en slik sammenligning skal lære oss noe, bør modellene så langt som mulig starte med det samme målet, de samme materialene og de samme kriteriene for å godta resultatet. Oppdragene og versjonene må også bevares. Ellers er det lett å tilskrive modellen en fordel som kanskje skyldtes en bedre instruks eller mer kontekst.

Mobilappen ga meg et tydelig signal for mine egne valg, men avgjør ikke spørsmålet. Jeg ville prøvd igjen med andre prosjekter. Og hvis Sol koordinerer ett av dem bedre i morgen, kommer jeg til å endre mening.

Prosjektet må kunne bytte motor

Denne arbeidsmåten skaper et praktisk problem. Hvis alt et prosjekt vet, er spredt mellom samtaler på én plattform, kan et modellbytte tvinge meg til å rekonstruere beslutninger, instrukser og arbeid som allerede er gjort. Da fortsetter jeg å bruke det samme systemet fordi det koster å forlate det, selv om et annet kanskje ville fungert bedre.

Derfor er målet mitt, når jeg bygger Alonides på Hermes, å bevare den konteksten jeg trenger for å fortsette, utenfor hver enkelt modell: mål, filer, instrukser, beslutninger, utestående oppgaver, resultater og gjennomganger. Jeg vil kunne snakke med agentene i et prosjekt eller henvende meg til Alonides som koordinator for helheten. Og jeg vil kunne bytte modellen som fyller hver funksjon, uten å miste historien om arbeidet.

I dag er min foretrukne kombinasjon i mange prosjekter Claude Opus 5.5 som koordinator og GPT-6.1 Sol som utfører av avgrensede oppgaver. Jeg trenger ikke at denne kombinasjonen skal være endelig. Jeg trenger en organisering som lar meg undersøke når den fungerer, oppdage når den slutter å fungere, og endre den uten å begynne på nytt.