Journal Je lis du code généré

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
27
12
déc.
2025

Salut les moules

J'écris souvent ; rarement ici.

J'ai depuis quelques semaines le bonheur de suivre quelques devs débutants, ou aspirants devs. Je lis donc du code généré, ma joie est grande. Je profite de ce vendredi pour partager avec vous mes impressions. L'incubateur d'excellence qu'est DLFP aura, si je suis chanceux, d'autres retours d'expérience à partager.

C'est propre.

Plus propre que du code humain. Trop propre. Ce que tu gagnes en lisibilité, tu le perds en concision, en expressivité et en sens. Au fond, rien ne change. Le code décrit le comment, alors que ce qui m'intéresse reste le pourquoi.

Il n'y a évidemment pas de tests. Rien à voir avec la génération. De toute façon il faudra tout reprendre pour intégrer un vrai dispositif de tests, condition nécessaire pour que je fasse confiance au programme.

Le code généré se repère immédiatement: fonctions bien nommées, formatage impeccable, docstrings qui brillent, noms de variables trop précis, aucune variable a, b, x, tmp, out, typage strict des entrées et sorties etc. Un niveau de détail souvent trop fin, l'inverse d'un code en cours d'écriture.

Cette forme parfaite est trompeuse.

Tu crois que le code fait le travail. Peut-être au niveau micro, les fonctions sont surement correctes. Au niveau macro, macache. Alors comment être sûr que ce code fait ce qu'il annonce ? En découplant les fonctions et en le disséquant pièce par pièce.

C'est certes plus agréable à lire, mais tu perds un indicateur essentiel. La maturité disparaît. La forme est standardisée. Il n'y a plus de code smell, plus de style, plus de rugosité. Comment juger du fond uniquement à la lecture ?

Certains codes écrits n'importe comment se repèrent au premier coup d'œil. C'est une alerte. Pas de structure, fonctions fleuves de 100 lignes, pas de séparation fond/forme. Un brouillon intégral. Et les brouillons doivent être réécrits.

Le même code, rédigé proprement, structuré, soigné, fera tout aussi n'importe quoi donnera l'impression que c'est pensé. L'impression d'une intention, de la crasse propre.

De la crasse propre ?

Oui mais c'est trolldi, alors je vous en prie.

Avec le code généré, tu perds la possibilité de juger sur l'apparence. Plus de style, plus de subtilités, plus de petites variables piégées. Si tout est bien nommé, comment repérer ce qui compte vraiment ?

Avec ce code aseptisé, je vais peut-être perdre du temps.
Ou pas.

(publié ici aussi)

  • # moi je lui demande de ré-ecrire moncode

    Posté par  (site web personnel) . Évalué à 8 (+6/-0).

    Arf, ben moi je fais ré-écrire tout mon code par des llm pour éviter justement ces noms de variables foireux, ces fonctions trop longues, pour documenter mon code, repenser les structures, etc.

    En tant que chercheur en sciences humaines qui a besoin de coder, et d'outils specifiques, mais qui ne code pas bien, et c'est pas comme si y aura un jour des sous pour employer des devs dans mon domaine, ben je suis très satisfait de l'aide que me fournissent les llm.

    D'ailleurs, je trouve le code des llm plus lisibles et compréhensibles que le mien une semaine après l'avoir pondu.

  • # Selon les jours

    Posté par  (site web personnel) . Évalué à 6 (+4/-0).

    Les LLM te pondent du code avec un style un jour et un autre style le lendemain… Si ton code est un peu sérieux, en gros plus que les quelques 500 lignes, tu vas rapidement te retrouver avec plusieurs styles très propre, mais différent.

    Si tu veux un truc propre et fonctionnel, tu te retrouve à reprendre des bouts régulièrement.

    • [^] # Re: Selon les jours

      Posté par  . Évalué à 2 (+0/-0). Dernière modification le 14 décembre 2025 à 12:38.

      Les LLM te pondent du code avec un style un jour et un autre style le lendemain…

      Même pas besoin d'attendre le lendemain …. Il suffit de leur demander de corriger un truc dans une nouvelle itératin moins e 5 mn après pour qu'elles changent des choses que tu n'as pas demandées …

      En plus de ça elles ont la mauvaise idée de feire des trucs du genre 

      function fairequelquechose_d_unuser( var name, var birthday, var status) {
   user_name = name
   user_birthday = birthday
   user_status = status
}

      plutôt que d'utiliser un truc du style :

      struct user {
    name = name
    birthday = birthday
    status = status 
}

      Je l'ai constaté de nombreuses fois …. Ca sent le stackoverflow basique qui répond à un problème d'étudiant … pas à du code solide.

      Je vois aussi du code généré passer …. il "marche" … mais pour ce qui est du respect des bonnes pratiques de codage, mis à part la forme (comme dit par le PI) ya rien …

      • [^] # Re: Selon les jours

        Posté par  (site web personnel, Mastodon) . Évalué à 4 (+4/-2).

        En plus de ça elles ont la mauvaise idée de feire des trucs du genre

        Vu la mise en page de ton post, il a probablement été écrit par un gadget de technobro que certains appellent HiHa.

        Titre de l'image

        Et comme le trolldi, tout est permis, je vais me vautrer au coin du feu avec un bon bouquin…

        • [^] # Re: Selon les jours

          Posté par  (site web personnel) . Évalué à 3 (+1/-0).

          Et comme le trolldi, tout est permis, je vais me vautrer au coin du feu avec un bon bouquin…

          ou relire aide édition sur le wiki : je ne vois plus quoi ajouter / retirer pour que ce soit compréhensible (le bouton Prévisualiser permettant d'avérer le résultat obtenu o_O bon faut regarder aussi).

          • [^] # Re: Selon les jours

            Posté par  . Évalué à 2 (+0/-0).

            J'avais prévisualisé, problème de mise en page …

            J'ai corrigé puis envoyé sena prévisualiser à nouveau. Désolé.

    • [^] # Re: Selon les jours

      Posté par  . Évalué à 8 (+6/-0).

      Les LLM te pondent du code avec un style un jour et un autre style le lendemain

      Ce n'est plus vrai depuis longtemps. Ou plutôt ça n'est vrai que si on s'amuse à demander à ChatGPT dans son interface Web puis à copier-coller mais plus personne ne fait ça. Ton agent est dans ta cli, il a un fichier AGENTS.md avec les guidelines, les librairies à utiliser ou à éviter, les trucs que tu lui interdis de faire, il met les commentaires là où il a touché des trucs, … Bref il faut le considérer comme un dev à qui tu donnerais toutes les consignes pour respecter le style et les consignes du projet. Ton dev ne peut pas les deviner, l'IA non plus. Par contre ça marche bien quand c'est fourni explicitement.

      • [^] # Re: Selon les jours

        Posté par  (site web personnel) . Évalué à 2 (+1/-0).

        J'avoue que je ne m'en sers pas.
        Un jour peut-être, quand j'aurais trouvé comment le faire fonctionner avec Emacs — et quand l'envie sera là.

        • [^] # Re: Selon les jours

          Posté par  (site web personnel) . Évalué à 7 (+5/-0).

          En attendant, tu peux lui préciser le style dans le prompt, j'imagine. « ChatQuiPet, écrit moi un Taptempo à la manière de Balzac stp ! »

          Adhérer à l'April, ça vous tente ?

  • # TDD

    Posté par  (site web personnel) . Évalué à 3 (+1/-0).

    Au niveau macro, macache

    demande à avoir les tests unitaires et les tests d'intégration en plus du code ;-)

    comme ça la 1ère relecture sera faite par un LLM, la 2ème sans doute aussi, ensuite tu auras une CI/CD opérationnelle qui fera le boulot pour toi.

    Elle est pas belle la vie ? :D

    Ah oui : TDD c'est bien-sûr Test-Driven Development et CI/CD, si tu ne connais pas, là il vaudrait mieux se renseigner :p

    • [^] # Re: TDD

      Posté par  (site web personnel) . Évalué à 4 (+3/-0).

      Ils ont oublié d'écrire des tests et visiblement ne connaissent pas le TDD ! Ca n'a aucun lien avec la génération, bien sûr, c'est générique. Ca donne un truc d'apparence très propre, dont le fond reste mystérieux et qui sent la pluie.

      Je suis assez étonné qu'on puisse encore se lancer dans du dev from scratch sans commencer par des tests.

  • # Mon expérience

    Posté par  (site web personnel) . Évalué à 5 (+6/-3).

    Pour la première fois, j'ai tenté ce soir de faire écrire un bout de code à un LLM. Un truc très simple (peut-être pas tant que ça en fait). Rien à faire. Mêmes une fonction de trois lignes, il n'y arrive pas. Pour le moment j'en reste à contempler l'abîme entre ce que j'ai entendu un peu partout, et ce que j'obtiens.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Mon expérience

      Posté par  (Mastodon) . Évalué à 8 (+5/-0).

      C'est un peu de mauvaise fois où tu ne lui a donné aucun contexte.

      Je n'aime pas trop coder avec une LLM mais si tu donnes du contexte tu peux obtenir des trucs simple en décrivant bien pas à pas ce que tu peux obtenir. À mon job je me connecte avec un VDI sur lequel je ne peux casi rien installer et mais en plus d'un IDE avec copilot j'ai accès à python, go et des jvm. Du coup j'ai vibe codé des petits outils rapides. Quelques exemples d'utilisation dernièrement:

      • une classe java (je n'ai jamais codé en java) qui se connecte à des brokers kafka en utilisant un keystore et liste les topics disponible (pour pouvoir tester des keystores avec des certificats renouvelés et m'assurer qu'ils fonctionnent avant de les déployer comme secrets dans un cluster kubernetes). Certains de mes collègues utilisent offset explorer pour ça mais la bureaucracie pour l'obtenir est tellement longue que j'ai laissé tomber.

      • un programme python qui prend en entrée un fichier csv dont je lui ai décris les colonnes, pour aller interroger des repos github, télécharger des artefacts (avec des rapports de sécurités) du résultat de pipelines github actions et les ranger comme il faut dans un répertoire pour pouvoir les donner à un comité gérant les autorisations de changements

      • un autre programme python qui interroge une api (je lui ai fourni le fichier swagger openapi comme contexte) pour me faire des listing et rapports variés sans avoir à faire 2000 clicks dans le site pour obtenir la même info.

      Bref pas des trucs critiques mais des machins qui me rendaient service sans me faire passer trop de temps dessus pendant que je me concentrais sur des trucs plus qui me demandaient plus de concentration.

      Par contre il faut être très précis sur ce que l'on veut, t'es obligé de lui dire des trucs évidents comme ne pas mettre plein de commentaires inutilesm ne pas hardcoder des valeurs mais utiliser des arguments ou variables d'environnement sinon il va faire son dev cracra. C'est bien d'avoir un canevas en markdown que tu peux fournir avec des règles à suivre.

      • [^] # Re: Mon expérience [mode trolldi=on]

        Posté par  . Évalué à 10 (+8/-0).

        Par contre il faut être très précis sur ce que l'on veut, t'es obligé de lui dire des trucs évidents […] C'est bien d'avoir un canevas en markdown que tu peux fournir avec des règles à suivre.

        L'idéal étant de lui montrer le code que tu veux, et de lui demander d'écrire le même code. Il y arrivera peut-être ?

        (inspiré de cette planche de Commit Strip : Des spécifications très complètes et très précises)

        • [^] # Re: Mon expérience [mode trolldi=on]

          Posté par  (site web personnel) . Évalué à 8 (+6/-0).

          Au boulot on prépare des entretiens d'embauche. J'ai écris un énoncé pour un exercice de programmation qui colle un peu à notre domaine, où le candidat doit implémenter un petit algo. J'ai fait un truc classique avec un peu de contexte général, les conditions sur les entrées, ce qu'on attend en sortie, etc.

          J'ai ensuite collé ça dans ChatGPT et il a sorti un truc tout à fait convenable. Maintenant je suis bien embêté parce que je ne vais pas pouvoir utiliser ce genre d'exo pour évaluer les candidats en travail à la maison :(

          En tout cas, ça m'a montré qu'avec une bonne spec' on pouvait obtenir un truc satisfaisant au moins pour un petit outil. Après j'ai aussi eu une expérience d'itérations sur du code dans le cadre d'une évaluation de l'outil, et là c'était catastrophique. Chaque itération était plus pénible que la précédente.

          Ça résume un peu mon expérience avec les LLM jusqu'ici : c'est plutôt OK en surface ou quand on connaît pas trop le sujet, et plutôt bof quand on creuse.

          • [^] # Re: Mon expérience [mode trolldi=on]

            Posté par  (site web personnel) . Évalué à 6 (+3/-0).

            Le test que j'utilise consiste à faire une revue de code avec un futur collègue.

            Il n'y a pas de piège, le code est banal et pourtant la plupart des candidats s'effondrent 😭.

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Mon expérience [mode trolldi=on]

              Posté par  (site web personnel) . Évalué à 3 (+1/-0).

              On avait commencé par une revue de code en fait, mais comme toi ce n'était pas convainquant. On a mis ça sur le fait qu'ils avaient trop de pression à relire un bout de code entourés de regards qui les jugent, du coup l'idée était de leur faire coder un truc tranquillement chez eux, sans pression, en conditions plus ou moins idéales. On aurait fait la revue ensuite.

        • [^] # Re: Mon expérience [mode trolldi=on]

          Posté par  (site web personnel) . Évalué à 5 (+4/-0).

          Exactement mon avis.
          Hors boilerplate et tuyauterie basique, écrire la spec de manière assez précise pour que le résultat soit correct et fonctionnel revient à écrire le code. Autant coder directement, non ?

          • [^] # Re: Mon expérience [mode trolldi=on]

            Posté par  (Mastodon) . Évalué à 10 (+7/-0).

            C'est un peu le grand fantasme qui date de plusieurs décennies: pouvoir programmer un ordinateur en langage naturel sans avoir à apprendre une syntaxe particulière.

            • [^] # Re: Mon expérience [mode trolldi=on]

              Posté par  . Évalué à 8 (+6/-0).

              J'ai un souvenir qui me revient.

              Années 1990, je suis au collège, une boutique de jeux vidéo d'occasion ouvre dans le quartier (pour situer, c'est l'époque ou Sega essaye de remplacer un hérisson bleu par un dauphin écologiste, ce qui n'a pas fonctionné du tout).

              Avec un pote on était assez bidouilleurs, et le patron du magasin avait un outil pour gérer son commerce, nommé QNR ou Q&R sur son PC, on aimait bien "jouer" avec.

              C'était un outil dans lequel on pouvait taper des instructions comme "affiche la liste des clients qui ont acheté aux moins 2 jeux ces 30 derniers jours". La vraie syntaxe était plus proche de "affiche clients avec achat > 2 et temps < 30 jours". Ça marchait un peu mais c'était moins pratique que DBase finalement. Assez vite, le gars est parti sur un logiciel de gestion plus classique.

              Autant dire qu'à cette époque, pouvoir poser une question presque en langage naturel, on se croyait dans K2000 :).

              (ce message est à purement à caractère historique^Wnostalgique et n'apporte rien à la conversation)

      • [^] # Re: Mon expérience

        Posté par  (site web personnel) . Évalué à 5 (+3/-0).

        « Je n'aime pas trop coder avec une LLM mais si tu donnes du contexte tu peux obtenir des trucs simple en décrivant bien pas à pas ce que tu peux obtenir. »

        Mon expérience de la marche est que sous découper un pas est effroyablement difficile :-). Comme je le disais, il s’agit d’à peine trois lignes de code. Mais j’ai tout de même vérifié que mes instructions étaient limpides. J’ai d’abord demandé la version avec boucle et test qui prend trois lignes. Je l’ai obtenue. Puis j’ai précisé qu’il me fallait une version compatible avec le type des données employées (donc sans boucle, et sans if), instruction parfaitement prise en compte également. Mais le modèle n’a jamais réussi à produire le code demandé. Merci pour la mauvaise foi…

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Que dire...

    Posté par  . Évalué à 3 (+0/-0).

    Si toutes les remarques que tu fais sont exacte :

    revois ton processus de dev.

    Le code généré se repère immédiatement: fonctions bien nommées, formatage impeccable, docstrings qui brillent, noms de variables trop précis, aucune variable a, b, x, tmp, out, typage strict des entrées et sorties etc. Un niveau de détail souvent trop fin,

    Un processus de relecture de code me semble indispensable; un nom de variable ne peut pas être 'trop' précis, quand au nommage ret, out, var_a_retourner, c'est au contraire super précis, c'est ce qu'on va renvoyer, comme la fonction doit tenir sur un écran maxi, on a même la description highlighté avec le nom de la fonction, et c'est facile à suivre.

    Pas de structure, fonctions fleuves de 100 lignes,

    là encore, relecture de code

    Quant au typage :

    l'inverse d'un code en cours d'écriture.

    Venant d'un monde où le typage statique est la norme, ça me parait la base de tout code, y compris en cours d'écriture.

    Certains codes écrits n'importe comment se repèrent au premier coup d'œil. C'est une alerte. Pas de structure, fonctions fleuves de 100 lignes, pas de séparation fond/forme. Un brouillon intégral. Et les brouillons doivent être réécrits.

    Relecture + chaine d'intégration avec sonar intégré, refus de merge en dessous d'une certaine note :)

    pas de séparation fond/forme.

    ça arrive aussi avec les llm, j'avais demandé un tableau en java, il m'a confondu le model avec la jtable, les deux étant intrinsèquement liés, alors quand j'ai demandé l'ajout des filtre ça a été une vraie boucherie, d'un code lisible quoi qu'un peu spaghetti, c'est devenu l'horreur. :)

    Il a d'ailleurs été incapable de séparer le tout, le code qu'il donnait était non compilable.

    Avec ce code aseptisé, je vais peut-être perdre du temps.

    Pas forcément pour la génération initiale, mais en un rien de temps ça peut devenir très moche :)

    Ensuite je ne lui ferai pas confiance sur le choix des technos, ou mécanismes à employer, elle aura une réponse de généré, mais pas forcément la meilleur, toujours sur le même projet je lui ai demandé d'écouter le presse papier (pour envoyer les donnée à un parseur, puis envoyer une notification d'update pour remplir la table)

    j'ai eu le droit à un scan périodique plutôt qu'un listener, pas de check de l'existence de la donnée avant de l'envoyer à la table, (en même temps une fois demandé, c'est l'id que l'ia avait décidé d'ajouter elle même a toute les lignes de la table (sans l'afficher) qu'elle a décider d'utiliser et non la variable du record appelé id dans les données…

    Bref décrire une fonction, pas de soucis, générer des données de tests, aucun problème (bon faut corriger à la main, mais ça fait gagner du temps), lui poser des question sur quelles solutions utiliser pour : "description du problème" top. Analyser des sortie d'erreur, la encore top.

    Bref de mon expérience faut la driver de très près, surveiller les errements, les corriger dès qu'ils surviennent même si le code à l'aire propre, ne pas hésiter a poser la question pourquoi t'as fais ça comme ça…

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Que dire...

      Posté par  (site web personnel) . Évalué à 3 (+2/-0).

      Je rajouterai :

      Il n'y a évidemment pas de tests. Rien à voir avec la génération. De toute façon il faudra tout reprendre pour intégrer un vrai dispositif de tests

      Il est possible de demander au LLM de générer les tests et même d'exiger 100% de couverture. Évidemment, comme pour le code, il faut aussi avoir un œil critique sur les tests : toutes les assertions générées ne sont pas pertinentes.

      Le code généré se repère immédiatement: […] formatage impeccable

      Il est plus simple de relire du code bien formaté, qu'il ait été produit par un humain ou un LLM. Il existe des outils pour le faire automatiquement dans un hook de precommit.

      • [^] # Re: Que dire...

        Posté par  . Évalué à 3 (+0/-0).

        Dans ma boite y'a un checkstyle d'activé, un poil chiant, mais au final tout le code à le même style, et c'est propre; j'avais aussi oublié de relevé ce point

        Il est possible de demander au LLM de générer les tests et même d'exiger 100% de couverture.

        J'ai pas mal utilisé aussi pour reprendre une base de code existante pour faire le gros des tests, le soucis c'est que le llm ne sait pas quels sont les points pertinents à tester, et parfois passe sur des morceaux de code inatteignable a grand coup de Mock (genre une exception qui ne peut pas arriver, mais qui doit être catché sinon le code ne compile pas)

        Il a aussi tendance a abuser des mock, et au final on ne teste que notre idée de l'implémentation.

        Bon au final ça fait gagner du temps, mais comme toujours faut relire et comprendre ce qui est fait, et avoir un oeil très critique

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Que dire...

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Ah il y a une légère incompréhension : je n'ai pas généré ce code, mais je le lis et je le subis. Mes remarques en découlent, et c'est ce que je constate sur n=1.

      De manière générale, je suis d'accord avec ce que tu écris : faut surveiller ce bot :)

      Je suis peut-être moins d'accord sur le typage, car je parle de code Python. Il y a des outils de typage qui sont utiles en analyse statique, certes, mais on (je?) ne s'attend pas à en voir sur une base de code proto et non testée.

      • [^] # Re: Que dire...

        Posté par  . Évalué à 5 (+2/-0).

        Il y a des outils de typage qui sont utiles en analyse statique, certes, mais on (je?) ne s'attend pas à en voir sur une base de code proto et non testée.

        J'ai fait du javascript qui souffre des même lacune, le projet est passé dans la douleur a typescript et ne reviendrait en arrière en aucune façon; si le python possède des mécanisme pour typer, je m'attends à ce qu'un projet complexe et prévu pour durer les utilises; les refactoring sont trop casse gueule sans ce genre d'outils.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Gain de temps ?

    Posté par  . Évalué à 4 (+2/-0).

    Cette génération propre permet également un gain de temps, on ne perd plus de temps avec les remarques sur la forme (taille des fonctions, structure du code, nom des variables, absence de commentaire…).

    Si le mauvais code ne peut plus se repérer aussi facilement, en quelques questions, on peut remarquer la personne qui a relu, critiqué, modifié et compris le code généré de la personne qui a pondu quelque chose sans réfléchir. Les questions "pourquoi avoir fait cela ?" et "pourquoi l'avoir fait comme cela ?" offrent des réponses très révélatrices.

    En résumé, est-ce que l'absence de remarque sur la forme ne permettrait pas de se concentrer sur le fond ?

    • [^] # Re: Gain de temps ?

      Posté par  (site web personnel) . Évalué à 1 (+0/-0).

      Ça peut.
      C'est exactement comme pour les textes classiques : formellement ça passe, mais le fond manque cruellement.

    • [^] # Re: Gain de temps ?

      Posté par  . Évalué à 2 (+0/-0).

      Cette génération propre permet également un gain de temps, on ne perd plus de temps avec les remarques sur la forme (taille des fonctions, structure du code, nom des variables, absence de commentaire…).

      Il y a des moyens plus simple d’y arriver avec un linter type blake.

      Si le mauvais code ne peut plus se repérer aussi facilement, en quelques questions, on peut remarquer la personne qui a relu, critiqué, modifié et compris le code généré de la personne qui a pondu quelque chose sans réfléchir. Les questions "pourquoi avoir fait cela ?" et "pourquoi l'avoir fait comme cela ?" offrent des réponses très révélatrices.

      Personnellement je me fou de savoir comment le code a était écrit. Que mon collègue applique TDD, TCR, qu’il ai fait une méditation avant, qu’il code dans un autre langage et transpile vers le notre ou utilise un LLM. Il y a son nom sur le commit, il doit avoir un bon niveau de confiance en ce qu’il soumet.

      En résumé, est-ce que l'absence de remarque sur la forme ne permettrait pas de se concentrer sur le fond ?

      En fait je trouve que ça demande de plus de travail à la relecture parce qu’avant tu avais des indices plus flagrant là où maintenant c’est plus subtil de repérer des problèmes qui des fois existaient déjà.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Gain de temps ?

        Posté par  . Évalué à 4 (+3/-0).

        Je subis du code Ansible écrit par des juniors chatgpt.

        C'est propre, ça fait juste ce qu'il faut sans déborder, ça ignore par contre le contexte global ou la façon dont les autres rôles avaient déjà été écrit, et parfois y'a des modules qui n'existent pas (pas encore il est en avance c'est le turfu).
        Du coup c'est cool on va vachement vite sur le JIRA, bon courage pour ceux qui suivront, les derniers qui s'en vont penseront à éteindre la lumière.

        • [^] # Re: Gain de temps ?

          Posté par  . Évalué à 3 (+1/-0).

          Du coup c'est cool on va vachement vite sur le JIRA, bon courage pour ceux qui suivront, les derniers qui s'en vont penseront à éteindre la lumière.

          Je suis pas particulièrement pro IA, mais ce que tu décrit est de l’accumulation de dette classico-classique. L’IA peut avoir tendance à en produire plus efficacement, mais le fait de ne pas intégrer l’essorage de la dette dans les tâches ou régulièrement ce n’est pas la faute de l’IA.

          Les LLM mettent ici en exergue des problèmes pré existant : les dev qui en ont rien à faire de la qualité de ce qu’ils produisent et/ou la hiérarchie qui ne donne pas le temps pour s’en occuper.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Gain de temps ?

            Posté par  (site web personnel) . Évalué à 2 (+1/-0).

            Les LLM mettent ici en exergue des problèmes pré existant : les dev qui en ont rien à faire de la qualité de ce qu’ils produisent et/ou la hiérarchie qui ne donne pas le temps pour s’en occuper.

            Amen.

            • [^] # Re: Gain de temps ?

              Posté par  . Évalué à 2 (+0/-0).

              Après pour être franc, s’ils vont plus vite pour avancer leurs tâches JIRA, je ai du mal à croire qu’il n’y a pas un problème côté dev pour de "definition of done" comme on dit où on pose en DONE des choses qui sont encore approximativement faites. C’est un comportement que j’ai surtout vu chez les juniors (que j’ai pu avoir d’ailleurs), une sorte de manque de perspective.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Gain de temps ?

        Posté par  . Évalué à 3 (+1/-0).

        Il y a des moyens plus simple d’y arriver avec un linter type blake.

        Je ne connais pas. Une recherche rapide m'oriente vers linter black pour Python. Ma connaissance sur le sujet est très limitée mais il y a peu de linters qui critiquent les noms de variables/fonctions. Les linters ne sont pas tous aussi bons dans tous les langages.

        Personnellement je me fou de savoir comment le code a était écrit. Que mon collègue applique TDD, TCR, qu’il ai fait une méditation avant, qu’il code dans un autre langage et transpile vers le notre ou utilise un LLM. Il y a son nom sur le commit, il doit avoir un bon niveau de confiance en ce qu’il soumet.

        Je ne partage pas cette facon d'aborder les choses, surtout pour des jeunes lorsque la relecture est aussi un moyen de transmettre des connaissances (dans les deux sens). Je peux apprendre de celui qui a écrit le code s'il y a des choses que je ne connaissais pas et je peux transmettre si mes remarques sont constructives. Alors oui, la reclecture de code, ce n'est pas toujours un échange constructif pendant lequel on peut apprendre, c'est souvent plus simplement pour améliorer le code et ne pas laisser d'erreur. Concernant la dernière phrase, je préfère un jeune développeur qui doute de lui qu'un jeune trop sûr de lui, je suis convaincu que l'un progressera plus vite que l'autre.

        En fait je trouve que ça demande de plus de travail à la relecture parce qu’avant tu avais des indices plus flagrant là où maintenant c’est plus subtil de repérer des problèmes qui des fois existaient déjà.

        C'était tout mon argument, si les problèmes détectés lors de la relecture de code sont grossiers, tu perds un peu ton temps. Certains problèmes grossiers doivent pouvoir être détectés avec linter, si la relecture consiste à trouver des problèmes qui pourraient être remontés par un linter ou un autre outil d'analyse statique, je pense que la relecture perd son intérêt. La relecture de code pour trouver des problèmes subtiles me parait très pertinente.

        • [^] # Re: Gain de temps ?

          Posté par  . Évalué à 2 (+0/-0).

          Je ne partage pas cette facon d'aborder les choses, surtout pour des jeunes lorsque la relecture est aussi un moyen de transmettre des connaissances (dans les deux sens). Je peux apprendre de celui qui a écrit le code s'il y a des choses que je ne connaissais pas et je peux transmettre si mes remarques sont constructives. Alors oui, la reclecture de code, ce n'est pas toujours un échange constructif pendant lequel on peut apprendre, c'est souvent plus simplement pour améliorer le code et ne pas laisser d'erreur.

          Je pense qu’il y a méprise. Je me fou de la méthode qui est utilisé pour produire le code. Quand tu soumet du code tu le fait en ton nom. Tu n’a pas à te dédouaner sur claude, gemini ou chatgpt.

          Concernant la dernière phrase, je préfère un jeune développeur qui doute de lui qu'un jeune trop sûr de lui, je suis convaincu que l'un progressera plus vite que l'autre.

          Je pense que l’incompréhension du paragraphe n’a pas aidé avec cette phrase mal écrite. J’attends à ce que quelqu’un qui soumet du code « own » ce code. Il peut l’avoir fait écrire par des outils, mais il a une compréhension de son code. Tu parle des jeunes dans le cas contraire il n’y aura jamais d’apprentissage

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Gain de temps ?

            Posté par  . Évalué à 3 (+1/-0).

            Effectivement, je n'avais pas compris le sens de ta pensée. Dans ce cas, je pense que nous avons des points de vue assez proches. Il n'est pas question de se dédouaner sur un outil. La compréhension du code produit, indépendamment des moyens, est nécessaire.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.