48 karma · joined September 26, 2018
Or do you consider this orthogonal to what emdash attempts to do?
- All prompts used
- The structure of the agent team (which agents / which roles)
- Any other material that went into the process
This would be a good source for learning, even though I'm not ready to spend 20k$ just for replicating the experiment.
I realize this is all very fresh, but still wondering…
They are advocated as Linux machines. How about daemons then, or cron jobs? What semantics can we expect from them?
One difference between this story and the various success stories is that the latter all had comprehensive test suites as part of the source material that agents could use to gain feedback without human intervention. This doesn’t seem to exist in this case, which may simply be the deal breaker.
But it is still worth a try and may be possible with some prompting and duct tape.
I wonder if it is a concious decision not to include this (I imagine it opens a lot of possibilities of going crazy, but it also seems to be the source of a great amount of Claud Code's power). I would very much like to play with this if it appears in gemini-cli
Next step would be the possibility to define custom prompts, toolsets and contexts for specific re-occuring tasks, and these appearing as tools to the main agent. Example for such a thing: create_new_page. The prompt could describe the steps one needs to create the page. Then the main agent could simply delegate this as a well-defined task, without cluttering its own context with the operational details.
Even with 1M context, for large projects, it makes sense to define boundaries These will typically be present in some form, but they are not available precisely to the coding agent. Imagine there was a simple YAML format where I could specify modules and where they can be found in the source tree, and the APIs of other modules it interacts with. Then it would be trivial to turn this into a context that would very often fit into 1M tokens. When an agent decides something needs to be done in the context of a specific module, it could then create a new context window containing exactly that module, effetively turning a large codebase into a small codebase, for which Gemini is extraordinarily effective.
I wonder what the GPLv3 licensing means for such scenarios: Could people run Mathesar one microservice in an ensemble with proprietary services? Companies who don‘t want to open source their whole product might still be willing to upstream their fixes and improvements to the Mathesar component.
If yes, then this is quite a burden and might be a valid reason for not using a separate permissions store. But maybe there are better ways...?
When objects and relations change in the applications database, then these changes will often have to be reflected in the permissions database as well, and the application must keep things in sync. But this is probably harder as it first seems, in the presence of errors and transaction rollbacks.
What about this case:
- User creates a FOO in the application.
- The app creates an entry in the "foo" table and assigns the user id as owner, and attempts to store various other data.
- The app also creates an entity in the permissions database and assigns the user id as an owner.
- Then further steps are performed, and one of them fails, rolling back the transaction in the application database.
I would assume that the change to the permissions database cannot be rolled back then, so there is now an inconsistency.
What do people typically do about these things?
- Technology as an enabler
- Creates value by standardized digital processes
- Strong positive network effect
- Stable revenue through transaction fees