jpbryan

I started noticing at the end of last week. My colleagues started noticing on different days this week.

Why do I need a canvas to visualize the work that the agents are doing? I don't want to see their thought process, I just want the end product like how ChatGPT or Claude currently work.

Why not just use AWS Secrets Manager?

What if you want to build a third party integration to connect to Claude Chat or Cowork? Those can't run arbitrary CLIs. The only way to integrate with them is via MCP.

For good reason, IMO. Anthropic can't just allow their execution environments to run arbitrary user-generated CLI tools.

Thank you!

The same arguments of this essay apply to LaTeX and Typst

>If lawyers would think that visuals are more important than semantics

I never claimed that it was more important than semantics. But it is, nonetheless, essential.

Correct. Lawyers load their Word instances up with many add-ins specific to their practice. Microsoft Word add-ins are the entire product surface for many legal tech companies.

It's somewhat analogous to how coders use add-ins in their IDE but if only one IDE could run them.

Correct. Solely relying on the built in Word Compare tool results in a whole host of version control issues, however, which I outline in detail in my post "On Building Git for Lawyers."

https://theredline.versionstory.com/p/on-building-git-for-la...

Diffing the XML is a complete nonstarter. I've spent years working with the OpenXML format and can assure you it is very complex even for a professional software engineer with 10 years of experience.

The diff of the document (referred to as a "redline") is what lawyers send to the client and their counterparties. It's essential that the redline is legible for all parties and reflects their professionalism.

Moreover, it is not enough to see the structural changes between the versions. A lawyer needs to see the formatting changes between the versions as well which cannot be accomplished by diffing XML files.

>the commit atomicity and comprehensive history aren't supported by Word either, are they? That's just a function of maintaining 20 separate copies of the file with each set of changes.

Sure, you could, but that defeats the purpose of Google Docs which is to make the document collaborative. If you save each iteration in a different Doc, you might as well use Word.

It would also add friction to the workflow because a lawyer would need to download the document from Google Docs whenever they circulate it to a client or counterparty.

The best solution to the problem, in my opinion, is a docx native version control system. I write about how that works in our product Version Story in "On Building Git for Lawyers."

https://theredline.versionstory.com/p/on-building-git-for-la...

I completely agree.

On the Google Docs front — I wrote specifically about its viability as a Word successor in an earlier post, "Why Lawyers Will Never Use Google Docs".

https://theredline.versionstory.com/p/why-lawyers-will-never...

Yes, exactly. A successor could theoretically replace Word, but first it needs to replicate all of its existing functionality.

For a competitor to supplant Word, it would need to:

- Be fully backwards compatible with .docx. Lawyers will inevitably receive .docx files from counterparties that they need to review, redline, and mark up. The new processor has to handle everything Word does flawlessly. (As an engineer who has spent considerable time building a high-quality docx comparison engine, I can tell you this is tremendously difficult.)

- If it introduces a new file format, support seamless comparison and conversion between that format and .docx. Not technically impossible, but also tremendously difficult with marginal upside.

- Defeat the Microsoft Office bundle in the market — meaning it either offers enough advantage that organizations pay for both, or it replaces Excel, PowerPoint, and Outlook too.

Given the enormous challenge of building a viable Word competitor and the marginal room for improvement that Microsoft has left on the table, I think it's very unlikely that a competitor will threaten its market position.

HTML can represent a docx file in a web application but it can never replace docx. Docx files are a protocol for sharing documents between lawyers. I go into more detail on that in the "Docx is a protocol, not a filetype" portion of the essay.

https://open.substack.com/pub/versionstory/p/on-the-immortal...

Version control + binary file support is of limited utility for lawyers. They need to see what's changed from version to version, including formatting changes. This is why we spent years building out the document processing technology needed build version control for Microsoft Word.

I write a lot more about it in an earlier essay, "On Building Git for Lawyers."

https://theredline.versionstory.com/p/on-building-git-for-la...

I'm sure ODT works well for many personal use cases, but can guarantee it will never see adoption in the legal industry. Microsoft Word is the only viable option for lawyers.

I actually wrote a detailed breakdown of why Google Docs doesn't meet lawyers' needs!

https://theredline.versionstory.com/p/why-lawyers-will-never...

The short answer is Google Docs: - Requires all-or-nothing adoption which is a non-starter for law-firms - Does not support commit atomicity - Does not store a comprehensive history of the document