Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Derek Sivers podcast
You load the program into the computer, and it begins its calculations. It’s computing. It’s working hard, and it’s going to take some time. People who tell me they are lost and running in circles have one thing in common: They say they keep listening to podcasts, reading books, watching videos, doing courses — taking in more and more information — and still don’t know what to do. Consider the computer metaphor for yourself. You’ve taken in so much information, and heard so many instructions. That’s enough input. It’s time for output. Run the program. Stop interrupting yourself with new information. Let yourself execute one plan of action, and see it through to fruition.
There was a crime out on Park Avenue today, so the police are gathering information. The police said, “This is great information. How sure are you of this?” That’s your brain, in the dark, inside your skull. It can’t see or hear, or experience anything directly. It interprets little signals sent through nerves, which is not much information to work with, so it’s often mistaken. But it tells you it’s completely sure. 100% positive. In each of these movies, the hero gets through it for the better. When he finds out his mind has been tricking him, it’s upsetting, but he adapts. His mind was at odds with reality but can now see the difference. It’s even a relief, because it explains some frustrating moments of confusion in his past. Since old beliefs were disproven, the hero takes in reality with clear eyes. He carefully proceeds with less confidence and more humility. So can you.
This book is about reframing — changing how you think about something — and choosing a perspective that’s useful to you right now, whether or not it’s universally true. This narrow definition is important because whatever you consider true is closed. No questioning. But when you say “not necessarily true”, it opens it up for reconsideration. Let’s look at “Useful Not True” in five steps: Your thoughts aren’t true. Reframe: Find better perspectives.
In my previous post, “a daily run” — (please read it first) — running was a metaphor for whatever actions you take in your life. The story is about how we choose beliefs because they’re useful, not true. Beliefs make emotions. Emotions make actions. Actions come from emotions. Emotions come from beliefs. So choose whatever belief makes you take the action you want. One belief makes you act selfish. Another belief makes you act generous. One thought makes you do something stupid. Another thought makes you do something smart. What matters is the action they create. So choose the thought that works for you. the story, picturing a pot of gold, or a tiger, or hot coals, made real improvements in the runner’s actions. Adopt beliefs for your current needs only. What works for others might not work for you. What you needed yesterday might not be what you need today. Life is nuanced. Choose your goals and beliefs only for how they help you now. I’m bad at this and have a lot to learn. This week it’s time to perform, so to summon the courage, I choose to believe I’m great at this. Neither belief is true, but I adopted them because they helped me take the right actions. In the story, picturing a pot of gold didn’t work well in the past, but later worked great during a different situation. Adopt beliefs just for fun, to try different ways of being. Don’t over-focus on the usual goal. Take your eyes off the prize and look around. Creative experiments, curiosity, and adventures are fun. Fun is always a legitimate and underrated goal. Different beliefs serve different goals. Gurus and pundits prescribe their beliefs. But their prescription might only apply if you have a very specific situation and destination. Advice should come with this disclaimer. Don’t care whether something is true — only whether it works for you. When you declare a belief to be true, it closes minds, cements identities, and leads to tribal fights with anyone who doesn’t find that belief to be true for them. photo © Josephine Stenudd
Here’s a story about my shortest date, and ketchup. I suggested we meet at a bar at 35th Street and 8th Avenue. Although she’s from New York, she didn’t know where that is. She said, “No.” OK, now I’m judging. Miserable voice. Doesn’t know the basic layout of the city she lives in. Two red flags. She said, in her weary voice, “I’m not going to tell you my last name. You could be a serial killer.” So a couple days later we met at the bar at 35th Street and 8th Avenue. She looked good. We said hello. I asked if she’d like a beer. She said yes. I brought two beers back to the table. So the first thing I say is, “Where do you think the word ketchup is from?” I looked at her and thought for a second. Miserable voice. Doesn’t know her city. Assumes I’m a murderer. And now doesn’t have the slightest bit of curiosity about anything — no willingness to engage in the tiniest bit of wonder. She said, “But you haven’t even had a sip of your beer!” Years later, I’m living in Singapore, which is next to Indonesia, so I’m reading a book about Indonesian history. It says there is only one word in English that comes from the Indonesian language. Ketchup. My instinct was right to walk out on that date. Little interesting things are all around us. But the uncurious will never know. ketchup photo by Betsssssy
More in startups
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
The company has not yet achieved the success of your logo for it, but we are still trying.
we get very detailed and autistic about social dynamics in this one
