V4 er tæt på målstregen – men Solo-Engine v4.1 strammer reglerne for AI-arbejdsgange

Konklusion: V4 bør ikke sættes i drift helt uændret

V4 har den rigtige grundidé: Den bygger en sammenhængende kæde fra research og beslutning til implementering, validering og dokumentation. Den gør især op med fire velkendte fejl i AI-assisteret udvikling:

• opdigtede værktøjer og søgninger,
• opdigtede bygge- eller testresultater,
• kodeudsnit, der fejlagtigt kaldes en komplet leverance,
• ADR’er, der markeres som accepterede uden dokumenteret grundlag.

Men konfigurationen er blevet for tæt pakket. Flere dokumenter gentager regler om status, validering, afhængigheder, ADR’er og færdigmelding. Det øger risikoen for, at modellen rammer én regel lokalt, men overser en beslægtet regel et andet sted.

Den anbefalede slutversion er derfor Solo-Engine v4.1 Final. Målet er ikke at tilføje endnu flere kontroller, men at gøre de vigtigste kontroller kortere, tydeligere og sværere at omgå.

De afgørende ændringer i v4.1

1. Ufravigelige regler skal stå i hovedinstruksen

Det er usikkert at antage, at alle detaljer i en uploadet vidensbase hentes frem i hver enkelt besvarelse. Derfor skal centrale regler stå direkte i Gem-instruksen:

• Ingen påstand om værktøjskald, browsing, Tavily, MCP, kompilering, test, Git eller deployment uden reelle beviser.
• Ingen påstand om “ingen kompileringsfejl” eller “alle tests grønne”, hvis der ikke er kørt en faktisk validering.
• Komplet kode betyder komplette filer og en lukket leverance – ikke løse uddrag.
• En manglende, bærende grænseflade i et eksisterende projekt må ikke gættes frem.

Detaljerede procedurer og skabeloner kan stadig ligge i vidensbasen, men de må ikke være eneste værn for sandfærdighed og færdigmelding.

2. Et automatisk loop er ikke en baggrundsproces

Et prompt kan ikke i sig selv give en Gem adgang til en vedvarende terminal, baggrundsjob eller hukommelse på tværs af sessioner.

I v4.1 betyder et automatisk loop derfor kun en afgrænset cyklus:

• i den aktuelle session,
• inden for brugerens tydelige godkendelse,
• med de værktøjer, der faktisk er til rådighed,
• med et fast retry-budget,
• og med stop i WAITING_VERIFICATION, hvis ingen eksekveringsmotor findes.

Det forhindrer, at “automatisk” bliver en upræcis betegnelse for noget, systemet i praksis ikke kan gøre.

3. “Zero dependencies” skal splittes op

Udtrykket “nul afhængigheder” er for upræcist i softwareudvikling. Det kan ellers fejlagtigt forstås som både ingen runtime, ingen tredjepartspakker og ingen lokale filer.

V4.1 erstatter det med fire konkrete krav:

• ingen udeklarerede afhængigheder,
• som udgangspunkt ingen nye tredjepartsafhængigheder,
• alle nye lokale afhængigheder skal følge med leverancen,
• runtime, SDK, operativsystem og værtsplatform skal angives som miljøforudsætninger.

For nye, selvstændige projekter er standarden STDLIB_ONLY. I eksisterende projekter er standarden LOCKED_EXISTING: Der må kun bruges afhængigheder, som allerede er bekræftet i projektets manifest eller lockfile.

4. Komplet kode afhænger af projekttypen

Kravet om komplet kode skal være strengt uden at betyde, at et helt eksisterende repository altid skal gengives.

For et nyt projekt skal leverancen indeholde alle nødvendige filer: byggekonfiguration, entry point, kildekode, tests, ressourcer, konfigurationseksempler og valideringsvejledning.

For et eksisterende projekt skal hver ny eller ændret fil leveres i sin fulde form. Uændrede baseline-filer, som brugeren allerede har leveret, behøver ikke gentages. Men hvis en manglende fil eller grænseflade er nødvendig for at sikre kompilering eller integration, skal systemet stoppe og bede om den – ikke opfinde den.

5. Leverance, validering og færdigmelding holdes adskilt

V4.1 bruger tre separate statusser:

• DELIVERY_STATUS: Er alle nødvendige filer leveret?
• VERIFICATION_STATUS: Er der faktisk kørt kompilering, test eller kun statisk kontrol?
• ENGINEERING_STATUS: Er arbejdet reelt klar til at blive kaldt færdigt?

Det er en væsentlig skelnen. En komplet kodepakke kan godt være afleveret, selv om den stadig afventer en reel kompilering i målmiljøet.

Status COMPLETE må først bruges, når den nødvendige validering er bestået, leverancen er komplet, dokumentationen er opdateret, og en State Reconcile har fundet projektets status konsistent.

BMAD: rolleorkestrering, ikke påstået multi-agent-runtime

V4’s brug af BMAD er fornuftig, hvis den beskrives præcist. BMAD-dokumentationen beskriver konkrete agenter, skills og workflows, herunder QA-forløb knyttet til udvikleragenten.11014

En enkelt Gem kan derfor bruge perspektiverne PM, arkitekt, udvikler, QA og drift til at kontrollere forskellige typer risici. Men den må ikke påstå, at flere uafhængige agenter faktisk har kørt parallelt.

Den korrekte betegnelse er BMAD-inspireret rolleorkestrering. Det giver de nyttige kontrolpunkter uden at overdrive runtime-kapaciteten.

Tavily skal være en reel capability – ikke en promptpåstand

Tavily understøtter reelt parameteren search_depth=advanced. Dokumentationen beskriver den som en indstilling for høj relevans og detaljeret, præcisionsorienteret søgning, med højere latenstid som afvejning.2411

Det betyder dog ikke, at en Gem automatisk har Tavily-adgang. I v4.1 gælder derfor:

• Tavily må kun nævnes som anvendt, når værktøjet eller en tilsluttet integration faktisk findes.
• advanced bruges til beslutningskritiske og præcisionskrævende forespørgsler, hvis den aktuelle tool-schema understøtter det.
• Ved manglende Tavily-adgang skal systemet bruge de faktisk tilgængelige kilder eller tydeligt oplyse, at research er nedgraderet.
• Ingen må opfinde Tavily-resultater, Extract-data eller Crawl-output.

Beslutningsmatrix: V4.1 er det klare valg

Scoren nedenfor er en statisk konfigurationsvurdering – ikke en benchmark af faktisk drift.

Dimension	Vægt	V4	V4.1 Final
Runtime-grænser og værktøjssandfærdighed	25 %	4,0	4,8
Tre-pass-læsning, DM og DR	20 %	4,5	4,8
Tekniske sikkerhedsventiler og fejlhåndtering	20 %	4,6	4,8
Komplet kode og afhængighedslukning	15 %	4,6	4,9
Instruktionstæthed og efterlevelse	10 %	2,8	4,5
Statusgenopretning og evidensafstemning	10 %	4,2	4,7
Vægtet samlet score	100 %	84,2	95,5

Beregningen er:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad \sum_{i=1}^{n}w_i=1
$$

Afgørelse

• Anbefaling: Solo-Engine v4.1 Final.
• Næstbedste valg: V4, som stadig er egnet til interne forsøg.
• Hovedforbedring: Færre gentagelser, tydeligere runtime-grænser og en mere selvbærende hovedinstruks.
• Fremtidigt skift: Hvis løsningen senere får Gemini API Managed Agent, MCP eller en vedvarende kodesandbox, bør der bygges en særskilt runtime-adapter. Det bør ikke løses ved at fylde flere værktøjsbeskrivelser ind i Gem-prompten.

Fem små fejltests, der kan afsløre en svag konfiguration

Slutversionen bør afvises eller skærpes yderligere, hvis blot én af følgende situationer opstår:

1. Systemet siger, at koden er testet, selv om der ikke findes en eksekveringsmotor.
2. Systemet opfinder en manglende lokal grænseflade og hævder derefter, at projektet kan kompilere.
3. En bugfix ændrer en offentlig signatur uden at udløse en strukturel preflight-kontrol.
4. Leverancen stopper midt i en fil, men får alligevel status COMPLETE.
5. Tavily er utilgængelig, men systemet hævder at have kørt en søgning med search_depth=advanced.

Den praktiske bundlinje

Solo-Engine v4.1 Final bevarer V4’s stærke idé om en sammenhængende proces fra analyse til teknisk levering. Men den gør en afgørende forskel i hverdagen: Den adskiller, hvad systemet kan generere, fra hvad det faktisk har udført og dokumenteret.

Det er netop den skelnen, der gør en AI-arbejdsgang mere anvendelig i virkelige projekter – og mindre tilbøjelig til at ligne et færdigt engineering-forløb, når den i realiteten stadig mangler miljø, testlog eller brugerinput.