Satisfying the static language's compiler usually doesn't require more code; it requires more-correct (ie. less buggy) code.
And the statically typed program is probably going to contain a lot less code than the dynamic program, especially if you consider all the extra code you'd need to write in those unit tests which simply duplicate the guarantees that you get for free when you use the static language's compiler.
Satisfying the type-checker can take a huge amount of extra code if you use type annotations everywhere. Even more so if you don't make good use of polymorphic functions.
Which is of course ludicrous--no one would create a static-typed language that made you code that way; it'd be practically unusable.
Most modern statically typed languages (for example, Haskell, ML, and OCaml) feature type inference; which means you don't have to annotate types except in very unlikely corner cases.
My own experience with some of these languages has been that when the compiler complains, it's because of a bug in the program, not because it can't figure out a type without annotation. So, a statically typed language's compiler becomes, in effect, a bug detector (to a much greater extent than a dynamically typed language's compiler or interpreter can be).
Having such a bug detector can be worth its weight in gold. But just how useful it is depends on how good the error messages are (or how good the programmer is at deciphering them). Unfortunately, this is an area that leaves a lot to be desired. But if you're seriously concerned about safety, statically typed languages (with all of their shortfalls) are still clearly the way to go.
You may want to reread my post with the sarcasm bit flipped to "on"; I was trying to make fun of static-typed languages that don't have type inference. Sorry about that.
I was actually hacking on some Haskell just now, in fact, trying to fix a "bug". ("Couldn't match expected type `ProgrammerThatUnderstandsMonads' against inferred type `Newbie'")
Depends on the expressiveness of the language type system.
Duck-typing may save quite a bit of code when dealing with generic functions without the complexity of a sophisticated type system (See "Scrap your boilerplate" for the Haskell approach).
