Building the machine that builds the machine (Interview)

Welcome friends, I'm Jared and you are listening to the Change Log. Interviews with the hackers, the leaders, and the innovators of the software world. On this episode, Paul Dix joins us to discuss the influx DB co-founders journey adapting to an agentic world. Paul sent his AI coding agents on various real world side quests and shares all his findings, what's going to prod, what's not, and why he's at least for now. Hand coding once again.

But first, a big thank you to our partners at Fly.io, the platform for devs who just want to ship, build fast, run any code fearlessly at fly.io. Okay, Paul Dix and building the machine that builds the machine on the Change Log. Let's do it. Well friends, I don't know about you, but something bothers me about getting back actions. I love the fact that it's there.

I love the fact that it's so ubiquitous. I love the fact that agents that do my coding for me believe that my CI, CD workflow begins with drafting, tom will file for get back actions. That's great. It's all great. Until, yes, until your builds start moving like molasses.

Get back actions is slow. It's just the way it is. That's how it works. I'm sorry, but I'm not sorry because our friends at NameSpace, they fix that. Yes.

NameSpace is like get up actions but faster. I'm like way faster. It caches everything smartly. It caches your dependencies, your Docker layers, your build artifacts so your CI can run super fast. You get feedback loops, happy developers because we love our time and get fewer.

I'll be back after this coffee and my build finishes. So that's not cool. The best part is it's drop in. It works right alongside your existing get up actions with almost zero config. It's a one line change.

So you can speak your builds, you can like your team and you can finally stop pretending that build time is focus time. It's not. Learn more, go to namespace.so, that's namespace.so. Just like it sounds, they said, go there, check them out. We use them.

We love them. And you should too. Namespace.so. Well friends, we're here with Paul Dix, CTO, founder of InflexDB, longtime friend. I would say old hat wisdom, all the positive things I can say about your wisdom, Paul, but happy to have you back here on the pod.

It's exciting times we're in but also very uniquely positioned times. How are you personally feeling about things? How are you deploying things? I think the things I'm talking about is obviously agent coding, et cetera, et cetera. How you doing?

I'm good. Yeah. I'm really excited to talk about agent coding stuff. It's highs and lows really. On the daily, on the weekly, minute by minute.

Oh man, I would say for the past six months it was mostly highs on the weekly. But then occasional setbacks when I feel like I got a little over my skis and let the agents do run a little hog while without enough supervision and then I had to dial it back and fix things myself. So I'm in the middle of one of those dial it back situations right now. You're writing code. You're saying you're actually writing some code now.

I am writing code, as I said before, I'm writing code by hand like a peasant there in the coding fields. When you're doing that, I know it's enjoyable but do you feel like given that you've tasted the milk and honey over the horizon, do you feel like, man, I'm kind of wasting my time. I could be moving faster. What is your feeling when you hand code like the old way, if that's the case we're saying here? When I hand code anything at this point, I definitely feel like I'm slow.

This could be faster. And the biggest thing is obviously this has all changed within the past year. My experience was I started using chat TPT when 4 came out in March of 23 and started using these tools more for coding along the way with copilot and all these other things in ID completion. But I would say everything really, really changed last year with the release of Opus 4 in the late May and I started using Cloud Code around the same time. I know people at that point were using cursor and their Cloud Code was released in what like February or March or something like that.

But my experience of feeling like agent coding as an experience, which I think is qualitatively different than completion and IDE or anything like that happened in June of last year. And since then, I started using it internally and I used it essentially for two or three weeks. And at first, I was just like, is this real? I couldn't believe how much it could actually do. But I was still keeping it fairly constrained.

I would have a well-defined problem and I would say implement this function or write these tests or whatever. But basically after two or three weeks, I was just like, this is magic and within my company I need to start spreading the gospel. So I basically wrote this lengthy documents that I shared with my engineering team. And I basically said, all of you have to start using this. And at the time, you know, Enthropic didn't even offer any sort of enterprise licensing for Cloud Code.

If you wanted to use Cloud Code without paying for individual tokens, actually, I don't even know if you could use an API key at that point. We still had to pay for a personal subscription. I told all my engineers, I was like, go sign up for this on your personal credit card and expense it and we'll pay for it. And I was like, if you hit the limits upgrade because the experience is different, if you're worried about hitting token limits versus you don't care. Because if you don't care, you'll feel more free to experiment and do things and basically like it progressed from there.

And I have a couple of like project like hack projects that I did in the background that I can certainly talk about along the way. And the progression basically over the last six months, but basically by the end of last year, it seemed obvious to me that, you know, our days as developers of like handwriting code were extraordinarily limited. And then at that point, basically with the release of Opus 4.5 and GPT 5.2 codecs and probably HMI 3, but I didn't, I don't really use JMI that much. But codecs 5.2 and Opus 4.5 I have a lot of experience with. My feeling was, if you're an engineer and you're writing even like 10% of the code you write by hand, you're like wasting your time and you're wasting your company's time.

And so this is basically like, you know, the end of last year, the first week or two of this year, I just hit my absolute peak of like, this is amazing and goodbye coding forever. I'm now like a manager of agents, right? I'm manager of clock codes and codecs and I just need to figure out how to get all these things working to maximum effects, right? The first, the first like post I wrote about this was basically on like New Year's Eve, where I basically brought up Ambell's Law about like performance optimization where it's like, if you have this complex system and you optimize one component of it, the total amount of performance improvement that you see is going to be limited by the percentage of that component represents in terms of the overall thing.

And I, you know, compared that to the software delivery pipeline where code is only like one portion of it, right? And depending on who you are, you think it's either larger or smaller as a proportion of what it takes to actually like deliver a software product to customers and put it in production and all this other stuff. And basically my thought then and still now really is like code's easy now, code's cheap. Like you can produce so much code, like you can produce more code than you could ever have time to review or want to put into a product or get into production or support. So what do you have to do?

You have to optimize the other parts of software delivery, right? You have to optimize how you tested verify this stuff, how you gather requirements, how you have product teams get it and validate that has the user experience that you want, how your support teams actually support it. So the interesting thing, so in the initial, I'd say like June, July, August or June, July, I was basically still in the mode where I had, you know, clock code running and I have one session and I'm focused there. And basically what enabled me to do is do all the other kind of work that I have to do as like an executive and leader within my company, right? It's interesting because as a CTO of a fairly established company, like still obviously startup, but usually CTOs aren't actually writing code, but I have been for the past two years on this new version of the database.

I've been very in the weeds, but I still have leadership requirements, things I need to do, right? So I say in June, July, it's like, okay, I can keep these agents going and then do other stuff on the side while they're working. And then I got to the point where I'm like, okay, well, maybe I can actually run another agent at the same time and have, and pursue a side quest. And I thought like, man, agent, agent coding is basically the age of the side quest because you can just like, start it on something else and get it going and see what happens. And I had a number of side quests that I pursued over the last, I would say, like four months, five months.

And I probably turned out a few hundred thousand lines of code, which is just like insane, none of which is going to production. So you're not going to accomplish any of your side quests? Like, were they accomplished? Yeah, so that's, I mean, that's one of the problems I have right now is I can, I can be more specific about a couple of these side quests that I thought would be interesting. So the first one was, so Opus 4, one was out.

This is probably like the beginning of August. And I had the idea, so InflexiV is a time series database, right? That's the project I'm working on. And it's for like, you know, observational data, hopefully of any kind that has a timestamp. And we, in our version of the database, we have now, we support InflexQL, which is our query language that looks kind of like SQL, and we support SQL, actual standards compliance SQL.

And one of the things some of our customers have been asking is like, oh, can you support Prong QL, right? The query language. And of course, our answer has always been like, we would love to, but we don't have the resources to do that or anything like that. And the idea I had was, what if, what if the agents could, could do Prong QL, right? So our current version of the database is written in Rust.

And what's it be three is written in Rust, Prometheus and Prong QL is written in Go. And I knew from basically historical experience with the Prometheus project that Prometheus has a very extensive test suite for Prong QL that is outside of the, it's actually like, they have a whole DSL that's basically this text based thing where they can define data input, the query and the expected results. And they built all this tooling originally so that they could validate compatibility for various Prometheus backends, right? Prometheus being the canonical example, but then other things like Cortex and, you know, all the other cloud provider specific Prometheus backends, right?

They're probably at least a dozen or two dozen backends that support Prong QL as a query language. And you can use these tests. They, with this, it's actually in the Prometheus repo. So basically like there's a bunch of Go code as a test runner and there are all these tests. My thesis was, well, the agents do a lot better job if you give them verification signals that they can use.

So I thought, why not try to have the agent try to create a port of the Prometheus Prong QL implementation in Go over to Rust so that we can have just native Prong QL support in the Intlify Cb. That makes sense. Right. I was just like, okay, I had a rough idea of how I wanted to look. I said, first go look at the, you know, I checked out the Prometheus code base because it's all Apache two licensed open source.

I was like, go look at the Go code base, like create a document that summarizes that, specifically focused on the Prometheus query language, not on all the other parts. And focus on the test runner because I'm going to have you create a test runner in Rust that we can put into Intlify Cb, which I had separately. So I created that. And then I said, okay, here's how we're going to organize the code within the project. And I knew I didn't want it touching the existing database code base.

I wanted a couple of very light touch points where it could integrate. And I wanted all the net new code that it's creating to be basically like a new crate within the Rust project. And I gave it this guy and said, use the Go implementation as your gold standard, right? Two things you have to do. Like one, get to the point where you can run this test suite as soon as possible and make like the simplest test pass.

So do that, write the scaffolding and use the Go implementation as both the guide for how to do it. So the structure should be roughly the same, obviously taking language idioms into account and do that and then basically just like crank on that. And it cranks in the background on that. And that test suite, by the way, is like, it's like 1,100 tests. It's very, very extensive.

It covers all of the functionality of Prom QL. And I just had a crank on the background. And meanwhile, I have a lot of development work that is my primary development work. And then all the other founder, executive-y kind of stuff. And it got really, really far, but it couldn't quite finish it.

And then CodeX, GPD5, and CodeX came out. And at that point, Opus 4.1 is kind of like stuck and spinning its wheels. And again, this was all just vibe-coded stuff. I gave it the parameters, but I wasn't paying attention to the code it wrote because I was like, this is all just like a ridiculous kind of test. And then CodeX came out and I had to pick it up.

And it was able to take it the rest of the way. And basically what it created, it's like I said, a native Rust implementation of Prom QL that's inside the Inflectiby 3 codebase where, Inflectiby, you can set it up. And it will act like a Prometheus server in terms of the remote write API is there. And all the query APIs are there for getting labels and executing queries and stuff like that. And it got to the point where it passed the test week.

Now, the test week doesn't actually test the Prometheus HTTP API. It tests the underlying query engine to see if it passes those tests. So that point is like, OK, does it actually work? Because the robot says it works. So I spun up a Prom E3 server on my laptop and I spun up this Inflectiby server.

And I mirrored, I set up Prom E3 to do remote writes to the Inflectiby server. And I set up to scrape the node export, like basic system stats, CPU memory, you just call that stuff. And then I set up Grafana and I pointed a, you know, a system metrics dashboard, a Prometheus, I pointed it in FlexDB, I looked at the two and they were the same. It's like, wow, it actually created a completely compatible implementation of Prom QL. And it was, this was like 60,000 lines of code.

And I didn't write a single line of it, like not a one. And I didn't really, other than the, like I said, the overall structure, the project structure, I didn't really do anything else. And again, like it had the go implementation to go off of and it used that. And to me, that was just like a wild experience, right? I finished that in like, I'd say, or like mid September.

I was just like, this is crazy. And then of course, at that stage in mid September, I was very much in the codecs camp because I was using, I think it was like codecs 5.1 or 5 at that point. Right? And I kind of like freely interchanged between both Cloud Code and the codec CLI. I mean, I pay for both.

And you know, at that point, I thought it was pretty amazing. And by, I would say, it was funny, like the week before Gemini 3 came out. So basically the ordering was Gemini 3 came out, then Opus 4.5 came out, then like two days later, then GPT 5.2 came out, right? So basically the week, the weekend before Gemini 3 came out, I wrote this like lengthy, again, like lengthy document to share with my engineering team internally. I was like, hey, everybody, like we have got to figure out how to take advantage of these capabilities.

Like, and I would say one of the things we've seen internally within InflexDB is every product manager has gotten on these tools and they have just been insanely productive. Like, it started in the fall of 24 where I told one of our product managers, he wanted to do a UI thing and I was like, we do not abandon it for that. We can't assign engineers for that. I was like, if you really want to do it, go get template and see what you can do. And he created something that's pretty interesting.

And then we like brought in a separate team to like turn that into an actual UI product, which we now have. But that's how it started. And then once I started using Cloud Code, I told all of our product managers, I was like, okay, you have to source code, use Cloud Code because you don't have to have like wait to ask engineers questions anymore. And you don't have to wait to ask engineers to do tiny things. Like, you can just do it, right?

So I've been very much in the camp of like, I'm trying to push everybody to like, use these tools. And along the way, I would say there's definitely been some skepticism. But over the last six months, it's just been getting people get a bin adopting it like more and more, right? So basically the week before Gemini 3 came out, I wrote this, you know, internal post. Right?

So we've got to think about how we fix, you know, how we make it so that we can actually like, legitimately figure out how to get this code into production and to our customers, right? And then we can just, as quickly as we can think of them now. And basically at that stage, not everybody believed that, but I firmly believed it then and of course, I believe it now. But it's like the problem is we can't review that code quickly. Like there's no, like every engineer can now produce a hundred times more code than they could before, but nobody can take the time to review all that code.

I was like, so we have to start thinking about what we can do here. And it's not just like code review, right? It's, it's more like product experience supporting all of this stuff. And again, like I don't have the answers for this stuff right now. That's why I wrote that post like build the machine that builds the machine.

Yeah. Yeah. And then I was thinking now is like, that's still the case. And then, so I wrote this whole thing and I was saying like, okay, here's what's going to happen. Or in the next year, all the major AI labs are going to have at least like one or two more releases that are not raised the bar again.

And more of what you, what, more of what was impossible will be possible, right? Because that's the whole argument. It's like, oh yeah, it's okay for code completion, but nothing else. Oh yeah, it's okay to write a single function, but nothing else. Yeah, it's okay to maybe write a module, right?

The scope of what these things can do just keeps expanding and it's happening like very rapidly. So I said, wrote all this like freaking out about it. And of course, like three days later, Gemini three comes out and four days after that, Opus four, five comes out and two days after that, GPT five two comes out. And you know, I would say at this stage, like most or all of our engineers are firmly in the camp of using these tools, but we still don't know all of our process, all of our, they'll very much in the old style development process where, you know, we come up with requirements and we log issues and we do full requests and we have human reviewers, even with the reviewing tools, like we also have AI reviewers, but nobody trusts the AI reviewers as the only review, right?

So it's guaranteed that you have to get it on a human looking at it. So to me, like, I think, I think the verification loop is the biggest, the most important thing to do, right? Because ultimately, like you need to make sure that you get quality results. And like I said, I've recently had the experience where I let the AI get too far ahead of me on some stuff I was working on. And I realized as like, wait a second, I got to like completely go through and refactor a bunch of this code by hand myself and rewind a couple of weeks worth of stuff.

So yeah, I don't know. But verification loops, I think are super, super important. But really when like all this stuff was important before, it's funny, like all the things that are the best practices software engineering before, like, you know, single command to deploy, single command to run your test suite, having unit test integration tests, you know, all these, you know, signals and tooling you build out over time to have reliable, you know, software delivery, all that stuff is just became even more important because if you have all those things and you actually open them up to the agents, the agents can use those things to actually iterate on your behalf without waiting for you, right?

You can get them into a loop where they'll work for hours grinding away at something, right? Like if you have a performance optimization problem, for example, if you create a tool where you say you run this tool and these are the signals you look at and they tell you whether or not you have improved or gotten worse, and you give that to an agent and you just put it in a loop, it will just grind away at the problem until it either comes up with something good or it doesn't. So at the end of a few hours or a night or whatever, you can look at it, you can be like, okay, that's good. And then I would say the same is true for functionality. I mean, I will say all of my experience is based on backend software development.

So I don't have front end software development experience in this. I did actually over like the holiday period do a side quest where I had to do some front end stuff. And those are my first chance opportunity to use something like Playwright, MCP, to have clod go through and hit the browser and try and fix things and stuff like that. And again, it worked insanely well. I was shocked.

I had it porting a piece of UI code to try to make it native as a WasmApp inside the database. And I'm like, it did the whole thing. But I'm not going to shift any of this code is the thing. I have all the stuff where it's like I feel like I can get things, I can get a demoable prototype. I can get what looks like working software, but I don't know how to cross over the line to get it to something that we actually want to deliver.

You're not shipping your Prom QL thing? Not right now. What's it missing? I won't want to take to get it there. So with a Prom QL implementation, I think the two things that are most important are one compatibility, which actually I have a high degree of confidence in the compatibility piece because of the test suite that's in the Prom Prometheus code base.

But then the other thing is performance. So just in terms of the pure, what I think makes a good Prometheus implementation is those two things. Performance being how fast are the queries, but also performance in terms of what's the infrastructure footprint to handle a given workload. And that's more dependent on the core pieces of the database, which is actually our focus right now. But then the other question is, we talk about this internally as engineering leaders, and it's like, what engineer is going to support this?

You've got 60,000 lines of code that wasn't written by you or anybody else in the company is written by Claude, or Claude and Codex. You're an engineer who's armed with Claude and Codex, support it. On some level, that is my argument too. It's like, okay, well, you have the robot to help you out. But I will say, which I agree with, right?

There's literally no engineering problem I can think of right now, like software engineering problem I can think of right now, where I wouldn't as a first stop use an agent to talk through the problem, to do an investigation, to explain to me about the code, right? If it's a new code base, even if it's a code base, I know my first stop is going to be like fire for agents and start iterating, right? Yes. And start investigating, just because they do it, like it's just so much faster than doing yourself. Exactly.

Exactly. There's a lot of clarity and blind spots in there too, though. Like even if you know the code base very well, there's a lot of things that you may miss, and I don't want to say like as a human, literally as a human, that there's this clarity and blind spots thing that I tend to throw at my AI when I'm doing something. It's like, okay, I know we're solid on this. We've done all the investigation.

We've got the spec and where we got a plane in place. We've even got an implementation man, they've got code samples in place. We feel very confident in our next step, which is actually implementation. But let's pause into a clarity and blind spots examination. Like, where is that?

We don't know about this. What about how it touches that? What about second effects over here? It's like, okay, you're right. Wow, we have such clarity here, but we don't have full clarity because there's a lot of touch points you just forget that you even think about because you're kind of excited.

Yeah, it doesn't mean rush. You're just going, you know? Yeah. Well, so for example, there's a new set of capabilities we're working on right now, which we do intend to release. And there was, you know, there was like a core change that I had to make towards the end of last year.

It was based on a workload that we had seen that we weren't able to handle. And I was like, okay, I need to make this change and I use Cloud to make it. And I didn't actually then take the time to go through and like refactor a bunch of other spots on the code that kind of were impacted by the change. So we got a few more weeks down the line and then everything seemed to be fine. And then we started doing more extensive testing.

And basically there were like these weird failures that only occurred when we were like under load or under resource constraints or certain like timing issues. We didn't know what it was, right? And last week, you know, we had multiple engineers myself included, like trying to figure out what it was. And of course, all of us are like using agents to try and like help and investigate the problem. And I was like, last Thursday I was like, man, we're just like spinning our wheels here.

It's like everybody is in the AI casino pulling the levers on the AI slot machine, slot machine, hoping for manna from heaven to come down and give me money. And I was actually getting anywhere and I was like, okay, I'm just going to pull the plug all of this. And I'm just going to go back to basics and audit everything myself by hand like personally. And I think on reflection, I think this was due to a few different problems. But before I cover that, that experience tells me, well, like, if we are going to take 60,000 lines of vibed up code or it's not totally vibed up, right?

Because it's not like there was absolutely no supervision. It wasn't like build me an app and I have no idea what's underneath the thing. But still it's 60,000 lines of kind of vibed up code and an engineer has to support it. It's a rust code too, right? Yeah, yeah.

Not that it's bad code, but like Rust is inherently hard. And so if you got 60,000 lines of even harder code than go code, go to go because we'll use them then Rust for example. Yeah, it's like, if there's a failure then and the AI's can't actually solve the problem, and an engineer has to dig in and get deep with it and whatever. And it's like, how do you determine what things you want to support at that level? Because we only have so many support tokens, engineering support tokens that we have to hand out, right?

And the thing is like, AIS will help scale that. But if you get to the point where the AI can't help and you actually need to do it yourself, then there's that limitation. So, but like, how do we, I guess the question for me then became like, how do we avoid this kind of thing? So one, like, I'm an absolute believer in a solid verification suite. And I think a verification suite is much, much bigger than unit tests or even integration tests, right?

It has to be more comprehensive. Like, it's basically what I would have a QA engineer do back in the day. Like, I got my start as a contract like tester on Windows 2000 back in like, 1998 and 99. And I was, you know, a QA engineer. And essentially, like I spent my time writing code to create QA environments to test out new builds and different scenarios and stuff like that.

I think that's going to become a lot more relevant for engineers this year, right? They're going to spend a lot more time. If they actually want to get the benefits of, you know, agent coding velocity, they have to spend more time building QA tooling to make sure that what they're cranking out is actually good and robust and all this other stuff. So I basically like, we have a bunch of testing internally, obviously, and we have multiple teams doing it, but we need more. And then the other piece is kind of just like a matter of like functional code organization.

So the problem I was working on spanned across, you know, probably like 10 different files in the code base or more, and it's spanned across, you know, maybe like over 100,000 lines of code. But when you start up clog or codecs or whatever, they won't read an entire file if it's more than what are like, 2500 lines? Yeah. 2500. Oh, 2500.

It's like, 2500 tokens are like some sort of number, 25,000 is a number. It might strap. Yeah. Definitely. Like, so there any code file that's like 20,000 lines of code, it will not read.

So basically like, it'll sample little pieces. And I think what that needs to do, again, this is just my theory of like, I think like the result is that it's good because you're only get a sampling of the thing and basically it doesn't have a context, it needs to make good choices. So I still think you need a lot more, you know, professional developer involvement when it comes to architecturally, how do you organize the code? How do you kind of like break down the problem? Like if you have this big problem that you're trying to solve, how do you break it down into smaller chunks so that you don't have to keep the entire thing in your head at once, which is important for developers, but it's also important for agents too.

Right. So part of this is code files that just, you don't let code files get that big, right? You break it, you break them up ahead of time. You make clear what the invariance of the system are and what the expectations are, you make it so that the agents can read those out quickly and easily to get the context for anything they're working on within a system. But I, like, for our, for our engineering team this year, you know, my expectation, like everybody's using these tools and my expectation is we're going to spend a lot of time building QA suites and things like that that essentially like run in on developer laptops, but also like in the cloud and all of it is going to be designed such that an agent can kick off the run, an agent can look at the results, it can run validation steps, you can give it like, we're building like command line tools, they're designed not for humans to run, but for agents to run so that they can validate signals from the, you know, the database running, right?

Some of them are like black box signals, they're accessible via public APIs. Some of them are reaching into object store and looking at file states and actually like reading binary files out with these tools. So yeah, basically building that so that the agents can kick those off, do the validation, do the inspection, make code changes and deploy it and run it again, like in the cloud without an engineer having to do a reasonable one. But also at the same time making it so that any engineer on our team at any time has a single command to kick off one of these specific tests and look at it and look at it and iterate with an agent. This is the year we almost break the database.

Let me explain. Where do agents actually store their stuff? They've got vectors, relational data, conversational history, embeddings and they're hammering the database at speeds that humans just never have done before. And most teams are duct-taping together a Postgres instance, a vector database, maybe a Elasticsearch research, it's a mess. Well, our friends at TigerData looked at this and said, what are the database just understood agents?

That's Agentic Postgres. It's Postgres built specifically for AI agents and it combines three things that usually require three separate systems, native, model context protocol servers, MCP, hybrid search and zero copy forks. The MCP integration is the clever bit your agents can actually talk directly to the database, they can query data, introspect schemas, execute SQL without you writing fragile blue code. The database essentially becomes a tool your agent can wield safely. Then there's hybrid search.

TigerData merges vector similarity search with good old keyword search into a SQL query. No separate vector database, no Elasticsearch cluster, semantic and keyword search in one transaction. One engine. Okay, my favorite feature, the forks. Agents can spawn sub-second zero copy database clones for isolated testing.

This is not a database they can destroy, it's a fork. It's a copy off of your main production database if you so choose. We're talking a one terabyte database fort in under one second. Your agent can run destructive experiments in a sandbox without touching production and you only pay for the data that actually changes. That's how a copy on right works.

All your agent data, vectors, relational tables, time series metrics, conversational history, lives in one queryable engine. It's the elegant simplification that makes you wonder what we've been doing at the hard way for so long. So if you're building with AI agents and you're tired of managing a zoo of data systems, check out our friends at TigerData at TigerData.com. They've got a free trial and a CLI with an MCP server. You can download the story experiment thing right now.

Again, TigerData.com. These tools are definitely bespoke too because like you at Influx Data, Building InfluxDB have a unique problem that may be shared by others but it's so unique to you the integration level of it. You know, it's got to be, I think we're in like this, this era where bespoke tooling used to be like, oh my gosh, like you said before, we can't support that new thing. I mean, we're trying to hit our roadmap, let alone internal tooling to support the work we're doing. But I think we're now in an era where maybe QA is the most important level to hire for, to build internal bespoke tooling to confirm and verify and code review and code quality.

The plethora of code we can't create and that's going to become the bottom economically supporting it with support. But QA, that process is all about the right bespoke fixtures or, you know, not actual tests in the code suite, but an actual like if I was a QA agent and I built a tool to test it, let's build those things. And now they're versioned, they're in perpetuity, maybe they're even hosted, maybe they're in an on-prem situation or a home lab like situation, you know, in the office or maybe even the cloud, if that's what you need to do. But that's the era I think we're in as bespoke tooling to test and verify and code quality what we're building. Yeah, I think so.

For sure. I mean, and the nice thing is like the agents are more than happy to create all that tooling. Oh, yeah. It's easier than ever to create that. Do you want to test it?

Yes or no? And I was like, let's test it. That's like, yes, to complete that and enter please. Right. But again, like, I, it's funny, like I've also had the experience where I have some tests and I tell the agent to make some change or whatever and it does this and then it will change the test.

So that it actually like, it makes the test pass but not because the code does what it's supposed to do but because it had to change the test expectation. So I still think you have to like keep your eye on them. You're 100%. I think your engineers will become your QA in terms of I don't think you necessarily need separate people for this because they're well positioned to actually craft those tools. As you said, it's no longer boring plumbing work because you're not doing the work yourself anyways.

It's actually can be kind of exciting and fulfilling to create a qualitative analysis tool that can be used across. I don't agree with that but I don't think that opinion is widely shared by software developers throughout the industry. Yeah. I mean, I think the problem is like software development is changing significantly right now, right? And it will this year and I think it probably will go more towards what you're talking about which is software developers more and more are going to be responsible for overseeing what's going on with the agents and doing QA and validating that the results are good.

But the thing is, if you talk to most software developers, you know, we got into this industry because we actually liked writing code and it's for a lot of people it's like they don't want to do that. And that's not why they became software developers. They don't want to spend their time validating what somebody else's code is doing, right? Most people if you talk to them like what's the thing they hate most about their jobs in terms of like being software engineers that hate doing code reviews. Now it's like the agents have turned us all just into code reviewers.

We're just reviewing agent written code. Well, I was going to ask you if you included code review in that because you didn't mention anything about code review at a certain point when you have so many validation tools. You know, do you do randomized testing like they do a drug test like do you have to do you have to code review everything because that's going to be such bottleneck. Whereas if you have your 1100 integration tests and then you add on to that thing after saying after saying to verify at a certain point, do you need to do code review? I know today you do.

Yeah, I mean, I would love to get to a point where, you know, you're able to triage code and you say like, ah, 70% of the code doesn't have to be reviewed by human. It's enough to have it reviewed by the AI. Right. And if it passes the verification suite, then you're good to go. And then, you know, then it's just a matter of like you have an AI triage the code as it comes through the pipeline and it's like, okay, here's the 30% that actually needs human eyes on it.

And right. And not all humans are created or focused on the same areas. So it's not just it needs human eyes on it. It's like, oh, it needs, you know, this person's eyes on it because they know this area of the code base, which is right, like code owners kind of thing. But even that, I don't know that we'll get there because the problem is you have to build up trust in the tools over time.

And really it depends on your risk profile, right? What is it you're creating? And the lower, like the things that aren't as critical, you're much more likely to be like, ah, we'll just, we'll just wave it through. And that's fine. And that's what you're seeing, I think out there in the world is like, you know, people are just creating fun things for themselves, whatever.

Yeah, zero users, you know, demo it off. Nothing to lose. Yeah. And as a software developer who hates code review, it always has and probably always will. You know, I'm ready for that one to go by the way, side.

I always like, I have a mixed opinion, a mixed feeling about code review because sometimes I feel like, you know, a lot of times like people are, it's just like, people are just hitting okay or whatever. Review reviewing it for like stupid like syntax stuff or whatever. It's not actually like reviewing the big picture. Yeah. What does this actually do?

Not everyone, but like at some point, like sometimes, yeah, even for me, like not on my code reviews are great. Like some of my code reviews, I'm just like, it's on this day. I'm just like, ah, let's just get this through. Yeah. You know?

I'm hitting my unline change and, like, a hundred nitpicks on your code review. And then you submit like a 3000 line edition and it's like L-G-T-M, you know, merger. We've been thinking it's true. Yeah, exactly. I get that.

I think there's some truth to that. Uh-huh. Yeah. I mean, I think it's tricky because for better words, like software engineering is changing and I think people are just going to have to like deal with that. I think for people who was somebody who wrote this the other day, it's like for people who were like maybe this Andre Karpathy.

It's just like for people who, you know, fancy that who always loved software engineering because they like to build things, those people are fine, but for people who like software engineering because they like the details of writing code. Those people are kind of hosed because, you know, those days are limited at best. Right. Yeah. It's weird.

I guess I'm a two minds because I've, I've been both people. I do enjoy crafting a function and like the thought process and the toil and the the win at the end of it where you're like, you know what? That's a well-factored thing that works as a court and I built that. I don't totally love that. But I think of that.

And I'm okay not doing it too. Like I actually kind of just want the end result. And so I guess I've, I've been on either side of that fence. That being said, I do think developers enjoy making internal tools for themselves. And for their colleagues and so we have verification tools.

I hope that we'll enjoy the process of like coming up with really cool tests and tools and building those at a fast rate without any of the toil. I actually have a theory that I just thought of because I agree with you. I think developers love building internal tools for the stuff like that. I think one of the reasons for that is because they're so little friction for doing so. You can create it.

And when you toss it up for code review or whatever, like people don't nitpick it because the stakes are lower, right? They're just like, ah, it's internal, it's not going to go out to a customer. That's true. You know, so the problem is when you raise the stakes, when it's like going out to a customer and you really have to worry about it, then it becomes harder to ship, right? And then then like your enthusiasm degrades because you're just like, ah, I really want to struggle with this and get me through.

You procrastate for a couple of days, maybe a life to who knows. You don't do that at all. You go work on some internal tools then, you know? Exactly. Yeah, it's just go do something fun for a moment.

It only runs in Chrome, but that's fine because that's the only browser I'm using. You know, like that feels good and I'll have to do all the extra stuff. Yeah. Yeah. Yeah.

So yeah, I think ultimately like sweating those details is still going to be important, even if all the ais are doing all sorts of code and stuff like that. It's still still important for somebody to sweat the details and make sure everything it's smooth works is expected and all this other stuff. The idea of editing and curating and fine tuning and having taste is like of the utmost importance. Now, it's like you said, if you have engineers who really enjoy the process of creating software for its sake and not just simply laboring over the function or the particulars of the language, you're going to see that be a less thing. But I feel like PMs, product managers, folks who were sort of like developer adjacent, but still sort of developer, their job wasn't really around writing codes around helping developers who write the code to understand what to build for the company.

Like this folks are in a well positioned to become engineers. When you say? Yeah, I mean, I think the people who are like in the best position to take advantage of all this are either product managers, like every product manager is in a great position right now. Like they've got to be living the best lives because they can actually do stuff before. They'd wait for an engine.

They'd ask, you know, try and sequence everything through the engineering team, wait for an engineer. Now they can just like do things. The problem is whether or not that actually anybody will accept that debt to production. But I think also like engineers who are like products minded or product focused engineers, like those those engineers are the ones who are just going to, you know, just run wild with this, right? The, you know, and I think in that case, if you give like product focused engineers, the ability to actually like freely create things and iterate on it, what you'll see is like a small team having a productivity level that's like a hundred or a thousand times greater than what you get before.

And you'll have teams of like two to four people producing what used to take a team of like a hundred engineers, right? What much more time it's crazy. Yeah. What I think is possible. And what I mean, I pretty, I've a lot of faith that actually like there's still going to be a couple improvements this year, even if they just make tool use a little bit better, maybe a little bit longer context, all this stuff is going to keep stacking up.

It just gets better and better. So when it comes to building the machine that builds the machine, I do so I look when we put it in your blog post, do you think that's something that every engineering team is going to reinvent inside themselves? Is they reinvent themselves? Or do you see vendors coming in and solving these problems? Or do you perhaps see the big model providers, the opening eyes and the entropics actually just leveling up their tool so much that it is the machine at a certain point?

What are your thoughts on? Like, where does this re-imagine come from? So I think all of the above happens just on different timelines. Okay. Right.

So I think right now people like forward thinking engineering organizations are already building a bunch of custom tooling to do this stuff. And they're either, you know, building up a whole set of like tools and stuff like that's that's designed for agentic use, or they're actually working with the API directly and they're creating their own custom agents to do things within their own infrastructure, to do things within their own code base and their own product delivery cycle. There are also a bunch of startups who are trying to build these things. Most obvious ones are like the code review startup and all that kind of stuff. And then, or on all the way opposite side of the spectrum, like pure like vibe-coded application builders, right?

Like lovable and rap lit and like all these things. But ultimately, I think that the big model providers are going to just continue down the pathway of producing better models, right? That have, they're able to process a larger context, ideally, hopefully a larger context. I feel like it's been a little while since we got a good upgrade there. But a bigger context, but they're also going to continue to build agentic tooling, right?

Just because it's so obvious that that's what people want. Like, you know, at this stage, like, you know, clock code keeps adding more capabilities along the way. Every single one of these agent programs keeps adding more capabilities. So at some point, it's like you don't need to write your own tool because it just does that. And you get to the state, I think you'll get to a point where, essentially, you have like a knowledge base within a company.

It could just be defined as markdown files, right? And the knowledge base says like, here's how you do these things. And you can define processes, you can define all these different things. And that's consumable by agents. It's consumable by humans.

But yeah, I think this year, a lot of people are going to be creating their own and they're going to be able to start up trying to create stuff. But I think within two or three years, maybe a lot of that gets eaten by, you know, anthropic Google and open AI, right? Hence the SaaS software apocalypse, you know, that's right. Right. Well, you know, we got to feel good as an infrastructure provider at this point, right?

Like, infrastructure, that's infrastructure. So you're, you know, you guys are sitting pretty, right? I mean, I feel good in the sense that I'm so much uncertainty. I mean, I'm generally an optimist. So, okay. And I'm like, I'm just excited about all the stuff that's currently possible.

And I just like want more time to play around with these tools and kind of like create things. But I think, yeah, as an infrastructure software provider, we're in a position to not be completely displaced. Yeah. But at the same time, like we're not, you know, we're not necessarily in the AI hype cycle or growth cycle, whatever, right? Because we're creating is not something, you know, that we're not on some sort of weird AI growth curve.

Well, you do probably have a lot of folks using InfluxDB. And I know that in the past, you've done a lot of, you've had your own conference, right? You have a, you know, a comfort of the thing to do, a lot of workshops that you participated in and have. So you're educating folks to use InfluxDB in great ways. I'm curious how, you know, while you're not in that AI centric, however you just phrased it, how your CLI and how your API may be reflecting this new world.

Yeah. I mean, so there's this idea I have, and this is like a prototype that I built up for the holiday, but the idea I had essentially then, which I still have now, which is, you know, before early days of InfluxDB, when I was thinking, you know, building the thing. And one of the things I wanted to do was like optimize for developer happiness, right? I was like, if you optimize for developer productivity, make it easy for them to use, easy to create things like the software will win. And that was informed by my experience, you know, using Ruby on Rails in the early Rails days, like, you know, I could create like a web app and a fraction of the time that you could with other frameworks.

And Ruby is a language generally, you know, it was like designed to, for developer ergonomics, right? Because Matt's cared about like creating a language that was like a delight to work with. So developer ergonomics were like the thing. And for InfluxDB, that's what I modeled. And I took inspiration also from MongoDB because I think MongoDB really nailed developer experience early on, right? They had a data model and a way for working with the database that just made it easier

for front-end JavaScript developers to create applications on top of that database. And I was like, so that's how you win, right? As you focus on developer ergonomics, you make something easier to use, whatever. So the thought I had in December, which basically the tail end of last year is like, I don't know if developer ergonomics matters much anymore because developers aren't going to actually be writing the software. What matters is actually like, how easy is it for an agent to use?

And it's actually, West McKinney had a post probably like two weeks ago where he mentioned this. He was like, you know, he mentioned like instead of designing for developer ergonomics, maybe usually designing for agent ergonomics because that's what's creating the software going forward, right? And he used, as his example, he's been lately writing a bunch of Go code, but he doesn't have to write it in age. He's never been a developer before. He's a Python guy or like a C guy, you know?

So I think that's very true. And when I was thinking about InfluxDB, I was like, well, what does it look like if an agent is writing most of the code? One, and two, you want to make it so that people can quickly use whatever code they're having the agent create. And the idea I had there was like, well, then you want the database to essentially be like a platform for running agent written code. So how do you do that? Well, you need some sort of safety in there.

Right. Forks, Sandboxes, stuff like that. So the idea was like, well, it's like, well, it's great because you can put a lot of time in the database. You can sandbox it. You can limit that number of CPUs, you can run ram, you can limit specific calls that it can make. So basically prototype that.

So we may experiment with that over the course of next year. I don't know. Again, that's not getting shipped. That's not always a side question. Right.

Steve, that's possible. I think what's happened to them, and you still have developers right here. I mean, developers still care about CLI. They still kind of route API. It's not think your notion of Wasm in a sandbox environment in the database is future thinking.

I think you're thinking a year from now, maybe not so much the next six months. You know, and only reason I bring this up is because I'm like, just laser focus on this idea that, you know, platforms like yours need to pay great close attention to the CLI. It's just the same thing that gateway to API, right? It's the framework developers use to implement and utilize that. And if you're paying close attention to your CLI and how that's engaged with by developer, that's augmented by an agent, we still have developers are still coding by hand.

They're still learning things. There's still people leveling up on InfluxDB and how it works and how they can utilize it, which also have agent enabled developers who are writing go for the first time with their Python developer, you know, I mean, and we need to pay close attention to those interfaces and identify or agent to identify, I suppose, by the right where to use, give them the right kind of tooling that helps a developer be augmented by an agent, utilizing those tools to get started faster, to take influx to new places inside their org. It's the great vertical for you, right? I mean, you can go much further into an org now because you can hand a much better agent enabled CLI coupled with your great API that's, you know, got all the right kind of tests and all the backing behind it. Now they're off to the races, you know, you've enabled them to go on their own roads at much greater speeds and not have to build new features. You just get to go further in, not, not the other way.

Yeah. I mean, I think the thing is like, we don't sell like a whole solution, right? Like we're just like, we're always a part of a component that a developer uses to build a solution, right? Whether it's like in sensor data use cases and monitoring system monitoring use cases or whatever. And I think where there's a lot of potential is like, you know, we've often had customers or users asking us to build like more application level features and stuff like that in a lot of times.

Sometimes we've tried to do that stuff and other times we've said like, no, we can't do that. I think all of the agent tools and coding, what that enables it, it makes it just much, much easier for end users to create all of that software. It makes it create a fully complete solution. And the solution is like can be tailor made for each individual organization that it sits in, right? The thing is all that I believe is like probably way too forward looking because that's not where we are, right?

Like most enterprises are, you know, they're, if they're using agent tooling, agent software development stuff like that. But my impression is that most enterprises are doing it just to make an individual software developer a little bit more productive, right? We just want you to hear people talking about, ah, yeah, I got like 10% gain, 30% gain in productivity, people are just like guessing, right? And that's because they're using one session and they're helping them write code a little bit faster, but everything is largely like the same. I think that's going to remain true.

But I think this year there will be just a continuing development of essentially like a separation of people who are like all in on it where they build the machine, the builds the machine, right? The machine is basically the software, software factory that delivering software. And if you're building the thing where it's like, okay, we can have not one developer running one agent, but we can have one developer managing 15 agents. That's just like writing a bunch of code and delivering everything in the background. I think you'll see a real difference between engineering organizations that are delivering at that kind of velocity versus once it aren't.

And I, but again, I think along the way what we'll also see is like spectacular failures, right? Like you will see big like security compromises. Like club like you. Yeah. Yeah.

You will see big like infrastructure failures or, you know, production failures and stuff like that. And we'll be my bad. Multiple. Yes. Multiple.

For open claw because it's not multi-pot anymore. That's right. No. That was so last week. Yeah.

So like it was like, yeah, it was like forever ago. Yeah. So yeah, I don't know. It's wild. It's crazy times.

Are you thinking about this from a CTO level only on how you enable your engineering department? Cause like the question that I was trying to pose there was, how do you, how does your product change so that you're tooling enables the users better, not just your engineering department better? Like how do you think this changes? How do you interface with your customer and enabling the users of influx? Uh, I mean, a lot of it is still the same.

Like, well, you know, we've already put like ask AI features and our documentation website and we have like, we're starting to thread this through our support organization. Right. So what I expect is like more and more tooling to allow AI to basically just solve proud, solve customer problems along the way. But in terms of actual like database features, other than making sure that the command line interfaces that we're coming up with and all this tooling that we're coming up with is accessible by agents. It's really, at this stage, we're really thinking like it's on the, it's on the individual organizations that are, you know, that are adopting inflexDB for them to use their tooling because we're still not trying to, you know, create an agentic platform for creating time series applications, for example, right?

Because then we'd be trying to like bring in a model and do this thing and it's like, a bunch of that stuff. So mostly what I'm thinking about it from is like the perspective of like a CTO, we're trying to optimize a software engineering organization. But I do think there's downstream impact. It's just that I don't think we have any particular talent in being able to like innovate in that area faster than, you know, the big AI companies like OpenAI, anthropic, Google are going to actually come out with new agentic tools and stuff like that. As those tools and those models get better, they're automatically going to be better at using inflexDB and better at using our stuff as long as we have proper documentation in markdown files that agents can consume command line and if tooling that the agents can use, you know, I'm not, I'm not super bullish on MCP.

Just because at this stage, if I can, if I can have the agent use the CLI, that's what I use. But, you know, I think MCP is a, there's a lot of reasons why it's good and a lot of reasons why it's bad. I mean, in certain cases, it makes a ton of sense, but in a lot of cases, it's just like, I want to just pull the CLI and make it more agentic friendly. You know, that's, it's a, it's a sibling to the CLI. Yeah.

I mean, I, I imagine we'll be adding like more security features to the database where the security features are designed around agents accessing the database versus humans, right? Because there's, you know, my guess is the, if you, if you take out like dashboarding, basic dashboarding, like I assume like agents are going to be the most frequent accessor of the database. So the question is like, how do you want to lock them down? Right. You want to lock them down so they can't mess up the data that's in there.

Maybe you want to lock down visibility in terms of what they can get to. So, but those are all like security and access controls. But the truth is like a lot of that stuff is the same if you have a very large enterprise organization with a bunch of human sex. So I feel like, you know, just like I said, like for all the software development practices that matter before, just matter even more, it's the same thing. Like all these features matter more.

The only difference is instead of having an organization where you have, you know, a hundred or a thousand humans accessing the thing, you also have a hundred, a thousand agents accessing it and doing it much more frequently because agents can work faster than humans can. How has collaboration changed inside your work as a result of moving faster? Is it like bonkers in real time chat? How do you track tickets? How do you guys get together and do scrum?

You know, are you practicing lean? How is your, your, I guess, day to day collab around what the build and how to build it? And maybe even pair programming, you know, is that, is that happening? How does it work? Yeah. So we've never been a pair programming shop.

I mean, certainly like individual developers will sometimes like contact on one of the other developers to like pair on something quickly, but not like, you know, agile pair programming kind of prescriptive kind of thing. Initially, like in July of last year, we started doing like, oh, we'll have like an AI day, like once a month where it's like, you don't have to worry about doing any sort of like product development or stuff like that. It's just like pick up some AI tool and do something either fun or whatever and share it with the rest of the engineering work. We also created, you know, Slack channel for, for like AI stuff where it's like, okay, share your learnings with, you know, the, what, whatever tools you're using.

And recently we started sharing like skills that are getting developed inside, right? Skills for like code review or other kinds of things. So I expect more of that. I, what I anticipate is like we will build a collection of skills for individual tasks. So like, you know, we have this pipeline for how customers get support.

Right. We have our 24 by 7 support org. Things come in, if they can answer it, great, if they can't, they log in issue in a specific recovery that we have called EARS, E-A-R engineering assistance request. Right. And basically that gets logged in that engineer looks at it, whatever.

So what we haven't done yet is build a set of agent skills to help process those and help engineers like dig into stuff. So I expect we'll probably be doing that. I'm guessing like a lot more skilled development stuff around those specific kinds of workflows, right? Sport thing comes in, do this. You're trying to do this in a production cluster or do this, right?

The kind of stuff we'll like preload as a, you know, context that's important and just a tools and just make it easier. But yeah, I mean, the collaboration part is tricky. I still, I'm thinking maybe we should be doing like a, you know, like an occasional like engineering demo to each other. Like we also have like a Slack channel where we can post, you know, demo videos of things. But again, this is all kind of like ad hoc.

It's not. I mean, you try to figure it out. Yeah. Yeah. And the demoing is pretty interesting because, I mean, showing off something because you're probably getting there faster, you probably need more feedback.

I'd imagine while you're not vibe coding necessarily, like a traditional, maybe even a negatively connotated version of vibe code or is doing it, you're still vibing with the agent. How are you defining those plans? Is there a centralized place for specifications or whatever plan the agent is working on? You know, how do you, you know, riff on that yourself to discover and learn and then define and feel secure in it, but then also share it and get feedback? Is there you have loops for that currently?

How do you do that now? We don't have loops for that currently. Like right now, everything just has to go into a GitHub issue, right? So we use GitHub for all of our issue tracking and stuff like that. And we use the Canva board and whatever.

So it's like anything working on has to go into a GitHub issue. What I will typically do is I will, before I start something, I will create potentially like a markdown file to track what I'm doing, right? To track like the work and I'll come up with like whole design for the thing and whatever. But even that, like the problem is like you put that up so people can review it. It is trivial to come up with like a plan that's like, you know, a few thousand words of with like words and some code snippets and whatever, right?

Because you just do some brainstorming with the agent to do that too. Yeah. Yeah. Do some brainstorming with the agent. You put together something and the thing is like if you actually iterate with it, like you could put together something that is actually like, I think qualitatively pretty good, right?

And it outlines in detail what you're going to do and how you're going to do it and what's important and all these other things. But again, the problem is like I can do that with an agent in 30 minutes. And it'll spin up like this, you know, the 2000 word document with all this other stuff. Another human to review that it's going to take them an hour or more to read it and digest it. So the problem is like if every engineer can do that in every amount of time, then again, like you have this problem of, okay, it's too easy to produce this stuff.

And who's going to review it and who's going to like, I always feel like the 37 signals model of like, okay, whenever we do a feature, we'll put two people on it. I think that's almost like the way to go. It's like you have two humans on something. They don't necessarily need to pair a program or whatever. But then you actually limit the scope of, okay, you have somebody who can review your stuff closely.

And again, like we don't, our engineering team doesn't have that. We have the thing is we have a bunch of different engineering teams with different responsibilities, right? Some of them are, you know, there's an engineering team that supports be one of the products, the hosted version and the on-prem version. There's an engineering team that supports me too. There's an engineering team that supports the iteration of V3 that we currently have hosted as an engineering team building.

This new version of V3 that we have is an on-prem product and also hosted in AWS, like a time stream for MPLXDB, it's actually like an AWS first party product. So every team is like kind of a little bit different in terms of what discovered those possibilities are and what they care about. It's tough times. I mean, because you, I was going to ask you to like you, you just mentioned it, but your team size, because we just had a conversation with a MEL, the same one of our past participants slash animal and GS party. Sorry, Jared.

We talked about just this idea of, you know, you mentioned 37 signals in that conversation, I mentioned getting real and backing in the days of getting real, which is 15 years ago, I'm assuming on the date range of the book release, very pivotal for many developers out there to, you know, to get real. But it defined, I think a four person team plus either a PM or designer. I forget the exact prescription, but it was still around four or five was like loosely there. And then Jeff Bezos was famously calling the idea of a two, two pizza team, which depending upon the, you know, your appetite for pizza is like a four person team in my brain. Right.

And so I think you will see, do you agree with that? Like it's probably four people. I don't know. I think I think Bezos have a larger team in mind, like up to like eight or 10. Okay.

Maybe. I don't know. But I mean, the thing is at this stage, I think any more than three is more than you need. I think it's like two or three. Well, yeah, because I mean, well, if you go back down to enabling one person, that one person can now in your words from earlier produce a hundred X more code.

And so any, if you put more than two to maybe three in that kind of sphere, you got now 300 X of code output possibility, which I think is great in throughput, but just so much to overwhelm our feeble human minds. You know, like we still only have so much cognitive low, we can handle no matter what kind of super so you are in, you know, which are sleepless like the night before, you know, is your diet on point? Did you have an argument with your spouse or, you know, whatever, you know, that's something wrong in the, in the carpool line dropping off your kids, like all these things impact our ability to comprehend our day to day and stuff like any, any more beyond two, maybe three is probably pushing it. Like I wouldn't do a four person team anymore. I have like a two person, it's probably pretty solid.

Yeah, I think two or three, mostly just two though, where like you can almost be like a PM and an engineer, right? That kind of thing. Yeah, you need a count of building responsibility. Most of the work at this point is like trying to figure out, okay, what is the problem we're actually trying to solve and defining that well, then you've come up with a restructure for how to solve it, but then the agent just does all the work. And then the other side of this is verification and iteration, right?

Like verification is like, doesn't actually do what's supposed to do. And then the other piece is like, is the user experience what we want it to be. And then you just have to like tune it and make sure and polish it, right? Because there, there's still like a difference between the output of an agent where somebody is iterated with it multiple times to produce a more polished product versus the one shot example. Interesting time to be in for sure.

Have you figured out a way since you've penned this post on building the machine? Are you actively doing anything to build a version of a bespoke machine for you all? Do you have any ideas that you, any side quest plans, any specifications you've aligned? Can you give us a behind the scenes at all? If you've got this in motion, do you think it'll be something that somebody builds and delivers to everybody?

Or will it be bespoke per team? Right now, I think it's bespoke per team. I do. Well, I think it's bespoke per team using whatever agentic tool they want, right? And it's almost like, it's almost like when you hire somebody, a human, you train them on what you want them to do, right?

Because whatever they're software developers, right? You can't land a software developer in any organization, expect them to immediately become productive, right? You have to go through training, they have to look familiar as themselves with code base, whatever. I think the same is going to be true for people taking advantage of agent agent tooling, which is the agent lands in an organization and you have to build tooling, build a documentation, whatever to make the agent effective. The difference is with hiring humans, you hire one human and then that's it.

You've got that one human doing it. Once you've optimized your process within an organization for an agent to deliver things, you can copy the agent a million times. You can spin up a hundred of them, a thousand of them. So what we're doing internally is still right now, we're still very much in the we're building tooling that is like infrastructure tooling and command line tooling so that both humans and agents can do more verification of does the software do what we expect it to do. And how if we have a customer issue that they're reporting, how do we reproduce that and then put it, roll it into a regression suite that gets rotated.

And then as we as that becomes more and more mature, what I want us to do is like to build agents that can run in a loop to try and solve some of these problems. But again, like, yeah, that'd be cool. Just like a regression suite that like an agent actively has bounds on and sandbox. And like, if it solves it, cool, if it doesn't solve it, then no harm to file, right? Just spend money on tokens.

And it's not a cost consideration, not so much a, you know, it's not the worst case. It solves the problem, right? Like it's a good thing. Well, so for example, like the thing I've told like our, you know, our engineers and like I told, you know, we had our QBR a few weeks ago with our executive team, quarterly business review. And basically I told the executive team, like, look, like everybody inside the company has a superpower that people outside of InflexDB do that have, right?

Which is they have access to the code base, the proprietary code base that we have that we sell our customers. If you pair that with like Cloud Code or Gemini CLI or codec CLI, you can actually do a lot of things. You can answer a lot of questions that people outside the company might have support questions. So basically where I want to get to is, you know, if there's something that comes in for support from our, from a customer, we are able to actually answer that within minutes based on agents doing the work. And you still need like support engineers and regular engineers to review things and to build the tooling behind the scenes.

But ultimately where I want to get to is all of that stuff is executed automatically when things come in and they can use both the code that we have internally that our customers can't see, right? And the, all the documentation and internal like knowledge base that we have either in, you know, support, previous support requests or issues that we have in close source repos or documents, markdown files and code. I think connect a lot of those dots. If you have that corpus of past ticket history regression history customer use case, even if you're paying diversions of InfluxDB or your API, for example, so I mean, that's a lot you can really give it to do a lot of cool automation stuff on top of that or just make the human faster.

Like imagine if you can answer a support quick ticket, you know, and next time, you know, like you just now solve the problem so much quickly, that customer is not more enabled. They have more faith in you and more trust in you. And that's a good thing. And ultimately, you know, I'd be remiss not to ask you this question before we begin to tell the show because we've talked to you in the past about your thoughts on open source licensing, open source in general, even a big believer and contributor to and champion of open source in your career. And I'm really curious how, how do you think this shapes or changes the landscape of open source software from this bespoke world?

And maybe it makes more sense just to build the thing we need from scratch, not lean on maybe a library or whatever might be out there. How do you think this will enhance or degrade if at all open source software? I mean, I still think there's a ton of value in libraries that are written and tested and hardened over the course of multiple years. So I don't think that's going to go away. I think it's probably the more complex something is, the more likely it is that you're going to want a library to do it.

So like a SQL query engine, for example, that is a very, very complex piece of software and you would be best picking something off the shelf that's actually written. You're not going to ask an AI to write the thing from scratch, right? Although it certainly could try and probably could produce some fairly passable result, but it's not going to be, you know, as performance and as battle hardened as something that's been developed over the course of the years. So I don't think that changes. I think as the eyes get better and better, like the scope of things that they can one shot and give just give you improves.

So like, you know, in the various like code ecosystems, like MPM or crates or whatever, there's this huge long tail of libraries where it's like, you know, a few functions or what, like those, the value of those is like on, right? But I think the bigger problem based on what I've seen from people online is there's now like a deluge of, you know, AI slot pull requests that open source maintainers are having to deal with. And they're basically getting to the point where they have to start shutting down pull requests, like they are accepting them at all, right? They have to be, you know, we'll be open source and whatever, but we're not open contribution because they can't deal with the fact that like they're just getting inundated with these pull requests that have no thought or time behind them, right?

Because it's just too easy for somebody to spin up an agent to say like, do this issue of PR. So, you know, maybe that gets better and GitHub actually adds some tooling. You know, I think we've seen a lot of like GitHub anger over the last like few months because they don't seem to be too on top of this at the moment. But yeah, right now that feels like a bigger impact. But ultimately, I think open source software is still going to be a thing.

It's still going to be important. Right? You're still, you're still going to want to adopt software, you know, well developed software rather than just trying to write it from scratch, right? Like, you know, who has a cursor may have been able to spin up like a, you know, a browser from scratch getting the agents to do it, but it's not, it's not Chrome. It's not Firefox.

I think a lot of that is like you want some of those Chrome developer tools, especially some of the headless crumb stuff that's available. Like, why would you fight that battle? Why would you recreate it? Because now you're just having one more surface to maintainer or to support even. Yeah.

I mean, I think, you know, there's, it's really difficult for open source, like software companies at the stage. I would expect to see fewer open source software companies really. Like, if people are going to do something, they'll do source available, or it just doesn't make sense to, to, to do open source really, like you do open source if it's not like the actual product you're trying to sell, right? So it's like, you know, if you have a social network and you want to open source, these libraries that do whatever, that's fine. But I think more and more for people who build infrastructure software, who want to sell it, they'll probably be doing source available licenses, if anything, because, you know, it's just like those.

It's too easy for anybody to pick up the source code and then like run wild with it and do whatever. So yeah, if you have good docs, a good API and a good CLI and open source, we just give them all the keys to your kingdom. Basically, like the aging and scupal that up and do most of the for you, what you do buy is, you know, obviously the support mechanism, maybe up time, maybe just a burden or the responsibility of up time, or if it crashes or backups, it's just one more surface where you have to now maintain. But if you have a pretty good ops team, then that's like, sure, let's just support one more thing. Why not already doing 50 other things we're doing over here, another things.

Why not add one more thing to it? If it's that important. Yeah, I know. I mean, it's funny because like before, I feel like over the last 20 years, you know, a lot of developers did open source in the early days. It's specifically for like junior developers, they would do open source because it was a way to like get some practice, right?

Get some examples of like work that you've done to help like raise your profile, to help you ultimately like get a better job. Right. So baseball problems are stats. Right. And then the problem is like that is kind of taken away, like that motivation is taken away because again, it's so easy to produce the code.

You can have an agent do it. And the maintainers don't want to take your code anymore because they're getting like slammed with a bunch of like garbage from whoever. So I think what we'll see most likely is a lot of like open source projects that again, are like open source, but close contribution and they're developed entirely by one person or they're developed by maybe a very small group of people. And if it's good, like what I'd expect is you'll actually see like very complex pieces of software that are very good and have a high quality that are again, just a couple of developers working with agents to produce a result that is better than what you get if you just asked an agent to write it on its own.

So maybe the rise of the of the single single developer open source project. Yeah, just on Mitchell Hashimoto was threatening to go close contribution just the other day because he's just fed up with it. Yeah, he was the one I was thinking of for sure. Yeah. I've heard that from other people too.

I actually have to talk to Andrew Andrew Lamb, who is the PMC for data fusion and Parquet and Arrow. He's on our team and basically like he runs those projects and he's definitely made like rules for PRs, rules for like using AI in your PRs along the way. But I haven't yet heard him complain that he's just getting completely. So I mean, he's getting slant. He would before the A stuff he was getting slammed just because his projects are like, you know, he's so on top of them and he's getting so much like momentum with people contributing.

Right. Turns out that produces more for quite not less. Yes. Yes. Kind of the backwards, the backfire, even email, the more you answer your email, people respond back and then they have more email.

So that's right. Yeah. These things compound. Stoking the fire. That's right.

That's right. The fire. Yeah. Yeah, it's interesting. Uh, what makes someone want to contribute more to to Go see, for example, like what's the groundswell there?

Why is he getting so much? Why is he inundated with change or suggested change? I don't get it. Why? Because you get your pet feature.

You want your feature in. Yeah. And that's easy to have an agent code it for you and you don't have to put a thought into it besides, well, I tested it real quick and it works. So right. So if you are open a PR, start advocating for your little pet feature to get in.

I mean, that's my assumption. Yeah. I mean, I think like one, it's like as a project, it has like super high visibility, right? It's super, super popular and it's an end user, like an end user project, right? People are using the terminal themselves.

So yeah, maybe they're just trying to submit features that they want. Maybe they're trying to get recognition or whatever to be like, Oh, yeah, they're calling card to be like, Oh, yeah, I got a PR landed in ghosty. And everybody knows this project. So yeah, there's lots of motivations now. The curl bug bounty actually was ended recently because too many low value PRs around bugs and because they're offering real money, if you find certain things.

And so they know, Stemberg finally had to just turn that thing off because of similar problems. It's just kind of perverse incentives at the hands of, you know, available code gen is like, well, I can just code gen up something and hopefully get some money. I mean, people are going to do that all day. Yeah. I mean, one could be, you know, setting I lose on that, that bucket and just say, give me all the cream off this, off this crop, so to speak.

But at the same time, it's like, well, what's the point if it's just a bunch of his mostly noise? I mean, if 1% was signal, which is to 1% given, does it become like emails fan filtering, right? Right. Yeah, exactly. Robots check another robots work, you know, we're headed to our headed.

We're in a wild world. What's over the horizon for you guys? What's what's happening in flux that is, you know, this show goes out next week. We got a week's time between now and then is there anything particularly happening or anything in particular that you want to mention before we close up the show? Yeah.

So we're busy at work right now on the 3.9 release of Inflex to be three. The goal, you know, there are a number of things we're launching there, but we have a beta, hopefully a beta of some really big enhancements that we were hoping for people to test out, basically, that will enable wide sparse tables, many, many thousands of tables like we had in B1 and B2 and, you know, better, better query performance and a bunch of other things. So that's kind of what we're focused on right now is getting, getting that release out the door and then 3.10 after it, which should come towards the end of March. So yeah.

And then later this year, like a whole litany of features that are building on top of that core. I mean, some, uh, prunki well. We'll see. We'll see. I'm not making promises on that one.

No, it's, it's easy enough to let AI make the thing and it's hard enough to see whether or not it's like, can we support it? I'm confident by that you'll solve the problem though. I mean, at this stage, it's like, you know, can we support it? Can we give our customers and users like a good experience because we don't want to like just toss something out there in the world that isn't going to get them a good experience. We're trying to be a little bit more measured these days.

I wonder if you could, you know, feature fly that to some degree or take the folks who have asked for it and say, you know what, we're going to give you access to this with these conditions because you want to get this in the production, but we need some willing participants, so to speak, some, uh, some testers, some production testers that are willing to understand their maybe warts and we don't know. We're just not sure yet. I don't know. Just think out loud here. How has removed to Rust been for you?

Are you a happier team, organization, products better this last year? Uh, I mean, I love Rust as a language. I mean, I still like go, even though I haven't really touched go since 2016, you know, I love Rust as a language. I think it's great. I think it's, you know, the best option for creating high performance server software.

I think it's also good with agents, right? Because you have linters and you have the compiler and stuff. Yeah. It's able to do stuff. Good.

Nor dead code if you need to. It's like that. Dead code is on purpose. Okay. I'm leaving it there.

It's a future feature to shut up about it. It's good. It's good. It's going to tell the agent to not, you're not allowed to use the allowed dead code flag. Oh, can't do that.

Well, see, I'm not in problem with this stuff. I'm just playing with this. So I let it go in certain cases. Like I got like five dead codes and one of my products. I'm like, that's cool with me.

I know what they're for and I'm okay with it. Fair, fair. I love the, I love the Clippy lint. It gives you, I think lints are also a great signal to give to the agents to make improvements. Clippy lints.

I agree. All right. Anything left here? What's left on our planning at all that we can say? Have you said it all?

There's so much to go out and do and figure out. I would love to have Paul back on in a year and just see how much they've accomplished and things have changed because you're like inside in FluxDB. There's going to be some serious machine building going on and I'd love to know where where they get in the years time, but I don't know if it's. I agree with the machine building. And when you officially launch prom QL, I feel like you can come back on here and celebrate that with us.

Like what was the journey to take a fully generated feature you've never thought of to use a test suite to build upon them? That's I'd love to like look back at how you went from not fully convection to full convection. Yeah. Yeah. I don't know.

It's going to be an interesting year. Like is that all the engineering leaders I know are kind of like having the same struggle interlude within their companies. It's just like very, very turbulent right now. All right. We'll leave it there.

We'll see you in three months, maybe six months, maybe one year. We'll see here. We'll see Paul. We'll get you back on to the last time though. We'll see what happens.

Yeah. Maybe maybe I'll have something interesting to say in another three to six months. Who knows where we'll be? Who knows what the A&M off our plane? I'm not so nice.

We have lots of free time. All righty. Thanks, guys. Thanks, Paul. Thank you.

All right. That is our change login review for this week. Thanks for listening. And thanks to Paul for stopping by the show again. So much hard and wisdom and it's clear.

He's on a similar journey that we're all on. It's nice being on this journey together, isn't it? Kind of like that line for piano, man. They're sharing a drink they call loneliness. What is better than drinking alone?

OK, that got somber there in hurry. Let's thank our partners at Fly.io and our beatmaster. Breakmaster cylinder. OK, that's all for me. This one's done.

But come back on Friday when we are joined by our old friend, Brett Cannon, a conversation that's supposed to be about Python and stuff like that. But starts out with the deep dive on. Mm. Star Wars. Talk to you then.