Softwareontwikkeling met Devin: integraties, testen en CI/CD (deel 3)

Welkom terug! Aan het einde van de tweede tutorial hadden we een fp-ts-playground met pastelthema, een NestJS + PostgreSQL-backend en anonieme UUID-progress-tracking.

Je vindt alle tutorials in de Devin-serie hier:

1. Setup en eerste pull request (deel 1)
2. Een verticale slice shippen met Devin (deel 2)
3. Integraties, testen en CI/CD (deel 3) 
4. Security, deployment, onderhoud (deel 4)

Wat we tot nu toe hebben gedaan is prima voor solo hacken, maar het is tijd om te zien hoe goed Devin integreert met teamworkflows. In deze derde tutorial kijken we naar:

• Integraties: Devin opent Jira-tickets, werkt eraan en stuurt elke PR-status rechtstreeks naar Slack.
• Quality gates:  We voegen Jest-unit tests toe voor de API, Playwright end-to-end-flows voor de UI, en handhaven 90% coverage.
• CI/CD: GitHub Actions voert linting, type-checks en alle tests uit, en voegt Playwright-rapporten toe aan pull requests voordat er iets gemerged kan worden.

Nog geen auth en geen prod-deploys, die komen in deel 4!

Een Slack-integratie instellen op Devin

Devin aan je communicatie- en ticketflow koppelen is volledig handmatig en gebeurt via de Devin-interface.

Je kunt verbinding maken met Slack via het integratietabblad in de Devin-instellingen, of de app "Devin AI" installeren via Slack’s App Directory.

De app toont nog steeds "Niet goedgekeurd door Slack" in de OAuth-dialoog. Cognition zegt dat hun securityreview in behandeling is en dat de functionaliteit niet wordt beïnvloed.

Kies vervolgens een kanaal:

Je kunt met Devin chatten met alleen een mention:

En het start een sessie die je in de UI kunt openen:

Standaard krijg je meldingen over PR-updates in het kanaal van jouw keuze, maar er zijn een paar verschillende notificatie-instellingen die je per sessie kunt aanpassen.

Een Jira-integratie instellen op Devin

Om te integreren met Jira moet je een aparte botgebruiker (bijv. devin-bot@…) aanmaken en die inloggegevens koppelen onder Devin → Team ▸ Integraties ▸ Jira.

Vanuit je persoonlijke account kun je vervolgens een nieuw ticket aanmaken en het label devin toevoegen.

Devin plaatst een analysecomment met een plan en een prompt "Sessie starten?". Typ "yes" om het te laten coderen of verwijder het label om het ticket mens-only te houden.

Opmerking: Devin verplaatst geen kaarten automatisch over je bord. Jij of je PM moet ze nog steeds naar In Progress of Done slepen. Zo blijft de controle over de workflow bij mensen.

Devin laten werken vanuit Jira-tickets

Toen Slack en Jira eenmaal waren gekoppeld, deed ik een echt "agent-als-teamgenoot"-experiment en gooide ik echte tickets naar Devin om te zien of het die kon implementeren zonder handholding.

De workflow die ik gebruikte

Dit was mijn workflow:

1. Maak een ticket aan in mijn nieuw gemaakte JIRA-project en schrijf een duidelijk acceptatiecriterium.
2. Voeg het label devin toe, wat voor Devin het signaal is om te analyseren.
3. Devin reageert met een stapsgewijs plan, een inschatting van het vertrouwen en vraagt: "Sessie starten?"

4. Ik antwoordde " Yes". Het ticket toont "Sessie gestart" en geeft de web-IDE-link. Wanneer de PR landt, post Devin "Merged ✅" terug naar Slack, en verplaats ik de kaart op het bord. Dit kost geen ACU’s totdat ik "Yes" antwoord.

Vijf echte tickets, vijf totaal verschillende uitkomsten

Hier is een samenvatting van wat er gebeurde bij vijf echte tickets:

Dingen die willekeurig aanvoelden

Dit zijn de dingen die verbetering nodig hadden:

• PR-titels: ik specificeerde een naamgevingspatroon in elke prompt, maar Devin verzon elke keer een nieuw formaat.
• Database-trouw: bij het ene ticket migreerde het naar Postgres, en bij een ander introduceerde het geruisloos SQLite opnieuw.
• ACU-inschattingen: de analysecomment claimde dat het sandpack-ticket 1,5 ACU zou kosten; in werkelijkheid waren het twee sessies en 5 ACU’s.
• Het vertrouwen vs de uitvoering: een ticket met laag vertrouwen werd in 3 minuten en perfect uitgevoerd. Een met hoog vertrouwen kostte 45 minuten gepruts.

Devin op Jira is veelbelovend: twee tickets perfect gesloten, één met lichte sturing, en zelfs het slechtste geval kostte alleen tijd, geen rollback. Maar consistentie is er nog niet, dus strakke afbakening en expliciete randvoorwaarden zijn je vrienden.

Geautomatiseerde tests toevoegen met Jest en Playwright

Nu chat en tickets lopen, was de volgende stap zekerstellen dat kapotte code er niet tussendoor glipt. Ik vroeg Devin om twee dingen: backend-unittests en end-to-end Playwright-tests die een lerende nabootsen die een oefening in de browser bewerkt.

Backend-unittests: verrassend pijnloos

Ik vroeg Devin om Jest-testsuites voor de GraphQL-resolver, servicelaag en Prisma-modellen. Toen ik om een ACU-schatting vroeg, antwoordde het 20 ACU’s!!

Ik dacht dat dat een fout moest zijn en startte de taak toch. Het kostte 1,1 ACU en het was met afstand de best uitgevoerde taak tot nu toe.

Playwright e2e: rode muur, groene muur

Deze was iets duurder en kostte 2,3 ACU.

De flow legde vast: open /learn/option-01 → code bewerken → wachten op ✓ → pagina verversen → ✓ blijft behouden.

In de eerste run faalde ongeveer 70% van de assertions. Er waren veel resize-glitches, verouderde dashboardtellingen en zelfs het happy path was flaky.

Ondanks het commando "Negeer falende tests, we fixen later" in mijn prompt, bleef Devin code patchen totdat de suite grotendeels groen werd (nuttig, maar niet wat ik vroeg).

We hebben nog steeds enkele falende tests omdat we best wat bugs in het systeem hebben. Maar dat is oké, we ruimen het later op zodat al deze tests groen zijn.

Een one-click GitHub Actions-pipeline toevoegen

Met unit- en end-to-end-tests op hun plek was de laatste stap zekerstellen dat elke pull request die checks automatisch draait. Ik vroeg Devin om een kale workflow, zonder artefacten, zonder coverage-gates, gewoon lint → type-check → tests.

Devin leverde in één keer een verrassend gepolijste pipeline, zonder vervolgduwtjes nodig:

• Geen config drift: Devin hergebruikte bestaande npm-scripts, dus geen nieuwe tooling om te leren.
• Alles parallel: lint, type-check en de twee testsuites draaien naast elkaar, dus de hele workflow is in ~4 min klaar op GitHub’s gratis runners.
• Duidelijke triage: als ESLint faalt maar tests slagen, rapporteert de samenvattingsjob nog steeds de linterror; je merged nooit "gedeeltelijk rode" code.

Devin pusht de workflow, wachtte tot de check in GitHub was voltooid en besloot pas daarna dat het klaar was. Ik moet zeggen, 0,4 ACU voor een volledig werkende pipeline is lastig te overtreffen. YAML is duidelijk Devin’s happy place.

Met deze workflow gemerged moet elke PR lint, compilatie en beide testsuites passeren voordat iemand op de groene knop drukt!

Devin’s wiki in het product

Devin wordt geleverd met een ingebouwde "Wiki" die naast je code kan leven. Het is een lichte, automatisch gegenereerde kennisbank waar de agent tijdens het werk zowel uit kan lezen als naar kan schrijven. Na het koppelen van Slack, Jira en CI is deze Wiki een goede plek voor architectuurnotities. De moeite waard om te bekijken!

Voor zover ik weet is dit niet handmatig bewerkbaar en moet je erop vertrouwen dat Devin de Wiki up-to-date houdt.

Kosten- & tijdsnapshot en reflecties

Zodra alle integraties, tests en de pipeline live waren, maakte ik de balans en de klok op:

Dus, ongeveer 2 uur menselijk werk om tickets, tests en CI te pushen. Het is zeker sneller dan ik het zelf zou doen.

Op dit punt ben ik echter verdeeld. Er zijn nog veel bugs, en als ik de hele codebase zelf had geschreven, zou ik issues waarschijnlijk sneller kunnen fixen dan Devin credits verbrandt. 

Maar Devin heeft het grootste deel van de app geschreven, dus de agent "kent" de structuur eigenlijk beter dan ik. Toch worstelt het met het vervangen van hardcoded waarden door dynamische, laat het losse eindjes achter in de code in elk bestand en moet ik voor mijn laptop zitten om al zijn acties te babysitten.

Ik vond het proces ook een beetje frustrerend, maar niet op dezelfde manier als wanneer ik een bug achterna jaag die ik niet kan grijpen. Er is een wereld van verschil (voor mij in ieder geval) tussen gefrustreerd zijn omdat de code niet werkt en gefrustreerd zijn omdat een AI-agent een paar basisinstructies niet kan volgen. Dat laatste is ronduit ergerlijk.

Ik denk dat Devin erg behulpzaam kan zijn als je het goed gebruikt, maar zoals met elke AI-agent kan het geen vervanging zijn voor een software engineer. Het is prima om het voor sommige taken te gebruiken, maar ik denk niet dat het heel geschikt of duurzaam is om het voor elk ticket te gebruiken.

Wat staat er op het programma?

We zijn gekoppeld aan Slack en Jira, tests zijn groen en de CI-poort blokkeert elke slordige PR. Maar voor een echte productielancering missen we nog vier pijlers:

1. Authenticatie: NextAuth-credentials koppelen → JWT-cookies → GqlAuthGuard in NestJS zodat voortgang aan echte gebruikers wordt gekoppeld.
2. Beveiligingsverharding: Sentry error-tracking in zowel web- als API-runtimes.
3. Continue deployment: een Vercel (web) pipeline die preview-URL’s opzet bij elke branch en promoot naar prod wanneer de main-branch groen wordt.

Dat is de agenda voor deel 4, de laatste etappe waarin we ontdekken of Devin de app kan beveiligen, deployen en in de gaten houden met bijna geen menselijke tussenkomst. Zet je database opnieuw vast op Postgres, zet een cap op die ACU’s, en ik zie je in het laatste hoofdstuk.

Klaar om door te gaan? Klik op het laatste item hieronder om naar de vierde tutorial te gaan:

1. Setup en eerste pull request (deel 1)
2. Een verticale slice shippen met Devin (deel 2) 
3. Integraties, testen en CI/CD (deel 3) 
4. Security, deployment, onderhoud (deel 4)