Does emdash also help making the setup secure by isolating the agent from my local environment? This is more than just git worktrees.

Or do you consider this orthogonal to what emdash attempts to do?

No Datepicker?

As pointed out in another comment, it's under the form elements, not listed as a top-level component as many UI libraries do

https://oat.ink/components/#form

Which actually makes sense: Oat's driving philosophy seems to be to use and enhance native controls as much as possible, and the date picker is already a native type on the input element.

But there's no enhancement here. That's just the native date picker control with a bit of styling on the textbox portion of it.

Thanks, I missed that when looking through the component list on the top level.

I'm not a web dev, but doesn't HTML come with a date picker?

HTML also comes with a button and an accordion.

I would like to see the following published:

- 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.

Yes unfortunately these days most are satisfied with just the sausage and no details about how it was made.

Just claims with nothing to back it. Steal people's work of years, and turn around be like I make it "so much better". Support this compiler for 20 years then

What I missed when trying it was a simple way of accessing private repositories. There does not seem to be ssh agent forwarding, or is there? What do people use?

I realize this is all very fresh, but still wondering…

Did you ever find an answer? Other than copy/pasting my priv/pub keys into ~/.ssh/ I'm not sure.

> Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console.

They are advocated as Linux machines. How about daemons then, or cron jobs? What semantics can we expect from them?

This is a good concise summary, regardless of provenance.

It is really important that such posts exist. There is the risk that we only hear about the wild successes and never the failures. But from the failures we learn much more.

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.

>> This doesn’t seem to exist in this case, which may simply be the deal breaker.

Perhaps, but perhaps not. The reason tests are valuable in these scenarios is they are actually a kind of system spec. LLMs can look at them to figure out how a system should (and should not) behave, and use that to guide the implementation.

I don’t see why regular specs (e.g. markdown files) could not serve the same purpose. Of course, most GitHub projects don’t include such files, but maybe that will change as time goes on.

> I don’t see why regular specs (e.g. markdown files) could not serve the same purpose.

I think because they're doomed to become outdated without something actually enforcing the spec.

What tooling are you using for the orchestration?

Quick feedback: both the „learn more“ link at the very top and the „Explore all examples“ link lead to 404

Thanks will fix that up shortly.

There is one feature in Claude Code which is often overlooked and I haven't seen it in any of the other agentic tools: There is a tool called "sub-agent", which creates a fresh context windows in which the model can independently work on a clearly defined sub-task. This effectively turns Claude Code from a single-agent model to a hierarchical multi-agent model (I am not sure if the hierarchy goes to depths >2).

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.

conscious decision not to include it mostly to cut a release we could ship to land yesterday ;)

various forms of this are being discussed, this commentary is helpful thanks!

Injecting ENV variables into the template would be super useful.

Would Gemini non-interactive mode be a stop gap if they don't have sub-agent equivalent yet?

https://github.com/google-gemini/gemini-cli/blob/main/docs/c...

Possibly. One could think about hooking this in as a tool or simple shell command. But then there is no management when multiple tools modify the codebase simultaneously.

But it is still worth a try and may be possible with some prompting and duct tape.

"sub-agent" sounds incredible! All tools should implement that.