We (harriethq.com) also have a somewhat similar insight, which is that setting up connectors is a drag for non-technical users, and a lot of systems don't support per-user connectivity so need an API shim.

The thing I like about this (Agent Vault) approach is that it's more extensible than what we're offering, which is a full managed service. But we've found that some features (e.g. ephemeral sandboxes to execute arbitrary e.g. uvx/npx based mcps) are just a big pain to self-deploy so it's easier for us to provide a service that just works out of the box.

Kudos to the team, this looks great and I'm looking forward to playing with it

All the Google Docs MCPs out there seem to be broken in annoying ways so I thought I'd make one. For instance they do character-offset-based editing and LLMs are reliably terrible at counting characters.

This one just works. (It uses the similar pattern-matching search and replace that code editor harnesses use for file editing to minimize token usage and latency).

There are some showstoppers still. The most annoying is that Google Docs comments API is has been broken for over a decade (sic). I (well, Claude) build a workaround that involves inserting a bookmark with the Apps Script API and linking to that bookmark from the comment. It's hacky but for a lot of LLM-based workflows like contract review or similar it gets you 80% of where you want to be - you can say something like "add comments and john@lawfirm.com for anything that you want their opinion on".

I hope people find it useful. Install involves the usual dance with Google Cloud API console; apologies in advance for taking some happiness from your day.

Comments URL: https://news.ycombinator.com/item?id=47865132

Points: 2

# Comments: 0

Sure, they could do that, but the cultural change required is an order of magnitude harder than just sticking an agent on top of their source-of-truth and believing that the problem is solved.

Maybe it works for areas where the application is a relatively self-contained island of productivity. Figma is somewhere that a designer spends a lot of their day, so it's going to be less vulnerable, but most pieces of softare fit into broader workflows. So for Figma the disruptor is less likely to be "AI-powered designer" and more "AI-powered web builder" - e.g. Lovable or even Claude Code itself that just generates great designs.

I assume we are talking

- China - maybe South Korea? - US (or is US not one of the 4?) - Russia (ok this is explicit)

I think there might be an interesting idea in here but there is some confusion that’s stopping it coming out

Can someone enlighten me?

IANAL but e.g. Claude Cowork is already good enough that it's hard to see how the legal tech startups are going to differentiate except around access controls, visual presentation of workflows, etc. And that's in a heavily enterprise/compliance-aware/security-focused context.

Don't get me wrong, that's still a big "except" - big enough for massive companies to be built. Personally the anxiety of being so close to being squashed by the foundation models would make me unhappy as an entrepreneur but looking at the market it seems like many people have a higher risk tolerance.

Now, that may not work in all jurisdictions for reasons of local taxation etc (and you'll have to work out payroll tax, benefits etc) but that's almost never anything to do with the legal entity type!

How is that different from trust erosion?

Re-read “The Art of Not Being Governed” by James C Scott which is really mind-expanding stuff.

I know the ecosystem not-at-all (sum total knowledge of the CAD ecosystem is that my kids got a Bambu printer for Hanukkah) but it feels to me that current LLMs should be able to generate specs for something like https://partcad.readthedocs.io/en/latest/, which can then be sliced etc.

Curious to know what others think? I come at this from the position of zero interest in developing the fine design skills needed to master but wanting to be able to build and tweak basic functional designs.

It does make you wonder, why not just be a lot smaller? It's not like most of these teams actually generate any revenue. It seems like a weird structural decision which maybe made sense when hoovering up available talent was its own defensive moat but now that strategy is no longer plausible should be rethought?

One of my tutors at university claimed that she was able to read 9th century manuscript Cyrillic faster than modern printed books because the orthography was more varied and easier to scan/speed-read.

(That wasn't something I found to be true)

However I think we should be thinking harder about how coding will change as LLMs change the economics of writing code: - If the cost of delivering a feature is ~0, what's the point in spending weeks prioritizing it? Maybe Product becomes more like an iterative QA function? - What are the risks that we currently manage through good software engineering practices and what's the actual impact of those risks materializing? For instance, if we expose customer data that's probably pretty existential, but most companies can tolerate a little unplanned downtime (even if they don't enjoy it!). As the economics change, how sustainable is the current cost/benefit equilibrium of high-quality code?

We might not like it but my guess is that in ≤ 5 years actual code is more akin to assembler where sure we might jump in and optimize but we are really just monitoring the test suites and coverage and risks rather than tuning whether or not the same library function is being evolved in a way which gives leverage across the code base.

Moscow’s street dogs are renowned for their intelligence. I have seen street dogs taking the escalators on the Metro. This dog worked out not just that the beeping + discomfort was worth the freedom, but also that he could wear out the battery faster by going up to the very edge of the fence - where the chirps became an uninterrupted beeeeep - and as soon as the beeping stopped, whoosh he was gone.

In practice high variance translates on the downside into failure to do basic things that a minimally competent human would basically never get wrong. In agents it's exacerbated by the compounding impact of repeated calls but even for basic workflows it can be annoying.

This is very interesting finding about how to improve capability.

I don't see reliability expressly addressed here, but my assumption is that these alloys will be less rather than more reliable - stronger, but more brittle, to extend the alloy metaphor.

Unfortunately for many if not most B2B use cases this reliability is the primary constraint! Would love to see similar ideas in the reliability space.

The most difficult part of the process (not dealt with in this version of Passport Application but maybe a future DLC pack?) was actually finding someone who could certify my evidence (you are meant to submit originals but they keep the docs including passports for 3-6 months which is a bit unrealistic if you are living abroad). I can't remember the exact rules but it wasn't possible to use a US notary or a normal solicitor certification process and instead I needed to go to a council office.

After calling about 5 councils all of whom disavowed any knowledge of the process or its requirements I ended up finding someone at Islington Council who was delightfully helpful. But it was one of the more frustrating UK government interactions I've had.