diff --git a/fine/design.md b/fine/design.md
new file mode 100644
index 00000000..506a3d0d
--- /dev/null
+++ b/fine/design.md
@@ -0,0 +1,41 @@
+# Design Notes for the Fine Language
+
+This language is being designed as I go, because the main thing I'm
+interested in is building something that's fun and productive for me
+personally. That means, rather than being super careful, I'm just
+building the thing that pleases me at any given moment.
+
+Here are some notes. The notes are for me in the future, in case I'm
+wondering why the language is one way instead of another way.
+
+## The `new` keyword
+
+I really like rust's "just use a type name with curly braces to
+construct new values". It's really clean! Unfortunately it leads to an
+ambiguity in the syntax that I don't like:
+
+``` rust
+if something { ...
+```
+
+In the code above, after I have parsed `something` and I see `{`, am I:
+
+- Parsing an object construction expression for the type `something`?
+- Parsing `something` as a boolean value reference and `{` as the
+  start of the block?
+
+Naively you would expect the latter, but if I scan ahead a little more:
+
+``` rust
+if something { foo: true }.foo { }
+```
+
+Rust does not allow `struct` literals in the condition of the `if`,
+which is correct, but that's more work than I want to do here. There's
+just a lot of context flowing around about whether or not I can parse
+a structure literal in any particular situation.
+
+The `new` keyword is a compromise: we know that the context
+immediately following the `new` keyword is always a type expression,
+so we know that e.g. `<` or whatever means "generic type parameter"
+and not "less than".