Claude Code greenfield-arbetsflöde: från tomt repo till första vertikala funktionen

Vad du vill undvika med en greenfield-start

Att börja i ett tomt repo känns som frihet, men det förvandlas ofta till rörig fart: massor av genererade filer, en halvbra build och ingen tydlig plats för nästa ändring. Poängen med ett Claude Code greenfield-arbetsflöde är att undvika det första veckans kaos.

Några återkommande misslyckanden:

• Kod som “funkar på min maskin” eftersom setup lever i någons minne, inte i skript.
• En mappstruktur som speglar ordningen filerna skapades, inte hur appen bör växa.
• En loop där varje ny prompt skriver om tidigare val, så inget blir stabilt.

Tidiga beslut är smärtsamma att ångra eftersom allt staplas ovanpå dem. En förvirrande struktur befästs hela tiden. En manuell build blir till tio olika uppsättningar. Om du inte låser in ett enkelt dev-kommando tidigt kan du inte veta om en förändring bröt appen eller bara miljön.

När det här inlägget säger “körbar app” menar det något specifikt: ett kommando som startar projektet, skriver ut förutsägbart output och felar högljutt när något saknas. Du ska kunna radera din lokala installation, klona repot, köra kommandot och se samma resultat.

En “vertikal funktion” är den minsta end-to-end-funktionen som bevisar att din app är verklig. Inte en UI-mock. Inte en databas-tabell i sig. Det är en tunn linje genom hela systemet, som en sida med ett formulär, ett API-endpoint som sparar data, en databas-skrivning och läsning, och ett synligt resultat tillbaka på sidan.

Om du kan köra appen med ett kommando och leverera en vertikal funktion har du en bas att iterera på utan gissningar.

Bestäm första skivan innan du genererar något

En tydlig första skiva håller ditt repo snyggt och dina prompts fokuserade. Detta är stunden att bestämma vad du vill demoa end-to-end, inte vad du hoppas att slutprodukten blir.

Välj den minsta användarberättelsen som bevisar att appen fungerar genom hela vägen. En bra skiva berör UI, data och en verklig handling. Exempel: “Som användare kan jag lägga till en uppgift och se den i en lista efter uppdatering.” Den är liten, men tvingar routing, validering, lagring och en grundläggande vy.

Välj en målplattform för vecka 1 och håll dig till den. Om du börjar webben, gör endast webben. Lägg inte till mobilskärmar “bara för säkerhets skull.” Även om du planerar att använda en plattform som Koder.ai senare, får du bättre resultat om första skivan håller sig i en fil (React webb, eller ett Go-API, eller Flutter).

Definiera vad “klart för vecka 1” betyder i enkla termer:

• Körs lokalt från en färsk clone med ett kommando
• En fungerande funktion du kan klicka igenom end-to-end
• Fel visar ett mänskligt meddelande (inte en stacktrace)
• Data persistens någonstans enkelt (även en lokal databas)

Skriv sedan ner tre icke-mål som skyddar omfattningen. Till exempel: ingen autentisering, inget temasystem, inga bakgrundsjobb.

När dessa beslut är nedskrivna kan din genereringsprompt vara strikt: bygg bara vad som stöder skivan och lämna allt annat som TODO.

Några beslut i förväg som sparar omarbete

Innan du ber Claude generera något, lås några standarder. De verkar små, men förhindrar att du “byter namn på allt senare”.

Först, bestäm appens form. Om du verkligen behöver en browser-UI och en backend, börja med två tydliga delar (frontend + API) och en gemensam plats för kontrakt (API-typer eller ett enkelt schema). Om appen kan vara server-renderad, behåll en kodbas så lokal utveckling förblir enkel.

Nästa, kom överens om konfigurationsregler. Använd en lokal env-fil, håll den utanför git, och committa en mall istället (t.ex. .env.example) med säkra platshållare och korta kommentarer. Det gör onboarding enklare och minskar risken för att hemligheter läcker.

Välj standarddev-portar och håll dem stabila. Portar hamnar i skript, dokumentation och felmeddelanden, så att byta dem senare är irriterande. Gör samma för namngivning: mappar, tjänster och paket bör följa en konvention. Konsekvens är viktigare än en “perfekt” konvention.

En enkel uppsättning beslut att börja med:

• Appens form: en app eller frontend + API
• Konfig: .env lokalt, .env.example committad
• Portar: en för webben, en för API, en för DB (om behövs)
• Namn: en casing-stil för mappar, konsekventa tjänstenamn
• Hemligheter: aldrig committas, roteras om de exponeras

Exempel: du väljer web på port 3000 och api på port 8080. Din env-mall innehåller API_URL=http://localhost:8080 och DATABASE_URL=.... När Claude genererar skript och docs senare faller allt på plats istället för att drifta.

Hur du promptar Claude Code så det håller struktur

Börja med att be om ett körbart skelett, inte “hela appen.” Den snabbaste vägen till rörigt resultat är att be om features innan du har en plats för dem.

Var explicit om struktur. Be om en mapplayout med korta kommentarer som förklarar vad som hör hemma var, och vad som inte gör det. Det tvingar fram beslut tidigt istället för att sprida filer på måfå.

Ett enkelt sätt att hålla disciplin är att sätta regler i prompten:

• Generera minsta körbara skelett först (hello-sida, health-endpoint eller en skärm).
• Föreslå en mappstruktur och förklara varje mapp i en mening.
• Lägg till skript som fungerar på en färsk maskin (install, dev, test, build) och ange förutsättningar.
• Håll ändringar i en PR-storlek och lista exakt vilka filer som skapas eller ändras.
• Stanna efter scaffolding och berätta hur jag kör det.

Här är en prompt du kan återanvända och anpassa:

You are working in an empty repo. Create a minimal runnable skeleton.

Constraints:
- Keep it small: no real features yet.
- Propose a clear folder structure and add brief comments in each folder’s README.
- Add scripts for: setup, dev, test, build. They must work on a fresh machine.
- Tell me exactly how to run it, and what output I should see.
- After generating, stop and wait for my “ran it” confirmation.

Output:
1) File tree
2) Key files (only)
3) Run instructions

Håll looparna korta. Be inte om fem förändringar på en gång. Generera en liten ändring, kör den, klistra in det exakta felet (eller framgången), och be sedan om en minimal fix. Denna generate-run-adjust-rytm håller projektet förutsägbart och gör det svårare för strukturen att drifta.

Steg för steg: från tomt repo till ett körbart skelett

Börja med ett löfte: vem som helst ska kunna klona repot och köra ett kommando för att se något fungera. Det ger en stabil bas innan du ber en AI lägga till riktiga features.

Skapa repot och skriv en liten README medan allt är nytt. Håll den praktisk: förutsättningar, det enda dev-kommandot och hur man kör tester (även om testerna är tomma för nu).

Välj sedan en top-level-layout som matchar appens form.

Om du bygger flera deploybara delar (till exempel frontend + API) kan en workspace-layout hjälpa:

/
  apps/
  packages/
  scripts/
  docs/
  README.md

Om du bygger en enda app, håll det enklare och undvik extra nivåer tills du behöver dem.

Nu lägg till minimala guardrails så koden förblir konsekvent. Välj en formatter och en linter, acceptera deras standarder och lägg till en enkel konfigurationsfil för vardera. Målet är rena diffs, inte perfekta regler på dag ett.

Gör utvecklarupplevelsen förutsägbar med ett kommando som alltid fungerar från repo-roten. Här är en enkel form:

{
  "scripts": {
    "dev": "echo \"start dev server here\"",
    "build": "echo \"build here\"",
    "test": "echo \"tests here\"",
    "lint": "echo \"lint here\""
  }
}

Innan du genererar något annat, kör det dev-kommandot, bekräfta att det avslutas rent (eller startar en platshållarserver), och gör din första commit med endast scaffolding. Om en kollega (eller framtida du) kan reproducera setupen från scratch är du redo att bygga första skivan.

En mappstruktur du kan behålla när appen växer

En bra greenfield-struktur gör två saker: den hjälper dig hitta kod snabbt och minskar utrymmet för Claude att hitta på nya mönster varje gång du ber om en ändring. Målet är inte perfektion. Det är stabilitet.

Om du jobbar i en singelapp (eller i en apps/<name>/-mapp) håller en enkel intern layout ofta väl:

• src/ applikationskod (features, delade delar, entry points)
• config/ icke-hemlig konfiguration
• tests/ högre nivå-tester som läses som användarbeteende
• scripts/ hjälpskript (dev-setup, db-reset, release-uppgifter)
• docs/ korta anteckningar och checklistor du faktiskt underhåller

Inuti src/, separera feature-kod från delad kod baserat på hur ofta de förändras. Feature-kod ändras ofta och bör ligga nära varandra. Delad kod ska vara tråkig och återanvändbar.

En praktisk regel: lägg UI-skärmar, handlers och feature-specifik logik under src/features/<featureName>/.... Lägg saker som logging, API-klienter, design-systemkomponenter och generella hjälpmedel under src/shared/.... Om en hjälpare bara passar en feature, behåll den där även om den ser återanvändbar ut. Flytta den senare när du har ett andra verkligt användningsfall.

Mappnamn bör beskriva syfte, inte teknik. “features” och “shared” förblir meningsfulla när stacken ändras. Undvik namn som “misc” eller “new”.

Håll docs/ liten. En bra start är en docs/checklists.md med några rader: hur man kör, hur man testar, hur man lägger till en ny feature-mapp och vad “klart” betyder.

Byggskript som gör projektet förutsägbart

Ett repo känns verkligt när vem som helst kan köra samma kommandon och få samma resultat. Skript är ledstänger: de minskar gissningar, håller ändringar små och gör det tydligt när något gick sönder.

Börja med en liten uppsättning kommandon och håll dem tråkiga. Om någon ny ansluter (eller du kommer tillbaka om två veckor) ska de inte behöva specialflaggor eller dolda steg.

Här är en enkel baseline du kan anpassa till vilken stack som helst:

{
  "scripts": {
    "dev": "node ./scripts/dev.js",
    "build": "node ./scripts/build.js",
    "test": "node ./scripts/test.js",
    "test:quick": "node ./scripts/test.js --quick",
    "test:full": "node ./scripts/test.js --full",
    "format": "node ./scripts/format.js",
    "lint": "node ./scripts/lint.js",
    "smoke": "node ./scripts/smoke.js"
  }
}

Gör dev-skriptet till den lyckliga vägen. Det bör starta appen, skriva ut var den körs och hålla loggar läsbara. Om servern inte kan starta, faila snabbt med ett tydligt meddelande (saknad env-variabel, port upptagen, databas nåbarhet saknas).

Build-skriptet ska alltid skapa en ren output-mapp. Radera gamla output först, producera sedan färska artefakter. Det undviker konstiga buggar som orsakas av gårdagens filer.

För tester, dela snabba kontroller från långsamma. Snabba tester körs vid varje ändring (unit-tester, typkontroller). Fulla tester inkluderar integrationstester och körs före merge.

Håll stil konsekvent med ett kommando. En enkel regel är: format fixar saker, lint klagar på saker.

Slutligen, lägg till en smoke-check som validerar grunderna innan du slösar tid på debugging:

• Nödvändiga env-variabler är satta (och inte tomma)
• Valda portar är fria
• Appen kan starta och svara på en enkel förfrågan
• Databasanslutning fungerar (om används)
• Build-output finns efter build

Bygg den första vertikala funktionen

Din första vertikala funktion ska bevisa att appen fungerar end-to-end, inte bara att UI ser bra ut. Det betyder en liten funktion som berör skärmen, logiken och någon form av lagring, även om lagringen är temporär.

Välj något tråkigt och användbart, som “Lägg till en anteckning” eller “Skapa en uppgift.” Håll det tillräckligt litet för att bli klart i ett pass, men tillräckligt komplett för att du ska kunna klicka runt och se verklig state-ändring.

En bra skiva har fyra delar: en rutt eller skärm, ett formulär, en spara-åtgärd och en visning. Exempel: en “Ny uppgift”-sida med ett titel-input, en Spara-knapp som anropar en funktion och en lista som visar sparade uppgifter.

Börja med en platshållarlagring så du kan gå snabbt. En in-memory-array, en lokal JSON-fil eller ett enkelt stub-interface duger. Nyckeln är att skapa gränssnittet du senare byter ut. Om din kod idag anropar taskRepository.save(task), blir det att byta till riktig databas en liten förändring istället för en omskrivning.

Håll UI enkelt. Hoppa över designsystem-debatter, empty states och animationer.

Acceptanskontroller du kan göra på två minuter:

• Sidan öppnas utan fel
• Du kan skriva in ett värde och trycka Spara
• Det nya objektet visas omedelbart
• Reload visar förväntat beteende (persistens om riktig lagring, reset om falsk)
• Fel input hanteras (tom titel visar meddelande och sparas inte)

Gör det tillräckligt stabilt för iteration

Efter att du har ett körbart skelett och en vertikal funktion skiftar målet: gör fel uppenbara och fixarna snabba. Här faller många greenfield-startar isär, inte för att funktionen är svår, utan för att små ändringar börjar orsaka överraskningar.

Sätt en liten stabilitetsnivå du möter varje gång du lägger till en skiva:

• Ett smoke-test som bevisar att appen bootar och huvudrouten/skärmen renderar
• Ett smoke-test som träffar skivan end-to-end (även om det använder en testdatabas)
• Tydliga felmeddelanden en normal användare kan agera på (inte stacktraces)
• Dev-loggar som förklarar vad som hände utan att skriva ut hemligheter
• Minimala beroenden, versioner pinnade, uppgraderingar gjorda med avsikt

Konkreta exempel: din första skiva låter en användare skapa ett “Project” och se det i en lista. Lägg till ett test som startar servern, anropar create-endpoint, hämtar listan och kontrollerar att nya objektet finns. Om det faller ska det göra det högljutt med ett hjälpsamt meddelande, som “Create Project endpoint returned 500”, inte en vägg av output.

För felhantering, håll dig till ett litet set av konsekventa svar. Valideringsfel returnerar ett kort meddelande (“Name is required”) och ett fältnamn. Ovntedda fel returnerar “Något gick fel. Försök igen.” Spara detaljer i loggar.

Logging är mest användbart när det svarar: vilken förfrågan, vilken användare (eller anonym), vad misslyckades och var. I dev inkludera en request id och timing, men undvik att dumpa tokens, lösenord, API-nycklar eller fulla payloads som standard.

Lägg till en liten health-check. På webben kan det vara en /health-endpoint som returnerar ok. På mobil kan det vara ett “Connected”-läge som blir “Offline” när appen inte når backend. Det är en snabb signal innan du börjar debugga fel sak.

Vanliga fallgropar när man använder AI för greenfield-projekt

Det snabbaste sättet att slösa en greenfield-start är att be modellen om en hel app och sedan bara köra den senare. Stora generationer döljer små misstag: saknade beroenden, fel importvägar, skript som antar verktyg du inte har. Behandla varje output som något du bör kunna köra inom några minuter.

En annan fallgrop är att designa perfekt arkitektur innan det finns en funktion. Debatter om mappnamn känns produktiva, men utan en riktig skiva kan du inte veta vad som blir opraktiskt. En enkel struktur som stöder en fungerande väg slår en smart struktur du inte testat.

Command-drift är också vanligt. AI lägger till ett nytt sätt att starta servern, du lägger till ett annat för tester, och snart vet ingen vilket som är “det” kommandot. Om en kollega klonar repot och frågar “Hur kör jag detta?”, betalar du redan ränta.

Misstag som orsakar mest omarbete:

• Generera flera tjänster, skärmar och konfigurationer i ett svep istället för att bygga en körbar väg först
• Dra in auth, betalningar, komplex styling och en full datamodell innan första funktionen fungerar end-to-end
• Låta setup-instruktioner leva i chatten istället för skript (eller en README)
• Glömma en ren env-mall, så nästa maskin inte kan starta utan gissningar

Ett enkelt exempel: du genererar en “komplett” app med inlogg, theming och billing, men första körningen misslyckas eftersom en sekret nyckel saknas och det inte finns någon .env.example. Du spenderar då en timme på setup istället för att lära dig om funktionen är användbar.

Håll det ärligt: ett körbart kommando, en liten funktion, en env-mall, sedan expandera.

Snabb checklista innan du börjar iterera

Innan du lägger till “en funktion till”, se till att projektet är lätt att plocka upp imorgon (eller av någon annan). Hastighet är inte målet i sig. Förutsägbarhet är.

• Ett-kommandos-körning: en ny dev kan kopiera en env-mall, sätta de få nödvändiga värdena och starta appen med ett enda kommando. Om det behövs extra steg (DB-setup, migrationer, seed-data) fånga dem i ett skript.
• Skript täcker grunderna: tydliga kommandon för dev, test, build och en snabb smoke-check.
• Tydlig struktur: layouten berättar en historia (appkod, config, skript, tester) utan att läsa hela kodbasen.
• Vertikal skiva demo-väg: du kan beskriva demon i en mening, t.ex. “skapa ett objekt, se det i en lista, uppdatera sidan, det finns kvar.”
• Återställningspunkt: före stora förändringar har du en säker punkt att återgå till (en ren commit, en tagg eller en snapshot/rollback-mekanism).

Om något misslyckas, fixa det nu. Strama upp skript och namngivning är billigt när repot är litet.

Nästa steg: gör arbetsflödet återupprepbart

En greenfield-start betalar sig bara om du kan upprepa den. Efter att din första vertikala funktion körts end-to-end, frys de bra delarna till en liten mall: samma mappmönster, samma skriptnamn och samma sätt att koppla UI, API och data.

Behandla din första skiva som en referensimplementation. När du börjar skiva #2, kopiera formen, inte koden. Om skiva #1 har en rutt, en handler, ett dataaccesslager och ett grundtest, bör skiva #2 följa samma väg.

Håll planeringen lättviktig. En enkelsidig anteckning räcker för nästa 2–3 skivor: mål och användarhandling för varje skiva (en mening), data du behöver, “done”-kontroller och risker att testa tidigt.

Gör sedan underhåll till en vana. En gång i veckan gör en kort städpass: tajta skript, uppdatera README med nya setup-steg och fräscha upp env-mallen så onboarding förblir enkel.

Om du föredrar en chatt-först bygg-loop är Koder.ai (koder.ai) ett alternativ som stödjer planning-läge plus snapshots och rollback, och det kan exportera källkod när du vill ta projektet vidare.

Målet är ett arbetsflöde du kan köra utan att tänka: planera 2–3 skivor, bygg en skiva, stabilisera, upprepa.