More from Dustin Curtis
I have been stuck. Every time I sit down to write a blog post, code a feature, or start a project, I come to the same realization: in the context of AI, what I’m doing is a waste of time. It’s horrifying. The fun has been sucked out of the process of creation because nothing I make organically can compete with what AI already produces—or soon will. All of my original thoughts feel like early drafts of better, more complete thoughts that simply haven’t yet formed inside an LLM. I used to write prolifically. I’d have ideas, write them down, massage them slowly and carefully into cohesive pieces of work over time, and then–when they were ready–share them with the world. I’d obsess for hours before sharing anything, working through the strengths and weaknesses of my thinking. Early in my career, that process brought a lot of external validation. And because I think when I write, and writing is how I form opinions and work through holes in my arguments, my writing would lead to more and better thoughts over time. Thinking is compounding–the more you think, the better your thoughts become. But now, when my brain spontaneously forms a tiny sliver of a potentially interesting concept or idea, I can just shove a few sloppy words into a prompt and almost instantly get a fully reasoned, researched, and completed thought. Minimal organic thinking required. This has had a dramatic and profound effect on my brain. My thinking systems have atrophied, and I can feel it–I can sense my slightly diminishing intuition, cleverness, and rigor. And because AI can so easily flesh out ideas, I feel less inclined to share my thoughts–no matter how developed. I thought I was using AI in an incredibly positive and healthy way, as a bicycle for my mind and a way to vastly increase my thinking capacity. But LLMs are insidious–using them to explore ideas feels like work, but it’s not real work. Developing a prompt is like scrolling Netflix, and reading the output is like watching a TV show. Intellectual rigor comes from the journey: the dead ends, the uncertainty, and the internal debate. Skip that, and you might still get the insight–but you’ll have lost the infrastructure for meaningful understanding. Learning by reading LLM output is cheap. Real exercise for your mind comes from building the output yourself. The irony is that I now know more than I ever would have before AI. But I feel slightly dumber. A bit more dull. LLMs give me finished thoughts, polished and convincing, but none of the intellectual growth that comes from developing them myself. The output from AI answers questions. It teaches me facts. But it doesn’t really help me know anything new. While using AI feels like a superhuman brain augmentation, when I look back on the past couple of years and think about how I explore new thoughts and ideas today, it looks a lot like sedation instead. And I’m still stuck. But at least I’m here, writing this, and conveying my raw thoughts directly into your brain. And that means something, I think, even though an AI could probably have written this post far more quickly, eloquently, and concisely. It’s horrifying. This post was written entirely by a human, with no assistance from AI. (Other than spell- and grammar-checking.)
We do not know how, why, or when the X algorithm devalues posts with links, but it does—without telling you, and by a lot—and it makes the experience there worse. Without links, information on X is headlines without stories, commentary without context, magic without the prestige. We do not know by how much the inability to share or see source links has impacted the spread of misleading or incorrect information, but we do know that primary sources cannot be put into X posts and that replies with links are shown to 70-90% fewer people. Speech on X is free, but only if you reference other speech on X. In Laos, I once asked a rural villager how he determined the truth, given that the government restricted his media to their controlled outlets. He thought for a few minutes, looked around, became confused, and then said, “Isn’t the truth what the government says?” The truth on X is what random people commentate, polarize, interpret, and summarize from source material that is intentionally lost by a black box algorithm. There is no depth to anything on X because context with links is heavily penalized. This is bad for humanity and the opposite of free speech. It is link winter on X.
Last week, Tesla unveiled two world-changing products: Robotaxi1, a fully self-driving taxi with no steering wheel or pedals, and an autonomous humanoid robot, called Optimus2, that can walk and has fully functioning hands and feet. Both of these products have been depicted in science fiction for decades, so the fact that a company is working on them was not surprising. What was surprising is that Tesla showed them existing today. The event looked and felt like a major product launch; they had clearly spent an incredible amount of time and effort to redecorate the 20-acre Warner Bros. studio backlot with a futuristic theme. In front of a couple thousand attendees, Elon Musk walked on stage and quickly showed off the new vehicles and robots while making very brief remarks about autonomy and the future of parking lots. Then he announced it was time to party, and walked off the stage. I was extremely confused. No products were launched. No details were shared about the Robotaxi or the Optimus robot. He raised a thousand questions and answered only one: when asked when Robotaxi would ship, Musk stumbled over himself as though he’d never thought about the answer before, and then appeared to make it up on the spot: “before 2027”. In other words, these products were not products: they were concepts. And while a lot of progress has recently been made on driverless cars and autonomous robots, for now (with few exceptions) they are still firmly in the realm of science fiction. Usually, when a company puts on a production this large, there’s a reason. When Apple announces its new operating systems or iPhones, they show off the new features and share when they’ll be available. But Tesla’s event seemed to have no purpose. Musk did not go into detail about features, design, or availability. In fact, the products he showed cannot even exist in the real world as they were presented. The Optimus robot hardware is extremely impressive, but the demo machines were surreptitiously and fully controlled by remote human operators. The Robotaxi relies on near perfect self-driving reliability, but the software for that doesn’t exist yet at Tesla, either. The demo units were half impressive engineering, half illusion. The choice of a movie set as the event’s venue was perfect. What I found most confusing was that Tesla gained nothing from showing off these concepts. They won’t be available to buy for years, and by then there will have been many more iterations. In the end, what they did accomplish was to throw an elaborate party for a small number of attendees, who were able to interact with a theme park-like vision of the future, while the millions of people who streamed Musk’s presentation were given an unorganized, disjointed misrepresentation of the state of the art. Tesla and Musk had a rare opportunity to use the event as an inspiring statement of mission and purpose. They could have told a story about why Tesla exists, why it is working on these products in particular, and how everything fits into the tapestry of the company’s overall mission. Musk could have explained that the Robotaxi has always been part of Tesla’s ambitious “master plan,” and then given a progress update on how the plan is being executed while showing the demo vehicles and robots. That would have been something worth watching and a story worth telling. But Musk didn’t tell that story. He showed off half-finished products and then threw a party. Over the years, I’ve come to believe that being able to put whatever you’re working on into the context of a bigger story is as important as making it work well–whether it’s a building, a company, an essay, a piece of software, or a hamburger. Good storytelling is good craftsmanship. Without a good story, without clear context and purpose, it’s hard to maintain the essence of a thing, and far too easy to make poor design decisions. When you develop the full story behind why and how you’re building something, you can make decisions based on principle instead of opinion, and if you can communicate that story well to others, you can way more easily get them to understand your vision. This applies to everything from product development to sales and marketing. The products Tesla has been working on are undeniably inspiring objects of a very optimistic future. Most companies focus on at most the next few iterations of their products, but Tesla is unique in that it defines the future for itself and then pulls it kicking and screaming into the present. Electric cars were impractical/impossible, and then Tesla made them ubiquitous. Humanoid robots have always been confined to science fiction, but Tesla is going to make them, too. The way Tesla operates is an inspiring story in and of itself. However, by announcing concept products years and years in advance, without providing context, especially while maintaining a wildly imaginative understanding of time, Tesla is damaging its reputation. Without a story, Tesla’s actions seem haphazard and erratic. Why did they throw a party instead of telling a good story? It makes no sense to me. Buried somewhere beneath its flamboyantly inarticulate product announcements, Tesla has one of the greatest and most inspiring stories in history. They are just awful at telling it. Musk variously and repeatedly refers to it as Robotaxi, Cybercab, and Cybertaxi. I think names are important, so I used the one on Tesla.com. ↩ Technically, Optimus was “revealed” a few years ago at a very bizarre presentation–even for Elon Musk–during which a human, dressed like a robot, performed an interpretive dance. ↩
In 2009, Microsoft released an enormous 200lb coffee table with an embedded 30-inch touchscreen called Surface. Although the iPhone had been around for a little while, the larger screen made Surface feel absolutely futuristic: in the Photos app, you could toss around pictures like they were physically in front of you. It cost $10,000. Very few people ever bought it. A little more than a year later, Apple released the $499 iPad. Microsoft had made a $10,000 table for no one, and Apple made a $499 tablet for everyone. This is a common theme among Apple’s most important products. They are usually built around existing ideas and technologies that have been improved and then repackaged into beautiful, premium experiences which are expensive but not unaffordable. This happened with the iMac, iPod, iPhone, iPad, and Apple Watch. Whatever the product, Apple has always brought seemingly impossible levels of quality and craftsmanship to the masses. Apple is luxury for everyone. Apple Vision Pro, however, is different. Yes, it is an undeniably beautiful product, and the software is very impressive. When I first used it, I was overcome with a sense of awe that I haven’t felt since seeing kinetic scrolling on the first iPhone. But Vision Pro costs nearly $4,000 and has enough faults that it still feels a bit like a technology demo. It is not affordable at all, and it brings nothing to the masses. Vision Pro feels bizarrely un-Apple in a way that only a few products have before, like the 18-karat gold Apple Watch, the $700 Mac Pro wheels, or the $1,000 Pro Display XDR stand. These recent Apple products are shameful Veblen goods that do not offer value commensurate with their price. And while the raw technology in Vision Pro is perhaps worth $4,000 today, I do not think it delivers nearly $4,000 in value. This is the exact opposite of most other transformative Apple products. So what happened? Good product design is a careful dance between what’s best and what’s possible. For the iPhone, building the right combination of technology and software at a practical price point was an enormous challenge that Apple pulled off. But it took years and years of development for the required technology in the iPhone to reach a price that was suitable for the market. When things were cost-prohibitive, the designers of the iPhone found clever workarounds or made hard trade-offs. The first iPhone wasn’t a perfect product, but it was designed against reasonable constraints. I don’t think Vision Pro was designed against reasonable constraints. If the goal was to make the equivalent of the iPod in a sea of mediocre MP3 players, Vision Pro hasn’t succeeded. It isn’t a disruptive VR headset because it isn’t even in the same market as its competitors, the majority of which are ten times cheaper. The goal, then, must have been to make a totally new product segment that only incidentally resembles the current VR market. Apple hints at this strategy by calling Vision Pro a “spacial computer.” The problem here is that if a spacial computer can’t be made today for under $4,000, then the technology simply isn’t ready. In its current state, I think Vision Pro is antithetical to Apple’s DNA: it isn’t accessible to most people, it is large and inelegant, and the platform itself has nebulous use cases. Design Philosophy # In my experience, whether it is hardware or software, there are two fundamental ways to approach product design. The first (and most common) philosophy is to build from the bottom-up, which involves assembling low-cost and basic components first, and then working to build up from those components to an experience that reaches a desired price-quality equilibrium. The second philosophy starts the other way around, by considering the maximum reasonable quality of an experience first–even if it is impractical–and then working over iterations to build down the product until it reaches an acceptable experience-cost equilibrium by making careful trade-offs and cleverly working around constraints. An example of a bottom-up product is the Amazon Kindle, which is made of inexpensive, flimsy injection-molded plastic and shows no signs of craftsmanship – it simply does what it says it will do. On the other hand, consider the Apple Watch, which is, even without its electronics, a beautiful object. It takes only a few moments of touching the watch case to realize that an incredible amount of thought was put into the materials, angles, and curves, and that perhaps even novel manufacturing techniques had to be invented to construct it. The top-down approach is more expensive and takes longer, but – as long as you have reasonable constraints and goals – the quality of the output is exponentially better. Apple Vision Pro seems to have subscribed to neither of these approaches, or its designers started with the top down approach and then gave up before hitting a reasonable equilibrium. It’s both absurdly expensive and has extreme tradeoffs that don’t seem to hit any cohesive product design strategy that would make it a great standalone product. It also has strange extraneous features like EyeSight, which must be incredibly expensive for what it accomplishes (rather poorly). What was the purpose of launching Apple Vision Pro now, when it is incapable of bringing anything new to the masses? It’s not luxurious, even though it’s well constructed. And at its current price, it’s definitely not for everyone. Essentially, it’s an expensive tech demo. Apple’s other groundbreaking products, like iPod, iMac, iPhone, and Apple Watch were all very focused products that launched with reasonable features at reasonable prices. They relied on Apple’s soul to guide their development. Vision Pro, it seems, not so much. Apple’s DNA and culture used to drive the company to make $499 tablets for everyone – a feat that seemed impossible at the time. But today, like the $10,000 Surface Table in 2009, Apple now makes a $4,000 headset for no one.
Ben Horowitz gave this remarkable response to a question about joy and happiness on Time Well Spent: In my experience there are really two things that lead to happiness and everything else is mostly noise. The two things are contribution and abundance. Contribution is basically exactly as it sounds. If you can align your life with where you have the talent to make a large, meaningful, and real contribution to the world, your circle, or your family, then you can be very happy. As an aside, doing so often leads to making money because when you create great value like Elon Musk, you get a lot in return. Now, that doesn’t mean you have to be a business person to be happy, because happiness comes from the knowledge and impact of the contribution rather than the reward. However, this doesn’t quite work by itself, which brings me to the second point: abundance. An easy way to think of abundance is that it’s the anti-hater/anti-jealous mindset. If you believe there is plenty in the world for everyone and you are always happy to see people who contribute succeed, then you become part of “team contribution.” You don’t worry that someone is getting ahead of you at work or that someone made a lot of money or that someone is better looking than you, because you believe in abundance over scarcity and you can focus on maximizing your contribution. In fact, their joy can become your joy (then you have an abundance of joy :-)). The good news is that abundance is actually true. There is plenty in the world for everyone and once you see that, there are so many ways to contribute. I visited a Syrian refugee camp in Jordan a few years ago. On the way to the camp, there were a few refugee families not even in the camp but in some tents on the way. The area was completely barren. No plants, no trees, no grass… just rocks. So here’s this extended family of about 20 living in this tent on rocks, because their farm was destroyed by the war and they had to flee to Jordan. They were all living in this tiny tent. If anyone should have had a scarcity mindset, it was them. But I experienced the opposite. They immediately offered me a cup of coffee and some rice pudding (as if they had enough to share) and told me the whole story of their journey. What struck me the most was that they were genuinely happy despite what they went through. They were less incensed by getting bombed out of their homes than people in the U.S. are if you accidentally interrupt them. I’ve seen this kind of happiness through abundance in many countries: Cambodia, Haiti, Uganda… Those refugees were happier than some billionaires I know. That’s not to say that money doesn’t help… it does, but without an abundance mindset, it’s not enough. If, on the other hand, you have a scarcity mindset, it’s really hard to be happy no matter what you get or how rich you are or how good looking you are, because there’s always somebody richer or better looking or whatever. You become part of team “hate.” This is why you see so many deeply unhappy political activists. In theory, they should be making a massive contribution, but often they are just expressing hate for the other side. Hitler and Lenin are famous cases, but there are many, many more, because there’s a fine line between advocating for one group and hating the other group. If you’re doing the former like Martin Luther King Jr., you have an abundant view and will find joy in the work, but if you are doing the latter, you have a scarcity view. People with scarcity mindsets are always unhappy in my experience. Scarcity is not just in politics. You see it in business all the time. You see somebody stealing credit for someone else’s work or being deeply jealous about someone else’s promotion — these people are almost never happy. You even see it in the music industry or in sports. The quest to be the best turns into you not wanting anyone else to be the best. In these cases, even if you reach the pinnacle, there is no joy. Ben Horowitz The interview is worth reading in its entirety: The Architecture of Tomorrow.
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
The company has not yet achieved the success of your logo for it, but we are still trying.