Bienvenue

VS Code : mettre en place un workflow d’ingénierie de contexte (instructions, agents, handoffs)

TL;DR #

  • Un assistant IA sans contexte n’est pas “bête” : il est aveugle. Et votre projet paie la facture (erreurs, tours de manège, décisions incohérentes).
  • L’ingénierie de contexte, ce n’est pas écrire de meilleurs prompts : c’est rendre le bon contexte disponible, au bon moment, de façon versionnée.
  • Dans VS Code, le workflow le plus robuste tient en 3 briques :
    1. instructions globales (.github/copilot-instructions.md)
    2. agent “Plan” (outils lecture seule) → produit un plan stable
    3. agent “Implementation” (édition + terminal) → exécute le plan
    • des handoffs pour passer de l’un à l’autre sans perdre le fil.

Lire la suite →

4 révélations qui vont transformer votre approche de la null-safety en Java (JSpecify + NullAway)

TL;DR #

  • JSpecify 1.0.0 met fin à la tour de Babel des @Nullable en standardisant 4 annotations stables.
  • @NullMarked inverse le défaut : non-null par défaut, @Nullable devient l’exception visible.
  • IDE et CI convergent : IntelliJ et NullAway se sont alignés (notamment sur les suppressions).
  • TYPE_USE rend la nullité “chirurgicale” (tableaux, génériques), mais il faut apprendre la grammaire.

Lire la suite →

La null-safety de Kotlin n’est pas de la magie — c’est un contrat écrit dans le bytecode

TL;DR #

La null-safety de Kotlin n’est pas une magie de l’IDE : c’est un contrat encodé dans le bytecode1. Le compilateur publie la nullabilité via @kotlin.Metadata et des annotations @NotNull/@Nullable, que l’IDE lit pour t’avertir23. Et si du code Java passe quand même null, Kotlin échoue immédiatement à la frontière avec Intrinsics.checkNotNullParameter(...), ce qui évite de propager un état corrompu plus profondément dans ton code.4

Lire la suite →

Kotlin ↔ Java : la null-safety, c’est un contrat (et comment Kotlin le fait respecter)

TL;DR #

En interop Kotlin ↔ Java, la null-safety n’est pas magique :

  • Kotlin→Java : le compilateur publie la nullabilité dans le bytecode (annotations @NotNull/@Nullable + @kotlin.Metadata), donc l’IDE voit le contrat.
  • Java→Kotlin : si Java passe quand même null là où Kotlin exige non-null, Kotlin fail-fast à la frontière via Intrinsics.checkNotNullParameter(...).
  • Le vrai point faible : quand Kotlin consomme des API Java non annotées → types “platform” (String!) = nullabilité inconnue → c’est là que les bugs se glissent.

Lire la suite →

AI & Java : passer des prompts au logiciel (vraiment) – mémoire, outils, JSON et Quarkus

Inspiré de la conf vJUG CONNECT “AI & Java: From Structured Prompts to Smarter Apps” (YouTube).

TL;DR #

Si tu retiens une seule idée : le “prompt engineering” n’est pas le sujet. Le sujet, c’est l’ingénierie du contexte et du contrat entre ton code et le modèle :

  • mémoire (court/long terme, cohérence, conflits),
  • outils (fonctions appelables par le LLM),
  • sorties structurées (JSON/records/enums au lieu de texte libre),
  • observabilité + timeouts + fallbacks (parce que “ça marche en démo” ne vaut rien en prod).

La conf le dit sans détour : ce n’est pas de la magie, c’est du logiciel.

Lire la suite →

«« « 1 2 3 » »»