Every few weeks someone sends me a newsletter with a subject line like “Everything you need to know about AI in 2026.” I always read it. I’m always mildly disappointed. Not because the content is bad — it usually isn’t — but because the field moves faster than any monthly synthesis can capture.
Simon Willison figured this out early. The co-creator of Django and founder of Datasette has been writing publicly about AI since before most engineering teams had an AI strategy. His blog, simonwillison.net, has quietly become required reading inside several Silicon Valley engineering organizations. He doesn’t do this by being smarter than everyone else. He does it with a system.
This post breaks down that system, what I’ve adapted from it, and how to apply it specifically if you’re a Tech Lead writing in Vietnamese and English.
The Core Insight: You Write to Think, Not to Publish
Most people think of blogging or note-taking as a form of publishing — you learn something, you write it up, you share it. Willison inverts this. Writing is how he processes and retains what he encounters. The published artifact is a side effect, not the goal.
This sounds like a small reframe. It changes everything about how you approach learning.
When publishing is the goal, you wait until you understand something well enough to explain it authoritatively. That threshold is high, which means you write rarely and only about things you already know deeply. The field moves on while you wait.
When processing is the goal, you write the moment you encounter something interesting, even if you only half-understand it. The act of writing forces you to identify exactly what you understood and where your understanding breaks down. You publish the gap, not just the mastery. Readers who are in the same stage of understanding find that more useful than a polished tutorial written by someone who finished learning six months ago.
Willison calls his micro-posts “TIL” entries — “Today I Learned.” A TIL is not an essay. It’s a paragraph or two capturing exactly one thing: what he found, where he found it, what surprised him, and what he still doesn’t know. He publishes them daily. Not because every day has a profound discovery, but because the discipline of looking for TIL-worthy moments makes him pay attention differently.
The Five Habits
1. Daily TIL notes — even when you think it’s trivial
The bar for a TIL is very low. “I didn’t know you could do X” is a complete entry. Willison has published TILs about git flags, Python tricks, and API quirks that took him thirty seconds to write. The value isn’t any individual entry; it’s the searchable archive of 800+ entries that builds up over years and becomes a personal reference library.
For Tech Leads: start a private Obsidian vault with a single til/ folder. Date each file. Write one paragraph. Publish selectively; the drafts don’t need to go anywhere until you want them to.
2. Weekly synthesis — the newsletter-for-yourself format
Every week, Willison writes a longer post that synthesizes what he’s been reading and experimenting with. This is different from a TIL: it connects dots across multiple discoveries and tries to articulate what they mean collectively. The synthesis forces him to actually process the week rather than scroll past it.
The format is simple: two or three observations from the week’s reading, with a “so what” sentence at the end of each. The discipline of finding the “so what” is where the real learning happens. If you can’t state the implication of something you read, you don’t actually understand it yet.
3. Public experimentation log — commits and notebooks as writing
Willison’s GitHub is active. He doesn’t just write about tools; he builds small experiments, writes up what he found, and links to the code. This matters for Tech Leads because it is the most credible form of learning: “I ran this experiment, here’s what happened” is fundamentally different from “I read that this is how it works.”
The code doesn’t need to be good. The experiments can be trivial. A Jupyter notebook that tests whether GPT-4o’s function calling behaves differently with one versus three examples is a legitimate experiment worth logging.
4. Teach-to-learn: explaining to your team
Willison gives talks. A lot of them. In February 2026 he spoke at The Pragmatic Summit on “Engineering practices that make coding agents work.” The talk wasn’t based on theory — it was built from the experiments and TIL entries he’d been writing for months. His preparation for the talk was largely already done because he’d been writing in public.
For Tech Leads, the analog is the team meeting. If you’ve been doing TIL notes and weekly synthesis, you have material for a fifteen-minute “what I’ve been learning about AI” slot at your next architecture review. The act of preparing to explain it to your team is where you discover what you actually believe and what you’re still uncertain about.
5. Curated RSS over social media
Willison reads blogs via RSS, not social media. This is deliberate. RSS is asynchronous, doesn’t optimize for outrage or viral content, and lets him subscribe directly to the people he’s found most useful over time rather than to whoever the algorithm is surfacing today.
His reading list includes a mix of practitioner blogs (people doing AI engineering work), researcher blogs (people publishing findings), and a few general tech observers. Social media gets a brief daily scan for announcements, not for learning.
What He Learned About Coding Agents (And What It Means For Your Team)
In 2026, Willison published his “Agentic Engineering Patterns” guide — the clearest distillation I’ve seen of what actually works when using tools like Claude Code in professional engineering contexts. His key distinction:
“Agentic Engineering represents the other end of the scale from vibe coding: professional software engineers using coding agents to improve and accelerate their work by amplifying their existing expertise.”
Two observations from that guide matter for Tech Leads:
First, the key skill going forward is designing the loop, not polishing the prompt. When you’re clear enough about success criteria that you can write a script to check them, you’re ready to hand the task to an agent. If you’re not clear yet, no amount of prompt refinement will fix that.
Second, safety requires sandboxing. Willison is explicit: run agents in isolation (GitHub Codespaces, Docker containers) with network access restricted. This isn’t just about security from external threats — it’s about preventing the agent from making irreversible changes to infrastructure while you’re not watching.
Both of these observations came from experiments he ran, wrote about, and published before turning them into guidance. The method produces the insight.
The Vietnamese + English Leverage Play
Here’s what’s specific to your context as a Vietnamese engineer: the writing habit gives you compounding advantages in both language communities, but you have to be intentional about it.
In Vietnamese: the AI engineering writing community in Vietnam is still thin. There are good technical writers, but almost nobody publishing at the level of synthesis and original experiment that Willison does in English. If you write consistently in Vietnamese about what you’re actually doing and learning, you become one of the most knowledgeable voices in your local community within twelve to eighteen months.
In English: your English writing demonstrates two things simultaneously — technical depth and the ability to communicate it precisely. For an APAC Tech Lead, that’s a differentiator in any global conversation, job application, or conference proposal.
The practical approach: write in Vietnamese first. Vietnamese is your native thinking language; you’ll be faster and more precise. Then translate to English, which also forces you to check whether your explanation would make sense to someone without your specific context. The translation step is editorial work, not just conversion.
Tool stack that works:
- Obsidian for private daily notes and TIL drafts. Use the Daily Notes plugin for automatic date-based files. Keep a
til/folder and aweekly/folder. Don’t worry about organization until the vault has 200+ notes. - Your public blog for synthesis posts — the ones that connect dots across multiple TILs and have a clear “so what.” Not every TIL needs to be public; filter for the ones where you found something counterintuitive or that you would have wanted to find when you were learning it.
- GitHub for experiment logs. A repository called
ai-experimentswith one folder per experiment is enough. The README of each folder is your write-up.
Starting Simple
The mistake is starting with a system. Willison didn’t build his TIL practice by designing it; he started by writing down one thing he’d learned, then another. The system emerged from the habit.
Start here: tomorrow, after you’ve read something about AI that surprised you or that you didn’t know, write one paragraph about it. Title it with the date. Save it somewhere you can find it again. That’s the whole system for the first week.
The compounding happens when you look back at a folder of 50 TIL entries three months later and realize you can actually synthesize them — because you wrote them down instead of letting them scroll past.
The AI field is genuinely hard to stay current in. But “hard to stay current in” doesn’t mean the only strategy is to consume more, faster. Willison’s method says: consume more slowly, with a pen in your hand. The people who will matter in AI engineering in 2027 are not the ones who read the most; they’re the ones who thought carefully about what they read and can articulate why it matters.
That articulation — in Vietnamese, in English, for your team, for your blog — is the skill worth developing right now.
Further reading: