Hoeveel engineers heb je nu nodig
AI-codeertools verhogen de individuele output, maar vervangen niet de behoefte aan engineers die systemen kunnen ontwerpen, gegenereerde code kunnen reviewen en verantwoordelijkheid nemen voor wat er wordt uitgeleverd. Teamgrootte hangt nog steeds af van scope, kwaliteitseisen en hoe consequent je engineers die tools inzetten.
Waarom de vraag lastig te beantwoorden is
De output per engineer is toegenomen, maar de relatie tussen tooladoptie en headcountreductie is niet lineair. Een team dat AI-tools goed inzet kan features sneller uitleveren. Het kan ook sneller technische schuld opbouwen als niemand controleert wat het model produceert. Het netto-effect op de benodigde headcount hangt af van factoren die per organisatie verschillen: complexiteit van de codebase, regelgevende beperkingen, de verhouding greenfield- tot onderhoudswerkzaamheden, en hoe ervaren de engineers zijn met AI-ondersteunde workflows.
Schattingen lopen uiteen, maar de consensus in discussies onder engineering-leiders is dat AI-tools bepaalde taken comprimeren, met name boilerplate-generatie, testscaffolding en eerste-versiedocumentatie, zonder het coördinatie-, architectuur- en beoordelingswerk te elimineren dat senior engineers doen.
Wat er daadwerkelijk verandert
De taken die het snelst krimpen zijn die met een duidelijke specificatie en een afgebakende output: schrijf een functie die X doet, genereer een migratiescript, maak een unit test voor deze methode. Dit zijn echte tijdsbesparingen.
Wat niet in hetzelfde tempo krimpt:
- Beslissen wat je bouwt en in welke volgorde
- AI-gegenereerde code reviewen op correctheid, beveiliging en onderhoudbaarheid
- Fouten debuggen in systemen die het model niet volledig begreep
- Context bijhouden over een grote codebase gedurende meerdere maanden
- Beslissingen communiceren naar stakeholders
Daarom is een AI-native engineer niet zomaar een snellere versie van een junior engineer. De winst is echt, maar je hebt onderliggende engineeringvaardigheid nodig om AI te sturen en de fouten op te vangen. Een engineer die AI-gegenereerde code niet betrouwbaar kan reviewen, bespaart je geen headcount. Die creëert een reviewlast voor iemand anders.
Een grove manier om over teamgrootte na te denken
Begin niet bij een headcountdoel, maar bij het werk:
- Breng de afzonderlijke werkstromen in kaart die parallel moeten lopen.
- Bepaal welke synchrone samenwerking vereisen en welke onafhankelijk zijn.
- Schat de complexiteit en het onderhoudsoppervlak van elke werkstroom.
- Weeg mee hoeveel van het werk goed genoeg gespecificeerd is opdat AI-tools zinvol kunnen versnellen.
Een team van drie engineers dat AI-tools goed inzet, kan vaak dekken wat voorheen vijf mensen vereiste, bij greenfield-productontwikkeling met een schone codebase. Bij legacy-systemen met hoge compliance-eisen verschuift de verhouding. De tools helpen minder; de beoordelingsvereiste blijft hoog.
Waar organisaties dit vaak fout doen
De meest gemaakte fout is het verminderen van het aantal mensen op basis van snelheidswinst in de vroege fases van een project, wanneer de requirements duidelijk zijn en de codebase nog klein is, om er vervolgens achter te komen dat het team onderbezet is zodra het systeem groeit en edge cases zich opstapelen.
Een verwante fout is alle engineers als uitwisselbaar behandelen zodra AI-tools in gebruik zijn. De variatie tussen engineers in hoe goed ze modeloutput aansturen, begrenzen en verifiëren is aanzienlijk. Twee engineers met vergelijkbare cv's kunnen sterk uiteenlopende resultaten opleveren, afhankelijk van hoe ze met deze tools werken. Zie hoe je het AI-vermogen van een engineer beoordeelt voor waar je op moet letten.
Waar we op testen
Het beoordelingsproces van Miyagami is ontworpen rond de vaardigheden die het meest tellen wanneer teams klein zijn en AI-tools een aanzienlijk deel van de output verzorgen. De fundamentals-assessment controleert of een engineer systematisch kan debuggen en prioriteiten kan stellen onder echte druk, zonder AI-ondersteuning. De AI-native assessment kijkt vervolgens of ze kunnen verifiëren wat een model produceert, en verkeerde logica of hallucinated APIs onderscheppen voordat ze worden uitgerold. Beide sessies scoren judgement by risk, de vaardigheid die het meest voorkomt dat een AI-ondersteund team snel in de verkeerde richting beweegt. Volledige details bij hoe we beoordelen.
Korte antwoorden
Betekenen AI-tools dat je minder engineers nodig hebt?
Soms, bij goed gespecificeerd greenfield werk, wel. Bij complexe of legacy systemen helpen de tools minder en blijft senior oordeelsvermogen essentieel. Personeelsreductie die volgt op de adoptie van tools zonder rekening te houden met review- en onderhoudswerkzaamheden, leidt doorgaans later tot problemen.
Wat is de minimale teamomvang voor een product startup?
Schattingen lopen uiteen, maar twee tot drie engineers die AI-tools goed inzetten, kunnen vroege productontwikkeling dekken. Je hebt minimaal één persoon nodig die de architectuur kan bewaken en gegenereerde code kritisch kan reviewen. Onder dat niveau wordt de review-lacune een reëel risico.
Hoe helpt Miyagami bij het bepalen van de teamomvang?
Miyagami plaatst fulltime senior engineers in plaats van projectteams, zodat klanten capaciteit per engineer kunnen uitbreiden. Dankzij de vijfdaagse shortlist-doorlooptijd kun je inspelen op scopewijzigingen zonder je te moeten vastleggen op een grote hire voordat de requirement is bevestigd.
