Verbind je met ons

Gedachte leiders

De API-explosie is echt – en Vibe-codering steekt de lont aan

mm
De AI-hausse heeft ons veel gebracht: productiviteitsverhogingen, nieuwe creatieve workflows en, meer recent, een lawine aan API's. Als het voelt alsof het aantal interne en externe API's binnen uw bedrijf in één nacht is verdubbeld, dan verbeeldt u zich dat niet. We maken een API-explosie door en generatieve AI is een belangrijke katalysator.

Nog maar een paar jaar geleden was het implementeren van een nieuw API-eindpunt in een volwassen codebase een kwestie van veel frictie. Je moest de eigendomsrechten van meerdere codedomeinen beheren, goedkeuringen van chagrijnige architecten verkrijgen en reviews uitvoeren die soms weken of maanden duurden. De frictie was pijnlijk, maar zorgde er wel voor dat elke nieuwe API een zekere mate van controle en institutioneel geheugen met zich meebracht.

En nu? AI-gestuurde ontwikkeltools hebben dat knelpunt opgelost.

GenAI-agenten kunnen enorme hoeveelheden contextuele data verwerken en binnen enkele seconden codewijzigingen in honderden bestanden doorvoeren. Dit heeft de mogelijkheid om API's te creëren gedemocratiseerd – niet alleen voor engineers, maar zelfs voor niet-technische rollen (schokkende cijfers) zoals productmanagers en supportteams die zich nu misschien in staat voelen om experimenten rechtstreeks naar productie te sturen.

Het is een enorme verschuiving in wie de macht heeft in het softwareontwikkelingsproces. En dat is niet per se slecht, vooral niet in een zakelijke omgeving die snelheid en iteratie vooropstelt. Maar het resultaat is een razende stroom snel geïmplementeerde API's: veel ervan werden gelanceerd als 'experimenteel' of verborgen achter feature flags, maar ontwikkelen zich snel tot essentiële infrastructuur naarmate de bedrijfsbehoeften evolueren. Wat begint als een snel prototype, groeit uit tot een belangrijke integratie. En nu is het te laat om het terug te draaien.

De opkomst van 'vibe-codering'

Deze nieuwe generatie door AI gegenereerde API's komt vaak met weinig architectuur, documentatie of tests. We noemen dit fenomeen 'vibe coding': software schrijven op basis van ruwe intuïtie, losse aanwijzingen en een algemeen idee van wat 'zou moeten werken', in plaats van een diepgaand begrip van systemen of ontwerppatronen.

Helaas volgen API's die op deze manier zijn ontwikkeld vaak inconsistente conventies, missen ze robuuste validatie en negeren ze vaak gevestigde interne standaarden. Erger nog, ze kunnen ernstige beveiligings- of regelgevingsrisico's met zich meebrengen, vooral wanneer ze verbonden zijn met gevoelige gegevens of extern gerichte eindpunten. AI kent het governancemodel van uw bedrijf niet – of uw compliancevereisten. Tenzij expliciet aangegeven, zal het niet met deze informatie in gedachten schrijven.

En de problemen worden snel groter. AI wordt ook steeds vaker gebruikt om tests te genereren. Maar wanneer kapotte code wordt getest met door AI gegenereerde validaties, bevestigen de tests slechts gebrekkig gedrag. Ontwikkelaars aarzelen om tests te schrijven voor code die ze niet zelf hebben geschreven, laat staan voor code die door machines is gegenereerd, dus AI vangt de klus op. Het resultaat? Een recursieve feedbacklus van code van lage kwaliteit die getest en "gevalideerd" is door een even wankele scaffolding.

Patchwork API's en de eigendomscrisis

Dit alles leidt tot een wijdverspreide, gefragmenteerde API-laag binnen de meeste organisaties. API's bestrijken nu overlappende domeinen, voeren vergelijkbare functies op net iets andere manieren uit en missen vaak een duidelijk eigenaarschap. Veel API's zijn geschreven zonder diepgaande kennis van de onderliggende datamodellen, servicegrenzen of teamcharters. Het is dan ook niet verwonderlijk dat onderhoud een nachtmerrie wordt. Wie is de eigenaar van dit eindpunt? Wie kan het aanpassen? Wie weet er überhaupt van dat het bestaat?

AI-tools geven prioriteit aan bruikbaarheid en snelheid. Als ze niet worden gecontroleerd, creëren ze de kortste weg naar levering, ongeacht of deze wel of niet overeenkomt met uw architectuurvisie. Na verloop van tijd kan de last van deze technische schuld de voortgang tot stilstand brengen.

Enkele praktische stappen die u kunt nemen.

1. Zichtbaarheid

Het antwoord is niet om alles te vertragen of AI te verbieden. Dat is niet realistisch en zou enorme waarde laten liggen. In plaats daarvan moeten we evolueren hoe we software beheren in het tijdperk van generatieve ontwikkeling.

De eerste fundamentele stap is zichtbaarheid. Je kunt niet beheren wat je niet kunt zien. Organisaties hebben behoefte aan continue API-detectie, niet aan statische documentatie die al verouderd is zodra deze wordt gepubliceerd.

Tools die API's monitoren – zowel tijdens runtime als in code – worden steeds belangrijker. Zodra u uw API-landschap in de praktijk in kaart hebt gebracht, kunt u risico's beoordelen, duplicatie identificeren en betrouwbare governance opbouwen.

Ironisch genoeg kan AI zelf helpen bij dit proces. Het gebruik van AI-modellen om API-kaarten te analyseren en te controleren, helpt bij het ontdekken van anomalieën, risicovolle blootstelling en consolidatiemogelijkheden. AI helpt dus niet bij het bouwen van meer, maar bij het opschonen van wat we al hebben.

2. Het opzetten van organisatiebrede standaardisatie van snelle engineering en tooling

Betere controle over zowel de output als de input in AI-tools draagt ​​aanzienlijk bij aan het behoud van controle over de gegenereerde code. Eenvoudige stappen zoals het afstemmen op de AI-gestuurde IDE's en modellen die binnen een organisatie zijn goedgekeurd, helpen bij de variatie. Dit heeft ook als voordeel dat het de uitrol van nieuwe modellen vereenvoudigt en de kans vergroot dat prompts reproduceerbaar zijn op alle werkstations van engineers.

Nog krachtiger is het om je te richten op de specifieke regels.md Typebestanden die AI-programmeurs als context aan hun agent moeten verstrekken. Hoe complexer de codebase, hoe nuttiger het voor alle engineers is om met dezelfde set regels te werken, zodat de AI-agent context krijgt over hoe hij code kan genereren die het beste werkt met de bestaande structuren.

We gaan de generatieve geest niet terug in de fles stoppen. Maar we kunnen hem wel sturen, de explosieradius beperken en gebruiken om verantwoorde innovatie te stimuleren. Dat werk begint niet met code, maar met duidelijkheid.

Bio: Benji Kalman, VP Engineering en medeoprichter van Rootheeft meer dan tien jaar ervaring in het onderzoeken en ontwikkelen van cybersecurity en DevTools. Benji, een 8200-alumnus die gespecialiseerd was in cyberoperaties, was een van de eerste medewerkers van Snyk, waar hij meer dan vijf jaar werkte als directeur van de Security R&D-groep van Snyk, verantwoordelijk voor het beheer en de ontwikkeling van de kennisbanken op het gebied van beveiliging van het bedrijf.