Så använder du ChatGPT och Codex tillsammans – steg för steg

Det är lätt att tänka att AI-verktyg ska lösa så mycket som möjligt på egen hand. I praktiken blir arbetet ofta bättre när verktygen får olika roller och när människan behåller kontrollen över nästa steg.

Här är ett praktiskt arbetssätt som vi själva har kommit fram till genom användning. ChatGPT hjälper dig att tänka, avgränsa och formulera uppgiften. Codex arbetar sedan i det verkliga projektet. Efteråt kan ChatGPT hjälpa dig att läsa Codex rapport kritiskt, medan du själv testar resultatet och avgör om ändringen är klar.

Kort sagt:

Du → ChatGPT → Codex → ChatGPT → du → test → commit → nästa steg

Det är inte det enda sättet att använda verktygen, och det är inte ett officiellt namngivet OpenAI-arbetsflöde. Andra Codex-användare beskriver närliggande uppdelningar mellan planering i ChatGPT och genomförande i Codex. Vår poäng här är att göra hela loopen lätt att följa – även för den som aldrig har arbetat så tidigare.

ChatGPT och Codex gör olika jobb

ChatGPT passar bra när du vill prata igenom en idé på vanligt språk. Du kan fråga vad som verkar rimligt, jämföra alternativ, reda ut ett problem och få hjälp att dela upp en uppgift. Det kan vara särskilt värdefullt när du vet vad du vill uppnå men ännu inte vet exakt hur förändringen bör beskrivas tekniskt.

Codex passar när uppgiften är tydligt avgränsad och ska genomföras i ett faktiskt projekt. Codex kan, i stödda miljöer, läsa relevanta filer, göra den beslutade ändringen, köra begärda kontroller och rapportera vad som hände.

Det betyder inte att ChatGPT bara är till för nybörjare eller att Codex alltid ska arbeta utan eftertanke. Det handlar om arbetsfördelning. ChatGPT kan vara resonemangs- och planeringslagret. Codex kan vara det praktiska lagret som arbetar med projektet. Du är den som avgör mål, gränser, test och godkännande.

Ett enkelt exempel – en metod som kan skalas

För att göra flödet tydligt använder vi en medvetet enkel, påhittad boklista. Projektet kan redan lägga till böcker och visa dem i en lista. Nu vill användaren lägga till funktionen Markera som läst.

Exemplet är litet med flit. Det handlar inte om att boklistan är svår. Det handlar om att se arbetsordningen: först förstå ändringen, sedan be om en smal implementation, därefter granska och testa.

Samma metod kan användas i större projekt med många filer, databaser, API:er, autentisering, tester, felsökning, refaktorering, arkitekturförändringar, migrationer och dokumentation. Ju större projektet är, desto mer värdefullt blir det att sätta en tydlig gräns för varje steg och att ha verkliga kontrollpunkter mellan stegen.

Arbetsflödet i sju enkla steg

1. Beskriv idén eller problemet för ChatGPT med vanliga ord.
2. Resonera om vad som ska göras, vad som inte ska ändras och hur resultatet ska testas.
3. Låt ChatGPT formulera en tydlig, avgränsad instruktion till Codex.
4. Kopiera instruktionen till Codex, som arbetar i projektet och rapporterar tillbaka.
5. Kopiera Codex rapport tillbaka till ChatGPT för granskning mot uppdraget.
6. Testa själv det verkliga resultatet och låt vid behov Codex göra en read-only-kontroll – alltså en kontroll där Codex bara granskar och inte ändrar något.
7. Först när ändringen är godkänd: kontrollera diffen – översikten över exakt vad som har ändrats – gör commit och välj nästa avgränsade uppgift.

Flödet behöver ingen avancerad integration. I sin enklaste form är det bara genomtänkt copy-paste mellan två verktyg och en människa som hela tiden har sista ordet.

Du måste inte fortsätta bara för att Codex har gjort en ändring. Om rapporten ser konstig ut, resultatet inte känns rätt, något är oklart eller du vill tänka om, kan du stanna där och diskutera nästa steg med ChatGPT innan något mer görs. Människan styr när processen går vidare.

Börja med att prata med ChatGPT

Du behöver inte kunna formulera en perfekt teknisk specifikation från början. Börja hellre med vad du faktiskt försöker uppnå och vad du är orolig för.

I boklisteexemplet kan du skriva:

Jag vill kunna markera en bok som läst. Jag vill göra det steg för steg så att vi inte råkar påverka resten av projektet.

Ett bra samtal fortsätter sedan med enkla kontrollfrågor. Vad ska användaren se när en bok är läst? Ska funktionen gå att ångra? Vilka delar ska uttryckligen lämnas oförändrade? Hur kan man prova resultatet när ändringen är klar?

Det viktiga är inte att skapa en lång plan. Det viktiga är att hitta ett lagom första steg. Ibland kan det vara att bara be Codex läsa projektet och rapportera vilka filer som verkar relevanta. I andra fall är uppgiften redan tydlig nog för att gå direkt till en smal ändring.

Låt ChatGPT formulera Codex-uppgiften

När ni har rett ut uppgiften kan ChatGPT hjälpa dig att skriva en instruktion som är konkret nog att arbeta efter. En bra instruktion talar både om vad som ska göras och vad som inte ska göras.

Det minskar risken för att en liten önskan, som att markera en bok som läst, utvecklas till en oönskat stor ombyggnad. Den hjälper också Codex att lämna en rapport som går att jämföra med det du faktiskt bad om.

Det är helt rimligt att be ChatGPT om flera versioner: en kortare, en mer försiktig eller en som först bara gör en read-only-analys. Instruktionen är din beställning till Codex. Läs den innan du kopierar den vidare och justera om den inte stämmer med din avsikt.

Kopiera instruktionen till Codex

Här är en enkel, fiktiv kopieringsruta för boklistan:

Arbeta i det aktuella boklisteprojektet.

Läs först de filer som är relevanta för hur en bok visas och uppdateras.
Lägg sedan till den minsta nödvändiga funktionen för att markera en bok som läst.

Ändra inte andra funktioner eller gör någon bred refaktorering.
Kör relevanta tester eller kontroller om de finns.
Gör ingen commit.

Rapportera när du är klar:
- vilka filer som ändrades
- vad som ändrades
- vilka tester eller kontroller som kördes och resultatet
- eventuella begränsningar eller öppna frågor

Stanna därefter.

Rutan är enkel men innehåller flera viktiga skyddsräcken. Codex ska läsa först, begränsa ändringen, köra relevanta kontroller, avstå från commit och återrapportera tydligt. Om din situation kräver fler gränser ska de stå med: exempelvis att ett API-kontrakt måste behållas eller att en viss fil inte får ändras.

Codex arbetar och rapporterar tillbaka

När Codex får instruktionen kan det arbeta i projektet och sedan lämna en rapport. En rapport kan vara kort, men den ska göra det lätt att se vad som faktiskt har gjorts.

Så här kan en fiktiv rapport se ut i boklisteexemplet:

Klart.

Ändrade filer:
- src/books.js
- tests/books.test.js

Gjort:
- lade till ett fält som sparar om en bok är läst
- lade till en åtgärd för att markera en bok som läst
- uppdaterade visningen så att lästa böcker får en tydlig status

Kontroller:
- tester: 14/14 godkända

Ingen commit skapades.

Det här är bara ett pedagogiskt exempel. Siffran 14/14 är inte ett verkligt testresultat och ska inte läsas som bevis för något verkligt projekt. I ditt eget projekt måste rapportens filnamn, ändringar och testresultat komma från Codex faktiska arbete.

Kopiera Codex svar tillbaka till ChatGPT

Nästa steg är inte att automatiskt godkänna rapporten. Kopiera i stället rapporten tillbaka till ChatGPT tillsammans med den ursprungliga uppgiften. Då kan ChatGPT hjälpa dig att jämföra de två texterna.

Ett sunt svar från ChatGPT kan till exempel vara:

Rapporten verkar följa uppdraget: den beskriver en begränsad ändring, nämner två filer, redovisar tester och säger att ingen commit skapades. Innan du godkänner bör du ändå kontrollera att markeringen visas rätt i gränssnittet och att en bok fortfarande går att lägga till som tidigare.

ChatGPT kan hitta en lucka i rapporten, be dig tänka på ett specialfall eller formulera en ny kontrollinstruktion. Det betyder inte att ChatGPT automatiskt har sett dina lokala filer. Det har bara fått den information du har klistrat in.

Granska och testa innan nästa steg

Om något behöver kontrolleras kan ChatGPT hjälpa dig att skriva en ny, read-only-instruktion till Codex. Till exempel:

Gör inga ändringar och skapa ingen commit.

Kontrollera om funktionen Markera som läst påverkar möjligheten att lägga till en ny bok eller visa befintliga olästa böcker.
Granska de relevanta filerna och testerna.

Rapportera endast vad du kontrollerade, resultatet och eventuella risker.
Stanna därefter.

Sedan testar du också själv den verkliga funktionen. Öppna boklistan. Lägg till en bok. Markera den som läst. Kontrollera att statusen syns och att resten av flödet fortfarande fungerar. Det mänskliga testet är viktigt eftersom en rapport och automatiska tester inte alltid fångar om resultatet är begripligt, ser rätt ut eller passar ditt faktiska behov.

Principen är enkel: Codex utför. ChatGPT hjälper till att granska. Människan testar och godkänner.

Commit först när du är nöjd

En commit är en kontrollpunkt i Git-historiken. Därför är det ofta klokt att under utvecklingssteget uttryckligen säga till Codex: gör ingen commit.

När du har granskat och testat ändringen kan nästa, separata instruktion i stället handla om att kontrollera diffen och stagea, alltså välja vilka ändrade filer som ska ingå i nästa commit. Därefter kan Codex skapa en tydlig commit. Genom att hålla det separat minskar du risken för att något hamnar i versionshistoriken innan du har hunnit förstå och godkänna det.

En enkel kontroll före commit kan vara: Stämmer diffen med uppgiften? Är bara de avsedda filerna med? Har testerna körts? Är commit-meddelandet begripligt för dig eller en kollega som läser historiken senare?

Exemplet i korthet

Se boklistan som en liten pingpongmatch, inte som en lång kedja där AI tar över: ChatGPT hjälper dig att avgränsa uppgiften och formulera instruktionen, Codex gör den lilla ändringen och rapporterar, ChatGPT hjälper dig att granska rapporten, och du testar innan commit.

När markeringen fungerar kan nästa avgränsade uppgift vara att låta användaren ångra den, filtrera lästa böcker eller förbättra utseendet. En sak i taget gör varje steg lättare att överblicka.

Samma metod – helt olika nivåer

Samma loop kan fungera för både nybörjare och erfarna utvecklare, men uppgifterna låter olika.

En nybörjare kan säga: Jag vill kunna markera en bok som läst, men jag vet inte vilka filer som behöver ändras. ChatGPT kan hjälpa till att omvandla idén till ett lugnt första steg, exempelvis att Codex först kartlägger relevanta filer utan att ändra något.

En van användare kan säga: Jag vill lägga till funktionen utan att påverka befintligt beteende. Kan vi först reda ut hur den bör byggas? Här kan ChatGPT fungera som samtalspartner inför en mer precis instruktion och hjälpa till att formulera vilka kontroller som ska göras.

En erfaren utvecklare kan säga: Ändringen ska behålla API-kontraktet, vara bakåtkompatibel och inte påverka befintliga integrationstester. ChatGPT ersätter inte den personens tekniska kunskap. Däremot kan det vara ett extra lager för resonemang, planering och granskning innan och efter Codex arbete.

I alla tre fallen är ordningen densamma: diskutera, avgränsa, instruera, utför, rapportera, granska, testa, commit.

Så skalar arbetsflödet till större projekt

I ett större projekt är det sällan klokt att skriva: Förbättra hela mitt projekt. Uppgiften är för bred för att du enkelt ska kunna granska resultatet. Dela i stället upp arbetet i tydliga pass: kartläggning, beslut om lösning, liten implementation, test, granskning och nästa pass.

Det kan handla om en databasändring, ett API, en inloggningsfunktion, en felsökning eller en större refaktorering. Då blir instruktionerna ofta mer exakta: vilka system som berörs, vilka kontrakt som måste behållas, vilka tester som är relevanta och vilka delar som inte får ändras.

Samma grundregel håller: be om tillräckligt mycket arbete för att komma framåt, men inte så mycket att det blir svårt att förstå vad som har hänt. Tydliga delmål gör det också enklare att avbryta, korrigera kursen eller be om ytterligare kontroll innan nästa ändring.

Git och GitHub som säkerhetsnät

Git är ett verktyg för versionshistorik. Med commits kan du skapa begripliga kontrollpunkter i ett projekt och se vilka ändringar som hör ihop. Git kan användas helt lokalt på din dator.

GitHub är en tjänst för att lagra Git-repositories på distans och för samarbete. Det ger också en kopia av repositoryt utanför din egen dator, men bör inte ses som en komplett backupstrategi för all projektdata. GitHub behövs inte för att använda Codex eller Git.

Innan du pushar ett befintligt projekt till GitHub för första gången behöver du kontrollera vad projektet innehåller. Leta särskilt efter `.env`-filer, API-nycklar, tokens, lösenord, privata nycklar och certifikat, databaser, personuppgifter, loggar, uploads och annan driftdata. Kontrollera också `.gitignore` så att känsliga eller onödiga filer inte följer med.

En enkel och försiktig rytm är därför: utveckla utan commit, testa och granska, kontrollera diffen, stagea exakt rätt filer, skapa commit och bestäm sedan om projektet ska delas till en fjärrtjänst.

Vanliga misstag

Att ge Codex en jättestor uppgift direkt. Undvik formuleringar som Förbättra hela mitt projekt. Prata igenom målet först och dela upp arbetet i mindre delar.

Att vara otydlig med gränserna. Säg vad Codex ska ändra, vad som inte ska ändras och vilka kontroller som är viktiga. En liten uppgift med tydliga ramar är lättare att granska än en stor, vag begäran.

Att göra commit för tidigt. En commit kan vara lätt att ångra, men den blir ändå en del av projektets historia. Testa och granska först.

Att lita blint på rapporten. Rapporten är ett värdefullt underlag, men inte automatiskt bevis för att ändringen fungerar i verkligheten. Jämför den med uppdraget, läs diffen när det behövs och testa själv.

Att göra för många saker samtidigt. En tydlig sak åt gången gör fel lättare att hitta och gör det enklare att avgöra vilken ändring som faktiskt gav ett visst resultat.

Slutsats – Tänk högt först. Bygg sedan.

Det viktigaste är inte att låta AI göra så mycket som möjligt. Det viktiga är att låta AI göra rätt saker, i rätt ordning, medan människan behåller kontrollen.

Använd ChatGPT för att tänka högt, ställa frågor och skriva en tydlig beställning. Använd Codex för att göra den avgränsade uppgiften i projektet och rapportera tillbaka. Granska, testa och gör commit först när du själv är nöjd.

Tänk högt först. Bygg sedan.

💬 Vad tycker du?

Hur skulle ett tydligt, avgränsat arbetsflöde med ChatGPT och Codex fungera i ditt projekt?

Dela gärna dina tankar i kommentarerna.

📚 Relaterade artiklar