diff --git a/how-i-use-mise.md b/how-i-use-mise.md
index a5560ab..437d9dd 100644
--- a/how-i-use-mise.md
+++ b/how-i-use-mise.md
@@ -28,81 +28,9 @@ often run tests or builds with in the IDE. Not sure why, just never been
 in the habit of that. (Because of that these docs and possibly mise support in
 IDEs may not be what it should be-it's just not how I work personally).
 
-## What makes me unique
-
-I'm often working on mise itself. Even when I am working on other projects
-I still use mise quite a bit but often I'm experimenting and trying new ideas.
-
-I am also quite different personally. I have a bizarre obsession with
-the CLI environment. I am constantly experimenting with new techniques
-and tools. My environment is often in a state of disarray.
-
-I _do not_ like shell extensions-of which `mise activate` is certainly one.
-Now this isn't me telling you how I think you should be whatsoever,
-(please don't think of _any_ of this doc as that). I will explain my
-story around these a bit though.
-
-Back when I first got out of college, I was a rails dev. I remember
-people using `bundle exec` (often aliased to "be"), to run the CLIs
-that gems provide. At the time, I found that maddening. Why on earth
-would I run `be rails c` when I could just run `rails c`? I actually
-don't think I understood what `be` actually did-though I'm positive my
-exuberant personality at the time would claim I did.
-
-This ties into my development with mise itself actually. I put myself
-back in those shoes using rbenv or chruby or whatever I was using. I
-really didn't want to know about shims and these version managers. I
-was interested in ruby/rails at the time and the CLI stuff was a
-distraction for me.
-
-I empathize with that past self and that's the reason the
-"golden path" for mise is to use `mise activate`. I'm making it for
-my 25 year-old self that didn't want to understand this stuff so I've
-tried to make it easy, reliable, and to do the right thing with as
-minimal "magic" as necessary.
-
-Now what I've discovered along the way is I actually don't really like
-using version managers! Before mise, I would just manage path directly
-and use `./configure && make && make install` (with a special PREFIX) 
-to install even things like node and python! Once I started writing CLIs as my full time job,
-I gained a much deeper understanding of things like `PATH` and how it is
-intended to be used. I bet more than a few of you are rolling your eyes
-at the idea that `PATH` could be complicated. I would argue, however,
-that there is actually an art around these things that's actually quite
-profound. It also certainly _becomes_ quite complicated once you start
-asking questions like "how does xcode get PATH?", or "is it .profile or .bash_profile that runs first?", and a million other tiny questions
-I find myself asking again and again because these small details actually matter a ton.
-
-Anyways, not sure if I'm actually arguing with a mystery person there,
-but what I'm getting at is I developed a deeper interest and understanding around the shell in general. I became quite picky about being explicit over making things easy for myself.
-
-I actually don't think people should follow my lead here. Not unless
-you also specifically have a passion for dev tools like me. I think
-the average person should learn as little as possible about the shell
-to get their work done. I think that idea is often mocked with engineers
-but I think that's wrong.
-
-There are whole universes of technology I have very little knowledge of.The shell is mine. You could say that mise is my attempt for me to take
-the load off of others and put the burden of the shell onto myself.
-
-Now, if that statement rubs you the wrong way, like maybe you think
-it's not the tool for you, well I suspect this article actually might
-be what you're looking for. If I'm able to have success with mise-and
-that wasn't always the case, I didn't use it myself until relatively
-recently-then I think you can too.
-
-Perhaps one day there will be a "I don't care about the shell" and
-"I care about the shell a lot" method for using mise. Not sure.
-
-:::tip
-I'll get to this later, but the essential difference here is that the
-"I care a lot" approach is not using `mise activate` and instead relying
-on `mise exec`, and `mise run`.
-:::
-
 ## `mise activate`
 
-Unlike probably nearly all mise users, I don't use `mise activate` or
+Unlike most mise users, I don't use `mise activate` or
 shims at all unless I'm explicitly testing them-and that's rarely the
 case. It certainly doesn't go into my `~/.config/fish/config.fish`.
 
@@ -113,7 +41,7 @@ Because I work on mise itself, I often need to rebuild it and run the code from
 #!/usr/bin/env bash
 set -euo pipefail
 
-cargo run -q --all-features --manifest-path ~/src/mise/Cargo.toml -- "$@"
+exec cargo run -q --all-features --manifest-path ~/src/mise/Cargo.toml -- "$@"
 ```
 
 :::info