Uncurieux a écrit :




C'est pas ultra-clair ce qui a été étudié. Est-ce que c'est plus clair dans le whitepaper?

En particulier, est-ce que c'est du code de librairie ou ça inclue du code de test? Est-ce qu'il s'agit de contributions sur des librairies open source par des contributeurs externes ou par les employés de l'entreprise en charge de la librairie?

A quel point c'est extrapolable au reste du monde?
Beaucoup de code est propriétaire. A quel point est-ce que c'est raisonnable de supposer que ce qui est visible dans l'Open Source s'étend au code propriétaire?

K a écrit :

> En particulier, est-ce que c'est du code de librairie ou ça inclue du code de test?

Il semble que ce soit global et inclue du code de test. Cela dit, je comprends assez mal en quoi ce serait un défaut de méthodologie ici, pour deux raisons :
- la répétition de code dans des tests est plutôt mauvais signe à mon avis : en particulier la recopie de code dans des librairies va mécaniquement créer des recopies dans les tests.
- tant que la méthodologie est consistante dans le temps (et ça semble l'être), la mesure garde du sens, sauf à montrer, par exemple, que les tests sont plus sensibles aux recopies que le code productif, et qu'il y a aussi beaucoup plus de tests qu'avant.

Tu peux trouver le white paper ici, la description des lignes utilisées est dans l'annexe A2. Ce que je comprends c'est que les données viennent uniquement de gitclear, avec toutes les lignes modifiées dans des projets non-anonymes, sans autre distinction. Les autres plateformes qu'ils mentionnent ne semblent pas proposer les informations qui leur servent.

> A quel point c'est extrapolable au reste du monde?

Difficile à dire, j'imagine. Mais cette évolution dans le temps interpelle en elle-même (en dépit de la faible durée de l'étude), et vient corroborer mon intuition et mon expérience de discussion avec des gens qui développent "avec AI".

Uncurieux a écrit :



Pas nécessairement. C'est une opinion subjective, mais il me semble préférable dans certains cas de dupliquer du code dans différents tests pour avoir des tests auto-contenus plutôt que d'avoir une grosse fonction avec de nombreux inputs qui fait de la magie.

Pour donner un exemple, supposons que je code une application web REST. J'ai un endpoint qui selon les inputs doit faire une ou deux opérations et renvoyer un certain résultat.

Je pourrais soit avoir:

test_1:
    inputs = ...
    expected_response = ...
    response = call_route_with_inputs(inputs)
    assert number_of_operations == 1
    assert response == expected_response

test_2:
    inputs = ...
    expected_response = ...
    response = call_route_with_inputs(inputs)
    assert number_of_operations == 2
    assert response == expected_response

ou

assertion_function(inputs, expected_number_of_operations, expected_response):
    response = call_route_with_inputs(inputs)
    assert number_of_operations == expected_number_of_operations
    assert response == expected_response


test_1:
    inputs = ...
    expected_response = ...
    assertion_function(inputs, 1, expected_reponse)

test_2:
     inputs = ...
    expected_response = ...
    assertion_function(inputs, 2, expected_reponse)

La première version a (très clairement) du code dupliqué, alors que la deuxième version est très bien factorisée.
Cependant la deuxième version est moins claire pour le développeur qui repassera sur ces tests ultérieurement. Elle est aussi moins claire pour certains outils de développement. Certains IDE (dont le mien ) ne sont pas capables d'aller voir dans assertion_function ce qu'il se passe, et montreront juste qu'il y a eu une erreur au moment d'appeler assertion_function. Là où quand les assertions sont faites dans le test, l'IDE gère beaucoup mieux ça.

Si mon exemple paraît simpliste (il n'y a qu'un appel de fonction et deux assertions), on peut facilement imaginer avoir des cas beaucoup plus compliqués (Je n'ai pas besoin de les imaginer, je les ai en vrai ).

Il se trouve que la boîte dans laquelle je travaille commence à intégrer l'IA et l'une des ses principales utilisations dans la codebase est justement de dupliquer des tests pour gérer un maximum de cas en limitant le temps passé par le développeur à écrire ces tests.

Et si, effectivement, du code de test se retrouve dupliqué, ce n'est pas nécessairement un problème ici.

D'ailleurs, le whitepaper évoque ça


Comme quoi je dis pas que des bêtises

K a écrit :

> Pas nécessairement. C'est une opinion subjective, mais il me semble préférable dans certains
> cas de dupliquer du code dans différents tests pour avoir des tests auto-contenus plutôt que
> d'avoir une grosse fonction avec de nombreux inputs qui fait de la magie.

Ok, je retire ce point. Il reste à expliquer l'inflation de duplication de code. Tu penses qu'il y a beaucoup plus de testing qu'avant ?

Pour ma part, je pense que l'explosion d'utilisation d'IA dans le codage de systèmes sera responsables de catastrophes numériques dans les années ou les décennies à venir (que ce soit à cause de slopsquatting ou autre chose), et que les entreprises qui les utilisent payeront (en défauts, en dette technique, ou en manque de formation de leurs devs) le fait d'avoir utilisé sans assez de recul ces technos.

Uncurieux a écrit :


Je ne sais pas.
Je pense que l'augmentation est trop significative pour être **juste** des tests.



Il me semble clair qu'utiliser l'IA sans supervision peut mener à des problèmes.
La partie "manque de formation de leurs devs" résonne en particulier avec moi, je suis assez outré par le manque de compréhension de la codebase chez certains de mes collègues, qui est au moins en partie dû à la dépendance à l'IA.

K a écrit :

Bha après le "problème" de l' "EY, Aye", c'est pour moi pas l'outil en lui même, mais le paradigme/la saucisse dans lequel celle-ci évolue, genre le progrès a vraiment bon dos koi. :v

Du coup à l'image de l'apparition du tracteur dans nos campagnes, c'est pas vraiment les gens, qui manquent de recul, mais bien qu'ils font exactement ce que le "système" attend d'eux et étant donné que les dés sont pipés dès le début, difficile de les blâmer.

Au final, le vrai miracle ce serait vraiment que tout ceci ne débouche pas sur des catastrophes.

Iska Rozen a écrit :

> Bha après le "problème" de l' "EY, Aye",
> c'est pour moi pas l'outil en lui même, mais le paradigme/la saucisse dans lequel celle-ci
> évolue, genre le progrès a vraiment bon dos koi. :v

Justement, je pense que la comparaison avec un tracteur atteint ici sa limite parce qu'autant j'arrive à imaginer un tracteur créé dans un système économique différent, autant les IA génératives sous la forme actuelle ne me semblent possibles que dans un système de late-stage capitalism. À la fois parce que c'est ce qui permet son existence, avec des petites mains sous-payées et délocalisées, à la fois parce que la techno n'est pas du tout viable, sauf en ce qu'elle permet de licencier par anticipation des gens (et alors que l'IA ne sait pas les remplacer, mais ça c'est secondaire).

Les IA génératives sont un sous-produit marketing de la création d'IA de délocalisations économique, que des boites peuvent se permettre d'offrir parce que ce n'est pas le vrai produit.

Uncurieux a écrit :

Bha, avec mon lien caché derrière le tracteur sur le remembrement, je pointais plus le fait, que c'était pas en soit le tracteur, qui avait conduit à un exil quasi forcé de la population, mais bien une politique nationale, qui a été imposé à un échelon locale, je dis ça parce que le tronc commun que l'on avait eu sur la révolution industriel réduisait ça juste à "des progrès techniques, qui réduisait le besoin de main d'oeuvre dans nos campagnes".

Mais après considérer que l'ia générative, serait un trait unique au "late-stage capitalism", je trouve que c'est aussi reducteur.

Genre j'ai découvert l'expression aujourd'hui "passer pour des peintres", en utilisant les premiers résultats de google l'origine ce serait soit "linkeldin", soit un journal qui sent bon la rose.

Bref peut être, que tu peux pas imaginer un gay futurisme communisme etc, mais c'est parce que dans le monde dans lequel on vit, le peintre, il peut pas rivaliser avec une machine, qui va générer 50 exemplaires en quelques seconde, puisqu'on est dans une optique purement pécuniaire de création.

Si le but, qui nous était imposé changeait, peut être qu'il nous sera possible de nouveau de rêver et donc on pourrait, enfin faire des trucs vachement bien avec cette "ia générative".