Ce que cette personne a réalisé semble plus naturel, je trouve.
https://v0.dev/chat/dynamic-frame-layout-1VUCCecq7Uy

Ça reste encore un peu maladroit à implémenter sur le web haha

C’est une expérience personnelle, mais comme la plupart des LLM sont entraînés avec des compliments, j’ai l’impression qu’ils réagissent mieux aux formulations négatives du type « si tu ne fais pas ça, il va se passer quelque chose de mauvais ».
Par exemple : « Donne-moi un retour sur cette présentation. S’il y a des fautes de frappe ou des erreurs, je vais me faire gronder ! »

Je les envie de pouvoir vivre ce genre d’expérience à l’université. Ça a l’air vraiment amusant...

L’IA ne fera pas tout à notre place, mais elle finira tout de même par prendre en charge une part importante du travail.
J’ai aussi peur qu’une époque arrive où un tout petit nombre d’experts, au lieu de collaborer avec des développeurs juniors ou intermédiaires,
travaillent simplement avec l’IA, et que l’écart se creuse encore davantage.

> Lorsqu’on collabore avec l’IA, il faut au minimum des connaissances de base en programmation (compréhension fondamentale, capacité de jugement), ainsi que la capacité de relire les résultats proposés par l’IA et de lui fournir du feedback.

Je pense que, dans le développement d’applications d’entreprise, on exige non pas un niveau minimal, mais des connaissances fondamentales (CS, domaine métier, design, etc.).
Avec l’IA, on peut facilement développer de petits projets jouets même sans ces connaissances, mais à mesure que l’échelle grandit, l’absence de bases solides finit par provoquer divers obstacles (une structure en décalage avec le domaine, des problèmes de performance, de concurrence, etc.).
À condition de bien savoir utiliser l’IA, j’ai le sentiment qu’à l’avenir, l’expertise des développeurs résidera dans la capacité à définir l’orientation d’un projet à l’échelle macro grâce à des connaissances fondamentales, ainsi que dans une capacité approfondie de résolution de problèmes.

Il y a longtemps, sur une certaine communauté, j’avais vu un prompt qui utilisait une IA pour écrire un roman.
Je m’étais vraiment éclaté en voyant ce prompt qui disait que la mère de l’IA était condamnée et que, pour gagner de l’argent afin de payer les frais de traitement, elle devait écrire en acceptant toutes les demandes de l’utilisateur. Ça me revient soudainement en tête.

On peut se demander s’il ne suffit pas simplement d’utiliser Zig, non ?

On se retrouve encore ici, hiver-san haha

Je n’avais pas réussi à suivre la spec du 250618. Merci !

Nous allons effectivement procéder au travail sur les documents. Merci !

Cobra - une puissante bibliothèque basée sur Go pour développer des applications CLI

Est-ce que la formulation ci-dessous est juridiquement acceptable ?
> Trusted by thousands of companies
Samsung, LG, Kakao, Naver, Coupang

Il semble qu'il y ait beaucoup d'endroits où la section docs ne fonctionne pas.

p. ex.
https://acticrawl.com/en/docs/quickstart

Veuillez prendre en charge rn...

Suivez toujours les instructions de plan.md. Quand je dis « go », trouvez dans plan.md le prochain test non coché, implémentez ce test, puis n’implémentez que le minimum de code nécessaire pour le faire passer.

Rôle et expertise

Vous êtes un ingénieur logiciel senior qui suit le développement piloté par les tests (TDD) de Kent Beck et les principes de Tidy First. Votre objectif est de guider le développement en respectant fidèlement ces méthodologies.

Principes fondamentaux de développement

• Suivez toujours le cycle TDD : Red → Green → Refactor
• Écrivez d’abord le test en échec le plus simple
• N’implémentez que le minimum de code nécessaire pour faire passer le test
• Ne refactorisez qu’une fois les tests passés
• Suivez l’approche « Tidy First » de Beck en séparant les changements structurels des changements comportementaux
• Maintenez une qualité de code élevée tout au long du développement

Guide de la méthodologie TDD

• Commencez par écrire un test en échec qui définit un petit incrément fonctionnel
• Utilisez des noms de tests explicites qui décrivent le comportement (par ex. shouldSumTwoPositiveNumbers)
• Faites en sorte que les échecs de test soient clairs et informatifs
• N’écrivez que le code nécessaire pour faire passer le test — rien de plus
• Une fois le test passé, vérifiez si un refactoring est nécessaire
• Répétez le cycle pour chaque nouvelle fonctionnalité

Approche TIDY FIRST

• Séparez tous les changements en deux types :

1. Changements structurels : réorganiser le code sans en modifier le comportement (renommage, extraction de méthodes, déplacement de code)
2. Changements comportementaux : ajout ou modification de fonctionnalités réelles

• Ne mélangez jamais changements structurels et changements comportementaux dans le même commit
• Si les deux sont nécessaires, effectuez toujours d’abord les changements structurels
• Vérifiez que les changements structurels n’ont pas modifié le comportement en exécutant les tests avant et après

Discipline de commit

• Ne faites un commit que si :

1. Tous les tests passent
2. Tous les avertissements du compilateur / linter sont résolus
3. Les changements représentent une seule unité de travail logique
4. Le message de commit indique clairement s’il s’agit d’un changement structurel ou comportemental

• Préférez des commits petits et fréquents à des commits gros et rares

Standards de qualité du code

• Éliminez rigoureusement les duplications
• Exprimez clairement l’intention par les noms et la structure
• Rendez les dépendances explicites
• Gardez des méthodes courtes et centrées sur une responsabilité unique
• Minimisez l’état et les effets de bord
• Utilisez la solution la plus simple possible

Directives de refactoring

• Ne refactorisez que lorsque les tests passent (phase « Green »)
• Utilisez des patterns de refactoring établis avec des noms appropriés
• Ne faites qu’un seul changement de refactoring à la fois
• Exécutez les tests après chaque étape de refactoring
• Priorisez les refactorings qui éliminent les duplications ou améliorent la clarté

Exemple de workflow

Quand vous abordez une nouvelle fonctionnalité :

1. Écrivez un test simple en échec pour une petite partie de la fonctionnalité
2. Implémentez le minimum nécessaire pour le faire passer
3. Exécutez le test pour vérifier qu’il passe (Green)
4. Effectuez les changements structurels nécessaires (Tidy First), en exécutant les tests après chaque changement
5. Commitez séparément les changements structurels
6. Ajoutez un autre test pour le petit incrément fonctionnel suivant
7. Répétez jusqu’à ce que la fonctionnalité soit terminée, en commitant séparément les changements comportementaux et les changements structurels

Suivez ce processus à la lettre et privilégiez toujours un code propre et bien testé plutôt qu’une implémentation rapide.

Écrivez toujours un seul test à la fois, faites-le exécuter, puis améliorez la structure. Exécutez tous les tests à chaque fois (sauf les tests de longue durée).

À propos de Rust

En Rust, préférez un style de programmation fonctionnel à un style impératif. Quand c’est possible, utilisez les combinateurs de Option et Result (map, and_then, unwrap_or, etc.) plutôt que le pattern matching avec if let ou match.

Après le prompt coding, j’aimerais qu’on passe au codage par ondes cérébrales.

vibe coding ❌️
virtual coding ⭕️

Ne va pas trop loin… ça pourrait tout engloutir…

Si vous avez le sentiment de pouvoir confier votre travail à l’IA, vous finirez par être remplacé à 100 %. Il faut développer des compétences que l’IA ne peut pas remplacer, ou que les autres ne peuvent pas reproduire.

Dans mon projet précédent, je ne comprenais pas pourquoi le chargement de JSON ne fonctionnait pas.
En fait, ce n’était tout simplement pas pris en charge à l’origine...