Programmeren met je stem: code, reviews en commits

„Programmeren met je stem” klinkt meestal als clownerie. De video uit 2017 waarin een ontwikkelaar „open paren if foo equals equals null close paren” schreeuwt, is een meme, geen workflow. Ik dacht zelf ook lang dat dit idee dood was.

Commander Flow heeft mijn standpunt veranderd. Niet omdat er een magische „code-dictee”-modus is bijgekomen. Maar omdat code niet alleen code is. Code is ook commits, tickets, code reviews, documentatie, comments, namen, gesprekken met collega's. En dat alles om de code heen — gaat nu via mijn stem.

Waar spraak het leven van een ontwikkelaar echt verandert

Mijn meest frequente spraakhandeling zijn commit-berichten. Ik zet de cursor in git commit -m "...", druk de toets in, zeg iets als „race condition gefixt in pipeline-cancellation, token correct geannuleerd bij hernieuwd indrukken van de sneltoets”, en in de terminal verschijnt een keurig conventional-commits-bericht — omdat ik die regels één keer met mijn stem heb ingesteld en ze onthouden zijn.

PR-beschrijvingen werken net zo, alleen langer. Ik open een GitHub PR-template, dicteer alsof ik een junior uitleg — wat verandert, waarom, wat we niet aanraken, hoe te testen. Een paar seconden later staat er nette markdown met ## Context, ## Changes, ## Test plan. Vroeger kostte dat zo'n vijf minuten, nu seconden.

Wat voor mij echt is omgeklapt: code-review-comments. Ik was vroeger te lui om uitgebreide reviews te schrijven: te veel tikwerk voor iets dat men leest en weer vergeet. Nu selecteer ik een regel, dicteer mijn gedachte, en krijg binnen een paar seconden een gepolijste review-comment. Mijn reviews zijn flink langer en duidelijk nuttiger geworden, en het team merkt dat.

Aparte vermelding voor documentatie. Het pijnlijkste deel van het vak. Ik dicteer een docstring alsof ik het aan een collega uitleg, en Commander Flow zet het om naar de stijl van XML-doc, TSDoc of markdown — afhankelijk van de taal van het project. Documentatie is geen belasting meer die ik betaal bij de code.

„Ik schrijf geen code met mijn stem. Ik schrijf alles om de code heen met mijn stem. En ik heb beseft dat dat de helft van mijn werk is.”

De code-comments-modus: een aparte favoriet

Daarom zeg ik gewoon hardop „laat het als code-comment" — en Commander Flow:

• Raakt identifiers in Latijns schrift niet aan (variabelennamen, klassennamen)
• Behoudt termen (kubectl, async/await, useEffect, OAuth) in hun originele vorm
• Voegt geen beleefdheidsformules toe (niemand schrijft „geachte lezer” boven een code-comment)
• Werkt correct met beide alfabetten in één comment: // controleer dat Subscription.IsActive vóór BillingService.Refresh

Dat klinkt als een detail. Maar zonder die spraakhint „beschaafden” de eerste alfa-builds mijn technische comment soms tot „laten we controleren of ons businessobject voor abonnementen correct is”.

Het termenwoordenboek — een onderschatte feature

In PolishOptions.Dictionary dump ik mijn eigen termen en afkortingen. Wat er bij mij in staat:

• kubectl, helm, argocd, flux
• IDictionary, IAsyncEnumerable, Span<T>
• ConfigureAwait(false) (volledig, als zinsdeel — zodat de LLM het niet herschrijft)
• Bedrijfsafkortingen, namen van interne services

Daarna stopt de LLM met „verbeteren” van specifieke termen en laat ze precies staan zoals ik ze noem.

Het scenario dat me elke dag overtuigt

10:30, ik in de IDE, daarnaast de team-Slack, daarnaast Linear met een ticket. Ik hou de sneltoets ingedrukt en zeg:

„Retry-logica verplaatst naar een aparte klasse RetryPolicy met exponentiële backoff, tests toegevoegd, controleer voor de merge ook het sequence-diagram in het ticket”

Dat gaat als comment naar Linear. Daarna — Alt+Tab naar Slack, dezelfde sneltoets:

„team, PR opengezet voor review, niet blokkerend maar liefst vandaag”

In Slack-stijl, kleine letters, geen „geachte collega's”. Daarna — terug in de IDE.

Drie handelingen in drie applicaties, allemaal met mijn stem, geen vinger op het toetsenbord.

Waar ik tegen aanliep

Punctuatie in code die tussen het dicteren door valt. Als ik dicteer „deze functie geeft Task<bool> terug”, denkt de LLM soms dat Task<bool> HTML is en wil hij het escapen. Opgelost door de term in het woordenboek te zetten, maar in het begin verbaasde het me.

Sneltoetsconflicten met de IDE. Mijn IDE heeft eigen sneltoetsen. De Commander Flow-sneltoets heb ik een paar keer moeten herbinden om botsingen te vermijden. Nu staat hij op Caps Lock — de handigste en minst gebruikte toets. Klein ongemak, opgelost in één klik.

De zwaarste modi „denken” soms iets trager in de IDE. Voor een e-mail vallen extra milliseconden niet op. Voor een code-comment „nu en hier” wel. Op mijn werklaptop staat de middelste modus, op de desktop met discrete videokaart blijft de zwaarste actief. Latency weg.

Wat ik geleerd heb over geluid als programmeerinterface

Spraak vervangt het toetsenbord in een IDE niet. Hij vult het aan daar waar het toetsenbord het slechtste werktuig was. Typen van if (x != null && y != null) — toetsenbord. Uitleggen waarom die check er staat — stem.

Tussen die twee taken zit een afgrond aan cognitieve belasting, en ze zijn niet in gelijke mate „op te lossen door te typen”. Ik forceer mezelf niet langer om het tweede type taak te typen. Het is lichter geworden.

Wat ik uit deze verhouding heb meegenomen

Programmeren met je stem is geen „code dicteren”. Het is een verschuiving in wat je precies met je stem doet. Logica met de hand, alles menselijks om de logica heen met de stem.

In tien jaar in dit vak heb ik geen comfortabelere verhouding gevonden.