pas idiot du tout, débat très intéressant au contraire!
C'est le problème éternel du niveau sémantique.
Le besoin du client n'est pas complètement traduit pas dans le code. Le LLM va être très bon pour décrire la logique du code (ca marche déjà très bien et c'est bien intégré dans vscode et autre).
Mais pour le reste il va inventer, et si le code est faux, il va se tromper.
Même la conception du logiciel n'est pas complètement traduite dans le code. Je prends un exemple qui provient du README du projet sur lequel j'utilise justement bbt pour faire les tests, acc : si le concepteur définit un logiciel en couches, couche C1 avec les modules A et B au dessus d'une couche C2 avec les modules C et D, le code n'embarque pas cette sémantique.
Le LLM verra dans le code qu'il y a un include de C dans A, de D dans C, mais il ne verra pas forcément qu'il y a une architecture en couche.
Parce que, en changeant de niveau sémantique, il y a perte d'information.
Si on laisse les LLM faire ce qui nous amuse, c'est à dire le code, alors je pense qu'il est plus efficace de procéder dans l'autre sens : il vaut mieux générer le code à partir d'une description du besoin plutôt que de lui demander de reconstituer le besoin à partir du code.
[^] # Re: Solution très (trop?) moderne?
Posté par Lionel Draghi (site web personnel) . En réponse au journal Documenter ou tester, il faut trancher (j'ai pas trouvé de rime avec choisir...). Évalué à 2. Dernière modification le 06 février 2025 à 14:40.
pas idiot du tout, débat très intéressant au contraire!
C'est le problème éternel du niveau sémantique.
Le besoin du client n'est pas complètement traduit pas dans le code. Le LLM va être très bon pour décrire la logique du code (ca marche déjà très bien et c'est bien intégré dans vscode et autre).
Mais pour le reste il va inventer, et si le code est faux, il va se tromper.
Même la conception du logiciel n'est pas complètement traduite dans le code. Je prends un exemple qui provient du README du projet sur lequel j'utilise justement bbt pour faire les tests, acc : si le concepteur définit un logiciel en couches, couche C1 avec les modules A et B au dessus d'une couche C2 avec les modules C et D, le code n'embarque pas cette sémantique.
Le LLM verra dans le code qu'il y a un include de C dans A, de D dans C, mais il ne verra pas forcément qu'il y a une architecture en couche.
Parce que, en changeant de niveau sémantique, il y a perte d'information.
Si on laisse les LLM faire ce qui nous amuse, c'est à dire le code, alors je pense qu'il est plus efficace de procéder dans l'autre sens : il vaut mieux générer le code à partir d'une description du besoin plutôt que de lui demander de reconstituer le besoin à partir du code.