Android Developer in 2031: loont het nog met de opkomst van AI?

Opinie — 25 augustus 2026

Laat ik meteen met de deur in huis vallen: ja, het loont nog steeds. Sterker nog, wij denken dat de Android Developer die vandaag zijn vak serieus neemt in 2031 méér verdient en méér invloed heeft dan nu — niet ondanks AI, maar dankzij AI. Dat is een impopulair standpunt in een tijd waarin elke tweede LinkedIn-post het einde van het programmeursvak aankondigt. Toch houden we eraan vast, en hieronder leggen we uit waarom.

Het doembeeld dat overal rondzingt

Het verhaal gaat ongeveer zo. AI-assistenten schrijven inmiddels moeiteloos een complete Jetpack Compose-schermflow, ze genereren unit tests, ze refactoren verouderde Java naar Kotlin en ze leggen je uit waarom je LaunchedEffect verkeerd gebruikt. Als een model in seconden doet waar een junior een middag over deed, waarom zou een bedrijf dan nog juniors aannemen? En als er geen juniors instromen, verschrompelt over vijf jaar de hele beroepsgroep.

De eerste helft van dat verhaal klopt aantoonbaar. Wie in 2026 nog handmatig boilerplate tikt, doet zichzelf tekort. De tweede helft — de conclusie — is een denkfout. Die berust op de aanname dat een Android Developer vooral iemand is die code produceert. Dat is al minstens tien jaar niet meer waar, en de laatste twee jaar is het nog veel minder waar geworden.

Argument 1: code schrijven was nooit het schaarse deel

Vraag een willekeurige ervaren Android-ontwikkelaar waar zijn week aan opging en je krijgt zelden "typen" als antwoord. Je krijgt: uitzoeken waarom een crash alleen op één specifieke fabrikantenskin optreedt. Onderhandelen met de backend over een API die niet past bij hoe het scherm werkt. Uitleggen aan een product owner waarom die ene feature op Android fundamenteel anders moet dan op iOS. Een release door de Play Console-review loodsen nadat het beleid weer is aangescherpt.

Dat zijn allemaal taken waarin de moeilijkheid niet in de syntax zit, maar in het oordeel. AI kan je een hypothese aanreiken over die crash, maar het model heeft het toestel van die klant niet in handen, kent de historie van jullie codebase niet in de diepte en draagt geen verantwoordelijkheid als de fix een miljoen gebruikers raakt. Naarmate het produceren van code goedkoper wordt, verschuift de waarde naar precies die dingen die niet geautomatiseerd worden: contextkennis, verantwoordelijkheid en smaak.

Argument 2: meer code betekent meer onderhoud

Er zit een wrange logica in de AI-hype die vaak wordt overgeslagen. Als het schrijven van software goedkoper wordt, wordt er méér software geschreven. Bedrijven die vroeger één app hadden, bouwen er nu drie. Features die niet door de businesscase kwamen, komen er nu wel doorheen. Interne tools die jarenlang op een Excel-bestand draaiden, krijgen ineens een eigen Android-client voor de buitendienst.

Al die software moet draaien, veilig blijven, migreren naar nieuwe API-levels en overleven wanneer Google weer eens een gedragsverandering doorvoert in de volgende Android-versie. Elke regel gegenereerde code is een regel die over drie jaar iemand moet begrijpen. Onze inschatting — nadrukkelijk een vuistregel, geen meting — is dat het aandeel van onderhoud en migratie in het werk van een gemiddelde Android-ontwikkelaar de komende jaren eerder toe- dan afneemt. Dat is geen leuk werk om te horen, maar het is wel werk waar bedrijven graag voor betalen.

Argument 3: de Nederlandse markt is structureel krap, niet cyclisch

Nederland heeft een specifieke situatie. We hebben een dichte concentratie van bedrijven waarvoor een mobiele app geen bijzaak is maar het primaire kanaal: banken, verzekeraars, vervoerders, retailers, zorgplatforms, energieleveranciers. Die apps moeten voldoen aan Europese regelgeving rond toegankelijkheid, privacy en digitale weerbaarheid. Ze verwerken betalingen en identiteitsgegevens. Ze worden getoetst door auditors.

Voor dat soort werk is "de AI heeft het geschreven" geen aanvaardbare verantwoording. Er moet een mens zijn die begrijpt wat er gebeurt met persoonsgegevens, die kan uitleggen waarom een bepaalde permissie wordt gevraagd en die aansprakelijk gehouden kan worden. Die eis groeit eerder dan dat hij verdwijnt. Wij verwachten dan ook dat de vraag naar ontwikkelaars met aantoonbare kennis van security, privacy en toegankelijkheid in 2031 hoger ligt dan vandaag — en dat de salarissen aan de bovenkant van de markt meebewegen, terwijl de onderkant (puur uitvoerend werk zonder domeinkennis) inderdaad onder druk komt te staan.

Het sterkste tegenargument: de juniorval

Nu het argument dat we wél serieus nemen, en dat we in discussies te vaak weggewuifd zien worden.

Als AI het werk overneemt dat juniors traditioneel deden — de eenvoudige schermen, de tests, het opschonen — dan verdwijnt de ladder waarlangs mensen senior worden. Je wordt geen goede ontwikkelaar door boeken te lezen; je wordt het door duizenden uren te maken, te falen en gecorrigeerd te worden. Als die uren wegvallen, kweken we over vijf jaar een generatie die uitstekend prompts schrijft en volstrekt niet kan beoordelen of het antwoord klopt. Dat is een reëel risico en het is al zichtbaar in vacatureteksten waarin "medior" tegenwoordig begint waar vroeger "senior" begon.

Wij weerleggen dat als volgt. Ten eerste is dit geen nieuw fenomeen maar een terugkerend patroon. Toen frameworks het handmatig tekenen van views overbodig maakten, klonk hetzelfde bezwaar. Toen garbage collection het handmatig geheugenbeheer wegnam, ook. Telkens verschoof het instapniveau omhoog en werd de leerweg anders — niet onmogelijk.

Ten tweede, en belangrijker: de leerweg is nu sneller dan ooit, mits je hem bewust bewandelt. Een junior met een AI-assistent kan in een middag vijf verschillende architectuurpatronen naast elkaar zien, uitgelegd krijgen waarom de een in dit geval beter past, en meteen zien wat er misgaat als je het anders doet. Dat kostte vroeger maanden en een geduldige mentor. Het probleem is niet dat de leermogelijkheid verdwijnt, het probleem is dat de verleiding om te accepteren zonder te begrijpen enorm is.

En dat maakt het een keuzeprobleem, geen structureel probleem. Wie de gewoonte aanleert om elk gegenereerd stuk code te lezen, te bevragen en desnoods handmatig na te bouwen tot het écht zit, bouwt sneller expertise op dan zijn voorganger uit 2018. Wie dat niet doet, wordt inderdaad overbodig. Het verschil zit niet in de technologie, maar in de discipline.

Waar wij op zouden inzetten tot 2031

Concreet, als je vandaag in dit vak zit of erin wilt stappen:

• Ga de diepte in op het platform zelf. Achtergrondwerk, batterijgedrag, permissiemodellen, fabrikant-specifieke eigenaardigheden. Dit is slecht gedocumenteerde, sterk contextafhankelijke kennis — precies waar generieke modellen het zwakst zijn.
• Word goed in architectuur en review. Kunnen beoordelen of een oplossing over drie jaar nog houdbaar is, is een menselijke vaardigheid die zwaarder gaat wegen naarmate er meer code wordt geproduceerd.
• Leer het domein van je werkgever. Een ontwikkelaar die begrijpt hoe hypotheken, OV-tarieven of medicatiebewaking werken, is niet vervangbaar door iemand die alleen Kotlin kent.
• Neem toegankelijkheid en privacy serieus. Dit wordt in Europa steeds harder afgedwongen en is aantoonbaar schaars in de markt.
• Gebruik AI agressief, maar controleer alles. Wie het gereedschap negeert, is over vijf jaar te traag. Wie het blind vertrouwt, is over vijf jaar onbetrouwbaar.

Conclusie

De Android Developer verdwijnt niet in 2031. Wat verdwijnt, is de ontwikkelaar die zijn waarde ontleende aan het kunnen uitschrijven van wat een ander bedacht heeft. Die rol was al kwetsbaar en is nu grotendeels weg. Wat overblijft — en groeit — is de rol van iemand die verantwoordelijkheid draagt voor een product dat op miljoenen toestellen draait, die begrijpt waarom iets werkt, en die kan uitleggen waarom het anders moet.

Dat is geen bedreigde functie. Dat is een promotie, verpakt als een crisis.