8 september 2026September 8, 2026

Mijn AI-development journey: van experimenteren naar een eigen developmentstraatMy AI-development journey: from experimenting to my own development pipeline

De afgelopen maanden ben ik steeds actiever bezig geweest met AI-development. Niet vanuit het idee om ineens softwaredeveloper te worden, maar vooral vanuit nieuwsgierigheid: wat kan er tegenwoordig eigenlijk met AI? Hoe werkt het? Misschien nog wel interessanter: wat kan ik er zelf mee? Dat begon niet helemaal vanuit het niets. Tijdens verschillende opdrachten zag ik AI al steeds duidelijker naar voren komen.

De eerste ervaringen met AI

Bij KWF, alweer 3 jaar geleden, waren we al actief bezig met verschillende AI-ideeën en proof-of-concepts. Vanuit mijn rol als Security Officer keek ik daarbij voornamelijk naar de securitykant. Wat betekent het als je AI gaat gebruiken? Welke mogelijkheden zijn er, maar ook welke securityrisico’s komen daarbij kijken?

Later, tijdens mijn opdracht bij Toyota Louwman Financial Services, werd AI opnieuw steeds zichtbaarder. Er werd veel over gesproken en ook op Europees niveau kwamen initiatieven op gang, bijvoorbeeld in de vorm van hackathons. Langzaamaan begon AI ook steeds meer binnen de organisatie zelf een onderwerp te worden. Op dat moment keek ik er vooral vanuit mijn eigen vakgebied naar. Interessant, veel mogelijkheden, veel securityrisico’s om te mitigeren, maar nog niet direct iets waarmee ik zelf applicaties aan het bouwen was. Dat veranderde nadat mijn opdracht bij Toyota was afgelopen.

Van erover praten naar zelf gaan bouwen

Daarna ontstond de ruimte om er zelf veel verder in te duiken. Ik sprak hier en daar met mensen die al actiever met AI-development bezig waren en begon steeds beter te begrijpen wat er inmiddels mogelijk was. Een eerste echte stap was een Claude Code-cursus die mijn neef, Mark de Kock, samen met iemand anders had gemaakt. Daarmee begon ik zelf daadwerkelijk te bouwen. Vanaf dat moment ging het eigenlijk behoorlijk hard.

Eerst relatief eenvoudig, een blog maken. Daarna een eerste concept voor een website. Dingen waarvan ik vooraf verwachtte dat ze behoorlijk wat tijd zouden kosten, bleken ineens in heel korte tijd te realiseren. Tijdens het bouwen kwamen er steeds meer ideeën. Als dit kan, wat kan ik dan nog meer maken?

Van ideeën naar applicaties die ik daadwerkelijk gebruik

Langzaamaan werden die ideeën steeds concreter. Voor een training die ik in de tussentijd heb gegeven, heb ik bijvoorbeeld een applicatie ontwikkeld die de training op verschillende manieren ondersteunt. Hetzelfde heb ik gedaan rond de ISO 27001 Lead Implementer-training die ik zelf heb gevolgd. Op basis van openbare bronnen en beschikbare informatie heb ik een eigen leer- en examenapplicatie gemaakt. Die heb ik vervolgens ook werkelijk gebruikt als ondersteuning bij het leren voor mijn examen. Dat bleek veel waardevoller dan alleen het hebben van een extra tool.

Door de onderwerpen zelf in een applicatie te verwerken, vragen te maken en verbanden zichtbaar te krijgen, begon ik de materie ook op een andere manier te begrijpen. Het bouwen van de applicatie werd daarmee tegelijkertijd een manier om zelf te leren.

Het hoeft ook niet allemaal zakelijk te zijn. Zo heb ik bijvoorbeeld een kleine applicatie gemaakt om samen met mijn zoon te gebruiken en mee te spelen. Andere ideeën zijn inmiddels verder in ontwikkeling. Daar zal ik later meer over delen wanneer ze daadwerkelijk live staan. Dat is voor mij misschien wel een van de leukste kanten hiervan. Een idee hoeft niet meer maanden op een lijstje te blijven staan. Je kunt je idee gewoon proberen te realiseren.

Langzaam ontstond een eigen developmentstraat

In het begin was het vooral experimenten, inmiddels is daar steeds meer structuur omheen ontstaan. Claude Code is voor mij de omgeving geworden waarin een idee in eerste instantie tot leven komt. Dat kan een proof-of-concept zijn, een MVP of gewoon iets waarvan ik wil weten: werkt dit eigenlijk? Vanuit daar wordt de applicatie lokaal opgebouwd. De branding die voor Hammer Cyber Security Services door Mats Roelofs, de grafisch vormgever, is ontwikkeld, kan daarbij direct worden meegenomen. Daardoor krijgen ook verschillende eigen applicaties steeds meer dezelfde herkenbare uitstraling.

Alleen een applicatie kunnen genereren is natuurlijk niet voldoende. Juist vanuit mijn securityachtergrond vind ik het belangrijk om ook te kijken naar wat er nodig is voordat zoiets daadwerkelijk online kan. Daarom heb ik in de loop van de tijd verschillende skills en controles opgebouwd. Die helpen om bijvoorbeeld naar de security van een applicatie te kijken, randvoorwaarden te controleren en te bepalen wat er nog moet gebeuren voordat een applicatie klaar is voor deployment. Het doel is daarbij om zoveel mogelijk op een gestandaardiseerde manier te werken, om vooral de AI-modellen op één manier te laten werken waar geen zaken worden vergeten. Dezelfde prompt in verschillende projecten levert namelijk verschillende uitkomsten op en dat moet voorkomen worden. Je wilt dat zoveel mogelijk op de door mij geverifieerde methode wordt uitgevoerd.

Van lokaal naar daadwerkelijk online

Ook voor deployment is inmiddels een duidelijke straat ontstaan. De ontwikkeling gebeurt lokaal. De code gaat vervolgens naar afgeschermde repositories in GitLab en vanuit daar kan deployment plaatsvinden via Vercel. Via DNS koppel ik vervolgens de juiste domeinen en subdomeinen aan de applicaties en is de applicatie live. Erg gaaf hoe dat nu werkt.

Daarmee heb ik inmiddels een omgeving staan waarin ik soms binnen een aantal uur, maar vaker binnen één of enkele dagen, van een idee naar een daadwerkelijk online werkende applicatie kan gaan. Technisch zou het waarschijnlijk nog sneller kunnen. Maar dat is voor mij niet het belangrijkste doel. Snel iets kunnen bouwen is mooi. Het moet alleen ook gecontroleerd, veilig en onderhoudbaar gerealiseerd worden.

Niet ieder experiment hoeft succesvol te zijn

De omgeving die zo is ontstaan zie ik inmiddels ook een beetje als mijn eigen speeltuin. Als ik een idee heb waarvan ik denk: dit zou interessant kunnen zijn, dan kan ik het gewoon uitwerken. In plaats van lang na te denken of het idee goed genoeg is om er veel tijd of geld in te investeren, kan ik eerst kijken wat er gebeurt als ik het daadwerkelijk bouw. Soms blijkt een idee uiteindelijk minder interessant dan gedacht. Dat is dan ook niet zo erg. Dan kan de applicatie weer offline en heb ik tijdens het maken alsnog nieuwe dingen geleerd. Dat vind ik een groot verschil met hoe ik vroeger naar zo’n idee zou kijken. De afstand tussen een idee en iets wat daadwerkelijk werkt, is enorm veel kleiner geworden.

Trial-and-error hoort erbij

In deze reis is zeker niet alles direct goed gegaan of gaat het nu helemaal vlekkeloos. De developmentstraat die ik nu gebruik is niet vooraf volledig uitgedacht. Die is ontstaan door ermee te werken. Dingen proberen, ergens tegenaan lopen, uitzoeken waarom iets niet werkt. Vervolgens aanpassen en opnieuw proberen. Sommige dingen werken verrassend goed, andere dingen helemaal niet. Juist dat trial-and-errorproces heeft mij veel geleerd. Niet alleen over AI-development zelf, maar ook over applicatiedevelopment, deployment, diepere security en hoe al die onderdelen uiteindelijk met elkaar samenhangen. Hoe verder ik ermee kom, hoe meer ik ook zie dat er nieuwe vraagstukken ontstaan.

Een voorbeeld daarvan is de keuze voor tooling. Voor deployment gebruik ik momenteel bijvoorbeeld Vercel. Als je vervolgens vanuit Europese digitale soevereiniteit naar zo’n developmentstraat kijkt, merk je dat een gelijkwaardig Europees alternatief niet altijd zomaar beschikbaar is. Dat onderwerp verdient wat mij betreft een eigen blog, want daar zit veel meer achter dan alleen de vraag waar een leverancier zijn verwerkingen doet.

Hetzelfde geldt voor de securitykant van AI-development. De verschillende skills, controles, instructies en structuren die ik inmiddels gebruik om development en deployment beter beheersbaar te maken, zijn inmiddels uitgebreid genoeg om daar afzonderlijk verder op in te gaan.

Van nieuwsgierigheid naar een eigen AI-developmentomgeving

Als ik terugkijk naar de afgelopen maanden, vind ik vooral bijzonder hoe snel dit zich heeft ontwikkeld. Het begon met ervaringen met AI bij klanten, gesprekken met mensen die er actief mee bezig waren en uiteindelijk een cursus om zelf eens te kijken hoe dat bouwen nu eigenlijk werkt. Daarna kwam een eerste websiteconcept, een eerste blog en vervolgens het ene idee na het andere.

Inmiddels staat mijn eigen website online en heb ik verschillende applicaties gebouwd die ik zelf daadwerkelijk gebruik. Andere applicaties zijn nog in ontwikkeling en zullen de komende tijd volgen. Een mooie ontwikkeling is dat ik nu een eigen omgeving heb waarin ik een idee kan pakken en dat soms binnen één dag daadwerkelijk online kan krijgen. Niet alles hoeft uiteindelijk een product te worden. Het mag ook gewoon een experiment zijn.

Tegelijkertijd probeer ik ervoor te zorgen dat die snelheid niet ten koste gaat van controle, security en onderhoudbaarheid. Als securityprofessional geef ik vaak juist dat advies bij klanten: het moet gecontroleerd, veilig en onderhoudbaar blijven.

Wat begon als wat experimenteren tussen opdrachten in, is daarmee uitgegroeid tot een zeer leerzame reis in AI-development. Een reis die nog lang niet klaar is, want hoe meer ik ermee werk, hoe meer ideeën er eigenlijk bijkomen. Over een aantal van die ideeën, de applicaties die daaruit zijn ontstaan en de security- en developmentstructuur die ik eromheen heb gebouwd, zal ik in volgende blogs verder schrijven.

Heb je ideeën, feedback, een interessant cybersecurityvraagstuk of wil je gewoon eens bijpraten of kennismaken? Laat het me weten, ik kom graag in contact.

Over the past months I’ve become increasingly active with AI-development. Not with the idea of suddenly becoming a software developer, but mainly out of curiosity: what can you actually do with AI these days? How does it work? Maybe even more interesting: what can I do with it myself? That didn’t start completely out of nowhere. During various assignments, I saw AI coming up more and more clearly.

My first experiences with AI

At KWF, already 3 years ago, we were already actively working on various AI ideas and proof-of-concepts. From my role as Security Officer, I mainly looked at the security side of things. What does it mean if you start using AI? What possibilities are there, but also what security risks come with it?

Later, during my assignment at Toyota Louwman Financial Services, AI became increasingly visible again. There was a lot of talk about it, and initiatives were also getting underway at a European level, for example in the form of hackathons. Gradually, AI also became more and more of a topic within the organization itself. At that time, I mainly looked at it from my own field of expertise. Interesting, lots of possibilities, lots of security risks to mitigate, but not yet something I was actually building applications with myself. That changed after my assignment at Toyota ended.

From talking about it to actually building it myself

After that, there was room to dive into it myself, much further. I talked here and there with people who were already more actively involved in AI-development and started to understand better what was possible by now. A first real step was a Claude Code course that my nephew, Mark de Kock, had made together with someone else. That’s when I actually started building myself. From that moment on, things moved pretty fast.

At first relatively simple, making a blog. Then a first concept for a website. Things I expected beforehand would take quite a bit of time suddenly turned out to be achievable in a very short time. While building, more and more ideas kept coming up. If this is possible, what else could I make?

From ideas to applications I actually use

Gradually those ideas became more concrete. For a training session I gave in the meantime, for example, I developed an application that supports the training in various ways. I did the same around the ISO 27001 Lead Implementer training I followed myself. Based on public sources and available information, I built my own study and exam application. I then actually used it as support while studying for my exam. That turned out to be far more valuable than just having an extra tool.

By working the topics themselves into an application, creating questions, and making connections visible, I also started to understand the material in a different way. Building the application became, at the same time, a way of learning it myself.

It doesn’t all have to be business-related either. For example, I built a small application to use and play with together with my son. Other ideas are currently further along in development. I’ll share more about those later, once they’re actually live. That’s perhaps one of the most enjoyable aspects of this for me. An idea no longer has to sit on a list for months. You can just try to make it happen.

Slowly, my own development pipeline emerged

In the beginning it was mostly experimenting; by now, more and more structure has grown around it. Claude Code has become the environment for me where an idea first comes to life. That can be a proof-of-concept, an MVP, or just something where I want to know: does this actually work? From there, the application is built up locally. The branding developed for Hammer Cyber Security Services by Mats Roelofs, the graphic designer, can be taken into account directly at that point. As a result, different applications of my own increasingly get the same recognizable look and feel.

Being able to generate an application alone is of course not enough. Precisely because of my security background, I find it important to also look at what’s needed before something can actually go online. That’s why, over time, I’ve built up various skills and checks. These help, for example, to look at the security of an application, check preconditions, and determine what still needs to happen before an application is ready for deployment. The goal here is to work in as standardized a way as possible, mainly to get the AI models to work in one consistent way so that nothing gets forgotten. The same prompt across different projects delivers different outcomes, and that needs to be prevented. You want as much as possible to be carried out according to the method I’ve verified myself.

From local to actually online

A clear pipeline has also emerged for deployment by now. Development happens locally. The code then goes to protected repositories in GitLab, and from there deployment can take place via Vercel. Via DNS, I then link the right domains and subdomains to the applications, and the application is live. It’s pretty amazing how that works now.

With that, I now have an environment in place where I can sometimes go from idea to an actual, working, online application within a few hours, but more often within one or a few days. Technically, it could probably go even faster. But that’s not my main goal. Being able to build something quickly is nice. It just also needs to be realized in a controlled, secure, and maintainable way.

Not every experiment has to succeed

I’ve come to see the environment that has emerged this way as a bit of my own playground. If I have an idea and think: this could be interesting, I can just work it out. Instead of thinking for a long time about whether the idea is good enough to invest a lot of time or money in, I can first see what happens if I actually build it. Sometimes an idea turns out to be less interesting than expected. That’s fine too. Then the application can go offline again, and I’ve still learned new things while making it. That’s a big difference, to me, compared to how I used to look at an idea like that. The distance between an idea and something that actually works has become enormously smaller.

Trial-and-error is part of it

On this journey, not everything has gone smoothly right away, and it certainly doesn’t run flawlessly now either. The development pipeline I use now wasn’t fully thought out in advance. It emerged by working with it. Trying things, running into something, figuring out why it doesn’t work. Then adjusting and trying again. Some things work surprisingly well, other things not at all. That trial-and-error process in particular has taught me a lot. Not just about AI-development itself, but also about application development, deployment, deeper security, and how all those parts ultimately connect. The further I get into it, the more I also see new questions arise.

One example of that is the choice of tooling. For deployment, I currently use Vercel, for instance. If you then look at a development pipeline like that from the perspective of European digital sovereignty, you notice that an equivalent European alternative isn’t always readily available. That topic deserves its own blog post, as far as I’m concerned, because there’s a lot more to it than just the question of where a vendor processes its data.

The same goes for the security side of AI-development. The various skills, checks, instructions, and structures I now use to make development and deployment more manageable are by now extensive enough to go into separately.

From curiosity to my own AI-development environment

Looking back at the past months, what strikes me most is how quickly this has developed. It started with experiences with AI at clients, conversations with people who were actively involved with it, and eventually a course to see for myself how building actually works. After that came a first website concept, a first blog, and then one idea after another.

By now, my own website is live, and I’ve built several applications that I actually use myself. Other applications are still in development and will follow in the coming period. A nice development is that I now have my own environment where I can take an idea and sometimes get it actually online within a single day. Not everything has to become a product in the end. It’s also fine for it to just be an experiment.

At the same time, I try to make sure that speed doesn’t come at the expense of control, security, and maintainability. As a security professional, I often give that exact advice to clients: it needs to stay controlled, secure, and maintainable.

What started as a bit of experimenting between assignments has grown into a very instructive journey in AI-development. A journey that’s nowhere near finished, because the more I work with it, the more ideas actually come up. I’ll write more in future blog posts about some of those ideas, the applications that have emerged from them, and the security and development structure I’ve built around it.

Do you have ideas, feedback, an interesting cybersecurity question, or would you simply like to catch up or get in touch? Let me know, I’d love to connect.

This translation has been made by AI.

Reactie achterlatenLeave a comment

Je reactie wordt eerst gecontroleerd voordat die hierboven verschijnt.Your comment is checked before it appears above.