Ernesto

It is insane to me that there are still devs using terminals to prompt their agents

Next question: why are you still using branches? We talked about PRs. I don't think they make sense anymore, if you rethink them from first principles. Yes, if you only use them to trigger CI, then sure, go ahead. That's a fat commit, not a PR. But for mandatory code review? Knowledge sharing? C'mon. But some of you said: "we use PRs because we use branches! I love to keep my stuff on branches." And I'm here to tell you: you don't need branches! You can just push to main. It's called trunk-based development and the idea behind it is true continuous integration: you continuously integrate your changes with the trunk, the main branch. It's been around for a while, it works. Just yesterday I talked with someone who said they've used it in an org with 400 engineers, without any issues. Ruby, the project, uses trunk-based development. The main idea is that you want to avoid long-lived branches. They're bad, because branches can diverge and merging can turn into a thing. And you don't want routine operations to become a thing. Even when I worked in teams that used PRs and branches, I considered it a smell when a branch lived for longer than a day or two. But when I shared this with others, I'd often get something back like this: "Well, good for you, but no. MY thing, what I'm working on, that can't be done on main. It needs to be on a branch! It has a database migration, it changes the underlying shape, the architecture, it refactors this and changes that. It can't go on main yet! I need to merge it all at the end." And then I'd say: "Nah, I can merge nearly anything continuously in small commits to main. You split things up. Add the column first, merge that, deploy it, now it's out, works, safe. Add the helpers first, merge them, get them out. Want to migrate from legacy pattern A to new pattern B? Don't do it all at once. Add the dependency, then migrate A to B, one by one, safe." If it can be merged in a large change, I bet it can be done in small increments that you merge to main. Yes, there are exceptions, but it's 0.5% of cases, not 50%. But there was a real problem with this approach: it was hard! There's a lot of "meta programming" you have to do: make sure this small first change compiles and runs and the tests work, merge it, get it out, monitor it; then do the next small piece, make sure that works and get it out; then maybe push some still-unused dead code, add a feature flag, add a config variable; or keep both configurations working at the same time, etc. That meant sometimes it was just easier to do it in a big fat branch. But big fat branches are risky! A system that continuously flows is safer than a system that starts and stops in spurts. But -- you guessed it -- here's the good news: Now, with agents, all of these chores are no chores at all! Agents are great at adding feature flags, they're great at splitting up code, they're great at keeping track of three changes and merging them one by one and watching them roll out. They're great at keeping two configurations working for a day. They're great at migrating one by one. In other words: it's now 10x easier to just work on main and make sure everything is continuously integrated and working. It's now easy to make sure the system constantly flows. And look, ... I'm not here to convince you to switch to trunk-based development. Just a ruse to get you to read this. (But also, hey: try it! Pushing to main is amazing.) I'm here to make you RETHINK how you develop software. Don't just use agents to replace your typing. Use agents as the magic code-writing machines they are. Everything that was hard about software development because it involved writing code -- even the meta programming -- has become easier. You can now reach for the stars! But you need to look up.

AI isn't the designer. It's the tool. You're the designer. The art director. It can't design without your direction.

Issues created in @linear by people and via MCP are up 400% this year. Another fast growing trend: more customers are building their own internal agents and using Linear as the shared layer for workflows, communication and context between people and agents. As teams move faster, connecting goals, requests, reasoning and the work matters more, even if it sometimes happens after the fact in the review. Here is one customer oriented example we can do in our Linear: - Pick a top-10 customer. Ask the agent for a brief of their top requests and the reasoning we've captured - Write it to a doc in Linear and decide what to build with some people - Have the agent turn the decisions into projects and issues, carrying the customer requests and meeting notes with them - Teams send their agents to work on them - At the QBR, ask agent to generate a report and show the customer what has actually landed or them, how and why Now multiple these kind of workflows 100 or 1000 times where someone is learning something worth fixing, or trying ideas and finding beta customers for it. Or just aligning across the team or cross function. Not posting our revenue chart, but it looks a lot like this one

There’ll be times where you over-guide the AI. It knows better than you and is more intelligent than you. There’ll be times where you under-guide the AI. It can go off-track, have the wrong biases, or miss context. How well you manage this superpower is the #0 skill I look for.

One of the best UX's the web ever produced is no longer useful. If anything you're doing right now has to do with traditional UI/UX, you've got maybe a decade of utility in tech. User interfaces will eventually disappear. Agents, chat, voice, infra, videos, games--that's it

What day the week starts on