Welcome friends, I'm Jared and you are listening to The Change Log. Interviews with the hackers, leaders, and 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 by getting back. 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 getting back actions.
That's great. It's all great. Until. Yes.
Until your builds start moving like molasses. Getting 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.so to do all of our builds so much faster. NameSpace is like GitHub actions, but faster and 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 short of 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 GitHub actions with almost zero config. It's a one line change.
So you get speaker builds, you get to 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. Like it 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 agentic coding, et cetera, et cetera. How you doing? I'm good.
Yeah. I'm really like most developers. I'm excited to talk about agentic coding stuff. It's highs and lows really on the daily, on the weekly, minute by minute, 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 I got a little over my skis and let the agents do, you know, run a little hog while without enough supervision. And then I had to like dial it back and, you know, yeah, fix things myself. So I'm in the middle of one of those dial it back situations right now, but so writing code is I was 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, right?
Like this could be faster. And, you know, the biggest thing is obviously this has all changed within the past year. Yeah. You know, my experience was I used to start using chat TPT when four came out in March of 23 and started using these tools more for coding along the way with like co-pilot and all these other things, an IDE completion, but I would say everything like really, really changed last year with 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 so my experience of, you know, feeling like agent coding is an experience, which I think is qualitatively different than, you know, completion in 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 would like 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 documents 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 Cloud Code. Like if you wanted to use Cloud 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 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, you know, our days as developers of like hand writing code were extraordinarily limited. And that at that point, basically with the release of Opus 4.5 and GPT 5.2 codecs and probably Gemini 3, but I didn't, I don't really use Gemini that much. But codecs 5.2 and Opus 4.5 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 was 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 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 based on like New Year's Eve, or 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 like a larger, 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 could produce so much code, like you could 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 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, 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 in June, July, I was 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. And I thought like, man, 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 churned out a few hundred thousand lines of code, which is just like insane. None of which is going to production. Is it 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, some influx to be as a time series database where 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 influx 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 prom 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 prom QL, right? So our current version of the database is written in Rust and what to be three is written in Rust. Prometheus and prom 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 prom 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 this point, at least a dozen or two dozen backends that support prom 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, how the agent try to create a port of the Prometheus prom QL implementation in Go over to Rust so that we can have just native prom QL support in what's going to be fun. Right? Like, okay, I have 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 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 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 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 a 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 then 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 prom QL. 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, foundry, executive-y kind of stuff. And it got really, really far, but it couldn't quite finish it. And then codecs, GPT-5 and codecs came out.
And at that point, Opus 4.1 is kind of like stuck 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 code it wrote because I was like, this is all just like a ridiculous kind of like test. And then codecs came out and I had to pick it up and it was able to take it the rest of the way.
And when it created, it's like I said, a native REST implementation of prom QL that's inside the InflectDB3 codebase where, InflectDB, 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 suite. Now, the test suite 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, 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 this InflectDB server and I mirrored I set up Prometheus to do remote writes to the InflectDB server. And I set up to scrape the node export, right, 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 at Prometheus, I pointed in InflectDB, I looked at the two and they were the same. It was 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. 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 to 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 codecs 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 three came out.
So basically the ordering was Gemini three came out, then Opus four, five came out, then like two days later, yeah, then GPT five, two came out, right? Yeah. So basically the week, the weekend before Gemini three 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, 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 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 cloud code, I told all of our product managers, I was like, okay, get the source code, use cloud 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 Gemini 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?
We can write features as quickly as we can think of them now. And basically at that stage, not everybody believed that, but I firmly believed it then, 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, it's because like my thinking now is like, that's still the case. And then so I wrote this whole thing and I was saying like, OK, 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 what more of what was impossible will be possible, right? Because that's the whole argument. It's like, oh, yeah, it's OK for code completion, but nothing else.
Oh, yeah, it's OK to write a single function, but nothing else. Yeah, it's OK 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 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 the camp of using these tools, but we still don't know all of our process, all of our build 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 as 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 myself.
And rewind a couple of weeks worth of stuff. So yeah, I 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, a single command to deploy a single command to run your test suite, having unit tests, 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 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 do something like playwright MCP to have, you know, clod, 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 a WASM 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 did like, 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 like something that we actually want to deliver. You're not shipping your prom QL thing?
Not right now. What would it 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, like, I have a high degree of confidence in the compatibility piece because of the test suite that's in the problem for media's 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 for media 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 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, OK, 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 for agents 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 yourself. Exactly. Exactly.
There's a lot of clarity and blind spots in there, too, that 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, 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 like, OK, I know we're sold it on this. We've done all the investigation. We've got the spec and where we've got a plan in place. We've even got an implementation mandate.
We've got code samples in place. We feel very confident in our next step, which is actually implementation. Oh, we don't know about this. What about how it touches that?
What about second effects over here? It's like, OK, 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, I don't mean rush. You're just going, you know. Yeah. 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, OK, 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 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, 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 basically by like last Thursday, I was like, man, we're just like spinning our wheels here. That's like everybody is in the AI casino pulling the levers on the AI slot machine slot machine, hoping, you know, hoping for a man from heaven to come down and give me give me a knee. And probably it's like none of us were actually getting anywhere. And I was like, OK, 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? Cause 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 vibed up code and an engineer has to support it. It's a rust code too, right? 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 because we'll use them than Russ, for example. Yeah, it's like if there's a failure then and the AI can't actually solve the problem, then an engineer has to dig in and get deep with it and whatever. And it's like, how do you, how do you determine like what piece of, what things you want to support at that level, right?
Cause we only have so many like support tokens, like engineering support tokens that we have to hand out, right? And the thing is like, hey, I 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, yeah, but like how do we, I guess, you know, the question for me that became like, how do we avoid this kind of thing?
So one, like is 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.
But like, I got my start as a contract, like tester on Windows 2000 back in like 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, 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 span across, you know, maybe like over a hundred thousand lines of code, but when you start up clogged or codecs or whatever, they won't read an entire file. If it's more than what are like, 25,000 lines.
Yeah. No, 2500. Oh, 2500. It's like, it's like, 25,000 tokens or like some sort of number, 25,000 is a number.
It might travel. Yeah, definitely. I mean, definitely, like, so any code file that's like 20,000 lines of code, it will not read it. 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 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. Uh, so part of this is code files that just you don't like code files get that big, right? You break it, 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, but essentially like run on the over 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, from, 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 elastic search for search. It's a mess. Well, our friends at Tiger Data looked at this and said, what are the database just understood agents?
That's agent to 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 running fragile blue code. The database essentially becomes a tool your agent can wield safely.
Then there's hybrid search. Tiger 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 that 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 and 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 copyright 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 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 to because like you at influx data building influx DB 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 of view 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 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 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 for. Yeah. It's just easier than ever to create that. Do you want to test the yes or no?
And I was like, let's test it. That's like, yes, I complete that and enter, please. Right. But again, like, 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 to keep your eye on them. Yeah, a hundred percent.
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. Anyway, this is actually going to be kind of exciting and fulfilling to create a qualitative analysis tool that can be used across. I would agree with that.
But I don't think that opinion is widely shared by software developers to the industry. Yeah, I mean, I think, 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. But 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, 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, 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 include a 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 a 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, 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, uh, 70% of the code doesn't have to be reviewed by a human. It's enough to have it reviewed by the AI, right? 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 were created or focused on the same areas. So it's not just it needs human eyes on 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. Cause 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.
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 there in the world is like, you know, people are just creating fun things for themselves, whatever, zero users, you know, demo it off. Nothing to lose.
Yeah. Yeah. I totally get that. As a software developer, who hates code review and 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 reviewing it for like, stupid, like syntax stuff or whatever. Like it's not actually like reviewing the big picture. Yeah. What 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, ah, let's just get this through, you know, have you ever seen the meme where it's like, you submit like a 10 line change and like a 100 nitpicks on your code review and then you submit like a 3000 line edition and it's like LGTM, you know, merger. Leave it through.
Yeah, exactly. I get that. I think there's some truth to that. Yeah.
I mean, I, I think it's, 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 who wrote this the other day, it's like for people who were like, maybe it's Andre Carpathi, this is 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 likes software engineering because they like the details of writing code, those people are kind of hosed because, you know, those days are, are, are limited at best.
Right. Yeah, it's weird. I guess I'm, I'm two minds because I've, I've been both people. I, 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 most and 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, do I really want to struggle with this and get me through? You procrastinate for a couple of days, maybe a wife who knows. You don't ship it 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, 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, you're still still important for somebody to sweat the details and make sure everything is smooth works is expected and all this other stuff. The idea of editing and curating and fine-tuning and having taste is like, oh, the utmost importance now.
And like you said, if you have engineers who really enjoyed 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 PM's 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-position to become engineers. When you say, yeah, I mean, I, 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 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? What much more time? It's crazy.
Yeah. What I think is possible and what, I mean, I, I, I pretty, I have 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 and 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 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 opening eyes and the enthalopics actually just leveling up their tool so much that it is the machine at a certain point? What are your thoughts on, on like, where does this re-engine 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. 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 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 that 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 going to be happening.
Well, you got to feel good as an infrastructure provider at this point, right? Like infrastructure. So you're, you know, you guys are sitting pretty, right? I mean, I feel good in the sense.
So much uncertainty. I'm generally an optimist. So 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 influx DB. 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, conference, I think you do a lot of workshops that you participated in and have. So you're educating folks to use influx DB 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 influx DB, 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 InflexDB, 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?
As 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 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 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, well, it was great, because you can put a lot of time in the database, you can sandbox it, you can limit the number of using the RAM, you can limit specific calls that it can make.
So I basically prototype that. So we may experiment with that with the course next year. I don't know. Again, that's not getting shipped.
That's not that was a side question to see what's possible. I think what's happened to them, and you still have developers right here. I mean, developers still care about CLIs. They still kind of route API is I think your, 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 to the gateway to API, right? It's the frame where 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, but you also have agent enabled developers who are writing go for the first time with their Python developer, you know what I mean? And we need to pay close attention to those interfaces and identify or agent, you know, identify as opposed by 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, coupled with your great API that's, you know, got all the right kind of tests and all the backing behind it and 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 could 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 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 the agent tools and coding, what that enables 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 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? 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 they're, 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 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. You can't, 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 you, yeah, yeah. You will see big like infrastructure failures or, you know, production failures and stuff like that. And where will be my bad, multiple book, yes, multiple book for open claw, because it's not multiple anymore. That's right.
No, that was so last week. Yeah, so like it was like, yeah, 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, 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, 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 are 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 a 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 bolt 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 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, a hundred or a thousand humans accessing the thing, you also have a hundred thousand, ten 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, are you practicing lean? How has your, you were, I guess, day to day collab around what to build and how to build it and maybe even a 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 seven support org, things come in. If they can answer it, great. If they can't, they log an issue in a specific, how repo that we have called EARS, E-A-R 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 skilled development stuff around those specific kinds of workloads, right?
Support 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 as a set of 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 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, 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 faster, you probably need more feedback. I 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 riff on that yourself to discover and learn and then define and feel secure in it, but then also share it and get feedback? Because 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 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 or to track 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 you. You can do that too.
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 we'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 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.
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. It's a time stream for InflectDB. It's actually like an AWS first party product. So every team is like kind of a little bit different in terms of what discover 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 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 NGS 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-pizza team, which, depending upon the, you know, your appetite for pizza, it's like a four-person team in my brain, right? And so I think I will see, do you agree with that? Like, it's probably four people. I don't know.
I think Bezos had a larger team in mind, like up to like eight or 10. Okay. Maybe. 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. And that's all. 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 supersall 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?
And you know, there's something wrong in the, in the carpool line, dropping out for kids, like all these things impact our ability to comprehend our day to day. And so if like any, any more beyond two, maybe three is probably pushing it. Like I wouldn't do a four person team anymore. I don't like a two person, it's quite 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, any side quests, 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 agent 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 codebase, whatever. I think the same is going to be true for people taking advantage of 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 the, 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 spend 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 way that we're building tooling that is infrastructure tooling and command line tooling so that both humans and agents can do more verification of does the software do what we expected 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 spending on tokens and it's not a, it's 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 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 basically told the executive team, I was 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, you know, proprietary code base that we have that we sell our customers. If you pair that with like Cloud Code or Gemini CLI or Code X 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 or 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 InflexDB 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 some more quick ticket, you know, and text time, you know, like you just now solve the 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 on it, ultimately. And 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 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.