Chris Shiflett décrit la création d’un serveur MCP (Model Context Protocol) pour son laboratoire personnel, un espace où il centralise ses projets et outils maison. Il explique comment il a rationalisé son répertoire ~/local, autrefois encombré de projets inaboutis, en relançant des outils comme Landice, Faculty ou Schoolcase, tout en adoptant progressivement l’IA malgré ses réticences initiales. Son approche progressive avec l’IA, passant de simple référence à collaborateur, l’a conduit à voir cette technologie comme un "robot" capable d’exécuter du code, bien que des limites persistent, comme l’interface de Claude ou la perte de contexte entre conversations.

Shiflett souligne deux obstacles majeurs dans son utilisation de l’IA : d’abord, l’asymétrie entre l’exécution manuelle du code et l’approche automatisée de Claude Code, qui réduit sa participation active. Ensuite, le manque de mémoire des assistants, obligeant à résumer manuellement l’historique des échanges dans des fichiers Markdown avant de recommencer une conversation. Ces contraintes l’ont poussé à concevoir un serveur MCP pour mieux contrôler l’interaction avec l’IA et intégrer ses outils existants.

L’objectif final est de fluidifier ce processus en créant une interface unifiée, où l’IA agit comme un véritable partenaire de développement plutôt qu’un simple exécutant. Ce projet reflète sa volonté de concilier innovation technologique et méthodes de travail personnelles, tout en résolvant les frictions rencontrées dans l’adoption de l’IA.

L’article propose une version optimisée de l’utilisation de PostgreSQL pour remplacer Redis, en corrigeant les erreurs d’une précédente publication. L’auteur souligne l’importance des valeurs par défaut dans PostgreSQL 18, comme les fonctions uuidv4() ou uuidv7() pour les identifiants, ou encore la génération automatique des dates d’expiration via des intervalles, simplifiant ainsi les opérations côté client. Il met aussi en avant l’utilisation de RETURNING pour récupérer les valeurs générées directement lors de l’insertion, évitant des requêtes supplémentaires.

L’auteur critique l’héritage de tables, une fonctionnalité de PostgreSQL souvent mal comprise, car les index ne sont pas hérités, ce qui peut impacter gravement les performances. Il illustre ce problème avec un exemple comparant une table classique et une table héritée, montrant que l’absence d’index sur la table parente rend les requêtes coûteuses, même sur de grandes volumétries (25 millions d’entrées).

Enfin, l’article aborde brièvement l’utilisation des index, recommandant d’éviter les index inutiles qui alourdissent les opérations d’écriture. L’auteur conclut en insistant sur l’importance de bien comprendre les mécanismes de PostgreSQL pour éviter des erreurs de conception coûteuses en performance.

L’auteur explique comment Domain-Driven Design (DDD) a révolutionné sa vision de l’architecture logicielle, notamment pour les agents IA. Après des années de routine en développement, il découvre ce concept en lisant Domain-Driven Design d’Eric Evans, ce qui transforme sa manière d’aborder la complexité des systèmes. Son expérience précédente avec des microservices mal conçus, où les services manquaient de sens métier, l’a poussé à chercher une approche plus structurée.

Le livre l’a confronté à une réflexion approfondie sur la modélisation du domaine, où chaque détail (noms de classes, relations, effets de bord) devient crucial. Cette approche l’a ramené aux fondamentaux de la programmation orientée objet, avec une attention accrue à la clarté et à la cohérence du code. Il souligne que DDD a comblé un vide entre le développement et la compréhension du métier, contrairement à sa vision initiale où ces deux aspects étaient dissociés.