# Loop Engineering: Automating AI Software Factories

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

## Transcript

Ultimately, your goal should be that agents are doing a lot of this work in the background.
And so the Tesla agent is built to sort of almost get you to stop using it, right?
So you work with it, and at the end, it'll sort of say, hey, I could set some of these up as recurring actions.
I could create a CI-CD check for this.
So in that regard, you might see that the Tesla agent is actually pushing you a little bit more towards this idea of loop engineering and automating its own work in addition to your coding agent.
And at some point, you might say, like, wow, 40, 50% of our PRs don't even have a human looking at it.
We never had to do a big...
initiative to make that happen.
We got started.
We focused on doing what we were doing.
And over time, we could just delegate more to the agent.
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.
We just wrapped up two amazing days at AI DevCon in London.
But the great thing is that we get to do it all over again in New York City this November.
You're absolutely right.
We're going to be back in the city that never sleeps on November 3rd and 4th for more amazing sessions, really engaging hands-on workshops and much more.
Yep, all that great networking, partying, eating and drinking that you've come to expect from AI DevCon.
We think we have one of the best hallway tracks in the business and it's the perfect complement to our incredible speakers and presenters.
We'll both be in person and virtual with live streamed access to all main stage keynotes and talks.
Sign up right now for our super blind bird ticket for just $100, only available for a limited time.
We're really excited to be headed back to the Big Apple.
We hope to see you all there.
Hello everyone, welcome back to the AI Native Dev.
Today, I am excited to announce that we're launching a new product from TESOL, the TESOL Agent.
We're going to spend a good portion of this podcast talking about what this agent is and what it is.
But don't worry, we're not just going to sort of talk about our products over here.
We'll also talk about loop engineering and what that is and why we think it's a thing that you should know about as well.
We'll talk about the importance of ease of use and UX in DevTools, even in the AI era, and maybe some learnings from a company perspective.
about building a product in this era.
So to do all of that, we have Drew, our head of product here from TESOL.
Thanks for joining us here, Drew.
Hi, everybody.
Glad to be here.
Finally made my way onto the podcast.
It's been only a year and a half.
Well, you know, don't take it personally.
We'll see how long it is till the next time.
We'll see.
We're inspecting.
Yeah, yeah, yeah.
Performance review.
So Drew, tell us a little bit about what this TESOL agent is and what is it that we've just launched.
Yeah.
There's sort of two pieces to it.
First is that the Tesla agent is a new agentic interface to all of Tesla's tools.
So everything Tesla does today, helping you scale skills, make them sort of work organization wide, Tesla agent is going to help you set that up, put it together in more flexible, intelligent workflows, sort of connecting the tools.
The second, the Tesla agent is sort of a first step towards a broader vision of loop engineering or factory building.
TESL Agent is a factory-building agent, so it helps you go from scaling skills across your org to building your software factory piece by piece, setting up these loops that will talk about how you engineer them to make agents more effective over time.
Very cool.
And this is, I guess, you'd still run it with the TESL Agent command in the terminal.
It sort of has a little bit of a...
Claude Codex, you know, a similar feel for it.
But, you know, while you can ask it to write code, we don't recommend you do, right?
Like it is focused on sort of, I guess.
Pinning agents down these days is always so hard because at the end of the day, you know, you can ask the Tesla agent to write a poem for you and it will, but I wouldn't recommend it.
It's certainly not built for that.
It's not part of our evals.
No, it's not part of our evals.
So ultimately, though, yeah, using the Tesla agent will feel quite familiar.
It's a terminal-based CLI agent.
You work with, it just feels like cloud code in that sense, right?
Like you just type some commands, it'll pick the right skills and actions to take on top of that.
But in addition to that, we've also designed the Tesla agent to be very automation friendly.
So, you know, as we'll get into the idea of loop engineering.
With much of the work that you put into making agents successful and building up a software factory, you kind of want to get out of these interactive sessions, right?
Those are sort of a transitionary period where you are figuring out what works, figuring out where you can delegate tasks and sort of what are the workflows you want.
But ultimately, your goal should be that agents are doing a lot of this work in the background.
And so the Tesla agent is built to sort of...
almost get you to stop using it, right?
So you work with it, and at the end it'll sort of say, hey, I could set some of these up as recurring actions, I could create a CI-CD check for this.
So in that regard, you might see that the Tesla agent is actually pushing you a little bit more towards this idea of loop engineering and automating its own work in addition to your coding agent work.
Right, okay, so we're going to dig a lot into that, and we'll talk about sort of factory building.
Factory Manager.
Let's start, though, just from a concrete use case.
So I picked up the agent.
What are some examples of things you can do?
Maybe walk us through a bit of a story.
Yeah, I'll give a couple just of how it works.
So probably the one I'm most excited about that we are using a lot here at TESOL is using a TESOL agent to set up your agentic code review harness.
So maybe what I'll do is quickly walk through how you can use the TESOL agent to create an agentic code review, agree with your team on a risk policy for when humans need to review it, and then ultimately set up a recurring loop that will optimize that code review over time so that you can just spend time reviewing code, shipping features, and know that everything's going to get better as you go.
And so there's a few components of this that I think are pretty illustrative of how the Tesla agent works.
So the first, you'd come in and just type something like...
set up agentic code review or I want to spend less time reviewing code.
And the Tessel Agent is going to start by reviewing and creating evidence-backed findings.
So the Tessel Agent is trained or instructed to look through all of your PRs, look through all of your issues in your issue tracker.
and then also to look through coding agent session logs that it has access to.
Those can be either local, or if you've been using TESL for a while and you've been uploading those logs, we can look through those.
We'll try to find...
Exactly.
So it's the kinds of information that you might want to review against.
So it's looking for things like, what is your style guide?
What are common failure cases that agents might have?
What are comments that your team seems to provide frequently in code review?
And then once it's gathered all this information, first it will tell you what it's found.
That information is, as is often the case, what's useful for agents is also useful for humans.
So writing that down, it gives you a chance to correct anything that may be off base there.
And then what it will do is it will walk you through a few concrete components.
So the first is that it will set up a general skill-based agentic PR code review.
And skill-based here is kind of interesting because it's unlike a lot of tools that are just sort of one click, you put it in production, you forget about it.
One of the core principles of TESOL Agent and of TESOL generally is that...
we think people are going to want to own and build their own factories, right?
That this is the kind of thing that will be part of your software engineering discipline, not something you buy off the rack and just take as given.
And so for code review, we give you, we'll help create a skill that we think maps to your code review best practices, but it's a skill that you own.
So you can update it, you can augment it, you can share it with other people, put it in other parts of your workflow.
So we'll set that up and that kind of immediately gets you going.
Now every PR that goes up, you'll get agentic review.
So once it's created that skill, the next thing that it will do is set up an actual automated flow so that when a PR goes up, an agent with that skill will be run.
So there's a few things that we, the TESL agent and TESL can help you with there, which is we provide basic primitives for running an agent through CI, for having it leave inline comments on a GitHub flow, just the sort of niceties that every team ends up building to get a flow that actually works for them.
But TESL is built to be modular by design.
So if there's things you already have or things you already like, the TESL agent is fine working with those as well.
As part of setup, it will try to learn your preferences.
And we have defaults that we think are great, but it works with whatever you want to bring in.
So at this point, you've already used the TESL agent to figure out...
what it should have in a review process to create a unit, a skill, a plugin to be able to execute that code review.
And it specializes a little bit in all these repo automations or whatever other tools.
So let's say, for example, here it created a GitHub action to run that for you, or it uses our app, and we have a little app to help you point it out.
So you're already just with a relatively simple command set up.
automated code review right now that is based on your historical learnings.
Yes, yeah.
And if you're using the TESOL default primitives, you will get a lot of nice things out of the box.
So one will have helped you create that code review skill.
We have a cloud sandbox that you can run the review from, which will have log observability, so you can go in and look at the coding agent logs as it ran.
It's also agent and model agnostic, so you can switch easily between any number of coding agents like Codex, Cloud Code, Gemini, etc., without having to configure all of them.
You just log into TESL and then set which agent you'd like it to use.
Includes open models and open agents as well, which is great for minimizing cost, which is a big one for code review because it's running all the time.
It's an area that's really valuable to optimize.
There's probably a point worth emphasizing, which is the actual review in this setup isn't happening with...
with TESOL itself or with TESOL agent, as we said, that is not a coding agent.
It is running your agent of choice and sets you up so you can actually swap that agent of choice over time.
And we'll talk a little bit more about how evals can help you guide to pick the right ones.
Exactly, exactly.
So we help you get it set up.
So a lot of what TESOL agent does is actually just helping you orchestrate other coding agents.
So sometimes the TESOL agent orchestrates itself, which always gets a little bit meta.
But once you have that generic code review set up, The next thing that the Tesla agent will help you do is set up a PR review sort of human gate.
And what this means is that we found a lot of companies when they adopt agentic code review, the next question they have is, when do I have to review it now versus when can the agent review it?
And they would like to, for simple PRs, for ones that they have deemed to be not risky.
be able to just let a good agentic review handle it, and then they can sort of focus on the more complicated or riskier PRs with their human review time.
This is a common practice.
Basically, what we found most teams get to is you want to agree on some sort of policy across your organization, with your security team, with privacy team, anyone who might be involved.
And then you want to set up an analysis of every PR to decide, based on this policy, does it need a human or does it not?
Right.
And so the TESL gives you, we call it the change risk verifier.
You can configure it with your own policy, but it also comes with a relatively straightforward one out of the box that you can tune between either more permissive, if you'd like to do as much as possible through agentic code review or more strict.
So you can say, I still want humans to review most of the PRs.
So again, help you set that up as an action that will just run within your CICD pipeline.
And then the last thing that we'll do is we'll go through all of your existing skills and context in your repository, and we will create what we call verifiers out of those.
So you can think of these as very small, targeted, and fast LLM linting rules that look at a change, look at the sort of code that's coming into your code base, specifically against different aspects that you've codified in your skills.
So let's say that you have a design...
guidelines that says how accessibility traits should be handled on new elements.
there will be a verifier that we can create for that that looks at specifically files that touch front end and looks just for do they apply those ARIA properties correctly.
And if you stack a bunch of those up and keep them very focused, you can keep them small, fast, cheap, and you basically run them like linting against every change that comes in.
It catches a lot of the mistakes where agents just don't adhere to what you've codified in your skills.
Yeah, I love that.
So we've now, kind of with that command, set up.
three different types of reviews.
You review the code itself, I guess, that you're sort of invoking a coding agent for.
You're reviewing the risk of the change so you can make some smarter decisions about whether you merge them or auto-merge or like a little bit of a flag for people.
So you kind of codify your policy.
And then we introduced this verifiers there, which probably kind of is worthy of a podcast episode on its own.
But really what that does is it reviews whether the agent has adhered.
to the context that you've given it, like the skills, the attempts you've already made within the repo to define how it should behave.
It checks whether it adheres to those.
The verifiers, in my opinion, are the thing that really closes the loop between skills and plugins and the sort of instructions, the control plane you have over agents.
to the actual code that is generated.
So it's a way of saying, I told an agent to do these things, but did it actually do them in a way that is fast and scalable and doesn't require a million tokens every time you want to ask that question?
And then the last piece, I mentioned the Tesla agent will always push you towards the loop.
We sort of believe in loop engineering.
Yeah, exactly getting loopy.
The final thing that will be set up is a recurring daily or weekly, depending on what you'd like, automation where the Tesla agent will scan, again, all of your PRs, CI checks, PR comments, coding agent sessions, and try to find new mistakes that are slipping through.
So, for example, you might start with a more...
strict humans still must review most PRs.
And as humans are leaving review feedback, the Tesla agent is basically observing those and creating new verifiers or updating your review skill to try and capture those issues.
And then it'll use the Tesla platform to create evaluation scenarios to sort of run back and say, okay, I've seen this problem.
I've created what I think is a fix to it.
I've now sort of simulated this PR a few more times.
Yes, now you wouldn't have had to provide that feedback.
And so that's where you get into the automated loop of every day, every week, you're just getting a couple PRs from the Tesla agent that make you just a little more AI native, right?
Like your skills are a little more robust.
Your PR review is catching a few more errors.
Over time, you don't even realize you're necessarily investing in it this way, but you'll see just sooner code review completion, less time on code review.
And at some point you might say, wow, 40-50% of our PRs don't even have a human looking at it.
We never had to do a big push or initiative to make that happen.
We got started, we focused on doing what we were doing, and over time we could just delegate more to the agent.
And I think a core principle that you're describing here is that you set it up to be a loop.
at the time.
And so we've defined a thing that would run recurrently, the skill over here, we're running it in some sort of recurring location in an automation that runs again and again, and now we're surveying it over and over again.
And so because it's a loop, you can observe and you can kind of voice an opinion of saying, has it gotten better?
Has it gotten worse?
Can you just figure out what is that sort of feedback loop that it gets?
Yeah, exactly.
I'd say the loop is probably...
One thing, if somebody was just waking up to agents today in 2026 and looking to get started, I think, interestingly, building these loops, doing this sort of loop engineering, it feels maybe like an advanced topic to start.
But I think in our own experience, in our own working with customers or building our own sort of software factory, it actually feels like the right place to start.
When you get going with these loops, they solve a major problem with agentic development.
In fact, this is one of the main reasons we chose to build the Tesla agent is that building your software factory, making agents more effective, getting them to run more autonomously, delegating work to them, all of that is unplanned work.
You have no way of anticipating where agents will fail, when they'll fail, how much work it's going to take to get them to stop failing.
And so when most teams get started with the traditional boot up an agent, you start interacting with it.
they basically find this place where the agent will have made a mistake and they have to choose between do I push through and ship the feature or do I pause, roll back, and do some science to try and make the agent able to do this in the future.
And so people fall into one of two categories.
They either focus on shipping, in which case they just get stuck in this local maximum where they never take the time to fix the agents and get them to a higher level of autonomy.
Or they fall into the second category.
They are disciplined.
They do focus on that autonomy.
But you're left with this gulf of several months or longer, depending.
It takes forever to build that up.
Exactly.
And it's like, can you eat that sort of a velocity drop as you basically shift all your work into internal tooling?
And so moving to a loop early does two big things.
The first is that these loops run in very legible ways.
So instead of having a bunch of your...
insights into how agents are failing, locked away in local coding agent session logs.
If it's running through a PR review.
It extracts it out.
Exactly.
Exactly.
It's all available to you.
So you can start making these improvements.
And then the loop handles that.
grunt work, right?
Actually putting up the PR that says, I saw this mistake, I think this fixes it.
And it allows you to focus just on, oh yeah, that makes sense, accept, right?
And so it gets the, it matches the sort of investment and the time scale so that you just stay focused on shipping.
Agents will get better naturally as you engage with them.
Right, as you go.
So I love this sort of loop interaction.
And I guess the, we talked about the sort of the loop.
improvement when it comes to the code review and inspect those things.
But there's also a loop around the agentic process, right?
And I really like how in the process of that, we oftentimes sort of preach here the importance of evals and how you do that.
And so...
One of the challenges I guess we've been encountering is that, what do developers not like doing?
They don't like writing docs and writing tests and loading cold.
They kind of need to write those on the app.
So I think what I also like about the concept of the loop...
is that it moves at least the test authoring into something that is done through observation.
So instead of having the human write down the developer and review things, which, again, sometimes you still need to do.
You still need to find those tests up front.
But hidden behind the scenes, if you use the Tesla flow, we will have created some evals for that plugin that you have because we've looked at issues.
But as you do the loop, you can now say, OK, let's extract an eval.
out of that process of it.
And, you know, again, you can kind of debate about how much do you let, you know, like how much do you accept those, you know, autonomously or not, but you extract test cases based on real world scenarios.
So you still get yourself into a place in which you're not only modifying continuously, but you're also building more confidence in your changes because you're creating evals as you go.
But at the same time, you are...
you're not making an effort.
You're not really asking developers to do this thing.
And we should, towards the end, talk a little bit about ease of use and its importance, but it's one of those things where eventually it might be right, but if it's not easy, people won't do it.
So I like that.
Which I guess maybe I'll ask one more question about the review thing, and then we'll expand to some other use cases.
But you mentioned cost in passing, and I guess that comes down to that sort of eval process over here, right?
What happens?
over time, as I run these things, what do I need to do to be able to make it cheaper?
Yeah, yeah, yeah.
Cost's certainly a much hotter topic these days than it was.
It used to be.
It's amazing.
Like a month ago, if you were talking about cost, you were a Luddite.
You're not sufficiently AGI-pilled on it.
And now you're like a forerunner.
You're thinking about it.
You're like open models on it.
So it's amazing how these things twist.
It is.
It certainly makes it hard to build products that are forward-looking and meet people where they are today.
I'd say that there's maybe two big pieces to this.
So again, to your point, we get a lot of questions from folks internally or externally working with customers on how do I think about cost?
How do I make these things cheaper, but without sort of unnecessarily slowing my devs down, right?
Like people are willing to pay if it has good ROI, but they also don't want to just pay because.
I think the first thing, this is I'm sure going to become a broken record of pulling it back to loop engineering, but the first piece of advice I always give, and the Tesla agent really tries to espouse this philosophy, is don't try to optimize your general cost.
If you're thinking about how do I make it so that every time someone opens Claude Code, they're picking the right model, they're planning with Opus, and then delegating to Haiku or things like that.
That's going to be a bit of a losing game, I think, for two reasons.
The first is humans.
Nobody really wants to think about that kind of stuff as they're getting going.
And they'll kind of always default to whatever their preference is.
But the second is that it's also very hard to anticipate up front when a job is going to become complicated.
You might hit an unexpected...
issue snag part of the code base that you thought this was a haiku task or you thought this was a you know GPT-4-1 or something like that but it actually is a 5-5 task right so that is just hard and I'd say for most people you're going to get the best results in your daily interactive driver of just you know use the best model that you're comfortable using and let it be flexible But then alongside that, if you are good about identifying recurring tasks and structuring them into workflows and really relentlessly carving them off of that general purpose path into a dedicated skill or plugin that codifies, this is how we add a new command to our CLI or this is how we do version bumping or anything like that.
Those become great targets for optimization.
And so what I generally say is, The work of delegating and sort of putting a box around a certain task and setting it up to run automated is also the work of cost optimization.
Because then you can find where your bottlenecks are.
Say like, this is a workflow that runs, for example, code review.
Every single PR.
So it's, you know, 50, 60, 70 times a day.
And it's really important to us.
We really need to strike the right balance of cost versus quality.
That's where you can bring in the rest of Tesla's tools to say, I have this skill.
It codifies my workflow for code review, create a bunch of hypothetical PRs for it to review, run it through its paces, try it on a small model, try it on an open model, help me make that trade-off of maybe it's 5% worse, but 80% cheaper.
I'm willing to pay that cost.
And so the Tesla agent basically is built to help you do that process.
It watches you as you work with agents.
It watches the PRs you put up.
And it's going to try and sort of bit by bit move repetitive tasks into structured workflows.
And then once that's in place, it can help you optimize them.
Right.
Yeah.
And I think we've always observed how.
Our evals could help you know, for instance, that you can use DeepSeq instead of Sonnet or instead of GPT-55.
And that's fine.
But one of the struggles was, how do I, again, from a reasonable ease of use, do you really expect people to every time spawn a sub-agent with that or change it and remember what they're doing it?
And so I think one of the hidden wiring that we do when you set up the agent is when you run that environment, we don't just set up the skill in the plugin.
We also run it under this command called Tesla launch, which again, we'll probably sort of write more about, which is more of like an environment management setup, which allows you to then modify that sort of app.
project or that plugin when it runs.
So once you've concluded that, you can also switch easily.
And it's all about the gradual path and the evolution.
This is, I'd say, a big...
So in many ways, a Tesla agent is an interface to and a driver of a lot of these workflows that without the agent, we found that just building up towards a factory was too hard.
There's knowledge that you don't have that's changing every few weeks.
People would try to build their own harnesses and then update their harnesses and then update them again and then, you know, cobbling everything together.
So a lot of what we're doing, to your point, is just trying to bring into one place a vertical agent focused specifically on this task with good tools, the right sort of latest cutting-edge knowledge kept up to date on your behalf.
But you could probably take a bunch of this and use it elsewhere if you want it, right?
We like to work with any agent that you bring, but we also want to make it easy for users.
But there's a second component that you alluded to with one of the new commands we're launching, Tesla Launch, which is basically allowing you to create an environment for agents to run in.
When you get into this task of, okay, I have my sort of skills platform in place, I have the governance, the security, the standardization that I want, I'm ready to start scaling and building these loops.
teams immediately start building the same few primitives over and over again.
You need a way to wire your issue tracker up to some kind of agent environment to kick off tasks.
You need a whole suite of agentic code review.
You have things like, when a task finishes, I want to post back to the issue tracker.
And so alongside the Tesla agent, we're releasing a whole bunch of building blocks that make those parts easy.
So the big one that you mentioned, Tesla launch, is just a sort of dead simple drop it in coding agent environment, runs in the cloud, gathers all the logs for you to review and do that sort of optimization loop against.
But it also just has good defaults.
It can run for longer than 60 minutes.
It doesn't have to refresh its GitHub action token all the time.
Easy to switch between agents.
There's a few others that I'm sure we'll detail in the launch blog post.
But all these things come together, to your point, to make it really easy to just start building your factory one piece at a time.
You don't have to pause and do a foundational investment to build a linear app and a GitHub app that can talk to each other and then think about the polling semantics.
You can just find a task.
put it in automation, and then find the next task, find the next task.
And it's never going to feel like you're stopping to do this big initiative.
You're just slowly working towards automation.
Yeah, so I love that definition.
And I guess also, probably as people think about sort of Tesla as a whole, you know, we increasingly think about Tesla as this sort of composable factory, right?
And you run the agent, and you can use the Tesla tools.
And clearly, you know, we're sort of quite familiar, we built the tools for a reason, you know, we have those, whether those are the existing tools like...
our ability to eval and gather logs and analyze them, but also, you know, or these newer capabilities that we're introducing.
But the idea of the agent is, you know, it can help pull that together and provide you these different services to help you.
So we said a lot about code review in the process of it.
Can you just sort of quickly name a few other examples of loops or use cases that the agent can help you with?
So...
There's sort of infinite, which always makes it hard to talk about these products, but I will control myself.
Just a few.
So after setting up code review, I think my next few favorite.
First is you can just ask the agent, what could I delegate to agents?
And it will go and look through recurring tasks that seem to succeed with a high rate for you and suggest creating automated CI, CD actions around that.
Another thing that you can do is if there is a certain component or type of feature that agents have been struggling with, you can just ask Tesla agent, you know, help agents work in my front end or make agents more effective at designing layouts.
And it will go and it will analyze, find failures, pull them in.
Another great one to get started is just make my repo agent ready.
This will do a bunch of things, but one of the main things is we have a bunch of default repo maintenance tasks.
daily architecture review, test quality checks, things like that, that we'll just set up for you.
It's a great way to get going of just immediately hand off a bunch of work to agents in a sort of general purpose way.
So I'd say those are probably the ones that get started.
Just set up code review, fix a thorny issue where agents have just been messing up in your code base, set up repo maintenance tasks, or just ask the Tesla agent to help you delegate.
more work to ai and then it'll go from there yeah i love those i also i like uh recurring things around all of those activities and so like each of those things once you get them loopy uh you you start saying okay run a kind of recurring architecture review yeah you know fix my flaky tests uh on a recurring fashion yeah and once you have one set of loops then you can make loops around those loops so You set up your daily architecture review, but then eventually you can set up a loop that monitors your daily architecture review and makes it more effective every single day or week.
And all of this, I know it can seem a bit overwhelming, just loops on loops on loops.
Tessel Agent is designed to handle all of this.
So you just give it the task, give it the problem you're seeing.
And one of the main things that the Tessel Agent does is think about how to break it down into a loop.
and suggest an automation so that you never have to do the same task more than once or twice.
And maybe I'll also highlight that many of these automations in these loops, they will oftentimes be focused on the repo itself.
So the other flexible aspect of it is, oftentimes you will set up those optimizations and they will land.
as let's say a GitHub action that runs on a schedule or things like that if you're doing something that's in the repo.
And then of course you can set up automations that are a bit more broadly.
So lots and lots to do.
So much to do.
So a common question that we get and discuss with customers around this notion of building a factory versus buying one.
I think today it's sort of a non-controversial statement to say that everybody needs to...
kind of work towards a factory?
Maybe you can say a few words about sort of our philosophy when it comes to kind of factory building and kind of, you know, own it versus buy it.
Yeah, of course.
So I'll belie some of my roots here.
I started my career working on open web platform, web standards.
So certainly have a bit of a bleeding heart for this as well.
But I also think it makes good sound business sense.
At TESOL, we think that...
The factory that you build is going to be a piece of technology.
It's going to be a differentiator that your team owns.
It's part of your software discipline is building and maintaining this factory and that there will be repeating components to a factory, but that everyone's factory will look slightly different based on your preferences and the services that you use.
So factory platforms will be much more like platforms, less like frameworks or like end-to-end solutions that you just...
buy-off-the-shelf black box.
And we think that for a few reasons.
I think the most important one is that when you think about the grand total of building software products, right, there's a lot that goes into it.
It just seems hard to imagine how a single provider, a single company could be best in breed at every single component that goes into that, right?
design mockups, code review, actually generating code, working with your legal team, sales, like all those things need to be brought into the factory over time and buying into a single solution somewhere in that stack, you're going to be buying into not the best version of that component.
And so we think that being open, modular, Tesla wants to provide good defaults so you don't have to think about it if you don't care about it.
But for the parts that you care about, you need to be able to plug in either your own built solution or the best of breed so that you can be getting the results that you need.
That's an important one.
I think the other is that when you think of how critical this factory is going to be to your company, I mean, in effect, it is.
the thing that produces your product.
It's what you're developing now.
Yeah, exactly.
And so it's a very sensitive place to be bought into a fully integrated solution that now has complete pricing leverage over you.
If you think about just the sorts of processes and workflows that you bake in, they're very specific, and that's part of what becomes your IP, your moat against competitors.
But imagine if then all of that work you've built to differentiate yourself is now...
owned by someone else.
And so they say, hey, everything that makes your company you is in our ecosystem.
And so we're going to crank up the token cost, the token spend, etc.
And so we think that your factory needs to be built on an open modular framework that you can sort of trust to assess its own work.
Optimizing the factory is like an important component of the factory.
And so you need to trust it when it says.
hey, this time you really do need to use the biggest model and you do need to spend 50% more on tokens.
You don't want to be questioning those kinds of suggestions.
And then finally, it's like a big part of TESL is we like to think of there's the rails that your factory runs on and then there are the artifacts and knowledge, the context basically that powers those rails in the factory.
And for that, we believe that you should own those artifacts so that you can always pick up and move to another provider.
you basically own the secret sauce, right?
So a great example of this with code review, we think that there is a general harness that should provide code review, but you don't want the brain of your code review to be locked inside that harness.
You want to be able to say, look, we found a better tool, we're going to move to it.
All of the work we've put into finally crafting our workflow, our style guide, the things that we've worked for, that's just a skill checked into our repo, so we can go plug that into any brain.
And I think, so this is very consistent with how we've generally been thinking about sort of, you know, context and skills and building those out, which is, you know, we believe in the future you will have many agents because agents will specialize in different things.
We think you will need to sort of share context with them.
And similarly, we think you'll actually have multiple factories.
You know, you'll have different factory lines or different sort of aspects that optimize for different parts and different sort of, you know, stages of development.
And really, we're talking a lot about software factories.
But we expect very much that this sort of expands into agentic factories.
And also, maybe it's worth pointing out that while all of this stuff, it could sound a little bit like a change from what we have been discussing all this time.
We've been talking about scaling skills and governing them and securing them.
And a lot about context, and context is the new code.
How do we think about that?
So I guess it's worth maybe taking a moment a little bit to say, we don't perceive this as a pivot.
We see it as an expansion.
I guess, how does all of this conversation around scaling context, scaling skills that, you know.
Again, customers have a real pain around it.
How does that relate to the agent?
Over here, we're starting saying loop engineering.
We alluded to harness engineering on it, which, again, probably needs its own conversation on the podcast.
How do you see the two interacting?
On the product team, there's always this question of what is our field to play on or not?
And so we're always asking the question for a new feature.
Does it make sense for us to solve this problem?
And this is actually one of the easier choices or easier decisions.
When we think of TESL's mission of agent enablement, we want to help you actually bring coding agents and all agents in the future to do real productive work for you.
This just feels like a very natural extension of that.
So in that regard, I think it's all part of the same goal, which is help you actually deploy and delegate work to agents effectively and get real productive work done.
Maybe from a more mechanical perspective, I think all of these are aspects of the same solution.
So it really sort of depends on where you're starting.
So most companies that have gotten started with agents, they're starting to feel skill sprawl.
They have hundreds, thousands of skills.
They don't know which ones are good.
They don't know where the duplicates are.
Those folks want to get started on the governance end of the spectrum.
They're going to say, help me inventory all of my skills.
use TESOL to do a security review, find any vulnerabilities, then create policies to make sure that we never have this issue again.
They're going to start doing review, quality review on skills, codifying their best practices.
You can think of this as taking charge of a sort of grounds-up upswell that you want to now make sure scales effectively across your company.
Right.
And it's worth noting that that's also the whole world of non-dev skills is where we've seen a lot of pickup and adoption, which is what we help a lot of customers deal with.
with kind of that world of they have their sales skills, their marketing skills, their product skills on it.
Those worlds are generally not ready for words like factory.
There's sort of a lot more around just sort of share best practices, basic around usage packaged up in the form of skills and rules.
I think of this as the very sort of bottoms up form of factory building.
Increasingly, I think of all of this as factory building.
The question is, do you build a factory by focusing on the components first, right?
finding your workflows, putting them into skills, getting your team trained up on how to work with agents, how to review their work?
Or are you a bit more on the leading edge of things?
You want to start factory first, and then as you get automated workflows running, you're going to go in and decompose the components that matter that you then want to add in things like governance or standardization, right?
So coming from this other direction, you might...
come in immediately with set up agentic code review or agents can't work with our front end layout, make it better and then make sure they never get worse at it again.
Right.
And so you're starting with these loops.
And I think it's a great way to get started if you are introducing your team for the first time to agents, because this is very focused on.
making agents effective and delegating work to them.
It's a quick path to value.
Exactly.
And you're actually setting yourself up in a good spot.
Yeah.
And it helps you also isolate the change as you work.
You have one team just get started with agents, make themselves a bit more effective.
You don't have to worry about the governance and the security parts at this point because it's just one team working on it.
But at some point, you're going to want to start scaling that.
out, right?
Like you'll have proven it with one team, they're effective, they've automated a lot of their work, they want to start interfacing with other teams in this automated fashion.
And that's where these governance and standardization primitives come in.
We say, okay, now, I'm going to start letting everyone in the company throw skills into this registry, we see again and again, is all these things run at the pace of agents.
And so The first week you'll say, I'm just getting started with skills.
And then the second week you're like, I have 15,000 skills.
What happened?
So you kind of have to get these primitives in earlier than you probably would normally.
But it really just depends on what are you trying to do first?
Are you trying to bring agents across your organization?
Or are you trying to sort of go deep on some agentic flows and get them automated?
Yeah.
Cool, cool.
So I think for us, we try to build all of that in that type of kind of composable approach to helping you build that factory, that estate.
So it's always in your control.
It's your context, it's your plugins, it's your workflows.
And now it is your loops and your harnesses that will help you optimize.
And I guess just as a side comment, we focus very much here on the agents.
advantages in the sort of new competency from in terms of like Tesla helping you with loop engineering and harness engineering.
But the agent is also an interface for many other things.
And we love sort of seeing customers use it for customizing and defining their policy, for handling that inventory processes, for sort of building those out.
So excited about the agent.
And it's interesting how...
We kind of grew to accept and get used to in the web interface having a little agent chat on the side.
And I'd say, fine, yeah, you have all of these things that you can invoke, but then you can have the agent to just...
perform a bunch of actions for me, whether it's on my slide deck or in my analytics portal or whatever it is.
But we still think it's a slightly bigger deal or change when it's on the command line interface.
So in that sense, it is also just a command line interface.
And it will eventually make its way to the web interface as well.
Starting with the local CLI, it just gives you the most flexibility.
And so given Tesla's overall approach to factory building, it just It seemed like a no-brainer.
Let's start with the thing that gives people the most power and then, exactly to your point, coming very soon we'll have much more streamlined interfaces for folks who aren't comfortable with the command line or who just want something in a simpler GUI interface, things like that.
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.
So we're kind of running up on time here.
I want to maybe share kind of one learning from the product building side of this, which I think is sort of useful and it's interesting.
Or maybe even two.
One is...
It's just sort of reiterating the importance of ease of use, right?
We're seeing this like in, I like talking about how, you know, even like in sneak days, I would talk about ease of use for security and, you know, how for everything in life, there's how much you care about something and how hard it is.
And you need to care more than it is hard.
And then you act.
And so it's interesting to see the action over here.
And I think one of the things we're trying to address in terms of ease of use is...
is just the ease of use of getting into this business.
It has kind of a newer problem.
It's not a new problem that you can't keep up, but it's a much bigger problem right now on it.
So the agent kind of embodies a bunch of that knowledge.
So yes, technically you can run it with whatever, with your codex, with your cloud, with your Gemini, but you need to know what you're doing and it's a lot of work.
And then whatever it is you thought, like loop engineering is like a few weeks old, best in terms of a term.
And so capture that knowledge.
It's about ease of use of...
of the UX, of being able to run a bunch of these things.
It's buddies of use with sort of TESOL providing a bunch of these tools around it.
So you don't need to say, okay, you can do this, but now you need to equip yourself with these seven different sort of foundations on it.
Which again, over time, you might modify, you might switch.
push us to build better tools.
And I guess it's about the ease of use feedback loop, right?
Because what we've seen is we created tools, we gave them to users.
We wanted to make it easier, so we gave them skills as well, and they ran.
But as they would run them in their coding agent of choice, it was It was hard for us to fix problems that we've seen.
It's hard to see visibility.
Like as a product builder, you want to be able to see what's going on so that you can improve.
It was hard to fix issues.
If the agents went sideways or a new, whatever, anthropic model sort of suddenly became less obedient, which we've had many cases of that, or tuning it.
And so the harness gives us that.
I guess as I think about it.
and this kind of spills a bit into my sort of second view, is that increasingly I think that the shape of a product in the AI era is sort of these like four components, which is a set of tools that you build, which we used to call in like the pre-AI era.
products.
Those are kind of the capabilities, but now we think about them as tools.
A set of skills, kind of embodied expertise, a harness to be able to provide a UX and bundle all of those things.
This is our harness.
We also help you build your harness and the likes.
And then some form of control center or like central repository for collaboration, especially as you go.
across time and across people to do that, which we offer with the platform.
So it was an interesting kind of learning process here.
The way that I've sort of brought it together when thinking about designing new products in maybe like a very concrete way is that, like you said, ease of use has always mattered, but agents have added a few new layers, especially if you're thinking about DevTool products, which is that...
Historically, I think DevTools have focused a lot more on providing expressive power, like make sure that you have really modular, composable primitives to do high-value tasks.
And there was just sort of an expectation that the value is going to be enough, that as a developer, you will learn my new vocabulary, you will stitch them together, you will do a lot of building on your own.
And I think the first thing to really internalize about agents is that...
they really made all of us insatiable, like outcome-oriented machines, right?
Gone are the days where you say, oh yeah, to do this, just call this command, then this command, then this command.
And they're all like, you got to learn a bit, but no, it's worth it.
And then now it's like, I'm going to tell you what I want and I expect everything to happen.
And so that sort of end to end, I want to speak in outcomes.
I don't want to speak in the language of your product is, has never been more extreme in this moment.
I think the second is the usability of knowledge is supercharged.
Agents are changing so fast, they're changing the industry so fast that not only is there just a lot to learn because there's all these new concepts coming out, but learning is no longer a one-time event.
We've always had continual learning, but now continual learning means daily or weekly.
I think a significant portion of usability that you can provide is handling that on behalf of your users, keeping things up to date for them.
And then maybe an out-outshirt of that, as you yourself become more agent-enabled as a product company, one thing that we have found is quickly your rate of shipping features will start to outstrip your GTM motions, eventually just your users' ability to ingest the changes.
And so you sort of end up getting back into this place where...
you have to provide an agentic interface that is keeping up with the change of your product so that users can stay focused on the thing that is stable, which is their business and what they want to be doing.
And then the agent is constantly updating and translating that into the latest and greatest in your product.
Yeah, it's agents all the way down.
Yeah, the answer is always more agents.
Yeah, indeed.
So lots of exciting things.
talking about learning and talking about knowledge on it, worth noting that we're actually also launching just now tesl.io slash learn, which has some interesting agentic patterns and has education capabilities.
So hopefully people will check that out.
This episode was dedicated to the TESL agent, but there's more that we've been chipping as the pace picks up.
So before we close off, Drew, just...
A couple of words about what happens next now.
We launch the agent, what happens next, and then how can people get started?
Yeah, so number one, we've just launched.
We're really excited to get feedback from folks.
Sort of always the name of the game is you can expect the Tesla agent to get faster, cheaper, smarter at everything we've talked about here.
And then from there, I think we're really just focused on how do we make it easier, more seamless to go from any starting point you may be at with...
scaling skills or exploring a few automations to how can we get you towards that factory vision faster with less effort, less uncertainty, lack of confidence as you go, but really focused on that incremental path.
I think that's the main thing to expect from Tesla is we're the...
We want to be the tool that helps you go from where you are today to factory.
We're not just the, hey, if you can throw everything out and build a greenfield code base, you can do the cutting edge.
So expect to see more there.
Indeed.
This notion of, we talked about the catchphrase, right, from scaling skills to a full-on factory.
Maybe there's loops somewhere in the process of it, but it's okay.
Everybody's behind.
Let's sort of gradually...
No one feels comfortable.
Everyone wants to go faster.
We're here to help you move through that process.
In terms of how to get started, it's pretty easy.
Just go to the website, download the TESL CLI, and then ask it to do something for you.
So TESL agent, hit enter, just like every other agent.
It'll open a session, ask it to set up code review, ask it to delegate some work to AI for you.
All of those things will work just fine.
It's an agent, so you can ask it to do other things as well.
And then over time, more and more of it will be put into automation just as you work with the agent.
Yeah.
And I think if you want to do the experiment, you can also try out having different team members run the Tessel Agent because it does look a little bit at their logs.
And so there's a little bit of an element of if you heard that someone is having a problem, having them try the Tessel Agent, that might be an interesting experiment.
Yes.
Yeah.
It's a great way.
The Tessel Agent both can look at your local logs.
It can also help you get your logs into a communal space.
And as a point of getting started, sometimes just...
sitting down with the last month's worth of coding agent sessions and just asking what's broken, what's taking a lot of our time will yield some really interesting results.
So...
I think that's it for us.
Hopefully you find the TESL agent interesting.
We'd love to have you try it out and share feedback.
This is very much about iterating.
Hopefully you're well familiar that we're all about the community at TESL.
So join the AI Native Dev Discord, share comments and feedback that you have around the product, things you love, things you want to see us change.
We're super, super excited about the TESL agent over here.
We're getting a little bit told off a little bit about...
just sort of how much we talk about it, but very, very keen to see it come to life.
Early users, thanks a lot for all the great feedback and evolutions for it.
And yeah, try it out and tell us what you think.
Yeah, can't wait.
And with that, thanks for tuning into this episode and hope you join us for the next one.
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 TESL offices in central London.
Visit tesl.io forward slash community to learn more, and I hope to see you there.