We should be more ambitious with the software we build

In this post, we're going to use ambitious in a way that feels consistent to me, but that one could argue is overloaded. I'm using this to mean, doing more than you could've before, in a generic sense. One could say that there's a difference between building a project that's larger than was reasonably feasible before and building some kind of super-specialized tool that could've been done before but just wasn't worth the time to build. While these are very different things, I think they both fall out of the same thing (it being much easier to produce software), so I feel pretty comfortable with this arguably overloaded definition. [return] Alex Kolovsky pointed out that these were not considered a bug. I see the argument from a security standpoint and I don't have enough context on Postgres to weigh on on this specifically, but I'll say that, for projects I've worked on, I've liked eliminating this kind of issue because it's a lot easier to find real bugs if you try to make your code clean from all issues like this. [return] One reason I trust Malis is that he's a lot more careful about what he claims than a stereotypical founder. For example, when I joined the pgrust discord to check out what people are saying, I saw this message from Malis (dated a month ago, 2026-09-17, an eternity in agentic coding land) in response someone asking about pgrust's readiness for use as a production database: I would not recommend using it as your primary production database today. We are setting a production deployment for a company right now, but they are more tolerant to their production database going down than most people. We'll have good empirical evidence on how reliable pgrust is after they start running it Malis doesn't seem like someone who would claim something is production ready when it's clearly wildly unready, like many well-known projects have, and it turns out he's not doing that. I wrote the draft of this a week before publishing and didn't have time to publish it. Since then, there was this pgrust Clickhouse benchmark controversy. On looking into this, the accusations of nefarious cheating seem to be false, and the accusation that it was premature to submit the preview of pgrust to the benchmark is something Malis acknowledged. I do think this is the kind of thing that a project will never live down, in that regardless of the truth of the matter, people will be bringing this up years later. You can see this right now in discussions around that specific controversy, and as we discussed when we look at Ed Zitron's prediction track record and when we looked at futurist predictors like Kurzwil, almost nobody actually looks at what actually happened and people will repeat incorrect statements that were based on vibes indefinitely. I don't think I can really present all of the evidence for why I trust Malis (technically, I could do it, but it would easily be a 20k+ word post), but if you look at how he discusses pgrust vs. how typical database founders market their new DB projects, it seems dramatically different to me. Of course there are extreme examples like MongoDB, which disputed correctness issues for years despite Kyle Kingsbury repeatedly showing that the anecdotes people had about data corruption were real. For an example that's more typical, a friend of mine worked as an early employee for a database startup. Their webpage bragged about doing some huge number of QPS. On testing it, my friend found that the claim was off by multiple orders of magnitude and suggested that the webpage get changed. The founder disagreed because they were going to hit the performance numbers, so it was still a true claim. After multiple years of performance improvements, the company eventually reduced the claim by one order of magnitude and they can still only hit that number with a very contrived, unrealistic, workload. This is, unfortunately, pretty normal for a company peddling a product based on its performance. By contrast, when I look at the pgrust discord to see what Malis is saying about performance, here's his most recent message: Right now, the best way to help is to find bugs and performance issues in 0.4-beta. The new query engine is very fast on some workloads, but it causes performance regressions on others, and it doesn't support some more complex queries. We're trying to track down everything that's either slower than Postgres or errors out. It's not an easy thing to do given the massive space of queries you can run We want to fix these things before the general release of 0.4-beta. Off the top of my head, there was a big performance regression in very fast queries. This is because we primarily optimized the new query engine for large-scale OLAP-like workloads. I'm doing optimization work to fix the very slow queries. I don't think there's any fundamental reason why the new engine should be slower than the previous one for fast queries Even though he was a founder and exec of a successful startup prior to starting the pgrust project, he never really got into the mindset that most founders seem to, where they seem to be able to say anything and believe anything they say. You might say this is a low bar, and I'd agree, but I still think it's rare and it's why I trusted what he says about pgrust without looking into it and also why, when I looked into it, his claims seem to be borne out by reality. [return] One reason I trust Malis is that he's a lot more careful about what he claims than a stereotypical founder. For example, when I joined the pgrust discord to check out what people are saying, I saw this message from Malis (dated a month ago, 2026-09-17, an eternity in agentic coding land) in response someone asking about pgrust's readiness for use as a production database: I would not recommend using it as your primary production database today. We are setting a production deployment for a company right now, but they are more tolerant to their production database going down than most people. We'll have good empirical evidence on how reliable pgrust is after they start running it I would not recommend using it as your primary production database today. We are setting a production deployment for a company right now, but they are more tolerant to their production database going down than most people. We'll have good empirical evidence on how reliable pgrust is after they start running it Malis doesn't seem like someone who would claim something is production ready when it's clearly wildly unready, like many well-known projects have, and it turns out he's not doing that. I wrote the draft of this a week before publishing and didn't have time to publish it. Since then, there was this pgrust Clickhouse benchmark controversy. On looking into this, the accusations of nefarious cheating seem to be false, and the accusation that it was premature to submit the preview of pgrust to the benchmark is something Malis acknowledged. I do think this is the kind of thing that a project will never live down, in that regardless of the truth of the matter, people will be bringing this up years later. You can see this right now in discussions around that specific controversy, and as we discussed when we look at Ed Zitron's prediction track record and when we looked at futurist predictors like Kurzwil, almost nobody actually looks at what actually happened and people will repeat incorrect statements that were based on vibes indefinitely. I don't think I can really present all of the evidence for why I trust Malis (technically, I could do it, but it would easily be a 20k+ word post), but if you look at how he discusses pgrust vs. how typical database founders market their new DB projects, it seems dramatically different to me. Of course there are extreme examples like MongoDB, which disputed correctness issues for years despite Kyle Kingsbury repeatedly showing that the anecdotes people had about data corruption were real. For an example that's more typical, a friend of mine worked as an early employee for a database startup. Their webpage bragged about doing some huge number of QPS. On testing it, my friend found that the claim was off by multiple orders of magnitude and suggested that the webpage get changed. The founder disagreed because they were going to hit the performance numbers, so it was still a true claim. After multiple years of performance improvements, the company eventually reduced the claim by one order of magnitude and they can still only hit that number with a very contrived, unrealistic, workload. This is, unfortunately, pretty normal for a company peddling a product based on its performance. By contrast, when I look at the pgrust discord to see what Malis is saying about performance, here's his most recent message: Right now, the best way to help is to find bugs and performance issues in 0.4-beta. The new query engine is very fast on some workloads, but it causes performance regressions on others, and it doesn't support some more complex queries. We're trying to track down everything that's either slower than Postgres or errors out. It's not an easy thing to do given the massive space of queries you can run We want to fix these things before the general release of 0.4-beta. Off the top of my head, there was a big performance regression in very fast queries. This is because we primarily optimized the new query engine for large-scale OLAP-like workloads. I'm doing optimization work to fix the very slow queries. I don't think there's any fundamental reason why the new engine should be slower than the previous one for fast queries Right now, the best way to help is to find bugs and performance issues in 0.4-beta. The new query engine is very fast on some workloads, but it causes performance regressions on others, and it doesn't support some more complex queries. We're trying to track down everything that's either slower than Postgres or errors out. It's not an easy thing to do given the massive space of queries you can run We want to fix these things before the general release of 0.4-beta. Off the top of my head, there was a big performance regression in very fast queries. This is because we primarily optimized the new query engine for large-scale OLAP-like workloads. I'm doing optimization work to fix the very slow queries. I don't think there's any fundamental reason why the new engine should be slower than the previous one for fast queries Even though he was a founder and exec of a successful startup prior to starting the pgrust project, he never really got into the mindset that most founders seem to, where they seem to be able to say anything and believe anything they say. You might say this is a low bar, and I'd agree, but I still think it's rare and it's why I trusted what he says about pgrust without looking into it and also why, when I looked into it, his claims seem to be borne out by reality. This comment about an increase in cheating online has come to pass. On re-reading the actual comment that I wrote, I didn't explicitly write that it seemed inevitable that there would be a large increase in cheating, although it can be inferred from connecting the statements there together, and I've been on the record in public on some discords, etc. I don't follow the online game scene, but I'm told that for Azul (the most popular game on BGA, the biggest online board game platform for modern board games), 3 of the top 10 places last season were taken by cheaters, including top place. Also, as I've noted elsewhere in the past, BGA doesn't seem equipped to make reasonable policy decisions on almost any level. Things like the mechanics of their Elo ranking algorithm, their structure for game seasons, their policy for counteracting collusion, their policy for countering cheating, etc., are worse than the most naive straightforward solution you can think of so, as expected, they don't have a reasonable policy to counter cheating. The top ranks of the most popular game have been overrun with cheaters and this should be expected to spread to other games. As harms from AI go, this is a fairly benign one. It just happens to be one of a double-digit number of examples I saw last week of people being more ambitious in the software they create. I'm half mentioning this because it's easily quantifiable, and half because I predicted this would happen and it seems reasonable to follow up and see what happened. [return] This comment about an increase in cheating online has come to pass. On re-reading the actual comment that I wrote, I didn't explicitly write that it seemed inevitable that there would be a large increase in cheating, although it can be inferred from connecting the statements there together, and I've been on the record in public on some discords, etc. I don't follow the online game scene, but I'm told that for Azul (the most popular game on BGA, the biggest online board game platform for modern board games), 3 of the top 10 places last season were taken by cheaters, including top place. Also, as I've noted elsewhere in the past, BGA doesn't seem equipped to make reasonable policy decisions on almost any level. Things like the mechanics of their Elo ranking algorithm, their structure for game seasons, their policy for counteracting collusion, their policy for countering cheating, etc., are worse than the most naive straightforward solution you can think of so, as expected, they don't have a reasonable policy to counter cheating. The top ranks of the most popular game have been overrun with cheaters and this should be expected to spread to other games. As harms from AI go, this is a fairly benign one. It just happens to be one of a double-digit number of examples I saw last week of people being more ambitious in the software they create. I'm half mentioning this because it's easily quantifiable, and half because I predicted this would happen and it seems reasonable to follow up and see what happened. Pandoc supports {html, docx, xlsx, pptx, csv, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, odt, tsv, latex, ipynb, mediawiki, rst, asciidoc, bibtex, biblatex, org, typst, jira, docbook, endnotexml, ris, opml, dokuwiki, textile, man, mdoc, jats, csljson, fb2, pod, vimwiki, djot, creole, tikiwiki, twiki, t2t, haddock, muse, json, xml, native} as input formats and {pdf, html, html4, docx, plain, pptx, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, epub2, odt, latex, ipynb, mediawiki, rst, asciidoc, asciidoc_legacy, bibtex, biblatex, org, typst, bbcode, bbcode_phpbb, bbcode_steam, bbcode_xenforo, bbcode_fluxbb, bbcode_hubzilla, jira, docbook, docbook4, revealjs, beamer, opml, dokuwiki, textile, man, texinfo, context, jats, jats_publishing, jats_articleauthoring, tei, icml, opendocument, csljson, fb2, ansi, chunkedhtml, djot, xwiki, zimwiki, vimdoc, haddock, markua, muse, ms, slidy, s5, dzslides, slideous, json, xml, native} as output formats (native is a serialized version of Pandoc's AST). [return] BTW, this makes public evals not very meaningful for many use cases because what I and other programmers who are using models often care about is how good the model is at a task where the model still needs human guidance, not how good the model is at a task that's trivial for the model. [return] This is not a claim about the future. Perhaps almost all or perhaps even all of the software skills I have will become irrelevant in the near future. But we're not there yet. At the moment, programming skills seem higher leverage than ever before. There's something a bit funny about the current moment, where it seems like having the skills that models are replacing makes one much more effective than people who are trying to use models without having those skills. I like Max Bittker's framing that models are very good at counterfeiting and the level of expertise it takes to distinguish a counterfeit from the real thing has been increasing as models improve. [return]