Softwareontwikkeling met Devin: Setup en eerste pull request (deel 1)

Ontdek hoe Devin kan helpen bij je programmeertaken. In deze eerste tutorial starten we met een bestaande repo en verkennen we de functies die beschikbaar zijn in de Devin-omgeving.

Bijgewerkt 2 okt 2026 · 12 min lezen

Verken met AI

ChatGPT Claude Perplexity

Ik denk dat we allemaal wel hebben gehoord van Devin, de “AI junior software engineer” die naar verluidt je repo kloont, nieuwe features toevoegt, de tests draait en een pull request opent voordat jij je ochtendkoffie op hebt.

Zoals met alle AI-dingen tegenwoordig is het lastig om te weten hoe goed het echt is zonder het zelf te proberen, dus besloot ik dat te doen. Ik heb Devin door elke fase van de volledige softwareontwikkelingscyclus gehaald en een reeks van vier tutorials geschreven in de hoop dat andere ontwikkelaars er het maximale uit kunnen halen.

Je kunt alle tutorials in de Devin-serie hier vinden:

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

Als je GitHub-profiel een “kerkhof” is van vergeten repositories, ben je in goed gezelschap. Het mijne staat vol half-afgemaakte experimenten. In de komende vier tutorials zetten we Devin aan het werk op mijn verlaten fp-ts-exercises-repo en veranderen we de clone-and-run-oefeningen van vorig jaar in een modern, browsergebaseerd leerplatform.

Laat me heel kort mijn plan voor de vier tutorials uitleggen, en dan gaan we voor de rest van de serie praktisch aan de slag.

Wat we behandelen in deze tutorialserie

We blazen een side-project uit mijn eigen GitHub-kerkhof nieuw leven in, omdat Devin het best presteert met echte code, echte tests en wat geschiedenis om over te redeneren, niet met een lege repo.

Het project is fp-ts-exercises, een verzameling kleine challenges om functionele-programmeerconcepten (zoals Option, Either, enz.) in TypeScript te leren. Op dit moment is het een clone-and-run-repo: leerlingen halen hem binnen, bewerken lokaal bestanden en draaien de tests in hun eigen terminal.

Mijn doel is om die oefeningen om te vormen tot een browsergebaseerde, interactieve playground waar je een uitleg kunt lezen, code kunt tweaken in een inline editor en direct ziet of de tests slagen (of falen). Leerlingen kunnen ook inloggen om hun voortgang op te slaan.

Opmerking: ik heb de repo samen met Devin geüpdatet terwijl ik deze tutorials schreef. De link hierboven toont de staat van de code in april 2023, voordat ik het project liet vallen. De actuele code vind je hier.

Dit is het plan voor onze vier delen:

Deel 1 - Setup & eerste pull request

Meld je aan voor Devin, koppel GitHub.
Laat Devin de repo opschonen: dependencies updaten, nieuwe lints en scripts aanmaken en het eerste PR openen.

Deel 2 - Features shippen

Gebruik Devin om de nieuwe browser-UI en API te plannen.
Bouw pagina’s, stel een database en secrets in en laat Devin feature-PR’s openen.

Deel 3 - Integraties, testen en CI/CD

Introduceer Vitest/Playwright-tests en laat Devin ze groen houden.
Genereer een GitHub Actions-pijplijn, koppel tickets aan Jira en verbind Devin met Slack.
Verken de Wiki-functie.

Deel 4 - Beveiliging, uitrol & onderhoud

Voeg authenticatie toe, rol onze app uit en koppel Sentry voor foutmonitoring.

Aan het einde zou de oude CLI-repo een gepolijste webapp moeten zijn!

Voordat we met het hands-on gedeelte beginnen, geven we Devin een algemene introductie. Sla gerust door naar de setup-sectie als je al weet wat Devin is en hoe het werkt.

Wat is Devin?

Devin is een cloud-gehoste, volledig autonome codeeragent, ontwikkeld door Cognition. Als je het in een repo dropt, opent het een gesandboxte shell, editor en browser, waarna het taken end-to-end plant en uitvoert zonder je lokale machine aan te raken.

Het werd gelanceerd in maart 2024, met Cognitions blogpost waarin stond dat Devin 13,86% van echte GitHub-issues op de SWE-bench-benchmark sloot, wat het vorige SOTA van 1,96% volledig overtrof. Praktisch betekent dit dat het op een zorgvuldig gekozen subset (570 issues) zonder menselijke hulp 79 bugs uit populaire projecten zoals Django en scikit-learn heeft opgelost.

Dat is indrukwekkend, maar het is benchmarkcode (bestaande uit afgebakende bugs met test suites), dus de prestaties in de echte wereld variëren. Hoe dan ook, sommigen zeggen dat het presteert als een junior dev.

Use-cases voor Devin

Devin is een fijne partner als je het volgende wilt realiseren:

Incrementele repo-upgrades: Het kan tests draaien, dependencies updaten en iteratief breuken herstellen—ideaal voor taken als “breng dit Node 14-project naar Node 20”.
Goed afgebakende feature-tickets: Gegeven een GitHub-issue of Jira-ticket met duidelijke acceptatiecriteria is Devin’s plan-edit-test-loop behoorlijk goed.
Niet-codeertaken: Documentatie regenereren, CI-templates aansluiten of bestanden bulk-formatteren is saai voor mensen, maar perfect voor een agent.

Devin is echter minder geschikt voor:

Greenfield-architectuur: Het heeft moeite als je gewoon zegt: “bouw voor mij een SaaS-platform vanaf nul.” Het heeft scaffolds nodig en werkt beter met meer context.
Ambigue productbeslissingen: Vraag het om te kiezen tussen Stripe en Paddle voor betalingen, en het kan zomaar willekeurig kiezen.
Grote monorepo’s: Door contextlimieten moet het bestanden in- en uitladen, en de prestaties kelderen op workspaces met 100k regels.

Hoe werkt Devin?

Alle moderne codeeragenten, inclusief Devin, draaien een loop die een robotica-controlegang weerspiegelt:

Fase	Wat Devin “ziet”	Belangrijke tech
Waarnemen	Leest codebestanden, testlogs, terminaloutput, browser-DOM	Code-indexer, logparsers
Begrijpen / Plannen	Breekt de gebruikersprompt op in een takenlijst, redeneert over volgorde en tooling	LLM-gebaseerde planner met retrieval-augmented memory
Handelen	Voert shell-commando’s uit, bewerkt bestanden, klikt door web-UI’s	Veilige sandbox (Docker/VM) met Shell- / Editor- / Browser-tools
Reflecteren / Leren	Draait tests opnieuw, inspecteert diffs, werkt plan bij (of vraagt jou)	Self-critique-prompt + vectorstore-geheugen
Vasthouden	Slaat tijdlijn & artefacten op voor replay of overdracht	Cloud object store + tijdlijn-UI

Devin is opgebouwd als een gelaagde stack van samenwerkende modules:

Alles begint met de chatinterface of Slack-bot/Jira-ticket, waar je het doel formuleert als een prompt.
De prompt gaat naar een planner-LLM die het doel uitwerkt tot een stapsgewijs plan en elke stap van zelfkritiek voorziet voor uitvoering.
Een lichte executor kiest vervolgens de juiste tool voor elke stap (shell, code-editor of headless browser), allemaal draaiend in een strak gesandboxte workspace.

Die sandbox is in feite een cloudlaptop en isoleert credentials, geeft Devin een Bash-prompt, een VS Code-achtige editor en een Chrome-instantie waar het doorheen kan klikken.

Onder de workspace zit een geheugenslaag die gevectoriseerde snapshots van de codebase opslaat plus een volledige replay-tijdlijn van elk commando, bestanddiff en browsertab die Devin aanraakt.

Waarom is deze architectuur zo goed? Ten eerste de strakke feedbackloop: zodra tests falen of lints klagen, kan Devin autonoom itereren totdat de build groen is.

Ten tweede maakt het sandbox-ontwerp het triviaal om kleine klusjes te paralleliseren, omdat meerdere sandboxes naast elkaar kunnen draaien zonder elkaar in de weg te zitten.

Ten derde stelt het persistente geheugen Devin in staat langlopende migraties aan te pakken: de agent kan een doorlopende to-dolijst bijhouden en daar uren of dagen aan blijven werken, waardoor bulk-refactors meerdere keren sneller afgerond worden dan een mens met de hand zou doen.

Aan de slag met Devin

Eerst even een account instellen.

Aanmelden en een plan kiezen

Ga naar devin.ai en klik op “Get Started”.

De eerste stappen van de wizard zijn vrij eenvoudig te volgen. Ik moest een paar vragen beantwoorden over mezelf, het bedrijf en de naam van mijn team. Ben je net als ik een solodev, dan is dat geen probleem: de wizard houdt daar rekening mee.

Dan is het tijd om een plan te kiezen. Er zijn twee opties:

Core (pay-as-you-go): Voor de meeste solodevs is het Core-plan het goedkoopst—je betaalt $20 vooraf, wat 9 Agent Compute Units (ACU’s) oplevert.
Teams: Het Teams-plan geeft je 250 ACU’s/maand. Deze officiële documentatiepagina geeft gedetailleerde informatie over ACU’s en het factureringsmodel van Devin.

Het Core-plan is een vrij goedkope manier om Devin te testen, dus ik besloot $20 te betalen en te zien hoe ver ik daarmee zou komen.

Ik vulde mijn betaalgegevens in en kreeg de optie om een automatisch oplaad-drempel in te stellen zodat Devin ACU’s automatisch kan aanvullen in plaats van halverwege een taak te stoppen. Ik heb deze functie niet ingeschakeld en zou dat op dit punt waarschijnlijk niet aanbevelen. De optie is later beschikbaar in de instellingen, dus je kunt eerst één taak proberen en zien hoe je verbruik is. Je kunt ook ACU-limieten per sessie instellen, handig om binnen budget te blijven.

Snelle rekensom: $20 / 9 ACU’s ≈ $2,25 per ACU. Het Teams-abonnement ($500/maand) brengt dat terug tot $2,00 en laadt 250 ACU’s vooraf, maar je bespaart alleen geld als je verwacht dat Devin maandelijks 30+ uur draait.

Verbinding maken met GitHub (en optioneel met Jira en Slack)

Vervolgens wordt gevraagd om een GitHub-account te koppelen en Devin toegang te geven tot repositories.

Ik koos ervoor om Devin alleen toegang te geven tot onze fp-ts-exercises-repository, aangezien dat de enige is die het hoeft te kennen, en jij doet waarschijnlijk hetzelfde om onbedoelde codemodificatie te voorkomen.

Daarna kon ik een projectmanagementsysteem koppelen. Devin lijkt integratie te ondersteunen met Jira, GitHub Issues en Linear.

Als je op de Jira-optie klikt, opent deze modal, en de gele regels geven aan dat het het beste is als Devin een specifieke serviceaccount gebruikt en slechts toegang heeft tot één workspace, ook als dat betekent dat je hiervoor een apart Jira-account moet aanmaken.

Let op: het is mogelijk om de Jira-integratie later via de instellingen toe te voegen, dus je hoeft dit niet nu te doen.

Je krijgt ook de optie om met Slack te integreren, maar dat heb ik voorlopig overgeslagen.

Eerste taak: een verouderde repository updaten

Oké, nu we klaar zijn met de setup, gaan we naar het leuke deel. Tijd om te zien hoe goed Devin is!

Prompten

Zodra de initiële setup klaar is, landen we op deze pagina:

Niet verrassend: het begint allemaal met een prompt. Ik heb over alle kleine icoontjes gehoverd om de beschikbare functies te begrijpen en toen mijn prompt geschreven.

Prompt: Een paar jaar geleden ben ik een repo gestart genaamd fp-ts-exercises, bedoeld om ontwikkelaars functioneel programmeren in TypeScript te leren met de fp-ts-bibliotheek. Het bevat een reeks lokale oefeningen over concepten zoals Option, Either, enz. Leerlingen kloonden de repo, losten de oefeningen op en draaiden tests om hun oplossingen te controleren.

Ik wil dit project moderniseren en opnieuw lanceren met de volgende doelen:

Update & refactor van de bestaande codebase

Update alle dependencies en zorg voor compatibiliteit met de nieuwste versie van fp-ts
Verbeter structuur, leesbaarheid en developer experience
Vervang verouderde tooling of patronen (bijv. migreer van Mocha naar Vitest, of iets vergelijkbaars indien passend)

Dat was geen geweldige prompt, maar dat was ook de bedoeling. De output van een AI-agent kan maar zo goed zijn als de input die het krijgt, en een vaag doel kan op verschillende manieren worden geïnterpreteerd. Bij Devin is de kost van miscommunicatie aanzienlijk. Als grenzen van uitvoering en verwacht resultaat niet duidelijk zijn, en je het op een half-complexe taak zet, verspil je veel ACU’s.

Wat ik hier wilde testen, was het kleine “magische pen”-icoon naast de “Send”-knop. Dit is een “Analyze prompt”-functie die handig beschikbaar is om je prompt te verfijnen voordat je hem verstuurt, en zo het beste uit Devin te halen.

Toen ik erop klikte, herformuleerde het delen van mijn prompt en liet het ook weten dat er ruimte was voor verbetering.

Dat was prima feedback, dus ik heb mijn prompt iets aangepast om extra eisen mee te geven. Ik had op dat moment geen linting of unit-tests ingesteld, dus ik specificeerde dat het de tests van de leerlingen op de oplossing van het eerste probleem moest draaien om zeker te zijn dat de app zich gedroeg zoals verwacht.

Prompt: Ik wil mijn fp-ts-exercises-repository moderniseren en opnieuw lanceren, die ontwikkelaars helpt functioneel programmeren in TypeScript te leren met de fp-ts-bibliotheek. De repository bevat lokale oefeningen over concepten zoals Option en Either. Leerlingen klonen de repo, lossen de oefeningen op en draaien tests om hun oplossingen te controleren. Het doel is om het project te updaten en de developer experience te verbeteren. Doe het volgende:

Update alle dependencies naar de nieuwste versies en zorg voor compatibiliteit met de nieuwste versie van fp-ts.
Refactor de bestaande codebase om structuur, leesbaarheid en de algehele developer experience te verbeteren.
Vervang verouderde tooling of patronen. Migreer bijvoorbeeld van Mocha naar Vitest, of stel andere passende toolingupdates voor. Geef graag een onderbouwing voor eventuele toolwijzigingen die je voorstelt.
Zorg dat alle bestaande oefeningen en tests correct blijven werken na de updates en refactor.

Je kunt npm run solution -- option 01 draaien om zeker te weten dat de tests slagen en alles werkt zoals verwacht.

Specificeer welke stappen je gaat nemen om de updates en refactor uit te voeren. Stel je aanpak voor en vraag om feedback voordat je belangrijke wijzigingen aanbrengt.

Je kunt je wijzigingen ter review indienen in een pull request.

Zeker genoeg, het analyseren van mijn prompt leverde deze keer een “Prompt ziet er goed uit!”-melding op.

De interface

Ik verstuurde mijn prompt en Devin begon meteen te denken.

De UI is op het eerste gezicht wat overweldigend, maar vrij makkelijk te navigeren als je weet wat alles doet. Laten we het opdelen.

Het paneel met actieve sessies links is inklapbaar als je liever in één sessie tegelijk duikt.

Er is een chat-achtige interface waar je Devin’s redenering kunt volgen en ermee kunt interacteren.

De rechterkant van het scherm wordt ingenomen door een paneel met verschillende tabs: Progress, Shell, Browser en Editor. Deze tabs tonen de exacte redenering en stappen die Devin uitvoert in de verschillende omgevingen.

Door op elk van deze te klikken zie je de stappen in de shell (bijvoorbeeld het klonen van de repo), in de browser (navigeren naar de GitHub-pagina van de repo) en in de Editor, een VSCode-achtige editor met alle bestanden van de repo (waar het later onze code zal aanpassen). De progress-tab licht de stappen uit terwijl ze worden uitgevoerd.

Rechtsboven in het scherm is er nog een set tabs: Timelapse, IDE en Browser. Dit zijn de weergaven die jij kunt gebruiken en navigeren. De nu geselecteerde Timelapse-tab toont Devin’s voortgang en acties, zoals hierboven uitgelegd. De interactieve timelapse-functie (je ziet “Live” en de voortgangsbalk onderaan) laat je een sessie terugspelen. De IDE-tab opent een online VSCode-achtige IDE waarin je je code kunt aanpassen en zelfs kunt committen naar GitHub.

Plannen en Devin’s redenering

Devin dacht een paar minuten na, analyseerde de hele repo en legde bij elke stap zijn acties uit. Let op het gemarkeerde bericht “Devin kloonde de repo, overweeg een Devin-werkruimte in te stellen”. Daar komen we later op terug.

Vervolgens stelde het een plan voor, gaf aan dat het vertrouwen hoog was en vroeg mij om te bevestigen:

Ik was best tevreden met dat plan, dus ik klikte op Confirm. Devin ging meteen aan de slag.

Zie je het kleine “Agent”-dropdown onderaan de chatinterface? De andere optie in het menu is “Ask”. Deze functionaliteit onderbreekt Devin’s werk niet, maar laat je er wel mee communiceren. Ik besloot het te testen door te vragen om linting- en TypeScript-compile-check-scripts toe te voegen.

Het werk was al begonnen, maar het liet me weten dat het die scripts zou toevoegen (en dat deed het!).

De pull request

Ik heb het niet exact getimed, maar na een paar minuten had het een pull request klaar, en de beschrijving was grondig en accuraat.

Het was een aangename verrassing dat het uit eigen beweging meer deed dan alleen zorgen dat de tests van de eerste oplossing slaagden. Het testte de derde oplossing, maar ook de eerste oefening, en controleerde dat de tests faalden (zoals verwacht, aangezien geen enkele leerling de oefening had voltooid).

Ik bekeek het PR en vermoedde dat mijn linting- en TypeScript-compile-scripts zouden falen. Er ontbrak bijvoorbeeld een "type":"module" in mijn package.json.

Ik weet niet zeker waarom Devin die scripts niet draaide nadat het ze had geschreven om te controleren of ze werkten. Omdat ik het niet expliciet vroeg? Of omdat ik deze eisen toevoegde nadat het begonnen was?

Ik besloot de online code-editor te gebruiken om Devin’s omissie te herstellen, wat me ongeveer 5 minuten kostte. Ik draaide elk commando in de terminal en alles leek zich na mijn fix te gedragen zoals verwacht.

Ik had de fix aan Devin kunnen overlaten, maar het was sneller om het zelf te doen. In ongeveer vijf minuten draaide ik de scripts, bevestigde ik de lint- en compile-fouten en vond ik de oorzaak. Nog eens twee minuten later was de patch klaar en slaagden alle checks. Een gedetailleerde prompt opstellen, wachten tot Devin draait en dan de output reviewen had langer geduurd.

De juiste balans vinden tussen menselijke en AI-inspanning is een subtiele kunst: als een tweak overduidelijk laaghangend fruit is, doe ik het liever zelf dan “fix dit alsjeblieft” te typen en te wachten. Iedereen heeft persoonlijke voorkeuren, en jouw grens verschilt per expertise, taak en—laten we eerlijk zijn—je humeur van de dag.

De sessie beëindigen

Op dat punt was ik klaar met het moderniseren van de repo en werkte alles zoals verwacht. Maar wat nu? Hoe beëindig ik een sessie, en worden er nog kosten gerekend voor deze idle-tijd?

De interface werd hier een beetje verwarrend. Aan de rechterkant, in het sessiemenu, had ik twee opties: Devin in slaap zetten of de sessie beëindigen.

Ik raadpleegde de documentatie, en dit is wat ik vond: Devin verbruikt geen ACU’s terwijl het slaapt, en valt automatisch in slaap na ~0,1 ACU aan inactiviteit.

Ik vroeg ook aan de docs-AI-bot wat het verschil tussen slaapstand en beëindigen was:

Het antwoord was vrij duidelijk. Ons werk hier was klaar, dus ik heb de sessie beëindigd.

Onze repo instellen in Devin’s workspace

Herinner je je het gemarkeerde bericht dat we in de chat kregen terwijl Devin zijn werk plande? Het vroeg ons om de repo in te stellen op Devin’s machine, zodat we hem niet telkens opnieuw hoeven te klonen als we eraan willen werken. Maar waarom zouden we dat willen?Elke nieuwe sessie start met een verse virtuele machine, dus zonder setup moet Devin:

Onze codebase van nul af aan begrijpen
Alle dependencies en tools installeren
Onze projectstructuur en -conventies leren kennen
Kostbare tijd verspillen aan omgevingssetup in plaats van aan echt werk

Onze repo instellen is dus een efficiëntere aanpak qua kosten en tijd. Het is ook consistenter, omdat elke sessie met dezelfde configuratie start en Devin precies weet hoe het onze code moet runnen, testen en linten.

Deze functie vind je in het navigatiepaneel van je team, en de stappen zijn opnieuw vrij eenvoudig te volgen.

We beginnen met het specificeren van de commando’s om de laatste versie van de repo op te halen:

Je kunt aangepaste commando’s invoeren en met de knop “Verify Command” worden ze automatisch voor je in de terminal gedraaid. Je ziet binnen enkele seconden of ze slagen of falen.

Ik sloeg de stap voor het instellen van secrets over, want die hebben we nu nog niet. Dependencies installeren en onderhouden werkt hetzelfde, en zodra je commando is geslaagd, wordt de stap als voltooid gemarkeerd.

De rest van de stappen werkt vergelijkbaar, en zodra alle stappen zijn voltooid (of overgeslagen, indien niet van toepassing), wordt je configuratie opgeslagen.

Sessieverbruik en review

Tot nu toe hebben we een eenvoudige taak met Devin afgerond, een pull request aangemaakt, het gemerged en onze repo ingesteld voor toekomstige sessies. Laten we eens kijken naar wat data over onze sessie. Door op het kleine icoon bovenaan de sessie te klikken, opent er een modal met sessie-inzichten:

Onze sessiegrootte is XS, wat volgens Devins maattabel best goed was.

Als je op “Generate Insights” klikt en een paar seconden wacht, zie je algemene informatie over je sessie, de specifieke stappen die Devin nam en waar het moeite had.

Ik was ook benieuwd hoeveel ACU’s we hadden verbruikt. Iets vreemds dat me opviel, was dat de plannen-pagina aangaf dat ik 8,73 ACU’s over had, ondanks dat er al 1,7 ACU van de in totaal 9 was gebruikt (zie de blauwe markering in de Core-sectie).

De pagina Usage & Limits liet echter correct zien dat we 1,7 ACU hadden gebruikt en 7,3 ACU over hadden.

Ik keek 18 uur later nog eens, en toen toonde de plannen-pagina 7,3 ACU resterend, dus het bijwerken van deze informatie heeft een kleine vertraging. Gebruik de pagina Usage & Limits als je bron van waarheid om verrassingen te voorkomen!

Was het de moeite waard?

Laten we de cijfers erbij pakken.

Dus, 1,7 ACU à $2,25/ACU = $3,83 voor deze sessie.

Ik besteedde misschien 20 minuten aan prompten en reviewen. Het helemaal handmatig doen zou daar ruim overheen zijn gegaan, en ik had elke stap uitgesteld omdat dit precies het type taak is dat ik bijzonder saai vind. Voor de prijs van een cappuccino nam Devin het werk van me over. Die ruil maak ik elke dag.

Wat is de volgende stap?

Oké, we hebben:

Ons account aangemaakt
Onze GitHub-repository gekoppeld
De repo ingesteld voor toekomstige sessies op Devin’s machine
Onze eerste dependency-upgrade-taak gedraaid
Onze sessiemetrics en verbruik bekeken

Prima begin! In de volgende tutorial gaan we dieper en dagen we Devin verder uit door het te vragen volledige features te plannen en implementeren, inclusief API- en database-integraties.

Klaar om door te gaan? Klik dan op het tweede item hieronder om naar de tweede tutorial te gaan: