gptsh
CLI Node.js de décembre 2020: GPT-3 dans le shell, avant que les assistants de terminal ne deviennent évidents.
Décembre 2020, GPT-3 dans un shell
J'ai écrit gptsh à partir d'une friction banale: savoir ce que l'on veut faire dans un terminal, puis perdre du temps à retrouver la bonne commande. Le README le disait simplement: traduire une demande en langage naturel en commande shell.
À l'époque, GPT-3 se manipulait par un endpoint de completion. Pas de tool calling, pas de contexte de repo, pas d'agent qui édite des fichiers. On envoyait un prompt au moteur davinci , on recevait du texte, puis on décidait quoi en faire.
$ gptsh install node 12 repositorycurl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -Le repo tenait dans une boucle
J'ai gardé le code court. Le package exposait un binaire npm gptsh . src/index.js utilisait yargs pour lire la phrase utilisateur et les options. src/buildConfig.js cherchait la clé OpenAI dans les flags, les variables OPENAI_SECRET_KEY / OPENAI_ENGINE_ID ou ~/.gptshrc . src/buildPrompt.js remplissait un template et ajoutait un hint de plateforme: Linux, macOS, PowerShell, AIX, FreeBSD, OpenBSD, SunOS ou Windows Command Prompt.
La requête finale passait par axios vers /engines/{engine}/completions . Le résultat était dédupliqué avec lodash/uniq , nettoyé du préfixe $ , puis imprimé.
argv -> config -> prompt template -> OpenAI completion -> stdoutLe repo avait aussi ce qu'il fallait pour être essayé sans cérémonie: package npm, image Docker shorwood/gptsh , alias shell, Gitpod, workflow de publication npm, workflow Docker Hub, licence MIT.
La partie dangereuse restait visible
Le README contenait volontairement des exemples qui font lever un sourcil: List all files of this directory | bash , Delete the root directory --engine ada , ajout de remote Git, reset de service. Je ne cachais pas que générer une commande shell est une zone dangereuse.
Ce choix est plus important que le modèle. La sortie allait sur stdout. L'utilisateur pouvait lire, modifier, copier, pipe vers bash s'il assumait le risque. La boucle restait simple et inspectable.
Ce que les assistants CLI ont gardé
Les assistants CLI actuels sont beaucoup plus puissants. Ils lisent le repo, proposent des patchs, demandent des approvals, relancent des tests. gptsh montre une version ancienne et mince de la même direction: placer un modèle à côté de l'endroit où le développeur agit.
- Le shell donnait au modèle un contexte d'usage précis.
- npm et Docker rendaient l'expérience installable hors du repo.
- La commande restait visible avant exécution.
- Les limites du projet annonçaient déjà les sujets qui comptent aujourd'hui: contexte, permissions, dry-run, audit, rollback.