Découverte de Cursor, un éditeur basé sur l'IA

Posté le 27 septembre 2024 - High-Tech - Par Grafikart - Proposer une correction

Depuis quelque temps on parle de plus en plus de l'utilisation de l'intelligence artificielle dans le cadre du développement. Un éditeur en particulier, Cursor, a pas mal fait parler de lui en s'annonçant comme "The AI Code Editor". Mais est-ce vraiment un projet intéressant ou un nième projet surévalué visant à attirer des investisseurs sans réel utilité ?

Avant de commencer, je tiens à préciser je ne suis pas sponsorisé par Cursor. Je suis d'ailleurs quelqu'un de plutôt sceptique vis à vis de l'utilisation de l'IA pour le développement. J'avais testé Github Copilot pendant un petit moment et je n'avais pas été convaincu (les suggestions ajoutent trop de bruit et obligent à faire une revue de code perpétuelle). J'avais évoqué ce problème dans mon précédent article sur l'utilisation de l'IA dans le dev

Réels nouveautés ou marketing ?

Avant de télécharger l'éditeur j'étais plutôt sceptique sur la proposition et je m'attendais à un simple éditeur qui ne fait qu'intégrer une IA tiers pour une complétion / chat.
Lors du premier lancement on remarque déjà que l'éditeur n'est pas original, mais se base sur Visual Studio code (on nous propose même d'importer nos préférences et nos extensions). Cela n'inspire pas confiance...

Mais lors des premières suggestions Cursor se démarque par sa capacité à proposer des suggestion d'édition. L'IA ne se limite pas à proposer de nouvelles lignes de code lorsque vous taper mais peut aussi proposer de changer le code existant en fonction de ce que vous êtes en train de faire.
Pour vous donner un exemple :

export function MonComposant () {
    return <div>
        <h1>Mon titre</h1>
        {/* ... */}
    </div>
}

Si je commence à créer un type au dessus de cette fonction il me suggèrera automatiquement de l'utiliser comme paramètre de la fonction. Il proposera ensuite de modifier certains éléments du composant en lien avec le nom des propriété.

type Props = {
    title: string
}

export function MonComposant ({title}: Props) {
    return <div>
        <h1>{title}</h1>
        {/* ... */}
    </div>
}

Aussi, lorsque je change le nom d'une propriété dans un objet, il va automatiquement chercher à mettre à jour les utilisations de cette propriété et changer le nom des getter et setter.

Composer pour une aide à la demande

Une des critique que j'avais émis vis à vis de Copilot est le bruit apporté par les suggestions :

  • L'IA a trop peu de contexte mais se déclenche quand même et propose un code qui ne correspond pas avec ce que l'on a l'intention de faire.
  • L'IA hallucine des choses qui n'existent pas et introduit des bugs qu'il faudra résoudre par la suite.
  • La suggestion sort d'un coup plus d'une dizaines de ligne qu'il faut déchiffrer pour comprendre si cela correspond au besoin ou non.

Dans le cadre de Cursor il est possible de désactiver la fonction d'autocomplétions facilement. Une fonction "Composer" permet de faire appel à l'IA sur demande pour le fichier courant ou pour les lignes sélectionnées. L'IA propose alors des modifications, présentées sous forme de "diff", que l'on pourra accepter ou refuser.

Affichage des modifications

L'avantage de cette approche est que l'on n'est pas submerger de propositions en permanence et on peut choisir quand se reposer sur l'IA ou non. Mais aussi lui donner un peu plus de contexte sur ce que l'on cherche à faire.

Contexte dans les prompts

L'autre point intéressant est le fait de pouvoir ajouter un contexte dans les prompts afin que l'IA utilise le contenu d'un fichier particulier pour créer sa proposition.

Génère un test pour la fonction getHours() de @date.ts

Il est aussi possible d'utiliser l'entièreté du projet dans le contexte mais, dans les faits, je trouve que cela n'aide pas forcément l'IA a proposer une suggestion pertinente. Le fait de pouvoir lui passer un contexte plus limité et spécifique permet justement d'obtenir un résultat plus prévisible.

Génère moi le type correspondant au retour de GET /pets en utilisant @openapi.yaml

L'IA ne sait pas coder

Quand on utilise une IA il est important de comprendre son fonctionnement pour ne pas lui prêter des capacités qui ne sont pas les siennes. Cursor n'échappe pas à cette règle. On notera d'ailleurs que la présentation de l'éditeur va dans ce sens et ils ne prétendent pas être capable de faire coder l'IA à votre place.

Exemple de complétion

Là où l'IA est efficace c'est lorsqu'il s'agit de transformer de l'information. Si on lui demande de générer un type à partir d'un JSON, de rajouter des commentaires à des fonctions, de générer des erreurs… elle va souvent tomber juste. En revanche, si on lui demande d'écrire la logique d'une fonction qui n'est pas un problème classique, elle va avoir tendance à générer un mauvais code :

  • Les IA ne comprennent pas réellement le code qu'elles produisent et ont déduit les règles à partir des données d'entrainements. Elle ne sont pas capable d'une analyse fine pour comprendre les méthodes disponibles en fonction des types de données.
  • Il est aussi difficile d'expliciter correctement un problème car beaucoup de choses sont souvent implicites pour nous.

L'exemple que je donne souvent est une fonction qui liste les heures de la journées dans un format humain (par exemple 02:00 AM). Si vous demandez cela à une IA il y a de forte chance que le retour de la fonction ne soit pas en adéquation avec ce que vous attendez.

// Prompt : Donne moi une fonction getHours() qui renvoie les heures de la journées sous forme de tableau au format "02:00 AM" en JavaScript

function getHours() {
    const hours = [];
    for (let i = 0; i < 24; i++) {
        let hour = i % 12 === 0 ? 12 : i % 12;
        let period = i < 12 ? "AM" : "PM";
        let formattedHour = hour.toString().padStart(2, '0') + ":00 " + period;
        hours.push(formattedHour);
    }
    return hours;
}

// Résultat (exact si on suit la définition AM / PM, mais peu clair)
// ['12:00 AM', '01:00 AM', ..., '12:00 PM', '01:00 PM', '02:00 PM', ... '11:00 PM']

// Attendu (plus facile à comprendre pour un utilisateur)
// ['00:00 AM', '01:00 AM', ..., '12:00 AM', '01:00 PM', '02:00 PM', ... '11:00 PM']

Même si c'est techniquement exact, ces heures peuvent être perturbante pour un utilisateur (12 PM au milieu de la journée, et 12 AM au début de l'après midi) et obtenir le résultat attendu n'est pas évident pour une IA.

Attention donc à ce que l'on demande à l'IA car sa compréhension du problème n'est pas forcément représentative de ce que vous attendez et se reposer sur son interprétation peut amener à de nombreux bugs. Mais, dans le cas de Cursor, leur communication est plutôt honnête sur ce point là.

Cursor is the best way to code with AI

On code avec l'IA, ce n'est pas l'IA qui code.

Mes inquiétudes

Malgré le portrait plutôt positif que j'ai pu dresser de l'éditeur j'ai tout de même quelques réserves.

Un fork de Visual Studio Code

Le premier problème est évidemment la création d'un éditeur à part entière plutôt qu'une extension pour un éditeur existant. Surtout qu'il ne précise pas se reposer sur Visual Studio Code sur leur page d'accueil. Même si je peux comprendre la démarche (des besoins spécifiques en terme d'interface) je ne trouve pas idéal d'un point de vu éthique de se baser sur un projet open source pour vendre une solution fermée et payante.

Pour l'avenir, il est aussi fort probable que Visual Studio Code intègre les éléments pour permettre de reproduire les fonctionnalités de Cursor directement dans l'éditeur avec un extension. Ce qui pourrait rendre Cursor obsolète.

De manière plus général, je pense qu'il serait intéressant de voir se développer un protocole (un peu comme le Language server protocol) autour de la suggestion afin de pouvoir bénéficier de ce genre d'outil quelque soit l'éditeur utilisé.

La vie privée

Même s'ils garantissent un mode "Privacy" les prompts passent par différents services et, à moins de faire confiance à ce qui est annoncé, des données sensibles (fichier d'environnement, code propriétaire) peuvent rapidement se retrouver dans la nature. Surtout que les entreprises n'hésitent pas à utiliser les données des utilisateurs dans le cadre de l'entrainement de leur modèle et l'amélioration de leur service. A moins d'avoir une garantie absolue que les données ne sont pas utilisées en dehors du contexte du prompt je n'envisage pas d'utiliser ce genre d'outil sur des projets qui ne sont pas déjà open source.

A mon sens il n'y a pas de solution simple à ce problème en dehors d'une IA capable de fonctionner localement ou sur un serveur que l'on contrôle.

L'éco-conception

C'est un problème plus personnel mais j'ai beaucoup de mal avec le gaspillage énergétique que certaines pratiques provoquent aujourd'hui. A chaque suggestion on consomme une certaine quantité de ressource réseau pour envoyer le contexte de notre demande. Ensuite les IA consomment aussi une grosse quantité d'énergie à travers les GPU nécessaires pour fournir une suggestion qui ne sera au final pas accepté par l'utilisateur final.

Si on s'imagine que la pratique se développe et que beaucoup de développeurs se mettent à utiliser ce genre d'outil, l'impact sur la consommation d'énergie est loin d'être négligeable.

Faites vous votre propre avis

Malgré tout ce que j'ai pu dire je vous invite à vous faire votre propre avis et de tester l'éditeur si l'idée vous intéresse ou si vous êtes curieux.