
Produktekspert deler arbeidsflyten for vibe-koding som erstatter overleveringer til utviklingsteamet

Anton Ingachev
Grunnlegger av Mini Apps Builder

Anton Ingachev forklarer hvordan vibe-koding lar produktledere bygge og lansere funksjoner direkte, redusere overleveringer til utviklingsteamet og samtidig beholde teknisk gjennomgang i arbeidsflyten.
Anton Ingachev
Grunnlegger av Mini Apps Builder

Key Takeaways
Raskere lansering: KI lar produktledere bygge enkle funksjoner direkte, eliminerer overleveringer til utviklingsteamet og fremskynder lanseringer med små team.
Kontekst er viktig: Bedre prosjektkontekst hjelper KI med å produsere innhold av høyere kvalitet raskere, mens begrenset kontekst skaper svake og upålitelige resultater.
Utforming av arbeidsflyt: Produktteam kan bruke KI i utvikling, oversettelse, innholdsproduksjon, research, testing og dokumentasjon av lanseringer.
Menneskelig kontroll: KI-generert arbeid krever fortsatt tydelige instruksjoner, gjennomgang, testing og faglig skjønn før det når kundene.
Eksperimenter først: Ledere bør vurdere eksisterende prosesser på nytt og deretter teste selektivt, fordi effektiv innføring av KI avhenger av produktspesifikke begrensninger.
Anton Ingachev er grunnleggeren av Mini Apps Builder, en plattform uten kode for å bygge Telegram-apper, der han har produktansvaret. Før dette hadde han flere stillinger som CPO og produktdirektør.
Vi snakket med Anton for å lære mer om hvordan han eliminerer overleveringer til utviklingsteamet ved å vibe-kode små funksjoner selv. Her er det han fortalte oss.
Fordypning i AI av nødvendighet

Jeg har jobbet med produkt i over ti år – innen fintech, sjakkplattformer, blokkjede og helseteknologi. Jeg har vært CPO to ganger og produktdirektør én gang.
AI-reisen min begynte som et praktisk behov, ikke som en strategi. For omtrent halvannet år siden var jeg med på å grunnlegge Mini Apps Builder – en B2B2C-plattform uten kode for å bygge Telegram-apper. Som CPO uten utviklerbakgrunn trengte jeg å lansere funksjoner raskt uten å vente på en full utviklingssyklus. Det var da jeg begynte å bruke Claude Code og Cursor daglig, ikke bare til dokumentasjon eller prototyping, men også i produksjon.
For å demonstrere det fulle potensialet bygget jeg et produksjonsklart produkt alene – arkitektur, baksystem, brukergrensesnitt, alt sammen – ved hjelp av AI-verktøy, uten et utviklingsteam. Det var da det gikk fra «jeg bruker AI for å jobbe raskere» til «jeg kan bygge og lansere reelle produkter selv».
Nå bruker jeg den samme tilnærmingen i Mini Apps Builder – jeg bygger enkelte funksjoner direkte i stedet for bare å spesifisere dem for utviklere.
Veien min var altså ikke «jeg leste om AI-transformasjon og bestemte meg for å lede den». I stedet trengte jeg å bevege meg raskt uten et stort team; AI gjorde det mulig, og nå tenker jeg annerledes om produktstrategi på grunn av det – alle veikartbeslutninger inkluderer nå spørsmålet: «Kan AI gjøre dette steget, eller kan den bare støtte det?»
More Articles
Slik erstatter AI den gamle overleveringsmodellen i produktarbeidsflyter
I årevis trodde jeg at en produktsjefs jobb stoppet ved spesifikasjonen. Du skriver kravene, men du rører ikke koden – det er utviklerens jobb. Det føltes som å gå for langt å krysse den grensen.
Det er det viktigste AI har endret i produktverdenen. Nå håndterer jeg enkle funksjoner selv. Jeg bygger dem ved hjelp av Claude Code og lanserer dem direkte, uten å vente på kapasitet hos utviklingsteamet.
Det betyr at vi kan kutte ut et helt overleveringssteg. I stedet for å gå fra spesifikasjon → gjennomgang hos utviklingsteamet → bygging → kvalitetssikring, bygger og tester jeg ofte direkte.
Lanseringstakten vår er nå to eller tre lanserte funksjoner i uken med et team på to personer – på tvers av nettstedet, leverandørdashbordet, selve Telegram Mini App-en og vårt interne administrasjonspanel. Det tempoet ville ikke vært mulig med den gamle overleveringsmodellen.
Det endret også hvordan jeg tenker om teamstruktur. Begrensningen er ikke lenger «Hvor mange utviklere har vi?» I stedet er spørsmålet «Hvor godt kan jeg spesifisere det jeg ønsker?»
En AI-støttet arbeidsflyt for funksjonsutvikling
Slik ser funksjonsutviklingen ut:
- Jeg beskriver oppgaven for en førsteklasses modell som Claude Code. Jeg deler hva jeg liker, hva jeg ikke liker, hvilket problem vi løser, og hva som ikke må glemmes eller ødelegges. Jeg gir referanser – noen ganger fra direkte konkurrenter, men ikke alltid.
- Modellen lager en detaljert plan. Jeg leser den. Ved behov gjør jeg endringer eller utfordrer planen.
- Jeg ber Claude implementere planen i kode.
- Jeg oppretter en PR, som går gjennom automatiserte kontroller før den tildeles CTO-en.
- Hvis alt er i orden, slår CTO-en den sammen til utviklingsmiljøet, og jeg tester den i produktet.
- Hvis noe er galt, legger CTO-en igjen kommentarer, jeg ber modellen rette dem, og prosessen gjentas.
- Hvis noe er helt feil, diskuterer jeg med CTO-en hvordan vi kan forbedre instruksjonene som gis til LLM-en, og gjentar prosessen.
- Etter testing i utviklingsmiljøet ruller vi ut til produksjon.

Antons tanker
Jeg deler hva jeg liker, hva jeg ikke liker, hvilket problem vi løser, og hva som ikke må glemmes eller ødelegges.
Hvor AI kan brukes i produktarbeidsflyter

De viktigste AI-verktøyene jeg bruker, er Claude Code, Codex, Cursor, Gamma, Midjourney og Figma Agent. Her er andre måter jeg bruker AI i produktarbeidsflyter på, sammen med noen av fordelene:
- Hele produktet vårt – grensesnitt, blogg, hjelpesenter og artikler om produktoppdateringer – blir oversatt til 20 språk i tilnærmet sanntid med ett enkelt klikk.
- Bloggartikler skrevet av en LLM har omtrent doblet søketrafikken vår – og artiklene tar bare en brøkdel av tiden.
- Som produktleder gjør AI det enklere for meg å utfordre mine egne ideer – jeg kan be AI finne data som enten støtter eller motbeviser dem.
- Det er ikke lenger noe problem å skrive produktoppdateringer, siden AI gjør det nesten automatisk.
Ærlig talt kan jeg ikke nevne et område der AI ikke hjelper. Nesten overalt gir det en tydelig fordel å bruke AI. Ja, mennesker må dobbeltsjekke, finjustere og lære opp AI, men når det finnes et tydelig mål og en forståelse av hvordan det kan nås med AI, blir prosessen bedre.
Hvorfor AI trenger riktig kontekst før det integreres i arbeidsflyter
Når det gjelder AI, er kontekst alt.
Tidligere skrev jeg bloggartikler basert på en brief fra en SEO-spesialist. Det tok to til tre timer. Deretter lastet jeg prosjektkonteksten inn i en LLM og ga den briefen direkte – nå tar artiklene 5–7 minutter. Og som jeg nevnte ovenfor, har de høyere kvalitet, noe som har ført til dobbelt så mye trafikk.
Når det gjelder AI, er kontekst alt … Uansett arbeidsflyt bør du investere i å gi AI-verktøyene dine kontekst!

Men da jeg ba SEO-spesialisten skrive dem med AI, ble jeg overrasket over hvor dårlige resultatene var. Grunnen? LLM-en hans hadde langt mindre prosjektkontekst enn min.
Uansett arbeidsflyt bør du investere i å gi AI-verktøyene dine kontekst!
Hvorfor produktledere må gjennomgå noen produktarbeidsflyter fullstendig, men ikke nødvendigvis alle

Mitt råd? Integrer AI i de fleste av prosessene dine allerede nå. Det er ikke 2022 lenger; verdien er tydelig nå. AI er helt nødvendig.
Produktledere bør undersøke alle prosesser og verktøy som tidligere ble ansett som optimale, på nytt. Men det betyr ikke nødvendigvis at alle må gjennomgås fullstendig med AI. Du må forstå begrensningene til AI, dine egne styrker og svakheter, produktet du arbeider med, budsjetter og så videre.
Oppsettet vil se forskjellig ut for hvert enkelt prosjekt. Alt er fleksibelt. Og det finnes ingen etablerte beste praksiser. Det gjør ting mer komplisert.
Den eneste måten å finne ut av det på for produktet ditt er gjennom praktisk eksperimentering.

Antons tanker
Mitt råd? Integrer AI i de fleste av prosessene dine allerede nå. Det er ikke 2022 lenger; verdien er tydelig nå. AI er helt nødvendig.
Følg med
Du kan følge Anton Ingachevs arbeid på LinkedIn og GitHub. Ta også en titt på Mini Apps Builder.
Flere ekspertintervjuer kommer på The CPO Club!

