AI Agents, Open Source, and Modern Software Teams

Introduction

In this episode, Josh is joined by Evan Rusackas, Sr. Developer Advocate at Preset and a PMC member on Apache Superset, one of the largest and most active projects in the Apache Software Foundation. Evan spends his days on a repo that generates more valuable work than any human could keep up with, which makes him a useful person to ask a question most engineering teams are still circling: what actually changes when agents do the work, and what stays stubbornly human?

The conversation covers the mechanics of cutting Superset’s open issue count from roughly 800 to roughly 200 in a couple of months, why pointing a model at a repo and asking it to triage everything produces poor results, and how Evan splits a backlog into narrow buckets that each get their own treatment. It goes deep on where the approval boundary belongs, including a workflow where editing a YAML file from proposed to approved is the act that authorizes an agent to move, and a skill trained on Evan’s own past comments so that drafted replies sound like a person rather than a bot.

The second half turns outward, to Evan’s argument that individual speed gains create silos and that every organization needs an AI enablement engineer whose responsibility is lifting everyone else. It closes with a walkthrough of Agor, Preset’s open source multiplayer canvas for orchestrating coding agents, and the least automatable piece of advice in the episode.

Episode Highlights

• [00:01:51] Seven years maintaining the most starred repo in the Apache Software Foundation
• [00:02:49] From roughly 800 open issues to roughly 200, and how the backlog was split to get there
• [00:05:17] Why leaving a new contributor’s commit in the history matters more than the code
• [00:06:24] Fixing things upstream instead of patching them locally
• [00:08:20] Building the right piles of work: if your computer isn’t working overnight, you’re doing it wrong
• [00:10:24] A skill trained on your own writing so bot-drafted comments don’t sound like a bot
• [00:12:44] A YAML file as the approval gate: proposed to approved is the authorization
• [00:14:41] Mixing mechanical GitHub metadata rules with subjective LLM judgment
• [00:16:29] Several versions of the matrix: from a whiz-bang UI to an ugly, fast one
• [00:21:08] Losing git worktrees, and why the ratio makes it not matter
• [00:24:45] Guardrails in practice: Docker bubbles, git-only access, and a scoped GitHub token
• [00:28:22] The case for an AI enablement engineer in every organization
• [00:33:49] An Agor walkthrough: zones, worktrees, shared sessions, and a Slack gateway
• [00:46:29] Closing advice: the thing your bots will never do is say thank you

Episode Transcript

Josh Lee [00:00:10]

Hello, hello, hello, and welcome, everybody, to our ninth episode of Unevenly Distributed. I am your host, Josh Lee. I am a Developer Advocate at Altinity. I am joined by Evan Rusackas, who works at Preset. So Evan, welcome. Thanks for joining today.

Evan Rusackas [00:00:27]

Yeah, hi. Thanks for listening or watching, whatever the case may be. I’ve been working with Preset for about seven years. Preset.io if you want to check it out. We’re in the analytics space, providing all the agentic analytics and data visualization stuff you could ever need.

,All built on top of Apache Superset, which is a repo I maintain as an ASF member and a PMC member of that project. It’s the open source BI analytics tool that you should be using.

I’m also working on a new project called Agor, which is a whole wonderland of agentic opportunities for engineers and business users that want to build Slack bots, all these kinds of things. So happy to talk about all of this stuff, and about maintaining open source and being a good steward of community.

Josh Lee [00:01:21]

Yes. Yeah. It’s definitely a new world, right? The phrase “brave new world” has come up for me a lot in conversations, and it depends which source you’re actually quoting that from, whether it’s positive or negative.

Evan Rusackas [00:01:36]

The new world, whether you’re brave or not.

Josh Lee [00:01:38]

So yes, you mentioned Superset, which is the open source project sort of underpinning everything that Preset does, and you’re one of the maintainers of Superset.

Evan Rusackas [00:01:51]

Yes. Right. Yeah. I’ve been working on that repo for seven years I guess, and it’s been ramping up a lot over the years as my job has been Developer Advocate for the last few years. So I’ve always been trying to help people along with their work, as well as doing my own, just whatever needs to be done on the repo.

The repo is very large, very active. It’s the most starred repo in the Apache Software Foundation and somewhere around number 200 on all of GitHub. What that really means from my day-to-day is you get a whole lot of issues filed. You get a whole lot of PRs opened, and all kinds of people having all kinds of stuff that leads to this gigantic pileup of valuable work that in earlier days would just kind of get shuffled away or forgotten or ignored.

And we’re in a phase now with AI backing everything we do. So I’ve found I’m able to move a whole lot faster and sort through the pile. Just in the past couple of months we’ve gone, for example, from somewhere around 800 open issues to somewhere around 200, and it’s dwindling faster as the pile gets smaller, which is great. So kind of trying to get to that inbox zero mentality.

Josh Lee [00:03:13]

So it’s a little bit of a race, right? Because all of your contributors started using AI and that’s what led to those 800 open issues in the first place, right?

Evan Rusackas [00:03:22]

Well, not necessarily. Some of it was actually very old.

Josh Lee [00:03:25]

Okay.

Evan Rusackas [00:03:26]

The pile was coming in faster than ever, for sure. So we had to keep up with the new influx of AI contributions, but at the same time we had the giant backlog of long tail stuff that had been set back or set aside for, in some cases, years.

And those things are valuable. In some cases the bugs are real or the PRs are good. Not always. Some of them just needed sprucing up because the contributor vanished into the wind or something like that. But now, with all of this horsepower we have behind us, it’s actually quite possible to go in there and patch up all the old work and triage all those old issues and things like that. To catch up with the old stuff and eat away at that pile, while also doing kind of continuous triage and fix up of all the new things that flood in. So it’s really eating at this thing from both sides.

Josh Lee [00:04:25]

Okay. Yeah, that’s really cool. So you were successful. I mean, that’s awesome that you were able to go from 800 to 200.

Evan Rusackas [00:04:33]

Yeah, a similar number of PRs, too. So a lot of work to shepherd through, not just issues to triage. I’ve been just on a rampage for months now of rebasing PRs that grew conflicts over longer periods of time. If people don’t know how to fix issues that happen on CI with linting or tests or whatever, it’s now pretty easy to just patch things up for them so they can get it across the finish line. Just kind of lend a helping hand to everybody that wants to help but doesn’t necessarily know all the process and procedure and stuff to get their work to that bar that we expect.

Josh Lee [00:05:17]

That’s such a valuable part of being a maintainer. The first open source contribution that I ever made on GitHub, to a repo maintained by someone other than myself, the maintainer of the project actually completely rewrote my PR. But they left my commit there. So I have that commit in the history, and that’s a huge part of building a community.

Evan Rusackas [00:05:40]

Let me ask you this question, because it’s interesting. Did you mind, or did you like it that they got their work?

Josh Lee [00:05:45]

No, I was honored that they left my commit there. I clearly didn’t understand the codebase and the way that I had executed it. I needed a fix for a really, really weird compatibility issue and I kind of shoehorned my fix in there. At first the maintainer was like, “We don’t really need this, because who needs this?” I was like, “No, I have this really weird compatibility issue, but it’s actually with Microsoft Excel.” So yeah, it needs to be fixed.

And then he was like, “Okay, this is how to properly do it.” But he left my commit in the history, and I was honored that that was the history of me being the person who discovered that rough edge of that version of Excel.

Evan Rusackas [00:06:24]

Yeah, that’s fantastic. And I’m actually kind of curious about that, because I’m finding myself more and more in those shoes, and I’m contributing to more upstream projects.

So for those that don’t know Superset or Preset, the whole interface of this analytics and BI tool is built around SQL. There’s a whole long story to that, but at the end of the day we find a lot of little SQL issues with database drivers and DB engine specs and SQLGlot and stuff like that, because we support like 90 different databases and there’s edge cases everywhere.

So we’ve had a lot of PRs over the years that just kind of patch things up in a custom DB engine spec or something like that. And as I start looking at more and more of the new PRs and how they’re wired up to the core codebase that we maintain, I’m seeing, oh, this is something that should be, or could have been, fixed upstream on SQLGlot or some random database driver, you name it.

So more and more I’m starting to contribute those fixes upstream, and it’s very interesting to see how different maintainer communities handle these things. Some people are like, yeah, whatever, tests are good, bring it on in. And some people are real sticklers, saying all PRs must be small and must be this particular way. So the level of OCD varies project to project. But it’s very cool to see how other communities handle new contributors, because it affects how I handle our new contributors, and it’s a good lesson to learn.

Josh Lee [00:08:04]

Definitely. Yeah. What have you actually done for yourself that you were able to sort this out and get ahead of this, both the incoming avalanche and the backlog that never shrinks?

Evan Rusackas [00:08:20]

Yeah, so it’s a whole pile of stuff. There’s the technology to discuss, perhaps, and then kind of the methodology as well. I guess everybody’s using some LLM, some IDE or chat tool or whatever it is. There’s a million tools now to do the engineering work, which is fantastic. And we can all open a PR a hundred times faster than we ever could before. Hooray.

So now, how do I build the right piles of work for these things to do, and organize a workflow that constantly chews at it? One thing I like to say is, if you don’t have your computer working all night for you while you’re sleeping, then you’re probably doing it wrong. A lot of people I think just sit there in their silo and say, do this and wait, and do that and wait, and do another thing and wait. When really it should be like, okay, here’s a pile of stuff, and you machine and I human need to have some sort of interface where I can kind of co-triage with you and say yes, do this, no, don’t do that.

So I’ve been breaking this work into piles and building up a bunch of skills for the models to play with, and scripts that they can use, and a whole bunch of stuff to cater to different segments of my laundry list. Which might be my own work, which I could be very heavy-handed with. So I just want to be able to have those automatically address all review comments, assess them, fix them if warranted, reject them if not, mark them as resolved, push the stuff, and just kind of keep my PRs rebased and up to snuff.

But then other people’s, I don’t want to have to get a bot review and sound like a bot on the repo. So I’ve been doing things like building a skill that is my writing voice. You can have Claude or Codex or whatever go through all of your human era comments on a repo, or your blog posts, or whatever you’ve written, and say, “This is how I write.” Build up a corpus of my writing style and then create that skill. So when you suggest a PR comment for me to post on someone’s work, make it sound like me. And that’s been very valuable.

And then in these tools that I built, these workflows, there’s always new stuff to work on. And as it suggests comments, I can hand edit those. I could show this stuff if you want. It’s not the prettiest thing in the world, but I’ll edit them by hand to say, okay, this is how I would actually write it. And then with each turn it learns a little more. So it’s kind of dialing itself in as we go.

But I also have all the little check boxes of rebase this, address comments on that, merge block, fix CI, fix pre-commit, all these little things that are the common problems. I have skills for them and I can just check little boxes and say, do that. So it means I can just sweep through a hundred PRs in half an hour and move them all along one step.

Josh Lee [00:11:47]

Now when that actual comment gets posted, you haven’t given the bot access to post that, right? The agent isn’t posting it. It sent it to you for review, and there’s some kind of web server or harness that’s making that final call on your approval.

Evan Rusackas [00:11:58]

Yeah.

Josh Lee [00:12:00]

Okay.

Evan Rusackas [00:12:02]

I have a few different places I do this kind of stuff. I do a lot of it in Agor, which is our agentic product that Preset is building and launching as an open source thing.

Josh Lee [00:12:11]

Very cool.

Evan Rusackas [00:12:13]

Check out agor.live. But also I have some local stuff where I built my own launcher using macOS that fires up something tmux-ish using iTerm, and I have a bunch of terminal sessions where I’m constantly tweaking on stuff. As soon as the code stops scrolling, I know I need to go do something.

But one of them is running this constant triage, and it has a server, and it maintains this big YAML file, and that YAML file feeds a UI. So I’m looking at the UI, and whenever it triages, say, a new issue that landed, it suggests a comment, suggests some actions that I can click buttons on. And then when I click those buttons or edit the action in the UI, I’m basically giving it approval by editing that YAML file.

So the YAML file is approval. I’m still the human in the middle, but the fact that YAML changed from proposed to approved means take it and do it. Whether it’s a mechanical thing via the GitHub API, or something more agentic like do the rebase with a subagent.

Josh Lee [00:13:27]

Okay, so that’s really cool, because I think some people that I’ve spoken to would point Claude at their repo and say, triage my issues, make no mistakes, right? And just kind of hope for the best. And I don’t think you’re going to get good results that way. So you do have to have these deterministic flows. But then it does sound like you do have a model plugged in at the heart of that, doing the core triage task.

Evan Rusackas [00:13:51]

Yeah. Yeah. And those little things like loops and dynamic workflows and all of that, that are built into Anthropic products and probably others, are kind of what it’s all built on.

So yeah, and it’s not just like go through my repo and look at all the issues. That’s way too broad. So it might be issues that haven’t been touched in longer than 30 days, and they’re treated one way, or new issues that haven’t been triaged by anybody else, or issues that do or don’t have a PR targeting them to close it. They each have kind of a different signal and need a different sort of triage and a different sort of response. So they each have nuance.

Josh Lee [00:14:34]

And so did you build these different flows as deterministic, or how is that defined? Is that in a skill, or is it in something deterministic?

Evan Rusackas [00:14:41]

It’s a mixed bag. So some are very deterministic based on the GitHub metadata you can grab when you look at the issues themselves, like how long since its last updated at a timestamp. That’s a factor that’s very mechanical. But some of them are more subjective, and there’s a little bit of an LLM decision in them of, is it something I’m going to care about, is it important to others, is the bug valid, is it something I should or could write a test PR for?

That’s a whole other pile. For example, when I look at old PRs, figure out if they’re TDD candidates. Is it something I could validate an old unvalidated issue with, with just putting up a PR with some tests? If the tests pass, the issue closes. If it doesn’t, then it goes into another queue, and that’s one where I’d actually provide the fix. So, yeah.

Josh Lee [00:15:38]

Were these triage flows more or less doing the same things that you were already doing as part of your triage flow?

Evan Rusackas [00:15:46]

That’s exactly it. I’ve been having that mentality of, if I were to hire someone to do my work, how would I onboard them? How would I have them break up their day, break up their work, build a process? In any business, you should always think about how you would hire someone to replace yourself if you had the opportunity. And that’s definitely how I think we should be thinking about our agentic workflows. Just treat it like your own little team that works the way you work, and you’re just the feedback mechanism, the person in the loop saying prioritize this, that doesn’t look right, all that kind of stuff.

Josh Lee [00:16:22]

Yep. So how did you iterate to get to the point that you’re at, and how do you incorporate new improvements into the system without breaking it?

Evan Rusackas [00:16:29]

I have built several versions of the matrix. There were early attempts that were too broad and were trying to do too much with too little guidance on the buckets that I want to work on. And then I went a little too wild with trying to build up some super whiz-bang UI that had tabs and kanbans and fancy stuff, and I was like, okay, this UI actually isn’t speeding me up. It’s pretty, but it doesn’t help, and it’s just another thing to maintain.

So now, where I’m at, I’ve got a pretty ugly but functional workflow that’s very quick for me to use. It’s self-aware. It doesn’t have to be pretty. It doesn’t have to work for others. I’m not making a product of it.

But also, more importantly, that was all happening concurrently with the launch of Agor, this agentic product. And so now it’s model-agnostic, so I can use Codex and/or Claude. I can have them talk to each other. I can switch between models mid-session. All this kind of fancy stuff. So I’m building all of this stuff that I built locally into there.

So not only can I continue to use it in a place that’s maintained and not burning my own CPU so much, but also I can share it with others. Because that collaborative piece of taking the stuff that I’ve learned and built, and enabling others to use it as an AI enabler, is equally important. I’m moving a hundred times faster than I ever have. So how can I help the other people on my team move equally fast, or even faster? They can probably contribute to what I’ve built and make it better still. So that force multiplier thing is the obvious next step.

Josh Lee [00:18:20]

That’s really cool.

Evan Rusackas [00:18:24]

Yeah. Yeah. And I guess there’s so many directions to answer that question from, but the software part of building your own tools can extend in any number of directions. Typing into these things gets tedious to me. So I built my own little Mac application that does speech-to-text, because there’s a lot of off-the-shelf products like this now.

Wispr Flow is great, and I was using it, but I was like, do I really need to pay for something that’s going to send my voice to the cloud for somebody else to process and store, so it can type into my chatbot or whatever? And I was like, I could just build this. The Whisper model is open source. So a little local Mac app now does my typing for me, and that’s another speed doubler, which is great. It might sound crazy talking to my computer all day, but it works.

Josh Lee [00:19:16]

This is the new amazing world, right, that we have these self-updating tools almost. You can ask your Mac for a Whisper clone and have one pretty quickly.

Evan Rusackas [00:19:28]

Yeah.

Josh Lee [00:19:30]

The AI is not doing our jobs for us. It’s doing all the things we didn’t have time to do because we were busy doing our jobs. Although in your case it is also doing a big part of your job, or making it easier.

Evan Rusackas [00:19:42]

So that’s, yeah. So what is our job now, and how much do we do? It’s kind of a funny thing.

Josh Lee [00:19:47]

Well, I think a lot of it is the decision-making. Just because something can be done doesn’t mean that it should be done. And I think that’s where I had a mirror experience to what you described, where you started with too broad of a problem space that you handed over to the AI without enough buckets and instruction and guard rails, or even rails of any kind.

And yeah, that’s what I find myself doing all day now, is just deciding what should be done and what’s worth putting more effort into.

Evan Rusackas [00:20:24]

Yeah. Man, that’s the funny thing I think many of us face, particularly if you’re like me, the ADD type. You’ve always had this itch to work on a bunch of things in parallel. And now it’s never been easier.

So not only is it a bottomless pit from the start, but everything you look at, you find three more things underneath it, and you’re like, oh, I can work on these too. And before you know it, I don’t know, I guess it’s the new form of workaholism, but it’s kind of fun. I’m working too much at night. I fully admit it. And I work on the weekends when nobody’s looking. I admit it. But gosh, I’ve never had so much fun working, but I’ve also never worked so hard or so long. It’s kind of a mixed blessing.

Josh Lee [00:21:08]

Have you lost any git worktrees this… do you use git worktrees?

Evan Rusackas [00:21:11]

Oh, yeah. Yeah.

Josh Lee [00:21:12]

Have you lost any worktrees this week?

Evan Rusackas [00:21:14]

That’s a good question. Probably one or two, but it’s largely self-corrected. My problem is more likely the cleanup of the old ones.

Josh Lee [00:21:25]

Yeah. No, this is the thing, right? That’s the ratio. You lose one or two, but it doesn’t matter, because you did 10 when before you would have done three. And you can redo them, and probably better than you did the first time, because the model’s going to have some memory of how it did it.

Evan Rusackas [00:21:42]

Yeah. Yeah. I actually did, for the first time in all of this stuff, run into two of my own PRs that were basically doing the same thing. They came in from different angles. One was kind of adopting somebody else’s work, which is one of my little skills: okay, this PR is stuck, let’s just adopt it, give them credit. But then one was just from some other GitHub issue that was kind of a duplicate issue filed. So duplicate PRs, and it’s interesting to have your own little bakeoff competition. What a wild thing.

Josh Lee [00:22:14]

Yes. Yeah. No, that is fun. You can absolutely do that. So it sounds like you’re using a coding harness like Agor, or you’re basically doing what I call now the new version of pair programming, which is a model of sharing a console together writing code. And it sounds like that’s what you’re doing when you’re building the system, and then within the system you have loops.

Evan Rusackas [00:22:40]

Yeah. Yeah. More or less. I mean, I’m not using an IDE or anything like that. It’s all just through CLIs or through the Agor UI, which is this very card-based kind of, it’s like the Figma of AI, you could say.

Josh Lee [00:22:53]

Okay.

Evan Rusackas [00:22:58]

But yeah, they’re all chat sessions. But the more of them I have, the more tooling it builds. The more tooling I have, the more it knows, the more they’re going in auto mode. So it’s really a snowball effect.

Josh Lee [00:23:11]

Yeah. I do have a funny story though related to this. I have not let my looping agents work on themselves, or I’ve not asked them to work on themselves. I’ve only asked them to work on other projects. But one of my looping agents is running in Hermes. So I’m using Hermes with the gateway, and I have a kanban board that I hand off tasks to.

It was working in a repo. It didn’t have the permissions that it needed, but it did have read access to the repo with its own definition. So it made a PR. It didn’t have write access, so it just made a PR. It was like, “Hey, I need this. Can you update me, and then I will be able to complete my original task?”

Evan Rusackas [00:23:46]

Oh, that’s nice. And asking for permission in a weird way.

Josh Lee [00:23:50]

Yeah, it’s kind of exactly what I would want it to do.

Evan Rusackas [00:23:52]

Yeah, that’s important. It’s also worth saying that when I do the Agor driven stuff, that’s all server hosted and a big Docker thing, and there’s a lot of guard rails built into the product, a lot of governance-type of things.

Josh Lee [00:24:10]

Yeah.

Evan Rusackas [00:24:11]

On my local it’s a little more wild west. That’s kind of the difference. And on the local one I do have a lot of Docker stuff happening. You kind of have to put everything in its own little bubble. And a lot of stuff’s all done through git, so it doesn’t really have access to as much stuff from your environment and all of that. I recently switched from a GitHub OAuth to a GitHub PAT for my local access from my own workstation.

Josh Lee [00:24:42]

Yeah. Lock that down a little bit.

Evan Rusackas [00:24:45]

Yep. Yeah. It’s really all about guard rails. If you’re going to do this stuff at full speed, totally unhinged, you know, I guess.

Josh Lee [00:24:52]

Well, don’t be unhinged is the point. Have hinges.

Evan Rusackas [00:24:56]

Yes.

Josh Lee [00:24:57]

Or let the unhinged stuff live in a little sandbox, right?

Evan Rusackas [00:25:00]

Yeah. Yeah.

Josh Lee [00:25:02]

Okay. So we alluded to some tools. Tell me, what have been your favorite tools that you have used as you’ve been building this, besides Agor, which sounds awesome.

Evan Rusackas [00:25:13]

Yeah, that’s the one I would definitely highlight for others to use. And I could show it to you if you want. But otherwise, I think personally everybody works different. Here I am talking about how I deal with my maintainer workflow, but yours is probably not the same. So if I just shipped this tool, it wouldn’t work for you. Could I have built this tool in 15 other ways? Yeah, but I think that self-aware thing is kind of interesting.

I’ve been looking at a lot of new things as they come out, also potential marketplace competitors for Agor, these other AI agent building toolkits. I haven’t found one I like better, I’m happy to say. So I’m very happy with Agor.

But locally I am just pretty vanilla. It all boils down to, for me, Anthropic stuff. They have all these loops and dynamic workflows and schedules and all of that stuff built in, which works great. Sometimes I’ll have Codex or a Copilot in the mix to get a second opinion, which is cool. But I’m not really dependent on any of the other open source projects at the moment. I’ve tried Hermes a little bit, thanks to you, and some other stuff. I’m trying to think of good examples, but there’s no place like home, which is just iTerm.

Josh Lee [00:26:50]

I like that concept of self-aware, though. But it brings up an interesting issue, which is that you building it for yourself is one thing, right? But then at a certain point you start to share it with your organization. And then we have this sort of, it’s amazing that we all get the software that does exactly what we need it to do, but we also now have this compounding. It’s already the case in the software industry that there’s so many different ways to do anything, that when you switch organizations it’s like, oh yeah, this is…

When I talk to people who are not in tech about it, I’m like, it’d be like if you worked in construction and you get to a new job site and the first thing they tell you to do is to build your own drill. That’s kind of how we operate. And so is this just even going to get worse?

Evan Rusackas [00:27:35]

Yes. It’s a funny thing. I’m both using and working on the solution, via Agor, to the problem that I am, and all the stuff that I’m just describing.

All that I’ve built that I was going into detail on there is my own little silo that I’ve created for myself. And so many people working in this space in this way are honestly, probably for the most part, pretty happy in their little silo. Are you as an individual getting more work done and making your own life better? That’s great. But then there’s the engineering org to think about, or your open source community, or whatever it is. But think of others, right?

So then the thesis is you need to become an AI enablement engineer, and everything that you’ve learned and built needs to be available to others. And you can do that by creating a product that works hopefully for everybody, or a large swath of people. Or what I’m trying to do now is bring all of this stuff that I’ve done locally into Agor, in my case, so that everybody else in the org can use and benefit from that work that I’ve put in. And it compounds that way.

The AI enablement engineer should be a role in every company. It’s like, okay, I’m ahead now, let me drag everybody else along with me to do their own work faster. And that’s the part that is super important, that needs to be done in whatever product you prefer. It’s what Agor is built for. That’s the whole thesis of how we’re positioning this thing. And yeah, if you’re not letting others leverage what you’re building with your software, then that’s just selfish.

Josh Lee [00:29:22]

Okay. But then who gets to do that, right? Who gets to take on that role of being the AI enablement engineer? I can think of some organizations where I think everybody would want to be that person, sort of exploring the cutting edge.

Evan Rusackas [00:29:40]

We don’t.

Josh Lee [00:29:41]

Okay.

Evan Rusackas [00:29:42]

Yeah, everybody should be exploring this. If you’re not somewhere near the tip of the wave, then you know you’re not going to have a good time. But at the same time, there are going to be people that are ahead naturally, just because that’s their passion, knowing all the latest in tooling and workflows and how to deal with this. And you could think of them almost like a tech lead or something.

Josh Lee [00:30:09]

But in a way it’s more, I guess, like a managerial role where you have a responsibility.

Evan Rusackas [00:30:17]

That’s the difference, I guess. If you’re an organization that’s going to hire an AI enablement engineer, or give it a title quite like that, then it’s not just like, hey, I’m furthest ahead. It’s that you have a responsibility to be the force multiplier for others, and make sure that all of the KPIs are going up, and everybody’s velocity is higher, and everybody’s quality is higher, and the whole product is moving faster. It’s not just a hobby, it’s a goal, right?

Josh Lee [00:30:47]

And spending tokens isn’t the goal.

Evan Rusackas [00:30:50]

No, no. No. Nor is saving tokens either, though, right? That’s the wrong thing. It’s important, and dollars matter. Your carbon footprint matters. But at the end of the day, it’s trying to get more work done efficiently and expediently.

Josh Lee [00:31:10]

Absolutely. Absolutely. Have you found… this actually raises an interesting question. The barrier to usage for new open source projects is so much lower. Just in my own home lab, I have probably a dozen new services in the last year, because all I have to do now is ask Claude to write a Helm chart and then click merge, and I can try out Superset. So have you found that there’s more adoption?

Evan Rusackas [00:31:40]

I think so. It’s interesting, and yeah, I do the same thing. I’m trying out some different new tool all the time, and like you said, your agent is able to install stuff for you, whether it’s Helm or Docker or even just some CLI or npm package, whatever the delivery mechanism. You can just spin it up and have it configured and be off to the races in no time, which is amazing.

The problem, I guess, if you’re trying to get the world to adopt your open source, is not to have them download it and try it once, but actually create that stickiness, the utility that makes people want to come back again and again and again, and to share it with others and say, “This is the thing that’s working for me. You should try it too.” That’s the new challenge, I think.

Josh Lee [00:32:33]

Yeah, that’s definitely always been a challenge. How do you deal with that blank slate problem where, especially for data intensive tools, it’s not useful until you’ve loaded the data into it, but do you commit to loading the data into it before you determine if it’s useful?

Evan Rusackas [00:32:41]

Yeah, yeah. I think because of the ease of installation, people have less patience with onboarding. So that’s where a lot of it, like so many things in life, honestly comes back to good design at some point.

And that’s one of the things that we’re working on with Agor right now, actually. To take Agor Cloud, Preset’s offering of the hosted SaaS version of this open source tool, and really nail the onboarding so that it’s super easy to get in there, connect all your MCP tools, connect all your sources of data context, whatever, connect all your models, connect your Slack. That groundwork that you have to do to have the full setup could be very complicated and tedious. So making that accessible, expedient, that’s the real interesting challenge and opportunity, I think.

Josh Lee [00:33:49]

So let’s actually talk about, what is Agor at a high level?

Evan Rusackas [00:33:52]

Well, let me show you. Let’s see. Find my little screen sharing button here. Okay, I will share a window. Here we go. Can you see the window now?

All right, so this is the website, just to give you a quick overview without diving into it. In the little background video here, you see it’s kind of this interface that has a bunch of different cards that could be artifacts, chat sessions with different models, all kinds of stuff. And there you can see there’s multiple cursors doing stuff all at once. So it’s very Figma-like in that way. The whole experience is multiplayer.

So this is the silo thing we were talking about, that everybody’s kind of working on their own. I admit some guilt here, that in my local stuff I’m mostly using Anthropic. But if they jack up their prices or something like that, then my whole self-aware thing is kind of hosed. So this is a solution to that problem as well.

Now, it’s got this canvas concept where you have zones here. There’s an actual one here. I’ll go to a different one. This one’s pretty much a blank slate, but in here you can have these zones that are basically triggers for actions. And you’ve got worktrees, which are exactly what you think. And within worktrees, you have sessions.

So if I were to go create a new session, I just pick the LLM that I want to use. And we can add a bunch more of these. But if I pick Claude Code, then great, it’s pretty much just like using Claude Code locally. I can prompt about whatever and see a whole stream of responses.

And I’ll just load up this one from a prior demo. But what’s cool is it’s multiplayer. So somebody else could actually come right in here, see something that I’ve asked and gotten a response to, and they can follow up with a follow-up question. So that visibility across users of the tool is really quite unique and valuable. Nobody can use my software, because they can’t just bring their mouse over to my terminal and start typing. But here you can fork sessions and all of this kind of stuff. And these can create, you can create agents that actually leverage different models. They talk to each other and there’s a lot of different stuff you could do.

Now let’s see. This might be something you have to blur out, depending on what you’re about to see. But if I click knowledge base, this is kind of like the memory of all of our agents. And so when we ask about anything really, and it does some research, it starts to store a bunch of stuff, almost in its own little Notion. And all of the agents can tap into that.

And if you go look at, let’s see, I’ll look at… oops, wrong spot. If I go to my homepage here, you can see a bunch of stuff I’ve been working on recently. But I’m trying to figure out what’s something I can and should show you, with my agents that aren’t doing secret squirrel stuff.

But you do have the ability to create these agents that you can interact with through Slack. I guess I don’t have a demo of that built up at the moment. Maybe there’s something in the page here. Message gateway. So, yeah, here you go. Here’s a little video of it. And when you DM one of your Slack bots, it actually behind the scenes will go to Agor and create a worktree for whatever repo you wanted to work on. Or it will create or look up knowledge base articles and respond to you on Slack with, all right, I opened your PR, or here’s what I found on the web about your question, or here’s what I know from our knowledge base.

So we build up, for both Preset and Agor, like a whole repository of the competitive products. And we say, what are they doing that’s different from what we’re doing, so we can ask, how should we be positioning ourselves, what is the feature we should be working on next, what is nobody else doing. And that stuff’s really great.

Josh Lee [00:38:37]

I love the collaboration tools and just this concept of multiplayer, because I think that’s really been a missing piece for so many people. And yes, okay, before, you could integrate it through Slack, and you could kind of glue together some of what you showed there. But just to have that seamless experience without any external tools, to be able to collaborate on work together, whether it’s the planning phase, the actual implementation, all the different things that I’m running my sessions for, to share those.

Evan Rusackas [00:39:02]

Yeah, right. And then you’re sharing not only just the tool itself, which is kind of like Figma. You can see everybody else’s cursor. You can leave little messages to each other on the boards, all of that good stuff. But the outputs of it are also very much shared.

So when I create an agent, we have all these different ones in Preset that do different stuff, and they’re connected to their own skills and MCP tools and all of that. And you can ask them questions about their subject matter expertise, or they can refer you to a different one, or they talk amongst themselves, all that stuff.

But there are also artifacts. So if I go through a session and build an artifact like this one, everybody else can see it, everybody else can use it. Everybody else can hop in the session that made it and contribute to it and improve it.

So originally the idea was, Max and I were both going nuts with all of these chat tools, but watching each other on Zoom, I was like, “Oh man, can you type this for me?” Or you say, “Hey, can you type?”

Josh Lee [00:40:19]

It’s like going back to pair programming before we had the proper tools for programming. I wish I could reach through your window and type into your terminal right now.

Evan Rusackas [00:40:28]

Yeah. And that’s one of the many things that this now does, and it’s great. So if he has a chat that’s digging up some data, I can say, oh, but what about this dimension or this filter or whatever?

But yeah, I’ve got this giant SQL query here that I wrote up. I wrote it, but it’s just a monster. And now it’s not just something that I have sitting in a data set. It’s actually an artifact that everybody can understand. It’s kind of self-documenting. If you want to add more stuff to the pile here, they can edit it and pile on. But this could be the same for any other sort of artifact, whether it’s a data visualization or a little bit of a UI.

And artifacts themselves are just a whole crazy wonderland of opportunity. When we’re working on the website, because all of this stuff is all dockerized, I can actually spin up the web server within Agor and it’ll show me the live preview of the website as a little artifact. And everybody can look at it and continue prompting to dial in the website together, all on a live server together, without a development environment. It’s like, what the heck? It’s a whole new thing.

Josh Lee [00:41:44]

That is… yeah, that’s pretty cool.

Evan Rusackas [00:41:50]

Yeah. Take this for a spin.

But yeah, meanwhile, this is my other little thing that I use locally, just to show what I was talking about earlier. So these are my own PRs, right? And this one has CI running, but something failed on CI. Oh yeah, lint front end failed. So it’s simple, I just say fix CI, go for it. And then the agent in the background is going to go fix whatever is wrong with CI. This one has review comments on it, probably from other bots. So I’ll just say assess and reply, and it’ll do it. So it’s pretty neat.

And then there’s all these other different little bits of work. So these are approved PRs that just need some other touchup. So usually I’ll go look at them and see if the author actually wants help. But if this person wants a rebase on their PR, one button click away. So that’s how I do stuff locally.

Josh Lee [00:42:56]

Okay. Yeah, it’s funny, because you were mentioning these command centers people build for themselves, and it does actually boil down to, I just want a simple queue. Or yeah, you’re saying your first UI was crazier, and then it kind of…

Evan Rusackas [00:43:13]

Yeah, pretty much. It’s just my laundry list. And it just knows that, you know, fold these shirts, the socks don’t matter. It treats things according to what they are, and the rules I’ve set up.

Josh Lee [00:43:29]

And is it continuously evolving, I imagine?

Evan Rusackas [00:43:36]

Oh, yeah. Somewhat on its own. I might find some new common workflow that’s missing and just go back to the main session and say, okay, I need a skill that does something differently with this type of work. So build the skill, stick that in a button, then I have a button I can click that executes that skill. I like buttons.

And then also it’s constantly learning my voice. I didn’t really show you editing a comment. It’s just a text area, but it does a diff of what it suggested and what I actually let it post. And so anything I edited, by removing some extraneous details or em dashes or whatever, it just learns my patterns in that skill.

And yeah, anything I click skip on or dismiss forever, it starts to kind of take into account, like, oh, you’re always skipping this person’s PRs because they’ll take care of their own work.

Josh Lee [00:44:28]

I really like that combination, though, of letting it write the skill but then giving you a button that activates the skill. Because this is something I wish the other harnesses had, just a way to activate and deactivate skills on the fly. Because sometimes, if they’re not relevant to the task at hand, they can create these sort of…

Evan Rusackas [00:44:52]

Yeah. Yeah. You can conjure those things via CLIs, right? You can do slash commands to use a skill. But I find that tedious for two reasons. One, remembering what they all are, or knowing even what you built there.

Josh Lee [00:45:07]

No, it’s much easier to have the button next to the context of the thing that it’s acting on.

Evan Rusackas [00:45:11]

Yeah. But this is the other thing, just my little annoyance with a lot of AI things: having to type everything all day long drives me crazy.

This is very true in business intelligence and data visualization stuff. I respect that a lot of people want to control everything they do by typing. If that works for them, cool. But I don’t want to have to say, rotate the x-axis labels on this chart by 45 degrees. I’d rather click the button that’s just the label rotation menu.

I’ve always been a UI button clicking person. That’s why I was always a front-end developer instead of a backend developer, back in the olden days when we wrote code. But yeah, I think I’m a UI-centric person. I like to see what’s on the menu of options and say yes please, yes please, yes please. And so that’s the kind of tool I built for myself.

Josh Lee [00:46:18]

That’s really cool. All right. Well, what do you want to leave us with? Any closing thoughts? Any grand lessons?

Evan Rusackas [00:46:29]

Grand lessons. Well, I think if we’re all open source contributors here, the most important thing you can do that your bots aren’t going to do in all this stuff is say thank you. You need to really be the welcoming person. You need to be the thankful person. You need to get people, the humans behind the bots, to come back. So be nice to everybody and be welcoming.

But then also, I want to hear about everybody else’s tools and workflows, because certainly I don’t know everything. Certainly everybody’s out there inventing like crazy. So let me know what I’m missing, doing right or wrong.

But then third, go check out agor.live and let us know what you think. The tool is available. It’s free on open source grounds. The Preset-hosted Agor Cloud is coming soon. So by all means, book a demo, and we’d love to get your feedback on it and take you for a spin more properly than what I did here.

Josh Lee [00:47:32]

I am definitely going to be trying it out. It looks really cool.

Evan Rusackas [00:47:35]

Fantastic. Well, thanks for having me on. It’s been a pleasure to talk shop.

Josh Lee [00:47:40]

It’s been great. Yeah, always a pleasure, and looking forward to chatting some more.

Evan Rusackas [00:47:45]

Yeah, likewise. Thanks, everybody.