Arbetsgången såg enligt uppgifterna ut så här:
Verktygen hade olika roller. Claude Code var gränssnittet för utvecklingen, GitHub fungerade som kodarkiv, Supabase stod för backend-funktionerna och Vercel skötte publiceringen. Tillsammans gjorde de det möjligt för Tan att gå från en skriven idé till en fungerande webbapp utan att först lära sig en traditionell programmeringsmiljö.
Tan räknade inte med att den första versionen skulle bli perfekt. Han testade appen, beskrev vad som saknades eller blev fel och bad Claude Code att ändra resultatet. Arbetet blev en återkommande cykel: instruera, granska, testa och förbättra.
Hans erfarenhet ledde till en enkel regel: otydliga instruktioner ger ofta otydliga resultat. Ju mer exakt han beskrev fält, behörigheter, beräkningar och användarupplevelse, desto mer användbart blev det som AI:n skapade. Claude Code kunde i regel förstå även ofullständig eller ”bruten” engelska, men att förstå en fråga var inte samma sak som att frågan innehöll alla nödvändiga detaljer.
Det är en viktig skillnad för den som vill använda AI för programmering. Att beskriva en idé med vardagligt språk kan sänka tröskeln till att börja bygga, men det ersätter inte behovet av tydliga krav eller noggrann granskning.
Tan använde också Claude Code tillsammans med Perplexity AI för research, eftersom tjänsten presenterade svar med hänvisningar. Men han utgick inte från att en hänvisning automatiskt betydde att uppgiften var korrekt.
När researchen innehöll ett påstående om att fenfisk var ett av de främsta allergiproblemen i Singapore reagerade Tan. I hans erfarenhet var skaldjur en mer välbekant risk. Han kontrollerade det material som citerats och rättade sedan appen. Berättelsen visar också en bredare risk: AI-baserade söktjänster kan presentera hänvisningar till påhittade studier, vilket innebär att viktig information om hälsa fortfarande måste verifieras oberoende.
För en app som används kring ett spädbarn var försiktigheten särskilt viktig. Appen kunde strukturera observationer och jämföra dem med vägledning, men AI-genererad research ska inte betraktas som medicinska bevis bara för att den innehåller länkar eller källmarkeringar.
De färdigheter Tan fick genom arbetet med bebisappen kunde även användas i hans yrke. Han skapade ett verktyg med en knapp som kan översätta engelskt innehåll till 48 språk.
Instruktionerna handlade inte om ord-för-ord-översättning. Först skulle verktyget förstå källtextens betydelse, avsikt och övertygande mål. Därefter skulle det skriva naturligt på målspråket i stället för att behålla engelsk meningsbyggnad, rytm eller logik.
Samma princip återkom alltså: kvaliteten beror mycket på om användaren förklarar målet, sammanhanget och begränsningarna – inte bara själva uppgiften.
Tans erfarenhet visar inte att AI gör mjukvaruutveckling automatisk. Han behövde fortfarande identifiera ett verkligt problem, skriva en detaljerad specifikation, skapa konton, koppla ihop tjänsterna, testa appen och ifrågasätta osäker research.
Däremot visar den hur en AI-assistent kan göra det möjligt att börja med en användbar, avgränsad produktidé i stället för flera års programmeringsstudier. För Tan håller experimenterande och tydliga instruktioner på att bli praktiska färdigheter även för personer som inte skriver perfekt engelska.
Den mest användbara slutsatsen är därför inte att ”AI kan bygga vad som helst”. Det är att personer utan programmeringsbakgrund kan använda AI för att ta fram prototyper av smala, konkreta verktyg – så länge de själva tar ansvar för kraven, testerna och den faktiska bedömningen.