Pourquoi je crois moins aux LLMs pour le code
Au bout de 2 ans, j'écris plus de code de plomberie autour des LLMs que de code utile. Le serpent qui se mord la queue.
// 13 sujets · Machine learning, deep learning, LLMs
Au bout de 2 ans, j'écris plus de code de plomberie autour des LLMs que de code utile. Le serpent qui se mord la queue.
Pour les protos, game changer. Pour la prod, l'agent ne sait pas dire 'je sais pas'. À utiliser avec discernement.
Productivité +20% mais qualité du code -30%. J'écris plus vite mais je relis moins. Pas un trade-off que je veux.

API ergonomique, debug interactif, écosystème HF. TensorFlow est resté coincé en mode 'Google internal-first'.
Ollama + un petit loop tool-use. Gère mes mails, notes, todolist. C'est pas magique mais c'est utile.
Flux dev sur RTX 4090 fait des trucs incroyables. SDXL c'est plus rapide et tu peux entraîner des LoRA. Selon le use case.

LangChain trop magique. LangGraph mieux mais lourd. Pour 90% des cas, un loop while + JSON tool-call est suffisant.
Llama 4 70B sur 2x 4090, latence acceptable. Phi-4 sur un MacBook M3 pour du chat. On est à un cheveu du moment où on n'aura plus besoin du cloud.
Ollama : facile, mono-user. vLLM : production, throughput max. Pas le même outil, pas le même use case.

Mistral pour le pricing/local, Anthropic pour le code/reasoning, OpenAI pour la multimodalité. Plus de monopole, c'est sain.
Les deux. Fine-tune pour le style, RAG pour les faits. Complémentaire, pas concurrent.
Normalisation L2 obligatoire si cosine. Re-ranking après vector search. Et MTEB pour évaluer ton modèle, pas tes propres prompts.
Versioning models = comme code, monitoring drift = comme alerting, A/B = canary deploy. Arrêtez de vendre un nouveau métier.