We are nearing the six-month mark from the last large jump in model coding capability. Six months is often the honeymoon period. After that, some of the reality starts to set in.
I tend to be cautiously optimistic about AI. Mostly, I try to live in the current reality. Not in some far future where AGI branches off from humanity and forms it's own TechnoCore society.
The capabilities are real, but so are the limits. The interesting question is less “where does this end?” and more “what is actually different now?”
I find the current market narratives around AI too simplistic, and honestly a little disheartening. The conversation often leaves no room between optimism and doomerism.
I’m more interested in the space between: what is actually changing, what is useful, what is overhyped, what carries real risk, and what we still do not understand.
--
Plans are worthless, but planning is everything
Recently, it seems planning is going out of fashion.
The way I usually think about AI’s impact is to ask whether the same decision or activity could have been made before AI. As far as I know, there was never a hard requirement to do long planning cycles. If anything common wisdom was always to be more agile, and yet many companies ended up with annual or half-year planning cycles anyway.
So the question is: why? What problem were those planning cycles solving, and has AI actually solved that problem?
I do not have the full answer, but I often think planning is not about the output (the plans) but exercise on an alignment and commitment. It forces the organization to come together and debate what actually matters, decide priorities, create meaning and then share that direction with everyone.
Sometimes is also to pre-work organizational complexities or boundaries, and the plans create shared terrain that various departments can navigate on. The plan is actually just a forcing function for all these meetings and discussions to happen.
So while AI may change the timelines and increase bandwidth, I do not yet quite see how it solves the other problems organizations were solving for. The need to choose still remains. In some ways, those may become more important as the cost of building goes down. If it becomes easier to make more things, it also becomes easier to make the wrong things.
There is still some truth to the shift. Capabilities are changing quickly. Market preferences are in flux. Very long planning cycles now carry more risk, because the market may have moved before you complete the plan.
There is also a clear argument for more experimentation. AI capabilities keep increasing, and our understanding of how to use them is still incomplete. Valuable use cases, tools, and workflows often have to emerge from trying things. They cannot always be planned in advance.
This is how we have operated at Linear from the beginning. We have plans for at least six months, which set the overall direction. But we retain the ability to change the plan or priorities any month or week. The plan is always a belief about what we seemed worthwhile. As we learn or notice changes, we adjust it. We are also encouraging more experimentation now. More room to find emergent use cases, rather than only relying on the plan.
But having no plans, no planning, no direction, or only a very short roadmap can also make organizations rudderless. The risk becomes building the wrong things, for the wrong customers, and for the wrong reasons.
Without thinking, direction, or a plan for what you actually want to achieve, you may end up doing whatever comes easily.
When you don't do the planning exercise, you also never fail your thinking, commitments, plans, or timelines because you never make them. You can just build whatever and see whaat happens next, and potentially let the AI steer you toward what is easiest rather than what matters.
You steer the AI, AI steers you
This gets to something I have written about before: tools always steer and influence workflows. They always show you the path.
AI tools are different because they are thinking tools, not just mechanical tools. Their ability to steer you and your work is greater than before.
There is a valid workflow where you do not fight the AI. You let it pull you. This is essentially what vibe coding done well can be: following the grain of the tool, moving quickly, accepting that the model has a direction and using that momentum.
It can be useful while not leading you exactly where you wanted to go. Then depends on the situation if that is good or not.
The expertise paradox
AI often feels most impressive in domains where you know the least, which I think it's largest contributor to the dissonance in the market. AI capabilities are described and understood as limitless to the casual observer.
In areas you understand deeply, you see the gaps. The output is close but not quite right. It misses context, invents details, chooses the obvious path, or needs heavy steering before it becomes useful.
In areas you know less about, the same output can feel like magic because you lack the judgment to see what is missing. This is a kind of Gell-Mann Amnesia and Dunning-Kruger effect at scale.
The paradox is that expertise makes AI harder to use, but also more valuable if you know how to wield in a proper way. Experts see the slop, but they also know how to steer, constrain, and evaluate the model.
So AI does not remove the value of expertise. It makes expertise more about direction, judgment, and knowing what good looks like.
Coding
Talking to customers and companies in the industry, it is clear that agentic coding is now fairly standard. But there is a spectrum. Almost no one privately says their agents write 100% of the code. Also I don't hear lot of real stories from real companies running massive independent agent swarms.
Engineers are still very much involved in the steering the agent, and often can maybe can only run couple of agents at once, and few cloud agents in the background to do more menial fixes. Any more than that you're living in the world of Harrison Bergeron where something constantly pings you and disrupts your thinking process.
We see this in Linear as well. A majority of our paid workspaces now have a coding agent installed, and activity using those agents has increased more than 5x in few months. I do not know exactly how every company uses cloud agents internally, but the direction is clear: these tools are part of the normal development workflow.
At Linear, engineers use various agents and have also seen our pace increase. With just our own cloud coding agent, we are now fixing more than 1,000 issues per month and it's increasing fast. The biggest impact is see is increased bandwidth. We can tackle more smaller problems than before. The work that might have been too minor, too annoying, or too time-consuming now becomes easier to do.
But hard problems remain hard. Agentic coding does not speed those up as much as the narrative often suggests. It helps around the edges, with scaffolding, refactoring, investigation, and smaller fixes. But the difficult parts still require understanding the system, making tradeoffs, and knowing what should exist.
In expert coding workflows, the value is usually not “AI writes the code and you accept it.” The value is acceleration around the work. It can explore approaches, scaffold implementation, debug errors, refactor code, write tests or large migrations, and handle smaller fixes.
The expert still supplies the taste, constraints, and final judgment.
Design
The new image generation and design capabilities are much better, but I still find them challenging.
Image generation seems to break down the more iterations you have. It is hard to make the AI change one specific thing in one specific way. It often changes many things at once. Each iteration also seems to add some kind of filter over the whole image, and you might have to start over with a new chat, new descriptions and new files to fix it.
I would like to see better tools for containing AI to specific areas, rather than allowing it to reinterpret the whole output every time. This also happens in writing, where asking for one change often causes the model to reshape the entire piece. I wish I would have better controls and workflows for the image generation.
Design and code
I keep thinking about the value of having a design tool operate directly on the production codebase.
Many design+code tools show a React component, like a button, and then let you change it with the design tool.
But when I am designing, I can imagine how the button works. Whether it is a vector shape or a React button matters very little to me at that stage.
A lot of the design work I do is not production design. I am not trying to implement the final version or test every edge case. Most design work is about making decisions, understanding the problem, and finding the fit. That process generates many variations and messy ideas.
I do not want every change to carry the speed or token cost of production code. I don't want to get in to errors because my prompt wasn't completed. I also do not want to design primarily through words or code. Design is a visual field, and for me it still works best in visual, canvas-based tools.
And if we put aside the debate about whether UI is needed anymore. Design is still a way to shape the problem and the solution. Most design work is about understanding how a feature fits into the existing system, how it interacts with other concepts, what its limits are, and what it is optimized for.
Even if a product is used through an MCP, CLI, or API, the concepts and workflows still need to make some kind of sense.
What I would find more useful are advanced visual tools, or semantic UI design tools, where you can define layouts and patterns more directly. Instead of drawing a rectangle, you are drawing a modal, and it can inherit some aspects of the system. AI could help fill screens, generate variations, and explore directions. The value is in the patterns, not that those patterns are backed by real production code.
Then, once I have something I actually want to prototype live, there should be a clear workflow for distilling the design file for an ai and translating it into code.
In the AI world, design is like planning for me. It's the /gstack running, asking you questions, but it is your own brain asking those questions, finding solutions on the screen.
Domain matters
With almost anything said about how a company uses AI, I try to ask: who are they, what is their domain, what stage are they at, what is their product, do they have customers, and who are those customers?
The way I have always thought about products that they each need different levels of stability, trust, security or even things like product design is that each product needs a different level and type of design.
A frequent, tactile tool like email needs a lot of UX polish, because users feel every paper cut. They use it constantly. Small frictions compound.
A backend service is different. The value may be in the backend logic. The UI can be more limited, even rougher, and the product can still be valuable.
I think many AI companies operate more like backend companies. The capability is the model. The harness and tools are being iterated above it, but so far they are often behind the scenes. This helps them move fast, because every feature can be another tool in the system without much visual or conceptual footprint.
It feels closer to classic UNIX systems, where programs are text based can be created independently and combined at runtime. The composability of the operating system is easier than compared to something like modern macOS.
—
The last argument is always that "these are the worst as they ever be"
I agree, but I try to stay close to the capabilities as they are now, because I do not know exactly what they will become. That is where my cautious optimism comes from. I do not find much value in being a doomer, but I also do not find much value in wishful thinking.
The more useful position is to observe carefully, try things, and keep judgment intact. AI is clearly changing things, but I don't think we can build today just by believing harder. We need to be more real and noticing what is possible now, deciding what is worth doing, and adjusting as reality changes.
Sort of how old nursery rhyme goes, if potential were revenue, all this CapEx would already be profit.