Pour changer véritablement la donne de l’UI/UX, il faudrait aussi que les plateformes tentent de s’affranchir du form factor du téléphone ou du moniteur.
Quel langage de programmation s’accorde le mieux avec les agents de codage ?
En tant que développeur backend utilisant principalement Java & Kotlin et Spring, j’ai souvent l’impression que Cursor est assez frustrant à l’usage...
Je refactorise actuellement une ancienne application React vers Astro.
L’article met l’accent sur le « contexte intégré ». Le « contexte intégré » aide à créer rapidement un service, mais il faut savoir qu’il peut devenir une dette technique un jour.
Du point de vue de la maintenance à long terme du service, un « couplage lâche entre modules indépendants » vaut mieux qu’un « couplage fort intégré ».
Et Astro est justement le framework le plus flexible pour cela.
L’expérience consistant à « discuter » avec un LLM ressemble un peu à l’usage d’un terminal informatique des années 80. Le GUI (interface utilisateur graphique) n’a pas encore été inventé, mais je pense que certaines de ses caractéristiques sont déjà prévisibles.
Ce sera visuel (comme les GUI d’autrefois). Car l’information visuelle (photos, graphiques, animations, etc. — voir plutôt que lire) est comme une autoroute à 10 voies vers le cerveau. La vision offre la plus grande bande passante d’entrée d’information, et environ un tiers du traitement cérébral est consacré au traitement visuel.
Ce sera génératif et variable selon les conditions d’entrée. Autrement dit, l’interface graphique sera générée en temps réel en fonction du prompt de l’utilisateur, et chaque élément existera et sera agencé pour son objectif immédiat.
La question un peu plus ouverte concerne le degré de caractère « procédural ». À une extrémité, on peut imaginer un unique immense diffusion model produisant tout le canevas de sortie d’un seul coup ; à l’autre, une page remplie de composants React générés de manière procédurale (par ex. images, graphiques, animations, diagrammes, etc.). À mon avis, ce sera un mélange des deux, mais le second constituera l’ossature de base.
Mais ce dont je suis déjà certain, c’est qu’à mesure que les capacités se rapprocheront de l’infini, un GUI sous forme de canevas 2D interactif, fluide, magique et éphémère deviendra sa forme finale. Et je pense que cela commence déjà lentement (par ex. blocs de code/surlignage, blocs LaTeX, gras/italique/listes/tableaux en Markdown, emoji, et de manière plus ambitieuse les onglets Artifacts, les diagrammes Mermaid ou des applications plus complètes). Bien sûr, tout cela reste encore à un stade très initial et rudimentaire.
Iron Man, et dans une certaine mesure Star Trek / Minority Report, peuvent être considérés comme de bons exemples, dans la culture populaire, de l’orientation de cette IA/UI.
Tout à fait d'accord
De toute façon, même en MBA, on ne fait que des études de cas.
Quoi qu'il en soit, il y a des limites à ce qu'on peut faire derrière un bureau.
Si le LLM lui-même peut modifier le système de prompt, il faudrait aussi que les humains définissent les règles de cette politique ; au final, il ne restera peut-être plus que quelque chose comme les trois lois de la robotique.
On peut aussi joindre un lien de page web ou un lien YouTube, et le résumé s’affiche également en texte. Regardez la partie ajout des sources.
On peut aussi faire des demandes via un prompt.
LaTeX : si on l’exécute via une image Docker, on n’obtient pas une vitesse comparable à celle de typst.
Google Docs : étonnamment, l’édition n’est pas si flexible que ça.
En prenant ces deux points en compte, cela devient une nouvelle option intéressante.
J’avais beaucoup cherché s’il n’existait pas un plugin pour aider neovim à faire de l’autocomplétion au niveau de Cursor, mais il semble que cela n’ait été possible que grâce à leur propre modèle...
J’utilise au quotidien Cline avec Antrophic (ou QWEN) et Github Copilot Code Completion. Si la fonction de Code Completion (complétion par tabulation) de Cline fonctionne vraiment correctement, je pense qu’il n’y aura plus de raison d’utiliser Copilot. Je me suis habitué à Plan&Act avant même l’Agent de Copilot, donc j’utilise peu l’Agent, mais je l’essaie volontairement en ce moment pour faire la comparaison. Un autre avantage de Cline, c’est qu’il permet aussi d’utiliser des LLM distincts.
En complément, si une exécution quotidienne unique suffit, il y a aussi CloudType ; pour monter un serveur vraiment léger avec Node, Cafe24 (500 wons par mois) ; et pour le déploiement de sites statiques, Netlify, Cloudflare, etc. 🙇♂️
Pour changer véritablement la donne de l’UI/UX, il faudrait aussi que les plateformes tentent de s’affranchir du form factor du téléphone ou du moniteur.
Quel langage de programmation s’accorde le mieux avec les agents de codage ?
En tant que développeur backend utilisant principalement Java & Kotlin et Spring, j’ai souvent l’impression que Cursor est assez frustrant à l’usage...
Je refactorise actuellement une ancienne application React vers Astro.
L’article met l’accent sur le « contexte intégré ». Le « contexte intégré » aide à créer rapidement un service, mais il faut savoir qu’il peut devenir une dette technique un jour.
Du point de vue de la maintenance à long terme du service, un « couplage lâche entre modules indépendants » vaut mieux qu’un « couplage fort intégré ».
Et Astro est justement le framework le plus flexible pour cela.
C’est clair haha
https://x.com/karpathy/status/1917920257257459899
Comparer aussi avec l’avis d’Andrej Karpathy me semble intéressant.
L’expérience consistant à « discuter » avec un LLM ressemble un peu à l’usage d’un terminal informatique des années 80. Le GUI (interface utilisateur graphique) n’a pas encore été inventé, mais je pense que certaines de ses caractéristiques sont déjà prévisibles.
Ce sera visuel (comme les GUI d’autrefois). Car l’information visuelle (photos, graphiques, animations, etc. — voir plutôt que lire) est comme une autoroute à 10 voies vers le cerveau. La vision offre la plus grande bande passante d’entrée d’information, et environ un tiers du traitement cérébral est consacré au traitement visuel.
Ce sera génératif et variable selon les conditions d’entrée. Autrement dit, l’interface graphique sera générée en temps réel en fonction du prompt de l’utilisateur, et chaque élément existera et sera agencé pour son objectif immédiat.
La question un peu plus ouverte concerne le degré de caractère « procédural ». À une extrémité, on peut imaginer un unique immense diffusion model produisant tout le canevas de sortie d’un seul coup ; à l’autre, une page remplie de composants React générés de manière procédurale (par ex. images, graphiques, animations, diagrammes, etc.). À mon avis, ce sera un mélange des deux, mais le second constituera l’ossature de base.
Mais ce dont je suis déjà certain, c’est qu’à mesure que les capacités se rapprocheront de l’infini, un GUI sous forme de canevas 2D interactif, fluide, magique et éphémère deviendra sa forme finale. Et je pense que cela commence déjà lentement (par ex. blocs de code/surlignage, blocs LaTeX, gras/italique/listes/tableaux en Markdown, emoji, et de manière plus ambitieuse les onglets Artifacts, les diagrammes Mermaid ou des applications plus complètes). Bien sûr, tout cela reste encore à un stade très initial et rudimentaire.
Iron Man, et dans une certaine mesure Star Trek / Minority Report, peuvent être considérés comme de bons exemples, dans la culture populaire, de l’orientation de cette IA/UI.
Cline était payant ? Ce n’est pas gratuit ?
Des véhicules définis par logiciel, centrés sur le matériel
Tout à fait d'accord
De toute façon, même en MBA, on ne fait que des études de cas.
Quoi qu'il en soit, il y a des limites à ce qu'on peut faire derrière un bureau.
« Botox » lol, il m’a fallu un moment pour comprendre ce que ça voulait dire lol
C’est sympa
J’espère qu’une époque sans frontières arrivera vite
Si le LLM lui-même peut modifier le système de prompt, il faudrait aussi que les humains définissent les règles de cette politique ; au final, il ne restera peut-être plus que quelque chose comme les trois lois de la robotique.
Anthropic publie le « système de prompt » qui fait fonctionner Claude
Le système de prompt publié directement est de petite taille. Il semble que la partie liée aux outils en ait été retirée.
Waouh, une vie de nomade semble donc possible en Mongolie !
On peut aussi joindre un lien de page web ou un lien YouTube, et le résumé s’affiche également en texte. Regardez la partie ajout des sources.
On peut aussi faire des demandes via un prompt.
Waouh...
À bien y réfléchir, même si je passe parfois sur HackerNews, ça fait vraiment très longtemps que je ne vais plus directement sur TechCrunch.
typstest un logiciel qui a déjà été présenté plusieurs fois, mais je ne pensais pas qu’on pouvait l’utiliser pour ce genre d’usage.LaTeX : si on l’exécute via une image Docker, on n’obtient pas une vitesse comparable à celle de
typst.Google Docs : étonnamment, l’édition n’est pas si flexible que ça.
En prenant ces deux points en compte, cela devient une nouvelle option intéressante.
J’avais beaucoup cherché s’il n’existait pas un plugin pour aider
neovimà faire de l’autocomplétion au niveau de Cursor, mais il semble que cela n’ait été possible que grâce à leur propre modèle...J’utilise au quotidien Cline avec Antrophic (ou QWEN) et Github Copilot Code Completion. Si la fonction de Code Completion (complétion par tabulation) de Cline fonctionne vraiment correctement, je pense qu’il n’y aura plus de raison d’utiliser Copilot. Je me suis habitué à Plan&Act avant même l’Agent de Copilot, donc j’utilise peu l’Agent, mais je l’essaie volontairement en ce moment pour faire la comparaison. Un autre avantage de Cline, c’est qu’il permet aussi d’utiliser des LLM distincts.
Référence : https://x.com/addyosmani/status/1886316192136310838
En complément, si une exécution quotidienne unique suffit, il y a aussi CloudType ; pour monter un serveur vraiment léger avec Node, Cafe24 (500 wons par mois) ; et pour le déploiement de sites statiques, Netlify, Cloudflare, etc. 🙇♂️
Merci 👏