Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Shilin typing
Lately I've had a lot of time for thinking. Partially because I shut down Blymp back in January and freed up a lot of my mental resources. No clients to follow up with. No admin stuff to stress about. But thinking is also my favourite activity, and there'll always be time in my day for a good old mind-bending. So I sat down, as I often do, alone with my thoughts, and wrote about what business I should and, most importantly, should not consider doing next. The list you are about to read might be similar to Core principles I (try to) live by that I wrote one similarly pensive evening two years ago. Whether it's a comparison or a continuation is hard to say—still, one can't be without the other to show the inexorable passage of time that changed everything and nothing for me all at once. But it also serves another purpose: to remind me in the future, before I get myself involved in some dubious enterprise, what painful mistake I'm about to make by ignoring my values. So here it is, the list. My next business shouldn't (and hopefully won't) be about: Social Media. Enough of this crap. Some productivity bullshit. Do better, not more. Fast fashion and consumerism. Truly, I've already bought everything you wanted to sell me. Some “hack your health” app. Our bodies haven't changed much in the last three hundred thousand years, and they won't change in the next hundred. Or any other app, really. I don't even use my phone anymore. Distracting things and things that require constant attention. Some LLM wrapper with a fancy UI. Indefensible. The number of things I can do with ChatGPT or Claude is ridiculously high. It can surely handle one more thing. What it should (and hopefully will) be about: Sustainable, high-quality products Unscented products Building community Bringing people together, offline Empowering creativity Replacing animal products Doing one thing really damn well Small acts of kindness Things you can touch Things that last Clothes made of natural fibres Art Fun Questioning the status quo Simple, intentional living Deeper understanding of self Spending more time in nature Spending more time with loved ones Things and businesses I get inspired by: Framework: Sustainable/repairable laptops. Bitwarden: Open-source software that does one job really well and charges me a reasonable amount of money per year. Danish design: Beautiful. Sturdy. Timeless. I brought home two Royal Copenhagen mugs the other day. Bike-sharing and car-sharing. Literally anything-sharing. ZSA keyboards. What a keyboard should have always been. A water bottle that won't leak on a plane. Some random-brand bottle bricked my friend's MacBook, and I've been appreciative ever since of the fifty-dollar water bottle that I bought years ago, so hesitant about the price. Coffee. One of those timeless things on Earth. Kobo. It's like Kindle that doesn't decide what's best for you. Upload your own PDF. Or EPUB—whatever. It has physical buttons to flip pages. Best $200 I ever spent. A high-quality safety razor. It's just so nice to hold. A Japanese stainless-steel knife. So nice to hold, too. There are numerous other things that I appreciate having in my life that didn't make it into this list for some reason or another. A familiar mom-and-pop shop in my neighbourhood. A Timemore Black Mirror kitchen scale that just works, every time. A random USB-C charged electronic device that spares me from carrying an extra cable. My radically outdated ten-dollar Casio watch. An old pair of comfy shoes that just won't die. We need more of this in our lives. Things that you desperately look to buy again when they get lost or break or fall apart. Things that someone made a deliberate effort to get right the first time. The quintessence of art and craftsmanship. For all the genius of Steve Jobs, the iPhone wasn't that. It challenged the status quo and was surely a groundbreaking, outstanding piece of technology at the time of its first release. But in twenty years, people won't remember it ever existed. Like Gen Z doesn't remember the Walkman. I'd like to see more businesses that bet on doing one thing really well. Google could still have been the company people remembered for the best search engine if they had doubled down solely on that. Instead, we don't even know what they do anymore: Phones? Clouds? Ads? Certainly ads. I still remember the feeling of holding one of the first PocketBook e-readers in my hands back in Moscow. Pressing its buttons and waiting for what now seems like a torturous three seconds before the screen refreshed. Almost twenty years later and every day still, Kobo gives me exactly that feeling. So hopefully, my next business is the one that lasts.
When I first met Pierre, I couldn't have foreseen what the next three years of our friendship would be like. I had just come back to Montreal. Twice I'd failed to get a place in Toronto. My dream of traveling in a van had also fallen apart. So I rented a U-Haul and went to pick up my furniture from a storage unit. Pierre helped me unload it at the coliving house he had just started up. For Pierre's birthday in February, I made a short film from our first trip together. We found what we mistakenly thought was Crown land and went there to camp. I brought my camera along. I had no intention of filming anything. I was looking to get away, and so was Pierre. The most memorable thing wasn't getting kicked out of someone's private lake, even though I can hardly forget that. It was the chat at the campfire the night before. We talked about our worries and our hopes. About what would become of us. The meaning of it all. Girls, too, obviously. That campfire was where our friendship truly began. I hope the film speaks better than my words can. I love you, Pierre. I wish you the best.
Yesterday, I traded sun, beach, and a beautiful warm sea for a cold, gray sky and a pair of wet shoes. I still can't believe I did it. The constant winter overcast was reason enough to leave Canada and never look back. When I finally left, I had bought a ticket to a never-ending summer. It felt magical. Yet I am here in the cold again, and I couldn't be happier with my choice. I arrived in Marseille this morning. Dressed in light pants and a summer shirt, flip-flops on my bare feet, I stepped out of the airport. Cold rain got under my collar and ran down my spine. I held my small backpack over my head and ran to the bus station. There I bought a ticket to Aix-en-Provence. After four years of waiting, my France chapter has finally begun. I could, perhaps, write about this weird obsession that I’ve had with France for the last four years. About the language, que j’adore. The petit café I had this afternoon followed by a risotto served with the freshest baguette, as if it were the only way to serve risotto. But I’ll keep my message simple: don’t stop dreaming. It's not about some bucket list with three hundred items in it. Nor New Year's resolutions that you regret telling everyone about. But a childish, almost feverish “What if one day I…” sort of dream. Something that you are ashamed to dream of, perhaps because it's so silly or so trivial that you don't know why you should even bother. But you dream nonetheless simply because you can. I remember my first such dream. Back in school, I watched Sean Penn's Into the Wild. I'd never wanted to go to Alaska. And it didn’t seem realistic, living on the opposite side of the world. But it had planted a seed in the back of my mind until more than ten years later I landed in Fairbanks. And today, arriving in Aix, another itch got its long-deserved scratch. I walked into a grocery store and listened to the radio that reminded me of my favorite Café Montréalais on Spotify. I strolled the narrow cobblestone streets and pretended I was the main character of a new episode of Dix pour cent, filmed in Provence for a reason known only to me. It was a dream. But then again, I was living it. Be a fool. Dare to have foolish dreams. They might, after all, come true.
On December 31, I went to Wat Suan Mokkh in Thailand and registered for a ten-day silent retreat. I scribbled these notes on eight scraps of paper given to us for questions on days six and ten. Neither electronics nor diaries were allowed for “creative writing”. And because my writing isn't that creative anyway, here we go: Day -1 Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10 Day 11 -- P.S. A ten-day retreat somehow turned into a two-week-long adventure and will likely take a year to process. But what an experience it was!
More in startups
The explanation is so simple that it’s almost funny.
One problem with AI is that it’s pretty stupid. I mean, sure, the current models are wildly useful. But out of the box, they overcomplicate, take undue shortcuts, and compound deficiencies to the moon. To get from default Claude or ChatGPT to a fast, affordable software loop – one that reliably zaps bugs, backlog items, and security vulnerabilities in your product in particular – it takes some real work. Increasingly, this is the work. So it’s past time you shared that work with your team. Guidelines and guardrails There are two main ways to get coding agents to behave consistently and correctly: steer them with guidelines, and redirect them with guardrails. Basically a union of “Please go do the good thing” with Error: You did the bad thing, try again. Sometimes, this means fighting models’ non-determinism with better non-determinism. We build and refine Markdown instructions: rules, docs, skills, and the like. Then at PR time, AI reviewers, classifiers, and human review workflows can non-deterministically ask Claude to go back and do better. But while this informed guidance is helpful, deterministic rules are gold. Instead of “PLEASE don’t make 10,000 line files”, a lint script can simply reject overlong files before they’re pushed1. When practical, moving Markdown rules, checks, and guides into deterministic code like this is a big level up. Checks in code are harder, better, faster, and stronger than prompting – and a hell of a lot cheaper. Similarly, if you set up a local environment so models can verify how their code works in practice, you’ll get less speculation and fewer unnecessary fallbacks. Step by step, you can tune your laptop into an instrument for turning brilliant slash idiotic tokens into good PRs. Before long, you’re building at a pace never before seen, with architectural consistency no less. Your team is in awe of your productivity, and… wait. Your team. Some of them need to understand your work too. And you still need to review their agents’ work– OH GOD WHAT IS THIS PR?! Sharing is caring The history of software development is the story of sharing. At first we shared just code, once its author was done with it. Then we grew into sharing commit history, say with SVN. We’ve seen with everything from Makefiles to Jira, Slack, GitHub Actions, Terraform, and more recently code formatters and linters, that engineering improves with more sharing within teams. But when coding agents debuted, it made little sense to standardize how they were prompted. Hell, they barely worked in the first place. Nobody had any idea what it meant to use them well, and they lent themselves to experimentation and highly custom setups. But 2024 was a long time ago. We’ve learned a lot about good agent guidance and guardrails, and models have gotten far better at working within them. Yet many teams still work in repos with no shared agent instructions at all. These teams still use AI. But they rely mostly on models’ instincts, developers’ prompting skills, and reviewers’ discipline to keep agents in check. More industrious team members might email around skills they find helpful. Using their personal setups, a few folks on these teams elicit well-engineered PRs from Claude – but these get jammed up alongside other developers’ mystery slop in the review queue. Fortunately, this is beginning to change. In-repo AGENTS.md files are now common. Reproducible dev environments, consistent for every team member, are including more lints, sandboxes, MCPs, and other tools that make agent output more consistent. CI, previously the realm of unit tests, often now runs review agents – preferably steered by in-repo instructions. And teams are putting checks, constraints, and formatting rules on PRs, making them easier to review and trust. As Thoughtworks’ Rahul Garg said on martinfowler.com: A prompt on an individual machine is a personal productivity hack. The same prompt in the team’s repository is infrastructure. So from this, we now have two primary goals: work to make our agent instructions more deterministic, and more useful for the whole team. Before the work: Setup and guidelines After the work: guardrails Deterministic, shared 😀 Reproducible dev environments and sandboxes, verifiable structures (types, schemas, boundaries), shared tools and hooks Typechecks, lints, tests, builds, CI, blocking hooks, ratchets Nondeterministic, shared 🙂 AGENTS.md, in-repo docs, shared skills, existing coding patterns, guidance returned from shared tools, shared agent sessions PR review agents, shared classifiers, human reviews Deterministic, personal 🙂 Personal tools and MCP servers, local permission setups, local env config Personal lints and hooks, local pre-commit Nondeterministic, personal 🫠 Your prompt, local memories, personal skills, CLAUDE.local.md, a bespoke dev environment only on your laptop Yelling at Claude for being a complete doofus The job, increasingly, is not producing code. It’s iterating a system – guidelines, guardrails, and tools – that helps your whole team produce good work. And as more teams run coding agents in the cloud, spun out of Slack conversations, Linear tickets, or incident reports, ensuring your agents do the right thing regardless of where they run is even more essential. While a tuned software factory like this is a boon to generalists working in it, working on the system is where domain experts – perf wizards, database pros, and so on – can really shine. Instead of just running interference, trying to review and reject problematic PRs in their domain of expertise, they can iterate docs and guardrails that improve how every change, whether kicked off by a PM or a principal engineer, is written. PJ Onori, a design systems veteran at Sanity, responded to an increase in agent-authored code that didn’t comply with their design system not with derision, but with a spec. Basically, in-repo rules turn expertise into leverage. Note: The shared rules need to actually be good In 2024, models’ worst failures were not following instructions. In 2026, we also get agents failing because they do follow instructions, even overly absolute ones. Many a CLAUDE.md (or, now, AGENTS.md) has collected slop like: IMPORTANT: Every fix must start not with code, but with failing tests. Make the fix, then honestly verify it against the new tests. This is not busywork—it’s discipline. 1000 PRs merged later, agents have gifted you 9999 new unit tests, many of them useless, like a cat delivering its owner dead birds. “Oh great, thanks Codex, tests that enshrine every copy edit we’ve ever made to the UI, how thoughtful of you.” Let this herd of tests run on hundreds of pushes to GitHub every day, and in time your CI bill will gain an entire digit. While having at least some agent docs and guidelines in-repo has become standard, there is wild variation in how well-maintained these instructions are. Often they get so long, agent harnesses truncate them. Multiple teams I’ve helped have said they still required humans to read and review code changes, but not AGENTS.md instructions. That is, the root set of rules followed by every agent working in their codebase.2 Now, you definitely want to add in-repo guidance and guardrails for your team’s agents, but with great leverage comes great responsibility. If your one doc or tool can now affect thousands of nondeterministic coding runs across a team, it’s worth the effort to iterate and improve it over time. At the minimum, this means building a culture of standards for this shared infrastructure, and people who own its effectiveness. How do we actually do that? Closing the loop While surely you tested your AGENTS.md overhaul personally, how is it working for everyone else? You see that your agents aren’t adding overlong comment blocks anymore, but this new PR from Steve did. Had he pulled your new instructions before he wrote this? And come to think of it, is your new guideline now causing places where explanation really would have been merited to be under-commented? Of course, to maintain code well that runs on various other machines requires a measure of observability – doubly so when the flows are non-deterministic. What skills are people using? Are they working as intended? Are agents spinning needlessly on missing context or verification capabilities? Are they now yelling at Claude when it was actually your doc or skill that caused the problem? You need to be able to fix mistakes and waste. Not just on your laptop, but across your team’s agents. On some teams, this just means having developers send bug reports and traces to team members when a skill or doc goes wrong – if they notice it and know who can fix it. Other teams move to a coding environment like Amp that shares session transcripts and their telemetry by default, or our Powerplant tool that supports session debugging in a harness-agnostic way. Meanwhile, Entire wants to be GitHub but for agents’ session logs as well as code. Session sharing comes with its own challenges. As with observability tools like Honeycomb and Datadog, giving your coding agents access to log and telemetry data from other agents is both very useful and potentially risky. Shared context needs thoughtful security, privacy, and accountability controls. Meanwhile, social conventions on teams around working with agents in the open are still developing. Some companies are overtly skeptical of transparency with agents, while others are all-in. No matter how this all plays out, one thing is clear: the early scramble of siloed experimentation is ending. It’s time for teams to be building shared agent infrastructure, guidelines, and guardrails, and to be iterating them together. To be learning not just from some confident poster on X, but from how one another are working with AI. And to help us all do less yelling at Claude, and more building useful software. While simply failing lints for a file that exceeds limits is helpful, we can do better. If your lints emit graduated feedback, e.g. flagging when a file is close to, at, or beyond the threshold, then you can give models useful feedback without halting a critical change because a file got pushed one line too long. Another useful graduated approach is the ratchet: if you find a bad pattern in your code you don’t want agents copying, a ratchet counts how many instances of the pattern currently exist, and only fails if that number goes up. A helpful tool for longer-term migration projects. Also worth noting: deterministic checks can give agents just-in-time remediation guidance. It’s better to put “New endpoints should use the typed Result pattern instead” in the lint error when somebody copies the old pattern, rather than in global AGENTS.md clogging every session’s context. ↩ /claude-api prompt-audit may be helpful if you need to dig out of this hole. ↩
Look Mom I’m famous on French Linkedin
