Emilie Schario is co-founder and head of product and engineering at Kilo Code, the open-source, model-agnostic coding agent platform that Anaconda acquired in July 2026. She was an early member of GitLab’s data team, ran the data org at Netlify, spent a year as data-strategist-in-residence at Amplify Partners, and founded Turbine, an ERP startup later acquired by Settle.
In her conversation with Tristan, Emilie describes “kilo speed,” the cultural discipline Kilo built around removing friction so people can ship, and the org design underneath it: about 20 engineers, one person with the word “product” in their title, and every engineer owning their own area end to end, from the roadmap to the bug reports. Her argument is that this only works because each of those engineers is also managing a fleet of AI agents, which is why she thinks the job has quietly changed from individual contributor to manager, whether you’re managing people or agents or both.
She also makes the case for Kilo’s model-agnostic bet: instead of building on one lab’s models, Kilo supports more than 500 of them and works with model labs directly, sometimes for weeks, before a new model ships. Tristan draws a parallel to dbt Labs’ own argument for open data infrastructure, though Emilie is careful to draw a distinction: for models, she says, the case for staying open is less about fear of lock-in and more about preserving the freedom to pick the right tool for the task while the frontier keeps moving.
They close on a question about what software engineers are doing today that data people haven’t caught up on yet. Emilie flips it: data people, she argues, have spent years being multi-threaded across marketing’s ask, the VP’s ask, and finance’s ask in a way software engineers were mostly protected from, which may leave analytics engineers better prepared than developers for a world where everyone is managing a portfolio of agents.
dbt Summit 2026 is almost here. Connect with the world’s largest gathering of dbt users, September 15-18 at The Cosmopolitan in Las Vegas. Level up your data and AI work: Register now with a 25% discount using the code dbt26-podcast.
If you’d like to watch the keynote and on-demand breakout sessions from your desk, register for online access.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Three ideas from the episode
1. Kilo speed is a deliberate cultural choice, not a byproduct of being an AI company. Emilie names the feeling directly: no red lights on the drive to work, no friction, no checklist that exists just to exist. Tristan pushes back on the idea that this is a natural outcome of being an early AI adopter, and Emilie agrees it isn’t. It’s a decision the team makes over and over, in how they handle a Slack channel or an email as much as in how they ship a feature. The org design that makes it real is unusual: about 20 engineers and exactly one person with “product” in their job title. Everyone else owns their own area completely, roadmap, bug reports, Discord support, and the escalations that come with it. Emilie’s explanation for why this works now and might not have ten years ago isn’t that engineers got smarter. It’s that each engineer is running a team of AI agents alongside their own work, which is why she says nobody at Kilo is really an individual contributor anymore. Everyone is a manager, whether they’re managing people, agents, or both, and the coordination overhead that used to require four or five separate roles collapses into one person with a wider mandate.
2. Being model-agnostic is a bet on optionality, not a fear of lock-in. Kilo works across more than 500 models rather than building on top of one lab’s stack, and Emilie describes an early-access relationship with most major labs: testing unreleased models for weeks, adjusting Kilo’s system prompt for each one, and feeding real usage feedback back to the lab before a model ever goes public. When Tristan draws the parallel to dbt Labs’ own argument that pipelines should be defined independently of compute, Emilie pushes back gently on the framing. For data compute, she notes, the fear is a specific one: nobody wants to relive an Oracle-style lock-in. For models, she says the concern is different. Nobody knows what the best model, or the best value for the dollar, will be three months out, so the point of staying open isn’t protection from a vendor, it’s the freedom to choose the right model for the task as the frontier moves. She illustrates this with Kilo’s Agent Manager, which lets her give the exact same prompt to several models at once, running in separate git worktrees so they don’t collide, purely to watch how differently they perform. She also points to a broader industry mood shift: earlier in the year the conversation inside Kilo was about token-maxing, pushing usage as high as possible. By the time of this recording, it had flipped to efficient AI spend and measuring real ROI, which she reads as validation of the model-agnostic thesis rather than a contradiction of it.
3. The junior-engineer problem is real and unsolved, which makes her closing argument about data people more surprising. Every engineer at Kilo has at least 10 years of professional experience, and the company is fully remote, a combination Emilie is candid about: she doesn’t know how to build early-career hires into a distributed, AI-native org, and she’s optimistic the industry will figure it out rather than confident that it already has. She points to programs like Ember Fellows, which grew out of the now-closed Venture for America and intentionally reintroduces an in-person component, as one open experiment. It’s against that backdrop that her answer to Tristan’s closing question lands as unexpected. Asked what data people haven’t caught up to yet relative to software engineers, she flips the question: data people, she argues, have spent years being multi-threaded across marketing’s dashboard request, the VP’s ask, and finance’s filter change in a way software engineers were largely protected from until agents started forcing the same context-switching on them. If managing many parallel agents is really a management problem, analytics engineers, who’ve effectively been “manager of one” their whole careers without a product manager or designer running interference, may be better prepared for it than the developers currently writing the tooling.
Key takeaways
Lightly edited for clarity.
Give us your bio.
Emilie Schario: I’ve done a lot of things over the years. My claim to fame, at least in the dbt community, is that I was person number 52 in the dbt Slack and was pretty early on the GitLab data engineering team. I held a number of roles at GitLab, went on to spend some time at Amplify, started my own company, raised a couple million dollars, and we were acquired by Settle. I left Settle and landed at Kilo, where I was co-founder and led product and engineering. Most recently, we just announced two weeks ago that Kilo was acquired by Anaconda, bringing all the best of agentic engineering into the Anaconda universe, which will be familiar to folks in the dbt universe who are also using Python.
What’s kilo speed, and how does it feel different to work inside an AI company?
Emilie Schario: We have this saying at Kilo, kilo speed, which is kind of like your drive to work when you don’t hit any red lights. Everything is working, it’s smooth, there’s no friction. Working in AI is working with people who are trying to create that environment: no painful processes that slow you down, no checklist for the sake of having a checklist. It’s about looking at what needs to be accomplished, assuming everyone in the room is an adult, and creating the perfect environment for people to move through it as quickly as possible, whether that’s a feature to a customer, an order form to an enterprise, or something for an auditor in compliance. The sooner we get something out there and into a user’s hands, the sooner we get feedback and can make it better.
Is kilo speed a natural outcome of being an AI company, or something you have to pursue on purpose?
Emilie Schario: We are actively working on it. When people hit friction, we have to decide we’re going to make it better. It’s not just the people we’ve got around the team, it’s that the people we’ve got are also actively choosing to pursue this all the time, whether that’s in their work, in a process they’ve identified, or in how they handle email or create a new Slack channel. Those are all outflows of our kilo values, and they’re what we’re hiring for. So there’s probably a bit of chicken and egg: we’ve got the right people who want to work this way.
Walk me through the product and engineering process. What does it actually look like day-to-day?
Emilie Schario: We’re an org of about 20 engineers, and there is only one person with the word “product” in their job title, handling a shared core infrastructure piece. Otherwise, every engineer is responsible for their own area. Someone on our cloud agents team decides day-to-day what the roadmap for cloud agents looks like, and he’s the one in Discord responding to user feedback. When tickets come in via support, they’re escalated to him. When there’s a bug report, he’s handling it. He really owns the whole product. Some companies call these product engineers. We just think of it as our default way of operating.
That’s normally four or five different people’s job.
Emilie Schario: At least, if not eight or ten. And it’s not just about having more people, it’s the additional communication and coordination that comes with more people. One engineer can do this and go faster than ever before, with a wider mandate, because he’s got a team of AI agents working for him and with him all the time. I think about the first eight years of my career, where at the end of every workday you wrapped everything up with a nice bow. Now, at the end of every workday you’re thinking about what you’ll kick off a set of agents to work on overnight. You start your day, kick off another set, and then review what the first set gave you back. You don’t have a bunch of ICs anymore. You have a bunch of managers, whether they’re managing individuals or agents.
Of your 20 engineers, does anyone have less than three years of experience? Is this the death of the junior software engineer?
Emilie Schario: The average engineer at Kilo has 15 years of professional experience. The least-experienced engineer has 10. We’re also a fully remote organization, and it is so hard to onboard new people that way. You worked with me at the earliest stage of my career, and I remember very clearly being taught by you what a window function was. I probably would have already known that if I’d had a weekly meeting with a bunch of more senior folks in person, but I was working remotely at the earliest stage of my career. There are invisible things about learning how to work that are so much harder remotely. Kilo is a globally distributed org, so we’ve really indexed for seniority. I don’t know what it looks like to have early-career hires in this world. I’m optimistic we’ll figure it out as an industry, because we can’t only hire seniors. We have to build juniors into seniors along the way.
Who’s going to take the first risk on early-career hiring in this environment?
Emilie Schario: I’m excited to see programs like Ember Fellows, which grew out of Venture for America after VFA shut down. They still have a city component, getting people in person, because a lot of people prefer to learn that way, or it’s just easier to get people started in person. There’s the hiring piece, how you give people the skills, and then there’s the remote piece, which makes it that much harder for us to hire early-career folks at Kilo specifically.
What did running the data team at Netlify teach you? What did you find challenging about it?
Emilie Schario: My biggest concern was always the “so what from here” for my career. As people who know me will tell you, I’ve got ambition coming out of my ears. Someone once told me, if you’re going to be a bear, be a grizzly, and I think about that all the time. I remember looking around and asking myself: so what do I want to do next, lead a bigger data org, lead more data people? What does that even mean? We were a very impactful team at Netlify. I had an incredible group of people who’ve gone on to do phenomenal work at dbt Labs, at Brooklyn Data Co., and at lots of other companies. I think I left data less because I stopped seeing it as my next career opportunity, and more because data had given me a bunch of skills I thought I could apply to other domains.
What was your mandate at Amplify Partners?
Emilie Schario: My role was, in a lot of ways, to be a consultant for the different companies in the portfolio. I built internal playbooks, hiring your first data person, building an early data stack, things their portfolio companies could reuse over and over. I also worked with founders in and outside the data space. At the time I worked with Hex on some of their new hires, adding a voice to the interview process. I was also the target persona for a lot of those data products, so I worked with Hightouch on their messaging and reacted to their early positioning. It wasn’t just data companies. I worked with Prisma as they set up their earliest data team. Almost all of my work was with companies already in the existing portfolio, occasionally talking to a founder before they were invested so they could learn how I like to work across a portfolio.
That’s the dream: analytics consulting without the sales.
Emilie Schario: I really enjoyed the role for a set amount of time, but builders like building. I realized at the end of it that I missed being part of a team, growing a company, watching the revenue, building product. I don’t think I understood how important those things were to me until I spent a year at Amplify and there weren’t new people joining Slack every Monday, or someone else to have a coffee chat with. It’s a very different job, focused on meeting people outside the org rather than inside it. I get a lot of joy from that in-house building experience.
What do you walk away with from your couple of years founding an ERP company?
Emilie Schario: It’s going to take an unfathomable amount of money. Try not to compete with NetSuite unless you have a gajillion dollars in the bank already. I think accounting overall is hard, though there’s interesting work happening: Tiger Beetle doing database work for transactions broadly, Fragment.dev on ledgers, Puzzle doing automated AI competing more directly with QuickBooks than with the more complex layer of accounting. There’s a hearts-and-minds battle that isn’t a technological one: how do you convince someone who’s been doing this for 10 or 15 years, in an old-school industry like supply chain or finance, that NetSuite isn’t the inevitability? I never cracked that code, even in my own mind. I talked to one brand that told me, yeah, we moved to NetSuite too early, but now we’ve hired four consultants and don’t see a path back to QuickBooks. Battle scars galore.
Benn Stancil has written about whether data people make good founders. Did your data experience help you step into the founder’s seat?
Emilie Schario: Absolutely. I always looked at data as problem solving: what’s the best indicator for customer health, let’s break that apart, what numbers do we have, what do we need, how do we get to the core of the problem, and what’s the best indicator we have that’s reproducible. That’s true all the way back to my college senior thesis, which asked what behaviors indicate whether a woman will vote regularly.
It’s about breaking a problem into its component parts to figure out what happens next, or what you can change or make better. As long as you see data as that kind of work, then yes. But I’d bucket that as “startup data people” broadly. If you think of data as someone filing a ticket to update the filters on a dashboard, and you just do it without knowing how they use the dashboard or what problem they’re solving, that’s a very different persona, and you’re just a number cruncher.
Understanding how much you care about the why is what predicts whether you’ll be a founder, more than any specific skill you have.
Tell us the Kilo founding story.
Emilie Schario: Kilo was originally founded by JP Posma, who was working on the Vesuvius Challenge with Nat Friedman and Sid Sijbrandij. JP had a family circumstance come up and had to step away. I was in Sid’s orbit at the time, having just left Settle. Sid asked me to step in as CEO temporarily and keep things running while we hired someone permanent. I wasn’t very interested in the role at that point. I’d just come off Settle, I had three very little kids, and my husband was transitioning things at his work. It wasn’t a fit for me at the time, but I said I’d step in for a short period and get things going.
Tell us about Sid.
Emilie Schario: Sid is still executive chairman at GitLab. He’s a general partner at Open Core Ventures, which has started 30 to 50 companies over the last couple of years, all around open source. He also has Even One Ventures, focused on the biosphere. Sid has had a very public cancer journey, and he’s in great shape now, but he’s shared a lot about what he’s doing there.
How did Scott Breitenother end up joining as CEO?
Emilie Schario: I told myself I was there temporarily, got the ball rolling, and started thinking about who the best CEOs I know might be to bring in permanently. I texted our good friend Scott: “Hey Scott, I’ve got a crazy idea, you want to hop on a call?” He said, “Yeah, how about in an hour,” and we hopped on a call. I made the introduction. There are lots of things I enjoy about Kilo, but my favorite has to be working with Scott day in and day out. We probably talk ten times a day. I talk to Scott more than anyone besides my husband at this point. He took over as CEO and really transitioned the business from a project to a business, leveling up from an open-source project with a couple of commercial features into an agentic engineering platform. He’s led the business and go-to-market side, and I’ve led product and engineering. Somewhere along the way, in my words, not his, he called me out on my nonsense, and we all realized this wasn’t temporary, so I committed to joining permanently. Two or three weeks ago we announced the Anaconda acquisition, so it’s been a kilo-speed run of a company too.
How does Kilo differ from something like Claude Code or Codex?
Emilie Schario: When you use Claude Code or Codex, you’re using software built by a lab that only has that lab’s models available in it. Anthropic makes Claude Code and gives you access to their own models, Opus, Sonnet, Haiku, and so on. If you want to use Anthropic’s models in the morning and OpenAI’s models in the afternoon, you have to switch software.
With Kilo, we think models change, but your workflow shouldn’t have to. You can use the Kilo platform with over 500 models, including the big labs but also a much broader list, like Minimax, GLM, Poolside, and Kimi. In terms of platform, we’re a VS Code extension, a JetBrains extension, a web interface, a CLI, a mobile app, and a browser extension. We try to be everywhere you are.
Did it seem sane that a small player could compete with the giants of the industry?
Emilie Schario: I was already very AI-pilled. I was a daily user of Cursor at that point. I’d had my third son in fall of 2024, and I’m not very good at maternity leave, so I made AI my project. I started experimenting with Bolt.new and Cursor, and by the time I came back I told my boss at the time, I’ve seen the future and it’s AI and we need every developer to change how they work. You can imagine how well that went over. I made it my mission over the next three or four months to push AI adoption, and it was incredible.
I also started automating things at home, the household calendar, the grocery list, paper cuts I’d previously just lived with, by outsourcing them to a script or an agent. So when Sid’s call came in, in September 2025, I said yes, I know the coding agent space, even though I was candidly less familiar with Kilo specifically, which was still early in its journey. In some ways the answer to “why not compete” is just, why couldn’t you? Sure, you’re outnumbered, but I remind myself we’re still so early in AI that the last three or four years won’t even be in the history books.
Can you talk about Kilo’s open source roots?
Emilie Schario: Kilo, in its earliest days, was a fork of a fork. There was a project called Cline, an open source coding agent. Roo forked Cline because Cline didn’t take community contributions, and Roo built a real community around that. Kilo was then a fork of Roo, focused on community contributions with a slightly different product vision. Those were the building blocks for a long time, but Kilo is no longer a fork of Roo. We use parts of the open code server under the hood, which has been true since February of this year.
At our core, though, the team and Sid’s own approach are focused on the mission that if you make things open, you make it better for you and for everyone who wants to leverage the product.
As someone who contributed to dbt before 1.0, all my contributions were features I wanted, not necessarily things on your roadmap, and I see that pattern in our own contributors. There are still plenty of open source or open-core coding agents: Cline is still alive, Roo sunset their coding agent in favor of a remote product, and there’s Pi, which ships inside OpenClaw, plus Open Code. I’m excited to see open source continue to grow here.
How does it work to build across so many models? Do you have something like a dbt adapter?
Emilie Schario: We do. We can adjust the system prompt based on the model itself, and we work with the labs before models come out so we can make those adjustments in advance. Not every lab, but with most of the major ones we have early-access programs and real relationships.
We’re often testing models for weeks before they’re generally available, both so we know it works well in Kilo on day one, and so we can make the adjustments that give it that level-up experience: how the system prompt needs to change, what additional tools or skills need to be available.
It’s not uncommon for our whole engineering org to spend a day running on some model with a funky code name, share feedback in a Slack channel, and have our head of partnerships take that back to the lab. That might be the final checkpoint before launch, or an intermediate one while they’re still tweaking.
So this isn’t a world where Kilo can independently build product, similar to how dbt can’t independently build product without a compute partner.
Emilie Schario: Interestingly, I like to joke that we have as many shared Slack channels with model providers as we do internal Slack channels. What a time to be building, that there are so many people building models right now that we can set up shared channels with all of them, so that when their models come out on day one, it’s a great experience in Kilo.
Does the open-model bet track with dbt Labs’ own argument for open data infrastructure, that you don’t want pipelines tied too tightly to compute?
Emilie Schario: The key difference, I think, is that with data and open infrastructure, the worry is about not wanting to get locked in by a vendor. With models, I don’t think people are as worried yet about vendor lock-in specifically. If you’ve got a big AWS commitment, bring your AWS key into Kilo and drain against that commitment, that’s fine. It’s more that I don’t know what the best model is going to be three months from now, or the best bang for your buck. Preserving that optionality is less about a specific vendor concern and more about the freedom to choose the right model for the task, especially as companies start thinking harder about AI ROI.
Earlier this year we were talking about token-maxing, getting everyone spending more. Now it’s shifted to efficient AI spend, which makes me even more convinced that the thing that matters is using the right model for the task, the one that can complete it successfully without overspending.
I like to use knives as an example: you’re not going to slice a crunchy sourdough with a tomato slicer, and you’re not going to slice a beautiful July tomato with a bread knife. You need the right tool for the task, and model selection is part of that. We have an auto-efficient model in Kilo that can route on your behalf.
What’s the Kilo business model?
Emilie Schario: If you’re an individual, you can create a Kilo account and use the software free forever. Teams and enterprise customers pay for software features, a set price per seat per month. When it comes to actually using models, you can bring your own key, an Anthropic key, an OpenRouter key, or another subscription, and use that in Kilo. You can pay as you go, putting in a set amount and draining it down. Or you can buy a Kilo Pass, a monthly credit subscription where you get some bonus credits built in.
What’s a great way to see how different models actually perform on the same task?
Emilie Schario: One of my favorite things when a new model launches is our Agent Manager, which lets you give the same prompt to multiple models at once. I have a vanilla prompt: create a snake game, use only vanilla JS, make it beautiful, I’m a 33-year-old woman, design it in a UI I’d like. I’ll give that exact prompt to several different models and see what comes back, how long each one takes. They run in different git worktrees so they’re not stepping on each other. It’s a great way to see how differently models actually perform, because the results are drastically different even from an identical prompt.
Do you experience imposter syndrome stepping into this space, and do you have advice for others going through it?
Emilie Schario: Every second of every day. I think that’s where being surrounded by the right people matters. I’ve been lucky to work for people, yourself included, who were willing to say “I don’t know,” and that set an example: the smartest person in the room doesn’t have to have all the answers.
I’ve had plenty of moments of imposter syndrome, but more than anything I’ve embraced my willingness to say I don’t know, make the best decision I can with the information I have, and be willing to change my mind. Having a team around me helps too, which is part of why I talk to Scott ten times a day, going to him, getting his thoughts, and vice versa. If you want to go fast, go alone, but at Kilo, between Scott, Sid, and me, we’ve found a way to go fast as part of a team.
What are the most useful things software engineers are doing today that data people haven’t caught up on yet?
Emilie Schario: Good question. I actually think it’s the reverse in one important way. Every data person I know is much more multi-threaded than software engineers have ever had to be. Data folks are toggling between an ask from marketing, an ask from the VP, and an ask from finance in a way software engineers have largely been protected from.
One of the big pain points I hear from software engineers right now is context-switching that feels overwhelming, because it’s not something they’ve had to do before. As data people move up the AI-engineering maturity curve, I’d expect them to jump into managing many parallel agents in a way a typical software developer has struggled with, because data people have already been doing something like it.
If we’re all becoming managers, that’s something data people are probably already comfortable with, because they haven’t had a product manager or a designer running interference. They’ve been out there figuring it out for themselves. Manager of one, already.
Chapters
Timestamps are keyed to speaker-turn changes in the recorded transcript, so a mark shows when a topic’s turn begins, not necessarily the exact word. Verify against the edited cut before publishing.
00:00 Welcome, and Emilie’s podded bio
01:25 From traditional infra companies into an AI company
02:05 What “kilo speed” means
03:37 Kilo speed as a deliberate choice, not a natural outcome
05:20 Could this have happened at GitLab or Netlify?
05:55 The product-engineer model: one PM, 20 engineers
08:03 “You don’t have a bunch of ICs anymore, you have managers”
08:28 Is this the death of the junior software engineer?
09:58 Remote work and the difficulty of onboarding early-career hires
10:52 Who takes the first risk on junior hiring?
12:01 Emilie’s path: Smile Direct Club, Doist, GitLab, Netlify
12:47 What running a data team at Netlify taught her
14:30 A year at Amplify Partners, across the portfolio
16:10 “The dream”: analytics consulting without the sales
17:28 Founding Turbine, and the lesson about NetSuite
19:33 Ben Stansel’s question: do data people make good founders?
22:34 The Kilo founding story: Sid’s call, and “temporary”
23:15 Sid Sijbrandij: GitLab, Open Core Ventures, Even One Ventures
24:36 Texting Scott Breitenother: “I’ve got a crazy idea”
26:44 From project to business, and the Anaconda acquisition
27:08 How Kilo differs from Claude Code or Codex
29:20 Was it sane to compete with the giants?
30:02 AI during maternity leave, and “I have seen the future”
31:32 Automating the household calendar and grocery list
34:16 “Why couldn’t you”: still early in AI
34:37 Kilo’s open source roots: Cline, Roo, and a fork of a fork
37:21 Three million users, and open source coding agents
38:11 Working with model labs before launch
40:11 Building product in partnership with the labs
41:04 The dbt parallel: open data infrastructure vs. open models
42:32 The Cursor and SpaceX acquisition, and the Grok data joke
44:53 What’s the Kilo business model?
47:02 The right model for the task, not the cheapest one
48:44 Agent Manager: the same prompt across multiple models
49:39 Imposter syndrome, and the value of saying “I don’t know”
52:09 What software engineers do that data people haven’t caught up on
53:11 The flip: data people as natural multi-threaded managers
54:21 Closing thoughts
Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.