Some relatively unstructured thoughts: I'm not sure I agree with 2 for this use case: writing the GDP table is a pain because table markup is (necessarily) verb

Some relatively unstructured thoughts: I'm not sure I agree with 2 for this use case: writing the GDP table is a pain because table markup is (necessarily) verbose, and it's fiddly to copy and paste all of those fields individually. If I can get 95% of the way there with a couple of syntax errors that are picked up/fixed by my linter then I'm a happy customer. That said the way he generates a table is in no way idiomatic react, where you take an array of objects and map the data on to the table. In terms of code generation, is it actually any better than using an emmet expression? `table>tr*10>td` (I've probably mangled that). What's interesting with the table example is probably the combination of "knowledge" and knowing enough about a DSL to generate a coherent output. I agree re cherry picking, though the initial fine tuning set is extraordinarily small, just 2 items. Generating a much larger dataset shouldn't actually be that tricky, though perhaps getting agreement on how to actually describe a layout in plain English might be more of a challenge. Would a plethora of descriptions for the same layout be a bad thing? Lastly, I've been using TabNine (https://www.tabnine.com/ https://www.tabnine.com/) for the past few months, and I'm convinced that some kind of language model text generation is going to change how we write code, it's already changed it for me. If I signal my intent pretty clearly up front, I would say most of my coding is now tabbing and occasionally pressing the down arrow. Even writing comments becomes an exercise writing an initial three of four words and tabbing out the rest. Ditto tests.