# Agentic Coding Strategy and Dev Agency Models

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-09-08

## Transcript

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.
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 will be able to command a team of agents.
And I'm not in any sort of fantasy that you can manage thousands of agents, but you can manage six 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 Pajani, and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.
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 VPs packed in to hear speakers from Anthropic, OpenAI, Netlify and GitHub cut through the hype and get to what actually works.
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.
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 Ran Aroussi, 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, 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, Ran.
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 Y Finance.
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.
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 Y Finance.
And it just took off.
I mean, 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.
And I've done this for a living for a while.
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.
And 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.
And I remember just a few years ago, I boasted about having $600,000 every month.
It's quite insane.
And this number keeps accumulating because it turns out that every time you ask AI to write anything related to market data, it uses that.
So I assume that is part of the real growth over the past year.
Wasn't there a time when actually Yahoo dropped their API for that?
They never drop their API.
So the way the library works is not by scraping or it's using the official 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, they said, okay, sorry, and they backed off.
So I assume they weren't even hired by Yahoo.
They were just trying to land them as a client or something.
uh but yeah this is definitely not the the only library that does this i just think that it it's doing it really well and that the interface is uh api wise is very pythonic and very simple which is something that i really believe in uh let's cut the number of of uh code lines that you need to have and um yeah um over the past four or five years, I'm running a software development company called Automaze, as you mentioned.
And we tend to kind of do, now 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 spirit of the company.
I help with the specking of the products because my experience over the past few decades is, I've been both in product and in tech, so I kind of walk and talk the two languages.
And I have a great team that's scattered all around Europe that does the actual development.
And one of my most recent pet projects that turned into a behemoth of a code base, although it's...
not nearly as used as Wi-Fi is as MUX as you mentioned, 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...
Maxi, pull, push.
You pull a formation, which is in 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 formation's 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.
This one does email.
This one is a good writer.
And I just wanted to talk to Jarvis and have it manage whatever agents it needs.
A formation basically tells you, okay, which models am I going to use?
What are the back of where they're not?
I have role-based access management.
What type of memory allowance do I give the database?
Is this organizational deployment where I'm going to use Postgres with all different types of extension or just for me 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 a format that I call the agent formation schema.
It's again fully open source available in agentformations.org.
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 access to.
It has a very elaborate memory.
structure where it has it 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 uh i'm really philosophical here because what I'm trying to do is mimic how the human brain works when it comes to memories.
There's the misconception where observation and logging is memory.
I don't think so.
I think the distillation 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 an organic memory needs to work.
So it's all bundled in.
You don't have to worry about it.
You don't have to.
You just need to essentially configure what you're...
uh agentic ai can do which tools do you want to remove from the registry you know you're using uh stripe mcp with a million tools over there and you only need three so there's no reason to hog the memory just tell okay these are the only two or three tools that i actually use in this application it's not gonna load any of the other ones into memory uh so yeah it's uh it's it's very well thought out based on the needs that i've encountered both in my own own personal kind of Jarvis journey.
And what I noticed with organizations that we've deployed, we actually created a separate company in the US for deploying agentic AI at the organizational level.
So yeah, that's in a gist.
One of the interesting things there is the kind of like operating instructions, as it were, for a formation.
I believe that they can kind of like retrospectively look at those instructions and say, actually, I want to change my own instructions based on historic kind of like how things 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.
Where do you kind of like feel today we should draw the line between pure autonomy?
where things can essentially self-heal, 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?
I actually think...
that it's more of a trust line.
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.
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 help you get unstuck.
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 have the test passed.
Get the test screen quick.
Yeah, exactly.
By any means.
And we've all seen code with the comments by the AI, this needs to be changed later to dot, dot, dot.
And in order to have that trust, I think that the human still needs to be in the planning.
and in the confirmation stage.
So you need to, what is the definition of done?
What am I trying to achieve?
And you need to be there in these two steps in the specking.
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 uh code profiling and this need we need to achieve um these amount of tests and regression tests and you put all sorts of constraints that by definition the code quality is good if everything is green um the fact whether or not it's pretty or not you're not going to look at it anyway in the future so it doesn't matter What matters is that it's efficient and that it's maintainable by the AI.
And you can solve this with all sorts 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.
And going back to Moxie, you mentioned that 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, and you can look at the diff, and if you approve it, then you deploy a version, whatever it is, 0.1.
uh 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 you just put put in the time yeah to review it yeah it's very interesting actually because i mean for us at tesla we have our own software factory uh 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 some of our internal tools, for example, our own dark factory, we allow fully autonomous going from issue all the way through to...
you know, a pull request that gets merged without it's merged.
Okay.
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 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.
And we don't even realize those issues are being created or merged at all.
And 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.
If it's mission critical and it's part of your brand, you want to have humans in the loop.
And yeah, the role of humans would shift.
Even in the few months that we have to the end of this year, it will change.
And the role will move and maybe diminish, but I don't think it's going to be removed.
No.
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 in while they're still in production even.
Automatically, a diagnosis creates it and there's a PR waiting for us on the other side.
And it's been really fun to have this tool and you just wake up to PRs.
And that's, yeah, it's particularly important in the 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've 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.
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 log items.
So you have to have those systems in place to actually do this for you.
Hey everyone, my name is Sahil and I'm one of the engineers here at TESOL.
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 TESOL 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 TESOL and some of the specifics on how it works and why we made some of the decisions that we did.
Go to tesl.io slash events and I hope to see you all there.
Now Ran, you've also Created a number of books.
I'm not an author other than blog posts.
I don't think that...
That's a lot.
I'm not that I'm really an author from that.
But 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.
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 so i separate this uh into two terms there's automations there's fully agentic which means autonomous uh 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 or automation with AI sprinkled in.
And I think there's a misconception that agentic workflow, the term itself, is kind of an oxymoron.
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 I think that that's where a lot of the focus is on right now.
Most people who are doing AI and agentic stuff, this is actually what they're focusing on.
They're not focusing on actually creating this entity that can actually think 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 agentic automation and all of that stuff.
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 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 OpenClo or Hermes or anything like that, that just decides on its own.
And yeah, so that would be my take on it.
I think that if you're thinking whether or not you should go fully agentic and autonomous, first think of whether or not 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 shouldn't be used and it's just costing you money.
We're a simple script.
The number of times I've seen AI try being used to...
parse strings where simple regis can just do the work.
Faster, cheaper.
Faster, cheaper.
Literally free.
So, yeah, it's a shame.
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 the realization that for at least a year now, you do not need to hire junior developers for their coding skills.
You don't need them for that.
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 understand the product.
So it's both a product manager, a project manager, and a team lead where the team is agents in that case.
So we work in an operation where we have pods and that pod has the senior developers, kind of the architect, manage these agents.
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 uh they kind of joining along like you know go in the Renaissance days you had the apprentice and they would join the the master painter and kind of learn the rope and dabble around and Santa would get their own project and he 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 will be able to command a team of agents.
And I'm not in any sort of fantasy that you can manage thousands of agents, but you can manage six to 10 maybe.
But you need to, that goes back to the workflow itself.
You need to know how to spec products.
You need to know what agents are capable of and what we're not capable of.
be their mentor uh when they when it's time to develop a software and um you know be at the gate where okay is it ready for production uh did i put in the right um workflows uh where when the pr is ready i want to immediately create an environment where the full system is up and uh end-to-end test run and so you need to learn these types of things and um These are things that I don't think you can learn from reading programming books.
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, I need to sit down, do these deep designs, then code, then blah, blah, blah.
But from the junior developer side, of course, they don't truly understand, you know, the more complex architectures, complex designs.
When they wake up at three in the morning 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?
Where are the disadvantages for either?
I think that they have to work together because of the examples that you've given.
this is earned experience.
You cannot accelerate that.
You have to be there and you have to understand the consequences of, you know, just how much load can a two VCPU machine can handle.
Okay, 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.
So you need to have this...
It is earned experience.
There's no way of condensing that time.
But if we can take a junior developer, it used to take a junior developer three to four years to become a good level of mid-level developer and seven to eight 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.
I'm sure you're seeing a lot more value from junior developers when they're here a year versus junior developers that were after a year, like five years ago.
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?
And then come more baked.
with the questions ready to the senior developers for help.
And I think that that's exactly the role of an apprentice and a mentor kind of relationship, that they have to be together for a while before the junior is ready to start their own pod.
And I'm not in any rush to give them their own pod.
I mean, I think that if it's going to take them a year or two, that's fine.
It used to take five or 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.
Well, not taken away, but so many things are being automated 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 earned 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 with?
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 ones we have for the past 20 years.
And I don't know her number by heart.
I barely know mine.
Because we just, when 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 how much it can do for us before we forget how to do it ourselves completely.
So whether or not 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 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 drill yourself into, just create a situation for you.
And that might be a partial solution, just create those false alarms.
Every office building have fire drills.
So you'll have to do these apparently.
With these new workflows and our teams being adjusted into a more 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 weary about a year ago what would happen to our...
sales.
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 development time, probably for proof of concept.
you can reduce it to up to like 80 of the time you can cut off 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 percent 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.
The backlog of, oh, we might get to it one day.
It's actually becoming a reality now.
So do customers expect to pay less for functionality and features now?
Or is it, you know...
I assume they do, but since we charge on the monthly retainer anyway, so yeah, they pay less per feature, but our pricing model hadn't changed.
So we have clients staying with us for three years on average.
So yeah, 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 Coder coding experiments.
They're coming to us with an app that they've developed.
And obviously it's not anywhere near ready for going to production.
But I actually like this.
Some people resent that as a developer, as an agency that provides software development.
But I actually like it because I know exactly what the client is after.
Sure, we're going to have to replace 99% of the code and redo everything, maybe change stacks.
But it's fine, as long as you can develop your vision.
even if it looks ugly or whatever it is.
But we get a real sense of what you're after from a product perspective.
Even if you just do mocks, that's fine.
Just a bunch of HTML pages that sort of look like the app you're imagining.
I actually like it because there's no misunderstanding there.
So I actually like it very much.
More clarity than just a speck or something flat on the paper.
Yeah, exactly.
Now, Ryan, I understand you, I don't know if you still do, you used to certainly act as an FDE for every new Automaze client.
Is that still the case today?
Some.
Some.
Yeah, it's true to some extent.
First of all, tell us what is the role of an FDE?
And then secondly, I'd love to understand how that scales.
Is that something, you know, you eventually think I need to give this up.
I need to grow my FDE team.
Tell us a little bit about that.
Right now, we're about closing in on 30 developers on the team.
And when we start with any new project that we're doing for the first time, that kind of project, so whether or not it's a transformation project, or we're doing a new thing with healthcare, or whatever it is, I'd like to be there.
And the clients would like me to be there, along with one of the two development leads that are running the show there.
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 the role of an FD is basically to be deployed at the company remotely or in person, which for us is...
as 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 and even if you're creating i don't know just an e-commerce website you need to understand how the fulfillment on the company side is is yeah we know what the shopping site look like but how the back end looks like for that company might be completely different than what it looks for a different company and uh you know i'm all for let's mold the technology around the company and not the other way around so um i feel that i need to be there at least in spirit, at least for the first, like, that's a 10% 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 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.
So everything that we're doing for the first time in that sense, then I like to be involved and then hand it off to the team.
Yeah, it works.
It works.
We're not doing the FD in a traditional sense of like we're implemented and embedded into the company forever.
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.
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 go big picture now and talk about some of the fun things, some of the fun quotes and some of the fun hot takes you've had.
The first one I'd love to talk about is when you called an agent workflow an oxymoron.
First of all, what did you mean by that?
So I've talked about this before.
A workflow is not agentic by nature.
A workflow is a deterministic set 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.
So for something to be called agentic, it has to be fuzzy.
It has to be non-deterministic by nature.
And that's just my take on the reason why I think that it's just the wrong word to say.
It's not the workflow that is agentic.
The workflow is...
I want to say static, but a very deterministic workflow that has agentic components in it.
But the workflow itself isn't agentic.
So 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 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 agentic workflow where the workflow isn't necessarily deterministic but the agents determine what needs to be done based on certain criteria 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 see 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.
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 autonomous.
So it knows the company and it acts as an employee that's really open-minded and kind of try 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.
So, yeah, I think that we need to go more to that type of direction.
And ultimately, we do need that determinism in the workflow.
Yes.
For a lot of things, you will always need the determination.
But you can have workflows, but you can have an agentic entity that decides on which workflow needs to be called right now.
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.
Your work is a lot more dynamic, but for every task that makes up 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, and within those environments, just let them do their thing.
Another hot take, Ron.
Anthropic risks turning its strongest advocates into its loudest critics because of a specific strategic signal.
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 is a great successful project by Peter Steinberger.
And it used Claude, and specifically the Claude Pro and Max Plan in order to act as its brain.
They just shut it off the 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?
The solution is not let's shut it off.
The solution is...
have a toggle mode you do have a co-work mode now so you could have done an open claw mod uh so it's it's it was a very weak argument and um the the reason was um was financial obviously and uh i'm fine with that that that's fine it's your it's it's your company you need to make money but Don't BS, 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 um 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 um yeah it's it's kind of uh do you see other providers following suit there or i i think that uh we're seeing the exact opposite actually um Maybe it's just a temporary strategic move by OpenAI to say, hey, you can use it for whatever you want.
Grok is also doing that.
Of course, the Peter Steinberg situation was quite specific because Peter now works for OpenAI.
Yeah, exactly.
But I think they actually told you 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 Entropic has done.
I think this whole subscription model, it's eventually going to go away or it's going to be a lot more specific.
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 a discounted, but you're not going to, sorry, discounted price on X number of tokens, but you're not going to get 60X.
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 miracle chip that everyone's working on and we'll probably see, but I don't think we're months away from it.
I don't think we're even a year or two away from it.
be able to dramatically cut down their costs, it's a race to the bottom.
And I think that as soon as Anthropic goes IPO or something like that, they have no...
The motivation for such an aggressive user acquisition and growth slightly reduces once they're IPO'd.
Let's take one more hot take.
I 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 and Ellis than a SaaS startup.
Why do you think that?
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.
obviously we're already there but on a really production level we're almost there so you can be um a reasonably good developer and you can start your own firm because you're not limited by the capacity the however meetings you can hold to close sales that that's your true capacity it's not about the development so if you really want to attract and hold on to talent you have to give them stake in the company So that's why 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 into, buy the business that you bring in.
But if it wasn't for this model, there'll be just more and more law firms instead of more and more partners inside existing law firms.
And it is a matter of motivation.
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 hyper growth, 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 a cake.
and you say okay you're bringing you you handle your own pod uh so you get this amount of cut from uh the revenue or from uh 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 agreement uh which it's very clear we know what we get from the client that's all you need to know as a royalty partner yeah so uh and it's our problem to solve uh all the the expenses stuff part but yeah if i want to hold you i need to make you a junior partner than a senior partner and give you the ability to earn and i think that companies that especially software uh shops that are not going to use that model in the next few years and we're not still fully there i i'm If I'm being honest, we're not there, but we're heading there.
We built our pod model, and then we're slowly moving to that direction.
But once you have a senior developer that manages a pod, and they're handling two, three, 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 these clients are bringing $10 a month.
why would they stick around with the company if they can say, okay, I'm going to earn zero for a couple of months, but I'm going to lend my own clients, even one client.
I'm going to have less work and more money.
I'm just going to keep everything.
So you need to be able to say, you know what?
10, 20, whatever it is, percent of the clients that you manage are yours.
Another 10, 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 and what I liked about this model is that the motivation is aligned.
So everyone wants the business to make money.
And 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 their employees?
And also, does this lead to almost an explosion of new startups being created?
If not, because people will think, well, actually, as you say, I need one client and I'll get more than the 10 clients or the same as 10 clients worth of revenue.
So it really depends on the startup.
Most startups are not profitable by definition.
That's part of their growth strategy.
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 for 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 that's that's a focus you're not playing a goal it's never going to be even with automates we're not going to be a hundred million dollar business uh but we are going to continue to generate good amount of money and that's the cake that we have to offer so um Maybe I'll sell it in the future.
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 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're definitely going to see that.
So you're definitely going to see, or hopefully, I don't know if definitely, but hopefully you're going to see this.
And not only for software stuff.
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 need a lot fewer clients to match their salary.
than what they serve right now under this umbrella.
So just align those interests.
Amazing.
Rant, where can people find, where can our listeners find out more about Automaze and Muxi?
Well, I'm mostly on X, so that's the best place to go.
I link to everything that I do.
Muxi is on Muxi.org, M-U-X-I.org.
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?
I can't call it X.
I can't call it X.
Your handle on Twitter?
Twitter, yes.
A-R-O-U-S-S-I.
Perfect.
So that's it.
Amazing.
Ran, it's been a real pleasure chatting with you.
Thank you very much for having me.
And 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 TESL, the package manager for skills and context.
Your hosts are Guy Pajani 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 Tesla offices in central London.
Visit tesl.io forward slash community to learn more, and I hope to see you there.