Not a direct answer to your question, but I’m recently trying to adopt the mindset of letting Claude “prove” to me with very high confidence that what they did works. The bar for this would be much higher than what I’d require for a human engineer. For example it can be near 100% test coverage, combined with advanced testing techniques like property-based tests and fuzz tests, and benchmarks if performance is a concern. I’d still have to skim through both the implementation and tests, but it doesn’t have to be a line by line review. This also forces me to establish a verifiable success criteria which is quite useful.
Results will vary depending on how automatically checkable a problem is, but I expect a lot of problems are amenable to some variation of this.
> But I will never call into a library I don't fully understand while holding a mutex again. Fool me once.
Nice sentiment and an admirable goal. Not really actionable in practice. Even if we disregard all userspace libraries out there, fully understanding the most frequently used syscalls is a monumental task already. You have to pick your battles in terms of understanding parts of a complex system.
Anecdotal perspective. I’m usually ok with others copying my code since code feels less personal (for lack of a better word). The other day I found a prompt for internal AI that copied my technical arguments in prose verbatim without attribution. This felt very wrong and invasive. It made me much more sympathetic to people with intellectual work out in the public domain.
Whether it is significant is highly specific to the domain. I think protobuf has accumulated enough problems that every large scale application will eventually run into a footgun or two. Almost all of them have to do with the generated types, not the wire format.
Examples that can noticeably slow things down even for “normal” web apps: map types and deeply nested messages.
Can you explain how TCP_CORK helps here? The chaff packets are spaced 20ms apart and sent per socket, so I don’t see how TCP_CORK could help unless it coalesced across 20ms intervals? But coalescing is clearly not an option for the intended obfuscation effect of the original feature.
It is unrelated to SSH, it is a generic TCP thing.
"hello world" fits in a single TCP packet, but the kernel might end up sending one packet containing "hello" and another packet containing " world". It is completely opaque to userspace.
TCP_CORK lets userspace decide when packets are dispatched. You get to control whether "hello world" is sent across 1 packet or 11 packets.
It depends on the language and codebase. For something very dynamic like Python it may be the case that grepping finds real references to a symbol that won’t be found by a language server. Also language servers may not work with cross-language interfaces or codegen situations as well as grep.
OTOH for a giant monorepo, grep probably won’t work very well.
I work with an amazing QA team right now. They are good programmers that don’t mind doing lots of grunt work, understand the goal of the software deeply, collaborates extremely well with other teams, and are just all around great people. I expect they would kill it as a non-QA dev team as well, so I’m always grateful to have such partners.
Does anyone knowledgeable know whether it’s possible to drastically reduce the overhead of reading from procfs? IIUC everything in it is in-memory, so there’s no real reason reading some data should take the order of 10us.
For some reason Opus 4.5 is blowing up recently after having been released for weeks. I guess because holidays are over? Active agent users should have discovered this for a while.
Results will vary depending on how automatically checkable a problem is, but I expect a lot of problems are amenable to some variation of this.
reply