The Typewriter Defense

I recently wrote a post arguing that Atlassian faces serious structural risk in an agentic development world. It got more engagement than anything I've posted — and the responses were more interesting than the post itself, mostly because of the patterns in how people pushed back. I've seen these patterns before, every time a paradigm shift starts to bite, and they're worth examining because recognizing them is how you avoid being on the wrong side of them.

A Concession

Before I get into the patterns, let me own something. The original post was deliberately provocative. Atlassian is not going to die overnight. There's simply too much inertia in a company of that size with a customer base that large to collapse quickly. I was being cheeky, and I'll own that.

But "won't die overnight" is not the same as "will remain relevant." The trajectory matters more than the timeline. I wouldn't be surprised if, at some point in the future, Atlassian no longer exists except as a brand — in the same way Kodak still exists as a brand but not as the company it was. The question isn't whether they survive the next quarter. It's whether they survive the next decade as anything more than a name on a licensing agreement.

With that said, the responses to the post revealed some patterns worth pulling apart.

"You Wrote This With AI"

One commenter dismissed the argument because the post appeared to be written with AI. Set aside whether it was or wasn't. The implication is that the tool used to produce an argument invalidates the argument itself.

I also wrote it with a computer. I used a keyboard. The text was rendered by a browser. At what point in the toolchain does the thinking become illegitimate?

This gets at the core confusion. The value of a piece of writing has never lived in the mechanics of production, it lives in the judgment. What to argue, what to leave out, what structure serves the reader, what's actually true. If you can't separate the tool from the thinking, you're going to have a very hard time understanding what's happening right now in software development, because the entire shift is about exactly that separation. The mechanics of production are being automated. The judgment layer is what remains.

Dismissing an argument because it was produced with an AI tool is like dismissing a photograph because the photographer used autofocus. The camera didn't decide what to point at.

"Our Customers Won't Change"

The most common defense, particularly from people inside the Atlassian ecosystem, was some version of: enterprises have 500,000 users, complex compliance requirements, deeply embedded workflows. They're not going to rip out Jira for some homegrown agent pipeline.

This defense has an unexamined assumption buried in it: that replacement is expensive. And for decades, it was. Building bespoke tooling that matches the depth of an enterprise platform was a massive investment — years of development, dedicated teams, ongoing maintenance. The switching cost alone was a moat.

But what happens when building software becomes cheap?

We're entering a world where a small team directing agents can produce purpose-built tooling in days that would have taken months. When the cost of building drops by an order of magnitude, "too embedded to replace" stops being a permanent condition and starts being a temporary one. The enterprise that would never build its own workflow system because the investment didn't justify it might reconsider when the investment is a week of agent-directed development and the result is something that actually fits their workflow instead of forcing their workflow to fit the tool.

I'm not predicting that every Fortune 500 will delete Jira next quarter. But the implicit claim that they can't — that the complexity of enterprise requirements makes Atlassian's position structurally secure — depends on building software remaining expensive. That's the one assumption you absolutely cannot rely on right now. And the shift isn't just about cost — it's about the fundamental unit of work. Jira is built around tickets. Agentic development is built around specs. That's not a feature gap. It's a structural mismatch.

There's a classic incumbency trap here: mistaking the stickiness of your installed base for the durability of your value proposition. Switching costs and actual value are different things. The moment your customers are staying because it's expensive to leave rather than because your product is the best answer to their problem, you're in managed decline — even if the revenue still looks healthy.

This is the Kodak trajectory I mentioned earlier, playing out in slow motion. Kodak had an enormous installed base of film customers when digital photography arrived. Their defenders made exactly this argument: professionals need the quality, the ecosystem is too deep, the switching costs are too high. All true — right up until it wasn't. The installed base didn't save them. It just meant the decline was orderly enough to feel safe until it was too late.

Moats built on "it's too expensive to replace us" don't survive a world where replacement gets cheap.

"MCP Solves This"

Several people pointed out that Atlassian's MCP integration works well — that you can connect agents to Jira and Confluence via API, that the tooling is functional if you know how to wire it up.

The most interesting defense, because the people making it don't realize they're conceding the argument.

If the primary value of Jira and Confluence becomes serving as an API backend for agent workflows, that's not a win — it's a catastrophic repositioning. Nobody pays enterprise licensing for a structured data layer; that's commodity territory. The value of Atlassian's products has always been in the workflow layer — the boards, the views, the human interaction model. If agents are the primary consumers of that data and humans are interacting through agent interfaces, the workflow layer becomes a cost center, not a value driver.

And here's the part that should really concern them: if you've reduced yourself to a state layer, replacement becomes trivial. You're no longer competing with other enterprise workflow platforms. You're competing with a git repository. Specs, plans, decision records, review artifacts — all of it can live in version control alongside the code, with full auditability baked in for free. Every change tracked, every decision recorded, every agent interaction preserved in the commit history. The same auditability you already have for code, extended to everything else, searchable and right where the agents are already working.

That's the approach we're taking, and it's not heroic engineering — it's straightforward. When your competition is a free tool that every developer already uses, your enterprise licensing model has a problem.

"You can talk to it through MCP" is functionally equivalent to "it works fine as a database." And databases are easy to replace.

"You Just Don't Understand Enterprise"

The last pattern is the most reflexive: the argument must be wrong because the person making it doesn't work at sufficient scale. If you understood enterprise complexity — the governance, the compliance, the audit requirements — you'd see why these tools are essential.

There's an irony here. This defense assumes I've never worked at enterprise scale, which is itself an unexamined assumption. I've spent thirty years in software. I built high-frequency trading platforms at Peak 6. I was at Amazon from early stage through 100,000 engineers. I've run technology at organizations with thousands of employees and the governance requirements that come with that. The assumption that anyone questioning Atlassian's trajectory must simply not understand "real" enterprise complexity is a textbook ad hominem — don't engage the argument, disqualify the person making it. It's also deeply defensive. When your best response to criticism is "you're not qualified to criticize," you've stopped defending your product and started defending your identity. The question isn't whether those requirements exist. The question is whether Atlassian's current product architecture is the right way to satisfy them going forward.

Governance and compliance requirements don't disappear in an agentic world — if anything, they intensify. When agents are producing code at scale, you need more traceability, more decision lineage, more structured review, not less. The question is whether that governance layer looks like a Jira board with custom fields, or whether it looks like something fundamentally different — something designed for a world where the unit of work isn't a ticket but a spec, where the review artifact isn't a comment thread but a structured judgment.

The enterprise complexity argument gets the problem right. It gets the solution wrong.

The Pattern Under the Patterns

All four of these responses share a common structure: they defend the current tool by arguing that the current need persists. And the need does persist — organizations need to coordinate work, govern execution, maintain audit trails, collaborate on documents. None of that goes away.

What changes is the shape of those needs. Coordination shifts from tracking human tasks to orchestrating agent execution. Governance shifts from approval workflows to judgment frameworks. Documentation shifts from collaborative editing to spec-driven generation. The underlying tension is between workflow enforcement and judgment amplification — Jira and Confluence are built to enforce workflows, but what organizations actually need in an agentic world are systems that amplify human judgment. The needs persist but the form they take is unrecognizable from the vantage point of the current paradigm.

This is what makes paradigm shifts so hard to see from the inside. The incumbents aren't wrong that the needs are real — they're wrong that their current architecture serves the new shape of those needs. And because they can always point to the persistence of the need as validation of their product, they don't see the ground shifting until it's too late.

The people defending Atlassian aren't stupid. They're applying a mental model built for a world that's in the process of being replaced, and that's not a personal failing — it's just the structural disadvantage that comes with incumbency. You stop asking whether the shape of the need still matches what you've built, because the persistence of the need feels like enough.

So here's the question worth sitting with: if you were designing a coordination system today, from scratch, for a world where agents do the building and humans do the judging — would it look anything like Jira?

We're building one. It doesn't.