Thoughts — Seven Mile

There are no lossless transformations of natural-language text

Mon, 14 Sep 2026 00:00:00 GMT

By PA

J’ai déjà eu l’expérience à plusieurs reprises : je passe un draft à Claude Code avec un système prompt que je trouve plutôt intéressant, l’output est plutôt bon, mais de temps en temps je ressens qu’il y a de l’implicite qui disparaît. Certaines de mes particularités disparaissent.

Cette citation met des mots sur ce constat : tout changement fait sur un message, un post LinkedIn, un article, change en réalité quelque chose.

C’est là où il faut qu’on accepte, qu’on définisse chacun quel degré de changement on veut faire, à quel point on veut garder notre implicite. Il y a une réflexion à avoir sur ce qu’on veut transmettre.

C’est là aussi où le brain va être important. Il va permettre à chacun d’avoir une part de son identité, de sa façon de parler, de sa façon de penser, représentée dans ce cerveau-là. Les changements faits par les IA sur les textes qu’on écrit vont donc de plus en plus nous ressembler.

Dans tous les cas, il faut toujours prendre le temps dans l’étape d’écriture. Si on partage un texte, un message, un article, un post LinkedIn, c’est parce qu’on veut partager notre façon de réfléchir. Ce n’est pas forcément le résultat qui importe, c’est le processus.

Plus haut dans le même texte :

Writing is thinking. Spending time on the writing process — on deciding what to emphasize and how to structure your ideas clearly — teaches you more about your topic. If you circumvent this process, you will probably walk away with a poorer understanding of the subject matter.

Je le remarque quand je prends le temps d’écrire individuellement sur un sujet complexe sur lequel je travaille : ça me permet de connecter tous les nœuds. En sortie de mes étapes d’écriture, j’ai une meilleure compréhension du sujet. Et cette compréhension renforcée par l’écriture fait que l’output de ce qu’on présente aux autres, de ce qu’on leur transmet, est meilleur.

Et surtout, ce n’est pas vraiment l’output qui compte. Sur des questions techniques, ce sont plutôt les étapes de réflexion. C’est toute la logique qu’on a derrière les ADR : voir comment on a processé l’information, comment on a processé le besoin, avant d’arriver à une solution X et pas une solution Y. Ce sont vraiment ces étapes de réflexion qui sont importantes. D’un, pour nous, pour continuer à entraîner notre cerveau, entraîner nos neurones. De deux, pour montrer à l’autre les différentes alternatives, et montrer qu’on a pris le temps de vraiment travailler le sujet avant de lui transmettre de l’information.

Slack CLI : configurer une app Slack sans passer par l’interface

Tue, 08 Sep 2026 00:00:00 GMT

By PA

J’étais en train de créer un bot Slack, et le travail s’est arrêté sur des étapes manuelles. Du clic-bouton, et des fois il faut fouiller dans toutes les configs Slack pour retrouver le bon réglage. C’est ce que je déteste le plus faire, et c’était la seule partie que je ne pouvais pas passer à mon harness. Alors je me suis dit : est-ce qu’il n’existe pas, par hasard, une CLI Slack ? Patatra, elle existe, et elle est top.

Une fois l’authentification faite, les manipulations qui vivaient dans l’interface deviennent des commandes : installer l’app, lire et valider son manifeste, ouvrir ses réglages.

slack login

Ce qui suit vient de slack help, avec slack v4.7.0, observé le 8 septembre 2026 :

app
  install    Install the app to a team
  settings   Open app settings for configurations
manifest
  diff       Show differences between the project manifest
             and app settings
  validate   Validate the app manifest generated by a project

Après le slack login, je n’exécute plus ces commandes moi-même : je dis à Claude Code d’utiliser la CLI. Je décris ce que l’app doit être, le harness passe par la CLI, et il n’y a plus grand chose de manuel dans la création d’un bot Slack ou dans les réglages qui demandaient du clickops avant.

Et voilà !

What is knowledge

Tue, 08 Sep 2026 00:00:00 GMT

By PA

Knowledge is of no value unless you put it into practice. — Anton Chekhov

In college, I took a course called IF15: Knowledge Engineering. That's when I heard the word ontology for the first time in my life. It would pop up occasionally in papers and articles I read, but I never took the time to dig deeper–I never felt the need, the necessity.

This term has come back in force over the past few months with the GenAI boom, and especially with the realization that agents need context. That context needs to be structured, organised in a way that helps them understand user vocabulary, company language, specificities, and connections between concepts. Agents need to understand what a request means in the company, and how to act on it.

This is where ontologies come in.

Originally, this article was just going to be an introduction to ontologies. Then I realized how irrelevant it would be to stay narrowly scoped on that single concept. So I reoriented the article toward knowledge in general–the broader picture.

The thread running through this article: how do we structure what we know so that both machines and humans can understand it?

This subject comes in four parts:

From raw data to usable knowledge, and the metadata in between (this post)
Structuring knowledge, from a list to a knowledge graph (draft)
Modelling knowledge for humans and for agents (draft)
Why classic RAG retrieves text instead of knowledge (draft)

Knowledge Definition from my IF15 course

The Triptych: Data → Information → Knowledge

Before talking about how to model knowledge, let's define what it is.

We generally distinguish three levels. Take a simple example of a support request:

Data: Raw facts, without context. 42, "blocked", "production".
Information: Contextualized data. "Request #42 reports that a customer is blocked in production."
Knowledge: Information usable for action or decision-making. "Our support procedure treats a customer blocked in production as urgent: escalate the request to the on-call team."

Knowledge is therefore information used in a given context to solve a problem or make a decision (thanks to my UTT course).

Knowledge Engineering

My IF15 course defined knowledge engineering as:

An approach that collects and structures reasoning. Its objective is to formalize problem-solving: the approach followed by one or more experts to solve a problem.

In other words: externalize the knowledge produced "in" and "for" a domain, and make it exploitable.

At the time, I found it very theoretical, almost boring. Today, with agents that need to understand a request, find relevant knowledge and use tools to carry out work, this discipline makes complete sense.

Knowledge and Metadata

An agent handling that support request needs to know what "blocked in production" means in the company, which procedure applies, and how to reach the on-call team. Some of that knowledge lives in documents, some in tools, and some still in people's heads.

Metadata describes those resources: what a document covers, who maintains it, when it was updated, or what a tool does and which inputs it expects. It helps an agent find and interpret what is available. The procedure itself carries knowledge about how to handle the situation; its owner and update date help establish where it comes from and whether it is still applicable.

To structure this context, we can look at both the domain and the systems through which an agent works.

Domain Knowledge (Business Knowledge)

This is what the business knows about its domain:

Business concepts and jargon: What is "churn"? "MRR"? A "qualified lead"?
Glossaries and definitions: How do we calculate revenue? Gross or net?
Acronyms and synonyms: WC = World Cup (Water Closet), ARR = Annualized Run Rate (Annual Recurring Rate), CMR = Cameroon (Carcinogenic Mutagenic Reprotoxic)
Rules and procedures: What makes a request urgent? Who handles it? When does a decision need approval?

Structural Knowledge (Technical Knowledge)

This is how the resources and tools fit together:

Relationships between elements: How is a support request connected to a customer, a service, or an incident?
Tools and dependencies: Which tool can update the request? What inputs does it need, and what happens when its status changes?
Provenance: Where does a piece of information come from? Has it been transformed or summarized along the way?

These two types of knowledge are complementary. Domain knowledge says "a customer blocked in production needs urgent escalation"; structural knowledge connects that rule to the request, the affected service and the tool used to contact the responsible team. The agent needs that connection to turn its understanding of the situation into an appropriate action.

In text-to-SQL, this connection maps business concepts to tables and columns. The same need extends to agents working with documents, APIs and workflows: connect what a request means to the resources and actions that can fulfil it.

Garbage In, Garbage Out

We all know this principle in Machine Learning: if your training data is bad, your model will be bad.

This principle also applies to GenAI and agents, through the context we give them to work with. That includes the information they retrieve, the rules they follow, and the metadata that describes their sources and tools.

If an agent retrieves an outdated escalation procedure, it may contact the wrong team. If a tool's description leaves out that changing a status also notifies the customer, the agent may take an action without understanding its consequences. Both the knowledge and its description matter.

Very often, companies rush directly into the AI layer, GenAI–either to follow the trend or because they think that's where the difficulty lies. But part of the difficulty is upstream: making the domain knowledge explicit, keeping procedures current, and describing the tools well enough for an agent to use them appropriately.

Investing heavily in sophisticated agents without investing in the knowledge they work with is an "éléphant aux pieds d'argile".

PA,

Next: Structuring knowledge, from a list to a knowledge graph (draft)

GitLab Stacked Merge Requests : empiler les merge requests plutôt que gonfler la même

Mon, 07 Sep 2026 00:00:00 GMT

By PA

Je viens de découvrir les stacked merge requests de GitLab (thks Claude Code 😂)

Le problème

Quand un travail avance vite – et il avance vite avec Claude Code – on a envie de faire plusieurs changements liés d’un coup. Ils finissent dans la même branche, et la MR arrive en revue avec des centaines de lignes qui mélangent trois ou quatre sujets. Personne ne relit ça sérieusement.

Ce que fait une pile

Au lieu d’une branche, on en ouvre plusieurs, presque unitaires, une par périmètre. Chaque MR cible non pas la branche par défaut mais la branche de la MR précédente. Seule celle du bas cible main.

Sur un travail récent, ça donne quatre MR, du bas vers le haut :

feat(stages) – l’étape d’entrée e0_prequalification et ses notes de préqualification, vers main ;
feat(candidates) – le owner, le membre du roster qui suit une candidature ;
feat(events) – l’annonce des mouvements d’entretien sur le bus ;
feat(slack) – la notification Slack au owner quand une candidature bouge.

GitLab affiche la pile dans l’en-tête de chaque MR (1 of 4) et rappelle la règle : le bas de la pile fusionne dans main en premier.

Ce que ça change à la revue

C’est là que la mécanique devient intéressante. Sans la pile, la quatrième MR aurait montré l’écart entre sa branche et main : tout le travail, quatre sujets empilés dans un seul diff. Avec la pile, elle ne montre que l’écart avec la branche juste en dessous – c’est-à-dire uniquement ce qu’elle ajoute.

Chaque MR répond donc à une seule question : qu’est-ce que cette étape apporte à la précédente ? Et la pile porte un ordre de lecture : on relit la première, on la fusionne, on passe à la suivante, qui vient poser sa couche par-dessus.

Un travail global reste condensé en un groupe de MR, mais chacune redevient relisable.

Le savoir ne grandit que s’il circule.

Sun, 06 Sep 2026 00:00:00 GMT

By Dom, PA, Reyan and Stano

Nous ouvrons ce blog avec une conviction : pour profiter durablement de l’IA, une entreprise doit faire circuler son savoir et le rendre utilisable par les personnes et les agents.

Ce carnet est une manière de commencer. Un apprentissage fait par une personne devient une ressource que d’autres peuvent comprendre, réutiliser.

L’IA en conditions réelles

Nous écrivons pour les ceux qui cherchent à comprendre les évolutions de l’IA et à les mettre en pratique dans leur entreprise. Ceux qui se demandent quelle stack choisir, comment faire évoluer leur cycle de développement, comment maîtriser les coûts ou comment transmettre une méthode à leur équipe.

Notre point de départ, ce sont ces questions. AWS, Anthropic, Mistral, Litellm, les agents et le context engineering sont des terrains d’exploration.

Des convictions qui peuvent évoluer

Le Shared Brain est un fil conducteur de notre réflexion : comment rendre les connaissances, l’histoire des projets et les méthodes de travail accessibles et utiles au collectif ?

Nous le considérons comme une capacité essentielle pour tirer parti de l’IA. C’est une conviction que nous voulons mettre à l’épreuve, en explorant par la même les usages, l’évaluation, les coûts et l’organisation du travail.

On partagera, ici, nos conviction, explorations et rex. Une conviction s’appuie sur un raisonnement. Une exploration laisse des questions ouvertes. Un retour d’expérience décrit un contexte, des résultats et des limites.

Une découverte mérite aussi sa place

Vous trouverez ici trois formes de publication :

Des articles pour développer une implémentation, une méthode ou un point de vue.
Des TIL pour partager une découverte, même petite, même évidente pour quelqu’un d’autre.
Des liens commentés (Quotes) pour faire circuler une lecture et expliquer pourquoi elle nous intéresse.

La longueur dépend de ce qu’il faut pour transmettre l’idée. Une note utile vaut aussi la peine d’être publiée.

Des voix individuelles, un apprentissage collectif

Chaque auteur conserve sa voix, sa langue et son jugement. Un consultant peut discuter une conviction de Seven Mile, proposer une autre approche ou changer d’avis.

Notre exigence commune : partager quelque chose d’utile, préciser ses limites et donner du crédit aux personnes dont nous apprenons.

Bienvenue dans notre carnet collectif.

Publier ce que l’on apprend, même quand ce n'est pas révolutionnaire.

Fri, 04 Sep 2026 00:00:00 GMT

By PA

Deux points de départ suffisent : écrire sur ce qu’on vient d’apprendre, raconter ce qu’on construit.

Le format TIL nous parle particulièrement. Il annonce une découverte personnelle, sans promettre un tutoriel exhaustif ou une idée jamais publiée ailleurs. Même une notion simple peut mériter une note.

Nous voulons reprendre cette liberté dans ce blog collectif. Une personne apprend quelque chose, le signe et le partage. D’autres peuvent s’en servir, le compléter ou poser une question. C’est déjà une manière de faire circuler le savoir.

Enjoy: sevenmile.tech/thoughts?format=link