Le Problème
Les développeurs écrivent plus de texte que la plupart des gens ne le réalisent. Au-delà du code lui-même, il y a un flux constant d'écriture non-code qui se produit à l'intérieur de VS Code : commentaires en ligne, chaînes de documentation de fonction, sections README, brouillons de message de commit, descriptions de ticket, annotations todo et notes de décision architecturale.
Cette écriture est souvent traitée comme secondaire — quelque chose à faire rapidement ou à différer jusqu'à plus tard. Le résultat est des bases de code avec peu de documentation, des fonctions sans explication de pourquoi elles existent et des décisions architecturales qui n'existent que dans la mémoire de quelqu'un.
La friction est réelle. Après avoir dépensé l'énergie mentale sur un algorithme complexe, la dernière chose que la plupart des développeurs veulent faire est d'écrire un paragraphe l'expliquant. La dactylographie semble du travail supplémentaire en plus du vrai travail. Mais la documentation écrite immédiatement après l'implémentation — pendant que le contexte est frais — est dramatiquement plus précieuse que la documentation écrite une semaine plus tard, ou jamais.
Comment Telvr Fonctionne avec VS Code
Telvr s'intègre avec VS Code et tout autre éditeur de texte via l'injection de position du curseur au niveau du système. Aucune extension VS Code n'est requise. Aucune clé API dans votre éditeur. Aucune configuration à l'intérieur de VS Code lui-même.
Le flux de travail pour la documentation de développement :
- Ouvrez VS Code et positionnez votre curseur où vous voulez que la documentation apparaisse — au-dessus d'une fonction, dans un bloc de commentaire, dans un fichier README ou dans un nouveau document markdown.
- Appuyez sur votre raccourci Telvr.
- Dictez votre documentation, explication ou description de tâche.
- Relâchez le raccourci. La sortie formatée apparaît à votre curseur en moins de deux secondes.
- Continuez à coder.
Telvr fonctionne dans tous les contextes de VS Code : l'éditeur lui-même, le terminal intégré (pour les idées de commande parlées) et les fichiers de prévisualisation markdown. Il fonctionne également dans le fichier JSON des paramètres de VS Code et d'autres fichiers de configuration où vous pourriez vouloir ajouter des commentaires.
Meilleur Mode d'Enrichissement pour VS Code : Tâche de Développement
Le mode Tâche de Développement est conçu spécifiquement pour la documentation du flux de travail de développement. Quand vous l'activez et parlez d'un morceau de code ou d'une tâche, l'IA structure votre sortie dans un format prêt pour le développement avec quatre sections :
Contexte : Information générale expliquant ce que ce code fait, pourquoi il existe ou quel problème il résout.
Exigences : Ce que l'implémentation doit satisfaire — contraintes, dépendances, cas limites ou règles métier.
Notes d'Implémentation : Détails techniques, approche adoptée, compromis considérés ou avertissements importants.
Critères d'Acceptation : Comment vérifier que l'implémentation est correcte — quels tests doivent passer, quel comportement attendre ou quelles conditions définissent le succès.
Cette structure est immédiatement utile pour :
- Blocs de documentation au niveau de la fonction expliquant la logique complexe
- Commentaires d'en-tête au niveau du fichier pour les modules non évidents
- Descriptions de tâches lors de la planification du travail directement dans les fichiers de code
- Enregistrements de décision architecturale (ADR) rédigés en markdown
Pour les commentaires en ligne plus simples — une explication rapide d'une regex, une note sur une limitation connue — le mode Nettoyer et Corriger vous donne une prose propre et lisible sans la structure formelle.
Exemple Avant et Après
Entrée de parole brute (mode Tâche de Développement) :
« donc cette fonction gère la limitation de débit pour l'API euh elle doit suivre les requêtes par utilisateur par minute et elle devrait utiliser une fenêtre glissante pas une fenêtre fixe parce que les fenêtres fixes peuvent permettre le trafic en rafale juste à la limite um elle dépend de Redis pour le stockage du compteur et elle doit retourner un 429 avec un en-tête retry-after quand la limite est dépassée on devrait aussi s'assurer que les clés de limite expirent automatiquement pour ne pas remplir Redis au fil du temps »
Après le mode Tâche de Développement :
Contexte Gère la limitation de débit API par utilisateur en utilisant un algorithme de fenêtre glissante. Utilise Redis pour le stockage du compteur distribué pour supporter les déploiements multi-instances.
Exigences
- Suivre les requêtes par utilisateur par minute en utilisant une fenêtre glissante (pas une fenêtre fixe)
- Retourner HTTP 429 avec l'en-tête
Retry-Afterquand la limite est dépassée- Les clés Redis doivent expirer automatiquement pour prévenir la croissance de stockage non bornée
Notes d'Implémentation
- Fenêtre glissante choisie par rapport à la fenêtre fixe pour prévenir le trafic en rafale aux limites de fenêtre
- Dépendance Redis requise pour l'état de limitation de débit distribué
Critères d'Acceptation
- Limitation de débit appliquée correctement sous les modèles de trafic soutenus et en rafale
- Les clés Redis expirent comme prévu (vérifier avec les commandes TTL)
- Les réponses 429 incluent un en-tête
Retry-Aftervalide- Aucune accumulation de clé Redis après les périodes de test prolongées
La version parlée est une explication divaguante. La sortie Tâche de Développement est une spécification structurée que vous pouvez coller directement au-dessus de la fonction comme bloc de documentation.
Économies de Temps
La documentation est chroniquement sous-prioritaire parce qu'elle est lente à écrire par rapport à sa valeur perçue dans le moment. Les développeurs qui basculent vers la documentation vocale rapportent deux changements : ils documentent plus et documentent mieux.
L'écriture d'un bloc de documentation complète de fonction prend cinq à huit minutes de dactylographie concentrée. Parler le même contenu prend soixante à quatre-vingt-dix secondes, et le mode Tâche de Développement gère le formatage. L'investissement de temps réduit rend la documentation praticable plutôt que lourde.
Pour les documents plus longs — READMEs, enregistrements de décision architecturale, guides d'intégration — les économies de temps se mettent à l'échelle proportionnellement. Un README de mille mots qui prendrait quarante-cinq minutes à écrire peut être dicté en dix à douze minutes puis édité à partir de là.
Il y a aussi un argument de qualité. Quand la documentation est rédigée immédiatement après l'écriture du code, pendant que les détails d'implémentation sont frais, la documentation résultante est plus précise et plus utile. La vitesse de Telvr rend pratique de documenter pendant le codage plutôt que comme une tâche différée.
Sur une semaine de développement typique avec un travail de documentation régulier, Telvr peut récupérer deux à trois heures — et produire une base de code mieux documentée en tant qu'effet secondaire.
Débuter
- Téléchargez Telvr pour macOS depuis telvr.ai.
- Complétez la configuration et configurez votre microphone préféré.
- Définissez un raccourci qui fonctionne dans votre flux de travail VS Code — quelque chose que vous pouvez appuyer sans bouger vos mains loin de la rangée d'accueil.
- Ouvrez VS Code, positionnez votre curseur au-dessus d'une fonction ou dans un bloc de documentation et testez votre première dictée.
- Définissez Tâche de Développement comme votre mode défaut pour le travail de documentation de développement.
Un bon premier exercice : trouvez les trois fonctions les plus complexes dans votre projet actuel — celles qui bénéficieraient le plus d'une documentation claire — et dictez un bloc Tâche de Développement pour chacune. L'exercice complet devrait prendre moins de dix minutes et produire une documentation qui aurait pris une heure à écrire.
Telvr inclut un essai gratuit de 14 jours avec accès complet à tous les modes d'enrichissement. Après l'essai, la tarification est EUR 3 par mois plus à partir de EUR 0,003 par minute de transcription.