AI controleert je code. De specificaties blijven jouw werk.

Software controleren gaat verder dan code genereren

Bij AI en softwareontwikkeling gaat het al snel over code maken. Maar code controleren is minstens zo interessant. DeepMind introduceert met AlphaProof Code een toepassing voor softwareverificatie. Daarbij wordt op wiskundige wijze gecontroleerd of code overeenkomt met de specificaties.

Dat is een concretere vraag dan: ziet deze code er goed uit? Je wilt niet alleen een overtuigend antwoord. Je wilt weten of de beschreven werking en de daadwerkelijke code bij elkaar passen.

Voor ondernemers en IT-managers is vooral dat onderscheid relevant. De waarde zit niet uitsluitend in sneller ontwikkelen. Ook het controleren van wat er gebouwd is, kan door AI veranderen. Niet alleen meer software produceren, maar beter kunnen onderbouwen dat die software aan de vastgelegde eisen voldoet.

Wat laat de controle van Signal zien?

Een concreet voorbeeld is de controle van Signal. Die toepassing staat bekend om sterke encryptie. Toch werden bij het onderzoeken van de code beveiligingsproblemen gevonden. Dat maakt deze toepassing van AI interessant: ook software die bekendstaat om beveiliging kan nog fouten bevatten.

Om het systeem te testen, werden bovendien twee oude lekken teruggezet. Die werden door het systeem opgemerkt. Het bleef daarmee niet bij een algemene uitspraak over de kwaliteit van de code. Bekende problemen werden opnieuw herkend.

Er zijn hier twee resultaten die je uit elkaar moet houden:

• Problemen herkennen: het systeem signaleerde de teruggeplaatste lekken.
• Overeenstemming controleren: de code werd beoordeeld op aansluiting bij de specificaties.

Dat zijn concrete aanknopingspunten voor softwarecontrole. Ze maken ook duidelijk waarom de vraag achter de techniek belangrijk blijft. Niet alleen: kan AI onze code controleren? Maar: wat willen we met die controle precies vaststellen?

Een correcte implementatie begint bij correcte afspraken

De conclusie dat code overeenkomt met specificaties klinkt geruststellend. Toch zit daar een belangrijke voorwaarde aan: die specificaties moeten zelf op orde zijn. Anders heb je vastgesteld dat de software doet wat is beschreven, terwijl nog niet vaststaat dat dit ook is wat je organisatie nodig heeft.

Vergelijk het met bouwen volgens een bouwtekening. Precies volgens de tekening bouwen zegt nog niet dat de tekening jouw wensen goed weergeeft. Bij software is dat onderscheid net zo belangrijk.

Daarom verdient het vastleggen van de gewenste werking aandacht, juist wanneer AI meer controlewerk kan uitvoeren. Welke werking is afgesproken? Wat moet de controle aantonen? En is dat ook de vraag waarop je als organisatie antwoord nodig hebt?

Een geslaagde technische controle is dus geen reden om die vragen over te slaan. Het onderscheid tussen een technische uitkomst en de bredere toepassing komt ook terug bij softwaremodernisering met AI.

Wat betekent dit voor jouw organisatie?

Kijk bij AI voor softwarekwaliteit niet uitsluitend naar snelheid. Er zijn ontwikkelingen die juist daarop inzetten. Zo beschrijft TCS een testorchestrator met Amazon Bedrock. Volgens de eigen informatie nam de testinspanning met 88% af en gingen regressietesten van weken naar uren. Die resultaten zijn niet onafhankelijk geverifieerd.

Houd zulke claims daarom apart van de vraag wat een controle inhoudelijk bewijst. Minder testinspanning en aantoonbare overeenstemming met specificaties zijn verschillende uitkomsten.

Wil je hiermee aan de slag, begin dan bij drie vragen:

• Doel: wil je testwerk versnellen, fouten vinden of controleren of code aan specificaties voldoet?
• Afspraken: zijn de specificaties waarop je wilt controleren voldoende op orde?
• Onderbouwing: gaat het om een concreet aangetoond resultaat of om een nog niet onafhankelijk geverifieerde claim?

Zo beoordeel je een toepassing op het probleem dat je wilt oplossen. Niet op het indrukwekkendste percentage.