Hand-werkplekafgeschermd en klaarIk bouw al jaren websites, automatiseringen en andere digitale projecten. En iedere keer kwam hetzelfde ritueel terug. Nog voordat ik iets nuttigs kon maken, moest eerst de technische gereedschapskist worden ingericht.
Account aanmaken. E-mailadres bevestigen. API-pagina zoeken. Key genereren. Secret kopiëren. Veilig lokaal of in een secret store zetten. Controleren of de juiste rechten aanstaan. En daarna vooral hopen dat je drie maanden later nog weet welke key waarvoor was.
Hoe mijn projectsetup eerst ging
Stel dat ik een website bouwde die GitHub, Cloudflare, e-mail, analytics en misschien een database nodig had. Dan betekende dat meestal dat ik bij al die aanbieders eerst de toegang moest regelen. Soms met OAuth, maar vaak ook met losse API-sleutels, tokens of secrets die ergens veilig moesten worden opgeslagen.
Voor een eigen project was dat al vervelend. Bij klantwerk werd het nog omslachtiger. Want uiteindelijk moest die klant het beheer weer zelf kunnen overnemen. Dan wil je niet dat een website afhankelijk blijft van een map op mijn laptop, mijn persoonlijke accounts of een verzameling keys waarvan alleen ik nog begrijp hoe alles aan elkaar hangt.
Het irritante was niet één stap. Het waren alle kleine stappen bij elkaar. Ze leverden nauwelijks waarde voor de klant op, maar ze kostten wel iedere keer tijd en aandacht.
Eén regel verandert niet: secrets gaan nooit naar GitHub
GitHub is de plek voor je code en wijzigingsgeschiedenis, niet voor API-sleutels, tokens of wachtwoorden. Als een .env-bestand secrets bevat, hoort dat bestand buiten versiebeheer te blijven — bijvoorbeeld via .gitignore. Secrets bewaar je lokaal, in een daarvoor bedoelde secret store of in de beschermde omgeving van je Hand.
GitHubCode en niet-geheime configuratieHands verandert die regel niet. Het voordeel is juist dat je bij ondersteunde apps veel minder vaak zelf met losse secrets hoeft te slepen, omdat de verbinding via OAuth of een beschermde koppeling kan lopen.
Wat OAuth voor mij verandert
Met Hands hebben we voor veel van de apps die ik het vaakst nodig heb die verbindingslaag al ingericht. In plaats van eerst uit te zoeken waar een API-key verstopt zit en hoe ik die veilig moet doorgeven, klik ik bij een ondersteunde app op verbinden en doorloop ik de OAuth-toestemming van die aanbieder.
OAuth klinkt technisch, maar voor mij is het praktische verschil heel simpel: ik hoef het wachtwoord of de API-sleutel niet zelf tussen systemen te verplaatsen. Ik geef via de aanbieder toestemming om een account aan mijn Hand te koppelen.
“Bekijk de website in GitHub, controleer in Analytics welke pagina’s het meeste verkeer krijgen en maak op dev een duidelijkere versie van de belangrijkste landingspagina.”
Dat is voor mij de echte winst. Ik ben minder tijd kwijt aan het klaarmaken van gereedschap en kan eerder zeggen wat ik daadwerkelijk wil bereiken.
Wel snelheid, niet alle controle weg
Snel verbinden zou weinig waard zijn als dat betekende dat een AI daarna onbeperkt overal bij kan. Daarom vind ik juist de tweede helft belangrijk: per Hand bepaal ik welke apps ik koppel en welke handelingen ik daarin toestaan wil.
Een app kan bij het verbinden brede toestemming vragen, terwijl de Hand zelf nog steeds kleinere grenzen krijgt. Ik kan bepaalde acties alleen laten lezen, andere laten uitvoeren en bij gevoeliger werk eerst een beoordeling of bevestiging laten vragen.
- Alleen de apps die nodig zijn. Een Hand hoeft niet automatisch toegang te hebben tot alles wat ik gebruik.
- Verschillende vrijheid per taak. Lezen kan prima automatisch zijn terwijl publiceren of wijzigen eerst mijn akkoord vraagt.
- De verbinding hoort bij de Hand. Niet bij een los tekstbestand met secrets dat ergens op mijn laptop ligt.
Mijn laptop is niet meer de werkplek waar alles vanaf hangt
De andere grote verandering is dat mijn eigen computer niet langer de plek hoeft te zijn waar het hele project leeft. Iedere Hand heeft een eigen afgeschermde Linux-werkplek. Daardoor hoeft mijn laptop niet continu een lokale IDE, terminals, processen en projectmappen open te houden om een agent te laten werken.
Dat verandert voor mij ook waar ik kan werken. Ik kan vanaf mijn computer een grotere bouwopdracht geven, later vanaf mijn telefoon controleren wat er is gebeurd en daarna weer verdergaan zonder dat dezelfde laptop al die tijd de werkomgeving moest blijven.
Dat is een subtiel verschil, maar voor mij een grote. De Hand heeft zijn eigen werkplek; ik gebruik het apparaat dat op dat moment handig is om richting te geven, te controleren en nieuwe opdrachten te geven.
Waarom dit bij klantwerk misschien nog belangrijker is
Bij een klantproject wil ik uiteindelijk iets achterlaten dat van de klant is. Zijn domein. Zijn GitHub. Zijn Cloudflare. Zijn accounts. Zijn data. Niet een website die alleen blijft werken zolang mijn laptop, mijn persoonlijke API-sleutels of mijn lokale configuratie bestaan.
Met een goede Hands-opzet kan ik vanaf het begin werken met de accounts en verbindingen die bij het project horen. De klant kan later zelf toegang beheren en de Hand blijven gebruiken, zonder dat ik eerst een technische schattenjacht moet organiseren om alle secrets en lokale configuratie over te dragen.
Voor mij is dat de grotere ontwikkeling achter Hands. AI kan inmiddels ongelofelijk snel code schrijven, onderzoek doen en automatiseringen bouwen. Maar als je vóór iedere opdracht eerst een halve gereedschapskist handmatig moet installeren en koppelen, verlies je een groot deel van die snelheid weer aan setup.
Niet meer: “Welke accounts, keys en lokale configuratie moet ik eerst regelen?” Maar: “Welke apps heeft deze Hand nodig, hoeveel vrijheid geef ik hem en wat wil ik dat hij voor me doet?”
Verbind de apps die je nodig hebt. Houd zelf de grenzen. Begin daarna gewoon met de opdracht.
Bekijk de beschikbare apps, koppel alleen wat voor jouw werk nodig is en bepaal per Hand hoeveel vrijheid prettig voelt.