La vérité sur Claude et ChatGPT

Aujourd'hui, les gens n'ont que ça en bouche, Claude, ChatGPT, les MCP, etc...

MCP pour ceux qui n'en n'ont jamais entendu parlé, ce sont des "extensions" pour chatbot qui permettent d'ajouter des fonctionnalités. En gros de donner des super pouvoirs aux bots conversationnels.

Le besoin

En tant que développeur, créateur de produit, on a un besoin: de productivité.

On a besoin que les projets avancent, on a besoin d'aller vite, toujours plus vite.

Pour beaucoup de gens, les chatbots sont un cauchemar car ils font leur boulot rapidement, parfois presque mieux voire mieux que vous même.

Oui, ça va vite! Oui, on aimerait que ça marche parfaitement, que ça aille encore plus vite, si possible.

En tant que créateur d'applications, je suis très demandeur de ce genre de solutions. J'aimerais que ça aille vite et bien.

Le fantasme

Pour beaucoup de gens, ces solutions sont une réponse à plein de problématiques qu'ils rencontrent dans leur quotidien, dans leur travail...

Avoir un chatbot comme outil c'est avoir une carte en main pour régler certains problèmes et améliorer sa productivité.

Le problème, c'est aussi la vision des gens. Pour eux, c'est chatbot, c'est un peu de la magie, on lui demande quelque chose, et il fait. Et comme ça parait rapide et que le résultat parait convenable de loin, j'ai l'impression que cela crée un peu un fantasme du système parfait, très rapide et ultra compétent.

J'entends souvent parler des utilisateurs qui disent: "Olala c'est formidable, il est trop fort, il va trop vite..."

Oui, il va vite, oui il est pas mauvais.

Mais lorsque j'entends il va remplacer les devs etc... Je tiens à vous montrer quelque chose, et regardez bien en détail, soyez très attentifs si vous êtes un peu technique, je vous assure que cela vaut le détour.

La réalité

Je travail en ce moment sur un nouveau produit et je cherche moi même à améliorer ma productivité. Parfois je demande à un bot de gérer une fonction ou deux pour moi histoire d'accélérer un peu.

Car, comme je vous l'ai dit, pour moi ce sont des outils et je ne demande que ça de les utiliser pour améliorer ma cadence de code.

Coder vite c'est une chose, cependant j'ai une organisation et j'aime bien que le code suive mon organisation. Et pour cela je fais le maximum pour pré-prompt en donnant du contexte, l'accès au fichiers sources. D'ailleurs j'essaye au maximum de lui dire, regarde, c'est comme ça que je fais AB, tu as accès à tout, peux tu me faire AC ?

Donc on ne peut pas dire qu'il ne sait pas trop où aller. En sachant que je lui demande des choses très précises qui ne nécessite pas énormément de contexte extérieure à notre scope.

Ici je lui demande de me coder une fonction qui calcule les totaux et la tva sur une facture. Sans avoir besoin de rentrer dans les détails du pourquoi du comment, concentrez vous uniquement sur le résultat que va me pondre Claude 3.7.

export function computeInvoiceTotals(inputInvoice: InputInvoice): InvoiceRender {
  const updatedInvoice: Partial<InvoiceRender> = {
    ...inputInvoice,
    lines: inputInvoice.lines.map(inputLine => {
      return {
        ...inputLine,
        totalAmount: inputLine.amount * inputLine.quantity
      }
    })
  }

  updatedInvoice.lines = updatedInvoice.lines?.map(calculateLineTotal)

  updatedInvoice.vatTable = generateVatTable(updatedInvoice.lines ?? [])

  updatedInvoice.totalWithoutTaxes =
    updatedInvoice.lines?.reduce((sum: number, line: InvoiceLine) => sum + line.totalAmount, 0) ?? 0

  updatedInvoice.totalVat = updatedInvoice.vatTable.reduce(
    (sum: number, vat: VatLine) => sum + vat.vatAmount,
    0
  )

  updatedInvoice.totalWithTaxes = updatedInvoice.totalWithoutTaxes + updatedInvoice.totalVat

  const totalDiscounts = calculateTotalDiscounts(updatedInvoice.lines ?? [])

  if (totalDiscounts! > 0) {
    updatedInvoice.totalDiscounts = totalDiscounts
  }

  const hasDiscounts = inputInvoice.lines.some(line => line.discountAmount !== undefined)

  const invoice = { ...updatedInvoice, hasDiscounts } as InvoiceRender

  return invoice
}

Remarque: Claude a tendance à recréer des variables inutilement, le split des opérations est une bonne chose pour la lisibilité mais l'object duplication est superflu, d'ailleurs, à la lecture, je suis vraiment très perturbé, je trouve cela... sale, EXTRÊMEMENT SALE !

Du coup je me dis, ok... vas-y on refacto:

export function computeInvoiceTotals(inputInvoice: InputInvoice): InvoiceRender {
  const lines = inputInvoice.lines.map(calculateLineTotal)

  const vatTable = generateVatTable(lines)

  const totalWithoutTaxes = lines.reduce(
    (sum: number, line: InvoiceLineWithTotal) => sum + line.totalAmount,
    0
  )

  const totalVat = vatTable.reduce((sum: number, vat: VatLine) => sum + vat.vatAmount, 0)

  const hasDiscounts = lines.some(line => line.discountAmount !== undefined)

  return {
    ...inputInvoice,
    lines,
    vatTable,
    totalWithoutTaxes,
    totalVat,
    totalWithTaxes: totalWithoutTaxes + totalVat,
    hasDiscounts
  }
}

Si vous n'êtes pas encore convaincu, qu'à cela ne tienne, on fait un second essai. On va faire plus simple, on veut un total par ligne de produit:

Voici ce que Claude 3.7 nous donne:

export const calculateLineTotal = (line: InputInvoiceLine): InvoiceLineWithTotal => {
  const lineTotal = line.amount * line.quantity

  if (line.discountType === 'PERCENTAGE' && line.discountAmount) {
    const discountValue = Math.round(lineTotal * (line.discountAmount / 100))
    return { ...line, totalAmount: lineTotal - discountValue }
  } else if (line.discountType === 'AMOUNT' && line.discountAmount) {
    return { ...line, totalAmount: lineTotal - line.discountAmount }
  } else {
    return { ...line, totalAmount: lineTotal }
  }
}

Pareil, je suis très perturbé par ce que je lis, beaucoup de conditions successives des objets créés à chaque fois pour chacune des conditions.

Bon, dans ce cas, c'est pire, ça ne fonctionne pas comme attendu. Donc je refactor de nouveau:

export const calculateLineTotal = (line: InputInvoiceLine): InvoiceLineWithTotal => {
  let discountValue = line.discountAmount ?? 0
  let discountType = line.discountType ?? 'AMOUNT'

  if (discountType === 'PERCENTAGE') {
    discountValue = Math.round(line.amount * (discountValue / 100))
  }

  const totalAmount = line.amount * line.quantity - discountValue * line.quantity

  return {
    ...line,
    totalAmount
  }
}

Dans notre exemple, je comprends que peu importe le type de discount (AMOUNT ou PERCENTAGE), ce que l'on va faire, c'est une simple soustraction avec le total.

Je me dis que par défaut, qu'il y ait un discount ou pas, je vais tout passer en AMOUNT avec une valeur de 0. Comme ça, pas de valeur à calculer comme dans le cas PERCENTAGE, et une soustraction avec 0 ne changera jamais le résultat.

Et je trouve que cela beaucoup plus lisible.

Disclaimer: Alors oui, ce que Claude nous pond fonctionne et cela peut déjà satisfaire de nombreuses personnes.

Bémol: Je trouve en revanche que la qualité du code qu'il sort est médiocre. Sans vouloir vexer quiconque qui adopterait une même approche. Mais en toute honnêteté, un code comme ça, partagé avec des centaines de personnes dans une équipe.

Soit vous allez faire peur à beaucoup de gens et serez le seul maintainer de ce code, soit personne ne va broncher pendant des mois jusqu'à ce que tout pète parce que les gens ne comprennent pas ce que vous avez fait et plus tard, ce sera à l'origine de bugs...

Le problème

Je pense que tout vient de la source de donnée sur lesquels les bots s'appuient pour entrainer leur model. Dans les faits, ça fait des années que je développe et je pense sincèrement avoir les connaissances et l'autorité suffisante pour dire que peu de développeurs ont réellement un "bon niveau".

Parti de ce postulat, je ne peux que constater que si l'on appuie son model sur une base moyenne de développeurs médiocres (cf: le code spaghetti de Wordpress etc... l'open source n'a jamais été 100% parfait), il ne peut pas sortir quelque chose de fou comme résultat.

A moins que le bot, un jour, ne soit fondamentalement convaincu qu'il doit apprendre par lui même et opter pour une approche évolutive basée sur ses expériences personnelles et non la data existante, cela restera factuel.

C'est pourquoi, avec l'approche actuelle des models, même si les bots sont utiles dans pleins de tâches brain-less comme de l'affichage etc... Je ne recommande pas de faire coder votre logique par des bots.

Et n'en déplaise à tous les fanboys qui s'exclament "les bots font déjà mieux que tout le monde". Alors, probablement qu'il font déjà mieux que vous... Ca j'en suis quasiment certain. Mais si vous faîtes partie du tout petit pourcentage de gens suffisamment experts, je pense que vous avez encore des choses à apprendre aux chatbots.

Aujourd'hui, à part les extra juniors, je ne les vois pas remplacer grand monde, à moins que les utilisateurs aient envie de créer un bug latent qu'il ne seront pas en mesure de résoudre.

Faîtes le bon choix.