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

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

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...

Dean is saying (implicitly) that you can estimate performance, and therefore you can design for speed a priori - without measuring, and, indeed, before there is anything to measure.

I suspect that both authors would agree that there's a happy medium: you absolutely can and should use your knowledge to design for speed, but given an implementation of a reasonable design, you need measurement to "tune" or improve incrementally.

0: https://gist.github.com/jboner/2841832

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.

On the other hand, there are Real Programmers [0] who will happily optimize the already-fast initializer, balk at changing business logic, and write code that, while optimal in some senses, is unnecessarily difficult for a newcomer (even an expert engineer) to understand. These systems have plenty of detail and are difficult to change, but the complexity is non-essential. This is not good engineering.

It's important to resist both extremes. Decision makers ultimately need both intimate knowledge of the details and the broader knowledge to put those details in context.

0. http://www.catb.org/jargon/html/story-of-mel.html

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

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.

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.

https://blog.codinghorror.com/new-programming-jargon/#:~:tex...

  - bad communication possible in any medium
  - pptx in NASA even today!
  - issue is managers/SMEs communication differences
    - issues with technical papers
      - long
      - boring
  - vs word, excel, pdf...

Manager/SME Differences

  - context vs conclusion 
  - tell a compelling story
    - but give away the ending FIRST 
  - inherent personality differences
  - motivations/incentives/mindsets

Learning from disasters

  - medium guides message and messenger
  - blame tool - binary choice?
  - presentation aide vs distributed technical artifact

Questions?

If you ask an LLM where you can find a structured database of knowledge with structured semantic links, they'll point you to this and other knowledge graphs. TIL about Diffbot!

In my experience, it's a lot more fun to imagine the perfect database like this than it is to work with the actual ones people have built.

P vs NP, of course, but also the halting problem and Rice's theorem: non-trivial semantic properties of programs are undecidable.

In other words, if you say "this is the solution to that sudoku puzzle", that's easy to verify. "This sudoku puzzle has a solution" is almost certainly much harder to verify. "Here's a program that can solve any sudoku puzzle - impossible (in general).

https://snap.stanford.edu/class/cs224w-readings/Brin98Anatom...

"The research described here was conducted as part of the Stanford Integrated Digital Library Project, supported by the National Science Foundation under Cooperative Agreement IRI-94 11306. Funding for this cooperative agreement is also provided by DARPA and NASA, and by Interval Research, and the industrial partners of the Stanford Digital Libraries Project."