In this post:
Een content engineer is degene die het systeem ontwerpt, bouwt en draaiende houdt dat de content van een bedrijf maakt, in plaats van elk stuk zelf te schrijven. Wat hij oplevert, is een werkende pipeline: briefs, research, AI-concepten, reviewstappen en distributie, zo aan elkaar gekoppeld dat een klein team veel goed materiaal kan publiceren zonder dat de kwaliteit wegzakt.
De functietitel is nieuw en wordt nog los gebruikt. Sommige bedrijven bedoelen een schrijver die handig is met ChatGPT, andere iemand die dichter bij een GTM engineer staat en toevallig aan content werkt. De bruikbare definitie is de tweede. Een content engineer wordt beoordeeld op de machine, en op wat die machine elke week naar buiten stuurt. De artikelen die hij zelf heeft getypt, tellen daarbij veel minder.
Werven gaat mis als een bedrijf sneller wil schrijven en dat engineering noemt. Je krijgt meer concepten, dezelfde bottlenecks en een blog dat langzaam volloopt met pagina's die allemaal hetzelfde klinken.
TL;DR
Je ziet het werk het best door één stuk bronmateriaal erdoorheen te halen: één klantinterview wordt een onderbouwd artikel, een reeks LinkedIn-posts, een one-pager voor sales en zinnen voor outbound, en elk stuk wordt gecontroleerd voordat het de deur uitgaat.
De rol ontstond omdat schrijven niet langer de bottleneck was. Zodra een model in een paar seconden een redelijk eerste concept schrijft, zit het schaarse werk in de brief, de review en de distributie. De CMO van Jasper schreef in september 2025 al over de functietitel.
Een contentstrateeg bepaalt wat je zegt, een content engineer bouwt het systeem dat het zegt, en een GTM engineer bouwt de leidingen die het naar de juiste accounts brengen. In kleine teams bezet één persoon vaak twee van die stoelen.
De meeste content engineers worden uiteindelijk eigenaar van vier gekoppelde systemen: research, productie, repurposing, en distributie met meting. De koppelingen ertussen tellen zwaarder dan welke losse tool ook.
Mensen blijven op drie punten betrokken: het point of view bepalen, de brief goedkeuren en het eindresultaat aftekenen. De promptinggids van Anthropic zelf vergelijkt een model met een briljante nieuwe medewerker zonder context, en daarom bepaalt de brief het grootste deel van de kwaliteit.
Bij volume gaat het mis. Het spambeleid van Google noemt het met AI genereren van veel pagina's "zonder waarde toe te voegen voor gebruikers" als scaled content abuse. Houd de output dus op wat je kunt reviewen, en beoordeel het systeem op pipeline en reply rates in plaats van op aantallen pagina's.
Wat een content engineer bouwt uit één klantinterview
Abstracte beschrijvingen van deze rol klinken allemaal hetzelfde, dus neem een concreet geval. Stel je een Rotterdams bedrijf voor dat planningssoftware verkoopt aan expediteurs (het bedrijf is voor dit voorbeeld verzonnen). De customer success lead neemt een gesprek van 40 minuten op met een klant die haar lege kilometers flink terugdrong door retourvrachten anders te plannen.
Zonder contentsysteem blijft die opname op een gedeelde schijf staan. Misschien schrijft iemand er over een paar maanden een case study over. Met een content engineer gaat hetzelfde gesprek door een pipeline die er al ligt:
Het transcript komt in een researchtabel terecht, waar een AI-stap eruit haalt wat het probleem was, welke cijfers de klant wil delen, welke quotes bruikbaar zijn en welke bezwaren ze had voordat ze kocht.
De contentstrateeg leest die samenvatting en kiest de invalshoek: retourvrachten zijn een margeprobleem, en wie ze als roosterpuzzel behandelt, mist dat. Die gedachte wordt de kern van de brief.
Een schrijfworkflow maakt een lang artikel op basis van de brief, het transcript en de stijlgids van het bedrijf. Een mens redigeert het, controleert elk cijfer aan de hand van de opname en keurt het goed.
Een repurposingstap maakt van het goedgekeurde artikel vier LinkedIn-posts voor de oprichter en de customer success lead, een samenvatting van één pagina die sales na een demo kan sturen, en twee korte zinnen die reps kunnen gebruiken in outbound naar expediteurs met hetzelfde probleem.
Alles krijgt een tag met het onderwerp en het brongesprek, zodat het team later kan zien welk interview welke pipeline opleverde.
Niets in dat lijstje is bijzonder. De waarde zit erin dat het elke keer draait als er een goed gesprek is geweest, zonder dat iemand eraan hoeft te denken. En één stuk echt klantbewijs komt zo op vijf plekken bij kopers terecht in plaats van op één.
Een vergelijking met loodgieterswerk past goed. Een schrijver brengt het water met een emmer naar elke kraan. Een content engineer legt één keer de leidingen en besteedt zijn tijd daarna aan de druk, de lekken en waar het water hierna heen moet.
Waarom de rol van content engineer juist nu ontstond
Jarenlang was het schrijven zelf het dure deel van content. Een goed B2B-artikel kostte een ervaren schrijver een dag of twee, dus teams planden rond die grens en publiceerden wat hun schrijvers konden maken.
Taalmodellen veranderden wat er schaars is. Een degelijk eerste concept kost nu bijna niets, maar een degelijk eerste concept was nooit wat content liet werken. Waar nog steeds vakmanschap in zit: weten wat je wilt zeggen, materiaal verzamelen dat niemand anders heeft, de claim opvangen die niet klopt en het afgeronde stuk voor de mensen krijgen voor wie het geschreven is. Dat zijn net zo goed systeemproblemen als schrijfproblemen.
De functietitel volgde die verschuiving. In een post van de CMO van Jasper uit september 2025 wordt content engineering omschreven als het ontwerpen, bouwen en optimaliseren van contentproductiesystemen die op AI draaien, met de formulering dat een contentmarketeer stukken maakt en een content engineer de systemen die die stukken maken. Jasper verkoopt AI-marketingsoftware en heeft er baat bij als de titel aanslaat. De omschrijving klopt wel met wat de mensen die dit werk doen in de praktijk doen.
Het past ook in een breder patroon binnen go-to-market. Leadonderzoek, enrichment en routing gingen de afgelopen jaren van handwerk naar gebouwde systemen, en content volgt hetzelfde pad, alleen iets later.
Content engineer vs contentschrijver, strateeg en GTM engineer
De rol plaats je het makkelijkst door te kijken naar wat elke persoon oplevert.
Een contentschrijver levert stukken op: het artikel, de nieuwsbrief, de e-mail. Een contentstrateeg levert beslissingen op: welke onderwerpen ertoe doen, wat het bedrijf vindt, welke argumenten je maakt en welke je laat liggen. Een content engineer levert het systeem op, dus de workflows, templates, reviewstappen en koppelingen die van die beslissingen een gestage stroom afgerond werk maken. De AI-modellen zitten binnen dat systeem en doen het mechanische schrijf- en herformatteerwerk.
De naaste verwant is de GTM engineer. Allebei bouwen ze systemen in plaats van het werk met de hand te doen, en allebei hebben ze commercieel gevoel nodig voor wat het bouwen waard is. Het verschil zit in het materiaal. Een GTM engineer werkt aan de revenuekant van de GTM-stack: enrichment, scoring, routing, outbound-sequences. Een content engineer werkt aan wat er door die leidingen stroomt. In de praktijk geven ze voortdurend dingen aan elkaar door. De content engineer maakt een set pagina's die elk één bezwaar behandelen, en de GTM engineer zorgt dat de sequence van een rep op het juiste moment de juiste pagina naar het juiste account stuurt.
In een bedrijf van dertig mensen doet één persoon vaak allebei, en soms ook het werk van de strateeg. Dat werkt zolang iedereen weet welk deel dat kwartaal minder aandacht krijgt. Grotere teams splitsen de stoelen, meestal met de content engineer bij marketing en de GTM engineer bij RevOps.
De vier systemen die een content engineer draaiende houdt
"Systeem" kan vaag klinken, dus dit zijn de systemen die steeds terugkomen. Elk lost een ander probleem op, en het lastigste deel zit meestal waar het ene systeem het volgende voedt.
Research
Hier wordt content specifiek. Het researchsysteem verzamelt materiaal dat een concurrent niet kan kopiëren: gespreksopnames, CRM-data, supporttickets, productgebruik, aantekeningen van het salesteam. Zonder dat systeem is elk AI-concept gebouwd op hetzelfde openbare internet als dat van iedereen, en dat lees je er ook aan af.
Productie
Productie maakt van een brief een gecontroleerd concept dat bij het merk past. In de praktijk is het een keten van stappen in een AI-workflow, elk met een smalle taak (outline, concept, factcheck tegen de bron, stijlronde), gebouwd in tools als n8n, Make of Clay en met een model als Claude. Het vakmanschap zit in de instructies. Goede prompt engineering lijkt hier sterk op goed redactiewerk: een duidelijk publiek, een duidelijke claim en voorbeelden van hoe goed werk eruitziet.
Repurposing
Eén groot stuk wordt veel kleinere stukken, elk gevormd voor zijn eigen kanaal. Een artikel wordt posts voor LinkedIn, een paar alinea's voor de nieuwsbrief, een slide voor sales en korte zinnen voor outbound e-mails. AI-copywriting doet de eerste ronde. Een mens controleert of de korte versies nog iets zeggen, want bij het inkorten raakt de nuance vaak kwijt.
Distributie en meting
Dit systeem brengt elk stuk waar het heen moet en legt vast wat er gebeurde. Het is ook het deel dat de meeste teams overslaan. Content op een blog waar niemand komt, heeft niets opgeleverd, hoe efficiënt hij ook gemaakt is. Daarom bouw je de distributie met dezelfde zorg als het concept.
Waar mensen in de loop blijven, en waarom de brief het zwaarst weegt
Een contentsysteem waar geen mensen meer in zitten, is hoe bedrijven uiteindelijk zelfverzekerde onzin publiceren. Een goed gebouwd systeem zet mensen precies waar hun oordeel het resultaat verandert, en haalt ze weg uit de stappen waarin ze alleen maar overtypten.
Dat zijn drie punten. Het eerste is het point of view: wat het bedrijf vindt van zijn markt, en dat kan een model niet voor je beslissen. Het tweede is de brief, geschreven of op z'n minst goedgekeurd door iemand die het onderwerp kent. Het derde is de eindcontrole, waar een mens het stuk leest zoals een koper dat zou doen en het verkeerde cijfer, de claim die niet bij het merk past of de alinea die niets zegt eruit haalt. Dit is hetzelfde ontwerp met een human in the loop dat voor elke AI-workflow geldt, nu toegepast op tekst.
De brief verdient de meeste aandacht, want daar wordt het grootste deel van de kwaliteit bepaald. De promptinggids voor Claude van Anthropic raadt aan het model te zien als een briljante maar nieuwe medewerker die de context van jouw normen mist. Een vage brief levert ook bij een menselijke schrijver een vaag artikel op, maar een mens komt in elk geval terug met vragen. Een model vult de gaten met het gemiddelde van alles wat het heeft gelezen. Veel klachten dat "AI-content generiek is" blijken bij nader inzien klachten over magere briefs.
Waar je de poorten zet, is een afweging. Review je elke zin, dan heb je een handmatig proces nagebouwd met extra stappen. Review je niets, dan bereiken fouten je kopers. Het meeste afstemwerk van een content engineer gaat zitten in het verschuiven van die controlepunten, tot het systeem snel is en toch te vertrouwen.
Het loont ook om open te zijn over hoe de content gemaakt is. De richtlijnen van Google voor nuttige content die voor mensen geschreven is raden aan uit te leggen hoe een stuk tot stand kwam, inclusief automatisering of AI, als lezers zich dat redelijkerwijs zouden afvragen. Een systeem dat zijn bronnen en reviewers vastlegt, maakt dat makkelijk.
Volume is het deel dat je makkelijk verkeerd doet
Een werkend contentsysteem kan veel meer opleveren dan hetzelfde team met de hand zou kunnen schrijven. Dat is het verkoopargument van de rol, en ook het grootste gevaar.
Zoekmachines hebben een naam voor de slechte versie. Het spambeleid van Google omschrijft scaled content abuse als het genereren van veel pagina's met als hoofddoel rankings te manipuleren, en noemt als voorbeeld het gebruik van generatieve AI-tools om veel pagina's te maken zonder waarde toe te voegen voor gebruikers. Het beleid richt zich op het gebrek aan waarde. De tool zelf is het probleem niet. Een systeem dat meer publiceert dan zijn reviewers kunnen lezen, is in de geest al over die grens, nog voordat iemand bij Google het merkt.
De vangrails gaan er dus tegelijk met de motor in: een scherpe brief, een kwaliteitscheck die concepten afwijst die niet bij de toon passen of niet onderbouwd zijn, en een volumeplafond dat je baseert op wat je kunt reviewen, in plaats van op wat de tools kunnen genereren.
Meten werkt volgens dezelfde logica. Outputaantallen vertellen je dat de machine draait. Of hij werkt, vertellen ze niet. Kijk aan de inboundkant naar rankings, organisch verkeer en de pipeline die dat verkeer oplevert, want dat is wat demand generation hoort te produceren. Vergelijk aan de outboundkant de reply- en meetingrates van content-led outbound en personalisatie op schaal met die van dezelfde sequence zonder de content. Een flink deel van het effect zie je in geen enkel rapport terug, omdat kopers links doorsturen in privékanalen (dat is dark social). Het loont dus om "Hoe heb je over ons gehoord?" als open vraag op het demoformulier te zetten, de simpelste vorm van self-reported attribution.
Let daarna op drift. Een snel systeem gaat zelden met veel lawaai kapot. De artikelen worden iets vlakker, de claims iets vager, en een paar weken later zakken de cijfers. Behandel de pipeline als software: lees elke week een steekproef, en zoek bij een kwaliteitsdaling de stap die veranderde.
Kort gezegd
De content engineer bestaat omdat de kosten van schrijven instortten, terwijl de kosten van iets te zeggen hebben dat de moeite waard is gelijk bleven. Iemand moet de route bouwen van echt materiaal (klantgesprekken, dealdata, de meningen van de mensen die het onderwerp kennen) naar afgeronde stukken voor de juiste kopers, met controles onderweg.
Werf daarop. Een goede content engineer praat over briefs, reviewpoorten en waar de content terechtkomt, voordat hij vertelt welk model hij het liefst gebruikt. Hij gaat ook in tegen volumedoelen, want de snelste manier om een contentsysteem te verspillen is het op aantallen pagina's te richten. Goed ingevuld zorgt de rol ervoor dat thought leadership en sales enablement uit hetzelfde bronmateriaal komen, en krijgt de rest van de revenue-machine waar je team op draait iets wat het versturen waard is.
Nebor werkt aan de kant hiervan die sales raakt: de researchtabellen, de repurposingstappen en de koppelingen van content naar outbound-sequences en CRM-rapportages. Dat zetten we op in de eigen workspaces van de klant, en we laten bij elke stap geschreven notities achter, zodat de mensen die de content maken het systeem zelf kunnen bijstellen.
Veelgestelde vragen
Welke skills heeft een content engineer nodig?
Twee sets die zelden samengaan. Aan de redactionele kant: weten hoe een sterke brief eruitziet, snappen hoe search en structuur werken, en snel een zwakke claim of een alinea die niet bij het merk past herkennen. Aan de systeemkant: je thuis voelen bij automatiseringstools als n8n, Make of Clay, precieze instructies voor taalmodellen schrijven en basiskennis van data. De redactionele smaak is de helft die het moeilijkst te vinden is, want die bouw je op in jaren van lezen en redigeren.
Moet een content engineer kunnen programmeren?
Meestal niet. De meeste contentsystemen worden gebouwd in no-code-automatiseringsplatforms en AI-tools, met hier en daar wat JSON of een API-call. Een webhook-payload kunnen lezen of een kapotte veldmapping kunnen repareren helpt veel. Productiesoftware schrijven komt zelden voor. Iemand die nooit heeft geprogrammeerd maar graag spreadsheets en automatiseringen bouwt, pakt de technische kant meestal sneller op dan een developer redactioneel oordeel ontwikkelt.
Is een content engineer gewoon iemand die met AI schrijft?
Nee, en werven alsof dat zo is, is de meest gemaakte fout. Een model een blogpost laten schrijven is een klein en makkelijk deel van het werk. Het echte werk zit in alles rond het concept: bronmateriaal verzamelen dat niemand anders heeft, briefs schrijven, reviewstappen bouwen, elk stuk ombouwen voor andere kanalen en het bij kopers krijgen. Een schrijver met ChatGPT levert meer artikelen op. Een content engineer levert een systeem op.
Hoe weet je of je een schrijver of een content engineer hebt aangenomen?
Vraag je af wat er stilvalt als die persoon drie weken op vakantie gaat. Stoppen de artikelen, dan heb je een schrijver aangenomen, hoeveel AI hij ook gebruikt. Blijven de artikelen gecontroleerd en verspreid verschijnen omdat de workflows, briefs en reviewstappen zonder hem doordraaien, dan heb je een content engineer aangenomen. Het werk van die tweede persoon zie je terug in vastgelegde processen. Een lijst gepubliceerde stukken met zijn naam erboven vertelt maar een deel van het verhaal.
Valt een content engineer onder marketing of onder RevOps?
De meeste zitten bij marketing, naast de contentstrateeg, omdat daar de redactionele beslissingen vallen. De rol heeft wel een korte lijn nodig met RevOps of GTM engineering, want dat team beheert het CRM, de sequences en de rapportages die laten zien of content pipeline wordt. In kleinere bedrijven beantwoordt de vraag zichzelf vaak, omdat één technische marketeer zowel de contentsystemen als de bredere go-to-market-tooling voor zijn rekening neemt.
Welke tools gebruikt een content engineer meestal?
Een taalmodel als Claude of GPT voor concepten en samenvattingen, een automatiseringsplatform als n8n, Make of Zapier om de stappen te koppelen, vaak Clay of een spreadsheet als researchtabel, het CMS waarin content wordt gepubliceerd, en het CRM om bij te houden welke stukken deals raken. Welke tools het precies zijn, doet er minder toe dan hoe ze op elkaar aansluiten. Een simpele stack met duidelijke reviewstappen werkt beter dan een uitgestrekte stack die niemand kan onderhouden.
Schaadt content die met AI is gemaakt je rankings?
Niet op zichzelf. De richtlijnen van Google over generatieve AI vragen om nauwkeurigheid, kwaliteit en relevantie, en het spambeleid richt zich op grote aantallen pagina's die zonder waarde voor gebruikers zijn gegenereerd. Het gebruik van AI als zodanig is daar geen doelwit. Artikelen op basis van eigen materiaal, gecontroleerd door iemand die het onderwerp kent en gepubliceerd in een tempo dat het team kan reviewen, zijn prima. Honderden dunne pagina's die je maakt omdat de tools het goedkoop maken, brengen een site in de problemen.
Wanneer is een bedrijf klaar om een content engineer aan te nemen?
Als het contentteam weet wat het wil zeggen en de bottleneck zit in het consequent produceren en verspreiden ervan. Heeft het bedrijf nog geen helder point of view, dan maakt een content engineer alleen sneller generieke content. Een goed teken dat je klaar bent, is een achterstand aan goed ruw materiaal, zoals klantgesprekken, salesnotities of productdata, dat nooit gepubliceerd werk wordt omdat niemand tijd heeft om het te verwerken.
Wat moet een content engineer als eerste bouwen?
Eén smalle pipeline die van begin tot eind werkt, liever dan vier halfgebouwde. Een goed eerste project is opgenomen klantgesprekken omzetten in een onderbouwd artikel plus korte posts en snippets voor sales, waarbij een mens elke output goedkeurt. Het raakt research, productie, repurposing en distributie, dus je ziet snel waar de zwakke plekken zitten, en het levert vanaf de eerste week content op die specifiek is voor het bedrijf.
Kan een contentschrijver doorgroeien naar content engineer?
Ja, en veel goede content engineers komen uit het schrijven of redigeren. Ze weten al hoe kwaliteit eruitziet, en dat is het moeilijke deel. Wat ze erbij moeten leren, is systeemdenken: een proces stap voor stap in kaart brengen, de repetitieve delen automatiseren en de resultaten meten. Eén kleine workflow bouwen voor hun eigen werk, zoals automatische researchsamenvattingen voor elk artikel, is een praktische manier om de technische kant te leren.
Deel dit bericht
Content
Marketing
Begrippenlijst
Gerelateerde begrippen
De basis GTM-concepten begrijpen
Klaar om je pipeline te bouwen
