Ik automatiseer en stroomlijn mijn leven graag, en ik doe dat met name met software die ik hier zelf voor schrijf. Zo heb ik bijvoorbeeld scripts die gedurende de dag mijn to-do-lijsten aanvullen met taken die op dat moment gedaan moeten worden, zodat ik niet vergeet om mijn tanden te poetsen, programma's die de data van mijn energieleverancier ophalen, zodat ik optimaal gebruikmaak van de momenten waarop de energie goedkoop is, en natuurlijk de automatisering rondom mijn loopband.
Aan de lopende band automatiseren
Mijn loopband is een vrij simpel model, een onder-het-bureau-type, zonder een handrail of een bedieningspaneel. Geen knoppen erop, alleen een afstandsbediening waarmee hij aan/uit/sneller/langzamer kan. Ik loop vrij vaak op mijn loopband, en ik wil dan ook wel graag weten hoeveel en hoelang ik er dan precies op loop. In het begin noteerde ik het dus ook na iedere sessie. Maar: ik ben erg lui, dus ik werd dat al vrij snel zat. Dat moet gewoon automatisch gaan!
Zou het mogelijk zijn om deze data eruit te halen? Ik kon in de documentatie en op de website vrijwel niets vinden. Maar, ik merkte wel dat ik via Bluetooth met de loopband kon verbinden. Dus ik vroeg mij af: zou het mogelijk zijn om via Bluetooth te verbinden en zo deze data op te vragen? Tijd om te gaan reverse-engineeren 🔧.
Aan de lopende band reverse-engineeren
Wat is reverse-engineeren? Dit is het analyseren van een bestaand systeem, in situaties waarin je niet de beschikking hebt over de broncode of documentatie, om te begrijpen hoe het werkt.
Via mijn Linux-laptop maakte ik verbinding met de loopband, om eens te kijken wat voor signaal er verstuurd werd. Daar kwam het volgende uit:
45452c63302c7366302c737432302c6d70362e30
2c6d7331352c6d69312e302c63613130302c6469
73332e33342c6830302c73302c70342e352c7434
362e32372c3132392c4646
De loopband stuurt iedere seconde zo'n blok aan data uit via Bluetooth. Na wat puzzelen kwam ik erachter dat ik de data gewoon moest interpreteren als UTF-8. Toen kwam er dit uit:
"EE,c0,sf0,st20,mp6.0,ms15,mi1.0,ca2,dis0.05,h00,s0,p3.0,t2.02,216,FF"
Kijk, dat is al een stuk duidelijker!
Aan de lopende band interpreteren
"EE,c0,sf0,st20,mp6.0,ms15,mi1.0,ca2,dis0.05,h00,s0,p3.0,t2.02,216,FF"
Op het eerste gezicht lijkt dit fragment misschien volstrekte nonsens, maar via analyse en
experimenteren zijn een hoop van de waardes snel te achterhalen. Bijvoorbeeld dis0.05 betekende
waarschijnlijk distance, en ik zag dat deze overeenkwam met de waarde op het scherm op mijn loopband.
Door mijn loopband van snelheid te laten veranderen, ontdekte ik ook welke waardes de snelheid
weergaven, en bijvoorbeeld de tijd. Vrij snel had ik alle belangrijke waardes ontrafeld.
Zoals gewoonlijk met software development kwamen er nog allerlei kleine details bij kijken. Heel af en toe verliest mijn laptop bijvoorbeeld de verbinding, en wordt het signaal halverwege afgebroken en weer opgepakt. De code moest dus robuuster gemaakt worden om hiermee om te gaan. Toen dit eenmaal werkte, was het daarna nog gewoon een kwestie van deze verzamelde data verwerken en doorsturen naar een relevante spreadsheet. En zo heb ik dus het verzamelen van mijn loopbandstatistieken volledig geautomatiseerd.
Het enige wat ik niet heb geautomatiseerd is het daadwerkelijk lopen op de loopband. Dat moet ik helaas nog wel zelf doen.
Aan de lopende band baragouineren
Ik weet niet of het een (indirect) gevolg is van mijn software, maar heel af en toe, uit het niets, wanneer hij ongebruikt naast mijn bureau ligt, begint mijn loopband Frans te praten.
In het begin dacht ik nog dat ik het mezelf inbeeldde. Ik had dan mijn koptelefoon op, en dacht een paar vage woorden te horen, maar als ik ging luisteren was het weer weg. En dan, bijvoorbeeld een half uur later, kwam het weer even voorbij. Vaak alleen tijdens bepaalde uren in de avond. Het duurde dus ook wel enkele dagen voordat ik de bron van het geluid had vastgesteld. Was het de TV? Nee. Was het een van mijn laptops? Nee. Misschien een van mijn monitors met ingebouwde speaker? Nee. Het was mijn loopband!
Ik weet nog steeds niet wat het is. Af en toe komt het nog voor, soms ook langere fragmenten van Frans gesproken tekst. Misschien maakt iemand per ongeluk sporadisch verbinding ermee en stuurt deze geluiden? Op avonden waarop het vaker gebeurt, zet ik meestal de loopband maar gewoon uit. Want Frans is wel het laatste wat ik 's avonds in mijn huis wil horen!
AI-explosie aan software
De meeste mensen zitten niet in mijn situatie, waarin ze alles kunnen automatiseren wat ze willen automatiseren. Er is immers altijd een kennisbarrière - net als dat ik niet mijn auto kan onderhouden, en daarvoor naar de monteur moet.
Maar met de opkomst van LLM's/AI is deze situatie aan het veranderen. Het is nu mogelijk om jezelf met behulp van een LLM stapsgewijs door het maken van software heen te leiden. Of eventueel kun je zelfs (beperkt en selectief, zou mijn advies zijn) de software vibe-coden.
De wereld is op dit vlak in hoog tempo aan het veranderen. Het is nu eenvoudiger en toegankelijker dan ooit om, met hulp van AI, je eigen maatwerk-software te schrijven. In theorie is er dus een mogelijke toekomst waarin iedereen (die dat wil), net als ik, tientallen, honderden of zelfs duizenden losse maatwerkprogramma's heeft, waarmee ze hun leven automatiseren. Heeft iedereen straks, net als ik, zijn loopband geautomatiseerd?
Is zo'n toekomst mogelijk?
In ons vorige artikel schreef ik over mijn eerste vibe-coded applicatie. Ik noemde toen al enkele knelpunten waar ik tegenaan liep, en toch mijn eigen kennis (als software developer) moest inzetten om de AI uit de knoop te halen. Maar, wat als ik dit niet had kunnen doen?
Bovendien, stel dat het wel lukt om de applicatie af te krijgen: applicaties hebben onderhoud nodig. Besturingssystemen vernieuwen zichzelf, situaties veranderen: er treedt bit-rot op. Ook hierdoor blijft het nodig om de code steeds weer aan te moeten passen of uit te breiden.
De recente AI-modellen zijn heel indrukwekkend, maar zijn nog niet overal toe in staat, en maken vooral op architectuurvlak vaak nog onhandige keuzes, waarbij ze steeds meer complexiteit toevoegen aan de code. Dit blijft doorgaan, totdat de code een bepaalde complexiteitsdrempel overschrijdt, en de LLM's niet meer in staat lijken te zijn om hier nog verder aan te werken. Het is momenteel nog onvermijdelijk: zonder sturing lopen de modellen op een bepaald punt gewoon vast.
Als je op dat punt bent beland, wat kan je dan nog doen? Je kunt niet meer verder. Dan is waarschijnlijk je enige optie om een programmeur te zoeken, in de hoop dat hij nog wel dit gedrocht van een codebase weet te ontknopen. Ik denk dan weer aan de monteur waar ik heen moet voor het onderhoud van mijn auto. Hoe zou een vergelijkbare situatie eruit zien, als ik mijn eigen auto ge-vibe-bouwd zou hebben?
Zou jij erin durven te rijden?
Monteurmoment mijden
Willen we dat monteurmoment mijden? Ik denk dat er dan twee dingen zijn die we kunnen doen.
1. Software klein houden Hou je maatwerk-software zo klein mogelijk. Bij kleinere codebases is de noodzaak voor een goede architectuur veel kleiner, omdat de complexiteit veel lager ligt. Toch blijft software meestal doorgroeien, hetzij door noodzakelijk onderhoud, of omdat je in de loop der tijd features toe blijft voegen. De door AI veroorzaakte complexiteit zal langzaam toe blijven nemen. En dat moment van die complexiteitsdrempel zal een keer aanbreken. In dat geval komen we bij punt 2.
2. Applicatie opnieuw bouwen Tegen de tijd dat je AI-model begint vast te lopen in je codebase, is er een grote kans dat er inmiddels nieuwere modellen beschikbaar zijn gekomen. Of wellicht werk je daar al mee, maar is een groot deel van de oorspronkelijke codebase geschreven door een ouder model. De nieuwere modellen maken waarschijnlijk op architectureel niveau betere keuzes. Er zit dus maar een ding op: laat het nieuwere model de applicatie in zijn geheel opnieuw maken.
Waarom werkt dit?
- De software is al vrij klein; herbouwen is hopelijk niet veel werk.
- Er is een bestaand voorbeeld: vraag de LLM gerust om hier specs uit te extraheren (maar gebruik de code daarna niet als voorbeeld)!
- Nieuwe modellen maken betere keuzes, en werken bovendien op basis van betere specificaties. Hopelijk eindig je dus met een sterkere basis en betere onderhoudbare applicatie.
Conclusie / toekomst
Deze aanpak is een gok, waarbij je vertrouwt op de voortdurende verbetering van LLM-modellen.
Maar als AI-modellen steeds sneller en beter worden, komt er mogelijk zelfs een moment dat de stap van het schrijven van applicaties gewoon overgeslagen kan worden. LLM's schrijven en voeren nu al dynamisch code uit om bepaalde vraagstukken te beantwoorden. Dus misschien kan ik uiteindelijk wel gewoon tegen mijn LLM zeggen: maak maar verbinding met mijn loopband, en verwerk de stortvloed van berichten, en zet ze in mijn spreadsheet.
Als deze trend van verbetering in AI-modellen doorzet, komt er misschien wel een moment dat in ieder apparaat een LLM zit. Dan zouden alle apparaten gewoon direct met elkaar kunnen praten; de LLM van mijn laptop zou dan dus kunnen communiceren met de LLM van mijn loopband.
Ik vraag mij dan af... zouden ze dat dan ook in het Frans doen?
