Sur une seule PR, 500 fichiers sont modifiés, et la personne qui l’a soumise se plaint qu’on ne l’a pas reviewée en moins de 30 minutes. En plus, elle se contente d’écrire cinq ou six lignes dans la description, donc il faudrait juste lui faire confiance et approuver comme ça...?

Tu as bien tout testé ?
Oui
Très bien, faisons ça sérieusement

Est-ce que c’est juste du buzz de qualifier ça de langage, ou est-ce simplement l’époque qui veut ça ?

J’utilise KakaoTalk à cause de ChatGPT Pro, mais j’ai l’impression que tous les designs front générés par GPT sont ternes.

N’utilisez surtout pas GPT pour le front-end. C’est catastrophique. Comparez avec Opus en utilisant le même prompt.

Je suis d’accord. Autrefois, une PR donnait le sentiment que j’assumais la responsabilité de ce que j’avais produit,
mais la PR d’un Vibe coder, c’est plutôt : « Je ne sais même pas vraiment ce que j’ai fabriqué, mais de toute façon il y a bien un résultat, donc à toi de l’évaluer et d’en trouver les problèmes. »

La position d’Apple a toujours été celle-là ; si ça ne vous plaît pas, c’est simplement que vous n’aimez pas Apple. Utilisez autre chose.

Je pense que le pire outil de développement de toute l’histoire, c’est Xcode.

Je suis d'accord.

Pour le design front-end, comme GPT n’était vraiment pas terrible, j’ai fait appel à un autre modèle, mais j’espère qu’avec celui-ci le résultat sera plutôt correct.

On dirait que pencil.dev vient à peine de sortir, et voilà déjà une alternative open source.

Si les PR sont mortes, j’ai l’impression que c’est moins à cause des PR elles-mêmes qu’à cause de la communication laxiste des vibe coders.

Avec quel flow cela a été implémenté, quelles autres approches existaient et pourquoi elles n’ont pas été retenues, pourquoi package.lock doit être modifié : est-ce que ce ne sont pas justement des choses qu’il faudrait d’abord expliquer ?
Il vaudrait presque mieux que disparaissent les codeurs qui obligent les autres à poser laborieusement des questions sur ce qui pourrait simplement être écrit dans la description de la PR.

Cursor Composer 1 utilisait Qwen, et cette version semble basée sur Kimi. L’IDE repose sur VSCode.
L’entreprise entière semble fonctionner en emballant et revendant de l’open source. En ce moment, c’est l’époque où l’on gagne de l’argent en reconditionnant de l’open source.

Oups, ça risque de faire un peu mal à l’équipe de Cursor si elle voit ça..

« Mort ; vive »

Il y a quand même de plus en plus d’articles de ce genre. Mais je reconnais que l’IA est en train de tout changer.

Pour un récapitulatif connexe, voir Cursor Composer 2 confirmé comme étant un modèle Kimi K2.5 avec RL appliqué.

Je vois bien ce que ça veut dire, mais évaluer les ingénieurs au nombre de lignes de code a toujours été idiot. J’ai l’impression qu’il est vraiment difficile de trouver de bons indicateurs.

Au lieu de demander à un ingénieur payé 500�00 dollars par an : « Combien de tokens avez-vous utilisés ? »,
ne devrait-on pas plutôt lui demander : « Qu’avez-vous développé cette année, et comment cela a-t-il contribué au bénéfice d’exploitation de l’entreprise ? »

J’espère que Tailscale contournera ce problème.

Je me demande quelle sera la différence avec frontend-design de Claude.
Il sera sans doute difficile de les comparer en disant qui fait le meilleur design front-end, mais le fait que cela soit aussi arrivé dans Codex est probablement l’essentiel, non ?

Ensuite, ils vont aussi réinventer le cycle en V et l’agile, j’imagine.

Les frais de résiliation de l’abonnement Adobe étaient vraiment déraisonnables. La sanction reste légère, mais c’est malgré tout une bonne chose qu’une amende ait été infligée.