Werken met een developer aan een met AI gebouwde app

Om goed met een developer te werken aan een app die je met AI hebt gebouwd, geef je de code in een Git-repository, een samenvatting van één pagina over wat de app doet en waarom, en een duidelijk afgebakende taak met een definitie van klaar. Spreek af wie welke onderdelen wijzigt, zodat jij en de AI elkaars werk niet overschrijven, houd de repository- en hostingaccounts op jouw naam, en deel geheimen via de juiste instellingen in plaats van via berichten.

Veel mensen bouwen de eerste versie van een app met AI en halen daarna een developer erbij — om betalingen toe te voegen, iets te repareren wat de AI steeds verkeerd doet, de beveiliging te controleren, of het over te nemen naarmate de app groeit. Als je nog moet beslissen of je iemand inhuurt, zie een developer inhuren of met AI bouwen. Deze gids gaat ervan uit dat je dat hebt besloten en de samenwerking soepel wilt laten verlopen.

Wanneer een developer de moeite waard is

Gangbare redenen om iemand erbij te halen:

• Een probleem dat de AI niet kraakt na meerdere duidelijke pogingen en terugdraaiacties.
• Riskante onderdelen: betalingen, rechten, gevoelige gegevens, databasemigraties.
• Een beveiligings- of codecontrole voor de lancering of voordat je grotere klanten aanneemt.
• Prestaties zodra er echt verkeer komt.
• Groei: de app is een bedrijf geworden en heeft iemand nodig die de code beheert.

Welke van deze het is, bepaalt wat hieronder het belangrijkst is.

Stap 1: zet de code op een deelbare plek

Developers werken vanuit Git-repositories. Voordat je iemand benadert:

1. Koppel het project aan een privé GitHub-repository (of iets vergelijkbaars), of exporteer het.
2. Zorg dat er geen geheimen in de code of geschiedenis staan. Zie hoe je API-sleutels veilig houdt.
3. Controleer dat het project draait vanuit een verse kopie — vraag de AI om de installatiestappen te schrijven.

Schrijf een README voor een developer die aan dit project meewerkt: wat de app doet, de stack, hoe je hem lokaal installeert en draait, de omgevingsvariabelen die nodig zijn (alleen namen), de mappenstructuur en alles wat kwetsbaar of ongebruikelijk is.

Als Git nieuw voor je is, behandelt hoe je Git gebruikt met een met AI gebouwde app de basis.

Stap 2: schrijf een briefing van één pagina

De developer heeft jouw chatgeschiedenis niet meegemaakt. Geef de context op één pagina:

• Wat de app doet, voor wie, en hoeveel mensen hem gebruiken.
• Wat het belangrijkst is — de stromen die nooit mogen breken.
• Bekende problemen en wat je al hebt geprobeerd.
• De taak, en hoe je weet dat die klaar is.
• Beperkingen: budget, deadline, dingen die ze niet mogen veranderen.

Een goede ‘definitie van klaar’ is toetsbaar: ‘Een ingelogde gebruiker kan een maandabonnement betalen met Stripe Checkout, het abonnement verschijnt op zijn accountpagina, en opzeggen in het klantenportaal zet hem aan het einde van de periode terug naar het gratis plan.’ Niet ‘regel de betalingen’.

Stap 3: geef veilig toegang

• Code: voeg ze toe als medewerker van de repository. Stuur geen ZIP-bestanden heen en weer zodra het werk is begonnen.
• Builder: als je AI-app-builder teamleden ondersteunt, nodig ze uit voor een werkruimte die alleen dit project bevat.
• Geheimen: voeg ze toe in de instellingen van je host, of deel ze via een wachtwoordmanager. Plak sleutels nooit in e-mail of chat.
• Testaccounts: maak die aan met testgegevens, in plaats van je eigen login te delen.
• Productiegegevens: alleen als ze die echt nodig hebben, en alleen wat ze nodig hebben.

Houd de repository-, domein- en hostingaccounts op jouw naam. Voeg mensen toe; geef geen accounts uit handen.

Stap 4: spreek af wie wat wijzigt

De grootste bron van wrijving is dat twee partijen — jij met een AI, en de developer — tegelijk dezelfde code wijzigen. Kies een regel:

Wat je ook kiest: pull de nieuwste code voor elke sessie met prompts, en doe grote wijzigingen op branches die de ander kan beoordelen.

Stap 5: communiceer schriftelijk

• Meld problemen met stappen, verwacht resultaat en werkelijk resultaat. Zie hoe je een goede bugrapportage schrijft.
• Houd beslissingen op één plek: een issuetracker, een gedeeld document of opmerkingen bij pull requests.
• Vraag hen om elke wijziging in een pull request in gewone taal uit te leggen.
• Spreek af hoe vaak jullie elkaar spreken.

Stap 6: controleer hun werk

Je hoeft code niet te lezen om werk te beoordelen. Controleer:

• Het doet wat de briefing vroeg, op de preview of de stagingkopie.
• Er is niets anders kapotgegaan — draai je kritieke stromen.
• Ze hebben uitgelegd wat ze hebben gewijzigd en waarom.
• Er zijn geen geheimen in de code verschenen.

Voor een nauwkeurigere blik heeft hoe je met AI gegenereerde code beoordeelt een checklist die ook voor door mensen geschreven code werkt. Je kunt je AI-builder ook vragen om een pull request van een developer in duidelijke taal voor je uit te leggen.

Stap 7: houd het eigendom duidelijk

• De repository, hosting, het domein en de accounts van derden blijven van jou.
• Leg het eigendom van de code die ze schrijven schriftelijk vast voordat het werk begint. Check lokale regels of een adviseur voor contractvragen.
• Als het werk klaar is, haal je hun toegang weg en vervang je alle sleutels die ze hebben gezien.

Voorbeeldprompts

Een developer heeft in de laatste pull de checkoutcode gewijzigd. Leg in gewone taal uit wat ze hebben veranderd en of er nog iets anders in de app van afhangt.

Maak een lijst van de onderdelen van deze app die het meest complex of riskant zijn, zodat ik een developer kan vertellen waar de controle op moet focussen.

Ik geef de betalingen aan een developer. Raak vanaf nu geen bestanden aan onder src/payments of de /api/billing-routes. Als een wijziging die nodig heeft, vertel het me dan.

Veelgemaakte fouten

• Geen briefing. De developer besteedt betaalde uren aan het achterhalen van wat je wilde.
• Vage scope zoals ‘los de bugs op’ of ‘maak het productieklaar’.
• Beiden tegelijk bewerken zonder eerst te pullen, waarna werk verloren gaat in conflicten.
• Je eigen login delen of sleutels in chat plakken.
• Accounts op naam van de developer, waardoor het moeilijk wordt om uit elkaar te gaan.
• Vergeten de toegang weg te halen en sleutels te vervangen na de klus.

Checklist

• De code staat in een privérepository op mijn naam, zonder geheimen erin.
• Een README legt de installatie uit; een briefing van één pagina legt de app en de taak uit.
• De taak heeft een toetsbare definitie van klaar.
• Toegang loopt via uitnodigingen als medewerker, geheimen via instellingen of een wachtwoordmanager.
• We hebben afgesproken wie wat wijzigt, en ik pull voordat ik prompt.
• Het werk wordt beoordeeld aan de hand van de briefing en de kritieke stromen.
• Het eigendom staat schriftelijk vast; toegang wordt weggehaald en sleutels worden vervangen als het werk eindigt.

Werken met een developer op Mythex

• Nodig ze uit voor een werkruimte. Eigenaren kunnen onbeperkt medewerkers uitnodigen zonder kosten per zetel; leden werken aan de projecten van de werkruimte. Gebruik een aparte werkruimte zodat ze alleen dit project zien. Credits voor gepubliceerde apps worden gefactureerd aan de eigenaar van de werkruimte. Zie Uitnodigingen.
• GitHub-sync en export (Pro). Koppel een repository en push/pull, of exporteer het project zonder geheimen. Zie GitHub, export en import.
• Deel een previewlink om werk in uitvoering aan iemand zonder Mythex-account te laten zien; verwijder die als je klaar bent.
• Ask mode beantwoordt vragen over de code zonder die te wijzigen — handig om de wijzigingen van een developer te begrijpen.

Als de developer de app elders wil draaien, zie hoe je een met AI gebouwde app exporteert en zelf hostt.

Veelgestelde vragen