AI-arbeidsflyt

Dette prosjektet ble bygget med Claude Code. De fleste «bygget med AI»-påstander stopper ved merkelappen. Her er det fulle bildet: hva AI-en vet, hvordan økter fungerer, hvordan prompting ser ut i praksis, og hvor mennesket trekker grensen. Hvis du bygger med AI selv, eller bare er nysgjerrig på hvordan det faktisk ser ut, er dette for deg.

Hva AI-en vet

Claude Code har en persistent minnefil som bærer kontekst mellom økter. I stedet for å utforske kodebasen på nytt i hver samtale, fortsetter den der vi slapp. Her er hva den inneholder (anonymisert):

Prosjektidentitet

Appnavn, kildeplassering, lisens, app-identifikator
Fork-forhold: upstream er En Croissant av Francisco Salgueiro, vi vedlikeholder vår egen fork uavhengig
Hvorfor forken eksisterer: upstream-vedlikeholderen avslo TTS-funksjonen, noe som er rettferdig — forskjellige visjoner for det samme prosjektet

Byggeregler

Kun pnpm — npm ødelegger vanillaExtract (hvit skjerm ved kjøring, ingen feilmelding, bare ingenting)
Node.js 22+ påkrevd (Vite 7 trenger crypto.hash)
Alltid pnpm format && pnpm lint:fix før committing
Lukk appen før du overskriver binærfilen («Text file busy»)
Etter flytting av kildemappe, cargo clean for å fjerne foreldede stireferanser

Arkitekturkunnskap

Hvilke filer eier hvilke funksjoner (atomer i atoms.ts, trenavigasjon i tree.ts, TTS-motor i tts.ts)
Hvorfor alle TTS-atomer trenger getOnInit: true (imperative lesinger via store.get() før React abonnerer)
Hvordan lydcachen fungerer (provider:voiceId:lang:text-nøkler)
Chessground-koordinatfiksen er på CSS-siden, ikke en fork av biblioteket
Dataoppsett: hva ligger hvor, hva er symlinket, hva overlever omstart av appen

Hva den ikke vet

Minnet inneholder ikke API-nøkler, passord eller legitimasjon. Det refererer til lagringsplasseringene deres (localStorage-atomnavn), men aldri verdiene. AI-en genererer kode som leser nøkler fra innstillinger — den ser eller håndterer aldri de faktiske hemmelighetene.

Hva AI-en får beskjed om

Utover minnefilen følger Claude Code regler som er innebygd i systemet:

Ikke overingeniør. Gjør bare endringer som er direkte forespurt. En feilretting trenger ikke at omkringliggende kode ryddes opp. Tre lignende kodelinjer er bedre enn en forhastet abstraksjon.
Ikke gjett URL-er. Aldri fabrikere lenker eller endepunkter.
Les før du redigerer. Aldri foreslå endringer i kode den ikke har lest.
Foretrekk redigering fremfor opprettelse. Ikke opprett nye filer med mindre det er absolutt nødvendig.
Ingen sikkerhetssårbarheter. Se opp for injeksjon, XSS og OWASP topp 10-problemer.
Spør ved usikkerhet. Hvis en instruksjon er tvetydig, spør i stedet for å gjette.
Mål to ganger, kutt én gang. Destruktive operasjoner (force push, reset —hard, sletting av filer) krever eksplisitt godkjenning fra mennesket.

Å skrive gode prompter

Forskjellen mellom en nyttig AI-interaksjon og en frustrerende er nesten alltid prompten.

Vær spesifikk om hva du vil. Ikke «fiks feilen», men «TTS-cachenøkkelen inkluderer ikke leverandørnavnet, så å bytte fra ElevenLabs til Google spiller av cachet ElevenLabs-lyd i stedet for å generere ny lyd.»

Inkluder kontekst AI-en ikke har. AI-en kan lese koden din, men den kan ikke lese tankene dine. «Brukeren rapporterte at koordinatene er baklengs på brettet» er mindre nyttig enn «CSS-en i chessgroundBaseOverride.css har rekker og linjer byttet om — Franciscos original hadde dem baklengs.»

Angi begrensningene dine. «Ikke opprett nye filer» eller «bruk det eksisterende atommønsteret» eller «dette må fungere uten en API-nøkkel» forteller AI-en hvor lederepene er.

Si hva du ikke vil. «Ikke legg til feilhåndtering for tilfeller som ikke kan oppstå» eller «ikke refaktorer omkringliggende kode» forhindrer overingeniøring — den vanligste AI-feilmodusen.

Mønsteret er: intensjon + kontekst + begrensninger. Mestre det, og AI-en blir dramatisk mer nyttig.

Planmodus: Bruke én Claude til å prompte en annen

Claude Code har en «planmodus» som skiller tenkning fra handling. I planmodus leser AI-en filer, utforsker kodebasen og produserer en plan — men skriver ingen kode. Du gjennomgår planen, justerer den, og bytter deretter til implementeringsmodus der AI-en utfører.

Hvorfor fungerer dette? Fordi den vanskeligste delen av enhver kodeoppgave ikke er å skrive koden. Det er å finne ut hvilken kode som skal skrives — hvilke filer som skal endres, hvilke mønstre som skal følges, hvilke spesialtilfeller som finnes. Planmodus dedikerer full oppmerksomhet til det spørsmålet før en eneste linje blir skrevet.

Fra dette prosjektet: da vi omstrukturerte Hjelp-menyen for å legge til språkvelgeren, utforsket planmodussamtalen hvordan Tauri-menyer fungerer, hvilke atomer som allerede fantes, hvordan dokumentviseren løste ressursstier, og hvordan bekreftelsesdialog-API-et så ut. Da vi byttet til implementering, hadde AI-en et komplett kart over endringene. Ingen falske starter.

Du bruker egentlig én instans av AI-en som seniorarkitekt og en annen som utvikler. Samme modell, ulike roller.

Hvordan økter fungerer

En typisk økt ser slik ut:

Mennesket angir intensjon. «Legg til cachingmerknad i KittenTTS-seksjonen.» «Fjern PostHog-telemetri.» «Kvalitetsvurderingene er feil, her er hva de bør være.»
AI-en leser de relevante filene. Den gjetter ikke hva som er i en fil. Den leser den, forstår nåværende tilstand, og foreslår deretter endringer. Flere filer leses parallelt når de er uavhengige.
AI-en gjør endringen. Målrettede redigeringer av eksisterende filer. Ikke omskrivinger — kirurgiske modifikasjoner som bevarer alt rundt dem.
Mennesket gjennomgår. Hver redigering vises før den lagres til disk. Mennesket godkjenner, avviser eller omdirigerer. «Nei, det er for mildt — si at det genuint suger.» «Flytt det avsnittet opp.» «Det var ikke det jeg mente.»
Commit når det blir sagt. AI-en committer aldri på eget initiativ. Mennesket sier «commit» eller «commit og push.» Commits inkluderer Co-Authored-By: Claude Opus 4.6 — alltid kreditert, aldri skjult.

Kontekstvinduer og lagringspunkter

Hver AI-samtale har et kontekstvindu — den totale mengden tekst den kan holde i minnet samtidig. Når samtalen blir lang nok, komprimeres eldre meldinger for å gi plass.

To strategier: hold samtalene fokuserte (én oppgave per samtale), og bruk lagringspunkter (Claude Code lagrer transkripsjoner som JSONL-filer du kan gjenoppta fra med full kontekst gjenopprettet). Minnefilen tjener et annet formål — den er en persistent kunnskapsbase som overlever på tvers av alle samtaler.

Hva AI-en foreslår vs. hva som leveres

AI-ens første forslag er sjelden den endelige versjonen. En typisk utveksling:

AI-en utkaster noe fornuftig
Mennesket sier «for korporativt» eller «vær mer direkte» eller «det er feil, her er hvorfor»
AI-en justerer
Mennesket godkjenner

Smaken, tonen og den endelige avgjørelsen er alltid menneskelig. AI-en håndterer hastighet — leser filer, forstår kontekst, gjør presise redigeringer på tvers av en kodebase den kan holde i minnet. Mennesket håndterer dømmekraft — hva som skal bygges, hvordan det skal føles, når det er nok.

Ferdigheter og skråstrekkommandoer

Claude Code støtter «ferdigheter» — gjenbrukbare prompter lagret som markdown-filer i .claude/commands/-katalogen. Du aktiverer dem med en skråstrekkommando, som /translate-docs.

Dette prosjektet bruker en /translate-docs-ferdighet som automatiserer oversettelse av dokumentasjon til flere språk. Ferdighetsfilen inneholder de fullstendige instruksjonene: hvilke filer som skal oversettes, hvilket format som skal brukes, hvordan kodeblokker og lenker skal håndteres, hvilken tone som skal opprettholdes. I stedet for å forklare alt dette hver gang, skriver du bare /translate-docs og AI-en vet nøyaktig hva den skal gjøre.

Ferdigheter koder prosess, ikke bare informasjon. Du kan bygge dem for enhver gjentakende arbeidsflyt: kjøre tester, deploye, gjennomgå PR-er, oppdatere endringslogger.

Kodeprinsipper

Det fullstendige prinsippdokumentet ligger i repoet på .claude/01_UNIVERSAL_PRINCIPLES.md. Det startet som Robert C. Martins Clean Code (2008) pluss tillegg for AI-æraen. Så hadde vi en ærlig samtale om hva som fortsatt holder og hva som ikke gjør det.

Hva som er tidløst

Intensjonsavslørende navn. Alltid. For alltid.
Funksjoner gjør én ting. Det egentlige prinsippet er koherens, ikke størrelse.
Ingen sideeffekter. Fortsatt kilden til de fleste feil.
Kommentarer forklarer hvorfor, ikke hva.
Enkeltansvar. En modul bør ha én grunn til å endres.
Programmer mot grensesnitt, ikke implementasjoner.
Ikke svelg feil. Hver feil er informasjon.
Fremvoksende design: kjører alle tester, ingen duplisering, uttrykker intensjon, minimerer kompleksitet. I den rekkefølgen.

Hva som er kontekstuelt

Disse prinsippene er solide, men de spesifikke reglene reflekterer en pre-AI- eller språkspesifikk verden. Vi anvender ånden, ikke bokstaven:

DRY. Duplisering som drifter fra hverandre er farlig. Men å trekke ut hvert gjentatt mønster til en abstraksjon skaper indireksjon som kan være verre. Noen ganger er tre lesbare linjer rett her bedre enn en forhastet abstraksjon i en annen fil.
Streng TDD-seremoni. Prinsippet — lever testet kode, vit at den fungerer — er ikke-forhandlingsbart. Seremonien — testen må eksistere før koden — ble designet for en arbeidsflyt der mennesker skriver sakte. Skriv tester. Sørg for at de passerer. Om testen eller koden kom først er mindre viktig enn om begge eksisterer.
Speiderprinsippen. «Forlat leirplassen renere» — ja. Men speideren ryddet opp leirplassen, ikke hele skogen. Fiks det du berører. Ikke refaktorer hele strukturen i en fil fordi du endret én linje i den.

Tillegg for AI-æraen

Prinsippbasert veiledning skalerer bedre enn regler. Prinsippet tillater skjønn; regelen er skjør.
Hvis agenten bygger det, kan agenten vedlikeholde det. Behold samtalekontekst og artefakter. Dokumenter byggeprosessen, ikke bare resultatet.
Tydelig over smart. Systemet som bygde dette må rekonstruere resonnementet og modifisere det korrekt. Eksplisitt struktur slår små smarte abstraksjoner.
Kan dette bli infrastruktur? Et verktøy løser et problem for deg. Infrastruktur gjør det mulig for andre å bygge oppå. Design deretter.

Hvor mennesket trekker grensen

AI-en er et verktøy. Et bemerkelsesverdig godt et. Men det er ting den ikke gjør:

Produktbeslutninger. Hvilke funksjoner som skal bygges, hva som skal kuttes, hvordan appen skal føles. «System-TTS-kvalitetsvurderingen bør si ‘akseptabel’ fordi den genuint suger» — det er en menneskelig vurdering basert på å faktisk lytte til den.
Smak. AI-en kan skrive ren prosa, men prosjektets stemme, beslutningen om å være ærlig om kvalitet, valget om å kreditere Francisco fremtredende — det er menneskelige valg.
Etikk. Å fjerne PostHog var ikke en refaktoreringsoppgave. Det var «innstillingssiden sier at vi ikke samler inn telemetri, men det er en aktiv PostHog API-nøkkel i koden. Det er en løgn. Fiks det.» AI-en utførte. Mennesket identifiserte problemet og brydde seg om det.
Sjakk. Brettet bryr seg ikke om verktøyene dine.

Hvorfor dele dette

Fordi «bygget med AI» har blitt meningsløst. Alle sier det. Ingen viser det. Det interessante spørsmålet er ikke om AI var involvert — det er hvordan den var involvert, og hva mennesket faktisk bidro med.

Dette er svaret. Mennesket bringer visjonen, smaken, dømmekraften og ansvarligheten. AI-en bringer hastigheten, hukommelsen og den utrettelige viljen til å lese Rust-feilmeldinger klokken to om natten.

Ingen av dem bygger dette alene. Begge krediteres. Det er avtalen.

En Parlant~ er en fork av En Croissant av Francisco Salgueiro, bygget med Claude Code av Anthropic.