Er is al enige tijd een trend gaande, waarbij LLM-providers een CLI-applicatie uitbrengen, waarin ze hun modellen eenvoudig beschikbaar maken. Een aantal weken geleden was ik aan het experimenteren met het nieuwe Qwen3-Coder-model, in de qwen-codeapplicatie (met een slechte eerste impressie - hier komt later nog een, hopelijk kort, artikel over). Maar een aantal weken geleden kondigde Augment Code ook hun CLI-tool aan. Weer eentje op de grote lijst om te gaan proberen.
Maar dit leidde tot een discussie tussen mij en mijn collega. Hij vond dit een vreemde keuze - waarom een CLI voor zoiets? Ze hebben immers al prachtige IDE-integraties, waarom niet daar op focussen?
En hij heeft een goed punt. In dit blog artikel doorloop ik enkele van mijn gedachten hierover.
Maar wat is een CLI eigenlijk?
Een CLI is een Command Line Interface. Een CLI is dus een applicatie die je draait vanaf de command-line. Dan is mogelijk je volgende vraag: En wat is de 'command-line' dan?
De command-line was de eerste 'manier' om een computer te besturen, ontstaan in de jaren '60. Het is een text-only interface waarbij de gebruiker commando's kan typen, en direct feedback krijgt, ook in de vorm van pure tekst. We noemen deze interface ook wel de terminal.
Ja, dit is hoe er vroeger met computers gewerkt werd.
Grafische user interfaces kwamen later in de jaren '80 beschikbaar, populair gemaakt door Apple en Microsoft. Qua besturing is het grote verschil dat je bij een CLI alleen maar je toetsenbord gebruikt, en bij GUI-applicaties voornamelijk de muis.
Computerbesturing ging van focus op het toetsenbord naar focus op de muis.
Mijn eigen eerste aanraking met de command-line was met DOS, maar dit was van korte duur, want we schakelden binnen enkele jaren al snel over op het destijds gloednieuwe Windows 95 in mijn huishouden. Toch bleef de terminal mij altijd fascineren. En dat doet het nog steeds: ik werk als developer nog steeds dagelijks met de CLI.
Waarom nog steeds dagelijks met de CLI werken
De introductie van GUI's resulteerde niet in het verdwijnen van de CLI. Een GUI is niet per se 'beter' dan een CLI, maar gewoon 'anders'. Beide manieren van het besturen van de computer bieden hun eigen voordelen en mogelijkheden, en vaak sluit de een de ander ook niet uit.
Vaak kun je dus zowel via de CLI als via een GUI hetzelfde resultaat bereiken. Dit wil ik hieronder illustreren door enkele bekende CLI-commando's door te lopen. De eerste regel (die begint met $), is het commando dat je typt. De regels daaronder zijn de output van dat commando.
Wijzigen van de directory of folder: cd
Ga naar een bepaalde directory (folder) in je computer. Hiervoor gebruiken we het cd commando. cd staat voor change directory. Wil ik bijvoorbeeld naar mijn Downloads-directory, kan ik mijn terminal openen en typen: cd /home/jeroen/Downloads.
Inhoud van een (tekst)bestand lezen: cat
Met het 🐈 cat commando kan je de inhoud van een bestand uitlezen. Als ik bijvoorbeeld in mijn huidige directory het bestand todolijst.txt heb staan, kan ik die op de volgende manier uitlezen:
- tanden poetsen - blogartikel schrijven - to-do-lijst reorganiseren
Schijfruimte bepalen: df en du
Hoeveel ruimte heb ik nog beschikbaar op mijn computer? Ik typ in de terminal het commando df (dit betekent disk free).
Filesystem Size Used Avail Use% Mounted on C: 1952734204 282730396 1670003808 15% / D: 7814008828 2340304612 5473704216 30% /d E: 7814008828 428296 7813580532 1% /e F: 3907000316 234652276 3672348040 7% /f G: 3907000316 793647468 3113352848 21% /g Q: 308003680 112425424 195578256 37% /q Z: 308003680 112425424 195578256 37% /z
Maar, dit is eigenlijk best onduidelijk, want we tonen hier de waardes in kilobytes. Gelukkig is het ook mogelijk om commando's te modificeren door extra opties of 'arguments' mee te geven. Ik kan bijvoorbeeld het volgende schrijven: df --human-readable.
Filesystem Size Used Avail Use% Mounted on C: 1.9T 270G 1.6T 15% / D: 7.3T 2.2T 5.1T 30% /d E: 7.3T 419M 7.3T 1% /e F: 3.7T 224G 3.5T 7% /f G: 3.7T 757G 2.9T 21% /g Q: 294G 108G 187G 37% /q Z: 294G 108G 187G 37% /z
Als ik wil weten hoeveel schijfruimte een bepaalde directory in beslag neemt, kan ik het 'disk usage'-commando gebruiken: du. Net als met het df-commando wil ik gelijk meegeven dat het 'human readable' moet zijn, maar dit keer gebruik ik de afgekorte versie hiervan (-h i.p.v. --human-readable), en ik wil graag de samenvatting van de hele directory, dus geef ik ook -s mee (wat weer staat voor summarize).
70G Downloads
Zoeken naar patronen in tekst: grep
Met het grep-commando kun je zoeken binnen teksten of tekstbestanden. Als ik bijvoorbeeld wil weten of 'poetsen' voorkomt in mijn todo-lijstje, kan ik het volgende doen:
- tanden poetsen
En wat heb je daar dan aan?
Misschien denk je nu: Deze vier bovenstaande acties kunnen natuurlijk allemaal ook via de GUI. Wat heb ik eraan om dit via de terminal te doen? Misschien is het met de CLI sneller uit te voeren, omdat de meeste mensen sneller kunnen typen dan de muis gebruiken - maar zelfs dat is discutabel.
Maar in tegenstelling tot een GUI, is het bij de CLI mogelijk om meerdere commando's op één regel te zetten, of zelfs om commando's op verschillende manieren te combineren.
Ik kan bijvoorbeeld in één regel de volgende vier commando's in één keer uit laten voeren: Navigeer naar directory home, navigeer vanuit daar naar directory jeroen, en vanuit daar naar directory Downloads. Toon daar de inhoud van het bestand 'todolijst.txt'.
cd home; cd jeroen; cd Downloads; cat todolijst.txt
Nu hebben we dus al een situatie waar je met de GUI vrij veel moet klikken, maar vanuit de terminal met één regel zou kunnen uitvoeren. Mocht je deze actie vrij vaak willen uitvoeren, zou je bijvoorbeeld deze regel ergens kunnen bewaren. Op dat moment heb je dus al je eerste stap gezet richting het 'automatiseren' van een repetitieve taak.
Piping en output redirectie
Het is mogelijk om de 'resultaten' van een uitgevoerd commando door te sturen naar andere commando's. Stel dat ik bijvoorbeeld iedere dag wil vastleggen hoeveel ruimte in gebruik is op één van mijn specifieke harde schijven. Onderstaande regel vraagt de beschikbare schijfruimte op, filtert de regel voor schijf 'D' en voegt dit toe aan het einde van een tekstbestand.
De manier waarop CLI-applicaties met elkaar kunnen samenwerken (composability) is wat de terminal zo krachtig maakt. Ik stuur hier het resultaat van de output van het 'schijfruimte' commando moeiteloos door naar een applicatie die vervolgens deze data filtert, om het vervolgens weer door te sturen naar een bestand.
Dit vind ik zelf een mooi voorbeeld van een kantelpunt waarop een taak uitvoeren vanuit de terminal duidelijk de betere optie is dan een GUI. Ga maar na hoeveel verschillende acties je moet uitvoeren om dit voor elkaar te krijgen in een normale GUI-omgeving.
En dat is al helemaal het geval wanneer we ook het automatiseren ervan in overweging nemen. Want tenzij je applicatie toevallig precies deze specifieke feature biedt, is de kans vrij klein dat je dit eenvoudig kunt automatiseren in een GUI-omgeving; terwijl daarentegen iedere command-line regel heel eenvoudig te automatiseren valt. De terminal biedt namelijk de 'crontab', waarin je eenvoudig kunt specificeren op welke momenten je automatisch een taak wilt laten uitvoeren (zolang je computer aan staat - als je computer uit staat op het ingestelde tijdstip biedt de standaard crontab helaas geen mechanisme om een gemiste taak alsnog uit te voeren).
Bovenstaande is natuurlijk nog maar een simpel voorbeeld. Waar vaak de automatiseringsmogelijkheden van GUI's eindigen, is waar de terminal pas echt begint. Je kunt hier alle kanten mee op, en eindigen met veel geavanceerdere of complere taken. Je zou bijvoorbeeld alerts kunnen sturen wanneer je schijf te vol dreigt te worden, of automatisch ruimte vrij laten maken, of een plaatje van een koe tonen die waarschuwt dat je schijfruimte vol is.
______________________________
< Je hardeschijf is bijna vol! >
------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||Dat is toch iets wat iedereen wil?
Servers
Wij beheren (en besturen) bijna al onze servers via de terminal. Omdat een terminal puur uit tekst bestaat, is de data die verstuurd en ontvangen moet worden erg klein. De meeste van onze servers hebben niet eens een visuele omgeving geïnstalleerd staan.
Terminal editors
Een minderheid van de programmeurs, vooral die van de oude stempel, werken zelfs met editors die puur binnen de terminal draaien. De bekendste terminal editors zijn emacs en (neo)vim. Ik moet bekennen dat ik vooral regelmatig nano gebruik. Deze editors gaan dusdanig diep dat zelfs een volledig toegewijde blogserie niet voldoende voor zou zijn, laat staan een enkele paragraaf in een blogartikel. Meer dan het benoemen van het fenomeen doen we nu dus ook niet.
Dus waarom al die AI CLI-tools?
Mijn collega had natuurlijk wel een punt over de voordelen van de IDE-omgeving; want in een IDE (of IDE-integratie) heb je bijvoorbeeld de beschikking tot het eenvoudig kunnen inzien van historische gesprekken, rich text, visualisaties, en veel meer.
Maar waarom investeren al deze grote AI-providers dan zo veel in de CLI-tools? De meest geciteerde reden lijkt te zijn dat developers toch al in hun terminal leven. Ik vraag me af in hoeverre dat waar is - want zoals inmiddels wel duidelijk is ben ik een grote fan van de terminal, maar toch 'leef' ik met name in mijn (JetBrains) IDE. Net zoals dat de meeste developers dat doen. En als we kijken naar enquetes uit 2025 over IDE gebruik, werkt minder dan 20% van de developers in terminal IDE's zoals de hierboven genoemde (neo)vim en emacs. Dat betekent dus dat het merendeel in de (GUI) IDE's werkt. Is het dan niet logischer om daar een integratie voor te bouwen?
Vanuit het perspectief van de grote AI-providers begrijp ik het wel - want het is een stuk 'eenvoudiger' om een CLI-applicatie te bouwen, dan om twee IDE-integraties, vaak in de vorm van een plugin, te maken voor Visual Studio Code en IntelliJ IDEA.
Niet alleen is het behoorlijk veel werk en lastig om een goede IDE-integratie te maken, maar je loopt ook nog aan tegen de limitaties die je hebt bij het maken van een plugin. Sommige dingen zijn gewoon niet mogelijk met een plugin. En om het nog ingewikkelder te maken: de mate van deze limitaties verschilt ook nog onderling tussen de VSCode en IntelliJ - dit zagen we vorig jaar ook terug in de capaciteiten van bijvoorbeeld Copilot. De VSCode-plugin was een stuk krachtiger dan de IntelliJ-plugin.
Deze complexiteiten, limitaties en de noodzaak om twee verschillende codebases te onderhouden is de reden waarom veel partijen zoals Cursor, Windsurf of bijvoorbeeld de recente Kiro (van AWS) een fork maken van VSCode en hun product als een gehele IDE leveren. En een terminal application maken is dan nog een stap eenvoudiger. Wij bij Webenable bouwen zelf ook regelmatig interne terminal-applicaties voor onze verschillende tools.
Dus de keuze voor een CLI-applicatie is best logisch, ondanks dat (naar mijn mening) de developer eerder leeft in zijn IDE dan de terminal. Maar, de partijen die wél integraties hebben met een IDE, of zelfs zelf een IDE hebben gebouwd, kunnen zich dus onderscheiden met deze integratie, omdat dit (wederom, naar mijn mening) wel daadwerkelijk de plek is waar de developers leven. Maar, ondanks dat, komen deze partijen dan alsnog met een CLI-applicatie. Waarom is dat?
Reden 1. Claustrofobisch
Dit is een persoonlijke observatie, waar ik dus zelf last van heb. Veel van de AI-plugins in mijn IDE geven mij vaak een bijna claustrofobisch gevoel, omdat het weer een extra venster is dat open moet staan, waardoor er minder plek over blijft voor de code. Zie bijvoorbeeld het screenshot hieronder. Mijn code is hier al breder dan de ruimte die ik nog over had. Eigenlijk eindig ik constant in situaties waarin al mijn vensters een worst-case compromis hebben, waarin ze allemaal net iets te klein aanvoelen.
En zodra je op een changed-file klikt halveert die ruimte in je codevenster nogmaals! Dus ik ben voortdurend ruimte aan het maken, door vensters groter en kleiner te maken. En om die reden kan ik mij best voorstellen dat ik ook vaker in de CLI zal werken, zodra ze dit beschikbaar maken. Puur omdat het dan zijn eigen application-window heeft.
Het middelste stuk is alle ruimte die ik nog voor mijn code heb. En zodra ik op een gewijzigd bestand klik, halveert dit nog een keer!
Reden 2: Automatisering en integratie met andere tools
Hier komen we weer terug op de grote voordelen van het gebruiken van de CLI - alles werkt goed met elkaar samen. Op het moment dat een CLI-applicatie 'bestaat', kan deze geïntegreerd worden in bestaande of nieuwe command line scripts, en wordt het opeens stuk eenvoudiger om automatiseringen te bouwen.
Ik zou bijvoorbeeld, zoals ik ook in mijn bovenstaande voorbeeld al liet zien, iedere dag automatisch de beschikbare ruimte van mijn harde schijf op kunnen halen. En in plaats van in een bestand te plaatsen, zou ik het naar de AI kunnen sturen! Het haakt dus perfect in op je bestaande flexibele ecosysteem van tools en oplossingen. Het is natuurlijk niet het beste voorbeeld, en geen idee waarom je dat ooit zou doen, maar het was helaas het voorbeeld dat ik hierboven al gebruikt had.
Reden 3: Grotere doelgroep
Uiteindelijk is dit denk ik de enige echte reden waarom ze dit doen. Ik heb lang en breed nagedacht, meerdere AI's ook dit vraagstuk voorgelegd (en de antwoorden zaten helaas vol met ondoordachte nonsens, zelfs o3 kwam met totaal onzinnige inzichten). De meerwaarde zit voor een groot deel toch in de 'backend' van een code-assistant, en door ook een CLI-applicatie aan te bieden wordt je afzetmarkt toch weer een stuk groter. Niet alleen de mensen die VSCode/IntelliJ IDE's gebruiken, maar ook de mensen die niet-ondersteunde IDE's gebruiken kunnen nu toch gebruik maken van je product. En de nodige investering is waarschijnlijk lager dan die van het bouwen van twee plugins. Dus door tevens een CLI-applicatie aan te bieden, bedien je echt de maximale markt.
Conclusie
Ik hoopte minimaal drie redenen in dit artikel te kunnen geven vanuit het perspectief van een developer die de tool moet gebruiken, maar eigenlijk was alleen reden 2 daar sterk genoeg voor. Bij reden 1 herken ik echt wel dat dit meer een 'me-problem' is, en reden 3 is vooral voor de maker van de CLI-tool relevant.
Ik heb natuurlijk nog wel een vierde, puur persoonlijke, reden. En dat is dat ik werken in de terminal gewoon veel leuker vind dan werken in een GUI. En misschien ben ik niet de enige?
