GitHub Copilot App: Hvordan skrivebordsappen endrer utviklerhverdagen

GitHub har gitt Copilot sitt eget skrivebord. Jeg har testet worktrees, Canvas og parallelle agenter i praksis, her er hva som faktisk endrer arbeidsdagen din.

Jeg har brukt Copilot inne i VS Code i to år. Denne uken installerte jeg noe helt annet: en frittstående app som ikke lever inni editoren, men ved siden av den.

Det høres ut som en detalj. Det er det ikke.

Hvorfor en egen app

Copilot inni VS Code er begrenset til ett prosjekt, én fil, ett fokus om gangen. Copilot App er bygget rundt en helt annen antagelse: at du har flere ting på gang samtidig, og at agentene dine bør kunne jobbe på dem uavhengig av hverandre.

Konkret betyr det at hver sesjon kjører i sitt eget git worktree. Jeg har nå tre agenter som jobber i samme repo parallelt, en som rydder opp i en gammel migreringsscript, en som skriver tester for en ny endpoint, og en tredje som svarer på PR-kommentarer fra i går. De tråkker ikke i beina på hverandre, fordi de rett og slett ikke deler samme filsystem-kopi.

Jeg testet dette først på Platform-Landingzone-repoet mitt, drøyt 72 000 linjer fordelt på Bicep, TypeScript og dokumentasjon, det jeg regner som en realistisk enterprise-størrelse. Ingen av agentene rørte hverandres branch. Ingen manuell branch-håndtering fra min side.

Canvas: der samarbeidet faktisk skjer

Det jeg brukte mest tid på å forstå var Canvas. Det er ikke en chattelogg. Det er en delt arbeidsflate der agenten og jeg kan se på det samme, samtidig, og begge kan justere.

Jeg brukte browser-canvas til å verifisere en frontend-endring live mens agenten jobbet. Ingen skjermdeling, ingen "vent litt skal jeg ta et screenshot". Agenten så nettopp det jeg så.

Det samme gjelder editor-canvas for markdown-dokumenter, eller terminal-canvas når jeg ville følge en lang bygge-prosess uten å måtte spørre "er du ferdig snart?" hvert tredje minutt.

Etter en uke med dette la jeg merke til noe jeg ikke forventet: jeg stiller færre statusspørsmål til agentene. Jeg ser det jo.

Modellvalget er blitt reelt

Tidligere valgte jeg modell én gang og glemte det. Nå bytter jeg faktisk, avhengig av oppgave.

Til rene kodeoppgaver med lang kontekst bruker jeg en av kodemodellene. Til andre oppgaver holder jeg meg til Sonnet-familien. Poenget er ikke hvilken modell som "vinner", poenget er at appen endelig gjør det billig å prøve begge på samme oppgave og sammenligne.

Hva koster dette faktisk deg i overgang

Jeg skal være ærlig om ulempene også, for det er lett å selge inn nytt verktøy uten å nevne friksjonen.

Første dag brukte jeg for mye tid på å finne ut hvor ting lå. VS Code-vanene mine, kommandopalett, snarveier, satt ikke. Andre uke gikk det bedre. Nå går jeg sjelden tilbake til den gamle arbeidsflyten for noe annet enn rask enkeltfil-redigering.

Verdt å nevne: parallelle worktrees krever litt mer diskplass enn du kanskje forventer, spesielt på store monorepo-er. Jeg holder nå et øye med det på et av mine repoer med mye binærdata.

Jas sin mening

Jeg installerte dette fordi jeg var nysgjerrig, ikke fordi jeg trengte enda et verktøy. Etter to uker er svaret mitt enkelt: det er ikke bare Copilot flyttet ut av editoren, det er en annen måte å tenke på hvor mange ting du kan ha gående samtidig uten å miste oversikten.

Neste artikkel i denne serien tar for seg Kimi K2.7 Code, den første åpne modellen i modell-pickeren, og hva den egentlig betyr for enterprise-sikkerhet.