# Will Larson - Irrational Exuberance Recent content on Irrational Exuberance This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Roadmap decisions rather than dates. DevFeed: [Roadmap decisions rather than dates.]() Original publisher: [Read original article]() Published: 2026-08-11T14:00:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Development](), [Passkeys](), [resiliency](), [User Experience](), [Mobile](), [Web]() Tags: [development](), [experience](), [implementation](), [mobile](), [phishing](), [resiliency](), [web]() ### AI overview The article argues that product roadmaps should prioritize decisions and execution constraints rather than fixed dates. It uses the development and rollout of passkey support at Imprint as an example, describing implementation behind a feature flag, staged web release, feedback iteration, and expansion to native mobile experiences. ### Source excerpt One thing that bothered me about Imprint's product after joining was our lack of passkey support. Passkey support is a rare opportunity to increase resiliency to phishing attacks while simultaneously reducing login friction. If it's good for our members, our partners, and our product, it felt like something we should have already shipped. Nonetheless, it was hard to get it onto the roadmap alongside everything else we were working on. To dig into passkeys, I started sketching out the implementation as a side quest. Some iterations later, I had something implemented behind a disabled feature flag for team review. At that point, most problems had a concrete solution implemented, and the remaining issues were messy intersections between passkey implementation and user experience. Issues remained, but the tangible implementation made tradeoffs explicit, and we were able to work through them. Soon thereafter, we launched passkeys to a small group in our web experience, iterated on feedback, finalized the details, and brought those details forward to our native mobile experiences as well. It never got onto the roadmap, but it did ship. Our passkey release planted a seed for me, but it required another experience to fully germinate. We had a discussion about hitting a date for a product extension we're developing. Our conversation kept anchoring on the idea that pulling in a date was dependent on pushing out dates for other projects. Presenting two conflicting projects as requiring timeline tradeoffs wouldn't have caused me to blink an eye five years ago, but in this conversation it inspired a sort of instinctual revolt: with modern development techniques, I believe very few projects are essentially constrained by execution bandwidth. Some are constrained by approvals, others are constrained by cross-team and cross-functional handoffs, and many are constrained by missing decisions, but almost none should be constrained purely on time. Shifting blocks of time across project ## Middle management roles are also a trap. DevFeed: [Middle management roles are also a trap.]() Original publisher: [Read original article]() Published: 2026-08-08T14:00:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Tech Lead](), [engineering-culture](), [Software Engineering]() Tags: [engineering-management](), [organizational-culture](), [software-engineering](), [tech-lead]() ### AI overview The article argues that middle-management roles can be a poor path to becoming an executive. Although these roles develop skills such as stakeholder balancing, process design, and resource allocation, the author says line-management roles provide better opportunities to develop domain expertise, execution, and organizational culture. ### Source excerpt Six years ago, I wrote Tech Lead Management roles are a trap. My argument then was that TLM roles present themselves as easier than moving into a full management role, but the tension between doing the software engineering and engineering management aspects of the role made being a TLM a much harder first management role than a pure engineering management role. I still agree with that post, and I have some additional bad news to share: middle management roles are mostly a trap as well, if you goal is to become an executive. The core aspects of middle management roles are: Balancing between top-down executive, lateral stakeholder, and bottom-up team pressure, e.g. keeping morale up as an organization deprioritizes last year's big initiative Defining and operating an organization's process, e.g. creating career ladders and interview loops Competing for a share of fixed organizational resources (e.g. budget) and allocating acquired resources These are all extremely important skills to be an effective executive, and they make up the bulk of The Engineering Executive's Primer, but they are insufficient to make you a great executive. If you don't have them, you will be a deeply flawed executive, but even if you're an expert at them, you can still be a terrible executive. That's because the most important skills of an effective executive are the same exact skills that make an excellent line manager: developing domain expertise, driving execution (including setting pace), and translating both of those into an organizational culture that extends beyond you (in any of innumerable different ways). All of them are more easily practiced and mastered as a line manager than as a middle manager. Most middle management roles make practicing those skills difficult, and sometimes negatively select against developing them. As a middle manager, if you drive execution too closely, you might get told off as a micromanager. As a middle manager, if you go too deep on domain expertise, you m ## How Layered Codebases and LLM-Assisted Reasoning Accumulate Complexity DevFeed: [How Layered Codebases and LLM-Assisted Reasoning Accumulate Complexity]() Original publisher: [Read original article]() Published: 2026-07-11T13:00:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [coding](), [Software](), [context](), [Large Language Model](), [Chain-of-thought]() Tags: [coding](), [complexity](), [context](), [llms](), [reasoning](), [software]() ### AI overview The article uses soil horizons as an analogy for software and organizational reasoning. It argues that codebases can accumulate distinct layers as architects and team leads change, especially in complex domains, and that relying on LLMs for conclusions rather than exploration or drafting can create similarly flawed reasoning layers. ### Source excerpt I've recently been thinking a lot about the concept of "soil horizons", which is the idea that there are many distinct layers of soil, from topsoil all the way down to bedrock, which all combine into a soil horizon. Translating this idea into software, the ideal codebase would have a single uniform "code layer", but a surprisingly large percentage of production software has numerous, distinct code layers as the leading architect shifted over time. I've found this particularly true for software in problem-spaces with high essential complexity and low scale complexity, where the purifying challenges of scaling never create enough pressure to compact disjoint layers into a unified layer. Codebases with the most code layers tend to be created by small teams working on complex domains over a long period of time. In many companies this might be an identity, permissions or payments team: stuff that's permanently valuable, but usually not the central concern at any given time. On such teams, there is often only one architect who understands the nuances of the domain well enough to make tradeoffs. When that architect leaves, they are replaced by someone who aspires to operate in the same code layer, but simply cannot because they lack enough context to do so. As a result, that new replacement creates a new code layer, despite not intending to. If the team runs through a handful of folks as the new team leads struggle, it's easy to end up with a complex code horizon very quickly. The problem of messy code horizons is not a new one, and the general approach to addressing them is the same one I wrote about seven years ago in Reclaim unreasonable software, but with the proliferation of coding and non-coding harnesses, lately I'm running into the problem of messy code horizons more frequently. Even more concerning, I'm seeing this problem expand from impacting code horizons into impacting how organizations make decisions outside of software, e.g. the company's general reasoning h ## Revised rules of engineering leadership. DevFeed: [Revised rules of engineering leadership.]() Original publisher: [Read original article]() Published: 2026-06-15T13:00:00Z Content type: article Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [engineering-leadership](), [migration](), [Development](), [CI/CD](), [Code]() Tags: [ci-cd](), [code](), [development](), [engineering](), [engineering-leadership](), [leadership](), [migration](), [tests]() ### AI overview An engineering leader revises their approach based on experience in hypergrowth environments and recent AI-tooling changes. The article argues that individuals can own much larger migrations, while the quality and speed of working code depend heavily on development harnesses such as tests, CI/CD, validation environments, and change previews. It also discusses designing processes so agents can handle common cases with appropriate controls and context. ### Source excerpt From early 2014 through late 2020, I was working in hypergrowth environments, which are challenging, but also educational. The most valuable feature of hypergrowth is that your mistakes reveal themselves next month rather than next year, because things go wrong very loudly when you're moving fast. I've been thinking a lot about hypergrowth recently, because Imprint's business is growing quickly and we did a large batch of hiring last year, but also because the AI-tooling shift has changed the pace at which it's possible to work. This post documents the new rules I've revised my approach to engineering leadership around, and then talks through the specific projects I've worked on over the past year that caused me to believe in these rules. Revised rules Migrations can be done by an individual rather than a team. Even complex, large changes can be 95% owned by the driving individual or team, and done in 10% of the time. As the initial cost of migrations goes down, the reward/penalty of each migration's quality goes up: even small sharp edges will break your colleagues' mental models about the software you co-maintain. The impact of individual judgment on your company has never been higher. While 1st-pass code is nearly free, the cost of working code depends on your development harness, and is not free. We're in an era when many companies say that everyone should be writing code, however our experience is that writing code that works well, while avoiding messy edgecases, remains difficult. Just how difficult remains a factor of your development harness, e.g. your tests, CI/CD, validation environments, preview-ability of changes, and so on. While I personally don't imagine it's valuable for most folks at a company to be contributing code, I suspect that most disagreement about that topic is actually a miscommunication: even at a company where "everyone codes", the marketing team isn't reducing allocations in your servers, instead it's about whether there is a safe bound ## Early and late-stage hypergrowth. DevFeed: [Early and late-stage hypergrowth.]() Original publisher: [Read original article]() Published: 2026-04-27T13:00:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Scalability](), [Requirements](), [Users]() Tags: [requirements](), [scalability](), [support](), [users]() ### AI overview The article distinguishes early-stage from late-stage hypergrowth. Early-stage companies can focus serially on their biggest specific problems, while late-stage companies must address many simultaneous requirements from a more skeptical market. It argues that adding a new leader can be preferable to expanding an existing leader's scope during late-stage hypergrowth. ### Source excerpt Last week, a colleague asked why I'd hired an additional new leader onto an important area rather than expanding an existing leader's scope to incorporate that area as well. The existing leader was a known quantity and doing well, so why not keep expanding them? It's a good question, and depending on the circumstances I might have done either, but explaining why I specifically brought in a new leader this time depends a bit on a distinction I think of as early versus late-stage hypergrowth. In Cross the Chasm's world, early-stage is when you've proven product market fit, have won the early adopters, and are just starting to win the early majority. In this phase, there are specific problems, and the most important problem is to solve those specific problems. For example, you might be having scalability issues, and solving that is the company's almost sole focus for a few weeks. After scalability is fixed, next you'll need to work on onboarding flows to convert for less technical users, and so on. Not only the executives, but much of the company, serially hunts down solutions to their biggest problem. When you reach late-stage hypergrowth, you are starting to encounter the late majority and laggards cohorts. This reorients the company and executive teams away from only creating an exceptional product, to also having to solve the numerous concerns and checkboxes that a skeptical audience introduces. Sure, your product might save hours a day for our team, but how does your compliance paperwork look? How stable are you? What contractual commitment will you make regarding customer support resolution? At this point, you'll still be in an extremely competitive environment to retain the innovators and early majority, while also having to solve the long list of skeptic-driven requirements. Instead of hunting down solutions, the company-and the executive team-now has to solve everything, everywhere, all at once. Going back to my colleague's question, in early-stage hypergrowth ## Using agents as scaffolding for recurring security-vulnerability tasks DevFeed: [Using agents as scaffolding for recurring security-vulnerability tasks]() Original publisher: [Read original article]() Published: 2026-04-12T17:00:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Agent Framework](), [Vulnerabilities](), [GitHub](), [Dependabot](), [Model Context Protocol](), [Slack]() Tags: [agent-framework](), [agents](), [dependabot](), [github](), [mcp](), [security-vulnerabilities](), [slack]() ### AI overview The article examines using agents to reduce human involvement in recurring software-company processes. It describes an internal workflow that receives GitHub Dependabot webhooks, filters vulnerability alerts, identifies issue owners through GitHub MCP, and sends alerts to Slack, while noting that the agent could not reliably limit notifications to critical-severity alerts. ### Source excerpt One of my gifts/curses is an endless fixation with how processes can be optimized. For a brief moment early in my career, that was focused on improving how humans collaborate, but that quickly switched to figuring out how we can minimize human involvement, and eliminate human-to-human handoffs as much as possible. Lately, every time I perform a recurring task-or see someone else perform one-I think about how we might eliminate the human's involvement entirely by introducing agents. This both has worked well, but also worked poorly, and I wanted to highlight the pattern I've found useful. For a concrete example, a problem that all software companies have is patching security vulnerabilities. We have that problem too, and I check our security dashboards periodically to ensure nothing has gone awry. Sometimes when I check that dashboard, I'll notice a finding that's precariously close to our resolution SLAs, and either fix it myself or track down the appropriate team to fix it. However, this feels like a process that shouldn't require me checking on it. Five to six months ago, I added Github Dependabot webhooks as an input into our internal agent framework. Then I set up an agent to handle those webhooks, including filtering incoming messages down to the highest priority issues. About a month ago, when I upgraded from GPT 4.1 to GPT 5.4 with high reasoning, I noticed that it got quite good at using the Github MCP to determine the appropriate owners for a given issue, using the same variety of techniques that a human would use: looking at Codeowners files where available, looking at recent commits on the repository, and so on. The alerts and owners were already getting piped into a Slack channel. So, this worked! However, it didn't actually work that well, because despite repeated iteration on the prompt, including numerous CRITICAL: you must... statements, it simply could not reliably restrict itself to critical severity alerts. It would also include some high severity ## The agentic passive voice. DevFeed: [The agentic passive voice.]() Original publisher: [Read original article]() Published: 2026-03-29T14:30:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Actor](), [ChatGPT](), [Claude]() Tags: [agentic](), [chatgpt](), [claude](), [model](), [writing]() ### AI overview This commentary humorously proposes calling sentences that attribute mistakes to AI models an "agentic passive voice." It argues that writers should use active voice and avoid unclear attribution when describing model behavior. ### Source excerpt At some point, you will have learned about the passive voice, where the actor in a sentence is unclear. For example, my software didn't compile. That's a good example of the passive voice. However, you might not know the full set of rules, because here are some sentences in the passive voice that you might not recognize: Claude made an error in my writeup. ChatGPT messed up the commitment. Gemini didn't write tests. You might think those are active sentences, but those are in fact examples of the agentic passive voice. The rule here is: whenever the actor in a sentence is a model, then it's a passive sentence. I'm sorry if your grammar instructor never taught you this rule, but this is just the way it works now. This is an important grammatical distinction to make, because I'm increasingly seeing folks say that Claude made a mistake, without recognizing that they're writing unclear, nearly ungrammatical sentences that their grade-school teacher would reject. So please, aspire higher. Write in the active voice, avoiding all passive variants. ## How continuous deployment and coding agents are changing software development DevFeed: [How continuous deployment and coding agents are changing software development]() Original publisher: [Read original article]() Published: 2026-03-11T14:30:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [CI/CD](), [Deployment](), [migration](), [AI-assisted coding](), [Heroku]() Tags: [coding-agents](), [continuous-deployment](), [deployment](), [heroku](), [migration]() ### AI overview The author contrasts manual deployment and database migration practices at Imprint with a later workflow in which most changes continuously deploy to production after pull-request review and merge. The article connects this migration to broader reflections on how coding agents may affect software development. ### Source excerpt When I joined Imprint a little less than a year ago, our deploys were manual, requiring close human attention to complete. Our database migrations were run manually, too. Developing good software is very possible in those circumstances, but it takes a remarkable attention to detail to do it. It was also possible to develop good software using Subversion and developing by ssh'ing into a remote server to edit PHP files, but the goal is making things easy rather than possible. Ten months later, the vast majority of our changes, including database migrations, continuously deploy to production without human involvement after the initial pull request is reviewed and merged. Reading aloud the relevant pages from the mandated gospel of continuous deployment, deploying changes this way doesn't make them less reliable, but more so. Each step of validation a human might do, is now consistently done on every deploy, including many steps that are just onerous enough to drop off the standard operating steps like meticulously checking the post-launch health on a production canary every minute for half an hour after each deploy. This migration has reminded me a lot of the Uber service migration, which prompted me to write Migrations: the only scalable solution for technical debt back in 2018, and in particular how different this sort of migration feels in the age of coding agents. The more I've thought about how these two migrations compared, the more it's solidified my thinking a bit about how this technology is going to impact software development over the next few years. Migrations as metaphor Although I really want to talk about how coding agents are changing software development, I want to start by expanding a bit on this recent migration at Imprint and how it compared with the migration at Uber. The Uber migration was: Spinning up a new self-service service provisioning platform, along the lines of a very minimal Heroku, including the actual scheduling algorithm across cluste ## Refactoring internal documentation in Notion DevFeed: [Refactoring internal documentation in Notion]() Original publisher: [Read original article]() Published: 2026-02-05T14:00:00Z Content type: article Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Notion](), [Refactoring](), [code productivity](), [Documentation](), [API]() Tags: [ai](), [api](), [content](), [developer-productivity](), [documentation](), [git](), [notion](), [refactoring](), [survey]() ### AI overview A writeup of efforts to improve an organization's internal documentation after a migration from Confluence to Notion. It examines stale and duplicated pages, unclear ownership, Notion AI usage, and API limitations, then describes policies focused on reducing duplication and stale content and optimizing documentation for Notion AI. ### Source excerpt In our latest developer productivity survey, our documentation was the area with the second most comments. This is a writeup of the concrete steps I took to see how much progress one person could make on improving the organization's documentation while holding myself to a high standard for making changes that actually worked instead of optically sounding impressive. Diagnosis There were a handful of issues we were running into: We migrated from Confluence to Notion in January, 2025, which had left around a bunch of old pages that were "obviously wrong." These files created a bad smell around our other docs, as folks felt like things weren't well maintained. We had inconsistent approach to what we documented in Git-managed files versus managing in Notion. This led to duplication. Duplication meant that it felt safer to create an N+1th version, rather than debugging why N versions already existed. We've had a bunch of new folks join over the past year, who weren't sure if they were empowered to update documentation or if someone else was managing any given file We started using Notion AI as the primary mechanism for exposing content, which meant that hierarchical organization was less important, and that having inaccurate snippets was harmful even if they were tucked away into a quiet corner This was combined with a handful of interesting limitations in Notion itself: You cannot tell if a non-wiki page is verified or not via API. You can tell if a wiki page is verified via API, but no one uses wiki pages You cannot retrieve all pages in a Notion Teamspace via API, you instead have to manually take list of the top-level pages in that Teamspace, and find the children from those pages There is no "archive" functionality in Notion that allows you to exclude a document from search results There is no programmatic visibility into views or usage of a page via API except for how recently it was edited Policy The policy we adopted for addressing the above diagnosis was: Optimi