# Kilo Code Acquisition and AI Engineering Strategy

**Podcast:** Tech Lead Journal
**Published:** 2026-09-07

## Transcript

I think the number one rule is don't outsource your thinking.
Today's guest is Emily Shario, co-founder of Kilo Code, the agentic engineering platform recently acquired by Anaconda.
With Kilo, she helps engineering teams on turning AI investment into real engineering output and measurable impact.
The human, the person is still the one prompting, they're still driving the results, they're still responsible for the architecture.
You cannot vibe code off, for example.
You cannot Vibe code billing.
And so we need to be intentional.
These days, everyone can churn out code pretty fast.
So you're saying that people have now the killing problem, right?
Shipping software is free now.
It is easier than ever to just ship at the speed of ideas.
So the question becomes, if you're shipping all this stuff, do you want all of this stuff in your product?
Because you don't want to end up with a Frankenstein product that has no coherency to it.
How do you see engineers' role now change because of the AI and agent development?
The human role has changed from generation to reviewer.
Thinking about an engineer, not as an IC anymore, but as an IC who's managing their own team of agents.
That tech lead role that we've seen engineers move into 5, 10 years in their career.
Now they have to jump into it faster, sooner, more efficiently.
Thinking about code review, one of the challenges is when AI produces a lot of things, especially if you work with multiple agents, there's a lot of cognitive...
load when you review the code.
We need to recognize that the volume of code that's being shipped is more than ever before.
And so we cannot change how code is generated without also changing how code is reviewed.
Even a year ago, users would say, I don't want people to know how much of a coding agent I'm using.
And it is crazy how much that has changed in the last year that people are totally comfortable with the bot doing everything.
Hey, quick pause.
My goal with TechLegional is simple.
Learn from the best in tech so we can all grow together.
If this resonates with you, hit subscribe.
to follow the channel is the biggest way for you to support the show and help us keep bringing great guests and insights to you.
Thanks for being here and let's get back to it.
Hello everyone.
Welcome back to another new episode of the Tech Digital Podcast.
Today I have with me, Emily Shario.
She's one of the co-founders of Kilo Code.
Maybe some of you have heard about Kilo Code.
And recently, it was probably a few days ago that Kilo Code was also just acquired by Anaconda.
So congrats for that.
And Emily, looking forward for this conversation.
Yes, thank you so much for having me.
I'm really happy to be here.
Right.
Emily, in the very beginning, maybe introduce a little bit more about Kilo Code because maybe some people have heard it, but I'm sure many people have heard about CodeCode, Codex and all that, but maybe some may have not tried Kilo Code.
So tell us a little bit more about Kilo Code.
Yeah, Kilo is an agentic engineering platform where we focus on being everywhere developers are.
So really...
leaning into the multi-platform, whether that's your VS Code extension, JetBrains extension, a CLI2E, a cloud agent on the mobile app on your phone, wherever you want to be, Slack, Discord.
But we also, what really differentiates us from those other tools that you mentioned is that we're model agnostic, which means that we support over 500 plus models from so many different labs in the Kilo gateway.
Or you can use Kilo with your own API key or with local models.
So you're not tying the software you're using to the lab that's creating the model.
Right.
Sounds very unique, right, in a sense that you support multi-model.
That's the first thing.
Because some people, I assume, if they want to use multi-model, they have to use multiple tools.
But this one is actually you support 500 plus models.
So how does it work?
How can someone...
you know, not being overwhelmed by the models that they are using.
Yeah, most people don't use 500 plus models, but I think what we really believe in is model freedom.
And so we work really hard to bring those models to users, whether that's via an AI gateway where we have a number of partners or building direct relationships with the model providers in the labs or inference partners.
And so...
We're not only working to make sure we have all the models available on Kilo, but making sure that they work well on Kilo.
One of the reasons those relationships with labs is so important is because that those relationships are what allows us really optimize the model to work well in the Kilo framework.
So one of the things that you mentioned is also about multi-platform.
I think this is quite unique, right?
Because these days people either have to use...
an extension something that is in the id or and they have to use a cli based terminal based kind of a user interface so how do you um think this kind of a multi-platform approach actually help developers much better yeah you know when we talk about developers and developer workflows so often we're talking about it like it's one swath of of samesies right and the reality is that developers especially when it comes to ai engineering especially when it comes to agenda coding are all over the place the stat from stack overflow is that like 50 of developers still don't use ai at work every day I met with a developer who's a platform architect at like a large investment group in the U.S.
And he told me that their AI budget per engineer is $13 a month, which means that on the first day of the month, you run one prompt and your budget is gone.
And they're still writing 99.9% of their code by hand.
Like this is 2023.
The AI that they want is tab autocomplete in their editor of choice.
For other developers, what they're looking for is how do they run 10 agents across eight repos all at the same time, not on their machine, but in the cloud, but within a sandbox environment.
Like there's so many different.
There's a spectrum.
And that's really important.
So with Kilo, you know, we are in VS Code.
We are in JetBrains with a native extension.
We are in the CLI, if you prefer that interface.
We've also got a cloud agent, which is when you're running Kilo in a sandbox environment on the web.
And then with our cloud agent, we're able to meet users in a lot of different places.
So through the Kilo mobile app, you can either communicate or kick off with a cloud agent, or you can connect to a remote agent.
So an agent that's running on your machine, but you're talking to it from your phone.
Similarly, we've got our code reviewer and our security reviewer, which are specified kinds of agents that run.
on the cloud infrastructure.
And then finally, we've got our Kilo bot or Kilo connect, which is in Discord, Slack, Teams, kind of all the places you are already working.
Now you can bring Kilo along as well.
Sounds really comprehensive.
I think it's so unique, right?
In the sense that you meet people where they are and they can use a variety of options to use it.
So I think...
Many people might have tried using all these CLI-based terminal.
In fact, it gets getting more popular.
I think one of the secret sauce of all these tools is actually they're talking about the agent harness, right?
How the things actually work and do this looping, making sure that they actually meet what the developers want in terms of answering their prompts.
So how does Kilo actually differ in terms of agent harness as well?
Maybe if there's any unique flavor that you guys provide compared to the others.
Yeah.
So one of the things that I think makes Kilo really special for individuals is that all of our code is either open source or source available.
So our Kilo code kind of surfaces, the CLI, the core, the VS Code and Jebrines extensions are all open source.
And then the...
The proprietary code is still source available, which means anyone can see it, can read it, can contribute to it.
But you just can't use it.
So I start there because this means that everything I'm going to say next, if you don't believe me, like go hook up an agent to the code base and double check, which is always exciting.
You know, what we do, I think other.
Other labs, especially if they're creating their own software, they're spending a lot of time making their models really strong in that software or making that software really a strong platform for their models.
With Kilo, we're focused on making the best model agnostic piece, but that doesn't mean we're completely indifferent to the models' performances themselves and the nuances related to that.
So we work with many of the labs to adjust.
prompts, system prompts specific to their models.
We've got a partnership where we can make things.
We've got a partnership with most of the labs where we get early access so we can make sure that tool calling is working correctly.
We can make any adjustments before models are available to users.
So we're really focused on providing not just a model agnostic experience.
but a model agnostic experience that's really strong in each of the platforms.
Nice.
So one thing that I would like to ask you as well, because you mentioned multimodal and model agnostic, right?
So probably some people are not used to this kind of, you know, doing switching of the models in practice day to day.
How do you envision engineers actually use this multimodal approach in their day to day life?
Yeah, great question.
I think of it a little bit like using spoons to eat soup.
Like most people do not care that much about the spoon that they're using.
Like as long as it doesn't have holes, right?
They just want to scoop.
And so any spoon, any size, shape, most people are like fine with it.
I think when it comes to models, we're going to see something similar over time.
Today, people have opinions because they're such different, drastically different quality in the different models.
But in, I don't know, the next couple of years, I think we're going to see models become a little bit more commodified where you're just going to want a model that can get the task done.
Kind of like you want that spoon for soup.
If it can pick it out of the bowl and put it in your mouth, that's plenty sufficient.
And the task that or the prompt that you give, if the model can execute on that, you're in great shape.
Right.
Yeah.
So I think currently, you know, model differs as well in terms of, you know, output in terms of, you know, again, the harness might be different, right?
So definitely people might have preference.
I personally also, I think I don't like switching too much for doing.
one task, right?
So it has like some cognitive load for me, like to know which kind of models.
But I think when we speak about agentic, you know, workflow, for example, if you want to automate, you know, code generation to the agent somehow and only review it when they get back, any kind of difference here?
Because I think some people might say that, okay, you use one model for planning, you use one model for architecture, one model for writing the code, and so on and so forth.
Any kind of things that you pick up.
from how people use kilo.
Yeah.
So we have.
I think there's two things I'll highlight.
The first is that we have a Kilo.ai slash leaderboard.
That's our leaderboard where you can see how people use different models in Kilo.
Not just what models are popular and what are the most bang for your buck, which is true across all tasks, but also breaking it down by specific kinds of tasks like planning versus coding versus debugging, where you're going to be in very different workflows.
And so I could tell you by the time this comes out, that data might totally be outdated.
because the models are changing so quickly.
But I'll just point you to a leaderboard where you're going to get live up-to-date information on how people are using different models in Kilo.
The other is that we have a suite of what we call auto models in Kilo where we can handle the routing for you based on your cost profile and how much you're willing to spend.
So we've got auto balance, which is like focused on a best thing for your bucks series of model.
Auto Free, which is only using free inference, and then Auto Frontier, which is the state-of-the-art models in Kilo, where you can just select Auto Frontier and we will route it to the right task for you.
We also do something similar with a model called Auto Efficient, but it's to the next level where a prompt comes in.
What we do is we categorize that prompt based on a type and a subtype using a small classifier model.
And then we compare that type and subtype identification to our own internal data and benchmarking so that we can route it to the right model for the task.
So that's a little bit more advanced.
And that's truly focused on giving you the best bang for your buck.
Focus on accuracy, but the most cost-efficient version of that.
accuracy.
Again, something very nice so that you can actually meet people based on their use case, right?
Yeah.
They can go to the store and say, hey, I just want a spoon and we can help them get the right one.
Nice.
So, yeah.
One thing that we know recently is that you guys got acquired by Anaconda.
Congrats.
Yes, we just announced this last week.
Yeah.
So how does it change now that Kilo code is part of Anaconda?
I think this is one of those acquisitions where I'm so excited because one plus one is going to equal three.
We get to bring the powerful coding agent that Kilo users know and love to the fast growing over 50 million Anaconda ecosystem where.
I forget the exact number, but it's like over the 90% of the Fortune 500 uses Anaconda.
So being able to bring the magic of Kilo to them in a time where companies are already starting to think about token efficiency is really powerful for us.
We also get the opportunity to see continued investment from Anaconda in Kilo and the coding agent.
So I really am excited about how we'll be able to bring all the power of Kilo's coding agent with the secure managed packages and environments that Anaconda users know and love.
And I think this is going to be a really exciting opportunity for both teams to do more together.
Yeah.
You mentioned about, you know, token efficiency and people also talk about costs these days.
I think the trend.
It seems like the cost keeps increasing and it might get increased even more.
So what do you feel about this?
Is it something that developers should be concerned, starting to get concerned with?
Yeah, I think spend is a number that if you look at it in isolation, it's only going to go in one direction.
Kind of like compute, right?
I don't think there's any company that's really seen their compute bills go down since the era of AWS.
So I think looking at spend in isolation is a problem because spend doesn't mean anything.
It's not just about the spend that you care about.
It's the spend in the context of what it did for your org.
If you could spend $100 to make $500, if you can get that ROI, great.
No CFO is going to complain about it.
But if you're spending $100 to make $98, then we have a problem.
So a metric that I...
I don't think we've circled around as an industry quite yet, but I do think we're going to see people push more and more is going to be spend per merged pull request.
And let me tell you why.
Broadly speaking, merged pull requests is the closest thing that engineering teams can come to to measuring customer value in the short term.
Right.
It's there's a lot of better.
metrics and really it's like dollars and cents but for companies that have long sales cycles that's a way off so merged full request is probably the best metric for customer value shipped by an engineering or product and engineering org and so if you can take that ai spend from that org and divide it by the merged pr count what you get is an average cost per merged pr i think this is the metric that matters If it's costing you $100 to create new customer value, that's a really different conversation from it costing you $20 to create more customer value.
On the other side of that, as we think about customer value, like that is also part of what we want to see go up.
So merged PRs should be increasing over time.
And as AI spend continues to increase, if we're also seeing the volume of customer value being created.
I don't think that's a bad thing.
Right.
But one challenge definitely is about the size of the merge request or the pull request, right?
Because some people can give you tons of, you know, code changes in one go.
Some might do little code change.
Yeah.
How do you tackle all these such?
Yeah, it's not, it's certainly not a perfect metric.
I think an organization needs to standardize for themselves on what...
your pull request size looks like.
For companies that are already using Dora metrics, though, this is probably the next iteration that helps capture customer value, tying into AI spend.
Right.
Speaking about delivering customer value, right?
So I think people want to use AI to deliver a lot more customer value.
But at the same time, I think people also think about consideration like security, you know, governance, making sure that the AI doesn't come up with the bad feature.
So how do you see this speed versus control kind of thing?
Do you actually care about it when you build kilocode such that people don't go off the rails?
Yeah, definitely.
I think the number one rule, and if people only take this from the conversation, let it be this, is don't outsource your thinking.
So the human, the person is still the one prompting.
They're still driving the results.
They're still responsible for the architecture.
They need to be thinking about the security implications, right?
You should not, you cannot vibe code off, for example.
You cannot vibe code billing.
You cannot vibe code security.
And so we need to be intentional.
And I think having really strong engineers who understand where human judgment still needs to be crucial is key.
A little bit of that is also a learning curve and understanding that.
some mistakes might happen along the way and giving people a little bit of room to experiment.
So that mistakes happen in safer areas than others.
Right.
Yeah.
Don't outsource your thinking.
Definitely.
It's a very good reminder for everyone.
Maybe once in a while.
Yes, but not for everything.
Right.
Time and place.
Yeah.
Yeah.
Sounds good as well.
So.
One other thing that you say you want to talk about in this conversation is that you want to talk about how AI native organizations or organizations that have used AI in multi-facets of their organizations, how they run companies differently.
And you even mentioned that we should not look at AI just for, I don't know, like code, software engineering, but also as the operation infrastructure.
So tell us more about this aspect.
Yeah, I want to tell you specifically about Arcadi on our marketing team at Kilo.
There are all these people posting on the internet about how they are using AI to source leads and things like that.
And I don't know how much of that is true.
But what I know is true is that Arcadi is using the Kilo coding agent to run our ads.
like our ads that we're running on Google and other platforms.
And it's because the work that he's doing is very similar to the work that an engineer would do.
You're prompting an agent, you're getting feedback, you're giving it corrections.
He's still doing the thinking, but the agent is now a partner for him.
And I think the future of work is one where every knowledge worker is working with.
a team of agents, not just engineers, not just marketers like Arkady, but everyone will have three or four tasks that they've delegated.
And over the course of the day, their interactions are going to be primarily with their agents as they move into what are the tasks that only a human can do.
A couple of months ago, I wrote a blog post that the human role has changed from generation to reviewer.
And we talk about this in engineering a lot, but I think this is true across the board.
You see people draft, for example, competitive analysis and then a human is doing the review of that analysis.
You see a human or an AI might draft the initial version of a cold email sequence and then the human is doing the review and the adjustments and the polishing and all the things that make it really unique and special.
I don't think we're in a place where we're going to outsource that but when you're working in an AI native company you have these people who all have this same mindset of how do I find more leverage in myself.
without outsourcing my thinking to an AI agent.
I think that piece of it is also really important because in a lot of companies where people are just being pushed to adopt AI, you also are hearing these horror stories of, you're hearing these horror stories around how people are getting AI slop generated back and forth, how docs are longer than ever, PRDs are longer than ever, confluence or wikis are full of slop, and people don't know what, and anyone's written, let alone read.
So I think we're going to find that sweet spot over the next couple of years for sure.
Right.
And speaking about AI native organizations, right, how much portion of things that are run by agents versus human, right?
Because I would imagine many people talk about this as well, right?
We have agents for everything.
They run maybe in the background.
You just submit tasks to them and they'll come back, you review it.
And I think it seems like the speed might be.
exponentially different compared to traditional organizations?
Like, how do you actually see AI native organizations run, you know, day-to-day workflows and things like that?
Yeah, I'll give you a really specific example that I hear across the board is like, when people are going to log off for the day, whereas I think in 2022, people are saying, hey, I'm wrapping up for the day.
closing out their work.
They're putting a bow on it.
They're, you know, making sure they've answered that last message so they can wrap up.
Today, what I hear from my team members is actually I'm using this last half hour to kick off.
three or four different agents that can run on long running jobs overnight so that when I come back to my desk in my morning, I'm not kicking off new work.
I am reviewing some work that's already been started.
And oftentimes what that'll look like is you've got the work you've kicked off from last night.
You will start off a new batch of agents and then you'll pick up that work as well.
You'll pick up reviewing that work from last night.
Right.
Sounds really like.
Futuristic maybe for some people.
Very, very.
And that is something we can talk about just briefly.
Something we talk about on the team all the time is that there is a whole spectrum of developers.
I know we talked about this earlier, but even within the team where everyone is pushing the boundaries, we hear people talk about how this week they're running five agents in parallel.
And then next week they're working on something that's a different level of intensity or they've come down with a cold and so their focus is off and they're running with like a different volume.
And so I think not only are we figuring out what this future of work looks like, we need to recognize that it takes a different kind of energy from people.
it's okay if we're seeing some variation right now.
Which is why I focus on when it comes to metrics, at least, averages, knowing that there's going to be some variation.
Everyone has a good week.
Everyone has a bad week.
Right.
Apart from running things, you know, with agents, any other, you know, AI features that is being used?
Some that I might have heard is like...
you know, like skills, you know, creating skills library within the organizations.
Also, how about cross-functional things that happen between other departments, right?
So, yeah.
I almost take that sort of stuff for granted because we've just operated that way at Kilo for so long.
So we have, Kilo, the product itself has an MCP marketplace as well as a skills marketplace and some additional tooling there that people are welcome to use.
And that's going to make...
things available in Kilo.
So to anyone in Kilo.
Within the team, you know, we've got multiple skills files that people share.
We've got a specific repository just for that kind of leverage and not just on the engineering side, but throughout the org.
So I'll give you a really specific example.
I spend a lot of time posting on LinkedIn, but I was having a hard time taking the content, the written content I was writing and turning it into PDF carousels.
I wanted it to be better, more beautiful, but also wanted it to be easy.
And there's lots of tools out there, but I just didn't have the time to sit there and decide six graphics.
Excuse me, that can take any blog post and turn it into a PDF carousel in the Kilo branding in the right font.
It writes like the HTML in a viewer and then it prints that to a PDF and it works every time.
And because of how I set it up, I can even like tweak the copy before I get those final PDFs.
So it's a really powerful tool.
I'm not a marketer.
marketing is not my day job, but of course that's the kind of thing that I'm sharing, not just with a marketing team, but with anyone at Kilo who wants to leverage it.
Yeah, so definitely I think it's a great thing that you mentioned about the example you publishing your post, right?
I mean, it will get exciting if you work in these AI native organizations, let's say if you have plenty of skills published by other people who have the experience and the expertise, and you can leverage on that, right?
So that everyone can use the same kind of like standard, the same kind of like expertise to generate the same kind of output as well.
So I think this definitely changed the profile of high-performing organizations.
Like one thing for sure, like if organizations can already leverage this, it's like more high-performing.
But how do you see high-performing organizations later on will differ versus each other?
Because I'm sure everyone will start to leverage AI a lot more.
And like what's the secret sauce here now?
I think a failure mode that I'm definitely seeing is companies taking their existing process and saying, how do we tack AI onto this?
And that's not going to be really effective for the org, for the people involved.
I mean, you see this in lots of SaaS apps where they're like, so let's add a chat interface.
Like that's the way everyone's just tacking AI on.
I don't think that's the right model.
I don't know what it means to have an AI native org if it's like a 20-year-old company, though.
And I don't think we're seeing that yet.
It's definitely a mindset.
It's definitely a peer more than it's in the specifics of the tooling.
And so it's not about a subscription to Kilo or some other coding harness, but it's about looking for ways to find leverage in your work.
People we're seeing who are these early adopters of AI tools who are making the biggest differences at their organizations.
They are also the people who were pushing the limits of finding efficiencies before AI.
And so the mindset was always there.
Now they've got stronger, better tools that can make them even more powerful.
Yep.
I mean, speaking about efficiency, one thing that also you want to discuss is about, you know, because these days everyone can churn out, you know, code pretty fast, which here assumes like more features to be built, right?
So you are saying that people have now the killing problem, right?
So tell us a little bit more about this problem.
What do you mean by killing problem?
Shipping software is free now.
It used to be that software development was a funnel.
where you had product managers who were filtering out ideas and then there were specs written and then software that was actually getting shipped was the very bottom of the funnel.
So you never had people work on things that you didn't think were going to drive notable impact.
And now that funnel looks a little bit more like this, which means it is easier than ever to just ship at the speed of ideas.
It's a little bit of a hyperbole, but not really.
You can ship more than ever before.
And with a strong engineer and a really great prompt, it's absolutely mind-blowing what can be done.
So the question becomes, if you're shipping all this stuff, do you want all of this stuff in your product?
And I think what we need to internalize is that now we are prototyping and building and pushing things out.
And then we're testing it in production.
Does it get users?
Does it see adoption?
Can people leverage it?
Are they interested in using it?
Rather than us having to do all this expensive discovery beforehand, I think discovery has moved to after the feature has gotten shipped.
What that means is that we have to be willing to say, hey, this did not stick.
Let's pull it out.
Because you don't want to end up with a Frankenstein product that has no coherency to it.
So it's going to take a lot of intentionality to work to identify exactly what it is that still belongs in the product.
It's just where that filtering mechanism is after the feature has landed.
which means we're going to push things out.
We're going to let users use it.
We're going to collect feedback.
We're going to use that feedback as a guide to decide whether we invest in them or we revert the change in the first place.
Wow, interesting change of kind of like way of delivering software, right?
Where you probably don't do discovery first because everything now kind of like cheap, right?
The way you want the features to be built, you can just trigger an AI agent and they will come up with something.
And you're saying like testing and production.
But I think also one important thing in all these life cycles is that you need to gather the metrics, right?
For some, probably this is not in their DNA yet, right?
When you deliver features, you want to measure how it is being used, how many people actually love it and things like that.
So how do you start thinking about changing this kind of mindset?
Because I think for some, this might be new.
Yeah, it is a key part of it, right?
When I think about how we're going to capture that feedback, it is...
qualitative feedback.
It's users saying, hey, I do or I don't like this thing.
And for us, that's coming mostly through Discord where our community is, but not exclusively.
But it also means that we're getting that quantitative feedback.
So, you know, a feature is not shipped unless it has metrics.
How many people are using it?
How many people are interacting with it?
What does adoption look like?
Not just like week one, but also are people going to use it?
day one and day two and day three and day seven and day nine?
Or are they going to give it a spin once and then never again?
Because the way you build, you have to understand how your users are using product in order to decide what's going to stay and what's going to go.
And it used to be that you did that through the...
this user research and and these big conversations and lots of discovery and i just i think we're still doing that we're just doing it at a different place in the cycle where we have different kinds of input right so i like that you mentioned right the metrics has to be there before the features gets you know maybe it's shipped right so how does the the role of the product manager also change because I think they play probably a much bigger role in, you know, deciding what features to be built.
I mean, kind of like traditionally, like in the future, do you see product manager also still kind of like hold this role or, you know, or engineers actually also has to evolve in taking some of this ownership as well?
Yeah, all of Bebop.
Product managers, which is I think a good place to start, are going to assume at a level.
The thing that product managers are going to be really key for, and this is true especially in developer tools when you're building for a technical audience, is that developers, engineers have really good judgment at building for themselves in a world where you're building in developer tools.
You are your own customer first and foremost.
And so that can, a lot of the product management that has always been done by traditional PMs can now move on to developers.
What has changed is that product managers now need to help connect what is useful to what generates revenue.
And that judgment still belongs with product managers.
What pricing looks like, what gets shipped where, what features you prioritize because they are going to unlock revenue, not just because they're focused on developers.
And developer, especially in developer tooling, I think...
Different pricing models generate different approaches.
What we've done at Kilo is follow a buyer-based open core model, which means that our free users, individual developers, don't pay a subscription fee to Kilo.
Using the software is free.
You just pay for the consumption that you drive.
So we charge for cloud infrastructure and inference costs.
So what you use is what you pay for, not for software.
The people that are paying for software are teams and enterprises who are getting SaaS features that they need, like management, authentication, billing, invoicing, audit logging, all of those features that a business cares about.
I think in that framework, it's even more important that the product manager is there to serve that revenue use case.
Because we're not selling to developers.
And so developers aren't the great guide on who, what they would be willing to pay for.
So, yeah.
Yeah.
Speaking about, you know, this number of features shipped and all that, right.
So I think one common example that people also posted over the internet is about, you know, the speed, how Anthropic actually delivers features, right.
So I think even some people post like a graphic showing a timeline, you know, how many features they ship within, I don't know, X months, right.
So definitely shipping the features seems really, really fast.
But also if you look qualitatively in some other people's feedback, right?
The quality might not be there for some, right?
Or there's long requests that people have asked for, but they also don't actually build that.
How do you see this balance, right?
Because we can certainly easily go into this trap, like delivering more features because it seems useful, it seems cool.
But at the same time, also some of the quality not so great.
You know, some people also want something different.
And how do you actually, you know, decide to actually kill some of the features that actually don't get used, right?
Because I think this lifecycle gets very shortened really, really fast.
And I think some people might get confused how to actually tackle this speed.
I can't speak for other organizations.
I know that at Kilo, we're really focused on...
How users can have speed and quality.
You know, in the past, when you think about the quality shortcut that came with speed, it's not necessarily a quality shortcut, but it's a, we're not going to handle those scenarios.
Right?
When you were shipping a feature and you're thinking about all of the edge cases, one through 10, you're like, we're going to handle scenarios one through eight, but we're not going to handle nine and 10.
And I think that is a super reasonable approach if you're focused on serving just users one through eight.
You have to be willing to say that nine and ten scenario is one that we're not willing to serve.
That's going to be the thing that we're honest about.
I think where people get frustrated is that they communicate or they hear from companies or products, hey, we're serving one through ten.
And then user nine comes in and they try to do the thing and it doesn't work for them.
So it's important to kind of be really clear on what portions are and aren't about serving your user base.
I think it's actually more honest to focus on serving a few things really, really well than doing too many things.
Not that great.
Yeah.
And I think also from my user experience as well, right?
Sometimes.
Too many changes in such a short time actually confuse me as a user.
Because what do you mean?
Like a few days ago, maybe this works this way, but now it seems to be different.
How do you actually now educate users that this is probably something that is more expected?
Yeah.
Yeah.
I mean, we have this problem a lot with our docs too, where we ship so fast, it's hard to keep our docs up to date.
Even if you have an AI agent working on this, just like a chronic problem.
And so I don't proclaim to have all the answers.
I think what we are trying to do at Kilo is get really crisp on who we do and don't serve.
And this is something we've been doing with the Anaconda team as well.
It's like we serve the builder.
This is someone who is building things.
They're making things.
Whether it's a computationally intensive program like a data scientist or a developer who's working in VS Code to ship a SaaS app, being really clear and crisp on who that user is and what their use cases are can help you make sure that when you're cutting scope, you're cutting that extra scope.
And I think this is where speed really matters.
The alternative is something that isn't shipped at all.
If the alternative is that a feature isn't shipped at all, that's worse for all 10 of those person mess.
Yeah, so definitely we all want to deliver more things faster, right?
But sometimes there needs to be a balance, right?
Maybe in terms of from your team, also from the organization's perspective.
And also don't forget about the users, right?
So I think what you mentioned about be really clear on, you know, the users who you focus on and not to focus on.
I think that's super important.
in this era as well.
So speaking about, you know, building things, right, writing code and things like that, I think one of the realization that many people have is that engineers' role is now kind of like evolve, right?
So no longer that you see them as, you know, the code producer, but they are moving into a higher level, maybe like a reviewer or some call it system architect and all that.
Like, how do you see these engineers' role now change because of the AI and agentic development?
When I think about what engineers have most adapted to AI well, it's these really senior engineers who, what role were they playing pre-AI?
They were reviewing everyone's code.
They were meeting with team members, architecting big features, and then handing off the work.
People were coming to them with questions.
They were pointing or kind of guiding the answer, but they weren't necessarily writing all of the code across the org.
But they still kind of had their own projects.
Why is that feature set so valuable?
Because that's the same things they're doing with AI agents.
They have internalized how to work with AI agents because they have always been working with...
team members that way with more junior team members.
And so I think the opportunity comes from thinking about an engineer, not as an IC anymore, but as an IC who's managing their own team of agents.
And when you come to it from that mindset, you can help coach them into that tech lead opportunity, that tech lead role that we've seen engineers move into, you know.
five, ten years in their career.
Now they have to jump into it faster, sooner, more efficiently.
But they are definitely, to the point we were talking about earlier, we've gone from producers to reviewers.
Right.
So yeah, I think this is probably something that, you know, especially for those engineers who just came into the industry, right?
Probably it's a bit of a challenge.
What do you, what message do you want to give to these?
you know, new people, juniors who, you know, not necessarily having some ideas how software development was done before and now they have to go to the industry with, you know, AI speed, AI native kind of way of building software.
That is a great question.
I don't know is the honest answer.
I think hold your head up high, keep experimenting and keep shooting your shot.
The average engineer at Kilo has 10 years of experience.
The average engineer at Kilo has 15 years of professional experience with the least experienced engineer having 10 years.
So we're a very senior team and I think that's part of the reason this has worked really well.
We didn't have to teach anyone how to work.
But when I think about moving into a world where we're hiring, say, college grads or people earlier in their career, I know that we'd have to be more intentional about bringing them along and coaching them how to use these tools.
But I don't think it's that different from bringing an IC engineer who is AI resistant or doesn't understand the value and bringing them along as well.
Right.
Yeah.
So I still don't know how to actually give a good advice for these juniors.
It's so hard.
Yeah.
And especially I think some organizations also kind of like, you know, I don't know, like focus on hiring seniors or they stop hiring more juniors simply because they think, you know, seniors can.
work with AI much better.
So I don't know about all this, but I guess I think the key message is like, you know, adapt and try to also adopt these AI, you know, engineering practices, right?
So speaking about code review, I think one of the challenges is when AI produces a lot of things, especially if you work with multiple agents, you know, spawning multiple agents and the agents come back to you.
It's like there's a lot of cognitive load that, you know, engineers now have to bear in terms of responsibility to review the code.
Some may actually give up and just accept whatever AI agents suggest to them.
So what problems do you see with this kind of behavior?
Like is code review something that we all still need to do for all changes?
Or is there any better way of doing it?
Yeah, I was on a panel last week with the head of product at Replit.
And he shared that they have a category of pull requests.
that if they don't touch things like off or billing or any of these sensitive areas, an agent reviews it.
And if the agent recommends it gets merged, it gets auto-merged.
There isn't even like a second person who reviews it, which is wild to me.
This is not advice and I'd encourage teams to understand their compliance obligations before making any changes to their review process.
But broadly speaking, I think The important, we need to recognize that the volume of code that's being shipped is more than ever before.
And so we cannot change how code is generated without also changing how code is reviewed.
So at Kilo, we use Kilo Code Reviewer as the first pass reviewer.
We also have a local code review agent that team members will often leverage.
We recommend you use a different model for code generation than you do code review so that you're getting multiple perspectives.
Our code reviewer has different focus areas you can give it so that it can focus on security or SQL injection and risk or whatever you guide it to.
And then for really high risk problems, you can also roll out a council of reviewers.
So having many different agents review it, they all come together and kind of make recommendations on what areas need to be changed.
So this is like having a code review, but with many agents at the same time.
And it's really a powerful option.
Your organization's risk tolerance appetite for new tooling needs to drive this decision.
What are your customer obligations?
What are your compliance obligations?
What is your organization's tolerance?
What does your history of shipping look like?
What does your uptime look like?
These are all, I think, important considerations as a company lays out their policy.
But I think that the most important thing is the recognition and alignment.
that we cannot change code generation without also changing code review.
Yeah.
So I think that's a very good tips, right?
And especially, you know, when you have so many lines of code being produced, I think definitely it's worth to think about how do you want to review all this such that it doesn't become a liability when, you know, things go bad, you know, like especially when it affects users, you know, compliance and all that.
I think one other challenge that, you know, I also discussed this with another guest in the past is that this thing called cognitive debt, right?
So it's so many things get done in such a short time.
Probably our attention span is also kind of like short.
And we tend to also forget, you know, what has been done.
So maybe even like if AI agents sneak in one line of code, we don't know actually how it comes there in the first place.
So how do you tackle this within your organization?
Like, do you?
Also think about improving documentations or, you know, capturing important stuff as part of the PRDs.
So how do you actually tackle this problem?
There's a lot of things that we're doing, and I think the most important one is experimenting.
So, for example, we were, for a while there, we were including all of the specs for our project in the code as well.
And that worked for a while.
And then the models started to...
pull in the files in weird ways.
And so we stopped doing that.
We have certain workflows where skills are included and certain models get prompted to pull the skill in.
And then that might work for a little bit and then it doesn't.
And so the really important thing is like this willingness to experiment and try and see what's working and recognize that just because it worked, you know, six months ago doesn't mean it's going to work today.
That MCP server that was awesome is now getting really expensive because it's eating all the contacts.
Whatever it might be, I think it's really just coming down to experimenting, seeing what's making workflows better, and then continuing to push on that.
That being said, the other thing that we are trying to work better at is making it really clear when lines of code are changed by a human versus by an agent.
And for a long time, if you had an agent running on your machine, that meant that code was committed by you.
And if that's the case, that's great.
But that means you're responsible for it.
And if you're putting up the PR, you're the author on it, you're responsible for it anyway.
But it can also be helpful to know, yeah, lines one through four were me, but lines five through 876, that was actually the agent that wrote that.
Yeah, I think it will be exciting, you know, seeing things like this, right?
Because I think, yeah, knowing where the code comes from is still going to be a big challenge, right?
Especially if you're new to all this new workflow.
So yeah, very, very...
Yeah, I mean, building on top of that, one thing that I find is that even a year ago, users would say, I don't want people to know how much of a coding agent I'm using.
So I don't want the commits to come from the bot.
I want them to come from me.
And it is crazy how much that has changed in the last year that people are totally comfortable with the bot doing everything and it being very clear that their job is just to prompt the Kilo agent.
And I think that's just an incredible shift where people are really buying into the future of what the next stage of work is going to look like.
Yeah.
I think we don't hide anymore.
Everyone uses AI these days.
So I think that's a key thing.
And I like what you mentioned, like experimenting, right?
Because with so fast pace of changes that is happening and also in terms of AI model also change fast.
It's just given that we have to experiment and change a lot if things change, right?
So I think this is probably a new way of working as well that people have to really think about how do you actually adopt things fast.
change it when things work not the same way as you expect it to be.
So definitely very true that we have to experiment.
So I think we have discussed a lot.
Is there anything else that maybe you want to touch on about Kilo, maybe about new way of AI native organizations work?
Yeah, before we wrap up to the last question.
I think the last thing that I'll share is that I don't believe that AI is just for work.
We've talked about it a lot in the context of coding agents and Kelo and customers and work, but I also think one of the areas that I have found the most impact in AI is at home.
So being able to leverage AI to make running my household smoother, managing information around my kids, coordination with my husband, being able to delegate to an AI agent at home the same way I have work has really unlocked a new level of productivity, but it's...
It's like a freedom.
It's less time that I have to spend on tedious household stuff and more time that I get to spend actually enjoying my family and time off.
I think that's not an understated accomplishment.
The other thing that's really nice about using AI in this context is that there's no security guardrails, right?
You don't have to go through the IT team to get access to some tool.
And so if you want to experiment, I think being at home is a great place or applying these AI tools to some workflow in your household is a great place.
It's a great way to experiment with cutting edge tooling.
Yeah, I think that's a very interesting thing, right?
I personally have been using AI a lot more for health stuff, right?
There's this new thing about AI coach released by Google, right?
been playing around with it.
I think it's kind of like useful as well.
And especially if you have all the metrics, all the data available that they can leverage on.
Yeah.
So I think these kind of things also, it's worth to experiment, you know, outside of work to improve your personal life.
So thanks for mentioning that.
So Emily, I think it's been a great conversation.
We learned a lot from you.
And also for people who haven't really checked out Killer Code, please do give it a try.
Right.
So before we wrap up, actually, I have one last question.
I call this the three technical leadership wisdom I ask to all my guests, which is kind of like an advice you want to give to the listeners.
Maybe if you can share your version today, that would be great.
Yeah, the first, and this is not mine, but I can't tell you where I heard it, was if you're going to be a bear, be a grizzly.
So if you're going to do something, do it all the way.
Go aggressive.
Be ambitious.
Don't settle for anything other than the biggest, scariest, biggest bear there is.
So if you're going to be a bear, be a grizzly.
The second is don't hesitate to ask for help.
I think all people struggle, whether that's professionally, personally, you've got an issue at work, find your community, find the people you feel comfortable going to, build your network and the group of people where you can where you can turn to for questions, community, camaraderie, both professionally and personally.
And then finally, number three, last but certainly not least, is that it is really something to applaud when someone changes their mind.
Especially in startups, it's important that we optimize for speed.
So we're going to make decisions off imperfect information, but...
As time goes on, more information is going to be made available.
And we should be willing to reevaluate past decisions when there is new information.
And it's actually quite admirable when a leader is willing to say, hey, I was wrong.
We've got new information.
Here's what changed.
Let's change course.
And people are afraid to do that because their ego and they think that people are going to look.
poorly upon them.
I actually think it's quite admirable and a show of strength.
Right.
Really love that, right?
A plot when, you know, someone changes their mind.
Of course, if it's for good, right?
Not for the bad reason.
For sure.
So, Emily, if people would like to, you know, reach out to you, ask you more questions, is there a place where they can find you online?
Yes.
LinkedIn is the best place.
My name is Emily, E-M-I-L-I-E, Sherio, S-C-H-A-R-I-O.
Outside of LinkedIn, I have a newsletter, emily.substack.com, where I write playbooks and priority.
A newsletter on parenting, working, and working parenthood.
And users can, people can feel free to reach out to me.
My email is emily.co.ai.
Nice.
Put that in the show notes later on.
So thank you again so much for this conversation.
So very excited to see where Kilo Code goes after the acquisitions.
Hopefully, you know, you guys can achieve bigger things, you know, talking about Grizzly just now.
Thank you so much.
Thanks for having me.
And I really enjoyed this.