AI Engineering

The method is stated plainly enough to hold them to: choosing a model is guess and check. What makes the walkthrough useful is that it attaches numbers to steps usually described qualitatively. A customer service agent handling returns starts at 76 per cent quality — their framing is not bad, not great, not shippable, with production needing 90 or better. The progression that follows is ordered by cost rather than sophistication: show the model a pattern to imitate, then supervised fine-tuning of a smaller model with scores moving as you go, then reinforcement where answers are checkable. The observation most likely to survive is about curriculum — you do not teach the hardest problem first, you teach addition before you teach arithmetic — which makes training data ordering a design decision rather than a preprocessing detail. What the session does not supply is the volume at which the effort amortises against serving cost.

Microsoft Build

Three claims here are worth separating from the announcements around them. The speech numbers are meaningful in different ways: blind preference testing is the right evaluation for synthesis where no ground truth exists, and a latency under 150 milliseconds crosses the threshold where spoken exchange stops feeling like a request and starts feeling like conversation. The principles slide contains an actual position rather than decoration — capability should be learned rather than inherited, which takes a side in a live argument about building on existing base models versus training capability directly. And the training description carries the most transferable idea: generate solutions, score against verifiable ground truth, reinforce the better ones, with the clause about verifiability doing all the work. That explains the shape of progress across the field, and it is the same boundary Hassabis drew at Davos, arriving here as engineering description rather than forecast.

Microsoft Build

Everything in this session is downstream of one diagram: an accelerator has finite memory bandwidth and finite compute throughput, and where a workload sits between them is decided by how many operations it performs per byte read. Landing memory-bound means expensive compute units idle while data arrives, and every technique demonstrated exists to move a kernel across that line. The natural objection is that a compiler should handle this, and the implicit answer is that it cannot, because the decision depends on tensor shapes whose relative importance a general compiler cannot infer. The kernel structure repeats identically for every operation — allocate on-chip, copy down, compute, copy back — which is an explicit data-movement schedule with arithmetic attached, and which ties the code to one memory hierarchy. Two practices are worth stealing regardless of hardware: measuring on a few layers rather than a whole model, and verifying numerical equivalence rather than assuming it.

AWS re:Invent