(I'm working with malisper on pgrust),
I think the focus for projects like this is going to shift to reviewing the testing/fuzzing process instead of reviewing each commit (going much further than what the postgres regression/isolation/crash tests do).
related post from danluu: https://danluu.com/ai-coding/
Some of this post reminds me of a story I heard long ago from someone who had worked at a HW/SW company. They’d transferred an engineer from the ASIC design team to the OS kernel team, though he’d never been on a software team before. After a while the manager called him in for the following conversation:
Manager: You’re doing amazing work — zero bugs in production! I’d like you to mentor the other SWEs on how to get their bug count down too.
Engineer: We’re allowed to have bugs?
Funny story but in my experience hardware engineers produce some of the worst software of the industry. Of course there must be some hardware engineers out there who do hood software but generally what they build are disasters.
Honestly, i do not blame them for that though. The whole eco-system of in C- procedurally bitbang on some registers and read on others, until some circuit that might be there is coerced into doing work - often with faulty prototypes you have to rewire yourself, whos documentation is - non-existant-complete while having deadlines within deadlines. And the project-culture is just "aggregate" a layer, wrap the problem like a pearl in shellacks as the main abstraction.
I bet it's being organized by project rather than product. Conway's law ensures such an org will create code around projects, not products, and that always ends horribly.
I know it’s a typo, but I love the idea of “hood software” lol
Hardware engineers call them errata ;-)
How many engineers does it take to fix a bug?
Hardware Engineers: "None. We'll fix it in firmware."
Firmware Engineers: "None. We'll fix it in software."
Software Engineers: "None. We'll document it in the manual."
Technical Writers: "None. The user can figure it out." etc.
While I get the joke, as a technical writer, you might be surprised how often I've found myself as a defacto QA engineer:
Me: This is what you said it does, and this is what it actually seems to do. Which one is right?
Engineer: Shit.
Very carefully - and I mean extremely carefully - word it so that it describes what it does, while implying what it should do without confirming that it actually does that.
Also helps if you fix the bug or change the behavior, the docs are still technically correct. I'm only partially kidding, I swear I've seen this a million times in documentation I read.
The joke is awesome.
Sadly, monospaced fonts kill sarcasm.
For large projects like this I think a hierarchical division of labor also helps.
If you first carefully define the overall architecture and thus individual high level components of the system, then you know which of those components are mission critical and which are commodity. Mission critical would be anything ensuring ACID, etc. That way, no matter what you farm out to LLMs, you can keep the majority of limited human focus on the far fewer mission critical components. If tests end up not being robust enough to catch all issues, at least they'll be isolated to commodity code where damage is limited to things like DoS, etc, and not code that could cause data loss.
I also think it's important to first define the _contracts_ on and between each of these components, and derive tests from those contracts. Partly because contracts more succinct and easier to reason about. And partly because Rust provides many tools to enforce contracts at compile time, reducing the need for tests (which themselves could end up subtly flawed). Contracts can be enforced through typing, private vs public APIs, etc. Newtypes are _incredibly_ powerful for both enforcing contracts and making footguns much less likely.
Oh, I just posted a similar comment elsewhere in the thread.
https://news.ycombinator.com/item?id=48856535
Though beyond testing, I think there will be increasing focus on proofs of correctness. (Testing can only show the presence of bugs, not the absence. —Dijkstra)
At any rate, it's never been this cheap to produce the proof of correctness of a program, or on the other hand, to produce an exploit for an incorrect program.
And what happens when your "tests" are also vibecoded. Right now all of these houses of cards reset on human-written tests. What happens without them?
> reviewing the testing/fuzzing process
I've got insanely good at designing testing oracles over the last year for exactly this reason.
I've ported some extremely finicky software between languages that it would have been borderline abusive to have a human do.
Codex 5.3 and later for those interested.