The New Dev Skill: Multi-Monitoring 10 Agents

8,611 words · about 34 min to read

0:00 For at least a year now, you do not need to hire junior developers for their coding skills. If we stop hiring junior developers, we will never have this archetype of an architect that we are looking for. It's both a product manager, a project manager, a team lead where the team is agents in that case. The real skill that we're trying to build is the ability to not multitask, but multi-monitor agents. So you'll be able to command a team of agents.

0:27 I'm not under any sort of fantasy that you can manage thousands of agents, but you can manage 6 to 10 maybe. The AI Native Dev is a podcast for developers and engineering leads at the cutting edge of AI and agentic coding. Join your hosts, Guy Podjarny and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.

0:54 This is the AI Native Dev. Yesterday you were writing code. Today you're prompting agents. Tomorrow you'll be running a software factory. Agentic coding is moving fast enough to give anyone whiplash. This June, AI DevCon London sold out. Hundreds of developers, engineering leads and VP's packed in to hear speakers from Anthropic, OpenAI, Netlify, and GitHub, cut through the hype and get to what actually works.

1:24 This November, we're bringing it back to New York. Bigger, bolder, and full of people actually building the agentic future. Three days of real talks, real tools, real answers. Whether you're directing the agents, building the loops themselves, leading the teams, or setting the strategy. Our early bird pricing ends on September 30th, so make sure you lock in your place before prices increase. As a podcast listener, you can get 15% off your ticket using promo code POD15.

1:54 We have so much planned and we can't wait to have you join us in New York. Hello and welcome to another episode of the AI Native Dev. My name is Simon Maple. I'm your host for this episode, and joining me is the founder of Automaze and MUXI. On today's episode, we're going to be covering major topics such as the difference between teachable knowledge and earned knowledge, and where junior developers today lack that earned knowledge.

2:25 How can they gain that information? Also, we're going to be talking about the agent workflow. And is the term agent workflow an oxymoron in itself? How do we get that determinism to remain in a workflow? And finally, we're going to talk about the law firm model and how that applies to software development agencies. Do we need to think more about that law firm model of distribution of wealth, or should we stick to that SaaS model that we're familiar with? Welcome to the episode.

Building scalable open source tools like yfinance

2:54 It's a pleasure to have you. Thank you very much for having me. And Ran is the founder of Automaze and MUXI, and the creator of yfinance. Tell us a little bit about some of those things. Yeah. So my developer journey started 35 years ago. I'm sad to say. And yeah, throughout that time I've been working pretty much in any tech adjacent industry as a team lead CTO, CEO, and my real love journey with open source started in the late late 90s, where I realized that one of my startups, that we had to raise millions of dollars for just to have a database can now happen for free.

3:40 So every time that since then, every time that I develop something that is not like my business secret sauce, I happily turned it into an open source library. One of those indeed was yfinance and it just took off. I mean, it's it's quite amazing. It all started when I'm still doing that, but I used to be a lot more invested into algorithmic trading.

4:05 And I've done this for a living for a while and actually with great results, and was very happy about that. And I needed a data source that was free, available, and very Pythonic, so I can use it for downloading market data into. So I just decided to leech on Yahoo Finance, and I created this library and it really took off. And these days I'm getting I think the latest number is about 25 million to 30 million downloads every month, which is insane.

4:37 Yeah. And I remember just a few years ago I boasted about having 600,000 every month. So it's quite insane. And this number keeps accumulating because it turns out that every time you ask AI to to write anything related to market data, it uses that. So I assume that is part of the real growth over the past year. And wasn't there a time when actually Yahoo dropped their API?

5:05 They never dropped their API? So the way the library works is not by scraping or it's using the Yahoo Finance API. It's just that they're trying really hard not to document it anywhere, but it is publicly available. I actually got a cease and desist that after I pointed them to, hey, this is a public API. This is okay. Sorry. And they backed off, so I assumed they weren't even hired by by Yahoo!

5:36 They were just trying to land them as a client or something. But yeah, this is definitely not the only library that does this. I just think that it's doing it really well and the interface is API wise is very Pythonic and very simple, which is something that I really believe in. Let's cut the number of of code lines that you need to have. And yeah, over the past 4 or 5 years I'm running a software development company called Automaze, as you mentioned, and we tend to kind of do now.

Declarative agent formations with layered memory

6:13 It's called FDEs, but we tend to embed ourselves into startups and different organizations with our development team. I act as kind of the the spirit of the company. I help with the specs of the projects, because my experience over the past few decades is has been both in product and in tech. So I kind of walk and talk the the two languages.

6:39 And I have a great team that scattered all around Europe that does the actual development. And one of my most recent pet project that turned into behemoth of code base, although it's not nearly as used as as yfinance, is MUXI, as you mentioned,

1 Highlight · MUXI agent formations and layered memory design

6:57 which is a different take on how I think AI should be deployed, which is having agents as primitive give them their own application server and make sure that you don't have to code your way into having an agentic platform, but just deploy. So it's kind of like a Docker in terms of how you deploy. It's like muxi pull, muxi push.

7:23 You pull a formation which is the entire setup. So yeah, a formation is a unit of, it's like a collection of agents. Is that correct? Yes. Yeah. So at the top of the formation is it's not just a collection of agents, but it also includes what I call the overlord, kind of the orchestrator that decides of the formations personality. And the agents themselves are sort of minions, because I didn't want the experience of having to remember which agent I need to talk to.

7:52 This one does email. This one is a good writer, and I just wanted to talk to Jarvis and have and have it manage whatever agents it needs. So a formation basically tells me, okay, which models am I going to use? What are the the back of where they're not. I have role based access management. What type of memory allow allowance to do I give the database is this organizational deployment where I'm going to use Postgres with the all different types of extension or just for me.

8:24 And I'm just going to use MySQL and it's all configuration files. So there's no code involved. Everything is in YAML files in the format that I call the agent formation schema. It's again fully open source available in agent formations. And yeah, it allows you to define both the obviously the soul of the document, what it can do, the tools, the domain knowledge for every agent.

8:53 Access to it has a very elaborate memory structure where it has a differentiates between preferences, memories, decisions, claims. Working memory, buffer memory. Episodic memory, recent memory. So it's a very layered type of memory because of what I'm trying to do is mimic how the I'm really philosophical philosophical here because what I'm trying to do is mimic how the human brain works when it comes to memories.

9:25 There's the misconception where observation and logging is memory. I don't think so. I think The distillation of of knowledge and recall is the memory, because we might not remember every single word that was said here. But we're going to have the takeaways. We're going to remember conclusions and things that we've agreed on. And I think that's how agentic memory needs to work. So it's all bundled in. You don't have to worry about it. You don't have to.

9:52 You just need to essentially configure what your agentic AI can do. Which tools do you want to remove from the registry? You know, you're using Stripe MCP with million tools over there and you only need three, so there's no reason to hog the memory just still okay. These are the only 2 or 3 tools that I actually use in this application. It's not going to load any of the other ones into memory. So yeah, it's it's it's very well thought out based on the needs

10:19 that I've encountered, both in my own personal kind of Jarvis journey and what I noticed with the what organizations that we've deployed. We actually created a separate company in the US for deploying, deploying agentic AI at the organizational level. So yeah, that's

Trust and human review in autonomous systems

10:41 in the gist. And it is one of the interesting things there is the kind of like operating instructions, as it were, for, for a, for a formation. I believe that can that they can kind of like retrospectively look at those instructions and say, actually I want to change. I want to change my own instructions based on historic kind of like how these have been done. One of the key things, though, there is I believe that requires a human interaction to say, actually, yeah, I do approve this or I don't approve that.

11:13 Where do you kind of like feel today? We should draw the line between pure autonomy, where things can essentially self-healing, fix, tune themselves versus requiring us to still provide an overview? And is that line more a technical line today, or is that more of a trust or culture line that we need to draw for ourselves?

11:41 I actually think that it's more of a trust line.

2 Highlight · Balancing agent autonomy with human trust and constraints

11:45 I think that technically you can create a fully autonomous system. And I was actually talking about this yesterday. I think that, you know, with AI it can hallucinate. So the first line of defense is make sure that it has up to date information, that it knows how to not only store it, but retrieve the right information, which is not always just contextual.

12:10 It needs to have the graph of relationships there. But even then, let's take a coding agent for example. So you're giving it a goal. And if you're not going to intervene at any point and saying, okay, after five tries, after two hours, whatever it is that you set as a threshold, come back to me and say, I can't do it and let me, let me help you get unstuck.

12:37 If you don't do that, agents will either create slop or run a very high token bill because it's just going to keep trying, or they're going to fake the tests just to, to to have the tests pass, to get the tests green. Yeah, exactly. And we've all seen code with the comments by the AI. This need to be changed later to dot dot dot. And you in order to have that trust, I think that the human still needs to be in the planning and in the confirmation stage.

13:10 So you need to what is the definition of done? What am I trying to achieve. And you need to be there these two steps in the spec. And you need to be there in the just making sure that it actually happened. Everything else you can put on different constraints on the system where you don't really have to look at the code anymore, because if you put enough constraints that says, okay, the we need to achieve this level of code profiling and this need, we need to achieve this amount of test and regression test, and you put all sorts of constraints that by definition, the code quality is good if everything is green, the fact whether or not it's pretty or not, you're not going to look at it any way in the future.

13:58 So it doesn't matter. What matters is that it's efficient and that that it's maintainable by the AI. And you can solve this with all sorts of, of rules and constraints. So I don't think there's a lot of technical constraints for us to let AI do everything, but I think it's more of a quality assurance and trust.

14:19 Yeah. And you know, going back to to to MUXI, you mentioned that. Yeah. You have several ways of improving a formation. One is the formation keeps learning and creates a file that is ready for the human to review. So it will never kind of auto update itself, but it will create a new version of itself and it will wait for you in a git format.

14:44 And you can look at the diff, and if you approve it, then you deploy version, whatever it is. 0.1 and that's how I feel that you do it. I haven't even allowed a flag of having it fully autonomous. I just don't believe that in a system that you need to trust, you can have flakiness. You know, some systems it's it's health, it's going to be life or a lot of money. And so yeah, just put putting the time to review it.

15:12 Yeah. It's very interesting actually because I mean for us at Tessl we have our own software factory that we look at every single pull request that is generated, even though it's pretty much end to end from issue to pull request automated in terms of the testing, the code generation and things like that, we make sure we validate and verify everything that goes through to production, but for our own, for some of our internal tools, for example, our own dark factory, we allow fully autonomous go from issue all the way through to to, you know, a pull request that gets merged without.

15:48 Gets merged with it. And I think for the internal a lot of it is trust. A lot of it is criticality as well. Right. And it's a case of if who's going to find this first, is it us or is it going to be a user that actually then affects your brand or your right data, those types of things. And in some cases we actually have maintenance agents that that will run. They will observe how the dark factories run, how agents are running, create issues, resolve, merge those issues.

16:15 And we don't even realize those issues are being created or merged at all. And it's a it's a scary world to live in, but it's almost like progression in small steps in non-critical systems. First till we actually then go to production and say, right, how close are we to actually doing this in lesser critical parts of production? And it's going to be a gradual cultural change. I think. It is. And I agree with you. That's if it's mission critical and it's part of your brand, you want to have humans in the loop.

16:45 And yeah, the role of humans would shift in even in the few months that we have till the end of this year, it will change and the role will move, maybe diminish. But I don't think it's going to be removed. Yeah. And it's funny because we also have obviously our own software factory and we have this Sentry-like feature we call Ladybug that catches bugs while they're still in production, even automatically diagnoses created.

17:16 And there's a PR waiting for us on the other side. And it's been really fun to to have this tool and just you just wake up to PR. And that's. Yeah, it's particularly important in 3 a.m., you know. Exactly. You don't get some groggy human who's like, you know, just waking up with pre coffee trying to diagnose something. By the time they have woken up to look at a pull request, it's already been fully diagnosed, RCA. They've got everything waiting for them that they have to review.

17:43 And you know, for these type of outages that will cost money. That's so important. It is. And look at the OpenAI Hugging Face breach that happened a few weeks ago. If I recall correctly, it was like 17,000 hacking attempts or something like that. There's no way a human, you know, sitting in front of logs with a cup of coffee can work through this because by the time they go through the 17,000 log items, it's going to be 170 times all cartoons.

18:16 So you have to have those systems in place to to actually do this for you. Yeah. Now, Hey everyone. My name is Sahil, and I'm one of the engineers here at Tessl. I'm going to be in New York and in Boston on the 16th and 17th of September, talking about how we've built our software factory here at Tessl and what engineering looks like in an AI native world. I'm going to be diving into the components that we've built out, why they're there, why they're useful, the mistakes that we've made along the way, the sort of metrics that we focused on early that actually didn't end up helping us, and the ones that actually did and all the different quirks and features that ended up building out the factory that we have today, this is going to be a much more practical look into the factory that we have here at Tessl, and some of the specifics on how it works and why we made some of the decisions that we did. Go to tessl.io/events.

Workflows are not truly agentic

19:06 And I hope to see you all there. Yeah. Now, Ran, you've also created a number of books. I've not I'm not an author other than blog posts. I don't think that. That's a lot that I'm really an author from that. But one of the one of the quotes that I really loved is in and around how agentic systems have zero of the properties that would actually make them agentic, right.

19:40 Tell us a little bit about that. And what is it that most teams get wrong when thinking about something that is being agentic or building something that's agentic, right.

3 Highlight · Agent workflows are an oxymoron

19:49 So I separate this into two terms. There's automations. There's fully agentic, which means autonomous and proactive. And it's just another person on your team that you have no control over other than the gates you've set in. And most of what I see is either automations, automation with AI sprinkled in. And I think there's a misconception that a workflow, the term itself is kind of an oxymoron.

20:22 And the reason is that if it's a workflow, then you've already given the road or the path that the AI needs to work in so it doesn't get to make its own decisions. And and I think that that's where a lot of, of the focus is on right now. Most people who are doing AI and the agentic stuff, this is actually what they're focusing on.

20:47 They're not focusing on actually creating this entity that can actually think and, and come up with ideas for itself. And the few people who actually went that extra mile are amazed by how capable AI can be. And it's fine, because I'm not dissing anyone, because for most use cases you do need workflow. You don't need the the agent automation and all of that stuff.

21:13 If it's deterministic, you don't need AI. If it's deterministic with some fuzzy bits like okay, I need AI in this step to write the email. Yeah. Then it's a, it's a, it's a workflow with AI sprinkled in, you know, tools like n8n did that a while ago. It's not like a full living, breathing entity that just like OpenClaw or Hermes or anything like that, that just decides on its own. And.

21:39 Yeah, so that that that would be my take on it. I think that if you're thinking whether or not you should go identify fully agentic and autonomous, first think of whether or not you either. You even need that in the organization. A lot of business operations are fully deterministic. So there's a lot of AI that's being used in places that it shouldn't be used. And it just costing you money.

22:05 Yeah. Where a simple script, the number of times I've seen AI try being used to parse strings where a simple regex can just do the work. Far cheaper. Faster, cheaper than literally free. You know, it's just so. Yeah, it's a shame.

Junior developers as apprentices in agent management

4 Highlight · Multi-monitoring agents replaces traditional coding skills

22:24 Yeah. Now, Automaze has this four phase ladder approach from I think it's no computer pure understanding to more of a full architect mode. First of all tell us a little bit about that and then I'd love to dig in a little bit. Yeah. So we came to realization that For at least a year now, you do not need to hire junior developers for their coding skills that you don't need them for that.

22:53 Now, if we stop hiring junior developers, we will never have this archetype of an architect that we are looking for. And an architect is. I don't know if this is a term that's going to catch on, but it is someone that walks. Both understands the product, so it's both a product manager, a project manager and a team lead where the team is agents in that case.

23:22 So we work in an operation where we have pods and that that pod has the senior developers, kind of the architect, manage these agents and a client facing individual, which is the delivery manager, and they kind of work with the client. One is working externally, one is working internally, and the junior developers are there as apprentices for the kind of joining along.

23:48 Like, you know, in the Renaissance days, you had the apprentice and they would join the the master painter and kind of learned the rope and dabble around and sometimes would get their own project. And he'd just finished this up. And so this is the real skill that we're trying to build is the ability to not multitask, but multi-monitor agents. So you'll be able to command a team of agents.

24:15 And I'm not under any sort of fantasy that you can manage thousands of agents, but you can manage 6 to 10 maybe. But you need to. That goes back to the to the workflow itself. You need to know how to spec products. You need to know what agents are capable of and we're not capable of and be their mentor when they when it's time to develop software and, you know, be at the gate where okay, is it ready for production?

24:48 Did I put in the right workflows where when the PR is ready, I want to immediately create an environment where the full system is up and end-to-end test run. And so you need to learn these types of things. And these are things that I don't think you can learn from reading programming books.

25:10 And that's that's what's kind of interesting, where there is so much new from the point of a workflow, from the point of, you know, we as experienced developers are needing to reprogram ourselves in terms of how we operate. From a junior developer point of view, it's going to be easier for them to snap into a different workflow because they don't have the baggage of many, many years gone by of right.

25:37 I need to sit down and do these deep designs, then code, then do and blah blah blah, right. But from the junior developer side, of course, they don't truly understand the more complex architectures, complex designs. When they wake up at 3:00 in the morning to to solve something. This could be, you know, for experienced developers, they understand what happens when AWS goes out, what the implications are and how to go around fixing that. What would you say are kind of like, how are you seeing both junior developers and senior developers, more experienced developers snap into this new model of development workflow.

26:12 Where are the disadvantages from? I think that they have to work together because the examples that you've given, this is earned experience. This is you cannot accelerate that. You have to be there and you have to understand the consequences of, you know, just how much load can two vCPUs machine can handle. This is not something you can math your way around because your application differs from my application or that other application that you've worked on in the past.

26:40 So you need to have this. It is earned experience. There's there's no way of of condensing that time. But if we can take a junior developer, it used to take like junior developer like 3 to 4 years to become like a, a good level of mid-level developer and 7 to 8 to become a senior developer. I think we can compress this, but not to zero and not to a year, probably to a two year where a junior developer and I'm sure you have this experience.

27:12 I'm sure you're seeing a lot more value from junior developers when they're a year in versus junior developers that were a year in, like, five years ago, right? Because they can produce a lot more. They can, for lack of a better term, nag the senior developer less because they can actually use agents to walk me through this problem, walk me through this function. Why is this doing that?

27:38 And then come more baked with the questions ready to to the senior developers for help. And I think that that's exactly the role of, of an apprentice and a mentor kind of relationship, that they have to be together for a while before the junior is ready to kind of just start their own pod.

AI risks creating deep knowledge gaps

27:58 Yeah. And I'm not in any rush to, to, to give them their own pod. I mean, I think that if, if it's going to take them a year or two, that's fine. It used to take five. So we're fine. And I love that. I think you call it teachable knowledge and earned knowledge. Right. And I guess that is something that is, as you mentioned, teachable knowledge being heavily compressed going forward. When we look at what was earned knowledge five years ago, that's going to be so much harder to earn now because so many things are being taken away or not taken away, but so many things being automated.

28:34 And we can hand things over to an agent. Now, do you feel like going forward, there's going to be a gap here in knowledge where it's important to have that knowledge, it's not really teachable and we can't earn it anymore because so much of that is being handed off to an agent. Is there a gap there that we're going to struggle? I think there is. I don't have a good solution for that. But I know what about you? But we moved to the UK six years ago, so my wife and I both got new phone numbers, different than the one we had for the past 20 years, and I don't know her number by heart.

29:08 I barely know mine because we just went, we got her new number. It just went straight to my phone. So my brain never had the opportunity to memorize it. And with AI, I think we're sort of in a race between in a race between how much it can do for us before we forget how to do it ourselves completely.

29:35 So whether or not we it can cure dementia before it becomes a wider phenomenon than it already is. So yeah, I don't have a good answer for that, but I definitely there will be things that you won't even need to know, because there are new solutions for them now, and some things that you'll probably have to to drill yourself into just creating those situations for you.

30:01 And that might be a partial solution. Just create those those false alarms, you know, every every office building have fire drills.

Production efficiency gains feed growing backlogs

30:11 So you'll have to you'll have to do these apparently. Yeah. with these new workflows and our teams being adjusted into kind of more an agentic workflow leading into a software factory, how much would you say your teams have become more efficient, more effective from even a time of delivery point of view? Right. It's actually very interesting because we were kind of wary about a year ago what would happen to our sales.

30:37 You know, we were working on a retainer basis. Now we're just going to finish things faster because of the AI promise. And that would mean that we're going to have less lifetime value of our clients. That didn't happen, because while we are able to shorten the the development time, probably for a proof of concept, you can reduce it to up to 80% of the of the time.

31:05 You can you can cut up. But for a true production grade system, you can probably go down by a good one third of the time, because there's still a lot of tests and so many edge cases that you have to test for. So I would say maybe 40 to 30% of the time you're able to cut. But what happened for us at least that we just ship more now. So the project is not ending. But all that bucket list that client had just goes straight on and we're just adding stuff.

31:36 The backlog. Yeah. The backlog of oh, we might get to it one day. Yeah, exactly. The reality. Exactly. So do customers. Do customers expect to pay less for functionality and features now, or is it you know. I assume they they do. But since we charge on the monthly retainer anyway. So yeah, they pay less per per feature. But our pricing model hasn't changed. So we have clients staying with us for three years on average.

32:06 So yeah, it's it's been fine. Your customers are actually getting more. They're getting. A lot more. Yeah, they're getting a lot more. And what I actually like is a lot of our clients, especially with new clients that we get, these are vibe coding experiments, and they're coming with us to us with an app that they've developed. And obviously it's not anywhere near ready for going to production.

32:33 But I actually like this. I you know, some people resent that as a, as a developer, as an agency that provides software development. But I actually like it because I know exactly what the what the client is after. Sure, we're going to have to replace 99% of the code and redo everything, maybe change stacks or, but it's fine as long as you can develop your vision in Claude, even if it looks ugly or whatever it is. But we get a real sense of what you're after from a product perspective.

33:01 Even if you just do mocks that, that's fine. Just a bunch of HTML pages that sort of look like the app you're you're imagining. I actually like it because there's no misunderstanding that. Misunderstanding that. So I actually like it. Very much more clarity than just a spec. Yeah, exactly. On the paper. Yeah. Now I understand you. I don't know if you still do. You used to certainly act as an FDE for every new Automaze client.

Founding developer engagement halts at scale

33:27 Is that is that still the case today? For some. So. Yeah, it's true to some extent. First of all, tell us what what is the role of an FDE. And then secondly, I'd love to understand how how that scales. Is that something, you know, you eventually think I need to give this up, I need to I need to grow my FDE team. Tell us a little bit about that. So right now we're about closing in on 30 developers on the team.

33:54 And when we start with with any new project that we're doing for the first time, that kind of project. So whether or not it's AI transformation project or we're doing a new thing with healthcare or whatever it is, I like to be there and the clients would like me to be there, along with 1 or 1 of the two development leads that that are running the show there.

34:24 The reason is that I cannot optimize or turn into a process, something that I haven't experienced and that I don't fully familiar with. And, and the role of an FDE is basically to be deployed at a company remotely or in person, which for us is is remotely and really be in contact with anyone that is related to the project to fully understand what's the best way to implement it and really understand not just what the spec requires, but how it's really going to be used, especially if it's an internal tool.

34:59 And even if you're creating just an e-commerce website, you need to to understand how the on the company side is. Yeah, we know what the shopping site looked like, but how the back end looks like for that company might be completely different than what it looks for a different company. And you know, I'm all for let's mold the technology around the company and not the other way around. So I feel that I need to be there, at least in spirit, at least for the first.

35:29 Like that's a 10% of the of the job. So I can spec it better so I can make sure that it fits in a way that we can move it forward. And yeah, so that's how I usually do it. And whether or not it's scale, it does not scale. It's it's a human time. It definitely doesn't scale. So that's why I'm doing it less on a per client but more on a per project type.

35:55 So everything that we're doing for the first time in that sense, then I like to be I like to be involved and then hand it off to the team. And yeah, it works. It works. We're not doing the FDE in a traditional sense of like we're implanted in, embedded into the company forever. Yeah, yeah. Hey everyone! Hope you're enjoying the episode so far. Our team is working really hard behind the scenes to bring you the best guests, so we can have the most informative conversations about agentic development, whether that's talking about the latest tools, the most efficient workflows, or defining best practices.

36:33 But for whatever reason, many of you have yet to subscribe to the channel. If you're enjoying the podcast and want us to continue to bring you the very best content, Please do us a favor and hit that subscribe button. It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you. All right, back to the episode. I'd love to get a big picture now and talk about some of the, some of the fun things, some, some of the fun quotes and some of the fun hot takes you've had.

37:03 The first one would love to talk about is when you called an agent workflow an oxymoron. What do you first of all, what did you mean by that? So I've talked about this before, and a workflow is not agentic by nature. A workflow is a deterministic set of, of of steps. You know, the inputs and you know the outputs. So just calling it agentic is either misleading, or if it's really agentic, then you're just wasting tokens because it could be fully deterministic or mostly deterministic.

37:38 So for for something to be called agentic it has to be fuzzy. It has to you. It has to be non-deterministic by nature. And that's that's just my take on the reason why I think that it's just the wrong word to say. There's not the, it's not the workflow that is agentic. The workflow is, is, I want to say static, but a very deterministic.

38:04 Exactly. That has an agentic component in it because the workflow itself isn't agentic. Yeah. So what I so kind of my, my interpretation for this, if you really want to have a mostly deterministic or somewhat deterministic. So we're just using a lightweight version of an SOP, which is this is how we usually do things. This is all the different forks that you can take and make up your own mind.

38:32 But I've given you the guidelines of what how we usually do that. If you can find a better way to do it, sure. Way to do it, go right ahead. But I've given you some context on how this is usually getting done. Going forward. Do you see scope or a place for an agent workflow where the workflow isn't necessarily deterministic, but the agents determine what needs to be done based on certain criteria?

39:00 Yeah, but then it's not really a workflow, right? So it's again, maybe someone else have a different definition for that. But for me, a workflow is deterministic. It's something that you can draw on a whiteboard and say how it works. It can have fuzzy parts like I mentioned. Okay, I want to know exactly what to write in the email based on the customer context.

39:25 But everything aside from the draft is deterministic and I'm sprinkling AI on different places. That's fine, but if we need to get to a point where the agent really becomes an autonomous, so it knows the company and it acts as, as an employee with really that's really open minded and kind of try to to tackle things that nobody else wants to do because it's too much work, it takes too much time, and it's a machine that doesn't care about any of those.

40:00 So yeah, I think that we need to, to go more to that type of direction. Ultimately, we do need that determinism in the workplace. Yes. For a lot of things you will always need the determinism. But you can have workflows, but you can have an agent entity that decides on which workflow is need to be called right now. So, you know, you come to work every day, you know how to do different things, you have workflows, but you're not working on an assembly line where you have your this is where you stand, and this is the box that you need to move.

40:37 Your work is a lot more dynamic, but for every task that makes up that that work, you have a workflow. So I think if we want agents to be more like humans, but just faster and more efficient, which I think this is what we're after. At the end of the day, I think that that's the direction we need to go. We need to provide them with a set of workflows, SOPs, whatever you want to call them.

41:02 But and within those, environment, just let them let them do their thing.

Subscription plan economics face inevitable collapse

41:08 Another hot take run. Anthropic risks turning its strongest advocates into its loudest critics because of a specific strategic signal. Tell us about tell us. About your take on that. So it kind of goes back to OpenClaw that was banned from using the Max plan. And their whole so for anyone who doesn't know, OpenClaw's a great, successful project by Peter Steinberger.

41:36 And it used Claude and specifically the Claude Pro and Max plans in order to to act as its brain. And they just shut off its access. If you want to use it, use it through the API. Their rationale was it messes up our statistics. We don't know how many people are actually using it for coding purposes, which is yeah, you could have found a different solution around that, right?

42:06 The solution is not let's shut it off. The solution is have a toggle mode. You do have a Cowork mode now. So you could have done an OpenClaw mode. So it's it was a very weak argument. And the reason was was financial obviously. And I'm fine with that. That that that's fine. It's it's your company.

42:31 You need to make money. But don't BS us. You know we can go without that. And I've seen this. There's a new project called Buzz by Jack Dorsey. It's really cool. And I also tweeted jokingly that it looks very promising. I can't wait for Anthropic to shut off access to it. And yeah, it's fine if you want to charge API charge API, but for me, you know I'm paying $200 a month for a single subscription and I have multiple.

43:02 Why can't I use it the way I like it? If you decided you want to give me some some allowance, then let me use the allowance however I see fit. Yeah, it's kind of a. Do you see other providers following suit there or. I, I think that we're seeing the exact opposite actually. Maybe it's just a temporary strategic move by OpenAI to say, hey, you can use it for whatever you want.

43:28 Grok is also doing that. Of course. The Peter Steinberger situation was quite specific because Peter now works. For exactly. But but I think they actually told you that you can do whatever you want with it, even before they started, discussions with him. But yeah, it would definitely a counter move. To what? Anthropic? As done. But, I think I think this whole subscription model, it's eventually going to go away or it's going to be a lot more specific.

44:00 So you're going to get so let's say that they're charging $5 and $20 for input and output. So your subscription will get you discounted. The but you're not going to sorry discounted price on X number of tokens, but you're not going to get 60 X on your plan compared to what the API provides, which is around what you're getting right now with Claude subscription and OpenAI subscription, this party has to end unless they come up with an ultra efficient GPUs or some some miracle chip that everyone's working on and will probably see, but I don't think we're months away from it.

44:42 I don't think we're even, a year or two away from it unless until the they'll be able to dramatically cut down their costs. There's, it's it's a race to the bottom. And I think that as soon as, I think as soon as Anthropic goes IPO or something like that, they're, they have no, the, the motivation

Dev agencies must adopt law firm models

5 Highlight · Shifting dev agencies to law firm models

45:10 for such an aggressive user acquisition and growth slightly reduces once they IPO. Right. Yeah. Let's take one more hot take like this one. It's around your law firm model, right. So your law firm model argues that dev agencies are heading more towards something like a Kirkland & Ellis than a SaaS startup, right. Why do you think that?

45:36 Okay, so right now we're very close to every single developer being able to create their own software factory, maybe on a technical level that obviously we're already there, but on a really production level, we're almost there. So you can be, a reasonably good developer and you can start your own firm because you're not limited by the capacity. However many meetings you can hold to close sales, that's your true capacity.

46:04 It's not about the development. So if you really want to attract and hold on to talent, you have to give them a stake in the company. So that's why. And law firms, they've done this for ages, you just become an associate, then a junior partner, then a partner. And yeah, you buy yourself in by the the business that you bring in. But, if if it wasn't for this model that there'll be just more and more law firms instead of more and more partners inside the existing law firms, and it is a matter of motivation.

46:40 If you want something to stick around with a startup, you can offer stock options. There are different things that you can do, but for a business that is not VC-backed or focused on hypergrowth, the only real benefit that you can give them is because you're not heading for an exit in those types of businesses, so what you can offer them is just a piece of cake and you say, okay, you're bringing you handle your own pod.

47:10 So you get this amount of cut from the revenue or from or from the profit. And I prefer revenue because then you don't have to let everyone know how your. Business operates. So that's why we also created an open royalties type of, of agreement, which it's very clear we know what we get from the client. That's all you need to know as a royalty partner. So and it's our problem to solve all the expenses that part.

47:39 But yeah, if I want to hold you, I need to make you a junior partner, then a senior partner, and give you the ability to earn. And I think that companies that especially software shops that are not going to use that model in the next few years and we're not still fully there, I'm, you know, for being honest, we're not there, but we're heading there. We built we build our pod model and then we're slightly, slowly moving

48:05 to that direction. But there's, you know, once you have a senior developer that manages a pod and they're handling 2 or 3, four clients and you're paying them, let's use kind of round low numbers. You're paying them $1 a month. But they know that they're these clients are bringing $10 a month. Why would they stick around with the company if they can say, okay, I'm gonna earn zero for a couple of months, but I'm going to land my own clients, even one client.

48:33 I'm going to have less work and more money. You know? I'm just going to keep everything. So you need to be able to say, you know what, ten, 20, whatever it is, percent of the clients that you manage are yours. Another ten, 20% goes in a pool that is being split around the pods. And I think this is a healthy model. You know, I used to do like 20 years ago. I used to do a lot of affiliate marketing.

49:00 And what I liked about this model is that it's the the motivation is aligned. So everyone is what's the business to make money. And is this would you say this is very much favoring the startups, because they're going to be more flexible in being able to offer more of those types of things to, to their employees or, and also does this, does this lead to almost an explosion of new startups being created?

49:27 If not, because people will think, well, actually, I as you say, I need one client and I get more than, you know, the ten clients or the same as ten clients worth of, of of revenue. So it really depends on the startup. Most startups are not profitable by definition. That's part of their growth strategy. So for those startups, especially if their goal is to become a unicorn and go IPO, then I think the existing model is already good enough. Of.

49:57 The stock options and equity. And yeah, it's pretty much doing its job. But if you're a bootstrap business or one that's focused on revenue generating, you know, that's that's a focus. You're not playing a goal. It's never going to be. Even with Automaze, we're not going to be a $100 million business, but we are going to continue to generate good amount of money. And that's the cake that we have to offer. So maybe we'll I'll sell it in the future.

50:24 I don't know, it's not part of the strategy. So I don't know a good offer will come. We'll see. But this is definitely not part of the strategy. We're here to stay. So this is the only way for me to really hold those people is to give them part of this revenue. And I think that for service based companies, you'll definitely going to see that. So you're you're definitely going to see or hopefully I don't know definitely.

50:51 But hopefully you're going to see this. And not only for software for software stuff. You know, every if you have a network of plumbers and you want to keep the best plumbers around, you have to pay them more than hourly. Otherwise, again, they'll just they just need a lot fewer clients to match their salary than what they serve right now under this umbrella. So just align those interests. Amazing. Ran, where can people find where can I find out more about Automaze and MUXI?

51:21 Well, mostly on X. That's the best place to to go. Links to everything that I do. MUXI is on. And Automaze is automaze.io. But yeah, just come on X, follow me, I'll follow back. We'll have a good discussion. And your handle on. It's @aroussi. I can't call it X, I can't call it X. Your handle on Twitter. It's Twitter. Yes. A-R-O-U-S-S-I. Perfect. So that's it. Amazing, Ran.

51:47 Been a real pleasure. Chatting with. Thank you very much for having me. And I love the pleasure. I love the hot takes. Really really wonderful. I hope you at home enjoyed all those hot takes as well. And thanks very much for listening. See you next time. The AI Native Dev is brought to you by Tessl, the package manager for skills and context. Your hosts are Guy Podjarny and me, Simon Maple. Our producer is Tom Dowler. The AI Native Dev is not just a podcast, it's a community. And we host monthly meetups at the Tessl offices in central London.

52:16 Visit ainativedev.io/community to learn more and I hope to see you there.