Forward Deployed Engineering
Een Forward Deployed Engineer gaat namens een softwarebedrijf (zoals Palantir of OpenAI) het veld in om de software of AI implementatie van dat bedrijf bij een klant neer te zetten.
Bij deze klant regisseert de FDE het implementatieproces en voert deze uit: specificatie, bouw, configuratie, testen en debuggen van de solution binnen het bestaande systeem van de klant. Hierbij draagt hij de verantwoordelijkheid voor de kwaliteit van de implementatie. Eigenlijk is hij een soort one man army die het vermogen heeft om e2e eigenaar te zijn van de oplossing.
Quality Engineering
Quality engineering gaat over het nemen van verantwoordelijkheid over de kwaliteit en het implementeren van maatregelen die d.m.v. preventie, detectie of correctie risico’s gedurende de hele levenscyclus beheersen. AI is daarbij zowel een nieuw testobject als nieuw gereedschap, en uit beide rollen komen nieuwe maatregelen voort zoals: evals en guardrails omdat een AI-systeem eigenschappen heeft die klassieke maatregelen niet dekken, spec-driven development om intent en scope vast te leggen voor wat een agent bouwt. Daarnaast verschuift ook de economische afweging achter maatregelen die we als effectief kennen.
Forward Deployed Quality Engineering
Als QA Company lopen wij voorop in deze ontwikkelingen. Om duidelijkheid te verschaffen in wat wij neerzetten, introduceren we de rol van Forward Deployed Quality Engineer.
Onze FDQE’s brengen onze agentic maatregelen, services, upskilling, kennis en kunnen naar de klant, configureren deze en hebben het vermogen om e2e eigenaarschap te nemen in de implementatie van quality stacks: de agents, tooling, pipelines, quality gates en dashboards waarmee een organisatie kwaliteit borgt. Waar de FDE eigenaar is van de kwaliteit van één oplossing, is de FDQE eigenaar van de manier waarop de klant kwaliteit borgt, over systemen, teams en leveranciers heen.
FDE
Eigenaar van de kwaliteit van één oplossing.
FDQE
Eigenaar van de manier waarop de klant kwaliteit borgt.
Een FDQE wordt ingezet om een concreet quality-engineeringprobleem op te lossen. Dat kan zowel binnen AI-systemen als binnen deterministische software en quality stacks zijn. Dat kan bijvoorbeeld een transformatie, implementatie of structurele verbetering zijn.
1Testing AI
Een organisatie zet AI-systemen in, zelf gebouwd of van een leverancier, en wil kunnen aantonen dat ze doen wat ze moeten doen. AI-systemen ontwikkelen is iets anders dan traditionele software ontwikkelen. Een AI-systeem kan technisch correct functioneren en toch antwoorden geven die onjuist, inconsistent, ongewenst of onvoldoende betrouwbaar zijn.
Dat maakt ook het borgen van kwaliteit wezenlijk anders. Er is vaak geen eenduidig juist antwoord om tegen te testen. Hetzelfde systeem geeft op dezelfde vraag niet altijd hetzelfde antwoord, dus kwaliteit wordt een percentage met een drempelwaarde in plaats van geslaagd of gefaald. En een nieuwe modelversie, een aangepaste prompt of een bijgewerkte kennisbank kan het gedrag veranderen zonder dat er één regel code wijzigt.
Traditionele software
Per test een eenduidige uitkomst: geslaagd of gefaald.
AI-systeem
Een percentage, getoetst aan een drempelwaarde.
De FDQE maakt meetbaar of het AI-systeem doet wat het moet doen en het doel bereikt waarvoor het is ingezet:
- 1Begrijpen: onderzoekt welke kwaliteitseisen en risico's uit het beoogde gebruik voortvloeien.
- 2Concretiseren: helpt die eisen vertalen naar toetsbare kwaliteitscriteria en acceptatievoorwaarden.
- 3Valideren: ontwerpt en realiseert evaluaties (evals) waarmee aantoonbaar wordt in hoeverre het systeem aan de verwachtingen voldoet.
- 4Bewaken: monitort kwaliteit en signaleert wanneer het systeem niet langer aan de afgesproken verwachtingen voldoet.
Samen vormen ze geen keten maar een cyclus: wat bij het bewaken opvalt, voedt opnieuw het begrijpen en concretiseren. Zo zet de FDQE de quality stack voor AI neer: eval-sets en monitoring, die blijven werken ongeacht wie het AI-systeem bouwt. Daarmee wordt een AI-oplossing niet alleen gebouwd en geïmplementeerd, maar ook aantoonbaar beheerst op kwaliteit.
2Framework Migratie
Een organisatie wil verouderde testautomatisering migreren naar een moderne technologie. In dit geval kan de FDQE:
- 1de bestaande testautomatisering analyseren en testassets en coverage inventariseren;
- 2vooraf vastleggen wanneer de nieuwe suite gelijkwaardig is aan de oude;
- 3een migratiestrategie bepalen en AI inzetten voor de transformatie;
- 4equivalentie en coverage meten;
- 5en de nieuwe suite integreren in CI/CD en continu monitoren.
Hiermee wordt de FDQE niet simpelweg ingezet als testautomatiseerder. De FDQE realiseert een complete quality-engineeringtransformatie en maakt het resultaat meetbaar. Een dergelijke aanpak vormt bijvoorbeeld de basis van QA Company's Migraite-oplossing voor het versneld migreren van legacy test automation naar moderne testtechnologie.
3Implementatie Testing Agents
Een organisatie wil testing agents introduceren in de software development lifecycle. De vraag is welke testactiviteiten met agents geautomatiseerd kunnen worden op dusdanige wijze dat men op de agents kan vertrouwen.
De FDQE kan dan:
- bepalen waar agents daadwerkelijk waarde kunnen toevoegen;
- de intent (wat de software moet doen en waarom) zo vastleggen dat de output van agents eraan getoetst kan worden;1
- testing agents selecteren, configureren en integreren met development- en CI/CD-processen;
- bepalen welke acties autonoom mogen worden uitgevoerd en hoe de mens toezicht houdt (human on the loop);
- en de kwaliteit van agent-output meten, met quality gates en continue monitoring.
De FDQE zet daarmee niet alleen agents in, maar bouwt de kwaliteitsmechanismen rondom die agents.
Conclusie
Zoals de FDE namens een softwarebedrijf de oplossing bij de klant neerzet, zet de FDQE namens QA Company de quality stack neer, met hetzelfde e2e-eigenaarschap. Zo stelt de FDQE organisaties in staat om AI-systemen, moderne testautomatisering en testing agents snel in te zetten, met aantoonbaar beheerste kwaliteitsrisico's.
Bronnen
- intent-driven.dev, Intent-Driven Development (bijgewerkt 23 augustus 2026): "Intent-Driven Development (IDD) is the practice of building software with AI coding agents by making your intent explicit (...)" en "Because intent is explicit, you can check work against it." https://intent-driven.dev/knowledge/intent-driven-development/ ↩
