Så bygger jag appar med AI som utvecklingspartner

Det bästa sättet jag har hittat att bygga med AI är att inte behandla AI som en magisk kodgenerator.

Jag får bäst resultat när jag använder AI som en utvecklingspartner: någon som kan resonera, strukturera, föreslå, skriva första versioner, granska kod och hjälpa till att hålla tempo. Men riktningen, prioriteringen och ansvaret måste fortfarande ligga hos mig.

Den här guiden beskriver hur jag brukar gå från idé till fungerande app med AI som stöd.

1. Börja med problemet, inte stacken

Det är lätt att börja med teknik:

• Next.js
• Prisma
• Docker
• PostgreSQL
• Tailwind
• React
• scheduler
• API
• adminpanel

Men det första steget bör vara mycket enklare:

Vad ska appen faktiskt lösa?

Jag försöker skriva ner problemet i vanlig svenska innan jag pratar om teknik.

Exempel:

Jag vill bygga en liten webbapp där jag kan skriva och publicera AI-byggen, prompts och guider. Den ska ha en publik sida, en skyddad admin-del, databas och Docker-drift. Det ska vara enkelt att skriva nytt innehåll och säkert nog att exponeras publikt.

När problemet är tydligt blir AI:n mycket bättre på att föreslå rätt struktur.

2. Definiera vad appen inte ska göra

Det här är nästan viktigare än kravlistan.

AI har en tendens att vilja bygga för mycket. Därför skriver jag alltid begränsningar.

Exempel:

Bygg inte multi-user SaaS.
Bygg inte betalflöden.
Bygg inte kommentarer.
Bygg inte AI-integration i första versionen.
Bygg inte filuppladdning ännu.
Prioritera säker grund, admin, innehållsmodell och Docker-drift.

Det hjälper AI:n att inte överbygga.

3. Be om arkitektur innan kod

Innan jag låter Codex bygga vill jag ha en plan.

Jag brukar be ChatGPT resonera fram:

• domänmodell
• routes
• databasmodeller
• säkerhetskrav
• Docker-upplägg
• teststrategi
• vad som ska vänta

Först när planen känns rätt låter jag Codex implementera.

Det sparar tid, eftersom man slipper backa ur felaktiga tidiga beslut.

4. Bygg i faser

Ett stort misstag är att ge AI en enorm prompt och hoppas att allt blir klart.

Det fungerar ibland, men det blir ofta svårt att granska. Jag föredrar faser.

Exempel på bra fasindelning:

1. Grundprojekt och Docker
2. Datamodell och migrations
3. Auth och admin-login
4. Inläggsmodell och admin CRUD
5. Publika sidor
6. RSS, sitemap och health
7. Designsystem
8. Editor och preview
9. Drift och backup

Varje fas ska kunna testas och committas.

5. Skriv prompts som en teknisk beställning

En bra byggprompt är inte bara en önskelista. Den ska innehålla:

• projektmål
• teknisk stack
• filstruktur
• säkerhetskrav
• vad som inte får ändras
• verifieringskommandon
• acceptanskriterier
• dokumentationskrav

Jag försöker skriva prompts som om jag lämnar över ett riktigt uppdrag till en senior utvecklare.

Exempel på tydlig instruktion:

Ändra inte datamodell.
Ändra inte auth/session.
Rör bara layout och komponenter.
Kör typecheck, lint, test och build.
Dokumentera vad som ändrades.

Det gör att AI:n jobbar mer kontrollerat.

6. Ha versionshantering från början

Git är extra viktigt när AI hjälper till.

Jag vill kunna backa efter varje fas.

Min regel:

git status
git add .
git commit -m "Beskriv fasen tydligt"
git push

Jag försöker aldrig låta flera stora refaktorer ligga ocommittade samtidigt.

Det gäller särskilt designfaser. AI kan snabbt ändra många filer, och då är det viktigt att ha en säker punkt att återgå till.

7. Låt AI bygga, men granska som vanligt

AI kan skriva mycket kod snabbt, men den ska inte slippa granskning.

Jag tittar särskilt på:

• har den ändrat saker utanför scope?
• har säkerhetslogik rörts?
• har den skapat duplicerad kod?
• har den lagt till onödiga dependencies?
• kör testerna?
• fungerar Docker?
• är dokumentationen uppdaterad?
• finns det hemligheter i repo?

Det är lätt att bli imponerad av mängden kod. Men mängd är inte samma sak som kvalitet.

8. Be AI skriva rapport efter varje fas

Efter varje större Codex-pass vill jag ha en rapport:

• vad ändrades?
• vilka filer?
• vad ändrades inte?
• vilka tester kördes?
• vad är nästa steg?
• finns kända begränsningar?

Det gör det mycket lättare att hålla projektet begripligt över tid.

En bra rapport är nästan lika viktig som koden.

9. Design kräver annan process

AI kan bygga design snabbt, men bra design kräver riktning.

Jag har märkt att “gör det snyggt” ofta leder till generisk AI-design:

• gradients
• mörka kort
• neon
• AI-buzzwords
• SaaS-layout

Bättre process är:

1. samla referenser
2. analysera designriktning
3. skapa designbrief
4. låta designverktyg utforska
5. låta Codex implementera tydligt specificerade faser

Design behöver alltså också arkitektur.

10. Bygg inte allt innan du använder appen

Det är lockande att direkt lägga till:

• sök
• AI-import
• bildhantering
• nyhetsbrev
• kommentarer
• avancerad admin
• analys
• automationer

Men den viktigaste frågan är:

Vad saknas när jag faktiskt använder appen?

För mrnicke.se blev svaret till exempel snabbt att admin-editorn behövde Markdown-preview. Det var mer värdefullt än en AI-integration i det läget.

Min standardordning för AI-byggen

När jag bygger en app med AI försöker jag följa den här ordningen:

1. Problem och mål
2. Avgränsningar
3. Arkitektur
4. Datamodell
5. Säker grund
6. Docker-drift
7. Minsta användbara funktion
8. Tester och dokumentation
9. Designsystem
10. Verklig användning
11. Små förbättringar baserade på verkliga behov

Det är inte snabbast på pappret, men det ger bäst kontroll.

Slutsats

AI gör det lättare att bygga appar, men det gör inte automatiskt appen bättre.

Det som fungerar bäst för mig är att använda AI som en strukturerad utvecklingspartner:

• tydliga prompts
• små faser
• hårda begränsningar
• verifiering
• dokumentation
• Git efter varje steg
• verklig användning innan nästa feature

Det är då AI går från att vara en rolig demo till att bli ett faktiskt verktyg i byggprocessen.