Discussion :

[Maubius]

Bonjour
Je poste ici car l'impact de l'IA varie en fonction du langage, et j'aurai aimé connaitre l'impact sur la communauté C en particulier.
Sur des forums généralistes, je lis souvent que les devs n'ont aujourd'hui plus besoin de programmer.
Quand j'ai demandé "L'IA va-t-elle remplacer les devs" on m'a répondu: "ta question a 3 ans de retard hein, elle a déjà remplacé 90% des devs. Perso ça fait 6 mois que je ne code plus".

Qu'en est il réellement? Avez vous senti un changement notable? Le métier de développeur C est il mort?
J'ai une formation en développement et j'ai toujours rêvé de faire du C, mais voir ce qui se trame me rend perplexe sur mon futur métier...

Merci de votre attention

[LittleWhite]

Bonjour,

Le métier a changé, c'est certain. Je veux dire, beaucoup de développeurs code moins et utilise l'IA pour générer du code. Toutefois, là où c'est intéressant, c'est lorsque les développeurs générant du code de cette façon relise le code et sont en mesure de comprendre l'impact du code et comment il s'intègre avec le reste du projet. Autrement dit, on parle de développeur expérimenté en mesure de valider ce que ferait l'IA. Bref, ils sont passés d'une casquette de développeur à une casquette de lead. Ils vont demander à générer le code, le relire, peut être le modifier à la main ou demander à l'IA de le modifier. Bref, un processus proche d'un lead qui aurait un stagiaire à disposition.
Toutefois, l'IA a aussi ses limites. Il y a des domaines que l'IA maîtrise moins (l'embarqué, moteur de jeux vidéo (à cause de la grande complexité des systèmes (grand besoin de performances, support de plusieurs plateformes qui ne sont peut être pas visible dans les données d’entraînement) et l'interconnexion entre les différents modules avec haute parallélisation), des technos moins utilisés). Aussi, il faut comprendre le coût. Une IA peut générer du code qui ne compile pas et devra compiler le projet afin de valider les modifications. Cela brûle des tokens.
Est-ce que le métier de développeur est t-il mort ? Non, je ne crois pas. Il suffit de voir les offres d'emploi sur LinkedIn. Le métier a juste évolué et nous avons un nouveau outil d'autocomplétion beaucoup plus puissant maintenant. Il est possible de lui faire générer du code, un petit projet complet, mais il reste qu'il faut beaucoup de connaissance pour le supporter et pour faire en sorte que le projet soit viable sur le moyen et long terme. Car, au bout de six mois de génération de code, lorsqu'il faudra modifier un morceau du logiciel, ajouter une fonctionnalité et que personne ne connaît le code et que l'IA empile les solutions "fonctionnels" mais bancales, alors il arrive qu'à un moment, cela coince.

[fred1599]

Hello,

En ce qui me concerne, au taf, c'est juste un assitant de productivité, C++ (différent de C et C# attention) ou autres langages, même fonctionnement...

Les problématiques que j'y ai rencontrées :
- répétition de codes (on oublie le principe DRY)
- interprétation abusive, délire... (principe YAGNI qui dégage)
- gestion du traceback quasi inexistante
- code souvent en version de langage obsolète
- ne maîtrise pas l'environnement

Le gros avantage, je développe beaucoup plus vite les tests unitaires, etc...

Donc, non, se fier à la réponse de l'IA risque de poser problème à terme sur votre projet s'il est assez important niveau taille, le développeur a encore des beaux jours devant lui, mais il doit s'adapter !

[Artemus24]

Salut à tous.

Que ce soit avec ou sans l'IA, il y a quand même un gros problème chez les développeurs, maitriser ce que l'on fait.
Même dans des développements où l'on ne demande pas une extrême expertise, on voit de ses aberrations.
Je prends l'exemple classique où dans la boucle la plus interne, on vient à interroger une base de données pour récupérer une information.
Sachant en plus que cette information se compte en quelques dizaines de valeurs, il y a une absence totale de stockage en mémoire.
Chaque nouvelle interrogation provoque un accès à la base de données, même si la même valeur a déjà été lu précédemment.
C'est un exemple, mais il y en a pleins comme ça, qui démontre que même avec l'IA, le niveau de programmation va baisser.

Gagner du temps avec l'IA, oui, je suis d'accord.
Avoir une application performante, je crains que cela ne soit plus du tout le cas dans l'avenir.

[alex5956]

Salut à tous.

Que ce soit avec ou sans l'IA, il y a quand même un gros problème chez les développeurs, maitriser ce que l'on fait.
Même dans des développements où l'on ne demande pas une extrême expertise, on voit de ses aberrations.
Je prends l'exemple classique où dans la boucle la plus interne, on vient à interroger une base de données pour récupérer une information.
Sachant en plus que cette information se compte en quelques dizaines de valeurs, il y a une absence totale de stockage en mémoire.
Chaque nouvelle interrogation provoque un accès à la base de données, même si la même valeur a déjà été lu précédemment.
C'est un exemple, mais il y en a pleins comme ça, qui démontre que même avec l'IA, le niveau de programmation va baisser.

Gagner du temps avec l'IA, oui, je suis d'accord.
Avoir une application performante, je crains que cela ne soit plus du tout le cas dans l'avenir.

sûr ???à ce point ?!!

[Obsidian]

Sachant en plus que cette information se compte en quelques dizaines de valeurs, il y a une absence totale de stockage en mémoire.
Chaque nouvelle interrogation provoque un accès à la base de données, même si la même valeur a déjà été lu précédemment.

Ça c'est un autre problème : la délégation au système d'exploitation, qui elle peut être tout-à-fait légitime. Si l'OS ou les bibliothèques sous-jacentes au programme gèrent elles-mêmes un cache efficace, alors il peut être pertinent d'en faire abstraction dans la boucle. Mais évidemment, on ne sait jamais si c'est « volontaire » ou non. Je mets les guillemets parce qu'il est difficile de parler de volonté en matière d'IA, contrairement au programmeur humain chez qui la question est au contraire prépondérante.

C'est un exemple, mais il y en a pleins comme ça, qui démontre que même avec l'IA, le niveau de programmation va baisser.

Tout va baisser drastiquement. La décadence au sens large est l'un des plus grands dangers pour une civilisation, devant même la guerre, à mon avis. Et cela va être d'autant plus critique que cela va être un cercle vicieux. On va être forcé à en devenir dépendant et il n'y aura pas de retour en arrière ensuite.

[Artemus24]

sûr ???à ce point ?!!

Ce n'est pas l'outil qui pose problème mais le fait de bien savoir s'en servir. C'est une question d'acceptation et ensuite de la maitrise de l'outil.
Tout comme le marteau, qui quand tu sais bien t'en servir te permet d'enfoncer des clous et non de te taper sur les doigts.

@ Obsidian : Le but de l'IA est de répondre à une demande formulé par le prompt. Il ne cherche pas à résoudre le problème d'une manière intelligente car il n'a pas la vue total du projet. J'avais un petit problème de gestion de jeux de caractères entre la page Web en HTML, Javascript et un script PHP. L'IA s'est entêté à me donné une solution coté Javascript, alors qu'il existe une fonction toute simple résolvant mon problème coté PHP.

Je suis d'accord sur ta conclusion, mais nous sommes dans un entre deux, où si tu préfères, un changement d'époque et il y aura nécessairement de la casse. Après, ce n'est plus la même histoire car tout le monde se servira de l'IA tous les jours. Il faut accepter ce changement sinon on sera à la traine, voir totalement exclu.

J'ai exactement le même genre de problème avec le fait que je n'ai pas de téléphone portable. Pour l'instant, ça va, mais il arrivera un moment où je serai obligé d'en prendre un. Par "un", j'entends un mobile (sans internet) et non un smartphone (avec internet).

[Guesset]

Bonjour,

L'IA ne peut imaginer des codes originaux avec, par exemple, un nouvel algorithme, car ce sont des modèles conservateurs au sens où ils re-moulinent des acquis, certes très nombreux, sans une once de nouveauté.

Le problème est que nombre de programmes n'ont pas besoin d'une grande originalité. Pour ceux-là, l'IA sera une bonne solution quand elle fournira des programmes testés et non juste assemblés à la glu. Il faudra quand même vérifier que la réponse fonctionnelle est correcte. Cependant, cela tuera toute la période d'apprentissage indispensable avant d'être capable de faire un code original. D'où viendront alors les nouveaux codes ?

C'est comme avec un grand sac de milliards de billes de toutes les couleurs sauf une. On peut les secouer, les mélanger, la couleur qui manque ne sortira jamais. Il faudra que quelqu'un crée la nouvelle bille de la couleur absente.

Quant à la dépendance aux outils et environnements, ce n'est pas un nouveau problème. S'appuyer sur leur intelligence pour légitimer un code très moyen me paraît assez faible.
Reprenons l'exemple de la boucle interne qui fait une requête systématique. L'existence d'un cache va certes diminuer l'effondrement de performances, mais ne va pas rendre le programme optimal. D'autant si le cache est au niveau d'une base de données réseau : on évite les requêtes, mais pas les temps réseaux et les indirections. L'idée de créer un cache local au programme est sans conteste une meilleure solution. Cependant, dans le cadre de boucles imbriquées, il peut être intéressant de remanier l'ordre des boucles (pour une dizaine de valeurs différentes, on peut supposer - sans certitude - un argument simple qui pourrait se trouver dans une boucle plus externe).

C'est la même chose avec le potentiel d'optimisation des compilateurs. Écrire un code sous-optimal en supposant que le compilateur va rectifier le tir me semble hasardeux. Cela créé une dépendance au compilateur préjudiciable. Quand un nouveau CPU apparaît, les compilateurs marquent un temps de retard avant de reprendre les optimisations de leurs prédécesseurs.

L'approche suivie est de faire comme si les optimisations de l'environnement n'existaient pas et d'essayer d'écrire le code optimal. Les gains des outils sont alors des bonus que j'accueille comme tels. Je me suis ainsi aperçu que les opérations binaires (donc niveau bit) étaient parfois mal maîtrisées et que certains préféraient pousser les optimisations en O3 pour que le compilateur s'en occupe. C'est comme le refus de l'assembleur sous prétexte que tout compilateur fera mieux, ce qui est vrai seulement si l'assembleur n'est qu'une transcription linéaire d'un code de niveau supérieur.

La recherche du vite fait, s'abstrayant des matériels, trouve un nouveau support avec l'IA. Qui blâmer ?

Salutations

[henderson]

Il faut toujours vérifier !
Il y a quelques temps, j'ai récupéré le code du drum de RISSET.
En fait, le code fourni est tel que RISSET l'expliquait mais pas tel qu'il était codé.
Il s'agit en particulier du timbre du drum obtenu par synthèse additive de 6 fréquences : la fondamentale + 5 inharmoniques.
C'est donné sous la forme d'une boucle alors qu'on a intérêt à développer la somme.
En effet, pour un seul échantillon, une boucle semble parfaite mais pour 96000 échantillons (1 seconde chez moi) et plus ... c'est autant de temps perdu par la boucle !
On peut toujours se dire (et espérer) que le compilateur va optimiser...