Lots of effort has gone into testing against real world docs. Its beta quality right now.

https://github.com/think41/extrasuite

The hypothesis is that llms are better off getting the "big picture" by reading local files. They can then spend tokens to edit the document as per the business needs rather than spending tokens to figure out how to edit the document.

Another aspect is the security model. Extrasuite assigns a permission-less service account per employee. The agent gets this service account to make API calls. This means the agent only gets access to documents explicitly shared with it, and any changes it makes show up in version history separate from the user's changes.

Early release can be found over here - https://github.com/think41/extrasuite.

re. what happens if its a big book - each "tab" in the google doc is a folder with its own document.xml. A top-level index.xml captures the table of contents across tabs. The agent reads index.xml and then decides what else to read. I am now improving this by giving it xpath expressions so it can directly pick the specific sections of interest.

Philosophically, we wanted "declarative" instead of "imperative". Our key design - the agent needs to "think" in terms of the business, and not worry about how to edit the document. We move all the reconcilliation logic in the library, and free the agent from worrying about the google doc. Same approach in other libraries as well.

While ChatGPT / Claude etc can create the initial versions of the files, the real complexity is in the workflow after the initial version. Team members add comments to provide feedback, or you decide several days later to make minor edits. Re-generating the entire sheet or doc is just not feasible. Our team members resorted to manual edits.

We looked around for a library to edit google drive files. We found gspread for google sheets - and our first version used it. It worked well - but it used way too many tokens. Every change required writing python code. This led to the first version of `extrasheet` - which pulls a spreadsheet and converts it into data.tsv, formula.json and several other files. Initial versions duplicated the formula in every cell for a column; subsequently we detected a formula was the same for a range and automatically compress it. Result - our teams were able to make more complex excel models, make targeted edits and perform analysis using fewer tokens and less capable models.

Subsequently, we followed the same approach for google docs. This turned out WAY COMPLEX. The batchUpdate API for google docs in insanely complex - you have to painstakingly compute the index. `extrasuite doc push` now detects changes, computes indexes, resolves internal dependencies and ultimately pushes the changes only to google docs.

As usage increased, we added google slides (this is pre-alpha), google forms, and even app scripts - all using the same pull-edit-push workflow.

One more differentiator is the usage of service accounts for the agent. The SA has no permissions other than the ability to read/comment/edit the specific files that have been shared with it. This means that agent edits are completely auditable. It is clear to everyone in the team that "Alice used her agent to write this document" - because it shows up clearly in the documents version history.

To achieve this service account, we deploy a lightweight gateway server that mints 1:1 service accounts per employee on demand. This isn't scalable as there are limits to how many service accounts you can create in a google cloud project (typically 100) - but this hasn't been a problem for us as yet.

The gateway server is strictly optional. You can download service account JSON keys and use it to authenticate if you wish, but we dislike giving keys to employees. A gateway server simplifies the workflow significantly for non-tech users.

Try it out, and hopefully it is of use to others.

P.S. This complements gog and gws, does not replace it. Neither of those tools has a workflow to perform in-place complex edits in a declarative manner.

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

Points: 1

# Comments: 0

It provides a git like pull/push workflow to edit sheets/docs/slides. `pull` converts the google file into a local folder with agent friendly files. For example, a google sheet becomes a folder with a .tsv, a formula.json and so on. The agent simply edits these files and `push`es the changes. Similarly, a google doc becomes an XML file that is pure content. The agent edits it and calls push - the tool figures out the right batchUpdate API calls to bring the document in sync.

None of the existing tools allow you to edit documents. Invoking batchUpdate directly is error prone and token inefficient. Extrasuite solves these issues.

In addition, Extrasuite also uses a unique service token that is 1:1 mapped to the user. This means that edits show up as "Alice's agent" in google drive version history. This is secure - agents can only access the specific files or folders you explicitly share with the agent.

This is still very much alpha - but we have been using this internally for our 100 member team. Google sheets, docs, forms and app scripts work great - all using the same pull/push metaphor. Google slides needs some work.

Another thing I do is ask for the claude session log file. The inputs and thought they provided to claude give me a lot more insight than the output of claude. Quite often I am able to correct the thought process when I know how they are thinking. I've found junior developers treat claude like a sms - small ambiguous messages with very little context, hoping it would perform magic. By reviewing the claude session file, I try to fix this superficial prompting behaviour.

And third, I've realized claude works best of the code itself is structured well and has tests, tools to debug and documentation. So I spend more time on tooling so that claude can use these tools to investigate issues, write tests and iterate faster.

Still a far way to go, but this seems promising right now.

In short, with 1 GET API call that uses 3 SQL queries, you are getting a list of questions, related answers and related comments.

You should parse that example as follows - 1. The first SQL query fetches all the questions, filtered by API parameters 2. The second SQL query fetches all comments for the questions selected in the first query. See the `WHERE c.postid in {{ questions.id | inclause }}` part - questions.id is coming from the output of the first query 3. The output of the first and second query is merged together on the basis of the questionid that is present in both the query output. 4. Similar approach is used for all the answers

GraphQL is great during development, but in production you often use "persisted queries" to prevent abuse. Persisted queries are also a way to use HTTP GET instead of POST, and thereby leverage HTTP caching. As such, if you swap out graphql and use sql during the development phase, you perhaps can get similar benefits.

My solution (https://github.com/hashedin/squealy) uses SQL queries to generate the API response. Squealy uses a template language for the sql queries, so you can directly embed where clause from the API parameters. The library internally binds the parameters, and is free from SQL injection.

Handling many-to-many relation, or many one-to-many relations is done in-memory after fetching data from the relational database. This provides the same flexibility as GraphQL, but of course requires you to know SQL.

Here is an example that builds various StackOverflow APIs using just a YAML+SQL based DSL - https://github.com/hashedin/squealy/blob/master/squealy-app/...

Squealy is still work in progress, so don't use it in production. But I would love to get some feedback!

JinjaSQL is a templating language, so you can use interpolation, conditionals, macros, includes and so on. It automatically identifies bind parameters, so you don't have you to keep track of them.

1. https://github.com /hashedin/jinjasql

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

Points: 3

# Comments: 0

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

Points: 3

# Comments: 0

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

Points: 1

# Comments: 0

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

Points: 3

# Comments: 0

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

Points: 2

# Comments: 0

Re. Guide comments - I usually try to make a smaller function with an appropriate name and then call the function. So long function become a series of invocations to smaller functions. This eliminates most guide comments IMO.

Lolwut is the perfect break from madness.