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

That's good advice to not lose your HEAD.

0: https://docs.divio.com/documentation-system/