The Changelog: Software Development, Open Source - Building the machine that builds the machine (Interview)

Episode Date: February 11, 2026

Paul Dix joins us to discuss the InfluxDB co-founder's 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 a bit) back to coding by hand.

Welcome, friends. I'm Jared and you are listening to The ChangeLog. Interviews with the hackers, the leaders, and the innovators of the software world. On this episode, Paul Dix joins us to discuss the InfluxDB co-founder's 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 by getting abactions. 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 Toml files for GitHub Actions. That's great. It's all great. Until your builds start moving like molasses. Get Up 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, we use Namespace. So to do all of our builds so much faster. Namespace is like GitHub Actions. but faster. I mean, like, way faster. It caches everything smartly. It cashes your dependencies, your Docker layers, your build artifacts, so your CI can run super fast. You get shorter feedback loops, happy developers because we love our time.

And you 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 GitHub actions with almost zero config. It's a one line change. So you can speed up your builds, you can delight your team, and you can finally stop pretending

that build time is focus time. It's not. Learn more. Go to namespace.com. That's namespace. Dot so, just like it sounds like it said. Go there, check them out. We use them, we love them,

and you should too. namespace.com. 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 agentic coding, et cetera, et cetera. How are you doing? I'm good. Yeah. Thanks for having me back on. Definitely, like most developers, I'm excited to talk about agentic coding stuff.

It's highs and lows, really. Yeah. On the daily, on the weekly, by minute by minute. Oh, man. I would say, you know, for the past like six months, it was mostly highs on the weekly. But then, you know, occasional setbacks when I feel like we got a little over my skis and let the agents do, you know, run a little hog wild without enough supervision. And then I had to like dial it back and, you know, fix things myself. So I'm in the middle of one of those dial it back situations right now.

Like you're writing code? Is that what you're saying? You're actually writing some code, bro. I am writing code. As I said before, I'm writing code by hand like a peasant out 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, right? Like, this could be faster. And, you know, the biggest thing is, obviously, this is all changed within the past year. Yeah. My, you know, my experience was I used, I started using chat GPT when four came out in March of 23. I started using these tools more for coding along the way. with co-pilot and all these other things in IDE completion.

But I would say everything like really, really changed last year with the release of Opus 4 in the late May. And I started using clog code around the same time. I know people at that point were using cursor and their clog code was released in what, like February or March or something like that. But so my experience of feeling like agentic coding is an experience, which I think is qualitatively different.

than, you know, completion and an IDE or anything like that happened, you know, I would say, in June of last year. And since then, you know, I basically adopted, I started using it internally and I used it essentially for like two or three weeks. And at first, I was just like, is this real? Like, is this? I, I couldn't believe how much it could actually do. But I was still keeping it fairly constrained, right? I would have, I would have like a well-defined problem and I would say like, hey, implement this function or write these tests or whatever. But basically after like two or three weeks, I was just like, this is magic and I need to, at least within my company, I need to start spreading the gospel, right? So I basically like wrote this like lengthy document that I shared with

my engineering team and I basically said like all of you have to start using this. And at the time, you know, Anthropic didn't even offer any sort of like enterprise licensing for Claude Code. Like if you wanted to use Claude code without, you know, paying for individual tokens. Actually, I don't even know if you could use an API key at that point. It was still like you had to pay for like a personal subscription. I told all of 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 like the experience is different. if you're worried about hitting token limits versus like you don't care.

Because if you don't care, you'll feel more free to like experiment and do things. And basically like it progressed from there. And I have, you know, I have a couple of like project, like hack projects that I did in the background that I could certainly talk about along the way. And the progression basically over the last six months. But basically by, you know, the end of last year, it seemed obvious to me that, that our days as developers of like handwriting code were extraordinarily limited. And that at that point, basically with the release of Opus 45 and GPT-52 Codex and probably Gemini 3, but I didn't, I don't really use Gemini that much.

But Codex 5-2 and Opus 45, I have a lot of experience with. You know, 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? A manager of clog codes and codexes. And I just need to figure out how to get all these things working to maximum effects, right? And the first, the first, like, post I wrote about this was basically on, like, New Year's Eve, where I basically brought up Amdell'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, you know, limited by the percentage 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 test and 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 do your support teams actually support it? 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,

Claude 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 is like an executive and leader within my company, right? I'm, it's interesting because as a CTO of a fairly established company, like still obviously a 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. So basically 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 pursue a side quest. I thought like, man, agentic 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 churned out a few hundred thousand lines of code, which is just like insane. None of which is going to production. None of which is accomplished 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, so I can, I can be more specific about a couple of these side quests. Yeah, please do. That I thought would be interesting. So the first one was, so Opus 4-1 was out. This is probably like the beginning of August. And I had the idea. So InplexDB 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 Inplex QL, which is our query language. It 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 PromQL, 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, well, what if the agents could do PromQL, right? So our current version of the database is written in Rust, Influx2B3 is written in Rust. Prometheus and PromQL is written in Go. And I knew from basically historical experience with the Prometheus project that

Prometheus has a very extensive test suite for PromQL that is outside of the, it's actually like they have a whole DSL that's basically. So this text-based thing where they can define data input, the query, and the expected result. 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 back-ends, right? They're probably at this point at least a dozen or two dozen back-ends that support prominence. as a query language. And you can use these tests. 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 have the agent try to create a port of the Prometheus PromQL implementation in Go? over to Rust so that we can have just native PromQL support in InflexDB3. Yeah, 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 Codebase because it's all Apache 2 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 InflexDB, 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, right? I wanted a couple of very light touch points where it could integrate.

And then I wanted all the net new code that is creating to be basically like a new crate within the Rust project. And I gave it this guidance. I 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 cranked in the background on that. And that test suite, by the way, is like, it's like 1100. tests. It's very, very extensive. It covers all of the functionality of PromQL. And I just had a crank on the background. And meanwhile, I have other development work that is my primary development work and then all the other, you know, foundery, executive e 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, like this was all just vibe. coded stuff. Like I gave it the parameters, but I wasn't paying attention to the coded rope because I was like, this is all just like a ridiculous kind of like 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 was like I said, a native Rust implementation of PromQL that's inside the inflex-DB3 codebase where InfluxDB you can set it up and it will act like a Prometheus server in terms of the remote right API. 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 suite. Now, the test suite doesn't actually test the Prometheus, you know, HTTP API. It tests the underlying query engine to see if it, you know, passes those tests. So at that point is like, okay, does it actually work? Because the robot says it works. So I spun up a Prometheus server on my laptop and I spun up, you know, this Influx

D-B server. I mirrored, I set up Prometheus to do remote rights to the Inflict TV server, right? And I set up to scrape the node exporter, right, basic system stats, CPU, memory, disk, all that stuff. And then I set up Grafana and I pointed, you know, a system metrics dashboard at Prometheus. I pointed at InflexDB. I looked at the two. and they were the same. I was like, wow, it actually created a completely compatible implementation of PromQL. And 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. But 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 Codex camp because I was using, I think it was like Codex 5-1 or 5 at that point, right? And I kind of like freely interchange between both Claude Code Code Codex CLI. I mean, I'd pay for both. And I, you know, know at that point I thought 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 or 5 came out then like two days later yeah then GPT 5 2 came out right yeah so basically the week the weekend before Gemini 3 came out I wrote this like lengthy again like lengthy document to share with

engineering team internally as like hey everybody like we have got to figure out how to take advantage of of these capabilities like and 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 have bandwidth for that we can't sign engineers for that. I was like, if you really want to do it, go get Replit and see what you can do. And he created something is pretty interesting. And then we like brought in a separate team to like turn that into an actual like UI product, which we now have. But that's how it started.

And then once I started using Claude code, I told all of our product managers. I was like, okay, get the source code, use Claude code because you don't have to like wait to ask engineers questions anymore and you don't have to wait to ask engineers to do tiny things like you you can just do it right um so i've been very much in the 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 there's definitely been some skepticism but over the last six months it's just been getting people have been adopting it like more and more right so basically the week before jemini three came out i wrote this you know internal post,

I said, 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? We can write features as quickly as we can think of them now.

And basically, at that stage, not everybody believed to 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 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. You got to make the machine, yeah.

Yeah, it's because like my, my thing. 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. Over the next year, all the major AI labs are going to have at least like one or two more releases that are going to raise the bar again. And more of what you, 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 wrote all this like

freaking out about it. And then of course, like three days later, Gemini three comes out and four days after that Opus four or five comes out and two days after that GPT52 comes out. And, you know, I would say at this stage, like most or all of our engineers are, are firmly in the camp of using these tools, but we still don't know all of our process. All of our process is still very much in the old style development process where we come up with requirements, and we log issues, and we do pull 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. So it's a guarantee that you have to gate it on a human looking at it. So to me, like, 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 AIs get too far ahead of me on some stuff I was working on. And I realized, I was like, wait a second, I got to like completely go through and refactor a bunch of this code by hand. 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, particularly when, like, all of this stuff was important before. It's funny, like all the things that are best practices, software engineering before, like, you know, a single command to deploy, single command to run your test suite, having unit

tests, integration tests, you know, all of these, you know, signals and tooling you build out over time to have reliable, you know, software delivery. All of 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. it's 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 could be like, okay, that's good. And I would say the same is true for functionality. I mean, I will say all of my experience is based on back-end 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 that was my first chance opportunity to use something like Playwright MCP to have, you know, Claude, like, go through and hit the browser and try and fix things and stuff like that.

And again, like, it worked insanely well. I was shocked. Like, I had it porting a piece of UI code to try to make it like native as some WASAM app inside the database. And again, like, it did the whole thing. And I'm just, but I'm not going to ship any of this code is the thing. I have all this 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 like something that we actually want to deliver. You're not shipping your prom QL thing? Not right now. What's it missing? What would it take to get it there? So with a with a prom QL implementation, I think the two things that are most important are one. compatibility, which actually, like, I have a high degree of confidence in the compatibility piece because of the test suite that's in the prom-Prom-Prom-Prom-Eas code base, right?

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

engineering leaders and it's like, what engineer is going to support this? You got 60,000 lines of code that wasn't written by you or anybody else in the company, right, is written by Claude, or Claude and then Codex. You're going to have 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. Right. 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 up the agent and start, you know, start iterating, right? Yes. And start investigating just because they do it like it just.

It's so much faster than doing it 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 just say like as a human, but 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 in order.

We've got a plan in place. We haven't got an implementation mandate. We got code samples in place. We feel very confident in our next step, which is actual implementation. But let's pause and do a clarity in blind spots examination. Like, where is that? We haven't thought about this.

What about how it touches that? What about second order 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 to even think about because you're kind of excited. You've got a dopamine rush. You're just going.

you know. Yeah, well, so for example, there's this 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 Claude to make it. And I didn't actually then take the time to go through and, like, refactor.

a bunch of other spots in the code that kind of were impacted by the change. So we got a few more weeks down the line and 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. And last week, you know, we had multiple engineers, myself, 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 basically by 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, slop machine, hoping, you know, hoping for manna from heaven to come down. And triple sevens. Give me. Give me.

gave me a need. Right, exactly. And the problem is, like, none of us were actually getting anywhere. And I was like, okay, I'm just going to pull the plug on 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, of vived 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.

Right. But still, it's 60,000 lines of kind of vived up code and an engineer has to support it. This is Russ code too, right? Yeah, yeah. Not that it's a bad code, but like Rust is inherently hard. And so if you got 60,000 lines of even harder code than Go code is a little easier than Russ, for example. Yeah, it's like, if, there's a failure, then and the AIs can't actually solve the problem, then an engineer has to

dig in and get deep with it, whatever. And it's like, how do you, how do you determine, like, what pieces, what things you want to support at that level, right? Because we only have so many, like, support tokens, like 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 it, you know, 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 98 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 test out these different scenarios and stuff like that. I think that's going to become a lot more relevant for engineers this year.

They're going to spend a lot more time. If they actually want to get the benefits of, you know, agentic 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 probably like 10 different files in the code base or more. And it spanned across, you know, maybe like over 100,000 lines of code.

But when you start up Claude or Codex or whatever, they won't read an entire file if it's more than whatever, like 2,500 lines. 25,000 lines, yeah. No, 2,500. Oh, 2,500. It's like 25,000 tokens.

There's like some sort of number that 25,000, I think is a number in my extract. Yeah. I mean, 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 leads to, again, this is just my theory of, like, I think, like, the result isn't as good because you're only get a sampling of the thing. And basically it doesn't have the context it needs to make good choices. So I still think you need a lot more 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, you break them up ahead of time. You make clear what the invariance of a system are and what the expectations are, and 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 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 database running. Some of them are like black box signals that are 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 every single 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 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 Elastic Search for Search. It's a mess. Well, our friends at Tagger Data looked at this and said, what if 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 glue code. The database essentially becomes a tool your agent can wield safely. Then there's hybrid search. Tagger Data merges vector similarity search with good old keyword search into a SQL query. No separate vector database, no elastic search 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 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 why we've been doing it 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 Tiger Data at Tiger Data.com. They've got a free trial and a CLI with an MCP server. You can download to start experimenting 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 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 can even, 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 in code review and code quality. the plethora of code we can create. And that's going to become the bottleneck. And then obviously 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 there 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 is this 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 for it. Oh, yeah. It's just easier than ever to create that kind of stuff. Do you want to test it yes or no? And I was like, let's test it.

It's like, yes, can 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's actually like it makes the test pass but not because the code does what it's supposed to do but because it changed the test expectation. So I still think you have to like keep your eye on them.

Yeah, 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 going to be kind of exciting and fulfilling to create a qualitative analysis tool that can be used across the... I would agree with that. But I don't think that opinion is widely shared by software developers. Really? across the industry.

Yeah. I mean, I think the problem is like, I, 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 those people, it's like they don't want to do that. That's not why they became software developers. They don't want to like spend their time validating what somebody else's code is doing. Most people have you talked to them, like what's the thing they hate most about their jobs

in terms of like being software engineers? They 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, you included code review in that because you didn't mention anything about code review at the certain point when you have so many validation tools you know do you do randomized testing like you 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 a bottleneck whereas if you have your 1100 integration tests and then you add on to that thing after thing after thing to verify at a certain point do you need to do code review i know today you do but 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 a 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 not all humans are created. are 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.

Code owners kind of thing. But even that, I don't know that we'll get there because the problem is you have to, you have to build up trust in the tools over time. And really it depends on your risk profile, right? Like, 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, yeah, we'll just, we'll just wave it through. And that's fine.

And that's what you're seeing, I think, out in there in the world is like, you know, people are just creating fun things for themselves or whatever. Zero users, you know, demo it off. Nothing to lose. Yeah. Yeah. Yeah. I totally get that.

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 wayside. I always like, I have a mix to. 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. Or they're reviewing it for like stupid like syntax stuff or whatever. It's not actually like reviewing the big picture. I'm like, does this actually do what we want to do? Not everyone, but like at some point, like sometimes, yeah, even for me, like not all my code reviews are great.

Like some of my code reviews, I'm just like, it's on this day. I'm just like, let's just get this through. Yeah. You know? Have you ever seen the meme where it's like you submit like a 10 line change and there's like 100 nitpicks on your code review? And then you submit like a 3,000 line edition and it's like LGTM, you know, merge it. Wave it through.

Yeah, exactly. I get that. I think there's some truth to that. Yeah. I mean, I think it's tricky because like for better or worse, 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 wrote this the other day,

it's like for people who were like, maybe as Andre Carpathie, 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. That's weird. I guess I'm of 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 win at the end of it where you're like, you know what? That's a well factored thing that works as a core. And I built that. I totally love that. But I think of the end and I'm, but I'm okay not doing it too. Like I actually kind of just want the end result. And so I guess 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're talking about 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 for that because I agree with you. I think developers love building internal tools for themselves and stuff like that. I think one of the reasons for that is because there's 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 like your enthusiasm degrades because you're just like, do I really want to.

I really want to struggle with this and get this through. You procrastinating for a couple of days, maybe a week or two. Who knows? Maybe you don't ship it at all. You go work on some internal tool instead, you know? Exactly. Yeah. 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. I don't have to do all the extra stuff. Yeah. Yeah. So, well, 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, is still important for somebody to sweat the details

and make sure everything is smooth, works as expected and all this other stuff. The idea of editing and curating and fine-tuning and having taste is 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 code. It was around helping developers who write the code to understand what to build for the company.

I think those folks are in well positioned to become engineers, wouldn't 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 their best lives because they can actually do stuff. Before they had to wait for an engine, they had to ask, you know, try and sequence everything through the engineering team and wait for an engineer. Now they can just like do things.

The problem is whether or not that actually anybody will accept that and get to production. But I think also like engineers who are like product 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? Much more time. It's crazy. What I think is possible and what, I mean,

I have a pretty, I've a lot of faith that actually like there's still going to be a couple of 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, as you so eloquently put it in your blog post, do you think that's something that every engineering team is going to reinvent inside themselves as they reinvent themselves?

Or do you see vendors coming in and solving these problems? Or do you perhaps see the big model providers, the open AIs and the Anthropics, actually just leveling up their tool so much that it is the machine at certain point. What are your thoughts on, on like, where does this reinvention 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 that's designed for agentic use or they're actually working with the APA, and they're creating their own custom agents to do things within their own infrastructure, to do things within their own code-based and their own product delivery cycle. There are also a bunch of startups who are trying to build these things. The most obvious ones are like the code review startups and all that kind of stuff. And then or on all the all the way opposite side of the spectrum, like pure like vibe-coded

application builders, right? Like lovable and replit 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 are able to process a larger context, ideally, hopefully a larger context. I feel like it's been a little while since we've gotten a good upgrade there. But a bigger context, but they're also going to continue to build agenetic tooling, right? just because it's so obvious that that's what the people want. Like, you know, at this stage, like, you know, Claude 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 a bunch of startups trying to create stuff. But I think within two or three years, maybe a lot of that gets eaten by, you know, anthropic, Google, an opening eye, right? Hence the SaaS software apocalypse, you know, that's kind of happening. Well, you got to feel good as an infrastructure provider at this point, right? Like Influx TV, that's infrastructure. So you're, yeah.

You guys are sitting pretty, right? I mean, I feel good in the sense that so much uncertainty. I mean, I'm generally an optimist. Okay. And I, like, I'm, like, I'm just excited about all the stuff that's currently possible and I just 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, growth cycle, whatever, right? Because what 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 an annual conference of the thing you do. A lot of workshops that you participate 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 in the holiday. But the idea I had essentially then, which I still have now, which is, you know, before early days of InflexDB 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 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. It was like, so that's how you win, right? is you focus on developer ergonomics, you make something easy 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 funny.

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 you should be designing for agent ergonomics because that's what's creating the software going forward. And he used as his example, he's been lately writing a bunch of go code,

but he doesn't write it and agent writes it. He's never been a go 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 InflexDB, 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 WOSM. Wasam is great because you can put a WOSM runtime in the database. You can sandbox it. You can limit the number of CPUs, the amount of RAM. You can limit specific calls that it can make. So I basically prototype that. So we may experiment with that over the course the next year. I don't know.

Again, that's not getting shipped. That was a side question to see what's possible. I think what's happening too, though, I mean, you still have developers right here. I mean, developers still kind of. care about CLIs. They still care about APIs. I 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. And the only reason I bring this up is because I'm like just laser focused on this idea that platforms like yours need to pay great close attention to

the CLI. It's your CLI is essentially a gateway to your API, right? It's the framework the developers use to implement and utilize that. And if you're paying close attention to your C-Line, how that's engaged with by a developer that's augmented by an agent, we still have developers, they're still coding by hand, they're still learning things, there's still people leveling up on InflexDB and how it works and how they can utilize it. But you're also going to have agent-enabled developers who are writing Go-Co

for the first time, but they're a Python developer, you know what I mean? And we need to pay close attention to those interfaces and agentify or agendify, you know, agendify, you know, agendify, I suppose is probably the right word 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

couple 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 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 or 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. Sometimes we've tried to do that stuff and other times we've said like, no, we can't do that. I think all the agenic tools and coding what that enables is it makes it just much, much easier for end users to create all of that software to basically 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 of that I believe is like probably way too forward looking

because that's not where we are. Like most enterprises are, you know, if they're using agentic tooling, agentic software development and stuff like that, my impression is that most enterprises are doing it just to make an individual software developer a little bit more productive, which is why you 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 it's 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 that builds the machine right the machine is basically the software software factory the 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 you again And I think you'll see a real difference between engineering organizations that are delivering at that kind of velocity versus once it aren't. 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? Yeah. Yeah. You will see big, like, infrastructure failures or, you know, production failures and stuff like that. And where it will be, my bad. Maltbook, yes. Yeah, Maltbook.

For OpenClaw, because it's not MaltBot anymore. That's right. No. That was so last week. So, like, that was like, yes, last week. Forever ago. Yeah. So, yeah, I don't know.

It's wild. It's crazy times. Are you thinking about this from a C. level only on how you enable your engineering department? Because like the question that I was trying to pose there was how do you, how does your product change so that your tooling enables the users better, not just your engineering department better? Like how do you think this changes how you interface with your customer

and enabling the users of influx? I mean, a lot of it is still the same. Like, well, you know, we've already put like Ask AI features in our documentation website. And we have like, we're starting to thread this through our support organization. So what I expect is like more and more tooling to allow AI to basically just 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 in FlexDB 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 C.

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 innovate in that area faster than, you know, the big AI companies, 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,

and FlexDB and better at using our stuff, as long as we have proper documentation in markdown files that agents can consume command line tooling that the agents can use. I'm not super bullish on MCP just because at this stage, if I can have the agent use a CLI, that's what I use.

Yeah, 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 the cases, It's just like, I want to just bol-sh 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 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, my guess is the, if you, 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 humans accessing these things

So I feel like, you know, just like I said, like 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, 100 or 1,000 humans accessing the thing, you also have 100, 1,000, 10,000 agents accessing it and doing it much more frequently because agents can work faster than humans can. How has collaboration changed inside your org 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 a lien? How has your, I guess, day-to-day collab around what to build and how to build it and maybe even pair programming. You know, 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 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 or work. We also created, you know, Slack channel for like AI stuff where it's like, okay, share your learnings with, you know, the whatever tools you're using. And recently we've 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. 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. We have our 24 by 7 support org.

Things come in. If they can answer it, great. If they can't, they log an issue in a specific GitHub repo that we have called EAR, engineering assistance request, right? And basically that gets logged and then an engineer looks at it and whatever. So what we haven't done yet is built 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 skill development stuff around those specific kinds of workflows, right?

Support thing comes in, do this. If you're trying to do this in a production cluster, do this, right? The kind of stuff where it will like preload as a, you know, context that's important in a set of tools and just make it easy. 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. Yeah, you're trying to figure it out. Yeah. Yeah. Yeah. 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 coder 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 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, do 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 Canvan board and whatever. So it's like anything you're 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 if 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. Pretty easy 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, thousands. a 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 a brief 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 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 a pair 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. 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 V1 of the product, the hosted version. in the on-prem version. There's an engineering team that supports V2.

There's an engineering team that supports the iteration of V3 that we currently have hosted. There's an engineering team building. This new version of V3 that we have is an on-prem product and also hosted in AWS. It's a time stream for InfluxDB. It's actually like an AWS first-party product. So every team is like kind of a little bit different

in terms of what the scope of their responsibilities are and what they care about. It's tough times. I mean, because you, I was going to ask you too, like you just mentioned it, but your team size, because we just had a conversation with Amel, the same one of our past participants slash animal in 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 back in the days of getting real, which was 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 a designer. I forget the exact prescription, but it was somewhere around four or five was like loosely there. And then Jeff Bezos was famously calling the idea of a two-two-pisa team, which depending upon the, you know, your appetite for pizza, as 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 Bezos had potentially a larger team in mind, like up to like eight or ten. 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 100x more code. And so any, if you put more than two to maybe three in that kind of sphere, you got now 300x 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 superstar you are in, you know, what your sleep was 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, there's something you go wrong in the, in the car pole line dropping off your kids. Like all these things impact our ability to comprehend our day to day. And so I feel like any more beyond two, maybe three is probably pushing it.

Like I wouldn't do a four-person team anymore. Probably like a two person. It's probably pretty solid. Yeah. I think two or three, mostly just two, though, where like you can almost do like a PM and an engineer, right? That kind of thing. Yeah, you need accountability 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 rough structure 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, does it 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'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 times 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 will 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. 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 the 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 familiarize themselves with the codebase, whatever. I think the same is going to be true for people taking advantage of agentic tooling, which is the agent lands in an organization and you have to build tooling, build documentation, whatever, to make the agent effective. The difference is with hiring humans, you hire one human and 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's actively has bounds on and sandbox. And like if it solves it, cool.

If it doesn't solve it, then no harm, no file, right? To spend money on tokens. And it's now it's a cost consideration, not so much a, you know, it's not the worst. case solves the problem, right? Like, it's a good thing. Well, so for, 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. I mean, I told the

exact, I was like, look, like everybody inside the company has a superpower that people outside of InflexDB do not have, right, which is they have access to the code base, the, you know, proprietary code base that we have that we sell our customers. If you pair that with like ClaudeCode or Gemini CLI or Codex 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 a customer, we are able to actually answer that within minutes based on agents doing the work. And you still need 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. And all the documentation and internal knowledge base that we have, either in, you know, support or previous support requests or issues that we have in closed source repos or documents, mark down files and code. Yeah, they can connect a lot of those dots if you have that corpus of past ticket history, regression history, customer use case, even if you're pending the versions of Inflex DB 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 ask, answer support quick. ticket, you know, and 10 next to time. You know, like you just now solve their problem so much quickly. That customer is now more enabled. They have more faith in you and more trust in you. And that's a good thing ultimately. And I'd be remiss not to ask you this question before we begin to tell off the show

because we've talked to you in the past about your thoughts on open source licensing, open source in general. You've been a big believer and contributor to. and champion of open source in your career. And I'm really curious how 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

and 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. and 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 as performant and as battle-hardened as something that's been developed over the course of years. So I don't think that changes. I think as the AIs get better and better, like the scope of things that they can one-shot and just give you improves. So like, you know, in the various like code ecosystems like NPM or crates or whatever, there's this huge long tail of libraries where it's like, you know, a few functions or whatever.

Like those, the value of those is like gone, 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 and issue a PR. So, you know, maybe that gets better in GitHub actually add some tooling. 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 the 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 going to want to adopt soft, you know, well-developed software rather than just try and write it from scratch. right like you know who is 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 it's not standards either yeah I think a lot of that is like you want some of those chrome developer tools especially some of the headless Chrome 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 maintain 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 if it's like, you know, if you have a social network and you.

you want to open source these libraries and 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 it's just like there's, it's too easy for anybody to pick up the source code and then like run wild with it and do whatever. Yeah, if you have good docs, a good API and a good CLI and open source, Well, you just give them all the keys to your kingdom, basically, like the age, you can scoop all that up and do most of it for you.

What you do by is, you know, obviously the support mechanism, maybe the uptime, maybe just the burden or the responsibility of uptime. Or if it crashes or backups, it's just one more surface here 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? We're already doing 50 other things we're doing over here, a hundred other things. why not add one more thing to it if it's that important? Yeah, I don't 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. 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. These are baseball cards or stats. Right. And 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 closed 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 very complex pieces of software that are very good, that 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 developer open source project. Yeah, I just saw 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. But I've heard that from other people too. I actually haven't talked 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. I mean, he's getting slant. Before the ASF, he was getting slammed just because those 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, full request, not less. Yes. Yeah. Kind of the backwards, the backfire of even email, the more you answer your email, people respond back and then they have more email. That's right. Yeah.

These things compound. Stoke in the fire. That's right. That's right. Yeah. Yeah, it's interesting. What makes someone want to contribute more to ghosty, for example? Like what's the ground swell there?

Why is he getting so much? or has he in a data with change or suggested change. I don't get it. Why? Because you get your pet feature. You want your feature in. Yeah. And it's easy to have an agent coded for you.

And you don't have to put a thought into it besides, well, I tested it real quick and it works. So, you are opening PR, start advocating for your little pet feature to get in. I mean, that's my assumption. Yeah. I think like one, it is 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, the calling card to be like, oh, yeah, I got a PR landed and ghosty. And everybody knows this project. Yeah, yeah, there's lots of motivations. Now, the curl bug bounty actually was ended recently because too many low value PRs around bugs.

And, you know, because they're offering real money if you find certain things. And so Daniel Stenberg 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 co-gen up something and hopefully get some money. I mean, people are going to do that all day. Yeah, I mean, what angle could be, you know, set an AI loose on that bucket and just say, give me all the cream off this, of 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, or it's mostly noise, I mean, if 1% was signal, would you still want the 1% given?

Yeah, does it become like email spam filtering, right? Right. Yeah, exactly. Robots check another robots work, you know? Oh, gosh. That's definitely where we're headed. We're in a wild world. What's over the horizon for you guys?

What's happening in influx that is, you know, this show goes out next week. we got a week's time between now and then. Is there anything particular 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 in the 3.9 release of InfluxDB3. 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're hoping people to test out, basically that we'll enable wide sparse tables, many, many thousands of tables like we had in V1 and V2 and better query performance and a bunch of other things.

So that's kind of what we're focused on right now is 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. Maybe some PromQL?

We'll see. We'll see. I'm not making, not making promises on that one. Because it's, it's easy enough to, 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 then you'll solve the problem, though. At this stage, it's like, 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 give them a good experience. We're trying to be a little bit more measured these days.

I wonder if you could 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 into production, but we need some willing participants, so to speak, some testers, some production testers

that are willing to understand there may be warts and we we don't know we're just not sure yet i don't know just think out loud here how has your move 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 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 like that. It's able to do stuff. You can ignore dead code if you need to. It's like that that code is on purpose. Okay, I'm leaving it

there. It's a future feature. Just shut up about it. Compiler. No, it's good. It's good to tell the agent, do not, you're not allowed to use the allow dead code flag. Oh, you can't do that. Well, see, I'm not in prod with this stuff. I'm just playing with this. So I let it go. And in certain cases, like I got like five dead codes in one of my projects. I'm like, that's cool with me. I know what they're there for and I'm okay with it. Fair, fair. Yeah, I love the, I love the clippy lints.

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 we 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 I feel like inside InfluxDB, there's going to be some serious machine building going on. And I'd love to know where they get in a year's time. But other than that, no, I don't think so. I agree. The machine building. And when you officially launch PromQL, I feel like you can come back on here and celebrate that with us. Like, what was the journey to take a fully AI generated feature? you've never thought of to use the test suite to build upon.

I mean, that's, I'd love to, like, look back at how you went from not fully, full conviction to full conviction. Yeah. Yeah, yeah. I don't know. It's going to be an interesting year. Like, is that all the, all the engineering leaders I know are kind of like having the same struggle internally 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. We'll see, Paul. We'll get you back on sooner the last time, though. We'll see what happens.

Yeah, maybe I'll have something interesting to say in another three to six months. Who knows? Who knows where we'll be? Who knows what the A&S will take him off our plane? Who knows? Who knows? We have lots of free time. All righty.

Thanks, guys. Thanks, Paul. Thank you. All right. That is our change. vlog interview for this week. Thanks for listening. And thanks to Paul for stopping by the show again. So much harder in 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 from Piano Man. They're sharing a

drink they call loneliness, but it's better than drinking alone. Okay, that got somber there in a hurry. Let's thank our partners at fly.io and our beatmaster. Breakmaster cylinder. Okay, that's all for me. This one's done. But come back on Friday when we are joined by our old friend, Canon, a conversation that's supposed to be about Python and stuff like that, but starts out with a deep dive on. Star Wars. Talk you then.