jkaptur

Putting cynicism aside (there's plenty of that here already): there is a theory that people invest in index funds because they don't want to pick individual stocks. They want exposure to "the public stock market as a whole". I think there are good arguments on both sides of including SpaceX in such an index.

The other thing to keep in mind is that if you have a policy of considering 98% to be "close enough", then it only takes 35 of those decisions to remove over half the population. And it'll be exceptionally difficult to work your way back up, because each improvement will be minimal!

(Of course, this assumes that each decision is independent, which, when you're talking about browser support for CSS, is certainly not the case.)

I’m not an expert here, but it sounds like you’re forcing a first-order logic problem into a propositional logic box.

A “native” first-order logic solver like Z3 might be something to try.

> I personally don’t know any colleagues who were good engineers just because they wrote code faster.

However, the best engineers I know are usually among the quickest to open an editor or debugger and use it fluently to try something out. It's precisely that speed that enables a process like "let's try X, hmm, how about Y, no... ok, Z is nice; ok team, here are the tradeoffs...". Then they remember their experience with X, Y, and Z, and use it to shape their thinking going forward.

Meanwhile, other engineers have gotten X to finally mostly work and are invested in shipping it because they just want to be done. In my experience, this is how a lot of coding agents seem to act.

It's not obvious to me how to apply the expert loop to agentic coding. Of course you can ask your agent to try several different things and pick the best, or ask it to recommend architectural improvements that would make a given change easier...

To be fair, many of those films do not portray human drivers in the best light.

(I'm not an expert. I'd love to be corrected by someone who actually knows.)

Floating-point arithmetic is not associative. (A+B)+C does not necessarily equal A+(B+C), but you can get a performance improvement by calculating A, B, and C in parallel, then adding together whichever two finish first. So, in theory, transformers can be deterministic, but in a real system they almost always aren't.

Another point is that the world is always changing. If you work slowly, you are at much greater risk of having an end result that isn't useful anymore.

(Like the author, of course, I'm massively hypocritical in this regard).

I think that there are three relevant artifacts: the code, the specification, and the proof.

I agree with the author that if you have the code (and, with an LLM, you do) and a specification, AI agents could be helpful to generate the proof. This is a huge win!

But it certainly doesn't confront the important problem of writing a spec that captures the properties you actually care about. If the LLM writes that for you, I don't see a reason to trust that any more than you trust anything else it writes.

I'm not an expert here, so I invite correction.

"Couples often flake together. This changes the probability distribution of attendees considerably"

It's interesting to consider the full correlation matrix! Groups of friends may tend to flake together too, people who live in the same neighborhood might rely on the same subways or highways...

I think this is precisely the same problem as pricing a CDO, so a Gaussian Copula or graphical model is really what you need. To plan a great party.