Intro
Vier maanden geleden besloot ik een vreemd experiment te doen: een productiewebsite bouwen zonder zelf één regel code te schrijven. Alles - backend, frontend, infrastructuur, CI/CD, beeldverwerking - zou door AI worden geschreven. Mijn rol zou zijn om te beschrijven wat ik wilde en het resultaat te superviseren.
Vier maanden en 663 commits later: bigunphoto.com is live. ~60.500 regels code, 260 afbeeldingen, 16 pagina's in drie talen. GitHub-geschiedenis vertelt het volledige verhaal. Infrastructuurkosten: ongeveer €8/maand. Kosten voor AI: €0. Ik heb nog steeds geen enkele regel toepassingscode geschreven. Dit is geen tutorial of succesverhaal. Het is een verslag van wat er gebeurde.
Waarom ik begon
In mijn huidige rol beheer ik een team dat automatiseringsprogramma's bouwt, aanpast of overneemt. Omdat ik een iets andere loopbaanpad volgde, voelde ik vaak een groeiende technische kloof tussen mezelf en de ingenieurs waar ik mee werk - ik kon over architectuur discussiëren, maar bouwde zelf niets. Tegelijk wilde ik AI-ontwikkelingsprogramma's van binnenuit leren kennen, niet vanuit demo's. De beste manier om in engineering te leren is nog steeds hetzelfde: bouw iets echt.
Mijn vrouw is een professionele fotograaf. Ze had nooit een echte website - alleen Instagram. Dat gaf me een speelplaats. Het doel was niet om het perfecte ontwikkelingsportfolio te bouwen. Het doel was om te zien hoe ver AI-geassisteerde ontwikkeling kan gaan.
De regels
Ik stelde drie beperkingen.
Geen handmatige code - alle toepassingscode door AI.
Minimale budget - ik onderzocht, speelde en was niet zeker genoeg van de resultaten om te investeren.
Echte engineering-stack - geen kant-en-klare e2e-oplossingen zoals WordPress; gebruik van containers, CI/CD, moderne frameworks.
In de praktijk bewerkte ik af en toe handmatig wat YAML, CSS, JSON-bestanden. De rest was AI-generatie. Ik ben nu zo lui dat ik zelfs een CSS-padding niet meer wil oplossen - ik inspecteer het element, probeer waarden in de console, en zeg dan tegen de AI: los deze padding op, het ziet er naar uit.
De stack eindigde uiteindelijk zwaar voor een portfolio.
Frontend: Next.js, React, TypeScript, Tailwind, Tiptap, Zustand.
Backend: Node.js, Express, PostgreSQL, PgBoss, Sharp. Authenticatie: sessiegebaseerd (PostgreSQL), bcrypt, OAuth (Google, Apple, Facebook), TOTP voor admin. Beveiliging: AES-256-GCM voor PII, blind indices.
Infra: Vercel (frontend), AWS Lightsail (backend), Docker Compose], Nginx; k3s + Skaffold voor lokale ontwikkeling. Waarom een vlieg met een kruitvezel slaan? Omdat ik een trainingsplek wilde voor de technologie die mijn teams op het werk gebruiken - inclusief Kubernetes, om simpelweg geen angst meer te hebben voor onze interne clusters.
Tijdlijn
Fase 1: Chatbots en infrastructuur.
Ik begon met ChatGPT en Gemini. Een ding dat ik snel ontdekte: chatbots werken beter als je ze vraagt je te interviewen. "Stel me één vraag tegelijk over het systeem dat we willen bouwen en wacht op mijn antwoord voordat je de volgende stelt." Dat hielp om te verduidelijken wat ik eigenlijk wilde. Het nadeel is: als je via chat ontwikkelt, blijft de AI vaak vragen stellen - één detail meer, één verduidelijking meer. Het trekt context uit jou. Het kan voelen alsof je wordt geïnterviewd totdat het genoeg heeft. Hetzelfde patroon als je later de AI vraagt je te helpen schrijven over het onderwerp: het blijft tokens uit jou trekken. Daarom verhuisde ik later naar specificaties - een punt waar we later op terugkomen. In plaats van de context stukje bij beetje te laten extraheren, geef je het in één keer. Met deze aanpak definieerden we de architectuur: de brede vorm van wat de stack hierboven werd - backend, frontend, database, implementatiemodel. Voor productie overweegden we Vercel en Render. Voor lokale ontwikkeling wilde ik iets dichter bij wat onze teams gebruiken - Docker Desktop viel door het loodje vanwege licentie, dus ik koos voor Rancher Kubernetes en DevPod. DevPod draait ontwikkelomgevingen in de cloud of je lokale Kubernetes-cluster; ik had het eerder gebruikt met ContainerLab, volgens voorbeelden van mijn collega Roman Dodin, en dacht dat het me zou kunnen helpen om omgevingen over te brengen tussen mijn Windows-PC op het werk en mijn persoonlijke MacBook. Op dat moment waren ongeveer 60% van deze technologieën nieuw voor mij.
Maar chatbots leven in de cloud. Ze kunnen je lokale machine niet zien. Elke stap bij het oplossen van problemen betekende logs in de chat plakken. Het contextvenster at zichzelf op. Modellen begonnen te hallucineren, vast te lopen, te vergeten. Ik begon de AI te zien als een gemotiveerde student die zelfverzekerd zal liegen om het examen te halen. Wat tien jaar geleden eenvoudig was - XAMPP installeren en gaan coderen - is nu een ander verhaal met containers en Kubernetes. Infrastructuuropstelling duurde veel langer dan ik verwachtte: 2-3 weken avonduren. Ik besteedde veel tijd aan worstelen met DevPod, proberen een stabiele lokale omgeving te krijgen. Uiteindelijk verhuisde ik naar Skaffold, wat de ontwikkelomgeving automatisch implementeert en opschoont. Dat vereenvoudigde de dingen. Maar tegen dat moment was mijn enthousiasme al begonnen te dalen. Ik stapte zelfs een tijdje uit het project.
Fase 2: Gemini CLI.
Het keerpunt kwam toen ik Gemini CLI vond. Ik had een YouTube-video van Network Chuck erover gezien en besloot het eens te proberen. In tegenstelling tot chatbots draait het lokaal in je projectmap en ziet het de hele codebase. Het kan bestanden lezen, documentatie bijwerken, commando's uitvoeren. De eerste keer dat ik het startte was ik onder de indruk en lichtelijk geschrokken - het genereerde code zo snel dat ik nauwelijks mee kon volgen. Productie-implementatie, die weken had gekost om lokaal voor te bereiden, was gedaan in een paar late-nightsessies. Ik gaf het de taak om de website-pagina's te maken. Een paar minuten later had het een set pagina's gegenereerd en een design dat redelijk goed uitzag voor een fotografieportfolio. Ik was onder de indruk - ik besteedde zo veel tijd aan voorbereiding en nu is het allemaal voorbij? Gelukkig niet. Gemini CLI deed een goede job met pretenderen dat de taak gedaan was. De meeste pagina's waren statisch, veel fallbacks, functies zoals authenticatie of dynamische galerijen waren niet geïmplementeerd of met problemen gedaan. Het werk was pas begonnen. Maar ik kon al resultaten zien. Naarmate het project groeide, begon Gemini CLI vast te lopen, onzin te geven, de draad te verliezen. Sessies raakten vast en moesten gedood worden, context werd verloren. Ik realiseerde me: als de AI geen kaart heeft, rijdt hij je in de sloot.
Fase 3: Spec-first-ontwikkeling.
Dingen beweegden pas toen ik stopte met "chatten" en gestructureerde specificaties begon te schrijven. Van prompt engineering naar spec engineering. Ik verhuisde naar Cursor en Antigravity wat net op dat moment werd uitgebracht; regels en projectoverzicht in Markdown-bestanden te hebben, liet me met verschillende AI-agents parallel werken. De spec werd een save point - als één model zijn quotum raakte, kon ik de spec naar een ander nemen en doorgaan. Verschillende modellen voor verschillende taken: Gemini Pro en Claude Opus voor planning, Claude Sonnet en Gemini Flash voor code. Mijn workflow:
Beschrijf de functie
Vraag het model een ontwerp voor te stellen
Verfijn de spec
Genereer implementatie
Test
Vraag het model bugs te fixen
Commit
Als instructies vaag waren, produceerden modellen inconsistente of incorrecte implementaties. Een typische spec zag er zo uit:
Functie: Clientgalerij
- Klanten zien watermerkpreviews; download alleen voor goedgekeurde afbeeldingen
- Galerietoegang beschermd door uitnodigingscode
- Afbeeldingen asynchroon verwerkt via PgBoss-wachtrij
...
Dan vroeg ik het model architectuur en implementatie voor te stellen. De spec gaf het een kaart in plaats van context stukje bij beetje te laten extraheren. Het moeilijkste was niet coderen. Het was duidelijk uitleggen wat ik wilde. Op een gegeven moment herinnerde ik me iets wat ik al wist - en als manager had moeten weten: het maakt niet uit of je werkt met AI of met een expert-ingenieur; een precise specificatie is een must. Dat inzicht alleen was de moeite waard.
Wanneer de realiteit productie raakte
We gingen live met Vercel en Render, zoals de AI aanraadde. De site werkte. Dan kwam de eerste redeploy - ik ververste de pagina en elke enkele afbeelding was weg.
Render's gratis plan heeft een efemere bestandssysteem - geüploade bestanden blijven niet behouden bij redeploys. De AI had geen idee. Gemini CLI was zich van deze beperking volledig niet bewust. Toen ik vroeg waarom de afbeeldingen verdwenen, met logs van troubleshooting, bleef het alles behalve de werkelijke oorzaak aanwijzen - e-mailprovider, configuratie - verschillende troubleshooting-streams door elkaar halen. Het was urenlang koppig. Ik moest zelf googlen om de oplossing te vinden, de ephimera filesystem ontdekken, en de backend naar AWS migreren. Dat leidde tot een complete configuratie-herstructurering. Het was een van de momenten dat ik realiseerde dat je niet door chatten naar een betrouwbare productiesysteem kunt.
De merge-hel. Op een gegeven moment ging Gemini CLI rogue, bewerkte een hoop code, deed een slechte niet-bevestigde merge - en een gefaalde rollback wiste dagen aan vooruitgang weg. Mijn fout - ik committe niet vaak genoeg. Ik had de AI gevraagd alles in het projectoverzicht bij te houden, ook Technical Debt en Resolved Issues bij te werken; op een gegeven moment herschreef het dat bestand ook en de geschiedenis was weg. Je kunt niet te veel aan de AI delegeren.
De donkere kant
AI-ontwikkeling kan verslavend zijn - alsof je geld verliest in een casino. Nog één prompt en je wint het terug. Plotseling is het 3:00 's nachts, je schreeuwt naar het scherm en slaat op het toetsenbord. Het is niet gezond. AI geeft je de illusie van een persoon achter het scherm, maar emotionele prompts verlengen alleen het contextvenster en brengen je verder van de oplossing. Als je worstelt, is het beter om de status samen te vatten, logs op te slaan, en een nieuwe sessie te starten of een nieuwe agent te openen, emoties aan de kant zetten.
Het is mogelijk om complexe systemen sneller te bouwen dan je ze echt begrijpt.
Dat is één van de grootste risico's van AI-geassisteerde ontwikkeling. Soms herschreven modellen delen die ik niet had gevraagd te raken; als ik niet goed doorlas, konden hele secties afwijken. Als de codebase groeit, wordt debuggen moeilijk als je de code niet zelf schreef. Het is ook moeilijk om gefocust te blijven - ideeën springen op, je begint parallel te implementeren. Ik begon de AI te vragen notities op te slaan in verschillende bestanden die we hadden zodat niets verloren ging.
Eén ding waar ik paranoïde van werd: geheimen. Je hebt .gitignore voor jezelf, maar AI-agents hebben hun eigen nodig. Sleutels en wachtwoorden moeten buiten de repo blijven. Het kon behoorlijk subtiel zijn ze uit sessies te krijgen, zelfs decoderen. Tijdens troubleshooting vond de AI vaak een weg om toegang te vragen - 's nachts klik je af en toe door. Het is beter om tijdelijke sleutels voor de AI te gebruiken en productiegeheimen geïsoleerd te houden.
Visitekaartjesite. Wat het werd
Geen simpele portfolio. Een klein Fotografie Business Systeem: portfolio, klantenbeheer, afspraakboeking, privégalerijen, levering. Een aangepaste blokgebaseerde CMS met drag-and-drop-pagina-builder. WYSIWYG-teksteditor. Beveiligde clientgalerijen met watermerkpreviews en hoge-resolutie levering. Klanten kunnen boeken via E-mail, Instagram, WhatsApp, Telegram. Voor offline leads - zeg de fotograaf ontmoette iemand op een bruiloft - maakt het systeem schaduwprofielen en genereert uitnodigingslinks zodat ze zich kunnen registreren en later hun galerijen kunnen raadplegen. PgBoss verwerkt asynchroon beeldverwerking: watermerkken, preview-generatie, bulk-opname van Google Drive. Meertalig (EN, RU, NL) met regionale prijzen. De workflow: client boekt of admin maakt afspraak; als nieuw, schaduwprofiel en uitnodigingslink; admin keurt goed, shoot vindt plaats, admin markeert afgerond; client selecteert uit watermerkpreviews of fotograaf uploadt finales direct; als client accepteert, sluit afspraak. De site host momenteel 260 afbeeldingen, 4 galerijen, 16 pagina's in drie talen. Verkeer is tot nu toe klein. Maar het systeem werkt.
Wat ik leerde
AI is goed in scaffolding en boilerplate, slecht in architectuur en lange-termijn consistentie. AI daagt je zelden uit. Het doet meestal precies wat je vraagt - zelfs als het een slecht idee is. Als het faalt, schakelt het vaak te vroeg over op een snelkoppeling in plaats van een juiste oplossing te vinden.
Spec engineering verslaat prompt engineering.
Je kunt systemen bouwen sneller dan je ze begrijpt. Versiebeheerdiscipline wordt erg snel kritisch.
AI vervangt engineeringoordeel niet - het versterkt welke discipline je al hebt. Goede discipline wordt beter; slechte discipline produceert spaghetti sneller.
Ik werd niet plotseling een React-expert of ontwikkelaar. Maar ik kreeg een veel duidelijker beeld van hoe moderne stacks bij elkaar passen - containers, CI/CD, frameworks. Ik ben nu niet meer zo verloren in discussies met engineeringteams. De echte opbrengst: voor dit project had ik nog nooit een commit gepusht in mijn leven. Nu ben ik prima in staat om CI/CD-pipelines op het werk op te zetten. Ik pas dit al toe - Power Automate scripts, JSON-parsers, interne RAG-apps. Ik stopte ermee een "manager die over AI praat" te zijn en werd iemand die ermee bouwt.
Ik zou dit systeem niet aan een klant verkopen. Ik ben geen ontwikkelaar. De authenticatie, versleuteling en datastromen werden geïmplementeerd door AI met mijn supervisie, maar ik ben geen beveiligingsingenieur. De site kan kwetsbaarheden bevatten die ik gewoon niet zie. Maar als experiment was het een succes.
Als ik opnieuw begon, zou ik het chatgedeelte overslaan, starten met specificaties voor de algemene architectuur en apart voor elke functie, een agentieke aanpak gebruiken - verschillende taken toewijzen aan verschillende modellen - en veel vaker committen.
Conclusie
Ik probeer nog steeds nieuwe tools en aanpakken. Ik experimenteer met lokaal gehoste LLMs via LM Studio en Ollama, zat ze in VSCode met Continue. Ik houd OpenClaw in de gaten maar ben voorzichtig met het installeren - door de community gemaakte agents met diepe systeemtoegang maken me nerveus. AI beweegt sneller dan ooit, nieuwe tools en modellen verschijnen bijna elke week, en je beslist constant wat je gebruikt terwijl de grond onder je voeten verschuift.
Andrey Doronichev vergelijkde AI eens met elektriciteit - je kunt intelligentie lenen van het net zoals je energie leent. Dat vind ik goed. Het betekent ook dat we zwakker kunnen worden als we ophouden met onze hersenen te gebruiken ten gunste van "geleende intelligentie." Net als elektriciteit kan pijn doen als je niet weet hoe je het moet gebruiken. Het maakt geen zin om het te negeren of bang te zijn dat het je zal vervangen. Vind je manier om de golf te rijden, niet door hem geraakt te worden. AI zal ons in geen enkele beroepsuitoefening vervangen. Maar een expert die AI gebruikt, zal degene die het niet doet vervangen. Het experiment beantwoordde de vraag: hoe ver kun je komen met het bouwen van echte software met AI? Verder dan ik verwachtte - maar niet zonder risico's. En als je toch een fotografiewebsite over-engineert, kun je net zo goed door gaan. Volgende plannen? Ik wil de website-functionaliteit uitbreiden en een virtueel fotostudio verkennen - ik test al ComfyUI, diffusiemodellen en beeldgeneratiewerkmethode. Ik wil mobiele app-ontwikkeling proberen, iets waar ik in het verleden mee heb gesjouwd. En natuurlijk zijn er op mijn hoofdberoep genoeg kansen om deze vaardigheden toe te passen. Ik probeer ideeën wel onder controle te houden - het is te makkelijk de focus te verliezen met de eindeloze mogelijkheden die AI biedt.