HN user
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
Thank you! I agree that it's an underrated tool.
Last November, I published "On Building Git for Lawyers" (https://news.ycombinator.com/item?id=42137391) about building Version Story, the first concurrent version control system for lawyers. Overwhelmingly, the response to my essay was positive! Many people across industries empathized with the problems we’re solving. One response stood out, however. Can’t lawyers just use Google Docs?
In this essay, I address this question and argue that the legal workflow requires a fundamentally different technology solution than what Google Docs provides.
Let me know if you'd like to try Version Story! I'm happy to add you to our whitelist.
That's the goal!
Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
We've designed our product to be backwards compatible with existing workflows. It does not require every team member to use the product to add value. Partners who prefer their way of doing things can continue to do so allowing associates to add their drafts to Version Story to create redlines and consolidate changes.
specialists edits get rejected because they don’t know the deal points and are just swooping in
The possibility of incorrectly rejecting specialists edits exists with or without Version Story. Our product makes it easier to understand what's changed so lawyers can exercise their judgement about these decisions.
Third big flaw in the product: big law firms are the least innovative organizations on earth
I think this assumption is worth challenging. Millennials are becoming partners at law firms and are spearheading initiatives to update their tech stacks. This is reflected in legal tech budget growth trends (https://www.legalcurrent.com/tech-spending-remains-especiall...).
Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
Making mistakes is not a feature (https://newsletterhunt.com/emails/40489). In the example I outline in the essay, the lawyer made three separate mistakes when manually merging documents.
the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked
This depends a lot on the practice. Transactional lawyers working in M&A and real estate encounter the issue of parallel drafts all the time. Personal injury lawyers tend to work in isolation and don't need all of git's functionality. Pretty much every lawyer redlines in some capacity, however, and benefit from visualizing a linear version history.
And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
Yes, this is absolutely correct. This is one of the main things that keeps docx entrenched as the standard in legal collaboration. It would be an enormous faux-pas to send another lawyer a contract in an application that they're unfamiliar with. Backwards compatibility with their existing workflows is essential.
I think a lot of people unfamiliar with docx think of it as effectively the same thing as any other rich text format. Because of that, they assume converting it to other formats is trivial, not realizing that other formats support a small subset of the functionality docx does.
Definitely. Finance professionals, academic researchers, legislators, among many other professionals, encounter similar version control issues. We are currently focused on law because of our domain expertise and because the problem is particularly pronounced in the law.