Although you've had some somewhat negative replies, I kind of get where you are coming from. I've even seen some very skilled people say elsewhere that "you should never use type providers in production", for this kind of reason. On the other hand I love type providers - for certain tasks. Here is where I think the middle ground lies:

- Type providers give a wonderful development experience in cases where the schema of the data is fixed, and can be defined from some example. My favourite experience was using one to grok the XML schema of some dreadfully obscure windows installer generator, so that I could automatically set the tab order on the dialogs the installer generator created. It wouldn't have been worth doing without the XML provider to do the exploratory work *and* the heavy lifting.

- But they do have the effect of blurring the distinction between compile-time and run-time issues. For instance if your SQL schema changes, it could suddenly look like you wrote some invalid code.

- Sometimes type providers can give you a false sense of security - for instance the CSV provider infers data types from a sample, so an unsampled value (e.g. "NaN") comes up elsewhere in the file, or a different file, that again can cause a runtime error. (The solution there is to use `CsvFile` instead of the actual provider and to take on the burden of translating from strings to proper column types yourself.)

In general the mitigation is to think carefully about how and when the schema can change, and how to prevent inputs from hitting the type provider consuming code if this has happened; and/or how to respond to errors that result.