Nantes n'a jamais été en Bretagne 🔗
Une élue de la région Nantaise m'a récemment dit «Nantes n'a jamais été en Bretagne», phrase que j'ai entendu plusieurs fois depuis que j'ai déménage dans la région. Et si je vous disais que cette affirmation est à la fois parfaitement vraie et complètement fausse ?
Oui c'est vraie - Nantes n'a jamais été en "Bretagne", mais seulement depuis la création de régions administratives modernes, dont la Région Bretagne, en 1959. Avant cela, Bretagne voulait exclusivement dire la zone culturelle, géographique et politique de l'ouest de la France.
Read Full Post
Looking beyond code - AI for a beginner's mind 🔗
Most of the research on large language models (LLMs) suggests a familiar pattern: experts, already skilled in their field, benefit most from AI assistance. So I was surprised to come across a study in The Quarterly Journal of Economics that seems to show the opposite:
"Less skilled and less experienced workers improve significantly across all productivity measures, including a 30% increase in the number of issues resolved per hour... AI has little effect on the productivity of higher-skilled or more experienced workers"
Note that this finding comes from a very specific context: customer support for business software. Here, the AI was trained on the full archive of support calls, tasks are relatively uniform, and staff turnover is high. In that environment, AI not only boosted productivity but also reduced customer complaints and helped retain new employees. Still, the result raises a broader question: where might we benefit from this effect? Perhaps in any domain where we are thrown into unfamiliar work and the AI has access to rich, relevant training data.
The study also suggests a way forward: when novices follow AI recommendations closely, they not only become more productive in the moment but also retain those improvements when the AI support is removed. That’s encouraging — it hints that AI can be more than a crutch. Used well, it can help us build lasting skills and confidence, rather than leaving us permanently dependent on the machine.
What's in my Copilot instructions file, and why? 🔗
Following my article on adopting LLMs in a startup, I was asked about the GitHub Copilot instructions file I maintain for one of our core projects. I’d like to explain what’s in that file, why it’s structured the way it is, and how it differs from standard Python/Django agents guideline templates.
My team uses GitHub Copilot in 3 main ways in VSCode and JetBrains PyCharm:
- Autocomplete on steroids - the classic in-IDE use case.
- Copilot Chat / Edit - in-IDE discussions or targeted edits on specific files or sections
- Agentic coding - in a dedicated environment on GitHub or in the IDE
This file is used in Copilot Chat/Edit and in agentic coding sessions — not for raw autocomplete.
What’s in the file
My copilot instructions markdown file is a project overview — a map of the terrain rather than a rulebook. It gives LLMs, but also developers, the essential context to work productively without overloading the context window. It covers:
Read Full Post
Bookmark: The Technological Republic by Karp & Zamiska (2024) 🔗
A surprisingly engaging read, the authors set out a strong argument that Silicon Valley doesn't stand for much of any importance, followed by some rather fragmented arguments and opinions on what should be done about it.
Part 1 describes the current state of Silicon Valley as the authors see it, highlighting the reluctance of many tech firms to engage in military, policing or surveillance contracts. For me this highlights their refusal to engage with no real opposition or alternative. They seem to hanker for a stronger pro-American attitude from their big tech colleagues.
Read Full Post
Adopting LLMs in a startup 🔗
I have been gradually increasing my use of LLM tools since 2022 when I started experimenting with the preview version of GitHub Copilot before encouraging my team to try it out. But adopting AI tools effectively requires more than just signing up for ChatGPT or GitHub Copilot. From my own experience testing and deploying AI across different workflows alone and in a team, here are some practical lessons worth sharing.
1. Be Clear About Context and “Why”
AI works best when you don’t just tell it what to do, but also why. For example, instead of asking “write a sales pitch,” tell it what audience you’re targeting, what problem they have, and why your product solves it. This mirrors how we delegate tasks to humans: explaining the reasoning improves the output.
Read Full Post
Always say "Please", never say "Thank you" to your LLM 🔗
We've all been there – that moment when you catch yourself thanking your AI assistant. But could that simple 'thank you' could have more environmental impact than you think?
LLMs run on tokens - one token is roughly equivalent to one word so when you say 'please,' you're feeding 1 extra token into your request. In an average 3-turn conversation with an LLM the LLM will re-read that token 3 times, so that's a cost of 3 extra tokens in an exchange which probably includes many hundreds or thousands of tokens.
But when you say 'thank you,' the AI has to reprocess the entire conversation from start to finish, plus the extra "thank you", taking up significantly more resources. Where "Please" costs 3 tokens, "thank you" costs an extra api call with many hundreds of tokens.
Lets avoid "thank you" but with the new generation of AI tools having memory, saying 'please' can help the AI understand your personality and communication style better over time. Yin et al (2024) show us that it may give better results - but don't overdo it! Overly polite requests can degrade results.
OK so mind your Qs, please and thank you for reading!
Bookmark: System Design Interview: An Insider’s Guide by Alex Xu 🔗
A structured guide to approaching system design interview questions using real-world case studies and a repeatable framework—from scaling basics to designing complex systems.
Key Ideas / Takeaways
Alex Introduces a 4-step framework to tackle system design questions:
- Understand the problem and establish the scope
- Propose a high-level design and get buy-in from the interviewer
- Dive deep into chosen components
- Wrap up with optimizations, bottlenecks, and improvements
I found this really useful for demystifying the process and giving some structure to help tackle this kind of interview. The repetition helps to reinforce the process.
Read Full Post
Testing GitHub Copilot agent mode 🔗
I tested GitHub Copilot agent mode in July 2025, setting Copilot to work online on different sized features - the workflow looks like this:
- Chat with Copilot online - ask it to open a PR to work on a specific feature. Copilot starts working in its own virtual machine on GitHub.
- 30 minutes later I get an email saying the PR is ready for review - I read it online and ask for any corrections via github.com
- If and when I am happy with it I pull the branch to my PC, review, modify, fix, change.
- I push from my machine and merge to trunk
Some stats:
- 19 Pull requests opened against our main monorepo in 5 weeks.
- 7 merged
- 8 still open on the 31st of July (3 of those created on the final day)
- 3 closed unmerged because they clearly didn't work or were not worth finishing
- 1 closed because I reimplemented it more successfully on my dev PC
For example, I tasked Copilot with refactoring 3 instances of near-duplicate code into a common service and make some improvements to error handling on the refactored service. My experience of code review from the last 4 years definitely helps with this workflow - reviewing code from an agent is similar to reviewing colleagues' code except that I don't feel guilty about leaving a PR unread for more than a day. Those PRs still become stale however and merge conflicts are a pain if the agent changes overlap with other PRs.
One challenge is that this makes it very easy to set Copilot working on easy to define low-impact work but that work still takes to review. It would be easy to get into the habit of doing lots of unimportant busy work with this workflow. I now want to explore how to use coding agents to achieve more ambitious changes, perhaps changes I would not take on individually because they lie near the limits of my current knowledge.
Playing "In my bag..." with LLM agent templates 🔗
There's a memory game "In my bag..." where you pretend you have a list of things in your bag "In my bag I have a comb and a cat". The next person in the circle has to list all the same things and add one more at the end "In my bag I have a comb, a cat and a clock". The game ends when someone makes a mistake or gives up.
It occurred to me that this is a great analogy for the templates used in LLM chatbots! Every time you chat with an LLM the LLM re-reads the whole history of the conversation before responding. This is why they get slower over time, particularly if they are making web searches, viewing images, using MCPs or other tools which add a lot of hidden tokens to the chat history.
Feature flags Pt 3: Deploy to some of the people all of the time, and all of the people some of the time! 🔗
My talk from DjangoCon Europe 2025 - I discuss:
- What are Feature Flags ?
- Why use Feature Flags ?
- How Acernis uses Feature Flags
- Getting started with Feature Flags in Python and Django
