# Agentic Coding Shifts Focus to Verification

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-02-11

## Transcript

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 changelog.
Let's do it.
Well, friends, I don't know about you, but something bothers me about GitHub Actions.
I love the fact that it's there.
I love the fact that it's so ubiquitous.
I love the fact that agents that do my coding for me believe that my CI CD workflow begins with drafting Toml files for GitHub Actions.
That's great.
It's all great.
Until, yes, until your builds start moving like molasses.
GitHub 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 casts your dependencies, your Docker layers, your build artifacts, so your CI can run super fast.
You get shorter feedback loops, happier developers because we love our time, and you get fewer.
I'll be back after this coffee, and my build finishes.
So that's 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.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 Influx DB, 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.
Uh definitely, like most developers, I'm excited to talk about agentic coding stuff.
Uh it's uh 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.
Um, 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, yeah, fix things myself.
So I'm in the middle of one of those uh dial it back uh situations right now.
But you're writing code, is that what you're saying?
You're actually writing some code, right?
Yeah, 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 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 I'm slow, all right.
Like this could be faster.
And yeah, the biggest thing is obviously this is all changed within the past year.
Um, my experience was I used I started using ChatGPT 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 and 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 Claude Code around the same time.
I know people at that point were using cursor, and their clawed code was released in what, like February or March or something like that.
But so my experience of you know, feeling like agentic coding as 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 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.
Um, 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, uh, 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 clawed code.
Like, if you wanted to use clawed code without you know paying for individual tokens, I 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 uh 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 handwriting code were extraordinarily limited, and that even at that point, basically with the release of Opus 4.5 and GPT 5.2 codex and probably Gemini 3, but I I didn't, I I don't really use Gemini that much.
Um, but Codex 5.2 and 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.
Um so that this is basically like you know, the end of last year, the first week or two of this year is I've 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 cloud codes and codexes, and I just need to figure out how to get all these things working to maximum effect, 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 Amdel's law about like performance optimization, where it's like if you have this complex system and you optimize 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 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 it 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, clawed 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?
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, right?
So basically 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 have and pursue a side quest.
And I thought, like, man, age 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've 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 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 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 401 was out.
This is probably like the beginning of August.
And I had the idea so InfluxDB 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 you know version of the database we have now, we support InfluxQL, which is our query language that looks kind of like SQL and we support SQL, actual standards compliant 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 what if the agents could uh could do PromQL, right?
So our current version of the database is written in Rust.
InfluxDB3 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 it's actually like they have a whole DSL that's basically this test text-based 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 all the other cloud provider specific Prometheus backends, right?
There are probably at this point at least a dozen or two dozen backends that support PromQL as a query language, and you can use these tests.
So basically, like there's a bunch of Go code as a test runner, and there are all these tests.
Well, the agents do a lot better job if you give them a verification signals that they can use.
So I thought, why not try 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 InfluxDB code?
That makes sense.
Right.
I was just like, okay, I had a rough idea of how I wanted to look.
I said, first go look at the, you know, I checked out the Prometheus code base because it's all Apache 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 I we can put into Influx DB, 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 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 go 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 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 PromQL.
And I just had a crank on the background.
And meaning, meanwhile, I have other development work that I'm doing is my primary development work and then all the other, you know, founder E, executive E kind of stuff.
And it got really, really far, but it couldn't quite finish it.
And then Codex GPT 5 and Codex came out.
And at that point, Opus4.
And then Codex came out and I had it pick it up and it was able to take it the rest of the way.
And basically what it created is like I said, a native Rust implementation of PromQL that's inside the InfluxDB3 code base, where InfluxDB 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 uh APIs are there for you know 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, I was like, okay, does it actually work?
Because the the robot says it works.
So I spun up a Prometheus server on my laptop and I spun up, you know, this InfluxDB server, and I mirrored, I set up Prometheus to do remote rights to the InfluxDB server, right?
And I I set up to scrape the node exporter, right?
Basic system stats, uh CPU memory, disk, all that stuff.
Uh and then I set up Grafana and I pointed pointed a you know a system metrics dashboard at Prometheus.
I pointed at InfluxDB, I looked at the two, and they were the same.
I was like, wow, it actually created a completely compatible implementation of promptl.
And I it was this was like 60,000 lines of code, and I didn't write a single line of it, like not a one.
Like and I didn't really, other than the like I said, the 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 I I finished that in like mid-September.
I was just like, this is crazy.
And then of course, at that 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 at that point, right?
And I kind of like freely interchanged between both Cloud Code and the Codex CLI.
I mean, I pay for both.
And I, you know, like at that point, I thought it was pretty amazing.
And by, I would say, it was funny, like the week before Gemini 3 came out.
Uh so basically the the ordering was Gemini 3 came out, then Opus 4.5 came out, then 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 my engineering team internally.
I was like, hey, everybody, like we have got to figure out how to take advantage of these capabilities.
Like, and and I would say one of the things we've seen internally within InfluxDB is every product manager has gotten on these tools and they've 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 assign 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 that was 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 have like wait to ask engineers questions anymore.
And you don't have to wait to ask engineers to do tiny things.
Like you, you could 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 was 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 K3 came out, I wrote this you know, internal post.
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, and of course I believe it now.
But it's like the problem is we can't review that code quickly.
Like, there's no like every engineer can now produce a hundred times more code than they could before, but nobody can take the time to review all that code.
I was like, so we have to start thinking about what we can do here, and it's not just like code review, right?
It's it's more like product experience supporting all of this stuff.
And again, like I don't have the answers for this stuff right now.
That's why I wrote that post like build the machine that builds the machine.
Yeah, is because like my my thinking now is like that's still the case.
And then so I I wrote this whole thing, and then I was saying, like, okay, here's what's gonna happen.
Over the next year, all the major AI labs are gonna have at least like one or two more releases that are gonna raise the bar again, and more more of what you what more of what was impossible will be possible, right?
Because that's the whole argument.
It's like, oh yeah, it's okay for code completion, but nothing else.
Oh, yeah, it's okay to write a single function, but nothing else.
Yeah, it's okay to maybe write a module, right?
The 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 3 comes out, and four days after that, Opus 4.5 comes out, and two days after that, GPP5.
And you know, I would say at this stage, like most or all of our engineers are firmly in the camp of using these tools, but we still don't know how all of our process, all of our processes are still very much in the in the old style development process where you know 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, right?
So it's a guarantee that you have to gate 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 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 gotta like completely go through and refactor a bunch of this code by hand myself and rewind a couple of weeks' worth of stuff.
So yeah, I don't know.
Uh, but yeah, 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, 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 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 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 I will say all of my experience is based on backend software development.
So I don't have front-end software development experience in this.
I did actually over like the holiday period do a side quest where I had it do some front-end stuff.
Uh and I 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 UI, a piece of UI code to try to make it like native as some WASM app inside the database.
And again, like it did the whole thing.
And I'm just, but I'm not gonna ship any of this code, is the thing.
I did like 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 PromQL thing?
Not right now.
What's it missing now?
Like, what would it take to get it there?
So with a with a promQL implementation, I think the two things that are most important are one uh 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 Prometheus code base, right?
Uh, 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 as 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 gonna have an engineer who's armed with Claude and Codex support it.
I on some level, that is my argument too.
It's like, okay, well, you have the robot to help you out.
Right.
But I I will say, we which I agree with, right?
There's no 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 gonna be like fire up the agent, yeah, and and 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, literally as a human, that there's this clarity and blind spots thing that I tend to throw at uh 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 got a plan in place, we even 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 and blind spots examination.
Like, where is that?
Oh, we don't, 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.
Yeah, a dopamine rush, and you're just going, you know.
Yeah, well, so for example, there's a this new set of capabilities we're working on right now, which we do intend to release.
And there was, you know, there's there was like a core change that I had to make towards the end of last year that was based on uh 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 weeks 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.
It's like everybody is in the AI casino pulling the levers on the AI slot machine, slot machine, uh hoping, you know, hoping for mana from heaven to come down and uh triple sevens, give me, give me, give 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 gonna pull the plug on all this, and I'm just gonna go back to basics and audit everything myself by hand, like personally, and the 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 gonna take 60,000 lines of vibed up code, or it's not totally vibed up, right?
Because it's not like there was absolutely no supervision.
It wasn't like build me an app and I have no idea what's underneath the thing.
Right.
But still, it's 60,000 lines of kind of vibed up code, and an engineer has to support it.
This is Rust code too, right?
Yeah, yeah.
Not that it's bad code, but like Rust is inherently hard.
And so if you got 60,000 60,000 lines of even harder code than Go code, GoCo is a little easier than than Rust, 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 and 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 yeah, 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 said, 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 I like I got my start as a 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, right?
They're gonna 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.
No, 2500.
Oh, 2500.
It's like 25,000 tokens or like some sort of number that 25,000 is a number in my extrapolate.
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, 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 are you don't let code files get that big, right?
You break up you break them up ahead of time.
You make clear what the invariants 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 gonna spend a lot of time building QA suites and things like that that essentially like run in on developer laptops, but also like in the cloud, and all of it is going to be designed such that an agent can kick off the run, an agent can look at the results, it can run validation steps.
You can give it like we're building like command line tools that are 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 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 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 Elasticsearch for search.
It's a mess.
Well, our friends at Tiger 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.
Then there's hybrid search.
Okay, my favorite feature: the forks.
Agents can spawn subsecond 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 for it 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 at the integration level of it.
You know, it's gotta be.
I think we're in like this this era where bespoke tooling used to be like, oh my gosh, look, like you said before, we can't support that new thing.
I mean, we can't 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 and 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 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 in 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 you.
Oh, yeah.
It's just easier than ever to create that kind of thing.
Do you want to test it, yes or no?
And I was like, let's test it.
It's like, yes, tad complete that and enter, please.
Right.
But again, like I it's it's funny.
Like, I 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 then it's actually like it makes the test pass, but not because the code does what it's supposed to do, but because it had the 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 can be kind of exciting and fulfilling to create a qualitative analysis tool that can be used across the I would agree, I would agree with that, but I don't think that opinion is widely shared by software developers across the industry.
Yeah.
I mean, I think I think the problem is like I 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 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 gonna ask you if 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 with drug tests?
Like, do you have to do you have to code review everything?
Because that's gonna 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 right and not all humans are created, you know, or focused on the same areas.
So it's like it's not just it needs human eyes on it.
It's like, oh, it needs, you know, this person's eyes on it because they know this area of the code base, which is right like code owners kind of thing.
But even that I don't know that we'll get there.
Because the problem is you have to 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, well, we'll just we'll just wave it through.
And that's fine.
And that's what you're seeing, I think out there in the world is like, you know, people are just creating fun things for themselves, whatever.
Yeah, zero users, you know, demo it off.
Nothing to lose.
Yeah.
Yeah.
Yeah.
I totally get that.
I 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 wayside.
I 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, or they're reviewing it for like uh stupid like syntax stuff or whatever.
It's not actually like reviewing the big picture of like how does this actually do what we want it 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.
Yeah, you know.
Have you ever seen the meme where it's like you submit like a 10-line change and then there's like a hundred 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, right.
Exactly.
I get that.
I think there's some truth to that.
Uh yeah, I mean, I 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 gonna have to like deal with that.
I think for people, who was I somebody wrote this the other day.
It's like for people who are like maybe as Andre Carpathi.
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 are are limited at best.
Right.
Yeah, it's weird.
I guess I'm of two minds because I've I've been both people.
I've I do enjoy crafting a function and like the you know, 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 core.
And I built that.
I don't totally love that.
But I think at the end, and I'm but I'm okay not doing it too.
Like I 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 uh 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 I actually have a 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.
Yeah, you can create it and when you toss it up for code review or whatever, like people don't nitpick it because the the stakes are lower, right?
They're just like, ah, it's internal, it's not gonna go out to a customer.
That's true.
You know, so the 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, ah, do I really want to struggle with this and get this through?
You procrastinate for a couple 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.
Well, yeah, it's I and I I think ultimately like sweating those details is still going to be important.
Even if all the AIs are doing all sorts of code and stuff like that, it's still still important for somebody to sweat the details and make sure everything is smooth and works as expected and all this other stuff.
The idea of editing and curating and fine-tuning and having taste is like of the utmost importance now.
Unless, 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, uh, you're gonna see that be a less thing.
But I feel like PMs, product managers, uh folks who are sort of like developer adjacent, but still sort of developer.
Uh, 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.
Like those folks are in well positioned to become engineers, wouldn't 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 management 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 had to wait for an engineer, they had to ask, you know, try and sequence everything through the engineering team, away 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 gonna, you know, just run wild with this, right?
The you know, and I 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 have a I pretty I've I have a lot of faith that actually like there's still gonna be a couple of improvements this year.
I even if they just make tool use a little bit better, maybe a little bit longer context, all this stuff is gonna keep stacking up.
Um 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 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 APIs 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 the all all the way opposite side of the spectrum, like pure like vibe coded application builders, right?
Like lovable and raplit 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 that have 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 agentic 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 you get to the stage, you 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 gonna be creating their own, and they're gonna be a bunch of startups trying to create stuff.
But I think within uh two or three years, maybe a lot of that gets eaten by you know, anthropic, Google, and OpenAI, right?
Hence the SaaS software apocalypse, you know, that's currently happening.
Well, you gotta 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?
Uh I mean, I feel good in the sense that so much uncertainty.
I mean, I I'm generally an optimist, so and I like I 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 uh I think yeah, as an infrastructure software provider, we're in a position to not be completely displaced.
Yeah.
Um, 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 uh I know that in the past you've done a lot of, you've had your own conference, right?
You have an annual conference, I think you do a lot of workshops that you participate 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 over 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 of, you know, building the thing, and one of the things I wanted to do was like optimize for developer happiness, right?
I was like, uh if you optimize for developer productivity, make it easy for them to use, easy to to create things, like the software will win.
And that was informed by my experience, you know, using uh Ruby on Rails in the early Rails days.
Like, you know, I could create like a web app in a fraction of the time that you could with other 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.
Um so developer ergonomics were like the thing.
And for Influx DB, I that's what I modeled.
And I I 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 matter as much anymore because developers aren't gonna actually write it, be writing the software.
What matters is actually like how easy is it for an agent to use.
And it's funny, actually, uh Wes McKinney uh had a post probably like two weeks ago where he mentioned this.
He was like, you know, he th he's 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, right?
And he used as his example, he's been lately writing a bunch of Go code, but he doesn't have doesn't write it, and agent writes it.
He's never been a Go developer before.
He's a Python guy or like C guy, you know.
So I think that's very true.
And I when I was thinking about Influx V, 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 uh the idea was like WASM.
Wow, WASM is great because you you can put a WASM runtime in the database, you can sandbox it, you can limit the number of CPUs, the amount of RAM RAM, you can limit specific calls that it can make.
Uh so I basically prototyped that.
Um, so we may experiment with that over the course of the next year.
I don't know.
Again, that's not getting shipped.
That's not that was a side quest to see what's possible.
Well, I think what's happening too, though, I mean, you still have developers right here.
I mean, developers still c care about CLIs, they still care about APIs.
I think your your notion of WASM in a sandboxed 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 the only reason I bring this up is because I'm like just laser focused on this idea that you know, 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 it's the framework that developers use to implement and utilize that.
And if you're paying close attention to your CLI and 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 InfluxDB and how it works and how they can utilize it, but you're also gonna have agent-enabled developers who are writing GoCo 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 agent to agentify, 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 coupled with your great API that's you know, got all the right kind of tests and all the backing behind it.
Now they're off to the races.
You know, you've enabled them to go on their own roads at much greater speeds and not have to build new features.
You just get to go further in, not the other way.
Yeah, I mean, I think the 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 the where there's a lot of potential is like, you know, we've we've often had customers or users asking us to build like more application level features and stuff like that.
And 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 agentic tools encoding, what that enables, it's 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, right?
Like most enterprises are, you know, they're if they're using agentic tooling, agentic software development, stuff like that.
But I 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, 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, I think you'll see a real difference between engineering organizations that are delivering at that kind of velocity versus ones that aren't.
And I but uh again, I think along the way, what we'll also see is like spectacular failures, right?
Like you will see big like security uh compromises, like claw book you.
Yeah, yeah.
You will see big like infrastructure failures or you know, production failures and stuff like that.
Where it will be my bad multi book, yes, yeah, multi book for open claw because it's not malt bot anymore.
That's right.
No, that was so last week.
So like that was like yes last week forever ago.
Yeah.
So yeah, I I don't know.
It's uh it's wild, it's crazy times.
Are you thinking about this from a CTO 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?
Uh 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, right?
So what I expect is like more and more tooling to allow AI to basically just solve pro 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 uh this still 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 InfluxDB 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 right a bunch of a bunch of that stuff so mostly what I'm thinking about it uh 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 I don't think we have any particular talent in being able to like innovate in that area faster than you know the the big AI companies like OpenAI, Anthropic, Google are gonna 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 InfluxDB and better at using our stuff as long as we have proper documentation in markdown files that agents can consume command line inter tooling that the agents can use you know I'm not super bullish on MCP just because at this stage, if I can use it, if I can have the agent use a CLI, that's what I use.
But yeah, I think MCP is uh 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 well, why not just bolt this the CLI and make it more agentic friendly?
Yeah, 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 my guess is the if you if you take out like dashboarding, basic dashboarding, like I assume like agents are going to be the most frequent accessor of the database.
So the question is like, how do you want to lock them down, right?
You want to lock them down so they can't mess up the data that's in there.
Maybe you want to lock down visibility in terms of what they can get to.
So, but those are all like security and access controls.
But the truth is, like, a lot of that stuff is the same if you have a very large enterprise organization with a bunch of humans accessing these things.
So I feel like, you know, just like I said, like for all the software development practices that mattered before just matter even more, it's the same thing.
Like all these features matter more.
The only difference is instead of have having an organization where you have you know a hundred or a thousand humans accessing the thing, you also have 100, a thousand, 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 are you practicing a lean?
How is your your, I guess, day-to-day collab around what to build and how to build it, and maybe even uh pair programming, you know, is that is that happening?
How's 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 uh 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 and share it with uh the rest of the engineering work.
We also created, you know, a 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 uh 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 GitHub repo that we have called ERS, 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 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?
Um, the kind of stuff where it will like preload a set of you know, context that's important and a set of tools and just make it easier.
Um but yeah, I mean the the collaboration part is tricky.
I I still I'm thinking maybe we should be doing like uh, you know, like the occasional like engineering demo to each other.
Like we 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're trying to figure it out.
Yeah, 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 uh while you're not vibe coding necessarily like a traditional, maybe maybe even a negatively connotated version of vibecoder is doing it.
You're still vibing with the 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 uh 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 Canban 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 the whole design for the thing and whatever.
Um 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 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 gonna 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, 2,000-word document with all this other stuff.
Another human to review that, it's gonna 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 gonna review it, and who's gonna like I almost feel like um 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 to 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 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 and 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 as an on-prem product and also hosted in AWS.
It's a time stream for Influx TB.
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 gonna ask you too.
Like you you just mentioned it, but your team sized because we just had a conversation with a male who's saying one of our uh past participants slash animal in JS Party.
Sorry, Jared.
Um, we talked about just this idea of you know, you mentioned 37 signals in that conversation I mentioned, getting real and back in in the days of getting real, which was 15 years ago, I'm assuming on the date range of the book release, uh, 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 uh prescription, but it was somewhere around four or five, was like loosely there.
And then Jeff Bezos was famously uh calling the the idea of a two two pizza team, which depending upon the you know your your appetite for pizza, it's like a four-person team in my in my brain, right?
And so I I think you will see.
Do you agree with that?
Like it's probably four people.
I don't know.
I well, I I think I think Bezos had potentially a larger team in mind, like up to like eight or 10.
Okay.
Maybe I don't know.
But really, uh I I mean it 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 well, yeah, because I mean, well, if you go back down to enabling one person, that one person can now, in your words from earlier, produce a hundred X more code, and so any if you put more than two to maybe three in that kind of sphere, you got now 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 load 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?
And you know, did something go wrong in the in the carpool line, dropping off your kids, like all these things impact our ability to comprehend our day to day.
And so I feel like any anymore beyond two, maybe three is probably pushing it.
Like I wouldn't do a four-person team anymore.
Like a two-person is probably pretty solid.
Yeah, we 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 and 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 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 towns to be in for sure.
Have you figured out a way since you've pinned this post on building the machine?
Are you are you actively doing anything to build a version of a bespoke machine for you all?
Do you have any ideas that you any uh side quest plans, any specifications you've aligned?
Can you give us a behind the scenes at all if you've got this in motion?
Do you think it'll be something that somebody builds and delivers to everybody, or will it be bespoke per team?
Right now I think it's bespoke per team.
I well, I think it's uh it's bespoke per team using whatever agenc 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 you software developers, right?
You can't land a software developer in any organization and expect them to immediately become productive, right?
You have to go through training, they have to look familiarize themselves with the code base, 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 then that's it.
You've got that one human doing it.
Once you've optimized your process within an organization for an agent to deliver things, if 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 will 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 I again, like, yeah, that'd be cool.
Just like a regression suite that like an agent actively has bounds on and sandboxed, and like if it solves it, cool.
If it doesn't solve it, then no harm, no file, right?
Just spend money on tokens.
And it's now it's a 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 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 basically I told the execs, I was like, look, like everybody inside the company has a superpower that people outside of Influx DB do not have, right?
Which is they have access to the code base, the you know, the proprietary code base that we have that we sell our customers.
If you pair that with like Cloud Code 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 our from a customer, we are able to actually answer that within minutes based on agents doing the work.
And you still need like support engineers and regular engineers to review things and to build the tooling behind the scenes.
But ultimately, where I want to get to is all of that stuff is executed automatically when things come in, and they can use both the code that we have internally that our customers can't see, right?
And the all the documentation and internal like knowledge base that we have, either in you know, support previous support requests or issues that we have in closed source repos or documents, markdown 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 pinning to versions of InfluxDB or your API, uh, for example.
So, I mean, that's a lot you can really uh 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 10x the 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 uh that's a good thing on ultimately.
You know, I'd be remiss not to ask you this question before we begin to tail 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 uh 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.
If we're in 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 you know, libraries that are written and tested and hardened over the course of multiple years.
So I think I don't think that's gonna go away.
I think uh it's probably the more complex something is, the more likely it is that you're gonna 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 gonna ask an AI to write the thing from scratch, right?
Although it certainly could try and probably could produce some fairly passable result, but it's not going to be, you know, as 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 give 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 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 adds some tooling.
You know, I think we've seen a lot of like GitHub anger over the last like few months because they don't seem to be too on top of this at the moment.
But yeah, I think I right now that feels like the bigger impact.
Um, but ultimately I think open source software is still going to be a thing.
It's still going to be important, right?
You're still you're still gonna want to adopt soft, what you know, well developed software rather than just try and write it from scratch, right?
Like, you know, uh 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.
Yeah, I think a lot of that is like you want some of those Chrome developer tools, uh 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 or to support, even.
Yeah.
I mean, I I think, you know, there's it's really difficult for open source like software companies at this stage.
I I would expect to see fewer open source software companies, really.
Like if people are gonna do something, they'll do source available, but 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 want to open source these libraries that do whatever, that's fine.
But I think more and more for people who build infrastructure software who want to sell it, they'll probably be doing source available licenses, if anything, because you know, it's just like there's it's too easy for anybody to pick up the source code and then like run wild with it and do whatever.
So yeah, if you have good docs, a good API and a good CLI and open source.
Well, you just give them all the keys to your kingdom basically, like uh 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 area 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, 100 other things.
Why not add one more thing to it if it's that important?
Yeah, I don't know.
I mean, uh, it's funny because like before I feel like over the last 20 years, you know, a lot of developers did open source in the early days.
It's specifically for like junior developers, they would do open source because it was a way to like get some practice, right?
Get some examples of like work that you've done to help like raise your profile to help you ultimately like get a better job, right?
These are baseball cards, open source stats.
Right.
And then the problem is like that is kind of taken away, like that motivation is taken away because again, it's so easy to produce the code, you can have an agent do it.
And the maintainers don't want to take your code anymore because they're getting like slammed with a bunch of like garbage from whoever.
So I think what we'll see most likely is a lot of like open source projects that again are like open source but close contribution, and they're developed entirely by one person, or they're developed by maybe a very small group of people.
And if it's good, like what I expect is you'll actually see like 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 uh of the single 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 I've heard that from other people too.
Uh I actually have to I haven't talked to Andrew, Andrew Lamb, who is the PMC for Data Fusion and Parquet and Aero.
He's on our team.
Uh, and basically, like he runs those projects.
Um, 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 slammed.
He before the ASDF, 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 pull requests, not less.
Yes.
Yeah.
Kind of the backwards, the yeah, the backfire of even email.
The more you answer your email, people respond back and then they have more email.
So that's right.
Yeah, these things compound.
Stoke in the fire.
That's right.
That's right.
Yeah.
Yeah, that's interesting.
Uh what what makes someone want to contribute more to Ghostie, for example?
Like what's the groundswell there?
Why is he getting so much why is 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 then it's easy to have an agent code it for you, and you don't have to put a thought into it besides, well, I tested it real quick and it works.
So PR, open a PR, start advocating for your little pet feature to get in.
I mean, that's my assumption.
Yeah, I mean, I think like one, it is it's like as a project, it has like super high visibility, right?
It's super, super popular, and it's an end user, like an end user project, right?
People are using the terminal themselves.
So yeah, maybe they're just trying to submit features that they want.
Maybe they're trying to get recognition or whatever to be like, oh yeah.
The calling card to be like, oh yeah, I got a PR landed in Ghosty and everybody knows this project.
So there's lots of motivations.
Now the curl bug bounty actually was ended recently because uh 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 code gen up something and hopefully get some money.
I mean, people are gonna do that all day.
Yeah, I mean, one angle could be, you know, set an AI loose on that that bucket and just say, give me all the cream off this uh 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 if it's mostly noise?
I mean, if one percent was signal, would you still want the one percent given?
Yeah, does it become like email spam filtering, right?
Right.
Yeah, exactly.
Robots checking other robots work, you know.
We're headed.
That's definitely where we're headed.
We're we're in a wild world.
What's over the horizon for you guys?
What's uh what's happening at Influx that is, you know, this show goes out uh next week.
So 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 out the show?
Yeah, so we're busy at work right now on the 3.9 release of Influx DB3.
The goal, you know, there are a number of things we're launching there, but we have uh a beta, hopefully a beta of some really big enhancements that we we're hoping people to test out basically that will enable wide sparse tables, many, many thousands of tables like we had in V1 and V2, and you know, better better query performance and a bunch of other things.
So that's kind of where we're focused on right now is getting getting that release out the door and then uh 3.10 after it, which should come towards the end of March.
Um so yeah, and then later this year, like a whole litany of features that that are building on top of that that core.
Maybe some uh prom QL.
We'll see.
We'll see.
I'm not I'm making not making promises on that one, right?
Because it's it's easy enough to let AI make the thing, and it's hard enough to see whether or not it's like can we support it?
I'm confident by then you'll solve the problem though.
I mean at this stage, it's like we you know, can we support it?
Can we give our 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 you know feature flag that to some degree or take the folks who have asked for it and say, you know what, we're gonna give you access to this with these conditions because you want to get this into production but we need some uh willing participants so to speak some uh some testers some production testers that are willing to understand there maybe 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 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 dead code is on purpose okay I'm leaving it there.
It's a future feature just shut up about it compile it's good.
We it's good we 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 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 I get I know what they're there for, and I'm okay with it.
Fair, fair I I uh yeah, I love the I love the clippy lints.
It it gives you I think lints are also a great signal to give to the agents to to make improvements.
Clippy links.
I agree.
All right.
Anything anything left here?
What's left on our plate?
Anything 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 gonna be some serious machine building going on, and I'd love to know where where they get in a year's time.
But other than that, no, I don't think so.
I agree.
The machine building and uh 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 con uh full conviction to full conviction.
Yeah, yeah, yeah.
I don't know, it's gonna 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.
Well, 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 than the last time, though.
We'll see what happens.
Yeah.
Maybe maybe I'll have something interesting to say in another three to six months.
Who knows?
There you go.
Who knows where we'll be?
Who knows what the house will have taken off our plane?
Who knows?
Who knows?
We may have lots of free time.
All righty.
Thanks, guys.
Thanks, Paul.
Thank you.
Log interview for this week.
Thanks for listening.
And thanks to Paul for stopping by the show again.
So much hard-earned 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 Brett Cannon.
A conversation that's supposed to be about Python and stuff like that.
But starts out with a deep dive on.
Hmm, Star Wars.
Talk to you then.