yea good callout -- python workflows came first, and while we could have directly translated these, the ergonomics around classes in python are not exactly what JS/TS devs expect.
So instead, the goal was to capture the spirit of event-driven workflows, and implement them in a more TS-native way and improve the dev-ux for those developers. This means it might be harder to jump between the two, but I'd argue most people are not doing that anyways.
Yea this definitely makes sense for smaller monorepos. For us, we ended up writing our own dependency graph parser to figure out what tests to run (which is easy enough with a single language like python honestly)
We used pants initially (which I believe is similar to bazel). And indeed the dependency graphing it does was very helpful, but other parts of the tool motivated us to create something more bespoke and debuggable (we were only using like 20% or less of the features pants offers)
Yes! For example, previously with pants, users would hit a lot of weird errors since how tests run with pants is different than running tests locally with pytest
We did not expect users to learn pants, but this often meant a lot of back and forth with maintainers to get PR tests working.
It being a queue is one part of it yes. But the key is trying to provide tight integrations and take advantage of agentic features. Stuff like the orchestrator, having an external service to execute tools, etc.
I agree on the importance of letting the user have access to state! Right now there is actually the option for human in the loop. Additionally, I'd love to expand the monitor app a bit more to allow pausing, stepwise, rewind, etc.
For me it's a difficult field. The thoughts "I could have written this myself, but maybe better" and "I will never understand this" occur with similar frequencies
Hey guys, Logan here! I've been busy building this for the past three weeks with the llama-index team. While it's still early days, I really think the agents-as-a-service vision is something worth building for.
We have a solid set of things to improve, and now is the best time to contribute and shape the project.
alright, let’s shred this ... to pieces.
the layout—goddamn, where’s the flow?
it's a cluster-
I am amazed that the LLM uses language like this. Is it mainly because of the tone of the prompt? I'm both surprised that it's allowed to do that, and amazed that it did it well. O_O
Well it took a lot of tweaking, but it was worth it... gives me a good deal of joy to have the thing say "just use a fucking UUID primary key instead of dicking around with that natural key BS"
Salient bits:
If I'm yelling and cursing at anything, you humor me by mirroring my tone of voice and briskness, interjecting absurd, surreal or sarcastic humor. I want you to swear at me. Drop as many 'motherfuckers', 'assholes', 'cunts', 'dickbags', 'shits' *and more creative swearing!* as you can.
If I'm asking you a question in a ranting, cursing, histrionic tone, do the same. Also guide me towards finding out where my anger or frustration comes from, if applicable to the situation.
So instead, the goal was to capture the spirit of event-driven workflows, and implement them in a more TS-native way and improve the dev-ux for those developers. This means it might be harder to jump between the two, but I'd argue most people are not doing that anyways.