Dorian Becker

People keep asking how companies like Ramp, Linear, and Anthropic ship so much software with agents. There is no new SDLC or secret set of tools. The tools are increasingly available to everyone. You can build your own, use Linear, Claude, or whatever works. The bigger difference is ambition. These companies encourage their teams to build more, experiment more, and let agents do more of the work. That's the main different between "AI native" or not. You try to use the technology to the max. But don't get there by adopting a tool. You get there by changing what you believe your teams are capable of. So in the very simplest way: - let agents build - make it easier and faster to contribute - increase the ambition of what your teams attempt. In practice, that means things like: - Standardize around cloud agents. Most of our code (5M lines last quater) is now written in Linear with our Linear cloud coding agent. Cloud sandboxes make standardizing the system and environment easier for everyone and enables faster contributions - Linear agent (with code access and cloud agent) operates in Slack too. If there is a discussion or someone notices a problem just say "@linear fix this" (decrease the time from something noticed to fixed) - As bugs, errors etc arrive in Linear, send them to Triage, and have Loop to auto-investigate (connect to tools like Sentry, Datadog), and write a fix - Let designers, PMs, non-technical people contribute code where useful. If they notice a problem, tell them they can submit a fix. If they want to try something, ask them to build a prototype. - Set up code review agent and system to make sure PRs are safe to merge. - Run security as an automation, have agents constantly try to find security issues in your codebase, as they find, send it to a coding agent - Instead of working on issue level, increase ambition, make a whole project, ask the agent to ask questions, investigate code base, create issues and have the agent work on the whole project at once. Set up goals like "give me proof that what you build works". All our PRs now come with screenshots and videos and preview build you can - Bring customer feedback to the system like Linear, and make it available for your team. At Linear every project now starts with 10-500 customer notes that influence the direction of the work, and which customers we should ask to test the solution first. - Set up Loops/automations to constantly update reference documents for agents, like product area/code owners so work can be routed to right humans Then what is left is how do you set direction for your teams (initiatives, projects they should work on) and how do you review results (better code review, Linear does it with Guided Reviews), how you maintain quality/cohesion which is not a new problem either. Basically most of the problems you always had remain, but the execution bit is now more and more solved. At @linear we can help with automation, cloud agents, and code review, customer feedback and planning bits. But we can't change your mindset or how your company operates. If your company is still spending energy debating jira workflow steps, you're probably solving the wrong problems.

New on the blog: — Our organizations are being DDoSed from the inside I’ve written before that you can outsource work, but not your understanding. As a CEO, I’m finding that harder to live up to. It feels like our organizations are being DDoSed from the inside. Nobody is trying to overwhelm the company. Everyone is doing something they think is useful. Leaders never saw every piece of work. But now the work can change the company’s direction faster than anyone can follow. It’s like a car speeding up until it becomes impossible to steer. I think lot of leaders are stepping back now and letting the things happen. But stepping back doesn’t remove my responsibility for where this all leads. Are other leaders feeling this? How do you deal with it?

I think we have lost some sense of judgment and moderation when it comes to product building currently. The moment you turn something into a universally celebrated metric, whether that is token burn, prototype count, or percentage of agent-written code, you start losing sight of what actually matters. I have felt the same way for a long time about overusing data and A/B testing to build products. The moment you reduce product quality or productivity to a metric, you stop shipping value and start shipping numbers. A lot of what people are doing with AI makes directional sense. The missing piece is counterbalance: 1. AI should help engineers build better products. Leaderboards and adoption metrics can be useful as directional signals. They do not tell you what is being built, whether it is good, or whether it should exist at all. 2. Users do not care what percentage of your code was written by agents. They care about the outcome. Faster output is useful. Like usually, faster doesn't seem to add to quality, clarity, or stability of products. Power to build should not become an excuse to lower quality bars. 3. LLM-generated prototypes can feel like late-night whiteboarding sessions. They look exciting in the moment and feel productive very quickly. Then a few days later you realize the idea was shallow, distracting, or simply wrong. The same trap shows up in jumping straight to code and solutions more broadly. You may just be building the wrong thing more efficiently. Prototyping has its place. So do clear thinking, good design, and a real understanding of the user’s problem. In terms of activities or momentum, the main quest and the side quest can both feel productive but only one actually moves the mission forward. 4. Adding more to products is still dangerous as ever even if time or effort to add it has gone down. Every addition creates complexity, maintenance cost, and user confusion. New features should be pushed back unless they clearly show it should exist and how it improves the product. 5. Not everything needs to be an agent shaped. A simple scheduled task does not need a full LLM sandbox. Making something agentic because it feels current or impressive does not make it right-sized, correct, or effective. The core ideas are: - even if you can, maybe you should not. - more power we have to build should not reduce our need to think, it should increase it.