Justy: Okay so Google just came out and said their database team is going heavy on AI coding tools for PostgreSQL work, and I actually think there's something interesting here.
Cody: I'm sure they did.
Justy: No, listen — the VP basically said the sweet spot is when you have a well-understood academic idea and a well-understood codebase and you're building something isolated. That is such a honest take for a cloud VP.
Cody: Right, right. And also conveniently the thing that's hardest to mess up.
Justy: Exactly. So anyway — how was your week? You mentioned something about a server thing?
Cody: Oh, the usual. Spent three hours debugging a replication lag issue that turned out to be a config typo. Super glamorous stuff.
Justy: Classic. Okay so back to this — what do you make of the accountability framing? Because that feels like the actual substance here.
Cody: It does, yeah. So Krishnamurthy's line is that individual engineers take accountability whether the code was fully AI-drafted or just partially assisted. And look, on the surface that sounds responsible.
Justy: Mm-hm.
Cody: But here's where it gets murky. If you're shipping code to an open source project like PostgreSQL and something breaks in production, who actually gets blamed? The individual engineer who approved it, or the project maintainers who merged it?
Justy: That's a fair point.
Cody: Accountability sounds great until you try to enforce it. And
Cody: I'm just saying — 'heavily' and 'judiciously' are doing a lot of work in that quote and they kind of cancel each other out.
Justy: Okay that's fair. But the open source training data point — that's actually technically sound, right? Like public codebases are just better inputs for these models?
Cody: Yeah, that part holds up. If you've got a model trained on Postgres internals and the commit history and the mailing list discussions, it has way more context to work with than some proprietary blob behind a firewall.
Justy: Right, right.
Cody: So credit where it's due — that reasoning is sound. The sweet spot framing is also more nuanced than I expected. They're basically saying use AI for extensions, not for touching the core storage engine.
Justy: Which — as someone who's watched people try to vibe code their way through a distributed system — is exactly right.
Cody: Yeah, the blast radius matters.
Justy: The article also mentions Google working on logical replication improvements specifically. That's not nothing — that's actual hard engineering.
Cody: True. And if AI is helping them get more contributors onto that kind of work faster, that's a legitimate win. I'm just skeptical of the framing as a whole.
Justy: Which is your whole thing.
Cody: I know, I know.
Justy: But seriously — who should actually care about this? Because it's Google PR, but there's a real trend underneath it.
Cody: Database engineers at companies contributing to Postgres, 100%. Also anyone maintaining an extension ecosystem. If AI is going to lower the barrier to entry for contributing, that's a real shift.
Justy: Yeah. And the Microsoft stuff they mention — the BSON extensions, the MongoDB-compatible layer — that's the kind of thing that becomes possible when more teams can participate.
Cody: Agreed. That's concrete and useful.
Justy: Alright so — is this a meaningful signal or just cloud PR? What's your read?
Cody: Both, honestly. The accountability framing is PR. The technical reasoning about open source codebases and the sweet spot for isolated work — that's real insight.
Justy: That's a fair split. Alright, I'll take it.
Cody: You're getting easier to convince.
Justy: Only when you're right. See you next week, Cody.
Cody: Later, Justy.